RE: Traffic Selectors (was SA fragments)

["Bora Akyol" <bora@cisco.com>]

 "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.
> 

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 :--->

> 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? ...)
> 

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.

> 	- 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.
> 

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)