Valery Smyslov writes: > Hi Tero, > > > > > I think the long term solution is to do puzzles, as I do not think you > > > > need to change puzzles secrets that often compared to the cookie > > > > secrets. > > > > > > Puzzle are not solution for this problem. RFC 8019 suggests that > > > <AdditionalInfo> is included in the cookie that allows the responder > > > to determine the requested puzzle difficulties and the like. > > > Even if cookie secret is not changed, this information may change > > > quite frequently and we will run into the same problem. > > > > If I remember right puzzles requires the attacker to solve the puzzles > > before it can do the attack, thus making changing the cookie or puzzle > > secrets something that can be done much more infrequently. I mean if > > it takes a second for the attacker to solve the puzzle, that means > > that you can easly slow the done the attack rate from single source so > > much that you do not need to change cookie secret too often. > > If the same cookie is returned every time to a given initiator, > then this initiator can solve puzzle once (since cookie is an input data > for a puzzle) and then present the solution many times (selecting the same > SPIi and Ni), thus bypassing DDoS protection.
But in that case the connection is same, and as puzzle is already solved, you have created state, and if the IKE_SA_INIT is repeated with solved puzzle and cookie, you simply retransmit the response. Or do you mean that after the few minutes when the actual IKE_AUTH failes the attacker can then reuse the old cookie and puzzle and try again, as responder has already forgetten everything about the previous attempt? I think adding timestamp to the cookie would allow you to detect when someone uses old cookie even if you have not changed the cookie secret, i.e. put unix timestamp inside the AdditionalInfo of the cookie, and then when you receive cookie with puzzle, you can verify that it is not too old. > For this reason RFC8019 advises to make every cookie different > or at least to change the secret frequently. I think adding timestamp is better solution. > > And if attacker has so much cpu power and with properly connected > > routable addresses, that you can't cope even with puzzles on, then you > > are out of action anyways, regardless whether you change cookie secret > > or not. > > Not exactly. If you return different cookies to the same initiator each > time it starts creating IKE SA, then this initiator will have to solve > new puzzle every time. Otherwise it can do it once and then > present the solution many times. If you have timestamps there it can only present it as long as you allow time for it to solve the puzzle. Also as the time cookies and puzzles are accepted is limited, you can also keep state of already used puzzles, as for anything to be added to that state do require attacker to solve the puzzle first, and you will anyways at least once move to the IKE_AUTH doing diffie-hellman so you can keep that state bit longer (for example if you only allow cookies that are sent in last 5 minutes to be used, that should allow plenty of time for initiators to solve the puzzle but still allows responder of limited amount of state it needs to keep (i.e., few bytes for every puzzle attacker can solve during that time period). > > > - it eliminates cases when the responder cannot verify cookie sent > > > in IKE_AUTH (unclear what to do in this case) > > > > If responder cannot verify the cookie, it will drop the conenction > > with error, because this cookie was so old that it is no longer > > valid... > > Why? Note, that the purpose of cookie is to verify that the client > is a live host. If the client managed to get to IKE_AUTH, then it's > definitely live. On the other hand, I agree that it's strange to > receive unverifiable cookie. That's why I said that it's unclear > what to do in this case and I'd rather to eliminate such situations > from the protocol. Because of the cookie is not anything responder ever used, the authentication will anyways fail, as responder will not be using same cookie when calculating auth payload than initiator. This is just to make sure we do not fail with AUTHENTICATION_FAILED but with some other error message the indicates more clearly that something wierd happened, and you should try again. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
