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

[Nicolas Williams <Nicolas.Williams@sun.com>]

On Fri, Feb 20, 2004 at 02:20:01PM -0500, Stephen Kent wrote:
> At 11:54 -0600 2/20/04, Nicolas Williams wrote:
> >Or just drop non-initial fragments arriving before their corresponding
> >initial fragments (or so much later that the corresponding initial
> >fragments have fallen off the cache).
> >
> >IP can lose packets.  Sometimes it's good to excercise this feature.
> 
> yes, sometimes taking advantage of this "feature" can make our lives 
> easier as designers ;-)

:)

> >In transport mode scenarios (IPv4) this doesn't apply either since the
> >sender won't fragment and any middle boxes would fragment protected
> >traffic between the transport mode peers so there's no fragment
> >protection issue.  (I should have noticed this earlier instead of piping
> >up about transport mode.)
> 
> In a BITS implementation the host could have fragmented prior to 
> IPsec receiving the packet, but one would certainly expect that the 
> first fragment would arrive at the BITS first in that case.

Good point.

> >In BITW scenarios with SPDs that use port selectors this issue comes up,
> >as it does in one side of SG/VPN scenarios, right?
> 
> It used to be the case that transport mode was restricted to end 
> systems, but due to popular demand we have removed that restriction. 
> so, this used to be just a tunnel mode issue for SG scenarios, but it 
> might arise for transport mode too,under our new paradigm.

I thought that SGs were allowed to use transport mode for administrative
traffic where the SG is an end-point.  Is this a misunderstanding of the
new paradigm?  If not then no issue here.

> >
> >[...]
> >> >Or to do the fragment handling properly, i.e. put them to the same SA
> >> >which haves the non-first fragments.
> >>
> >> What concerns me is that the processing you describe could be a
> >> significant burden, maybe even infeasible, for very high speed
> >> operation.  We have focused more on such operation in this round of
> >> revisions, e.g., support for 64-bit sequence numbers and explicit
> >> discussion of caches. Thus I would prefer a spec that works well in
> >> all cases.
> >
> >If you remove the store-and-forward aspect of the proposal and drop
> >non-initial fragments for which you can't find a matching initial
> >fragment entry in the cache, then the only burden is that of keeping a
> >small cache of initial fragment identifiers, which means:
> >
> > - a small computational hit on initial fragments: cache id
> > - a small computational hit on non-initial fragments: lookup id
> > - a fixed memory hit
> > - plus the burden of any additional restransmitted traffic that may
> >   result from dropping some non-initial fragments; the cache should be
> >   sized accordingly
> >
> >The cache is indexed by selectors visible in a fragmented packet
> >(protocol, addresses) and packet ID; collisions are irrelevant, as are
> >fragment offsets.  LRU, LFU, aging, can be used to deal with cache
> >pressure.
> 
> I'm not sure how to size the cache, but otherwise I think your 

Probably according to the proportion of traffic that is fragmented and
which must be protected.

> analysis is correct, based on dropping non-initial fragments. one 
> also has to deal with housekeeping issues, e.g., timing out fragment 
> IDs, to prevent possible mismatches, and one needs to specify the 

How bad would mismatches be?  They may get protected with an incorrect
SA, but the receiver should be the same either way (if not, that would
be a bigger deal) and should then simply drop them since they wouldn't
match a correct first fragment (and if they did the result would, in all
likelyhood, not match various checksums and the like, leading to the
full packet being dropped which, again, would be within spec).

> receiver-side algorithm too, e.g., remembering packet IDs for initial 
> fragments so that the later fragments are treated as acceptable. but, 
> is this easier than what Charlie Lynn described?

I'd have to re-read that.  In any case, the receiver already has to
track packet IDs for reassembly, so now all it has to do in addition is
track the SA that was used to protect each fragment and drop any
fragments that don't use an acceptable SA.  Unlike an SG, the receiver
here probably wouldn't want to drop non-initial fragments received
before their intial counterparts, if it can avoid it, and should have
the necessary buffer space, usually, so the receiver here can behave as
Tero proposed -- it does not seem like this would impose much of a
burden on the receiver.

Nico
--