[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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@xxxxxxx]
 Sent: Thursday, February 19, 2004 11:40 AM
 To: Bora Akyol
 Cc: 'Tero Kivinen'; Barbara Fraser; 'Charles Lynn';
 ipsec@xxxxxxxxxxxxxxxxx
 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