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

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



Hi Bora,

Maybe you missed some of the earlier emails...

> >There are better and straightforward ways of getting around the issue 
> >of fragmented packets in the implementation without requiring a 
> >separate SA for fragments.

The WG rejected the idea of a *separate* SA for fragments.

We are now talking about how to indicate that an existing SA should be
used to carry fragments, that is interoperable (can be communicated
via IKEv2) so that the packets the sending implementation puts into
the SA will be consistent with the receiver's access control policy (SA).

How the sending implementation figures out that a packet is a fragment
is a local matter.

> I think in an earlier email Nicolas gave some examples of how this
> can be achieved ...

> > There are better and straightforward ways of getting around the
> > issue of fragmented packets in the implementation
> > without requiring a separate SA for fragments.

> Delay policy evaluation until fragmented packets are reassembled?  This
> might be fine for transport mode SAs [but not for tunnel mode SAs?].

It requires memory in, e.g., a security gateway, code to do
fragmentation and reassembly, and makes it harder to keep up with line
rate.

> Queue fragmented packets for reassembly remembering what SA protected
> each fragment, then when the packet is reassembled, and if all fragments
> were protected by the same or congruent SAs check SPD, otherwise drop.

Is this at the sending end of the IPsec channel or the receiving?
I.e., "what SA protected each fragment" sounds like the receiver.
If the fragments got that far, a solution that protects fragments
is assumed, but not identified.

> and it can achieved efficiently without actually doing copies etc.

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

The suggestion I made does not require any copies, and dos not double
the number of SAs.

> No, but the standards should be simple, clear and easy to
> implement.

Agreed.

> Adding features that improve the protocol coverage by 0.01% while
> increasing code complexity by 1-3% is hardly worth the effort.

Where did you get these numbers?

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

Not always.

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

Well, not using port selectors might make sense for VPNs, but IPsec is
designed for more than just VPNs.

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

That sort of assumes that past usage is a good predictor of future use.
I think that the Internet has proven that not to be the case more than
once.

Charlie