Some questions about the protocol

Some questions about the protocol

[sopium]

Hi,

These are some questions about some corner cases and details of
the protocol, that the paper does not seem to clearly specify:

* Do we send cookie reply messages in response to handshake
  _response_ messages? My guess is YES? The figure in 5.4.1 only
  shows the case that the responder chooses to reply with a
  cookie message.

* Shall we start handshake in case the _previous_ session is not
  alive, or too old? My guess is NO?

* When padding packets, how to avoid getting larger than MTU,
  because we don't seem to know the MTU?

* When we receive a valid handshake init message, a secure
  transport is session is created. Do we start sending with this
  session immediately, in case there is still a valid previous
  session? Because if the handshake response we send is lost, the
  peer won't be able to decrypt our transport messages. The
  problem should eventually go away, but the peer may experience
  a brief blackout.

  So, shall we wait until successfully receiving a transport
  message with the new session, before start sending with
  it? (When the previous session is still valid, of course.)

Regards,
Sopium

Re: Some questions about the protocol

[sopium]

And, do we set peer endpoint when receiving an authenticated cookie reply message? No?

Re: Some questions about the protocol

[Jason A. Donenfeld]

Hey,

Good questions.

Firstly, I've augmented the timers section on wireguard.io/protocol/ a
little bit, and I'll continue adding detail to this.

Secondly, I hope work is coming along nicely with you and Sascha for
merging your efforts. With Sascha's approval, I can set you up with
commit access to wireguard-rs, if you'd like.

Now, onto your questions:


On Tue, Mar 14, 2017 at 8:25 PM, sopium <sopium@mysterious.site> wrote:
> * Do we send cookie reply messages in response to handshake
>   _response_ messages? My guess is YES? The figure in 5.4.1 only
>   shows the case that the responder chooses to reply with a
>   cookie message.

Yes. Cookie reply messages are sent when:
- mac1 is valid; and
- mac2 is invalid; and
- the machine is under load
This applies to all messages that have mac1&&mac2, which means both
the handshake initiation and handshake response messages.

> * Shall we start handshake in case the _previous_ session is not
>   alive, or too old? My guess is NO?

I'm not sure I understand your question. Could you rephrase? Here's
some text that might clarify things possibly:

- A handshake initiation is retried after REKEY_TIMEOUT ms, if a
response has not been received.
- If we have sent a packet to a given peer but have not received a
packet (or a keepalive) after from that peer for (KEEPALIVE +
REKEY_TIMEOUT) ms, we initiate a new handshake.
- After sending a packet, if the number of packets sent using that key
exceed REKEY_AFTER_MESSAGES, we initiate a new handshake.
- After sending a packet, if the sender was the original initiator of
the handshake and if the current session key is REKEY_AFTER_TIME ms
old, we initiate a new handshake. If the sender was the original
responder of the handshake, it does not reinitiate a new handshake
after REKEY_AFTER_TIME ms like the original initiator does.
- After a handshake is completed, with a message from initiator to
responder and then responder back to initiator, the initiator may then
send encrypted session packets, but the responder cannot. The
responder must wait to use the new session until it has recieved one
encrypted session packet from the initiator, in order to provide key
confirmation. Thus, until the responder receives that first packet
using the newly established session, it must either queue up packets
to be sent later, or use the previous session, if one exists and is
valid. Therefore, after the initiator receives the response from the
responder, if it has no data packets immediately queued up to send, it
should send en empty packet, so as to provide this confirmation.

> * When padding packets, how to avoid getting larger than MTU,
>   because we don't seem to know the MTU?

You know the MTU of the WireGuard interface, and so you pad packets to
fit into that. You can query this from the TUN device.

WireGuard currently doesn't do per-peer-endpoint PMTU, but I'm working
on this, and I'll update you when this is worked out.

> * When we receive a valid handshake init message, a secure
>   transport is session is created. Do we start sending with this
>   session immediately, in case there is still a valid previous
>   session? Because if the handshake response we send is lost, the
>   peer won't be able to decrypt our transport messages. The
>   problem should eventually go away, but the peer may experience
>   a brief blackout.

The initiator begins using the newly created session immediately after
receiving the response from the responder.
The responder keeps using the previously created session, until it has
received the first encrypted message from the initiator, at which
point it starts using the new session. This is to ensure "key
confirmation" and also has the nice effect of avoiding race conditions
and blackouts.
In total, you need to have "previous session", "current session", and
"next session", and cycle these as needed.

In case that explanation above isn't clear:
add_new_keypair is called immediately after computing the session keys
(the combination of initiation message + response message):
https://git.zx2c4.com/WireGuard/tree/src/noise.c#n122
noise_received_with_keypair is called whenever a symmetrically
encrypted&authenticated packet is received.

>   So, shall we wait until successfully receiving a transport
>   message with the new session, before start sending with
>   it? (When the previous session is still valid, of course.)

Yes.

>
> * And, do we set peer endpoint when receiving an authenticated
>   cookie reply message? No?

Your intuition is correct: no, you shouldn't do this.

Great questions. Let me know if you have more, or if it'd be helpful
to talk through this stuff on video chat or telephone instead of
email.

Regards,
Jason

Re: Some questions about the protocol

[sopium]

Hi,

Thanks for the reply. Some more questions.

The most tricky one first:

Do we send back keep-alive packets in response to keep-alive packets?
[No?] If so, they will ping-pong indefinitely, and persistent
keep-alive seems unnecessary. If not, do we send keep-alive packets in
response to persistent keep-alive packets? [Yes?] Then we need to
distinguish these two different types of keep-alive?

And,

2017-03-16 0:34 GMT+08:00 Jason A. Donenfeld <Jason@zx2c4.com>:
> [...]
>> * Shall we start handshake in case the _previous_ session is not
>>   alive, or too old? My guess is NO?
>
> I'm not sure I understand your question. Could you rephrase? Here's
> some text that might clarify things possibly:

[Not a question] I was thinking of these timers as tied to individual
sessions. It all makes sense if they are tied to the peer.

>> * When padding packets, how to avoid getting larger than MTU,
>>   because we don't seem to know the MTU?
>
> You know the MTU of the WireGuard interface, and so you pad packets to
> fit into that. You can query this from the TUN device.
>
> WireGuard currently doesn't do per-peer-endpoint PMTU, but I'm working
> on this, and I'll update you when this is worked out.

Since a WireGuard interface can have multiple peers, some may have
a smaller MTU than the interface MTU?

Regards,
Sopium

Re: Some questions about the protocol

[Jason A. Donenfeld]

On Mon, Mar 20, 2017 at 6:06 AM, sopium <sopium@mysterious.site> wrote:
> Do we send back keep-alive packets in response to keep-alive packets?
> [No?] If so, they will ping-pong indefinitely, and persistent
> keep-alive seems unnecessary. If not, do we send keep-alive packets in
> response to persistent keep-alive packets? [Yes?] Then we need to
> distinguish these two different types of keep-alive?

You do _not_ send a keepalive to a keepalive.
You do _not_ need to distinguish the two different types of keepalives.
You do _not_ send keepalive packets in response to persistent
keepalive packets. They are the same and indistinguishable.

The rule is:
   If a non-keepalive data packet has been received from a given peer,
but we have not
   sent either a non-keepalive data packet nor a keepalive data packet
to the given peer
   within the last KEEPALIVE ms, then we send a keepalive data packet.

When persistent keepalive is enabled, we simply send a keepalive every
X ms, which satisfies the condition above, and thus no additional
keepalives need to be sent, if persistent keepalive interval is >
KEEPALIVE ms.

>> WireGuard currently doesn't do per-peer-endpoint PMTU, but I'm working
>> on this, and I'll update you when this is worked out.
>
> Since a WireGuard interface can have multiple peers, some may have
> a smaller MTU than the interface MTU?

Yes. Per-peer PMTU discovery is currently a TODO item, but currently
is not worked out. Right now the best we can do is per-interface. This
will change at some point in the future, but not now.