Re: [quicwg/base-drafts] Address validation for connection migration (#732)

[janaiyengar <[e-mail]>]

janaiyengar commented on this pull request.

First off, and sorry for not saying this earlier, thanks for working on all this text -- a lot of this is helpful! I'll be fine with the comments I have inline. Mostly, I'll be fine if you remove the normative text about requiring switching to the new path, since this fundamentally prevents probing. The other stuff is good; I'd prefer less verbose text, but whatever. Happy to iterate after you get this in.

> +the value correctly.
+
+Note:
+
+: Retransmissions of the PING frame MUST also use the same remote address.
+
+If validation of the new remote address fails, after allowing enough time for
+possible loss and recovery of packets carrying PING and PONG frames, the
+endpoint MUST terminate the connection.  When setting this timer,
+implementations are cautioned that the new path could have a longer round trip
+time than the original.  The endpoint MUST NOT send a CONNECTION_CLOSE frame in
+this case; it has to assume that the remote peer does not want to receive any
+more packets.
+
+If the remote address is validated successfully, the endpoint MAY increase the
+rate that it sends on the new path using the state from the previous path.  The

This is about behavior after the path is validated ... conservative behavior would be to reset the congestion controller to initial state. I say SHOULD because there may be good reasons for using other state (such as state stored about the new network). I'm just suggesting a shortening that is adequate, not a different statement here. My suggestion here is to not say anything about what to do with NAT rebinding... if current practice is useful, I'm happy to help document what we observe in the wild. Otherwise, let's just recommend the conservative thing.

> @@ -1351,6 +1355,14 @@ connection when they move networks.  This includes state that can be hard to
 recover such as outstanding requests, which might otherwise be lost with no easy
 way to retry them.
 
+An endpoint that receives packets that contain a source IP address and port that

I don't think this is too bad, it's just one design that I don't think is adequate. Which is why I don't think there should be normative behavior here yet. I would like to build on this PR, and add normative behavior that _we all agree_ should be normative. At the moment I don't think what you're stating as normative is useful. You're requiring that an endpoint switch immediately, which is unnecessary.

FWIW, I've opened #880.

> @@ -1484,9 +1501,110 @@ number. "packet_number_secret" is derived from the TLS key exchange,
 as described in Section 5.6 of {{QUIC-TLS}}.
 
 
-### Address Validation for Migrated Connections
-
-TODO: see issue #161
+### Address Validation for Migrated Connections {#migrate-validate}

I think this section is useful, and does capture the resolution of #161.

-- 
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/732#pullrequestreview-69762241