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

From: Tristan Ninet <[email-masked]>
Date: Sat, 21 Sep 2019 19:22:19 +0200 (CEST)

Dear Mr. Wouters, 

Thank you for your interest in our work. 

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

Let us denote Initiator by A, Responder by B, Victim by C, IKE_SA_INIT request 
by m1, IKE_SA_INIT response by m2, IKE_AUTH request by m3, and IKE_AUTH response 
by m4. 

I understand you are saying that authentication of A to C would fail because of 
IDi and IDr payloads. 

However, we put as a requirement to the attack that C trusts A, i.e. C has some 
configuration entry with the ID of A. In this case, authentication will succeed. 

Regarding the IDr payload, this payload is optional in m3. In fact libreswan 
does not send this payload in m3 by default. 

Furhermore, even if IDr is sent in m3, as explained in Section V-C-a) 
("Vulnerability of strongSwan") in our paper, the RFC does not mandate to cancel 
the IKE SA setup if the IDr of m3 does not match C's identity. The RFC says: "If 
the IDr proposed by the initiator is not acceptable to the responder, the 
responder might use some other IDr to finish the exchange". This actually 
suggests that completing the IKE SA setup even if IDr is wrong is OK. So 
depending on the implementation, even if IDr is sent in m3, an IKE SA could be 
set up, and the attack could succeed. 

Therefore, with our requirements, authentication of A to C succeeds, and at 
least an IKE SA per deviation is up in C. 

You then say that a proper implementation would send a Liveness probe if its 
IPsec SA sequence numbers remain zero. 

The RFC does say that Liveness checks are needed. In this regard, strongswan and 
libreswan do not follow the RFC since in both implementations, Dead Peer 
Detection (DPD) is disabled by default. 

However, DPD does not deter the attack. A classic flooding DoS attack can only 
set up half-open SAs. An IKEv2 implementation should remove half-open SAs after 
some short time. In strongswan by default half-open SAs are removed after 30s. 
Therefore a high-rate of m1 messages is needed to achieve memory exhaustion 
using classic flooding against IKEv2. 

However, the Deviation attack sets up full IKE SAs (if not Child SAs as well) in 
C. We measured that a full connection (one IKE SA + one Child SA) is 23kB in 
strongswan, whereas a half-open SA is 1kB. This divides by 23 the minimum 
throughput of m1 messages to deviate in order to exhaust the memory of C. 

In strongswan, when DPD is enabled, by default, connections with a dead peer 
(such as in the Deviation Attack) are removed after dpdtimeout + total 
retransmission timeout = 30s + 165s = 195s. It does not make sense to go much 
lower, and some implementations might want to set this timeout higher so that 
bandwidth is not overwhelmed. This longer stay of undesirable connections in C's 
memory divides by 6 the minimum throughput of m1 messages to deviate in order to 
exhaust the memory of C. 

In total the Deviation Attack thus divides the required throughput by 140. In 
consequence the DA is much harder to detect using intrusion detection systems 
than classic DoS attacks, in particular when DPD timeout is high. 

In strongswan, when DPD is disabled, connections with a dead peer are removed at 
the time of rekeying, i.e. by default 3h. A DoS with a throughput 8000 times 
lower than classic DoS techniques is then possible. 

On the other hand, the requirements for the attack are quite strong. Firstly, 
the attacker needs to have some control over the connection between A and B. 
Secondly, all Initiator parties authenticate themselves using signature mode and 
are trusted by Victim. Thirdly, the attacker needs to find enough m1 messages to 
deviate. In addition, each m1 message must come from a different IKEv2 peer. 
Otherwise connections will simply replace current connections with the same 
peer. In fact I did not see this behavior in the RFC, but strongswan behaves 
this way by default. 

The contribution of the paper is to point out that when the above requirements 
are satisfied, then an attacker may perform a DoS attack with a significantly 
lower throughput than expected from classic flooding techniques. 

Note in addition that the vulnerability described in our paper is very much not 
specific to IKEv2. The vulnerability may appear in any stateful protocol that 
performs authentication and does not satisfy the weak agreement property. 

I admit however that we do not sufficiently detail the difference between the DA 
and classic DoS attacks in the paper. Also the version of the paper you read is 
quite old. It is a version that we submitted to a conference some time ago. We 
are currently publishing a more recent version at another conference. 

You also say that a proper implementation would put an idle limit on an 
childless SA that resulted from a TS_UNAVAILABLE (as opposed to a by design 
childless IKE SA). I think you mean TS_UNACCEPTABLE. I cannot find this behavior 
anywhere in the RFC. But even if it is true, the point I made above stays valid. 

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

You say that our assumption that TS negotiation will fail in most cases is 
wrong. Even if this assumption is wrong it only makes the attack stronger, as an 
even heavier connection is installed in C. 

You say that authentication using ID_IPvx will fail because A would be using 
different IP addresses in its IDi and in the source address of the m3 packet. 
However, in the attack the deviation only changes the destination address, not 
the source address. Thus no such failure would occur. 

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

In our demonstration we decided, for practical reasons, not to create the N 
Initiator machines of the generic scenario, but instead to only create 
`N_{demo}` Initiator VMs, with each of them sending `N/N_{demo}` m1 messages to 
Responder machines. We are using fully virtualized machines (Virtualbox) in our 
demo, so it would not have been possible to create that many VMs. 

However, by default in strongSwan, a party requires an IKE ID to be unique among 
the IKE SAs it manages. That is, when that party receives an m3 message with an 
IDi payload that is equal to the peer ID of an existing IKE SA in its SAD, it 
will delete the old IKE SA and replace it with the new one. Because of this in 
our experiment, the Deviation Attack would add only `N_{demo}` unintended 
connections in Victim. To stay faithful to the generic scenario, we tell Victim 
not to delete the old IKE SA in this situation, and instead, to set up the new 
one alongside. This is done using the "uniqueids=never" option. 

However, as I said above, the attack does assume that each m1 message comes 
from a different IKEv2 peer. It is obvious that if the attack works with Ndemo 
Initiators and the "uniqueids=never" option set in Victim, then it works in the 
same setup but with N Initiators and without the "uniqueids=never" option in 
Victim. 

The above explanation is in appendix E of the version of the paper you read. It 
is also in the README of the demo. 

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

You say that authentication will fail if A sends IDr. We already discussed this 
point above. Note that sending an IDr payload in the IKE_AUTH request might be 
indeed a potential countermeasure to the deviation attack, assuming that the 
implementation actually rejects incoming IKE_AUTH messages with improper IDr 
when acting as a responder (behavior that one might expect but once again is not 
mandated by the RFC). 

You say that A likely expects the ID_IPv4 later which wouldn't match when it got 
redirected to a different peer, using a different ID_IPv4. Well of course, and 
that will make the authentication of C to A fail, but the harm is already done 
since an SA was set up in C. 

You say that the attack has strong requirements. We already discussed this point 
above. It is true that the deviation attack is only successful in very specific 
conditions but I think that our paper is rather explicit on this point. 

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

As said above, we do not consider the case where repeated attempts would not 
replace the existing connection. 

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

As said above, the Deviation Attack works even if C uses DPD, even if less 
efficient. 

> 
> 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 we said that the attack is not possible with PSKs, we assumed that the PSK 
between A and B is different than the PSK between A and C. In this case, 
authentication of A to C will fail and the attack does not work because no SA in 
installed in C. 

We were not talking about asymmetric encryption. Maybe it was bad phrasing. We 
were just considering the somehow "asymmetric" (i.e. not the same on both sides) 
situation where A authenticates himself using signature and C authenticates 
himself using PSK (in fact we switched A and C in the paper, this is a typo). 
What we said is that in this situation the attack still works, which is true. 

As a side note, the above situation is mentioned in the RFC: "There is no 
requirement that the initiator and responder sign with the same cryptographic 
algorithms. [...] In particular, the initiator may be using a shared key while 
the responder may have a public signature key and certificate". I am not sure 
whether this is a common situation. 

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

As I said, we only considered the case where the PSK between A and B is 
different than the PSK between A and C. 

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

As I said above, the version of the paper you read is quite old. The gitlab repo 
that this version refers to was an anonymized repo. As later we did not need 
anonymisation anymore, we switched this repo to private and moved its content to 
a new public repo at gitlab.inria.fr/tninet/demo. Feel free to check 
it out. 

We refer to the above repo in the version of the paper that will soon be 
published. I agree however that because the version you read is public, we 
should have kept gitlab.com/deviation/demo public. To this end, we recently set 
the latter back to public and mirrored it to gitlab.inria.fr/tninet/demo. 

We actually use Ndemo + 3 VMs (Ndemo Initiators + Victim + Intruder + Probe), 
which by default in our demo amounts to 6 VMs since we use Ndemo = 3 by default. 
I already explained above why we do not used all N Initiators and why it does 
not affect our proof. 

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

We should indeed have contacted the IPsec community at IETF and the vendors of 
strongswan and libreswan. It would have been interesting to discuss the attack 
with you prior to publication. We hope that the answers and explanations we 
provided above remove (at least some of) your concerns with this paper. 

Best Regards, 
Tristan Ninet

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 23 Sep 2019 10:15:52 +0300

Hi,

I think that the key assumption for this attack to happen is an ability

for the attacker to drop packets in the network. Note, that this is 

quite strong assumption, because it's easier for an attacker to inject packets

then to remove them, unless he/she controls some parts of network infrastructure.

If attacker is able to drop packets, then a lot of DoS attacks are possible.

And I agree with Paul that wise responder should initiate liveness check 

if case he/she sees no traffic on the just created SA, because 

AUTHENTICATION_FAILED notification might not reach he/she

even without attacker's efforts. It's not in the RFC? but it's

just a wise safeguard. At least our implementation does this.

Regards,

Valery.

From: IPsec [mailto:[email-masked]] On Behalf Of Tristan Ninet
Sent: Saturday, September 21, 2019 8:22 PM
To: Paul Wouters
Cc: [email-masked] WG; Olivier Zendra; romaric maillard
Subject: Re: [IPsec] FYI: A Novel Denial-of-Service Attack Against IKEv2 - HAL-Inria

Dear Mr. Wouters,

> understand.. They also then mumbled about asymmetric authentication, which I

Best Regards,
Tristan Ninet

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 26 Sep 2019 12:27:08 +0300

> I understand you are saying that authentication of A to C would fail because of

Normally authentication from A to C will fail because of different
authentication information. I.e., if they are using pre-shared keys
the pre-shared key for A to B is different than A to C (unless B and C
are part of same infrastructure, i.e., load-sharing or high
availaibility pairs). If A is using certificates then usually it has
two different CA infrastructures one for B and one for C, so C will
not accept certificate meant for B and will fail authentication.

You can get this work if B and C are sharing configuration i.e., they
are two different gateways in the same adminstrative domain. 

> configuration entry with the ID of A. In this case, authentication will succeed.

You also put restriction that A shares exactly same authentication
information for B and C both. This is not normal for cases where B and
C are independent. 

> Detection (DPD) is disabled by default.

RFC says:

								If no
   cryptographically protected messages have been received on an IKE SA
   or any of its Child SAs recently, the system needs to perform a
   liveness check in order to prevent sending messages to a dead peer.

Usually DPD will be have timeout of 10-30 seconds, i.e., after initial
silence, i.e., if there is nothing happening in the IKEv2 SA after
final IKE_AUTH in few tens of seconds C will send DPD message to A and
will not get reply to that, and C will delete the IKE SA after few
minutes. 

> throughput of m1 messages to deviate in order to exhaust the memory of C.

Note, that sending classic flooding attack packets requires no effort
from the attacker. Settting up full IKEv2 SA do require
Diffie-Hellmans, Certificate verifications etc, thus rate you can set
them up is much more limited than classic case. The maximum number of
IKEv2 SAs that can be set up each second is usually in order of
hundreds or thousands, thus even if it uses 23kB for two minutes
(until DPD kicks them out) that is only few gigabytes of memory.
Older phones would run out of memory at that point, but newer ones
have more memory than that...

Also as you are relying for A to set initiate the connection you can
only set up one connection per few minutes, as A will not immediately
retry connection to B/C when it receives IKE_AUTH message failing
authentication. The RFC does not provide instructions for this case,
but authentication failure in IKE_AUTH means there is something wrong
that most likely will not be automatically fixed, the clients usually
wait for some time before retrying. I.e., if you are waiting for
adminstrator of either end to go and fix the authentication
information in configuration there is no point retrying every second.
You can try every 30 seconds without any issues, and still almost
immediately detect when other end fixes their configuration.

> memory divides by 6 the minimum throughput of m1 messages to deviate in order to

So if A tries every 30 seconds and C keeps it in memory for 200
seconds that still means we only have 6-7 of them active at one time.
Not really proper attack. 

> than classic DoS attacks, in particular when DPD timeout is high.

You seem to be assuming that A will retry immediately when it gets
authentication failure? Even if it did that usually the setup time
needed for one IKEv2 SA is in order of second or so, so getting more
than one connection per second from the same host A is difficult (2 *
RTT + Diffie-Hellman calculations + certificate calculations). Even
with new connectiona attempt every second you only have few hundred
extra IKEv2 SAs. 

> lower than classic DoS techniques is then possible.

Disabling DPD is bad idea, and if you do that, then you are asking
for it... 

> peer. In fact I did not see this behavior in the RFC, but strongswan behaves

Normally each new connection has INITIAL_CONTACT notification which
tells the responder that this replaces all previous connections with
same authenticated peers. I assumed you had assumed that
INITIAL_CONTACT notifications would have been disabled on A to get
this attack working at all, as I assume you forced A to do multiple
connections right after each other. 

On the other hand here you do assume that we simply take normal m1
messages going to B and redirect them to C also, which means that the
load of C can at most be same than B, thus you do not really do Denial
of Service attack, you just cause some extra load to C. I mean if B
and C are required to be part of same authentication infrastructure,
you can assume that they have about same amount of resources, thus
C has no problem of handling the same load B is having. 

> lower throughput than expected from classic flooding techniques.

I would say the throughput is much lower than normal operational case
on the Monday morning problem. I.e., when gateways are assumed to be
able to handle 100-1000 times of normal load every now and then and
still process operations without major delays. This throughput seems
to be lower than that.

> anywhere in the RFC. But even if it is true, the point I made above stays valid.

Most implementations uses something like 30 second timer for that. If
the initiator has some other Child SAs to be set up they will do it
immediately after the IKE_AUTH finishes, thus you just need to wait
for few tens of seconds for them. If they do not have any other Child
SAs to create there is no point of keep extra IKE SA up.

RFC do not provide all possible implementation detail, quite a lot of
corner cases are left for implementors to solve. RFC8019 does have
some discussion about these issues, even though it mostly concentrates
on the half open SA problem, as that is hardest to protect against. 

> the source address. Thus no such failure would occur.

ID_IPvx and outer IP does not have anything common. It is completely
possible and valid for node to send ID_IPv4 identity of 10.0.0.1 from
completely different IP-address. From the RFC7296 section 3.5:

	   	     		      	  	  When using the
   ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2
   does not require this address to match the address in the IP header
   of IKEv2 packets, or anything in the TSi/TSr payloads.

Also the most common road warrior setup would be any<->any traffic
selectors, and leave the narrowing for the responder, so C will
happily narrow that range down to something that is useful for him. 

> same setup but with N Initiators and without the "uniqueids=never" option in

If you assume that each m1 comes for differnet legitimite IKEv2 peer,
you only provide work factor of 2, which is very very low...
Especially when you compare that to Monday morning problem where work
factor might suddenly be raised by 100 or 1000 times the normal load.

If you can cause C to provide any kind of visibile change of behavior
with work factor of 2 then C is completely misconfigured and
underresourced and will fail in normal use every now and then anyways.

> authentication of A to C will fail and the attack does not work because no SA in

Note, that it is also does not work for certificates, as CA trust
anchors configured for B and C are different, thus C will not accept
A's certificate as it is not signed by proper CA for C, it is signed
with trust anchor used for B. Only time where B and C uses same
certificate authorities is when they are part of same authentication
domain.

In IPsec we do not have similar common trusted CA list than we have in
web. Each adminstrative domain will configure the CAs they trust
separately, and quite often those CAs are separate CAs only for IPsec
use for that specific gateway. 
-- 
[email-masked]