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

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

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.

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


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

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