Re: [IPsec] IKE fragmentation

[Paul Wouters <[e-mail]>]

On Wed, 13 Mar 2013, Valery Smyslov wrote:

> As for IKEv2, I don't know how Cisco is doing fragmentation in this case
> (it seems to have support for it), but if it is done similarly to IKEv1,
> than I prefer our own solution - draft-smyslov-ipsecme-ikev2-fragmentation.
> The main difference is that in Microsoft/Cisco solution (for IKEv1)
> the whole encrypted ISAKMP message is fragmented,
> leaving each fragment unauthanticated untill message get reassembled
> and its authentity could be verivied. This opens door for
> a very simple DoS attack on receiver.

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.

> In our proposal each fragment is encrypted and authenticated
> individually, that allows receiver to distinguish valid fragments
> from bogus, thus preventing from abovementioned DoS attack.

But I can send lots of small forged fragments and you will do lots
of crypto on them for _each_ forged fragment. I think you will end
up using a lot more cpu and the attacker needs a lot less bandwidth.

I actually do like the IKEv1 version. It's very simple. And uses
the exact same code path apart from a little buffer where we store
some fragments (with sane limits). The only oddness is that
fragmentation ID that serves no purpose, as you cannot really have
two different packets fragmented in flight for a single exchange.
(well you can, but they are going to be identical anyway)

While implementing the IKEv1 version, I did wonder about what should
trigger fragmentation. For instance, if both parties have send and
received the vendorid, and one side sends fragments, should the
other side fully indepedantly wait for failure/retransmit before
using fragments, or take the hint that if the path is broken one
way, it is likely broken in the other way as well? It seems that
being a little aggressive here can really help the IPsec SA to
establish much faster - especially since our own retransmit time
is 20 seconds, which is something we are now consideraing lowering
a lot.

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.

Paul