wireguard::CookiePacket Class Reference

#include <wireguard.h>

Inheritance diagram for wireguard::CookiePacket:

Public Member Functions
	CookiePacket (const std::string &buffer)
crypto::string &	operator[] (const size_t &val)
const crypto::string &	operator[] (const size_t &val) const
Public Member Functions inherited from wireguard::Packet
std::string	Serialize ()
	Serialize the packet.
void	Expand (const std::string &buffer, const bool &fill=false)
	Construct a Packet from a std::string.

Static Public Attributes
static constexpr size_t	reserved = 0
static constexpr size_t	receiver = 1
static constexpr size_t	nonce = 2
static constexpr size_t	cookie = 3

Additional Inherited Members
Protected Attributes inherited from wireguard::Packet
std::vector< crypto::string >	values

Detailed Description

Remarks

The WireGuard Reference at 5.4.7 explains the idea of Cookie, where if the Server is overloaded and cannot accept new connections, it will return a cookie packet as opposed to the second packet of the handshake. The idea is that the peer will wait the timeout period, and when they request a handshake again, provide this cookie. Don't think of this cookie like an internet cookie: It doesn't cache any part of the handshake such that the peer can just sent the cookie as opposed to the first packet of the handshake. They still need to do the work, including generating new ephemeral keys; to my understanding, the cookie is little more than a priority queue. The Reference stipulates that (5.3): "When the responder receives the message, if it is under load, it may choose whether or not to accept and process the message based on whether or not there is a correct MAC that uses the cookie as the key. This mechanism ties messages sent from an initiator to its IP address, giving proof of IP ownership, allowing for rate limiting using classical IP rate limiting algorithms (token bucket, etc—see section 7.4 for implementation details)" You may notice the language "choose to accept based on a correct MAC based on the cookie." (mac2). This, to me, reads that peers connecting without cookies are deprioritized to those that do have cookies.

Now, onto how the Cookie actually works: The random value cookie_random is hashed with the clients IP and Port. This creates a random value, cycled every 2 minutes, that the server sends to clients. By setting the value with the client's IP, it necessarily ties the cookie to a particular client, so it can't be reused by other peers. However, if we send the cookie across the wire it would be possible to brute force the random value given that we know the IP of the peer; so, we add additional measures. Firstly, we encrypt the message with the server's public key (Nothing too special here), and use a randomized nonce (So a cookie cannot be reused), but then provide AAD as the mac1 of the the original packet. In doing so, only the person who sent the original handshake packet is able to decrypt the cookie.

---

The documentation for this class was generated from the following file:

• src/wireguard.h