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

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

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