Re: IKE negotiation for fragmentation controls in IPsec

[Stephen Kent <kent@bbn.com>]

At 7:25 PM +0300 6/30/03, Tero Kivinen wrote:
>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?

"... encapsulating them with IPsec ..." and fix the spelling of IPsec :-)

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

like I said, DoS concerns.

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

agreed

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

remember, we have this problem already if the SA does not use port 
field selectors. the relaxation I suggested merely allows the sender 
to say that they want to send fragments despite the presence of the 
port field selectors.

>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 in principle.  But, unlike the generic firewall case, here we 
know the source of the traffic and we do have some recourse for the 
DoS attacks, i.e., shutting down the SA and having a chat with the 
admin at the other end, if we are willing to accept that sort of 
remedial action.

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

Fair.

Steve