Valery Smyslov writes: > Hi Tero, > > > Simple solution. Do not change cookie generation secret too often if > > you are under attack with really crappy network... > > Unfortunately, RFC7296 advises just the opposite: > > The responder should change the value of <secret> frequently, especially > if under attack.
Frequently, as in every hour or so. Not as every few minutes. There is nothing gained changing the cookie secret too often, as changing it only protectes against attackers who can do return routability checks. It only protectes against attackers who are using single or very few devices to do the attack, and want to collect lots of valid cookies, and then mount an attack. > > 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. 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. > > > > It seems like a rare scene but I think it needs to be considered. > > > Compared with ignoring cookie payload, how about adding N(COOKIE2) > > > in the 9th message? Then when Initiator received the 12th message, > > > it'll know which cookie this message matches with. > > > > Actually I think the best option is to include the N(COOKIE) in the > > Initiators IKE_AUTH too. I.e.: > ... > > Now when Responder receives IKE_AUTH at step 9, it will decrypt that > > and it can see that Initiator thinks the cookie is COOKIE1, and it can > > then reconstruct the packets initiator is using for his calculations. > > Of course it needs to assume that initiator did not change order of > > payloads or anything else when it swiched from COOKIE2 to COOKIE1, > > i.e., that only difference in step 5 and step 7 packets is the cookie > > payload contents. > > > > 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. > 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. > > 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 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. > 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 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. > - 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. > - 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... > 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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
