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

From: Martin Thomson <[email-masked]>
Date: Thu, 11 May 2017 23:04:58 -0700

There's two layers of defense here:

1. Version Negotiation echoes 31-bits of entropy (maybe more if you consider the version to be at all unpredictable, or the client's source address to contain any entropy).

2. If validation fails and version negotiation happened, encourage the client to try again ignoring any Version Negotiation packets that match the failed profile.

Closes #523.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/524

-- Commit Summary --

  * Increase resilience to spoofed Version Negotiation packets

-- File Changes --

    M draft-ietf-quic-transport.md (33)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/524.patch
https://github.com/quicwg/base-drafts/pull/524.diff

-- 
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

---

From: Mike Bishop <[email-masked]>
Date: Tue, 16 May 2017 15:24:08 -0700

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

---

From: janaiyengar <[email-masked]>
Date: Tue, 16 May 2017 16:16:35 -0700

janaiyengar commented on this pull request.

+1. I would expect the common case to be mismatch, since an attacker can easily generate a VN packet that supports a large number of known versions (minus the client's chosen).

-- 
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#discussion_r116880042

---

From: janaiyengar <[email-masked]>
Date: Tue, 16 May 2017 16:19:06 -0700

The client has to rely on the list; it just cannot validate the list until the end of the handshake. 

-- 
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#discussion_r116880354

---

From: janaiyengar <[email-masked]>
Date: Tue, 16 May 2017 16:33:45 -0700

I don't think we know this to be likely a result of spoofing, so I wouldn't say it yet.

-- 
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-38539287

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 May 2017 09:32:09 -0700

martinthomson commented on this pull request.

Ack, I'll correct that.

If there is a disagreement between transport parameters and version negotiation, then something is broken.  I don't think that it matters if it is due to spoofing or a bug.

I'll cut this paragraph.

-- 
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#discussion_r117023206

---

From: janaiyengar <[email-masked]>
Date: Wed, 17 May 2017 18:14:21 -0700

I completely agree that something is broken in this case, but the text doesn't say that. It says "it is likely that the client received a spoofed Version Negotiation packet."

-- 
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#discussion_r117144211