[Swan-dev] redirect and cookies

[Vukasin Karadzic]

Hi,

please see inline.

уто, 21. јул 2020. у 03:42 Paul Wouters <paul at nohats.ca> је написао/ла:

> On Sun, 12 Jul 2020, Vukasin Karadzic wrote:
>
> I pushed a change so that redirect only finds established IKE SA's to
> redirect and not IPsec SA's. I've updated the tests that showed some
> minor output changes.
>

Thanks!

Other than man page entry verification, I think the feature is done for
> now?
>

Not entirely, specification of multiple redirect destinations for
redirection in IKE_AUTH (conn conf options) is still not supported.
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
been added in previous couple of weeks.

About the man pages, the whack one (pluto man page) is not updated, thanks
for the reminder.


> Although I'm a little puzzled by the support for DDOS COOKIE along with
> REDIRECT in IKE_SA_INIT. The RFC does not mention cookies, so no
> guidance there.
>
> Possible scenarios:
>
> 1) server is too busy but no DDOS, sends redirects to everyone in
> IKE_SA_INIT
> 2) server is too busy but no DDOS, sends redirects for specific connection
> in IKE_AUTH
>
> These dont do any COOKIES. Now there is a DDOS attack:
>
> 3) server is too busy due to DDOS, requiring cookies but then still
> serving clients without redirect
> 4) server is too busy due to DDOS, requiring cookies but then redirecting
> some connections in IKE_AUTH
> 5) server is too busy due to DDOS, requiring cookies and then redirecting
> everyone in IKE_SA_INIT
> 6) server is too busy due to DDOS, not requiring cookies and still sending
> redirects to everyone IN IKE_SA_INIT
>
> The question is, does 5) gain us anything over 6) ? In both cases we
> dont care about their packet content, we are just sending them all away.
>
> I guess at this point, we support it all because the two methods don't
> look at each other. And someone (Andrew?) ensured we handle the cases
> where both cookie and redirect happens.
>

We handle the case where both happen, first the cookie will be requested,
only after receiving
second IKE_SA_INIT request (this time with cookie) the client would be
redirected.

The following sentence from the IKEv2 RFC makes me think the above (that is
5)) is the right behavior

> 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.


Generating the cookie is pretty cheap, so I don't think it matters much.
> So I think I'm okay with the current method. But if anyone thinks we
> should maybe not support 5), please speak out. I could be convinced.
>
> Paul
>

Regards,
Vukasin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20200722/0049fb47/attachment.html>