The paper's defence against a flood of knocks, section 5.4.7, the last
piece of WireGuard the Temple did not speak.  A knock costs the
responder Curve25519 work; a flood of them with forged addresses costs
it everything.

- More than ten knocks in a second and the Temple is under load for the
  next second.  A knock or an answer then needs a good mac1 to get any
  word at all, and a good mac2 to get the Curve25519 work.  Without
  mac2 it gets a cookie instead: a MAC of the knocker's IP and port
  under a secret that changes every two minutes, sealed with
  XChaCha20-Poly1305 to the knock's mac1.  Only who really sits at that
  address can read it and come back.
- Every knock and answer we send now carries mac2 when a friend under
  load gave us a cookie less than two minutes ago.  We do not knock
  again at once, the timers do, so a cookie is no lever for a flood.
- WgCookieAlways asks for a cookie on every knock.  WgRep counts them.
- ChaCha20 gets HChaCha20 and XChaCha20-Poly1305, checked against the
  draft's HChaCha20 example and libsodium.  WgMac takes the key length:
  a cookie is a 16-byte key, not 32.

CryptoTest: HChaCha20, XChaCha20-Poly1305, and the whole cookie dance
against tools/wg_vectors.py, which gets the same in Python.  111 of 111.

wg_interop.py against Linux's kernel WireGuard: E, the Temple asks for
cookies and Linux comes back with mac2 and gets in; F (--flood), three
floods with a good mac1 put Linux under load, the Temple takes Linux's
cookie and gets in.  14 of 14.