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.
> I mean if the
> attackers are sending blind connection attemps where cookies help,
> changing the cookie does not make any difference. If the attackers are
> using real DDoS where each attack packet is actually a host which will
> reply to your cookie request then again changing cookie secret does
> not help. Only case where changing cookie secret helps is that
> attacker cannot collect thousands of valid cookie responsenses and
> then suddenly send them all out.
>
> Or you could try to make sure that the cookie secret selection is
> stabile for the same peer always for longer time, i.e. remember some
> state that you used cookie secret x for following sessions before
> changing to new one. After the cookie secret is changed and enough
> time has gone by, you can forget that list and old secret, and you
> only need to start collecting that list at the point when you are
> planning to change cookie generation secret again soon.
>
> If you have 10000 incoming connections per second and you consider 300
> seconds for suitable timeout for sessions to finish, and you only
> store source ipv4-address for each time you used cookies, you need 11
> MB of memory for that state (and that assumes none of the incoming
> sessions are actually coming from same ip-address).
I don't like stepping back from stateless to stateful solution (although with a
limited state)...
And it doesn't solve the problem completely, it will only occur less frequently.
> > Any opinions? Should this problem be addressed by the WG or ignored?
>
> 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.
> > 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.
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.
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.
Comparing with your proposal:
- it consumes less bits on the wire
- it consumes less resources on the responder (no need to verify cookie
received in IKE_AUTH)
- it eliminates cases when the responder cannot verify cookie sent in IKE_AUTH
(unclear what to do in this case)
The sad thing is that both initiator and responder need to be modified...
Regards,
Valery.
> kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
