Hi Yoav Thanks for the explanation, just for my understanding, why does this rate-limiting have to (strictly) rely on the cookie (or puzzle) notification? Is it more of the case that it guarantees that the attacker is the attacker (prevents blind-spoofing) and as you say limits the attacker to using their own IP address?
So say our bot would send 5 requests a second and always get to IKE_AUTH and transmit a random value attempting to authenticate, it would never leave any half open SAs. I presume enabling the cookie notification will prevent the bot attempting to masquerade as another legitimate address at the same time (where your rate-limiting would help prevent a DOS condition). As the attacker would never leave any half-open SA's (as they get to IKE_AUTH and then Authentication would fail), so strictly speaking the cookie notification might never be employed (if it's enabled to be activated when half open SA's are detected) and you could (and should) rate-limit without enabling cookies. I'm not knocking the cookie-notification (I'm all for it), but I think that rate-limiting should occur even if the headend isn't detecting a large number of half-open SA's. cheers On 10/10/2014 20:58, "Yoav Nir" <[email protected]> wrote: >Hi, Graham. > >Thanks for the endorsement, but see below. > >On Oct 10, 2014, at 2:31 PM, Graham Bartlett (grbartle) ><[email protected]> wrote: > >> 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. > >The cookie mechanism helps in one way. If my IPsec gateway is up against >an X-node botnet, the cookie mechanism limits the botnet to X unique IP >addresses (or IPv6 prefixes). > >This in itself doesn¹t help much, but we can limit the amount of >concurrent half-open SAs that the gateway is willing to store from a >particular IP address or prefix. So if, for example, we hold a half-open >SA for 10 seconds and allow an IPv4 address / IPv6 prefix to have at most >5 half-open SAs, this limits each node in the botnet to 1 half-open SA >every two seconds, even if their bandwidth is sufficient to create many >more. It also limits the total half-open SAs that they can hold on the >gateway to 5X. The limit mechanism doesn¹t work without either cookies or >puzzles. > >Reducing the time an half-open SA is held doesn¹t really help in this >scenario, because I¹m assuming that the attackers have enough bandwidth. >So if we reduce the hold time to 1 second, they should be able to create >5 half-open SAs per second. This is where puzzles come in. They can >reduce the rate that these attacking nodes can create new half-open SAs. > >Yoav >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
