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

[Tero Kivinen <kivinen@iki.fi>]

Stephen Kent writes:
> >	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.

In most(*) of all cases the packets are processed in order, thus the
only need is to store the information that allow other fragments of
this packet to go through.

(*) There used to be bug in the linux kernel where it sent all
fragments always in reverse order, i.e. the last fragment first and
the first fragment last. This bug was fixed some time ago, and all
decent implementations should send the packets in order anyways, and
because we are now talking about the connection from the end host to
the SGW (from the senders point of view) there are not that often
reordering happening in the internal network before the SGW. From the
responder's point of view the case is harder, as the connection
between SGW and SGW might more easily cause reordering of packets,
thus forcing the responder to store the fragments coming before
first-fragment.

If the current approach is to drop all fragments (or create new SA for
non-first fragments), I think this proposed solution have less impact
on the overall performance of the system (ok, dropping all fragments
would be faster, but not very workable solution). 

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

Yep. 

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

No, there are no ports there in the responder side. The responder will
check the ports when processing the first fragment, from the rest of
the fragments of the same packet it simply needs to know that they
came from the same SA, and they do not overwrite the data already
checked (i.e. source-ip/destination-ip/protocol/fragment-id are used
to identify the 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.

I do not think it will cause that much more processing, it is much
less processing that will be required if reassembly method is used
instead. I.e. reassemble the packet when getting it in, then select
SA, fragment it again, send it out, reassemble the packet in the other
end again, check the security policy, fragment the packet again, and
send it out. The reassembly method and the method described in the
beginning of the email are interoperable.

Also as the fragmented packets are not used that much, and even if
they are used the packets are in most cases received in-order, and in
those cases the extra processing burden caused is quite small.
-- 
kivinen@safenet-inc.com