Subject: Re: [quicwg/base-drafts] A more complete connection migration (#1012)

From: ihlar <[email-masked]>
Date: Fri, 02 Feb 2018 08:50:13 +0000 (UTC)

ihlar commented on this pull request.

> +#### Committing to a New Address
+
+When a server receives a packet containing a frame other than PATH_CHALLENGE,
+PATH_RESPONSE, or PADDING from a client address with a packet number that is the
+largest seen thus far on the connection, the server "commits" to this client
+address. The server MUST send all subsequent packets to this address, with the
+following exception.  PATH_CHALLENGE, PATH_RESPONSE, and PADDING frames are used
+for probing a network path, and receiving only these frames MUST NOT cause the
+server to commit to a new address.
+
+Receiving a packet from a new address but with a packet number that is not the
+largest seen thus far suggests that a reordered packet was received and MUST NOT
+cause the server to change its commitment.
+
+Upon committing to a new address, the server SHOULD reset its congestion
+controller and roundtrip time estimator to start new estimations.

At this point it is still possible that a substantial amount of data is outstanding on the "previous" path, this data will be acked on the new path. I suppose that resetting the congestion controller and roundtrip time estimator means that such acknowledgements should be ignored when calculating the congestion window and the SRTT? 
This should probably be explicitly stated somewhere.

-- 
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/1012#pullrequestreview-93551693

---

From: Martin Thomson <[email-masked]>
Date: Sun, 04 Feb 2018 23:08:24 +0000 (UTC)

martinthomson commented on this pull request.

+

Excellent point.  "Only packets sent on the new path contribute to the state of the congestion control and RTT estimation on that path."

-- 
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/1012#discussion_r165861957

---

From: erickinnear <[email-masked]>
Date: Tue, 06 Feb 2018 18:35:44 +0000 (UTC)

@erickinnear pushed 1 commit.

86fd34f  Merge branch 'master' into dev/migration

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1012/files/0e366ef1d0c199333457bc6a369c6c5c478724f0..86fd34fe2f4d8e0c87cc7542bc4fa436daac59b9

---

From: janaiyengar <[email-masked]>
Date: Sun, 11 Feb 2018 22:40:09 -0800

@janaiyengar pushed 4 commits.

d7c9445  sync
138ed42  first cut at rewrite
e46264c  sync
8ebb6ae  complete rewrite

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1012/files/86fd34fe2f4d8e0c87cc7542bc4fa436daac59b9..8ebb6ae4a599395f32f372351d0ed5c44126b3e5

---

From: janaiyengar <[email-masked]>
Date: Mon, 12 Feb 2018 06:42:51 +0000 (UTC)

janaiyengar commented on this pull request.

> @@ -1714,9 +1798,9 @@ state to draining, but it otherwise has no impact.
 An endpoint could receive packets from a new source address, indicating a
 connection migration ({{migration}}), while in the closing period. An endpoint
 in the closing state MUST strictly limit the number of packets it sends to this
-new address as though the address were not validated (see {{migrate-validate}}).
-A server in the closing state MAY instead choose to discard packets received
-from a new source address.
+new address as though the address were not validated (see

Good point, fixed.

-- 
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/1012#discussion_r167475936

---

From: janaiyengar <[email-masked]>
Date: Sun, 11 Feb 2018 22:44:07 -0800

> @@ -702,6 +702,10 @@ use it for all subsequent Handshake ({{packet-handshake}}) and 1-RTT
 Server's Version Negotiation ({{packet-version}}) and Retry ({{packet-retry}})
 packets MUST use connection ID selected by the client.
 
+Note that the connection ID may change during the connection via the use of
+NEW_CONNECTION_ID frames ({{frame-new-connection-id}}) and connection migration
+({{migration}}).
+

This is discussed further below, in the linkability discussion. There's no normative language in this section, this is only a statement of fact.

-- 
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/1012#discussion_r167476035

---

From: janaiyengar <[email-masked]>
Date: Mon, 12 Feb 2018 06:44:33 +0000 (UTC)

@janaiyengar pushed 1 commit.

440db50  nits

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1012/files/8ebb6ae4a599395f32f372351d0ed5c44126b3e5..440db50738ff8d9a30cc7f601b84de0954cd54b7

---

From: janaiyengar <[email-masked]>
Date: Sun, 11 Feb 2018 22:51:07 -0800

Based on the comments on the PR and from the interim, I've done a rewrite of this patch. I am not changing packet number behavior yet, but I expect that's going to have to come out of the packet number encryption conversation. I am also limiting the migration protocol to client migration since making this symmetric adds sharp edges that need to be more carefully dealt with. I'm restricting the scope of this PR to the client/server use case that's most relevant for v1.

-- 
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/1012#issuecomment-364840256

---

From: ihlar <[email-masked]>
Date: Mon, 12 Feb 2018 12:52:54 +0000 (UTC)

> +a new client address fails. If the server has no state about the last validated
+client address, it MUST close the connection silently and discard any further
+packets received from the client for this connection.
+
+We note that receipt of packets with higher packet numbers from the legitimate
+client address will trigger another connection migration.  This will cause the
+validation of the address of the spurious migration to be abandoned.
+
+
+### Loss Detection and Congestion Control
+
+The capacity available on the new path might not be the same as the old path.
+
+A client SHOULD reset its congestion controller and roundtrip time estimator
+prior to sending any non-probing packets from a new local address.
+

As discussed earlier, I think it would make sense to add a text like:
 "Only packets sent on the new path contribute to the state of the congestion control and RTT estimation on that path."

-- 
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/1012#pullrequestreview-95778794

---

From: MikkelFJ <[email-masked]>
Date: Mon, 12 Feb 2018 05:34:47 -0800

mikkelfj commented on this pull request.

+The PATH_RESPONSE frame MUST be received on the same local address from which
+the corresponding PATH_CHALLENGE was sent.  If a PATH_RESPONSE frame is received
+on a different local address than the one from which the PATH_CHALLENGE was
+sent, path validation is considered to have failed, even if the data matches
+that sent in the PATH_CHALLENGE.
+
+Thus, the endpoint considers the path to be valid when a PATH_RESPONSE frame is
+received on the same path with the same payload as the PATH_CHALLENGE frame.
+
+The endpoint MAY send additional PATH_CHALLENGE frames to handle packet loss,
+but is subject to the following limit to avoid excessive network load: an
+endpoint SHOULD NOT send more than one PATH_CHALLENGE frame in 200ms.  This
+limit is approximately equivalent to the network load due to a new connection,
+and is based on the initial Handshake Timeout defined in {{QUIC-RECOVERY}}.
+

200ms is probably a sensible value, but for the life-time of the protocol it is hard to say what the network load of a new connection would be, not to mention that it could be totally different depening on the environment.

A different wording could be that is MUST be rate-limited to the estimated connection establishment time, and otherwise 200ms can be used as a default.

+An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames with other
+frames, as appropriate.  For instance, an endpoint may pad a packet carrying a
+PATH_CHALLENGE for PMTU discovery, or an endpoint may bundle a PATH_RESPONSE
+with its own PATH_CHALLENGE.
+
+
+### Initiating Connection Migration {#initiating-migration}
+
+A client MAY initiate connection migration to a new local address in one of two
+ways.
+
+The client may immediately migrate the connection by sending all packets from
+the new local address.  Receiving acknowledgments for this data serves as proof
+of the server's reachability from the new address.
+

Why is PATH_RESPONSE more strict than ACK's from just sending data wrt. local and remote addresses?

Should there be a rate limit on how often a migration can take place? It might stress the peer, and gaps in packet numbers can be a DoS on the peers implementation (I know gaps are up for discussion, but if/when there are gaps...)

+The client may immediately migrate the connection by sending all packets from
+the new local address.  Receiving acknowledgments for this data serves as proof
+of the server's reachability from the new address.
+
+Alternatively, the client may probe for server reachability from the new local
+address first using path validation {{migrate-validate}} and migrate the
+connection to the new address at a later time.  Failure of path validation
+simply means that the new local address is not usable for this connection and
+should not be fatal to the connection when alternative local addresses are
+available.
+
+A client migrating to a new local address SHOULD use a new connection ID for
+packets sent from that address, see {{migration-linkability}} for further
+discussion.
+

Is SHOULD sufficient? One endpoint might not care, but it the other endpoint might.

-- 
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/1012#pullrequestreview-95785888

---

From: ianswett <[email-masked]>
Date: Mon, 12 Feb 2018 21:10:38 +0000 (UTC)

ianswett commented on this pull request.

I wonder if this warrants a state diagram?

> @@ -1477,35 +1481,236 @@ connection if the integrity check fails with a PROTOCOL_VIOLATION error code.
 
 ## Connection Migration {#migration}
 
-QUIC connections are identified by their 64-bit Connection ID.  QUIC's
-consistent connection ID allows connections to survive changes to the client's
-IP and/or port, such as those caused by client or server migrating to a new
-network.  Connection migration allows a client to retain any shared state with a
-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.
+QUIC allows connections to survive changes to endpoint addresses (that is, IP
+address and/or port), such as those caused by a client migrating to a new
+network.  This section describes the protocol for migrating a connection to a
+new client address.
+
+Migrating a connection to a new server address is left for future work. If a
+client receives packets from a new server address that are decryptable, the
+client MAY discard these packets.

nit: Why bother decrypting the packets if they're going to be discarded?

I think we should try to mimic the handshake retransmission timer as closely as possible and require exponential backoff.

-An endpoint MUST validate that its peer can receive packets at the new address
-before sending any significant quantity of data to that address, or it risks
-being used for denial of service.  See {{migrate-validate}} for details.
+It is possible that the client is spoofing its source address to cause the
+server to send excessive amounts of data to an unwilling host.  If the server
+sends significantly more data than the client, connection migration might be
+used to amplify the volume of data that an attacker can generate toward a
+victim.
+
+Thus, on receiving and decrypting a packet from an unvalidated address, the
+server MUST immediately validate the client's new address to confirm the
+client's possession of the new address.
+
+Until a client's address is deemed valid, the server MUST limit the rate at
+which it sends data to this address.  The server MUST NOT send more than 4 * MSS

Where is 4 MSS from?  Recovery specifies 2 packets.  Also, what if there's no RTT for the new path?  Should one use the default or the previous path's RTT?

I think I like Marcus suggestion here.  The text seems to presuppose an implementation approach(a single congestion controller that's reset), opposed to specifying the correct behavior.

-- 
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/1012#pullrequestreview-95900994

---

From: janaiyengar <[email-masked]>
Date: Tue, 20 Feb 2018 13:50:51 -0800

Modified this text.

-- 
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/1012#discussion_r169471614

---

From: janaiyengar <[email-masked]>
Date: Tue, 20 Feb 2018 22:44:26 +0000 (UTC)

5760cbe  comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1012/files/440db50738ff8d9a30cc7f601b84de0954cd54b7..5760cbea406c439c387b4c23021839437cc0f9e3

---

From: janaiyengar <[email-masked]>
Date: Tue, 20 Feb 2018 22:45:53 +0000 (UTC)

Thanks folks, I've addressed comments this far. PTAL.
Ian -- happy to add a state machine, which I think is a great idea. But if we can agree on the mechanism, I'd like to consider that a next step and do it after we've got the mechanism in the draft first.

 

Fair enough, changed text.

There's no timer prescribed, which I'd like to avoid prescribing, so exponential backoff is a step after that. I was trying to avoid specifying exactly what the sender should do to detect loss of these packets,  but put a safe cap on network load.

200ms is the default recommended in the recovery draft for new connections. Since this is a new path, there's no info available about this path, hence I'm using the default.

PATH_CHALLENGE/PATH_RESPONSE is used for reachability tests, to ensure that the reverse path works fine, before migrating data. Sending Data is a bit more aggressive, where the sender is "committing" to the new path without testing it. That said, you raise a good point. I've changed some text here.

I think this is adequate for now. The section on migration linkability has the real normative text anyways.

It's a bit arbitrary, but I was shooting for something > min cwnd. Honestly, any number SGTM. Do you prefer min cwnd? 

I assumed the initial RTO period implied a default if path RTT was unknown. Happy to clarify if you think it's not clear.

-- 
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/1012#pullrequestreview-98003702

---

From: ianswett <[email-masked]>
Date: Fri, 23 Feb 2018 02:36:02 +0000 (UTC)

I have a few more small suggestions, but I think this is close to done.

> @@ -1487,8 +1487,8 @@ network.  This section describes the protocol for migrating a connection to a
 new client address.
 
 Migrating a connection to a new server address is left for future work. If a
-client receives packets from a new server address that are decryptable, the
-client MAY discard these packets.
+client receives packets in the connection from a new server address, the client

nit: I don't think "in the connection" is necessary, since you begin the sentence with "Migrating a connection..."

> @@ -1477,35 +1481,240 @@ connection if the integrity check fails with a PROTOCOL_VIOLATION error code.

If this is client specific, should it be called Client Connection Migration, at least for the time being?

> @@ -1477,35 +1481,240 @@ connection if the integrity check fails with a PROTOCOL_VIOLATION error code.

+client receives packets in the connection from a new server address, the client

nit: I don't think "in the connection" is necessary, since you begin the sentence with "Migrating a connection..."

I agree that we should avoid being specific, which is one of the reasons I'm not a fan of saying 200ms here, and would prefer text such as: "an endpoint SHOULD NOT send a PATH_CHALLENGE more frequently than it would a client INITIAL, ensuring that connection migration is no more costly to a new path than establishing a new connection."

I see why you chose 4*MSS.  In this document, 2*Min CWND seems preferable to a specific value to me.

I think it's worth clarifying that the RTO is likely based on default RTT/default RTO in this case, since if you haven't received a PATH_RESPONSE, I would expect you either have no estimate or a somewhat unverified estimate of RTT.

-- 
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/1012#pullrequestreview-98795534

---

From: Martin Thomson <[email-masked]>
Date: Fri, 23 Feb 2018 04:29:36 +0000 (UTC)

Again, I appreciate that this targets a particular use case, but describing the basic mechanisms in general terms would be appreciated.  Role agnostic descriptions of the core mechanisms would be valuable if we ever need to migrate a server, and maybe also if we wanted to do something like was proposed in #560.

Some of that has happened, but it's not very consistent.

+QUIC allows connections to survive changes to endpoint addresses (that is, IP
+address and/or port), such as those caused by a client migrating to a new
+network.  This section describes the protocol for migrating a connection to a
+new client address.
+
+Migrating a connection to a new server address is left for future work. If a
+client receives packets in the connection from a new server address, the client
+MAY discard these packets.
+
+
+### Path Validation {#migrate-validate}
+
+Path validation is used by a server to confirm the client's ownership of a
+new address and by a client to establish reachability to the server from a new
+local address.

Path validation is used by the migrating endpoint to verify reachability of its peer from a new local address.  Path validation is used by the peer to verify that the migrating endpoint is able to receive packets sent to that address.  That is, that the packets the peer receives do not carry a spoofed source address.

+Migrating a connection to a new server address is left for future work. If a
+client receives packets in the connection from a new server address, the client
+MAY discard these packets.
+
+
+### Path Validation {#migrate-validate}
+
+Path validation is used by a server to confirm the client's ownership of a
+new address and by a client to establish reachability to the server from a new
+local address.
+
+To start path validation, an endpoint sends a PATH_CHALLENGE frame containing
+a payload that is hard to guess on the path to be validated.
+
+On receiving a PATH_CHALLENGE frame, the peer MUST immediately respond by

s/the peer/an endpoint/

"immediately" here implies no ack delay or pacing.  I think that you need to explicitly say which (if either) of these is being excluded.

+
+### Path Validation {#migrate-validate}
+
+Path validation is used by a server to confirm the client's ownership of a
+new address and by a client to establish reachability to the server from a new
+local address.
+
+To start path validation, an endpoint sends a PATH_CHALLENGE frame containing
+a payload that is hard to guess on the path to be validated.
+
+On receiving a PATH_CHALLENGE frame, the peer MUST immediately respond by
+echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame.
+The PATH_RESPONSE MUST be sent on the same path: from the same local address on
+which the PATH_CHALLENGE was received, to the same remote address from which the
+PATH_CHALLENGE was received.

Is this same-path requirement solely to ensure that reachability is symmetric?  Is it to ensure that the frames can be used to measure RTT on the new path?  I think that you should say why here.

+On receiving a PATH_CHALLENGE frame, the peer MUST immediately respond by
+echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame.
+The PATH_RESPONSE MUST be sent on the same path: from the same local address on
+which the PATH_CHALLENGE was received, to the same remote address from which the
+PATH_CHALLENGE was received.
+
+The new address is not considered valid until a PATH_RESPONSE frame containing
+the same payload is received, even if the packet containing the PATH_CHALLENGE
+frame is acknowledged.
+
+The PATH_RESPONSE frame MUST be received 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.

I can't rationalize this requirement at all.  Can you explain why you think that this is necessary?

+The new address is not considered valid until a PATH_RESPONSE frame containing
+the same payload is received, even if the packet containing the PATH_CHALLENGE
+frame is acknowledged.
+
+The PATH_RESPONSE frame MUST be received 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.
+
+The PATH_RESPONSE frame MUST be received on the same local address from which
+the corresponding PATH_CHALLENGE was sent.  If a PATH_RESPONSE frame is received
+on a different local address than the one from which the PATH_CHALLENGE was
+sent, path validation is considered to have failed, even if the data matches
+that sent in the PATH_CHALLENGE.

Same as above.

I think that I agree with Ian.  We don't run timers that slowly for ICE any more anyway, and setting a fixed value (wishy-washy 2119 language notwithstanding), is a real issue.

+The endpoint MAY send additional PATH_CHALLENGE frames to handle packet loss,
+but is subject to the following limit to avoid excessive network load: an
+endpoint SHOULD NOT send more than one PATH_CHALLENGE frame in 200ms.  This
+limit is approximately equivalent to the network load due to a new connection,
+and is based on the initial Handshake Timeout defined in {{QUIC-RECOVERY}}.
+
+The endpoint MUST use fresh random data in every PATH_CHALLENGE frame so that it
+can associate the peer's response with the causative PATH_CHALLENGE.
+
+The endpoint SHOULD abandon path validation after sending some number of
+PATH_CHALLENGE frames or after some time has passed.  When setting this timer,
+implementations are cautioned that the new path could have a longer roundtrip
+time than the original. The endpoint may receive packets containing other frames
+during this period, but a PATH_RESPONSE frame with appropriate data is required
+for the path validation to succeed.

Again, the rules are likely the same as for a new handshake.  Maybe say as much for both this and the previous paragraph.

BTW, we're starting to get into a very long section.  Consider sub-headings to break things up a little.  A section on retransmission, timeouts, and path abandonment would seem to be a reasonable subject.

> +possession of its address after a period of quiescence.
+
+of the server's reachability from the new address.  Note that since

No it doesn't.  A server could lie too.

If we want to do this right, we should try to always verify paths before using them. Obviously, when an endpoint migrates without its knowledge, that's not going to happen, so we would need to make allowances for that, but this says that it's OK to just move to a new address and start sending.

This is a big departure from existing systems.  ICE always verifies.  TCP always verifies.

I think that the important distinction is choice.  A client that is moved (because the network moves or rebinds) can keep sending because it's no different to route change in the network.  The client didn't move itself, it was moved.  But if the client decides to use a different network interface (wifi vs. cellular, for example), then we're into the MUST-validate territory.  I think that you need to move that distinction up into the introductory material.

+
+
+### Initiating Connection Migration {#initiating-migration}
+
+A client MAY initiate connection migration to a new local address in one of two
+ways.
+
+The client may immediately migrate the connection by sending all packets from
+the new local address.  Receiving acknowledgments for this data serves as proof
+of the server's reachability from the new address.  Note that since
+acknowledgments may be received on any path, return reachability on the new path
+is not established. To establish return reachability on the new path, a client
+MAY concurrently initiate path validation {{migrate-validate}} on the new path.
+
+Alternatively, the client may probe for server reachability from the new local

s/may/could/

+### Initiating Connection Migration {#initiating-migration}
+
+A client MAY initiate connection migration to a new local address in one of two
+ways.
+
+The client may immediately migrate the connection by sending all packets from
+the new local address.  Receiving acknowledgments for this data serves as proof
+of the server's reachability from the new address.  Note that since
+acknowledgments may be received on any path, return reachability on the new path
+is not established. To establish return reachability on the new path, a client
+MAY concurrently initiate path validation {{migrate-validate}} on the new path.
+
+Alternatively, the client may probe for server reachability from the new local
+address first using path validation {{migrate-validate}} and migrate the
+connection to the new address at a later time.  Failure of path validation

s/at a later time/later/

+A client MAY initiate connection migration to a new local address in one of two
+ways.
+
+The client may immediately migrate the connection by sending all packets from
+the new local address.  Receiving acknowledgments for this data serves as proof
+of the server's reachability from the new address.  Note that since
+acknowledgments may be received on any path, return reachability on the new path
+is not established. To establish return reachability on the new path, a client
+MAY concurrently initiate path validation {{migrate-validate}} on the new path.
+
+Alternatively, the client may probe for server reachability from the new local
+address first using path validation {{migrate-validate}} and migrate the
+connection to the new address at a later time.  Failure of path validation
+simply means that the new local address is not usable for this connection and
+should not be fatal to the connection when alternative local addresses are

s/connection and should not be fatal [...]/connection.  Failure to validate a path does not cause the connection to end unless there are no valid alternative paths available./

> +is not established. To establish return reachability on the new path, a client
+MAY concurrently initiate path validation {{migrate-validate}} on the new path.
+
+Alternatively, the client may probe for server reachability from the new local
+address first using path validation {{migrate-validate}} and migrate the
+connection to the new address at a later time.  Failure of path validation
+simply means that the new local address is not usable for this connection and
+should not be fatal to the connection when alternative local addresses are
+available.
+
+A client migrating to a new local address SHOULD use a new connection ID for
+packets sent from that address, see {{migration-linkability}} for further
+discussion.
+
+A client MUST NOT initiate connection migration before the handshake is
+finished and the client has 1-RTT keys.

Another case where the distinction between voluntary and involuntary migration is important.

+available.
+
+A client migrating to a new local address SHOULD use a new connection ID for
+packets sent from that address, see {{migration-linkability}} for further
+discussion.
+
+A client MUST NOT initiate connection migration before the handshake is
+finished and the client has 1-RTT keys.
+
+
+### Responding to Connection Migration
+
+A server may receive a packet from a new client address at any time during the
+connection after the handshake is complete. If the packet is decryptable, the
+client may be either probing from a new address or migrating immediately, as

s/decryptable/authenticated/
s/may/could/ or s/may/might/

-Due to variations in path latency or packet reordering, packets from different
-source addresses might be reordered.  The packet with the highest packet number
-MUST be used to determine which path to use.  Endpoints also need to be prepared
-to receive packets from an older source address.
+A server MAY skip validation of a client address that it considers to be already
+valid.

Wow, this invites all sorts of speculation.  I think that you need more explanation here.

-An endpoint MUST validate that its peer can receive packets at the new address
-before sending any significant quantity of data to that address, or it risks
-being used for denial of service.  See {{migrate-validate}} for details.
+Note that the server MAY send data to an unvalidated client address, but it MUST
+protect against potential attacks as described in {{address-spoofing}} and
+{{on-path-spoofing}}.
+
+If a non-probing packet is received from a new client address but with a packet
+number that is not the largest seen thus far, the server must process the packet

s/must/can/

-An endpoint MUST validate that its peer can receive packets at the new address
-before sending any significant quantity of data to that address, or it risks
-being used for denial of service.  See {{migrate-validate}} for details.
+Note that the server MAY send data to an unvalidated client address, but it MUST
+protect against potential attacks as described in {{address-spoofing}} and
+{{on-path-spoofing}}.
+
+If a non-probing packet is received from a new client address but with a packet
+number that is not the largest seen thus far, the server must process the packet
+as usual, but it MUST ignore this client address under the assumption that it is
+not the client's most recent address.

Some explanation as to why here (the client might have migrated twice), would be good.

-An endpoint MUST validate that its peer can receive packets at the new address
-before sending any significant quantity of data to that address, or it risks
-being used for denial of service.  See {{migrate-validate}} for details.
+Note that the server MAY send data to an unvalidated client address, but it MUST
+protect against potential attacks as described in {{address-spoofing}} and
+{{on-path-spoofing}}.
+
+If a non-probing packet is received from a new client address but with a packet
+number that is not the largest seen thus far, the server must process the packet
+as usual, but it MUST ignore this client address under the assumption that it is
+not the client's most recent address.
+
+After verifying a new client address, the server SHOULD update any address
+validation tokens ({{address-validation}}) that it has issued to the client if
+those are no longer valid based on the changed address.

What does update mean?  Does that mean sending them again?

Everything that Ian said, except that I don't understand why 2xMinCWND.  Seems equally arbitrary.  MinCWND on the assumption of a default RT[TO] would be more defensible.

+After successful validation of the client's new address, the server SHOULD reset
+its congestion controller and roundtrip time estimator prior to sending any
+further non-probing packets.
+
+An endpoint MUST NOT restore its send rate unless it is reasonably sure that the
+path is the same as the previous path.  For instance, a change in the client's
+port number is likely indicative of a rebinding in a middlebox and not a
+complete change in path.  This determination likely depends on heuristics, which
+could be imperfect; if the new path capacity is significantly reduced,
+ultimately this relies on the congestion controller responding to congestion
+signals and reducing send rates appropriately.
+
+There may be apparent reordering at the receiver when an endpoint sends data and
+probes from/to multiple addresses during the migration period, since the two
+resulting paths may have different rountrip times.  A receiver of packets on

roudtrip

> @@ -1735,9 +1829,9 @@ state to draining, but it otherwise has no impact.
+new address since the address is not validated (see {{migrate-validate}}). A

s/since/until
s/not //

-- 
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/1012#pullrequestreview-98806374

---

From: Mike Bishop <[email-masked]>
Date: Sun, 25 Feb 2018 14:19:37 +0000 (UTC)

MikeBishop commented on this pull request.

I also found possibly-stale comments.  Submitting these, then I'll do another read-through for current state.

I feel like these two paragraphs could be combined.

+An on-path attacker could cause a spurious connection migration by capturing and
+forwarding a packet such that it arrives before the legitimate copy of that
+packet.  Such a packet will appear to be a legitimate connection migration and
+the legitimate copy will be dropped as a duplicate. After a spurious migration,
+validation of the source address will fail because the entity at the source
+address does not have the necessary cryptographic keys to read or respond to the
+PATH_CHALLENGE frame that is sent to it, even if it wanted to.
+
+To protect the connection from failing due to such a spurious migration, the
+server MUST revert to using the last validated client address when validation of
+a new client address fails. If the server has no state about the last validated
+client address, it MUST close the connection silently and discard any further
+packets received from the client for this connection.
+
+We note that receipt of packets with higher packet numbers from the legitimate

We've mostly avoided using the first-person plural in these specs.  Can we rephrase?  Simply saying that "Receipt of packets...." should be sufficient.

And the same below for servers, as well.

round trip

-- 
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/1012#pullrequestreview-96603384

---

From: Mike Bishop <[email-masked]>
Date: Sun, 25 Feb 2018 14:34:16 +0000 (UTC)

Not really -- we've already said that the tuple can't change during the handshake, so involuntary can be treated the same way as a violation of this requirement by the server.

I understand the desire to leave implementations room to explore the envelope, but I agree this is a bit vague.  I'm assuming this is mostly intended to be read as "same IP, different port" or "return to an IP address the client had used/validated previously" (e.g. cellular, migrated to Wi-Fi, lost Wi-Fi).

Sending new ones that validate the new address.

-- 
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/1012#discussion_r170454680