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

["Derek Atkins" <[e-mail]>]

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

On Thu, April 3, 2014 11:18 am, Valery Smyslov wrote:
> Hi,
>
>>> 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.
>>
>> 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
>
> No, it is fully cryptographically authenticated. IKE fragmentation
> 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.

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

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.

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

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,

> Regards,
> Valery.

-derek

-- 
       Derek Atkins                 617-623-3745
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant