[IPsec] FYI: A Novel Denial-of-Service Attack Against IKEv2 - HAL-Inria

[Paul Wouters <[e-mail]>]

https://hal.inria.fr/hal-01980276/document

"A Novel Denial-of-Service Attack Against IKEv2 - HAL-Inria"

(I've CC:ed the first author of the paper on this email)

I've read through the paper, and I believe is very much misrepresents
what it deems is a DoS attack against the IKEv2 protocol.

The DoS attack described seems to think it can change the IP address
and cause Initiator to be authenticated by a different peer than intended
(ignoring all of IDi / IDr payloads it is relaying). Then the different
peer is happy, but the last IKE_AUTH reply to the initiator would signify
a failure. Then when the initiator sends an Informational message with
a Delete payload and AUTHENTICATION_FAILED notify, the attacker drops
the message. Now the different peer has "lost resources" since its IKE
SA (and possibly IPsec SA) is up. A proper implementation would send a
Liveness probe if its IPsec SA counters remain zero. It would also put
an idle limit on an childless SA that resulted from a TS_UNAVAILABLE
(as opposed to a by design childless IKE SA)

It makes more wrong assumptions like "(TS negotiation will fail in most
cases)" which I guess they think would fail because the different peer's
have different IPsec SA configurations, but really if they are that
different, they will also have different IDi/IDr payloads because a
peer's configuration with many other peers for specific subnets would
be configured with local/remote IDs as to not tie these to hardcoded
IP addresses. Without explicit ID, the ID used is normally the ID_IPvx,
and if that is used, using an IP address X with ID_IPv4 Y will also
cause an IKE failure of the victim peer because for IP address X it
would then expect ID_IPv4 X.

It then "proves" this by using the strongswan/libreswan option
uniqueids=no, which is an non-standard override used to allow multiple
IDs to establish more than one connection. Obviously, such connections
MUST use liveness/dpd to kick out idle connections, because you cannot
detect a reconnect from behind NAT from a different user behind the
same NAT, and you would accumulate a lot of connections from restarting
clients that you wouldn't be able to cleanup otherwise.

Assuming all peers are on dynamic IPs, so no ACL's kick in between
the peers (which would really only happen on a mesh cloud encryption,
where an attacker would be extremely unlikely able to selectively NAT or
DROP packets), the DoS attack would still fail. If peer A tries to talk
to peer B and ends up talking to peer C, then the attack would fail if
peer A sends the IDr payload. If it does not send an IDr payload, then
it likely expects the ID_IPv4 later which wouldn't match when it got
redirected to a different peer, using a different ID_IPv4. But even we
assume all of this is true, and the attacker can block the packets from
peer A's delete request to peer C, then yes peer C uses one connection
resource. If peer A attempts a new connection because its connection
failed, the attacker can try this again, but peer C will replace the
existing IKE/IPsec SA in the normal case. So doing the attack twice from
the same peer (who is still trying to connect) will still only lead to one
extra unused connection of peer C. So you would need many peers to get
any real amount of memory wasted on peer C. But if peer C is expecting
to be part of a mesh with _many_ peers, it will have the resources to
setup connections with a large number of peers. Deflecting a few peers
through other peers isn't going to present a different scale level.

In the case where repeated attempts would not replace the existing
connection (which they emulate using the strongswan/libreswan uniqueids=no
option on peer C), peer C would indeed end up using another one connection
of memory. Peer A would do some kind of back-off on the failures, so
maybe you get a one connection per minute rate. You would still need
a lot of peers to DoS peer C, which again means that peer C is already
expected to talk to a lot of peers. At best you could double the load
by sending each peer configured through another peer.

And all this assumes peer C does not remove idle IKE/IPsec SA's, and
does not use liveness/DPD. Which in a mesh peer to peer enterprise
network encryption you would use. In a remote access VPN scenario,
there is no "redirect to a different peer" as all peers only connect
to the one security gateway (or a set of gateways with identical
credentials) so 'redirecting' a peer is not possible.

It goes on to say the attack is not possible with PSKs, which I don't
understand. They also then mumbled about asymmetric authentication,
which I don't understand, but regardless is basically only employed
with EAPTLS and Remote Access VPNs, so it does not apply to this attack.

When using PSK with a Group-ID, this "attack" is in fact the actual normal
deployment that implementations already handle. A groupID plus PSK, at
least on libreswan, implies uniqueids=no for free because otherwise each
client would kick of the next client. Now imagine a client on flaky wifi
that keeps dropping and reconnecting. It would actually set up duplicate
connections faster than this entire peer redirection attack. Those
configurations better better use liveness/dpd already to ensure an often
reconnecting client is not generating hundreds of new IKE/IPsec SA's
without cleaning up the old ones. (initial contact cannot be used when
using groupID with PSK as all different clients identify the same).

They link to proof of concept code at gitlab.com/deviation/demo but I
cannot access this - it is a private repository. But from the
description in the paper, they only show 3 VMs and one of these
connection tricks - and don't show any of this at scale using containers
to see how the target would respond when this happens at a scale of
which this becomes an actual attack.

In conclusion, I wish the authors of the paper would have contacted
the IPsec community at IETF or the opensource vendors of strongswan or
libreswan before publication. It also shows the limitations of formal
proofs in the absence of understanding operational deployments and
implementation details. And that one should never describe one's own
inventions as "novel". Leave that praise to others.

Paul