Subject: [IPsec] DoS Attack Possibility?

From: "Addepalli Srini-B22160" <[email-masked]>
Date: Tue, 17 Mar 2009 12:35:34 -0700

REDIRECT notification by the responder upon receiving IKE_SA_INIT might
be exploited by intelligent injection of REDIRECT notifications.  In
site-to-site VPN case, it is not difficult for attackers to know IP
addresses of gateways. UDP source port and destination ports are known.
If attacker guesses the Initiator SPI, it is possible to DoS the VPN
Initiator. This problem compounds if Initiator caches the information
from REDIRECT notification. This attack is similar to DNS Poisoning
attack which became famous in 2008.  

If the initiator SPI is random data, then guessing would be nearly
impossible and we don't need to worry about it.  I was told that
Initiator SPI was not mandated to be random in IKEv2 specifications
(Though this problem may not be there in IKEv1 as Cookies are expected
to be random - but we are not discussing IKEv1 here in this context). If
that was the case indeed, then I think that we need to have some
mechanism to thwart these kinds of attacks.

One possible solution would be to send RANDOM data as part of
"REDIRECTION_SUPPORTED" and expect this RANDOM to be seen in "REDIRECT"
notification.

Regards
Srini

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 18 Mar 2009 11:41:07 -0700

> "REDIRECTION_SUPPORTED" and expect this RANDOM to be seen in "REDIRECT"

Sounds ok to me. Anyone else have comments/opinions on this before I add 
this to the document?

We can have a random 32-bit identifier included in the 
REDIRECTION_SUPPORTED payload and have the gateway echo this in the 
REDIRECT payload. Note that this would be applicable only to redirect 
during the IKE_SA_INIT exchange.

Vijay

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 18 Mar 2009 22:07:44 +0200

Hi,

I'm not sure in what way this is worse than other potential attacks at this
stage, such as sending back an unprotected notification saying that the
offered group is unacceptable.

This case is different though if the attacker redirects into a legitimate
gateway, because things look normal, traffic gets through, but an innocent
gateway may get overwhelmed if all other "equivalent" gateways are
redirected to it.

It may be simpler to echo the nonce Ni back to the initiator as part of the
Redirect payload. This would introduce no new state.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Vijay Devarapalli
> Sent: Wednesday, March 18, 2009 20:41
> To: Addepalli Srini-B22160
> Cc: IPsecme WG
> Subject: Re: [IPsec] DoS Attack Possibility?
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.

---

From: "Addepalli Srini-B22160" <[email-masked]>
Date: Wed, 18 Mar 2009 15:50:36 -0700

Ok. Since Nonce is also randomly generated, it should work fine. 

Thanks
Srini

-----Original Message-----
From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Wednesday, March 18, 2009 1:08 PM
To: Vijay Devarapalli; Addepalli Srini-B22160
Cc: IPsecme WG
Subject: RE: [IPsec] DoS Attack Possibility?

Hi,

I'm not sure in what way this is worse than other potential attacks at
this
stage, such as sending back an unprotected notification saying that the
offered group is unacceptable.

This case is different though if the attacker redirects into a
legitimate
gateway, because things look normal, traffic gets through, but an
innocent
gateway may get overwhelmed if all other "equivalent" gateways are
redirected to it.

It may be simpler to echo the nonce Ni back to the initiator as part of
the
Redirect payload. This would introduce no new state.

Thanks,
	Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 Mar 2009 14:09:48 +0200

> during the IKE_SA_INIT exchange.

32-bits is way too short. If you want cookie better use something that
is suitable for cookie, and even better do not limit the size. As
there is no data currently in the REDIRECT_SUPPORTED, better to just
say that the whole REDIRECT_SUPPORTED payload must be returned as is
by the server when it is sending REDIRECT back. You can use similar
text RFC4306 has about nonces, saying that they must be t least 128
bits in size, and must be randomly chosen (i.e. the length MUST be
between 16 and 256 octects inclusive). 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 Mar 2009 14:13:51 +0200

> offered group is unacceptable.

If attacker sends notification back saying the offered group is
unacceptable, it will also indicate new group (which must be part of
initiators offer) in the notification payload, and then initiator
tries again with that. If that new group is acceptable by the server
too, then they create IKE_SA with that group, and as it was acceptable
with both it is ok. It might not be the strongest group they
supported, but the group is one of the acceptable groups for both
ends.

For other unauthenticated error emssages the initiator should ignore
them, and keep trying until the exchange times out.

> gateway may get overwhelmed if all other "equivalent" gateways are

Yes. 

> Redirect payload. This would introduce no new state.

That would also be good solution, as the nonce is already defined to
be random and large enough. 
-- 
[email-masked]