Subject: Traffic Selectors (was SA fragments)

From: "Bora Akyol" <[email-masked]>
Date: Fri, 20 Feb 2004 08:42:15 -0800

I think there is agreement that port based selectors 
do not make sense for tunnel mode. 

#1 use of transport mode SAs that I have seen is
GRE over IPSEC which also does not require port
selectors.

The other application of transport mode is communication
between two hosts. Nicolas brought up an excellent
point of a multi-user system where each socket can
require a different security protection level.
Even though the current socket APIs that I am aware of
are not capable of specifying a security protection grade,
I am sure this can be put in with some work. There is also 
the security policy management issue of how does an application
decide the security grade and is it better off using TLS, but that
is another nest of worms.

So based on this I would like to propose the following text
for traffic selectors (and please feel free to edit
and comment):
 ---
All IKE implementations MUST be able to negotiate IPSEC SAs 
based on tuples of {IP Source Address/Mask, IP Destination Address/Mask,
IP Protocol}.
Additionally, an implementation MAY support any traffic selector
of the form (Offset, Length, Value, Mask) where:

Offset: Offset of the field from the end of the IP version field in the
IP header.
Length: Length of the field being compared for SPD determination
Value: Value of the field
Mask: A bitmask that can be used for masking the value.

 ---

Note that range specifications are limited to bit boundaries for these
fields
but this should not be a significant limitation. If the word MAY is too
weak
for optional selectors, it can be changed to a SHOULD.

Comments?

Bora

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Feb 2004 14:05:40 -0500

Bora,

>do not make sense for tunnel mode.

Are we reading the same mailing list?  there is not agreement on this 
point.  You may keep saying it, but that does not make it so :-)

By my count, you posted one message to this list in all of 2003, 
three in late 2002, and four in August and September 2001. That tells 
me that you have been aware of the work of this WG for at least 2.5 
years, but have made almost no contributions during that time.  Now, 
5 years after we published 2401, you propose a significant change to 
the use of selectors.  I think you are way too late and have 
contributed far too little to be taken seriously in this regard.

Steve

---

From: "Bora Akyol" <[email-masked]>
Date: Fri, 20 Feb 2004 12:19:00 -0800

I wrote several responses to this, but chose
not to send them,
if there is no technical merit to my proposal
on traffic selectors, then be it. I will
point out that the proposed offset based 
optional selectors 
work equally well for v6, v4 and any other
protocol that does not use TCP/UDP.

Bora
-- Speechless SW engineer in San Jose

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]] 
> Sent: Friday, February 20, 2004 11:06 AM
> To: Bora Akyol
> Cc: [email-masked]
> Subject: Re: Traffic Selectors (was SA fragments)
> 
> 
> Bora,
>

---

From: Paul Koning <[email-masked]>
Date: Fri, 20 Feb 2004 17:25:26 -0500

>>>>> "Bora" == Bora Akyol <[email-masked]> writes:

 Bora> I wrote several responses to this, but chose not to send them,
 Bora> if there is no technical merit to my proposal on traffic
 Bora> selectors, then be it.

 >> -----Original Message----- From: Stephen Kent
 >> 
 >> ... I think you are way
 >> too late and have contributed far too little to be taken seriously
 >> in this regard.

Bora is right.

If his suggestions have technical merit, they have that merit whether
he has contributed for 20 years or 20 days.  Conversely, if they have
no merit, they would still have no merit even if he had contributed
far longer and far more.

Can we please evaluate proposals on their technical merit and leave 
ad hominem comments out?

Thanks,
	paul

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Feb 2004 18:36:34 -0500

>Can we please evaluate proposals on their technical merit and leave

Paul,

OK, you opened the dialogue, so I'll respond.

We have been working on IPsec for a very long time.  We need not 
address every suggestion for a change that arises from anyone. If we 
did, we will never finish. Most WGs understand this and operate on 
that basis.

In this case, Bora made an absurd, and to me, offensive, assertion, 
i.e., "I think there is agreement that port based selectors do not 
make sense for tunnel mode." There is no rational basis for this 
assertion, based on the message exchanges on the list. In my opinion, 
anyone who sends a message of this sort is way off base.

So, I checked my files to see if this was a comment from someone who 
had a track record of contributing, since I am willing to give some 
credence to an individual who has been a contributor.  The result of 
my search is exactly what I stated.  It is an ad hominem argument 
only to the extent that it provides a factual characterization of why 
I believe his comments ought to be ignored.

While you are right that, in principle, anyone may be able to 
contribute a good idea to a discussion, we don't have the time to 
devote to work this way. Ask the ADs if they think we should 
reconsider every aspect of the WG's work based on comments from 
anyone who chooses to send a message, irrespective of his/her 
contributory status. If someone finds an objective, technical flaw in 
what we have proposed, then fine. But when someone suggests that, 
based on his personal view, an extant feature of an existing standard 
should be dropped and replaced with another, remotely analogous 
feature, that's a different matter.

As for the substance of his suggestion, I find that it has NO merit. It is:

	- half-baked (what if the offset goes beyond the next layer 
protocol headers into data?, how do we apply this to a fragment? how 
would it work with IPv6 headers with header extensions? how would it 
work with IPv4 packets that contain options? ...)

	- it would lead to interop problems because it's a "MAY" and 
because it imposes no constraints on what offsets, lengths and mask 
vales might be defined, thus leading to a new set of peer SPD 
coordination requirements.

any other questions?

Steve

---

From: "Bora Akyol" <[email-masked]>
Date: Fri, 20 Feb 2004 16:33:09 -0800

"I think there is agreement that port based selectors do not 
> anyone who sends a message of this sort is way off base.

Steve, please give a real world deployment example of how and why
the port selectors are used in tunnel mode? 

Why does a network administrator define a security policy 
that secures one port in tunnel mode differently than another. Then
how is this administrator sure that some malicious user
is not circumventing his policy and intentionally bypassing
the port based selectors.

What is the most common application of tunnel mode on the Internet
today? 

VPNs either site-to-site or remote-to-security gateway are
99% of the IPSEC deployments today. Transport mode is used
pretty much to secure GRE-over-IPSEC and avoid double header
penalties. Other than, it is all tunnels all the time
and none of these actually use port selectors.

The amount of people that participate on this list actively
and exchange messages, is a minute fraction of a percent
when compared to people that have actually deployed IPSEC.

This is starting to remind me a lot about the three monkeys,
so I am going to change the channel and go to the technical
aspects of my proposal :--->

> work with IPv4 packets that contain options? ...)

Think of this as a construct in a programming language. With this
construct
you can define either a TCP port or range, or you can even define
a completely different value/range set based on ip protocol type. For
example
I may choose a field in the GRE header and treat ranges in it 
differently using the security
policy. The idea is not half-baked. People have been using 
this type of a construct in various hardware (ASIC-based) or network
processors for a LOOOOONG time. 
And bounds checking and validation should be part of any good software
implementation. Or you can even use an MPLS label when encapsulated in
IP to decide what kind of security policy needs to get applied. I am
guessing
such a flexible format can come in handy even for some storage
applications.

> coordination requirements.

I left this out as a MAY/SHOULD because based on my experience in 
looking at customer problems, bugs, interoperability issues
since 2001, I have not seen people use ports as selectors and
personally I think this is really an optional feature until someone
writes an application that can make use of it.

Tuples that contain IP SA/DA masks/ranges and proto values seem to 
be enough for 99% of the people out there.

And finally, 
there was no reason to discredit me or insult my intelligence either
but you chose to do this anyway. You could have just argued your
case on the technical merits. Everyone knows who you are, not many
people
know me unless they have read RFC3443 or were in the MPLS WG. IMHO,
this is no way conduct a conversation on any WG in the IETF.

Bora
-- Speechless SW engineer in San Jose (SSEISJ)

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Fri, 20 Feb 2004 19:36:54 -0700

Steve made the perfectly valid point that you had years of opportunity
to suggest a major change but chose not to.  If you feel that reflects
badly on your intelligence, suffer in silence.  You also made a
sweeping assertion, setting yourself up as a self-proclaimed expert,
and Steve takes issue with that.  Finally, it is completely typical
for IETF draft authors to go ballistic when they are nearly finished
with a long and complex document that has had a lot of WG input and
then, at the last minute, find people popping out of the mailing list
with major changes.  In fact, in my experience, they go ballistic over
just about anything short of "looks great".  Human beings as they are
and all.

Hilarie Orman
Infrequent poster

On Fri, 20 Feb 2004 at 16:33:09 -0800 Bora Akyol asserted:

> people know me unless they have read RFC3443 or were in the MPLS WG. IMHO,

---

From: "Bora Akyol" <[email-masked]>
Date: Fri, 20 Feb 2004 23:24:46 -0800

Since these documents are about to go to Last Call 
(and I have been there before), this will be my last email
on this subject.
The thread is not productive other than raising my blood pressure :-)

And finally my apologies to the WG and Steve Kent specifically for
dragging on this
thread longer than it needed to be and not engaging in the conversation
3 years ago.

However, I would love to hear private/public opinions to the
semi-coherent
thought train that I wrote below:

----------------

How come I have not seen IPSEC policy specified
that contains TCP/UDP port selectors in reports from
the field?

Then I realized, when I use an SSL enabled POP client
to get my email, I am in fact using transport layer security
with TCP port numbers.
When I check my bank account balance, there again, SSL.

So answering Nicolas's question about multi-user trusted OS,
if I am an application developer and I have the SSL API available
to me, why do I trust the network layer to provide me
with the security? I don't, I use SSL or transport layer security.
One could also argue that this makes the application more robust
since it is not dependent on a lower layer for security.

If IP is the network layer, and IPSEC is a network layer
protocol, why does a network layer security protocol
care about transport layer traffic selectors? 

Is the inclusion
of transport layer traffic selectors (TCP/UDP ports) 
an optimization in the
original design? Or
is it now an redundant feature with the pervasive
deployment of SSL/TLS? 

Would application developers actually
ever trust the network layer to provide them with the security that
they need? How can an application trust the network administrator
(especially in a shared system)
to correctly configure security on a per transport layer demux 
port basis especially when money or financial information
is involved? That is, unless everyone is sharing the same security
policy in which case the port-based selectors are not needed.

If all one wants to do is secure a particular application running
over a specific but not pre-determined port (dynamic), then is the
transport layer security the easier way to go? 

Only time and deployment
experience will tell the rest of the story in terms of what
features get used or are left to die. However, if the recent
uptake in SSL-VPNs (search google/light reading for market predictions) 
is an indication, we have interesting times ahead.

Regards,

Bora
-- Sleepless SW Engineer in San Jose

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Feb 2004 10:10:01 -0500

>thought train that I wrote below:

I cannot account for what you have or have not seen.

>When I check my bank account balance, there again, SSL.

Presumably you are trying to argue that if one wants port level 
security, the one uses SSL, but SSL does NOT provide any built, in 
access controls, so this is an odd comparison.

>since it is not dependent on a lower layer for security.

there is considerable literature on the differences between SSL and 
IPsec security features, which suggests that there are good reasons 
for choosing each in different contexts. however, the argument that 
port level security is better provided by SSL is NOT part of that 
literature.

>care about transport layer traffic selectors?

IPsec is a security protocol that operates at the Ip layer.  It is 
NOT just an encryption, authentication, integrity protocol. Access 
control is an important feature of IPsec, as the 2401bis intro notes. 
IPsec offers access controls consistent with what a stateless, packet 
filtering firewall offers. this includes port level filtering.  the 
lack of stateful inspection is less of a concern here, because SAs 
are authenticated, and thus we know who/what is at the other end.

>is it now an redundant feature with the pervasive

badly worded question.  why not just ask if Ipsec has stooped beating 
its virtual wife?

>policy in which case the port-based selectors are not needed.

a narrowly focused question, since IPsec is implemented in multiple 
contexts, not all of which are available to application developers, 
even when IPsec is in a host, e.g., consider the NIC implementations 
of IPsec which are designed to be managed centrally, not by app 
developers.

>is an indication, we have interesting times ahead.

This WG would be ill-advised to make standards design decisions based 
on what trade rags say.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Feb 2004 10:31:48 -0500

>the port based selectors.

wrong question, again. port-level access controls can be used to 
allow access to some set of services at an address, but not others. 
for example, one could allow access to HTTP on a web server, but not 
SMTP. if this control were applied symmetrically, then the worm that 
compromised IIS systems would not have been able to spread itself to 
other sites via e-mail from compromised servers.  is that a good 
enough example?

>and none of these actually use port selectors.

we don't develop standards to accommodate only what people do today. 
if we did, then TCP would not be usable with HTTP, since when we 
developed TCP) the primary apps using it were Telnet, e-mail, and FTP.

>when compared to people that have actually deployed IPSEC.

and the number of people who fly on planes or pilot them is much 
greater than the number who design planes. your point is ...?

	<SNIP>

>this is no way conduct a conversation on any WG in the IETF.

I didn't question your intelligence. I pointed out how I perform 
triage on the vast quantity of messages with which I have to deal. I 
don't like wasting time responding to every message someone sends 
recommending a change to a spec. If the author of a message is 
someone with a track record of significant contributions, then I 
always pay attention, even if that person has not sent any traffic 
for a while. if the message is well thought out and polite, even if 
not from someone I know, it too will probably merit a polite reply. 
Your  message failed both of these tests. In retrospect it might have 
been better to just ignore it.

Steve