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

[Mark Duffy <mduffy@quarrytech.com>]

At 12:12 PM 3/17/2004 +0200, Tero Kivinen wrote:
>They need to do partial reassembly, meaning that in normal case
>(fragments in order, no dropped packets), the cost is 4+4+2+4 (src ip,
>dst ip, id, used spi) bytes per fragment for few seconds. If you are
>using 1GBit/s link and sending 8 kB packets fragmented to 6 pieces,
>that will mean 16k packet/s. If we assume the total memory needed per
>fragment is 32 bytes, and you want to keep them full ttl seconds (say
>64 seconds), then you will need 32 MB of buffers to store that
>information.

Ah, but if the fragments do not arrive in order, or some are missing, the 
situation is different, much different.  Even though this might not be 
naturally common, it happens sometimes.  And, it might be common as a 
malicious attack.  Devices would have to be built to handle it.

>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.  And, the typical % of fragmented packets is 
probably irrelevant anyway; malicious attacks are a more serious consideration.

I stand by the statement that requiring logical "reassembly" is anathema to 
high-speed implementations.

--Mark