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

[Stephen Kent <kent@bbn.com>]

Nicolas,


	<SNIP>

>  > >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.
>
>I thought that SGs were allowed to use transport mode for administrative
>traffic where the SG is an end-point.  Is this a misunderstanding of the
>new paradigm?  If not then no issue here.

The old model allowed SGs to use transport mode for admin traffic. 
The new model allows SGs to use it for any traffic, e.g., so that an 
overlay net that does IP-in-IP tunneling can use transport mode for 
the already tunneled packets.

	<SNIP>

>  >
>>  I'm not sure how to size the cache, but otherwise I think your
>
>Probably according to the proportion of traffic that is fragmented and
>which must be protected.

that's hard to do a priori, right? if I am designing a hardware Ipsec 
implementation and need to decide how much memory to include for this 
purpose, this isn't a good algorithm :-)

>  > 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
>
>How bad would mismatches be?  They may get protected with an incorrect
>SA, but the receiver should be the same either way (if not, that would
>be a bigger deal) and should then simply drop them since they wouldn't
>match a correct first fragment (and if they did the result would, in all
>likelyhood, not match various checksums and the like, leading to the
>full packet being dropped which, again, would be within spec).

i agree that they would be sent to the same destination, but since an 
SG receiver is not required to reassemble plain text fragments, the 
issue is what happens at the real destination. long ago when we 
started discussing this issue there was a suggestion to check the 
offset for non-initial fragments (pardon the redundancy) to make sure 
that someone did not try to circumvent the receiver access control 
mechanism by sending a fragment with a port field that would not have 
been acceptable in a whole packet. this seems to be an easy check for 
v4, but it's apparently not feasible for v6, and thus we do have a 
concern re fragment reassembly attacks.

I was uncomfortable with the notion that we might send over fragments 
that don't really belong to the same packet, but maybe that's not 
fatal.

>  > 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?
>
>I'd have to re-read that.  In any case, the receiver already has to
>track packet IDs for reassembly,

an IPsec device such as an SG does not have to reassemble plain text 
fragments, at least not under the assumptions we have been using for 
the last 5+ years.

>so now all it has to do in addition is
>track the SA that was used to protect each fragment and drop any
>fragments that don't use an acceptable SA.  Unlike an SG, the receiver
>here probably wouldn't want to drop non-initial fragments received
>before their intial counterparts, if it can avoid it, and should have
>the necessary buffer space, usually, so the receiver here can behave as
>Tero proposed -- it does not seem like this would impose much of a
>burden on the receiver.

a receiver that is an end system could plausibly do reassembly and 
then subject the result to an access control check.

Steve