[noise] Still working on DoS to no avail

[Trevor Perrin]

On Tue, Dec 22, 2015 at 8:14 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> I've got a big problem with WireGuard and denial of service.
[...]
> Let's go through a few ideas that don't work.
[...]
> - Then why not use a cookie situation, like DTLS or IKEv2? Here, when the
> responder is overloaded, it can optionally send a response saying "here's a
> cookie value. Retransmit your message using this cookie value." The cookie
> value is actually an HMAC of the initiator's source IP and port with some
> responder secret that rotates every few seconds/minutes/whatever. The
> responder keeps a ledger of the last eight or so secrets so it can try them
> all, hoping one matches that isn't too old. Then, ordinary IP ratelimiting
> can be applied to messages with the correct cookies, since spoofing will no
> longer be possible.

"Cookies" do seem like the standard approach.  You mention DTLS and
IKE, but also CurveCP, and the idea goes back to Photuris, I think.

I'm not sure I understand your objections:


> The problem here is that WireGuard relies on symmetric roles and protocols
> of the initiator and responder -- they can change roles at any moment, and
> they each might be communicating with multiple peers.

Any Noise handshake has initiator and responder roles, the responder
would send the cookie if it's overloaded and wants to add a round-trip
to prevent IP spoofing.


> In the IKEv2/DTLS
> cookie scheme, the cookie the responder sends back to the initiator is
> unauthenticated. An attacker can flood an initiator with bogus cookie
> responses to cause a DoS.

I don't know whether they have a countermeasure for this beyond UDP
port numbers.  You could add a random value in the initiator's message
which is echoed by the responder.


> Also, this cookie value can be learned via MitM.

I guess people just live with that risk.  There doesn't seem to be a
better alternative.


> This also ruins the nice "one round trip" property of WireGuard. Though in
> most cases -- when not overloaded -- the cookie round trip wouldn't be
> required, sometimes it would, and this does add complexity.

Doesn't seem that complicated - the client sends an initial Noise_IK
message, and if the server wants the DoS countermeasure, it refuses to
handle the request, and instead sends a cookie.  The client resends
the request with the cookie, at which point the server accepts it.

Trevor