<div dir="ltr"><div>Hi,</div><div><br></div><div>please see inline.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">уто, 21. јул 2020. у 03:42 Paul Wouters <<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>> је написао/ла:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 12 Jul 2020, Vukasin Karadzic wrote:<br>
<br>
I pushed a change so that redirect only finds established IKE SA's to<br>
redirect and not IPsec SA's. I've updated the tests that showed some<br>
minor output changes.<br></blockquote><div><br></div><div>Thanks! <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Other than man page entry verification, I think the feature is done for<br>
now?<br></blockquote><div><br></div><div>Not entirely, specification of multiple redirect destinations for redirection in IKE_AUTH (conn conf options) is still not supported.</div>In the other two cases, redirect in IKE_SA_INIT and redirect during active sessions via whack, we do support it and that's what's</div><div class="gmail_quote">been added in previous couple of weeks.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><div>About the man pages, the whack one (pluto man page) is not updated, thanks for the reminder.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Although I'm a little puzzled by the support for DDOS COOKIE along with<br>
REDIRECT in IKE_SA_INIT. The RFC does not mention cookies, so no<br>
guidance there.<br>
<br>
Possible scenarios:<br>
<br>
1) server is too busy but no DDOS, sends redirects to everyone in IKE_SA_INIT<br>
2) server is too busy but no DDOS, sends redirects for specific connection in IKE_AUTH<br>
<br>
These dont do any COOKIES. Now there is a DDOS attack:<br>
<br>
3) server is too busy due to DDOS, requiring cookies but then still serving clients without redirect<br>
4) server is too busy due to DDOS, requiring cookies but then redirecting some connections in IKE_AUTH<br>
5) server is too busy due to DDOS, requiring cookies and then redirecting everyone in IKE_SA_INIT<br>
6) server is too busy due to DDOS, not requiring cookies and still sending redirects to everyone IN IKE_SA_INIT<br>
<br>
The question is, does 5) gain us anything over 6) ? In both cases we<br>
dont care about their packet content, we are just sending them all away.<br>
<br>
I guess at this point, we support it all because the two methods don't<br>
look at each other. And someone (Andrew?) ensured we handle the cases<br>
where both cookie and redirect happens.<br></blockquote><div><br></div><div>We handle the case where both happen, first the cookie will be requested, only after receiving</div><div>second IKE_SA_INIT request (this time with cookie) the client would be redirected.<br></div><div><br></div>The following sentence from the IKEv2 RFC makes me think the above (that is 5)) is the right behavior<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">When a responder detects a large number of half-open IKE SAs, it SHOULD reply to IKE_SA_INIT requests with a response containing the COOKIE notification.</blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Generating the cookie is pretty cheap, so I don't think it matters much.<br>
So I think I'm okay with the current method. But if anyone thinks we<br>
should maybe not support 5), please speak out. I could be convinced.<br>
<br>
Paul<br></blockquote><div><br></div><div>Regards,</div><div>Vukasin<br></div></div></div>