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. For this reason RFC8019 advises to make every cookie different or at least to change the secret frequently. > 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. > > > This kind of change would most likely be backward compatible, i.e., > > > old responders would simply ignore the extra notify payload in > > > IKE_AUTH and old initiators would not simply even send it. > > > > This change will require both client and server to be updated to > > take an effect. > > But it is backward compatible with both old and new client and server. > Meaning you can easily just turn it on in your initiator (where this > will be trivial change). Then when responder is supporting this you > will get protection. I agree that implementing this on responder do > require more work. I didn't say it is not backward compatible :-) > > IMHO in this case a better option would be as follows: negotiate an > > extension that will change AUTH payload input by zeroing out content > > of cookie. > > Implementing that do require about same amount of work than my > proposal on the responder, but now you again have one more option that > you need to include in IKE_SA_INIT making it even bigger. The responder only includes an empty Notify in a COOKIE request message, which usually contains only N(COOKIE), so it's less than 100 bytes in length. With my proposal it'll 8 bytes longer. Not a big loss. > > Initiator Responder > > HDR, SAi, KEi, Ni --> > > <-- HDR, N(COOKIE), N(COOKIE_NA) > > HDR, N(COOKIE_NA), SAi, KEi, Ni --> > > <-- HDR, SAr, KEr, Nr > > > > We define a new status notify COOKIE_NA (No Auth). The responder > > includes both COOKIE and COOKIE_NA in its response, COOKIE is formed > > as usual, COOKIE_NA is empty. If the initiator supports this > > extension, it includes COOKIE_NA (instead of COOKIE) in the retried > > IKE_SA_INIT request, copying a content of COOKIE there. If the > > responder receives retried request with COOKIE_NA and successfully > > verifies it, later when initiator's AUTH is being verified it just > > zeroes out the content of COOKIE_NA notification in the initiator's > > message passed to prf. The same does the initiator when calculating > > AUTH payload. I must correct myself. Zeroing out cookie is not enough - it must be completely removed from the initiator's message while performing AUTH computation, as if no cookie was exchanged (and correct Next Payload and Length in IKE Header). The reason is that another sequence possible when the server first feels it's under attack and returns cookie, but then when the client retransmits the server can no more feel it is being attacked and returns IKE_SA_INIT as usual. In this case if packets are reordered and delayed we may run into the situation when the client will think cookie was requested, but the server will think that it requested no cookie. > I think that would work too. I wonder if there is any new attacks > which can be done, because now the cookie is no longer authenticated > at all? I have to think about whether there is something that can be > done when initiator and responder do no longer include cookie in their > auth calculations. In my proposal both would still include the cookie > in calculations so security properties is not changed, responder just > gets informed which cookie was used by initiator. I hope it leads to no new attacks. Cookie is verified by other means and if we just have an input to the AUTH as if no cookie was exchanged (that is a legitimate case). > > Comparing with your proposal: > > - it consumes less bits on the wire > > It uses more bits on the wire in the IKE_SA_INIT where it counts. My 8 bytes on the very short message requesting cookie. > proposal does not use any extra bytes there. On the other hand your > proposal uses them in responders cookie reply, where it most likely do > not matter. Usually the size of cookie is about 32-64 bytes, so it'll add 40-72 bytes to repeat cookie. However, I agree that it's IKE_AUTH when this is not a big issue. > > - it consumes less resources on the responder (no need to verify > > cookie received in IKE_AUTH) > > Stateless cookie verifications are supposed to be very fast, so I do > not think that is big issue. I agree, but you still have to do some work. Comparing to zero work. > > - 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. > > The sad thing is that both initiator and responder need to be > > modified... > > I think that is unavoidable unless you want to do heristics like I > described in other email and keep some state. > > Anyways both of these would work, the question is, whether this > problem is big enough that we want to modify the IKEv2 protocol to fix > this. Or whether if we just change cookie secret not to change too > often that will make problem so rare that we do not care. This is the question. However, giving the advice from RFC8019 (see above), it seems that the problem is worth to solve. Regards, Valery. > -- > kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
