Re: [IPsec] A strategy against DoS/DDoS for IKE responders

["Graham Bartlett (grbartle)" <[e-mail]>]

Hi Yaron / Yoav

I'm summarising my thoughts below, I've spoken to a few folk offlist and
hopefully the following will help my understanding and also theirs.

So assuming a device is under potential attack by devices using their own
addresses (botnet or similar), the cookie notification is not going to
give any benefit (as they are using a legitimate IP address), but Yoav's
puzzle will slow the attack down.


If an attacker sent a legitimate DH public value (that would pass the 6989
checks) and we held off checking this until IKE_AUTH, as you say no
benefit would be gained from detecting this at SA_INIT. The only point in
this attack that we detect an attacker is when the AUTH value is known to
be incorrect so even if they send correct DH public values.

Now the only issue I can see is alluded to in the draft, where a VPN
headend is serving clients with varying resource. So say a botnet attacks
this headend and the puzzle is enabled, you have some clients with a lot
of resource (that require a hard puzzle) and some mobile devices with
minimal (that require an easier puzzle). How do you identify each? The
only way I can think is you must do this once the device has authenticated
itself - else how do you know who they are?

An idea - for example the minimum difficulty of the puzzle is sent by
responder and this is selected by the client and confirmed by the headend
based on IKE ID/certificate attribute? For IKE ID/cert that knows it
should perform a harder puzzle it will (manual local setting).

I know this is a bit of a corner case, but seems to be an easy attack for
someone to start disrupting a remote-access VPN solution that serves
clients with different processing resource.

So to summarise; Because of the attack(s) described in 6989 I personally
feel that this should always be implemented - it's a must. Cookie
notification gives no benefit (only mitigates blind spoofing), but Yoav's
puzzle will help slow down an attack using a devices own IP address.


So I'm all for Yoav's puzzle. :-)

cheers 


On 06/10/2014 20:31, "Yaron Sheffer" <[e-mail]> wrote:

>It seems to me the difference between the two options is not very
>important (assuming reasonable rate limits), because the cost of
>receiving an IKE_AUTH message and detecting an incorrect MAC is not very
>high, after the initial generation of the IKE SA key material.
>
>But Yoav's model also demonstrates that we could get the same effect by
>attaching the puzzle to IKE_AUTH - though I don't see an advantage.
>
>Re: RFC 6989, yes, the test refers to IKE_SA_INIT. But the response
>message does not depend on the received DH public key, so IMHO it's fine
>to postpone the test until IKE_AUTH is received, and before generating
>the IKE shared key.
>
>Thanks,
>	Yaron
>
>
>On 10/06/2014 11:31 AM, Graham Bartlett (grbartle) wrote:
>> Hi
>>
>> This is a very interesting attack, I would dismiss (1) as it leaves an
>> implementation open for a semi-easy DOS (just one packet that generates
>> work rate on both initiator and responder).
>>
>> Basing the behaviour on (2) the attacker would only have the window from
>> when the responder sends the SA_INIT, to receiving the (valid) IKE_AUTH.
>> As Nico said shortening the time is critical, but also once the
>>responder
>> receives a valid IKE_AUTH it should (IMO) dismiss any more IKE_AUTH
>> messages it receives.
>>
>>
>> I guess you could look at rate limiting IKE_AUTH messages if they fail
>>to
>> decrypt, but then you could drop the legit IKE_AUTH. Unless the attacker
>> is very very lucky (in their packet generation), or has the
>>authentication
>> credentials they will not be able to send a valid IKE_AUTH, so the
>>window
>> that occurs between the responder receiving the valid IKE_AUTH is key.
>>
>> I see the potential for an attacker dropping, or delaying the legit
>> IKE_AUTH and then sending many IKE_AUTH as you said, so if the behaviour
>> was set to 10s if a device detected it was under this attack it should
>> reduce the window of time to process IKE_AUTH (as Nico said), but once
>> again this could then drop the legit IKE_AUTH.
>>
>> As I understand the RFC6989 checks are performed on the public value
>> received in SA_INIT, no IKE_AUTH. (FROM RFC6989) "A receiving peer MUST
>> check that its peer's public value is valid;", so these checks (as I
>> understand) would be performed before the responder sends the SA_INIT.
>>
>> So to summarise, I think that (1) is worse, (2) should be implemented
>> (maybe with a different timer), but with guidance on what to do should a
>> device become under attack.
>>
>> cheers
>>
>>
>>
>> On 05/10/2014 21:22, "Yoav Nir" <[e-mail]> wrote:
>>
>>> Hi, Yaron
>>>
>>> On Oct 5, 2014, at 10:56 PM, Yaron Sheffer <[e-mail]>
>>>wrote:
>>>
>>>>
>>>> - I'm not sure what is special about "[the case] when an
>>>>Authentication
>>>> request fails to decrypt." Seems to me this is a verified DoS attack
>>> >from a specific IP.
>>>
>>> I see I wasn¹t clear about this, because both you and Graham missed
>>>what
>>> I meant.
>>>
>>> Suppose we have a responder where half-open SAs time out after 10
>>> seconds.
>>> This responder receives an Initial Request, and responds with an
>>>Initial
>>> Response.
>>> It stores its own private value and the peer¹s public value in the
>>> half-open SA database, keyed by IKE SPIs.
>>> 0.5 seconds later, it receives an IKE_AUTH request with the right IKE
>>> SPIs.
>>> It derives the keys (making any ECDH check that¹s needed)
>>> It tries to decrypt the message
>>> The message fails to decrypt (or more likely, the MAC comparison fails)
>>> Now the responder has two options:
>>> (1) delete the entry in the half-open SA database, or
>>> (2) store the derived key, and keep the half-open SA another 9.5
>>>seconds.
>>>
>>> (2) has the disadvantage that the attacker can keep sending more junk
>>> packets and get the responder to attempt to decrypt all of them.
>>> (1) has the disadvantage that an attacker can inject a junk IKE_AUTH
>>> request by just copying the IKE SPIs from the IKE_INIT response, which
>>> will prevent the responder from processing the real initiator¹s
>>>IKE_AUTH
>>> request.
>>>
>>> So I¹m not sure which is worse.
>>>
>>> Yoav
>>>
>>> _______________________________________________
>>> IPsec mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ipsec