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

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

On Fri, Feb 20, 2004 at 09:47:15AM -0500, Stephen Kent wrote:
> At 14:55 +0200 2/20/04, Tero Kivinen wrote:
> >Actually it can, but it requires little bit work. For example our code
> >does the following (I do know that this is much more than what is
> >required by the rfc2401):
> >
> >	1) If it receives unknown non-first fragment, it will put it
> >           in the separate queue (queue length and number bytes
> >           consumed is limited).
> >	2) When it receives the first-fragment it will find the SA
> >           suitable for it, and send packet forward.
> >	3) Then it will search through the non-first fragments queue
> >           and find other fragments for the packet, and send those
> >           forward (verifying in the process that the fragments do not
> >           overwrite the fields used in selecting the SA).
> >	4) It will create known-fragment entry to database, marking
> >           that if we see other fragments to this packet, they can be
> >           sent forward to this SA if they start after this offset.
> >           This entry will timeout after some time.
> 
> this sounds like a reasonable mechanism, though perhaps not not a 
> very high speed context, since receipt of an initial fragment could 
> trigger transmission of delayed non-initial fragments, which implies 
> possible further disruption to transmission. but, under the right 
> circumstances I can certainly see how this could work.

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.

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 BITW scenarios with SPDs that use port selectors this issue comes up,
as it does in one side of SG/VPN scenarios, right?

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

Cheers,

Nico
--