Re: Traffic selectors, fragments, ICMP messages and security policy problems

[Mark Duffy <mduffy@quarrytech.com>]

At 11:44 AM 3/18/2004 +0200, Tero Kivinen wrote:
>Mark Duffy writes:
> > >If only 1% of packets are fragments, and they all miss first fragment
> > >for some reason, then you need 66 MB of buffer space to store the
> > >non-first fragments for 64 seconds.
> > >
> > >Does anybody have any statistics how much of the packets in the net
> > >are fragmented?
> >
> > I believe the 1% number is very low for IPsec packets, due to the 
> frequency
> > of adding ESP to 1500 byte cleartext packets and then transmitting the ESP
> > packets over ethernet.
>
>That fragmentation happens after IPsec, thus it not concern here. We
>are now talking about the packets arriving to the SGW which are
>already fragmented at that point. If PMTU etc works perfectly there
>should not ever be any TCP packets that are fragmented, and most of
>the UDP traffic is for small packets, with only exception of the NFS
>etc.

That fragmentation can happen before IPsec, and is highly likely to in 
high-speed implementations.  And PMTU discovery does not work perfectly.


> > And, the typical % of fragmented packets is
> > probably irrelevant anyway; malicious attacks are a more serious
> > consideration.
>
>The typical % of fragmented packets is important, as we need to make
>sure the protocol works fine in normal case. If there is an attacker,
>we simply need to make sure the protocol can still work, and it does
>not crash or run out of memory, but the performance does not have to
>be optimal (i.e. we might want to drop some of the non-first fragments
>in those cases, just like the normal host reassembly will do
>currently).

I agree with your statement here in a general sense and indeed that is how 
many things work.  But here there are several options on the table that 
would allow the protocol to be *more* resistant to attack, such that 
legitimate fragments do not suffer as a result of such an attack.  (The 
options I mean are the approaches that do not call for an IPsec 
implementation to "reassemble" fragmented packets.)


> > I stand by the statement that requiring logical "reassembly" is 
> anathema to
> > high-speed implementations.
>
>And you still claim that we do need port-selectors and fragments in
>those high-speed implementations?

I can accept an approach where a SG can do either port-selectors or 
fragments.  However, I would prefer to do both, without reassembly.  This 
could be accomplished by several means that have been discussed on this 
list including having a separate SA for fragments, or allowing non-initial 
fragments to be sent under a different policy entry than other packets 
(e.g. one with port selectors of "opaque".)

--Mark