Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Reported-by: Cedric Buxin <cedric.buxin@izri.org>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

This took hours of debugging. In some cases, the src and dst are
different for the last piece, so the incorrect code here resulted in
computing the poly1305 over the wrong data. This lead to packets being
unnecessarily dropped.

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

These amount to the same exact thing, except that IPv6 auto
configuration won't assign it a (useless) random address and add
multicast routes.

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jörg Thalheim <joerg@higgsboson.tk>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

If it's time to rekey, and the responder sends a message, the initator
will begin the rekeying when sending his response message. In the worst
case, this response message will actually just be the keepalive. This
generally works well, with the one edge case of the message arriving
less than 10 seconds before key expiration, in which the keepalive is
not sufficient. In this case, we simply rehandshake immediately.

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

With the prior behavior, when sending a packet, we checked to see if it
was about time to start a new handshake, and if we were past a certain
time, we started it. For the responder, we made that time a bit further
in the future than for the initiator, to prevent the thundering herd
problem of them both starting at the same time. However, this was
flawed.

If both parties stopped communicating after 2.2 minutes, and then one
party decided to initiate a TCP connection before the 3 minute mark, the
currently open session would be used. However, because it was after the
2.2 minute mark, both peers would try to initiate a handshake upon
sending their first packet. The errant flow was as follows:

1. Peer A sends SYN.
2. Peer A sees that his key is getting old and initiates new handshake.
3. Peer B receives SYN and sends ACK.
4. Peer B sees that his key is getting old and initiates new handshake.

Since these events happened after the 2.2 minute mark, there's no delay
between handshake initiations, and problems begin. The new behavior is
changed to:

1. Peer A sends SYN.
2. Peer A sees that his key is getting old and initiates new handshake.
3. Peer B receives SYN and sends ACK.
4. Peer B sees that his key is getting old and schedules a delayed
   handshake for 12.5 seconds in the future.
5. Peer B receives handshake initiation and cancels scheduled handshake.

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Since it's extremely unlikely for jiffies to be exactly identical
everywhere, applying quarter second power of two slack not only improves
power efficiency but also ensures that retries have a bit of jitter.

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Before:
	t+120: A sends rekey
	[packet dropped by network congestion]
	t+125: A sends rekey
	[packet dropped by network congestion]
	t+130: A sends rekey
	t+130: B sends rekey
	! race !

After: t+120: A sends rekey
	[packet dropped by network congestion]
	t+125: A sends rekey
	[packet dropped by network congestion]
	t+130: A sends rekey
	[packet dropped by network congestion]
	T+132.5: B sends rekey
	[packet dropped by network congestion]
	T+135: A sends rekey
	[packet dropped by network congestion]
	T+137.5: B sends rekey
	! success, eventually !
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

http: //marc.info/?l=linux-mm-commits&m=147553169709478&w=2
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Otherwise we get packet reordering.

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>