Valery Smyslov writes: > I believe that the proper solution would be to exclude cookie from > the AUTH payload calculation. It is verified by the responder using > cookie generation secret and it is not concerned with a client (the > client did not generate it, just echoes it back). However, this > solution is obviously incompatible with RFC7296, so this is not an > option.
Simple solution. Do not change cookie generation secret too often if you are under attack with really crappy network... 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). > 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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
