Hi Tero, > > 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?
Yes, that's what I meant. > 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. Yes, that's what RFC8019 advises. However, this would make the problem with false failed authentication worse, since even without changing secret cookies will change frequently for the same peer and the chances for this situation to happen will increase. > > > 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). I'd rather to avoid additional and prolonged states on responder... > > > 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. OK, and that's the problem:. you drop the connection that otherwise would succeed just because cookie is stall. Sure, the initiator will retry, but overall it looks like a non-optimal protocol design. Regards, Valery. > kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
