Subject: [quicwg/base-drafts] Stop requiring remote address to match during path validation (#2637)

From: erickinnear <[email-masked]>
Date: Fri, 19 Apr 2019 17:54:41 -0700

This covers a few issues and attempts to clean up the normative text, further editorial rearranging is for a future PR, since we need to agree on some changes to the requirements first.

This removes the requirement that the remote address match between PATH_CHALLENGE/PATH_RESPONSE. 

As @martinduke said in #2582: 
>With PATH_CHALLENGE going out on both paths, these duplicate packets create four outcomes depending on which packets arrive first: both paths appear to be valid, the right path only is valid, the wrong path only is valid, or neither path is valid. The current requirement that the source address of PATH_RESPONSE matches the destination of the PATH_CHALLENGE can cause validation of the correct path to fail.

In #2580, there was some thought around performing path validation as a MUST "unless the endpoint has other means validate the validate the new path". This text is a little stronger, saying that you MUST validate unless you have already done so and remembered --some of the mitigations to attacks being described rely on a guarantee that validation occurs (and on both the old and the new paths). If folks wanted to have a completely separate mechanism for validating paths and considered their server/client to "know better", I'm not saying we should prohibit that, but such a mechanism would need to be analyzed in terms of the possible attacks.

So far, I *think* this closes out the changes to actual requirements that are necessary, and can be followed with an editorial pass to group the requirements in a way that's less confusing to first time readers (and thanks to @martinduke and others who gave this a close read in Prague!).

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

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

-- Commit Summary --

  * Stop requiring source address to match on path responses
  * Merge branch 'master' into validation_source_address

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2637.patch
https://github.com/quicwg/base-drafts/pull/2637.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/2637

---

From: ianswett <[email-masked]>
Date: Tue, 23 Apr 2019 13:31:07 -0700

ianswett approved this pull request.

Thanks, this seems sensible to me.

-- 
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/2637#pullrequestreview-229779757

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Apr 2019 20:42:59 -0700

martinthomson requested changes on this pull request.

> @@ -1762,9 +1756,9 @@ initiated while a path validation on the old path is in progress.
 # Connection Migration {#migration}
 
 The use of a connection ID allows connections to survive changes to endpoint
-addresses (that is, IP address and/or port), such as those caused by an endpoint
-migrating to a new network.  This section describes the process by which an
-endpoint migrates to a new address.
+addresses (the two-tuple of IP address and port), such as those caused by an

```suggestion
addresses (IP address and port), such as those caused by an
```

For some, this is a three-tuple, if you include the address family.

> @@ -1714,12 +1714,6 @@ meets the following criteria:
   acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate
   validation, since the acknowledgment can be spoofed by a malicious peer.
 
-- It was sent from the same remote address to which the corresponding
-  PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received from a different
-  remote address than the one to which the PATH_CHALLENGE was sent, path
-  validation is considered to have failed, even if the data matches that sent in
-  the PATH_CHALLENGE.
-
 - It was received on the same local address from which the corresponding
   PATH_CHALLENGE was sent.

I think that we can remove this requirement also.  For the recipient, there is no requirement to have the packet that carries a PATH_RESPONSE travel on any particular path.

What you need to have here is a much clearer split in the requirements: the responder MUST send a PATH_RESPONSE on the same path that it got the PATH_CHALLENGE on, but the initiator MUST accept a PATH_CHALLENGE that arrives on any path.  I think that you need a paragraph explaining that split and why it exists.

-- 
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/2637#pullrequestreview-229887152