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

[Nicolas Williams <Nicolas.Williams@sun.com>]

On Fri, Feb 20, 2004 at 04:15:14PM -0500, Stephen Kent wrote:
> 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.

But in that case the transport mode SAs would still be end-to-end and,
outside the end-point fragmentation in BITS implementations, the clear
packets would not be fragmented prior to application of transport-mode
protection.  Right?

> 	<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 :-)

Right, but there is a limit: assume 100% of traffic to be protected is
fragmented.  :)

I know, assuming 100% IPv6 traffic, 100% of packets fragmented, avg.
fragment size on the order of 1-2KB and 4 fragments per-packet on avg.
that would make the cache size be on the order of 1GB (!) for 10Gb/s.

With more reasonable assumptions (and path MTUs :) I think an SG can get
by with a far smaller cache, but one fast small-MTU link could cause the
SG packet drop rates to make some users miserable.

But this is "just" a trade-off: if you want support for the use multiple
SAs for the same SA end-points plus port selectors in VPN/BITW SG SPDs
then you must configure your network with sane MTUs.

I'd better read Charlie Lynn's proposal now :)

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

If all necessary selectors are not visible in the initial fragment,
drop.

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

Right, it makes me queasy too, but seems to be within what one can
expect of IP anyways.  And since the fragmented packets are coming in on
a clear interface (red, black, whatever the terminology is nowadays) the
SG can't really vouch for their integrity; if the clear packets are
really protected with a nested SA there's going to be no issue anyways,
and if they're not, well, then presumably they can be trusted, else the
SG wouldn't apply IPsec to them.

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

I meant an end-point receiver.  Presumably an SG wouldn't have to
reassemble packets it is tunnelling -- it would apply the fragment
selector/id caching approach to select an SA for fragments (and then
only if the SPD has entries that use selectors that can be obscured by
fragmentation) as discussed.

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

Exactly.

Nico
--