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

[Stephen Kent <kent@bbn.com>]

At 14:55 +0200 2/20/04, Tero Kivinen wrote:
>Stephen Kent writes:
>>  In 2401, and so far in 2401bis, we have distinguished between ANY and
>>  OPAQUE. if we decide to continue to do that, then at a minimum, we
>>  would not consider a fragment with no port fields to match an SA that
>>  allowed traffic with ANY as the value for port fields.
>>
>>  Also, If an IPsec implementation has two SA between the same
>>  source/dest address pairs, and with the same protocol value(s), but
>>  distinguished traffic based on specific (vs. ANY) port fields, then a
>>  non-initial fragment cannot be mapped to either SA unambiguously. An
>
>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.

>
>This will allow selecting proper SA for each fragment (non-first or
>first). Of course the other end needs to do the same processing when
>packets are processed to verify the selectors, in this case it is
>easier, as the other end has already waited for the first-fragment, so
>it will most likely come first (not necessary, the order might have
>changed during transit).

right. so there is some reassembly-like processing at the receiver, 
e.g., per SA state to remember initial fragment data plus queuing of 
non-initial fragments to accommodate out or order delivery, etc.

>So it is not impossible, it simply requires some work. We do not need
>to do full reassembly, we simply need to mark that fragment matching
>this source/destination/protocol/id should be sent/received from this
>SA.

you left put ports here, the crux of the problem, but I assume that 
was just a typo, right?

>  > analogous problem arises if there is just one, extant SA that matches
>>  the addresses and protocol, and we are forced to search the SPD to
>>  see if another SA might be appropriate. These observations motivate
>>  use of a separate SA to carry fragments, 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.

Steve