CVS commit: src

["Taylor R Campbell" <riastradh%netbsd.org@localhost>]

Module Name:    src
Committed By:   riastradh
Date:           Tue Jun 30 20:05:12 UTC 2026

Modified Files:
        src/sys/net: if_wg.c
        src/tests/net/if_wg: t_basic.sh

Log Message:
wg(4): Move DoS mitigation a little earlier.

1. Don't store the cookie -- just recompute it on the fly as a
   pseudorandom function of the current two-minute unit, under a
   secret key generated at interface configuration time.

   This way we don't need to find what peer we're talking with --
   which requires a DH key agreement -- before we can verify mac2.

2. Actually, recompute _two_ cookies on the fly, one for
   floor(now/60) and the other for 1 + floor(now/60), and accept a
   valid mac2 under either cookie, or if mac2 is not valid, send the
   1 + floor(now/60) cookie.

   This way every cookie is valid for a total possible time of 2min,
   but the cookie we send is always valid for at least 1min in the
   future, so we never send a cookie that's going to immediately
   expire and require another REKEY-TIMEOUT delay (and this works
   without keeping any state).

3. Send the cookie to the handshake's source address, not to the
   peer's current address.

   This way we don't need to find what peer we're talking with --
   which requires a DH key agreement -- before we can send a cookie
   back.  And this way we don't send the cookie to a stale peer
   address, in case the peer has migrated networks.

4. Count all handshakes from any sources together when estimating
   whether we're under load.

   This way, again, we don't need to find what peer we're talking
   with -- which, you guessed it, requires a DH key agreement! --
   before we can decide whether we're under load.  Contention on
   these timestamps may not be great, but it's probably cheaper than
   computing DH key agreements (tens or hundreds of thousands of
   cycles).

   => Side effect: this causes some of the tests (multiple
      interfaces, multiple peers, bad handshake keys) to trigger the
      `under load' estimation when they didn't before, so we have to
      raise the test timeouts a little bit (from 1sec to 3sec for
      various pings) even if we tune REKEY-TIMEOUT to the minimum
      possible (1sec).  So the wg(4) tests take a few more seconds to
      run now.

PR kern/60386: experimental wg(4) DoS mitigation is suboptimal


To generate a diff of this commit:
cvs rdiff -u -r1.138 -r1.139 src/sys/net/if_wg.c
cvs rdiff -u -r1.9 -r1.10 src/tests/net/if_wg/t_basic.sh

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.