Subject: [secdir] sec-dir review of draft-ietf-ipsecme-ikev2-fragmentation-06

From: Derek Atkins <[email-masked]>
Date: Thu, 03 Apr 2014 10:20:22 -0400

Hi,

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

   This document describes the way to avoid IP fragmentation of large
   IKEv2 messages.  This allows IKEv2 messages to traverse network
   devices that don't allow IP fragments to pass through.

I see no major issues with this document.

There is still a minor issue where you move the exhaustion attack from
the IP layer to the IKE layer -- an attacker could, theoretically,
fill an IKE session with incomplete fragments causing it to use
resources waiting for missing fragments.

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Valery Smyslov <[email-masked]>
Date: Thu, 3 Apr 2014 18:42:20 +0400

Hi Derek,

thank you for your review. Please see my comment inline.

----- Original Message ----- 
From: "Derek Atkins" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, April 03, 2014 6:20 PM
Subject: sec-dir review of draft-ietf-ipsecme-ikev2-fragmentation-06

> resources waiting for missing fragments.

Note, that in this proposal each IKE fragment is individually protected - 
encrypted and authenticated. Forged fragments will be detected
before they are placed into reassembling queue and thus they
couldn't exhaust receiver's resources - only fragments from real peer
will be taken into consideration. And if attacker is capable enough 
to drop an arbitrary IP packet, than there is no protection
anyway - the connection will fail on attacker's will in any case, 
with or without IKE fragmentation.

Regards,
Valery Smyslov.

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 3 Apr 2014 11:00:20 -0400

Hi,

> with or without IKE fragmentation.

It's only authenticated in the sense that you have to have already had a
full round trip so yes, an attacker can not forge their source IP.  But
that doesn't prevent a true DDoS where real hosts (think botnet) all
perform a real IKE_SA_INIT and then use their sessions to build a lot of
held state with "fake" fragments that will never complete.

Like I said, it's an improvement because it's not at the kernel IP layer,
and theoretically there are more resources available at the IKE layer. 
But it probably should still be mentioned.  (Not that IKE without
fragmentation isn't also subject to this kind of DDoS attack).

Thanks,

-derek

---

From: Valery Smyslov <[email-masked]>
Date: Thu, 3 Apr 2014 19:18:46 +0400

Hi,

> full round trip so yes, an attacker can not forge their source IP.  But

No, it is fully cryptographically authenticated. IKE fragmentation
may only take place after shared keys (SK_*) keys are computed.

> held state with "fake" fragments that will never complete.

Messages of IKE_SA_INIT cannot be fragmented with this proposal,
because SK_* are not yet computed. This is limitation, mentioned in the 
draft.
It is assumed that IKE_SA_INIT messages can
be made relatively small to avoid IP fragmentation.

> fragmentation isn't also subject to this kind of DDoS attack).

As I've said, IKE_SA_INIT are beyond this proposal
(and IKE_SA_RESUME also, if we count in IKE session resumption
protocol). But messages of the other exchanges can be
fragmented with full cryptographic protection, including
authentication of each fragment, and I don't think this attack is possible
here (and it was one of the goals to prevent this kind of attack).

Regards,
Valery.

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 3 Apr 2014 12:02:52 -0400

Valery,

At this point I expect we have a language issue.  Either I am not
explaining myself clearly or you are not understanding what I'm saying. 
Let me try to be more clear with what I mean inline below..

> may only take place after shared keys (SK_*) keys are computed.

The SK_ values are just the result of an unauthenticated DH exchange. 
There is no endpoint authentication yet.  There is no endpoint identity. 
You've just exchanged a random number and computed a shared secret.  You
don't know if that shared secret is shared with a real player or a botnet
player.  Indeed, this is why we have the IKE_AUTH packets, to actually
authenticate the endpoints to each other.

So yes, you are correct that fragments are encrypted and "authenticated"
the the Shared Key generated during IKE_SA_INIT.  However at the end of
IKE_SA_INIT all you know is that the peer is reachable.  At this point the
attacker can send you a bunch of bogus "authenticated" IKE_AUTH fragments
and use your resources.

> be made relatively small to avoid IP fragmentation.

I did not say that they could.  As the document clearly says (and I agree
with), you don't fragment the IKE_SA_INIT packets.  But that's not the
attack I'm talking about.  I said that an attacker completes IKE_SA_INIT
and then (after you have a DH Computed Shared Key) it can send a bunch of
bogus fragments.

> here (and it was one of the goals to prevent this kind of attack).

Again, I'm not talking about IKE_SA_INIT (or IKE_SA_RESUME).  I'm talking
about AFTER that point, but before IKE_AUTH.

The attacker still needs to perform work and be reachable.  It needs to
perform an IKE_SA_INIT round trip to compute a shared key with the target,
but once it reaches that point it can send a bunch of bogus
"authenticated" fragments and cause the target to use resources.

For example the attacker could say that there are 2^16 IKE_AUTH fragments
and then send a bunch of packets that each individually are
"authenticated".  Assume each packet is 1024 bytes but it only sends
2^16-1 of them.  This would cause the target to use ~64MB of RAM per peer
buffering the packets.

As I said, this is an improvement over IP fragmentation and buffering in
the kernel, but such an attack is still possible with this protocol.

The GOOD news is that the attacked host can log this -- they know the
actual source IP of the attack.  But a botnet doesn't care.

I hope you understand my point now?

Thanks,

-derek

---

From: Valery Smyslov <[email-masked]>
Date: Fri, 4 Apr 2014 10:25:10 +0400

Hi Derek,

sorry for my slow understanding, now I got your idea.
Please, see my comments inline.

> authenticate the endpoints to each other.

Fully agree.

> attacker can send you a bunch of bogus "authenticated" IKE_AUTH fragments

Sure. But note, that similar attack is possible without IKE fragmentation.
Attacker (botnet) may send unfragmented IKE_AUTH message
without AUTH payload (pretending to use EAP for authentication)
and then stop sending anything. In this case server will spend
roughly the same (*) amount of resources as in attack you described,
so IKE fragmentation doesn't make server more succeptible to this
kind of attack.

(*) You may argue, that in the attack you described botnet may send
a very large number of fragments, indicating that original unfragmented
message is very large, thus forcing server to use more memory
to store them. But implementation may limit the maximum number
of fragments it accepts to some reasonable value and reject
connection with higher number of fragments. And in attack with
EAP the server will probably allocate some resources to communicate with
AAA server, and probably even will send first request to it, causing
creating the state on it. So, it is difficult to directly compare the 
impacts
of these attacks, but IMHO they are _roughly_ the same.

> and then (after you have a DH Computed Shared Key) it can send a bunch of

Now I got your point.

> about AFTER that point, but before IKE_AUTH.

OK.

> 2^16-1 of them.  This would cause the target to use ~64MB of RAM per peer

Yes, this is possible. But see my comments above.

And an implementation may limit the maximum number of fragments
it accepts, taking into consideration the size of fragments.
The guidlines could be the following.

Firstly, IKE fragmentation is optional, so it must be possible
to send any IKE message without fragmentation.
And it places some restrictions on message size - it must fit into UDP,
i.e. be less that 64Kb. So, when you receive IKE fragments, you may
safely assume, that total size of all fragments must not exceed 64Kb
(plus some overhead). Taking into consideration the size of fragments
you have been receiving, you may calculate the maximum number
of fragments that makes sense to accept. For example, in situation
you described, implementation should have limit the number of
fragments to about 70 (due to overhead), and reject connection
if peer indicated higher value.

And secondly, implementation may furter limit the number
of fragments it accepts with some configurable option.
Most real IKE_AUTH messages are less than a few Kb in size,
especially from road warriors, so in most cases it is
safe to assume that real peer will never send larger
messages and to accept only those values for the number
of fragments, that results in unfragmented messages
of this or smaller size.

> the kernel, but such an attack is still possible with this protocol.

Unfortunately, DoS attack is always possible with any protocol :-)

> I hope you understand my point now?

I hope so. And I also hope you will understand my comments on this.

Regards,
Valery.