Subject: [IPsec] DDoS Protection issue #226 - Do we need puzzles at all?

From: Yoav Nir <[email-masked]>
Date: Wed, 26 Nov 2014 14:01:22 +0200

http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/226 <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/226>

Hi.

I think this one we should get out of the way first.

Puzzles limit the rate at which a particular host can create half-open SAs. If the puzzle takes 2 seconds to solve then a particular initiator (whether legitimate initiator, or a node in a bot-net) can create at most 1 half-open SA every 2 seconds.

Another way to achieve the same goal is to limit the half-open SA lifetime to 10 seconds and have a hard limit of 5 concurrent half-open SAs per peer. Sure, the attacker will be able to open 5 half-open SAs within one second, but will then be rejected for the next 9.

So why do I think we still need puzzles?

I don’t like hard limits. Hard limits allow a very easy form of DoS. If everyone in this hotel is behind a single NAT device, then it’s fairly easy for me to create multiple half-open SAs from my room until I hit the hard limit. After that, everyone will be effectively blocked from initiating. So while this is not a “nobody can connect to victim gateway” attack, it is “nobody in this hotel can connect to victim gateway”.  Soft limits are better. With soft limits you start dishing out puzzles when you reach a certain threshold, and you never completely block.

That’s why I think puzzles should stay.

Yoav

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Nov 2014 11:46:05 -0500

Yoav Nir <[email-masked]> wrote:
    > I don’t like hard limits. Hard limits allow a very easy form of DoS. If
    > everyone in this hotel is behind a single NAT device, then it’s fairly
    > easy for me to create multiple half-open SAs from my room until I hit
    > the hard limit. After that, everyone will be effectively blocked from

Except now apply CGN in a IPv4-address poor country, and it's not just the
people in the hotel, it's potentially everyone in that area.  Given 300-odd
well distributed, compromised hosts, one could keep the half-SA table full
for much of the  developing world...

So I buy your argument.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 26 Nov 2014 21:05:35 +0200

I don't buy Yoav's argument but I also think puzzles should stay.

The reason is, puzzles work well in the case where a botnet is attacking 
multiple gateways concurrently. Each gateway can rate-limit the traffic 
directed to it, but unless we associate a significant cost with each 
message, the botnet is as effective against each of the gateways as it 
would be if it was only attacking a single gateway. With puzzles, the 
"good guys" are helping one another without needing to communicate 
between them.

Thanks,
	Yaron

On 11/26/2014 06:46 PM, Michael Richardson wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Nico Williams <[email-masked]>
Date: Wed, 26 Nov 2014 14:02:08 -0600

On Wed, Nov 26, 2014 at 02:01:22PM +0200, Yoav Nir wrote:
> Puzzles limit the rate at which a particular host can create half-open
> SAs. If the puzzle takes 2 seconds to solve then a particular
> initiator (whether legitimate initiator, or a node in a bot-net) can
> create at most 1 half-open SA every 2 seconds.
> 
> Another way to achieve the same goal is to limit the half-open SA
> lifetime to 10 seconds and have a hard limit of 5 concurrent half-open
> SAs per peer. Sure, the attacker will be able to open 5 half-open SAs
> within one second, but will then be rejected for the next 9.
> 

I agree with your and Michael's points, but do recall that
initiator/responder roles are exchangeable, and even when initiators are
"clients" they might have to speak to many other responders.  Puzzles/
puzzle complexity, seems like a good device for throttling half-open IKE
SA creation when under load, but it might not be a good idea to have 2s
puzzles on all the time.

Nico
--

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Wed, 26 Nov 2014 20:10:35 +0000

Great point. Puzzles a good tool that will be needed if/when ddos becomes
a serious issue. (I can't think of a silver bullet which will solve this)

They should also not be mandatory (with the option to be configurable as
per cookie notifications) as I would assume some hosts will never be able
to support these.. 

cheers

---

From: Nico Williams <[email-masked]>
Date: Wed, 26 Nov 2014 16:17:20 -0600

> a serious issue. (I can't think of a silver bullet which will solve this)

For VPN SGs using puzzles all the time would be fine, but for VPN
clients it'd be very rude to use them when acting as the responder!  The
protocol may be symmetric, but some uses aren't.

VPN clients probably don't talk to more than one SG at a time, so why
should they need puzzles at all?  For single-user VPN clients there's
not much of a DDoS problem.  Even for BITW uses...

For end-to-end IPsec using complex puzzles all the time would probably
not be useful at all, but using them as load goes up would be very
appropriate.

Responder load seems like a variable that always works for deciding when
to use puzzles and how complex they should be.  VPN clients generally
will never have too much IKE load, while SGs make tempting DDoS targets,
therefore SGs could definitely use puzzles when under attack.

Another variable worth using for determining puzzle complexity is the
responder's estimated cost of holding the half-open IK_SA and completing
the exchange.  For a protocol where the initiator can demonstrate having
recently been a productive peer there may be no need to make the
initiator spend a lot of time on puzzles -- no need to punish the
innocent parties, when you know who they are (but innocence is difficult
to determine).

> per cookie notifications) as I would assume some hosts will never be able

Yes, but I'd rather we have a general recommendation with as simple a
configuration knob as possible and with a sensible default setting that
most will never need to change.  IKE load seems like the most sensible
variable to use in deciding when to use puzzles and how hard they should
be.

Specify the feature (puzzles) and provide general guidance as to when to
use it and how hard to make it on the initiator.

Nico
--

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Sun, 30 Nov 2014 22:16:57 +0000

Hi Nico

On 26/11/2014 22:17, "Nico Williams" <[email-masked]> wrote:

>not much of a DDoS problem.  Even for BITW uses..
>

Is this for 2 peers with a site-site IPsec (with known addresses)? I agree
that there would be little need for puzzles as security controls -
IPS/Firewall (even Cookie Notifications) etc would be better suited to
mitigating an attack as the peer address is known and would need to be
spoofed.

>innocent parties, when you know who they are (but innocence is difficult

This is interesting, so maybe you could have a token that is bound to
identity, if you have completed a puzzle it's valid for x period of time?
This is presented to over-ride having to complete a puzzle?

cheers