RE: SAs that carry fragments Was: Re: Some IKEv2 issues

[Stephen Kent <kent@bbn.com>]

At 12:07 -0800 2/19/04, Bora Akyol wrote:
>Thank you for your comments, please see inline
>
>>  -----Original Message-----
>>  From: Stephen Kent [mailto:kent@bbn.com]
>>  Sent: Thursday, February 19, 2004 11:40 AM
>>  To: Bora Akyol
>>  Cc: 'Tero Kivinen'; Barbara Fraser; 'Charles Lynn';
>>  ipsec@lists.tislabs.com
>>  Subject: RE: SAs that carry fragments Was: Re: Some IKEv2 issues
>>
>>
>>  At 10:41 -0800 2/19/04, Bora Akyol wrote:
>>  >Steve
>>  >
>>  >How often do we see multiple IPSEC Sas between the same two peers
>>  >protecting different ports (or in general different selector sets)?
>>
>>  I don't know, but I do know that we have mandated the ability to
>>  support this for over 5 years.
>>
>
>Yes, and people have figured ways of supporting this
>without needing separate SAs for fragments.

your said "ways" which is plural.  It's not enough for a vendor to 
decide how to map a fragment to an SA, since the receiver is supposed 
to check each received packet against the selectors for the SA via 
which it is received. So, if there is ONE way to do this, and 
everybody already does it, and if it accommodates all the possible SA 
configurations that a compliant implementation MUST support, then we 
should just describe that way in 2401bis.  But, what I fear you are 
indicating is that different vendors have different ways of 
accommodating fragments, and that these may not be common, which 
means that interoperability problems may (will) occur, OR that not 
all possible SA configurations will work.  if so, then we need to fix 
this situation.

>
>>  >There are better and straightforward ways of getting around
>>  the issue
>>  >of fragmented packets in the implementation without requiring a
>>  >separate SA for fragments.
>>
>>  what are they and why are they better?
>>
>
>I think in an earlier email Nicolas gave some examples of how this can
>be achieved and it can achieved efficiently without actually
>doing copies etc. Oh, they are better because they don't double the
>effective number
>of SAs that will be used for communication.
>For example, if I can currently support 1,000,000 IPSEC SA pairs
>(tunnels),
>then by having a separate SA pair for fragments is going to cut my
>capacity
>in half. This is a big loss.

your example seems a bit vague in some details, but I refer you to 
Charlie's message for this discussion.

>  > >As a side-note, configuring even the most basic traffic selectors in
>>  >some host OS that are widely-deployed is a big chore (really
>>  >hit-and-miss). The most deployed IPSEC scenarios supporting road
>>  >warriors don't even use a traffic
>>  >selector at the head-end.
>>
>>  I am aware of at least one very poor, definitely non-conforming,
>>  management UI for a widely deployed IPsec implementation.  But I
>>  don't think that a vendor's failures in this area ought to dictate
>>  our standards going forward.
>>
>
>No, but the standards should be simple, clear and easy to implement.
>Adding
>features that improve the protocol coverage by 0.01% while increasing
>code
>complexity by 1-3% is hardly worth the effort.

it's easy to make a contrast like that, but it's harder to justify the numbers.

>Speaking from an implementor's perspective,
>I think we should aim to cut rarely used features off existing IPSEC
>standards
>as opposed to adding to the feature set. Generality is good but it comes
>at
>a cost of implementation complexity, interoperability problems and
>deployment headaches.
>I think the traffic selectors and their broad flexibility is one of
>these features.
>For example just by cutting port based selectors for TCP and UDP,
>cost of doing security policy checks goes down exponentially for most
>software
>and linearly for most HW. This has huge scalability benefits if ever
>IPSEC is
>going to get widely deployed.
>I am sure at some point before the 2401bis and IKE V2 efforts were under
>way,
>there must have been a deployment survey performed. If that is the case,
>then we should look at that and cut the features that are not used at
>all,
>cut features that are rarely used and agree on a core set of features
>and
>specify these clearly from both protocol and management perspectives.
>
>Regards,
>
>Bora

Sorry, but I cannot agree with your suggested approach to deciding 
what is and is not important for any standard. What is and is not 
used in current deployments may be a good measure of what folks need, 
or is may be an artifact of limits imposed by current 
implementations, etc.

We have removed some features from IPsec that were complex and not 
widely used. in the selector area we have added support for ICMP 
because folks asked for it.  we added the ability to map multiple 
distinct protocols to an SA to reduce the number of SAs, without 
loosing security functionality.

Steve