Re: IKE negotiation for fragmentation controls in IPsec

[Tero Kivinen <kivinen@ssh.fi>]

Stephen Kent writes:
> This does not really convey the right semantics.  What we want is for 
> the sender of the payload to say "I will NOT send any post-IPsec 
> encapsulation fragments." Any receiver MUST be able to accommodate 
> fragments that occur prior to IPsec encapsulation, because these 
> fragments could have been generated by a host before arriving at the 
> IPsec device. The goal of the proposed payload is to inform the 
> receiver so that the receiver can mark an SAD entry to reject all 
> fragments that arrive (prior to IPsec encalsulation).

Ok, so:

----------------------------------------------------------------------
         NO_FRAGMENTED_IPSEC_PACKETS		24587

             By sending this notification the sender announces that it
	     will always fragment packets before encapsulating them to
	     the IPsec packets, i.e the recipient of this notification
	     MAY drop all fragmented IPSec packets, as they are not
	     generated by the other end.
----------------------------------------------------------------------

would be better?


> We agree that there is no need for a receiver to reassemble. However, 
> so long as we prevent fragments with too-short offsets from 
> traversing an SA, I'm not sure much damage (other than a form of DoS 
> on an SA where the Source and Dest IP addresses are already 
> acceptable) will be done if we allow fragments to pass before we see 
> the initial fragment at the receiver.  That avoids the need for any 
> buffering at the receiver, which it self might create DoS concerns.

The most common fragmented packets that can cause damage is when the
attacker attacks the reassembly code of the final recipient, i.e send
packets whose offset + size > 65536, or suitable packets filling up
the reassembly queue in the receipient and causing denial of service
attack.

There are some attacks where you generate for example fragments each
having 8 bytes of data, and leave gap between each of those. This
means that the recipient might have 4000 of those in its reassembly
queue. If this queue is linear sorted list, and every time you send
the fragment the code searches the suitable place where to insert the
fragment it means 4000/2 list operations per fragment, which will take
considerable cpu-time (yes, I have seen this attack to work, and the
machine was completely trashed by just very few such packets).

This does not need the first fragment at all.

Also another attacks are done by sending lots of non-first fragments
to the recipient and again filling up the queues.

I think the reason than most of the firewalls (and I assume also
security gateways) want to check the fragments is that they want to do
some sanity check them before letting them through, i.e some of them
simply drop all fragments that are too small (unless they are the last
ones) and also they might even check that there is no overlapping
areas in the fragments (might be attack, and should not happen in
normal case) etc. Making sure that the reassembly code in the sgw can
handle all attack cases is easier than trying to fix all the hosts
behind them.

I agree, that we propably could also allow letting the non-first
fragments through, but I think we need also some text of possible
attacks and checks that should be done in those cases. And of course a
good explanation about the risks of letting fragments with too small
offsets through.

I.e I want to see the final text before I can say more about this
issue...
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/