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

[Stephen Kent <kent@bbn.com>]

At 11:54 -0600 2/20/04, Nicolas Williams wrote:
>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.

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.

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

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

Steve