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

[Valery Smyslov <[e-mail]>]

Hi Derek,

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

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

Fully agree.

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

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.

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

Now I got your point.

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

OK.

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

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.

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

Unfortunately, DoS attack is always possible with any 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?

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

Regards,
Valery.

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