Re: [quicwg/base-drafts] Increase resilience to spoofed Version Negotiation packets (#524)

[Mike Bishop <[e-mail]>]

MikeBishop requested changes on this pull request.

First part seems good; second part makes me a little sad.

> @@ -1228,6 +1235,18 @@ client MUST terminate with a QUIC_VERSION_NEGOTIATION_MISMATCH error code if
 version negotiation occurred but it would have selected a different version
 based on the value of the supported_versions list.
 
+If the client receives a Version Negotiation packet and these validation checks
+subsequently fail, it is likely that the client received a spoofed Version
+Negotiation packet.  A client MAY attempt to create a new connection and ignore
+any Version Negotiation packets that match those that caused the connection to
+fail.
+
+Note:
+
+: The client cannot rely on the version list from the transport parameters.

I'd rephrase this -- the client certainly *can* rely on that list -- once the handshake has completed.

> -uses on every packet it sends.  Packets MUST continue to use long headers and
-MUST include the new negotiated protocol version.
+A client MUST discard a Version Negotiation packet that does not contain Packet
+Number and Version fields that match those fields in a packet that the client
+previously sent.  This doesn't guarantee that the Version Negotiation packet is
+genuine, but it reduces the chances that the packet is spoofed.
+
+A client that receives a valid Version Negotiation packet selects an acceptable
+protocol version from those listed by the server.  The client then reattempts to
+create a connection using that version.  Though the contents of a packet might
+not change in response to version negotiation, a client MUST choose a new packet
+number it uses on every packet it sends.
+
+If the server does not list an acceptable version, the client MAY ignore the
+Version Negotiation packet.  This might reduce the likelihood that a spoofed
+Version Negotiation packet can be used to disrupt connection establishment.

This seems very painful if there is a real mismatch.  We've already blocked out injected packets, and I suspect that legitimate failures will be more common.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/524#pullrequestreview-38528721