Re: [IPsec] IKE fragmentation

[Paul Wouters <[e-mail]>]

On Wed, 13 Mar 2013, Valery Smyslov wrote:

>> How is that a DOS attack? In our implementation of the IKEv1
>> fragmentation, we limit the number of fragments to 16. We will
>> only need to do any crypto when we received the IKE packet
>> marked as "last". Then we do crypto once on the assembled packet
>> and throw it away when crypto fails.
>
> If attacker sends you a forged fragment, you cannot determine this
> untill you get reassembled the whole message. When you determine
> this you have to discard all received fragments (as you don't know
> which of them is bogus) and wait for retransmission. For attacker
> it is enough to send you forged fragments with rather low rate
> to have a good chance to prevent you from communication with your peer.
>
> I think this is kind of DoS attack as Initiator is denied to get desired 
> service (IPsec).

But then the attacker has to know the SPI/COOKIES too? So it is an
in-path attack. But I see you point.

> I think that responder should start replying with fragments
> immediately after it receives first fragmented message from initiator,
> but not before this event. It is initiator who is responsible
> for retransmissions and it is his/her responsibility to
> switch on fragmentation.

Yes, this case is different for IKEv2.

>> Our implementation also does not handle the first packet of an
>> exchange to be fragmented, because we have no state to store the
>> fragments for. In practise this does not matter because the first
>> packet is never large enough to need fragmentation.
>
> We do the same.

So does it make sense to say in the document that the first packet
must not be fragmented?

Paul