* Some questions about the protocol @ 2017-03-15 3:25 sopium 2017-03-15 5:52 ` sopium 2017-03-15 16:34 ` Jason A. Donenfeld 0 siblings, 2 replies; 5+ messages in thread From: sopium @ 2017-03-15 3:25 UTC (permalink / raw) To: wireguard 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Some questions about the protocol 2017-03-15 3:25 Some questions about the protocol sopium @ 2017-03-15 5:52 ` sopium 2017-03-15 16:34 ` Jason A. Donenfeld 1 sibling, 0 replies; 5+ messages in thread From: sopium @ 2017-03-15 5:52 UTC (permalink / raw) To: wireguard And, do we set peer endpoint when receiving an authenticated cookie reply message? No? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Some questions about the protocol 2017-03-15 3:25 Some questions about the protocol sopium 2017-03-15 5:52 ` sopium @ 2017-03-15 16:34 ` Jason A. Donenfeld 2017-03-20 5:06 ` sopium 1 sibling, 1 reply; 5+ messages in thread From: Jason A. Donenfeld @ 2017-03-15 16:34 UTC (permalink / raw) To: sopium; +Cc: wireguard 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Some questions about the protocol 2017-03-15 16:34 ` Jason A. Donenfeld @ 2017-03-20 5:06 ` sopium 2017-03-20 15:18 ` Jason A. Donenfeld 0 siblings, 1 reply; 5+ messages in thread From: sopium @ 2017-03-20 5:06 UTC (permalink / raw) To: Jason A. Donenfeld, wireguard 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Some questions about the protocol 2017-03-20 5:06 ` sopium @ 2017-03-20 15:18 ` Jason A. Donenfeld 0 siblings, 0 replies; 5+ messages in thread From: Jason A. Donenfeld @ 2017-03-20 15:18 UTC (permalink / raw) To: sopium; +Cc: wireguard 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-03-20 15:13 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-15 3:25 Some questions about the protocol sopium 2017-03-15 5:52 ` sopium 2017-03-15 16:34 ` Jason A. Donenfeld 2017-03-20 5:06 ` sopium 2017-03-20 15:18 ` Jason A. Donenfeld
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).