A more complete connection migration #1012

janaiyengar · 2017-12-13T00:16:04Z

Closes #880.

This PR describes a more complete connection migration design. Among other small bits, this design includes the following:

Allow a client to probe alternate paths without having to use them for data.
Ensure that a server validates client ownership of a new address.

Rewrite of Connection Migration logic

martinthomson

Thanks for writing this up. It's a pretty solid design overall (not nearly as prescriptive as ICE, which is good). I think that there are a number of details that need more meat on them to support the new features that this adds. I've tried to highlight them.

I also think that the structure of this is unfortunate. I would prefer to see a generic description of path validation that is role-agnostic. I realize that we do have a fundamentally asymmetric protocol and I'm not suggesting that this be perfectly symmetric, but this is unnecessarily asymmetric and the structure you have chosen has what appears to be errors in symmetry. There are some generic requirements that are only in one or other of the client or server sections where they should (at least from my brief review) be shared. Some of the differences seem like errors, but they could be intentional. If there are intentional differences (like the fact that you have chosen to allow only clients to migrate here), then those asymmetries should be more explicit.

There needs to be a more explicit mention of NEW_CONNECTION_ID in relation to the client-initiated path probe. If the client uses a new connection ID for that probe, what does that do to packet numbers on the existing path? That could be a hard problem given the current design (this is something I hope to address with packet number obfuscation/encryption, so you might decide not to address that and instead leave a TODO for packet numbers).

Finally, I'm not quite done with reviewing this. I want to do a gap analysis between this and STUN to see if this is a reasonable substitute (because you are effectively replicating STUN capabilities now, albeit in a more integrated and minimal fashion).

martinthomson · 2017-12-13T00:47:16Z

draft-ietf-quic-transport.md

+
+PATH_CHALLENGE ({{frame-path-challenge}}) and PATH_RESPONSE
+({{frame-path-response}}) frames MAY be used for validating that an endpoint
+owns an address, or to verify the PMTU to/from an address.


This section doesn't talk about verifying PMTU from.

The client is verifying PMTU from its new address

I mean, this talks about verification toward the peer (outward bound), not from the peer (inbound).

martinthomson · 2017-12-13T00:49:19Z

draft-ietf-quic-transport.md

+
+### Client Behavior {#migration-client}
+
+A client triggers connection migration to a new address by sending a


I hope that this isn't a trigger for migration. The path verification might be a prerequisite for a conscious migration by a client, but it's not what we should be using to trigger the switch on the server end.

Oops -- yes it doesn't. Will fix.

Perhaps "When a client intends to migrate to a new address, it prepares for the migration by...."

We really need to separate involuntary NAT rebinding and voluntary migration.

martinthomson · 2017-12-13T00:51:31Z

draft-ietf-quic-transport.md

+failure.
+
+
+#### Responding to a Server's Validation


I would prefer that we talk about the different types of migration rather than have this talk about client and server behaviour separately. Having this text here is hard to contextualize because it comes before any of the text about what might have happened to cause it to be necessary.

Also, I think that initiating and responding to validation is a generic thing that could be described independent of the different use cases/scenarios.

So I chose to structure it like this because it's easier to see how to implement such a thing. If it's useful to contextualize, I can add more text in the common text up at the top of this section.

Validation can be described separately, but in this description, it's only used for the server to validate a client's new address.

martinthomson · 2017-12-13T00:52:55Z

draft-ietf-quic-transport.md

+A client may receive a PATH_CHALLENGE from a server that is validating the
+client's ownership of its address, as described in {{migration-server}}. The
+client MUST respond to this frame by echoing the data from the server's
+PATH_CHALLENGE frame in a PATH_RESPONSE frame.


This doesn't say what path the response follows. It's important here to note that the client doesn't need to change its addressing info in any way when responding.

martinthomson · 2017-12-13T00:54:26Z

draft-ietf-quic-transport.md

+{{migration-server}}).
+
+A client migrating to a new network might use a new connection ID for packets
+sent from the new address, see {{migration-linkability}} for further discussion.


There's nothing here about the use of connection ID and packet numbers for the probes on the new path.

Probes are just packets, and are not treated any differently, so they follow the same rules for connection ID and packet numbers as specified in the linkability section.

There's an assumption in the current design that connection IDs are used in series. If a client wants to send on a new path, then it will want to use a new connection ID. But it will then send on the original path, and that will need a different connection ID. It can't use the original connection ID, or the one that it used on the path it was probing with the current design.

With the potential need for multiple probes on the new path, interleaved with continuing packets on the old path, this will consume far more connection IDs than our current design really allows for. Or it will be linkable.

This is where I think packet number encryption/obfuscation will help. It will allow us to switch back to the old connection ID without having to worry about gaps in packet numbers. I think that we will need to fix that.

That doesn't make me think that this is a broken design, only that it reveals that our current design for unlinkability across paths is not suitable any more.

martinthomson · 2017-12-13T00:55:30Z

draft-ietf-quic-transport.md

+The server sends the PATH_RESPONSE in a packet that is padded to no more than
+the size of the client's packet carrying the PATH_CHALLENGE.  The server SHOULD
+pad the packet to the same size as the client's packet, unless the server has
+reasonable assurance of a smaller PMTU.


Why does the server pad its PATH_RESPONSE, but the client does not? Also, this smaller PMTU seems confusing, even if it isn't explicitly wrong. We definitely need a 1200 in here somewhere.

Security consideration: if we allow PATH RESPONSE packets to be larger than the PATH CHALLENGE packet that triggered them, we enable a reflection DOD attack.

martinthomson · 2017-12-13T01:00:04Z

draft-ietf-quic-transport.md

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


I think that this can be simpler. Any packet containing PATH_CHALLENGE is ignored.

You do allow STREAM frames with that packet in earlier text (and STREAM frames aren't a terrible waste of octets, so I can imagine people using the bandwidth for that rather than padding, even if the probability of loss is that much greater). But this text would cause the recipient to latch.

martinthomson · 2017-12-13T01:01:04Z

draft-ietf-quic-transport.md

+subject to the congestion controller's limits.
+
+A PATH_CHALLENGE frame used for validation MUST contain at least 12 randomly
+generated octets {{?RFC4086}}, making the payload sufficiently hard to guess.


This is a generic requirement, but you have it here in the server-specific section.

Seconded. Shouldn't this simply be in the definition of the PATH_CHALLENGE frame?

martinthomson · 2017-12-13T01:02:05Z

draft-ietf-quic-transport.md

+
+Data:
+
+: This variable-length field contains arbitrary data.


Can we make this a fixed length?

We already have a minimum. Is there a scenario in which a server would want it to be longer?

Maybe look at it this way. We have a certain dependency on the connection ID for path verification during the handshake and that is only 64 bits. So, maybe we can reasonably say that 64 bits is enough here as well.

martinthomson · 2017-12-13T01:02:59Z

draft-ietf-quic-transport.md

-FRAME_ERROR, indicating the PONG frame (that is, 0x10d).  If the content of a
-PONG frame does not match the content of a PING frame previously sent by the
-endpoint, the endpoint MAY generate a connection error of type UNSOLICITED_PONG.
+A PATH_RESPONSE frame MUST NOT elicit acknowledgements.


I don't think that this is a necessary requirement. Given that it's the packet that generates the acknowledgments, that PADDING causes ACKs to be sent, and that this will never fill an entire packet, I think that you can drop this line.

erickinnear · 2017-12-13T03:22:40Z

draft-ietf-quic-transport.md

@@ -3841,7 +3941,8 @@ Issue and pull request numbers are listed with a leading octothorp.

 ## Since draft-ietf-quic-transport-08

-No significant changes.
+- Added PATH_CHALLENGE and PATH_RESPONSE frames, removed PING with Data, removed
+  PONG frame and rewrote connection migration (#000)


This should be filled in with the correct number now

MikeBishop

Thanks for the write-up -- I think it helps move in the right direction. I agree with Martin, though -- you have a lot more asymmetry here than seems necessary. We also have issues open around server-side migration, and this doesn't allow for that, even though it seems like it could do so with relatively little additional work.

MikeBishop · 2017-12-14T00:13:02Z

draft-ietf-quic-transport.md

+A server validates a client's address by sending a PATH_CHALLENGE frame
+containing a payload that is hard to guess to that address.  The server
+considers the address to be valid when a PATH_RESPONSE frame containing the same
+payload is received from the client.


Does it have to come back from a particular address? Either way, perhaps say so.

MikeBishop · 2017-12-14T00:14:22Z

draft-ietf-quic-transport.md

+
+### Client Behavior {#migration-client}
+
+A client triggers connection migration to a new address by sending a


Perhaps "When a client intends to migrate to a new address, it prepares for the migration by...."

MikeBishop · 2017-12-14T00:15:27Z

draft-ietf-quic-transport.md

+### Client Behavior {#migration-client}
+
+A client triggers connection migration to a new address by sending a
+PATH_CHALLENGE as a probe or by switching to sending all packets to the new


to => from. If you take the proposed change above, perhaps expand this to talk about unintended/unexpected address changes, in which case the client will just keep sending from whatever address it has to work with.

MikeBishop · 2017-12-14T00:15:45Z

draft-ietf-quic-transport.md

+A client triggers connection migration to a new address by sending a
+PATH_CHALLENGE as a probe or by switching to sending all packets to the new
+address. The client SHOULD do PMTU verification before considering migration
+complete. The client also participates in an address validation that the server


MikeBishop · 2017-12-14T00:16:32Z

draft-ietf-quic-transport.md

+
+#### Verifying the PMTU
+
+When the client intends to use a new local address, it MAY establish server


Or realizes that it is using a new path? But how does it do that, based on receipt of a PATH_CHALLENGE from the server?

MikeBishop · 2017-12-14T00:39:16Z

draft-ietf-quic-transport.md

-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


I know this isn't new text, but why "as though the address were" rather than "since the address is not"?

Good point, fixed.

MikeBishop · 2017-12-14T00:40:33Z

draft-ietf-quic-transport.md

+
+Endpoints can use PATH_CHALLENGE frames (type=0x0e) to check reachability to the
+peer, to verify a new path's PMTU, and to perform address validation during
+connection migration.


Is PATH_CHALLENGE useful for PMTU validation once the address is known to be good? Why couldn't you simply rely on ACKs to tell you whether the packet got through or not?

Yeah, I think that the requirement for a minimum size on probes is a requirement on the probing packet, not a property of any particular frame that it contains.

MikeBishop · 2017-12-14T00:41:21Z

draft-ietf-quic-transport.md

+
+Data:
+
+: This variable-length field contains arbitrary data.


We already have a minimum. Is there a scenario in which a server would want it to be longer?

MikeBishop · 2017-12-14T00:41:58Z

draft-ietf-quic-transport.md

+
+
+The sender of this frame MUST include at least one octet of data in the Data
+field.


A larger minimum is provided above (eight octets, I think?).

MikeBishop · 2017-12-14T00:43:10Z

draft-ietf-quic-transport.md

+PATH_CHALLENGE frame containing an empty payload MUST generate a connection
+error of type FRAME_ERROR, indicating the PATH_CHALLENGE frame (that is, 0x0e).
+
+A PATH_CHALLENGE frame MUST NOT elicit acknowledgements; the corresponding


Frames don't get acknowledged; packets do. Does this mean that a packet containing a PATH_CHALLENGE MUST NOT be acknowledged? That's going to play merry hob with the loss recovery if you start putting actual data in there (padding with STREAM).

But frames do elicit acknowledgments. Generally. ACK doesn't. The "MUST NOT" isn't appropriate; it seems like the intent is to say that it doesn't elicit acknowledgment (that is, it's not an interoperability requirement, it's just a property).

I don't think that it makes sense to have special acknowledgment rules for PATH_CHALLENGE though. Acknowledging PATH_CHALLENGE doesn't contribute to path validation, but on the other hand explicitly excluding it creates another exception. I don't see any reason to suppress acknowledgments in this case.

I have a feeling that this text about the composition of challenge response is repeated multiple times. Can we simplify?

janaiyengar

@martinthomson : I'm going to try to unify the mechanisms and make this client/server agnostic, which might resolve some issues. We did that because it was easier to reason about in the earlier designs, but the current version actually lends itself nicely to symmetry, I think. At any rate, let me try that first.

janaiyengar · 2017-12-13T06:51:53Z

draft-ietf-quic-transport.md

+
+### Client Behavior {#migration-client}
+
+A client triggers connection migration to a new address by sending a


Oops -- yes it doesn't. Will fix.

janaiyengar · 2017-12-13T06:53:02Z

draft-ietf-quic-transport.md

+{{migration-server}}).
+
+A client migrating to a new network might use a new connection ID for packets
+sent from the new address, see {{migration-linkability}} for further discussion.


Probes are just packets, and are not treated any differently, so they follow the same rules for connection ID and packet numbers as specified in the linkability section.

janaiyengar · 2017-12-13T06:57:10Z

draft-ietf-quic-transport.md

+failure.
+
+
+#### Responding to a Server's Validation


So I chose to structure it like this because it's easier to see how to implement such a thing. If it's useful to contextualize, I can add more text in the common text up at the top of this section.

Validation can be described separately, but in this description, it's only used for the server to validate a client's new address.

huitema · 2017-12-26T00:12:12Z

I have mixed feelings about this. First, I am not sure that this belongs to the frame layer. The path challenge is in many ways similar to a client initial packet. It requires the same kind of padding, for the same reason. And it carries similar content restrictions such as "no other frame allowed". A new packet type might be more appropriate than a frame type.

Second, this probably requires a three ways handshake, not just a question response. And it would be better served with a symmetric structure --
Maybe "your nonce, my nonce", so as to allow symmetry.

Then, there maybe a need for more attributes than nonces, especially if we want to handle NAT rebinding. Like, echoing the address from where this was sent.

huitema · 2017-12-26T01:27:50Z

I guess my uneasiness stems from the PR's scope - supporting both involuntary transition like NAT remapping and voluntary transition like make before break. The latter addresses maybe 80% of the multi path issues, and I don't like addressing that without completing the multi path work. Sine full multipath is indeed out of scope for V1, how about simplifying drastically and only addressing involuntary NAT rebinding?

huitema

I think this is not quite ready yet. We should separate the NAT Rebinding and the network migration scenario. We should be explicit about the "per path" nature of congestion and PMTU. We should consider encrypting the sequence number.

huitema · 2017-12-28T00:50:11Z

draft-ietf-quic-transport.md

+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}}).
+


The connection ID SHOULD change during the connection.

In fact, it is debatable whether the client should engage in connection migration if the server has not provided new connection identifiers via the use of NEW_CONNECTION_ID frames. Maybe it should use close/resume instead.

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

I'd prefer:

The connection ID could change over the lifetime of a connection, especially in response to connection migration (cite). NEW_CONNECTION_ID frames (cite) are used to provide new values.

huitema · 2017-12-28T00:53:34Z

draft-ietf-quic-transport.md

+QUIC connections are identified by 64-bit connection IDs. QUIC's connection IDs
+allow connections to survive changes to the client's address (client's IP
+address and/or port), such as those caused by a client migrating to a new
+network or a NAT rebinding changing the client's public address.


I think we should really distinguish between NAT rebinding and connection migration. The clients can generally not anticipate that a NAT rebinding will occur, and are thus likely to continue using the same connection ID as before the rebinding. In contrast, clients can generally control the decision to start migration to a new network, and should use a new connection ID when doing that.

huitema · 2017-12-28T00:58:42Z

draft-ietf-quic-transport.md

+
+### Client Behavior {#migration-client}
+
+A client triggers connection migration to a new address by sending a


We really need to separate involuntary NAT rebinding and voluntary migration.

huitema · 2017-12-28T01:02:11Z

draft-ietf-quic-transport.md

+The server sends the PATH_RESPONSE in a packet that is padded to no more than
+the size of the client's packet carrying the PATH_CHALLENGE.  The server SHOULD
+pad the packet to the same size as the client's packet, unless the server has
+reasonable assurance of a smaller PMTU.


Security consideration: if we allow PATH RESPONSE packets to be larger than the PATH CHALLENGE packet that triggered them, we enable a reflection DOD attack.

huitema · 2017-12-28T01:03:06Z

draft-ietf-quic-transport.md

+received for a prior one.
+
+Servers MUST ignore a PATH_CHALLENGE frame from a client that is carried in a
+packet smaller than 1200 octets in size.


Yes. Security consideration as to why?

huitema · 2017-12-28T01:04:41Z

draft-ietf-quic-transport.md

+a denial of service attack against an unsuspecting victim.
+
+When validation of an address fails, the server SHOULD revert back to using the
+last validated client address, absent which the server MUST close the connection


Basically, starting a new path should reset the congestion control algorithm to ts starting condition. Just say so.

huitema · 2017-12-28T01:07:30Z

draft-ietf-quic-transport.md

+For instance, an endpoint may run a separate alarm when a PATH_CHALLENGE is
+sent, which is disarmed when the corresponding PATH_RESPONSE is received. If the
+alarm fires before the PATH_RESPONSE is received, the endpoint might send a new
+PATH_CHALLENGE, and restart the alarm, but for a longer period of time.


I see the discussion of the congestion control window, but I do not see an equivalent discussion of flow control and the MAX_DATA frame. Yet if the client migrates to a slow connection, MAX_DATA is going to be way too large. Where is that discussed?

huitema · 2017-12-28T01:11:10Z

draft-ietf-quic-transport.md

@@ -1541,112 +1731,6 @@ number. "packet_number_secret" is derived from the TLS key exchange,
 as described in Section 5.6 of {{QUIC-TLS}}.


The packet-number-gap trick only works if both the client and the server do it, and if both refrain from sending any packet on the old connection in parallel with the new connection. That seems very fragile. We should really consider encrypting the packet sequence number.

Note that all this discussion only applies to voluntary migration. It does not apply to NAT rebinding. If the client cannot anticipate the NAT rebinding, it will not be able to switch to a new connection ID or to insert a gap in the sequence numbers.

See issue #1034. The packet number gap is a complex mechanism that does not actually protect privacy, because client and server apply the same gap.

I agree with Christian, this seems fragile, but that's for another issue and discussion

huitema · 2017-12-28T01:13:25Z

draft-ietf-quic-transport.md

+PATH_CHALLENGE frame containing an empty payload MUST generate a connection
+error of type FRAME_ERROR, indicating the PATH_CHALLENGE frame (that is, 0x0e).
+
+A PATH_CHALLENGE frame MUST NOT elicit acknowledgements; the corresponding


I have a feeling that this text about the composition of challenge response is repeated multiple times. Can we simplify?

huitema · 2017-12-28T01:15:36Z

draft-ietf-quic-transport.md

+generate a connection error of type FRAME_ERROR, indicating the PATH_RESPONSE
+frame (that is, 0x0e).  If the content of a PATH_RESPONSE frame does not match
+the content of a PATH_CHALLENGE frame previously sent by the endpoint, the
+endpoint MAY generate a connection error of type UNSOLICITED_PATH_RESPONSE.


Did we say before that path challenges do not need to be acked? Presumably, some servers will want to repeat them. Should the repeated challenge have exactly the same content as the original challenge?

ianswett

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

ianswett · 2018-02-23T02:21:16Z

draft-ietf-quic-transport.md

@@ -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..."

ianswett · 2018-02-23T02:23:47Z

draft-ietf-quic-transport.md

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

 ## Connection Migration {#migration}


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

SGTM. done.

I'm not seeing the change.

...except that it isn't. The title of the section is still "Connection Migration."

ianswett · 2018-02-23T02:24:57Z

draft-ietf-quic-transport.md

+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


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

That's a different sentence... I think it's still useful because if the packets don't belong to this connection, the rest of the sentence doesn't apply.

I'm in favor of Ian's change, because if packets don't map to a connection they'll be discarded anyway. The extra words just sound awkward. However, it's not technically incorrect, so this is purely wordsmithing.

Ok, removed.

ianswett · 2018-02-23T02:28:20Z

draft-ietf-quic-transport.md

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


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

ianswett · 2018-02-23T02:31:19Z

draft-ietf-quic-transport.md

+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


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.

martinthomson

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.

martinthomson · 2018-02-23T03:52:04Z

draft-ietf-quic-transport.md

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

Done (with some mods).

martinthomson · 2018-02-23T03:53:50Z

draft-ietf-quic-transport.md

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

Ack delay does not apply, since it's not an ack that's being sent. Though this made me realize that I hadn't said anything about limiting the number of responses, so I've added some text (and moved some text around) limiting the rate at which responses are sent.

martinthomson · 2018-02-23T03:55:23Z

draft-ietf-quic-transport.md

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

It was meant to establish reachability in both directions. I've written it down now.

martinthomson · 2018-02-23T03:56:32Z

draft-ietf-quic-transport.md

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

Perhaps this needs to be more explicitly stated, but bi-directional reachability is what is desired when doing connection migration to a new address. The test is incomplete if it only tests one direction. I've also added a sentence up above making this explicit.

Worth noting that one-way reachability might be a thing once we get to multipath. If client->server has two valid paths, but server->client only one, so be it. But I don't object to saying path validation has to test both directions when we're only doing migration.

Yes, that would be quite a different deal. You'd want to be very careful when thinking about reachability in the multipath case, but as you say, that's for a different day.

I'd agree that requiring bi-directional reachability in this version is a good step, we can always remove that when defining true multipath.

martinthomson · 2018-02-23T03:56:43Z

draft-ietf-quic-transport.md

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

martinthomson · 2018-02-23T04:14:13Z

draft-ietf-quic-transport.md

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

added some text

martinthomson · 2018-02-23T04:15:42Z

draft-ietf-quic-transport.md

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

Sending new ones that validate the new address.

updated text

martinthomson · 2018-02-23T04:22:56Z

draft-ietf-quic-transport.md

+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


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.

martinthomson · 2018-02-23T04:25:37Z

draft-ietf-quic-transport.md

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


the 'd' is redundant anyways, nobody pronounces it :-)
... though fixing english is not in charter, so fixing text

martinthomson · 2018-02-23T04:27:26Z

draft-ietf-quic-transport.md

-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 since the address is not validated (see {{migrate-validate}}). A


s/since/until
s/not //

Updated PR

MikeBishop

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

MikeBishop · 2018-02-14T18:16:50Z

draft-ietf-quic-transport.md

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


I feel like these two paragraphs could be combined.

MikeBishop · 2018-02-14T18:39:42Z

draft-ietf-quic-transport.md

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

MikeBishop · 2018-02-14T18:40:51Z

draft-ietf-quic-transport.md

+
+A client SHOULD reset its congestion controller and roundtrip time estimator
+prior to sending any non-probing packets from a new local address.
+


And the same below for servers, as well.

MikeBishop · 2018-02-14T18:41:32Z

draft-ietf-quic-transport.md

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


janaiyengar

Addressed comments, PTAL.

janaiyengar · 2018-02-28T23:21:16Z

draft-ietf-quic-transport.md

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

 ## Connection Migration {#migration}


SGTM. done.

janaiyengar · 2018-02-28T23:23:16Z

draft-ietf-quic-transport.md

+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


That's a different sentence... I think it's still useful because if the packets don't belong to this connection, the rest of the sentence doesn't apply.

janaiyengar · 2018-02-28T23:29:18Z

draft-ietf-quic-transport.md

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


Done (with some mods).

janaiyengar · 2018-02-28T23:32:33Z

draft-ietf-quic-transport.md

+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


Ack delay does not apply, since it's not an ack that's being sent. Though this made me realize that I hadn't said anything about limiting the number of responses, so I've added some text (and moved some text around) limiting the rate at which responses are sent.

janaiyengar · 2018-03-02T22:01:12Z

draft-ietf-quic-transport.md

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


It was meant to establish reachability in both directions. I've written it down now.

janaiyengar · 2018-03-07T02:00:44Z

draft-ietf-quic-transport.md

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


updated text

janaiyengar · 2018-03-07T02:28:32Z

draft-ietf-quic-transport.md

+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


added text and set the rate to min cwnd per rto.

janaiyengar · 2018-03-07T02:29:01Z

draft-ietf-quic-transport.md

+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


janaiyengar · 2018-03-07T02:33:12Z

draft-ietf-quic-transport.md

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


the 'd' is redundant anyways, nobody pronounces it :-)
... though fixing english is not in charter, so fixing text

janaiyengar · 2018-03-07T02:34:19Z

draft-ietf-quic-transport.md

-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 since the address is not validated (see {{migrate-validate}}). A


MikeBishop

Looking good. Most of these are strictly wordsmithing.

MikeBishop · 2018-03-07T16:27:35Z

draft-ietf-quic-transport.md

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

 ## Connection Migration {#migration}


...except that it isn't. The title of the section is still "Connection Migration."

MikeBishop · 2018-03-07T16:29:19Z

draft-ietf-quic-transport.md

+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


I'm in favor of Ian's change, because if packets don't map to a connection they'll be discarded anyway. The extra words just sound awkward. However, it's not technically incorrect, so this is purely wordsmithing.

MikeBishop · 2018-03-07T16:31:53Z

draft-ietf-quic-transport.md

+An 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 a PATH_CHALLENGE more frequently than it would a client
+INITIAL, ensuring that connection migration is no more load on a new path than


Packet names are title-cased, not all-caps. Also, I'd drop the colon lead-up.

...but to avoid excessive network load, an endpoint SHOULD NOT... an Initial packet. This ensures that....

MikeBishop · 2018-03-07T16:33:18Z

draft-ietf-quic-transport.md

+
+On receiving a PATH_CHALLENGE frame, an endpoint MUST respond immediately by
+echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame,
+with the following stipulation.  Since a PATH_CHALLENGE may be sent from a


"might be" - there's no permission involved here.

Ah, right. I'm always confused between may and might. This is a good way to think about it. Done.

MikeBishop · 2018-03-07T16:34:04Z

draft-ietf-quic-transport.md

+Path validation tests both directions of a path.  To ensure reachability in both
+directions, the PATH_RESPONSE MUST be sent on the same path as the triggering
+PATH_CHALLENGE: from the same local address on which the PATH_CHALLENGE was
+received, to the same remote address from which the PATH_CHALLENGE was received.


and port, I presume?

an address is defined above as IP and/or port

MikeBishop · 2018-03-07T16:36:09Z

draft-ietf-quic-transport.md

+
+### Initiating Connection Migration {#initiating-migration}
+
+A client MAY initiate connection migration to a new local address in one of two


This "MAY" seems superfluous, particularly since the first way also has a MAY. I'd either lower-case it, "can", or "A client initiates...." Also, I don't know that I'd frame these as two "ways" of migrating. Ultimately, the client migrates by sending data from the new address/port. A client MAY probe for reachability first, if it has the opportunity.

Good suggestions. I've made restructured a bit so that it flows as you suggest instead of "two ways".

MikeBishop · 2018-03-07T16:40:47Z

draft-ietf-quic-transport.md

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


How does this tie in to the closure/draining states described elsewhere? Does the server enter draining? Can it send Stateless Reset?

Good q. I've changed it so that the server basically discards all connection state, leaving subsequent packets to be treated generically. That is, the server could send Stateless Resets in response. I think this is reasonable.

janaiyengar

Thanks, Mike. Addressed your comments, PTAL.

janaiyengar · 2018-03-07T19:19:41Z

draft-ietf-quic-transport.md

+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


Ok, removed.

janaiyengar · 2018-03-07T19:23:07Z

draft-ietf-quic-transport.md

+An 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 a PATH_CHALLENGE more frequently than it would a client
+INITIAL, ensuring that connection migration is no more load on a new path than


janaiyengar · 2018-03-07T19:23:59Z

draft-ietf-quic-transport.md

+
+On receiving a PATH_CHALLENGE frame, an endpoint MUST respond immediately by
+echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame,
+with the following stipulation.  Since a PATH_CHALLENGE may be sent from a


Ah, right. I'm always confused between may and might. This is a good way to think about it. Done.

janaiyengar · 2018-03-07T19:24:37Z

draft-ietf-quic-transport.md

+Path validation tests both directions of a path.  To ensure reachability in both
+directions, the PATH_RESPONSE MUST be sent on the same path as the triggering
+PATH_CHALLENGE: from the same local address on which the PATH_CHALLENGE was
+received, to the same remote address from which the PATH_CHALLENGE was received.


an address is defined above as IP and/or port

janaiyengar · 2018-03-07T19:25:45Z

draft-ietf-quic-transport.md

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


Yes, that would be quite a different deal. You'd want to be very careful when thinking about reachability in the multipath case, but as you say, that's for a different day.

janaiyengar · 2018-03-07T19:47:21Z

draft-ietf-quic-transport.md

+
+### Initiating Connection Migration {#initiating-migration}
+
+A client MAY initiate connection migration to a new local address in one of two


Good suggestions. I've made restructured a bit so that it flows as you suggest instead of "two ways".

janaiyengar · 2018-03-07T20:02:01Z

draft-ietf-quic-transport.md

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


Good q. I've changed it so that the server basically discards all connection state, leaving subsequent packets to be treated generically. That is, the server could send Stateless Resets in response. I think this is reasonable.

erickinnear

Latest changes look great! A few minor nits and other comments, but nothing major.

erickinnear · 2018-03-07T20:21:48Z

draft-ietf-quic-transport.md

+Initial packet, ensuring that connection migration is no more load on a new path
+than establishing a new connection.
+
+The endpoint MUST use fresh random data in every PATH_CHALLENGE frame so that it


Here we indicate that this should be random data, but above we just said "hard to guess" -- I know we took out the note about what's considered hard to guess, but perhaps we should still include a note in the above paragraph that it's random?

I've added "random" to the sentence above

erickinnear · 2018-03-07T20:25:55Z

draft-ietf-quic-transport.md

+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'd agree that requiring bi-directional reachability in this version is a good step, we can always remove that when defining true multipath.

erickinnear · 2018-03-07T20:27:54Z

draft-ietf-quic-transport.md

+time than the original.  Again, to avoid excessive network load, an endpoint
+SHOULD NOT send more PATH_CHALLENGE frames than it would a client INITIAL,
+ensuring that connection migration is no more load on a new path than
+establishing a new connection.


Good to have this reminder so everything is in one place when implementing

erickinnear · 2018-03-07T20:28:34Z

draft-ietf-quic-transport.md

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


Does this mean packets on the new path or on the old path? What are we trying to indicate here?

I meant to say other packets might be received on the new path, but they are not adequate for validation. Fixed up sentence.

erickinnear · 2018-03-07T20:30:01Z

draft-ietf-quic-transport.md

+
+If it has the opportunity, a client MAY probe for server reachability from a
+new local address using path validation {{migrate-validate}} prior to migrating
+the connection to it.  Failure of path validation simply means that the new


nit: to it -> to the new local address

erickinnear · 2018-03-07T20:44:44Z

draft-ietf-quic-transport.md

+performing with other addresses on the expectation that those validations are
+likely to fail.  Abandoning path validation primarily means ceasing subsequent
+transmissions of the PATH_CHALLENGE frame.  An endpoint MUST ignore any
+subsequently received PATH_RESPONSE frames from abandoned addresses.


This could mean the client ends up spending some additional time if it wants to re-establish reachability on the other addresses / maintain that ahead of time (like is best for performance). Probably okay, but worth considering.

Ah, I see below that this allows us to avoid issues where someone tries to migrate us and we grab it back. Looks fine in that case.

Hm. I don't think we need a MUST ignore here. Changing to a MAY.

erickinnear · 2018-03-07T20:54:46Z

draft-ietf-quic-transport.md

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


I worry that people may be confused by the perceived conflict between this and:

A server MAY skip validation of a client address if it has been seen recently or if the server has reasonable certainty that the new address is the result of a NAT rebinding.

Can we resolve that somehow?

Perhaps we could say above:

A server MAY consider validation to be complete for a client address that has been seen recently or if the server has reasonable certainty that the new address is the result of a NAT rebinding.

Or something to that effect (maybe A server MAY deem a client address to be valid to echo the next paragraph here).

Good point. I've rephrased some things here and added an explicit sentence calling out that a server SHOULD NOT apply this limit when it is not validating the client address.

erickinnear · 2018-03-07T21:00:44Z

draft-ietf-quic-transport.md

+its congestion controller and round-trip 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


Nit: restore -> return to ?

fixed up sentence too

erickinnear · 2018-03-07T21:02:55Z

draft-ietf-quic-transport.md

@@ -1541,112 +1731,6 @@ number. "packet_number_secret" is derived from the TLS key exchange,
 as described in Section 5.6 of {{QUIC-TLS}}.


I agree with Christian, this seems fragile, but that's for another issue and discussion

janaiyengar

Thanks, Eric, PTAL.

janaiyengar · 2018-03-08T01:09:25Z

draft-ietf-quic-transport.md

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


I meant to say other packets might be received on the new path, but they are not adequate for validation. Fixed up sentence.

janaiyengar · 2018-03-08T01:16:06Z

draft-ietf-quic-transport.md

+
+If it has the opportunity, a client MAY probe for server reachability from a
+new local address using path validation {{migrate-validate}} prior to migrating
+the connection to it.  Failure of path validation simply means that the new


janaiyengar · 2018-03-08T01:46:55Z

draft-ietf-quic-transport.md

+performing with other addresses on the expectation that those validations are
+likely to fail.  Abandoning path validation primarily means ceasing subsequent
+transmissions of the PATH_CHALLENGE frame.  An endpoint MUST ignore any
+subsequently received PATH_RESPONSE frames from abandoned addresses.


Hm. I don't think we need a MUST ignore here. Changing to a MAY.

janaiyengar · 2018-03-08T02:14:33Z

draft-ietf-quic-transport.md

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


Good point. I've rephrased some things here and added an explicit sentence calling out that a server SHOULD NOT apply this limit when it is not validating the client address.

janaiyengar · 2018-03-08T02:17:20Z

draft-ietf-quic-transport.md

+its congestion controller and round-trip 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


fixed up sentence too

ianswett

Small editorial nits, but the content LGTM.

ianswett · 2018-03-07T14:57:20Z

draft-ietf-quic-transport.md

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

 ## Connection Migration {#migration}


I'm not seeing the change.

ianswett · 2018-03-08T02:25:35Z

draft-ietf-quic-transport.md

-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.
+Path validation is used by the migrating endpoint to verify reachability of
+its peer from a new local address. Path validation is also used by the peer to


nit:s/its/the or a

ianswett · 2018-03-08T02:32:09Z

draft-ietf-quic-transport.md

+An 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 round-trip
+time than the original.  Again, to avoid excessive network load, an endpoint


nit: "Again," is unnecessary.

ianswett · 2018-03-08T02:36:38Z

draft-ietf-quic-transport.md

@@ -3599,7 +3629,7 @@ entire round trip.
 For smooth operation of the congestion controller, it is generally considered
 best to not let the sender go into quiescence if avoidable.  To avoid blocking a
 sender, and to reasonably account for the possibiity of loss, a receiver should
-send a MAX_DATA or MAX_STREAM_DATA frame at least two roundtrips before it
+send a MAX_DATA or MAX_STREAM_DATA frame at least two round trips before it


nit: Should it be round-trips as it is elsewhere?

It's "round-trip time" or "round trip" elsewhere (I think, I'll make it consistent separately)

MikeBishop · 2018-03-08T20:44:18Z

draft-ietf-quic-transport.md

+PATH_CHALLENGE frames or after some time has passed.  When setting this timer,
+implementations are cautioned that the new path could have a longer round-trip
+time than the original.  Again, to avoid excessive network load, an endpoint
+SHOULD NOT send more PATH_CHALLENGE frames than it would a client INITIAL,


Same issue with "Initial" as at ~1519. BTW, double check that you actually need near-identical text both places?

Good point -- I don't think I need it here. The earlier text is adequate. Removed.

huitema · 2018-03-09T00:39:47Z

I am looking at a stateless implementation of challenge/response. Not hard, but the 8 bytes challenge/response is a bit short.

janaiyengar

@martinthomson : can you take a look? I'd like to merge tomorrow (Friday), but would like to confirm that you're fine with this.

martinthomson

This is still too one-sided for me sadly. I would like this to say "endpoint" and "peer" everywhere it says "client" and "server", except for one paragraph that outlines why these mechanisms are only supported for client migration (i.e., because we don't want to deal with glare).

I also retain concerns about structure. I find this structure hard to deal with because - though the requirements are all there and correct - they are distributed in a way that makes working through the process difficult.

I think that you want:

validation (this section is good)
migration
2.1. probing
2.2. migration at the initiating end
2.2.2. voluntary migration
2.2.1. involuntary migration
2.2. migration at the responding end
2.3. congestion/loss concerns

I'm happy to propose a remix of this text that follows that structure, but that will have to wait until next week.

martinthomson · 2018-03-09T01:38:28Z

draft-ietf-quic-transport.md

+Path validation is used by the migrating endpoint to verify reachability of
+a peer from a new local address. Path validation is also used by the peer to
+verify that the migrating endpoint is able to receive packets sent to that
+address.  That is, that the packets received from the migrating endpoint do


"sent to the migrated address" perhaps? The "that" is a bit hard to follow.

replaced with "sent to its new address". I'm not sure if "its" is confusing; let me know if it is.

martinthomson · 2018-03-09T01:42:22Z

draft-ietf-quic-transport.md

+frames and MAY silently discard PATH_CHALLENGE frames that would cause it to
+respond at a higher rate.
+
+Path validation tests both directions of a path.  To ensure reachability in both


"Path validation tests that packets can be both sent to and received from a peer."

The implication I got from reading this text was that a single validation process (CHALLENGE/RESPONSE) was sufficient for both peers to be satisfied that the path is good. That's not the case: both endpoints need to do their own challenge.

martinthomson · 2018-03-09T01:50:50Z

draft-ietf-quic-transport.md

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


Please avoid normative language then.

martinthomson · 2018-03-09T02:10:51Z

draft-ietf-quic-transport.md

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


This paragraph has too many ideas for me. Here's a breakdown:

You want to say that a client can initiate migration to a new address at any time. You also should point out that the basic functions are potentially usable for server migration, but that is not supported due to not having a means of avoid glare.

The point about paths being validated (for both server and client) belongs elsewhere, likely in the introduction of the validation section.

Same again for the point about acknowledgments. Receiving data (including acknowledgments) does not provide proof of return routeability (too low entropy).

So that leaves one idea in the first paragraph: who can do it, and what it is for.

Move the bit about concurrent path validation to a new paragraph.

Overall, I think that needs to be crisper than this and structuring this differently might help.

Give the migrating endpoint three sections:

Speculative probing. Why you might do it, and how you do it. Maybe also what the reaction should be, so that this is self-contained.

The voluntary migration an endpoint makes when it is aware of what it is doing. This happens when an endpoint is aware that it is using a new address. In this case, we should mandate path validation and a new congestion state (absent some heuristics about continuity). Path validation might be concurrent with the change, particularly if the old path is gone, so this might appear to be involuntary at the server, but this is logically distinct.

The involuntary migration (NAT rebinding) needs a section of its own too.

The peer of the migrating endpoint reacts differently, because the concurrent validation looks like involuntary migration to it. Note - as you do - that it can tell between a speculative probe and actual migration by the presence of frames other than PATH_CHALLENGE in packets on the new path. Then say that speculative probes don't trigger migration. After that, the only thing you need to say is that send rate is limited until the path challenge is successful, and the congestion state is reset (absent continuity heuristics again - repetition of this theme suggests a section that you can point to and include some of the nuance) after it.

Let's chat about this tomorrow.

martinthomson · 2018-03-09T02:13:32Z

draft-ietf-quic-transport.md

+validation of the address of the spurious migration to be abandoned.
+
+
+### Loss Detection and Congestion Control


This section is good. I worry a little that the pattern of acknowledgments triggered by this will leak information about what is going on, but I don't have a good solution for that here.

martinthomson · 2018-03-09T03:32:32Z

draft-ietf-quic-transport.md

+in {{QUIC-RECOVERY}}).  In the absence of this limit, the server risks being
+used for a denial of service attack against an unsuspecting victim.  Note that
+since the server will not have any round-trip time estimates to the new address,
+the RTO period is likely to be estimated based on the default initial RTT (see


"SHOULD be" not "likely to be"

I think that this text belongs in the section that deals with handling of migrations by the non-migrating peer.

done. I've simply moved this and the section below into the section above (Responding to Connection Migration).

martinthomson · 2018-03-09T03:42:04Z

draft-ietf-quic-transport.md

+
+Note that the endpoint might receive packets containing other frames on the new
+path, but a PATH_RESPONSE frame with appropriate data is required for path
+validation to succeed.


You might also hint here that a path challenge might be abandoned for other reasons. Primarily, this happens if a path challenge is initiated as a result of a path migration and another path migration occurs before it completes.

You also need to talk about failure. If this timer pops, then the path is invalid and cannot be used further.

martinthomson · 2018-03-09T03:42:43Z

draft-ietf-quic-transport.md

+packets.
+
+
+### Path Validation {#migrate-validate}


I think that you should promote this section one level and put it before connection migration generally.

done. I've redone the front matter in this section to flow better as a standalone.

martinthomson · 2018-03-09T03:45:03Z

draft-ietf-quic-transport.md

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


Please add a paragraph disclaiming any suitability for UDP NAT traversal. Though these mechanisms might be effective for the creation of NAT bindings that support NAT traversal, the expectation is that one or other peer (typically the server) is able to receive packets without first having sent a packet on that path. Effective NAT traversal needs additional synchronization mechanisms that are not provided here.

Added, PTAL.

…ice.

* Create new branch for migration PR (#1012) because unicorns are not nice. * remove overview. again. * sync * fix rebase * Martin's comments * fix ref * comments

ekinnear and others added 22 commits December 4, 2017 15:06

Initial text for new frame types

3b5d429

Replace ping/pong frame

24bcd24

Text for probing and connection migration

84266ae

Text cleanup

ebcf6d5

Remove PATH_PROBE frame, cleanup text

9eeabbc

Add change log

95d7f86

Clean up

6b6d18c

Additional cleanup

040ae7b

initial changes

c2f0bde

initial overview and some nits

e8409fc

wrapped up path probing section

1f439d0

section on committing

5320b27

committing before I start pruning

516f010

first complete pass

da2b65e

change abandon behavior

88c4427

more structure and some more text

54283b8

editorial changes and added section on loss detection

3a53131

added PING frame back in

c18d79c

ekinnear's comments and some wordsmithing

b98920a

Merge pull request #1 from erickinnear/jri-mods

160f2a0

Rewrite of Connection Migration logic

remove unnecessary normative

3e8b841

Merge remote-tracking branch 'origin/master' into dev/migration

0e366ef

janaiyengar mentioned this pull request Dec 13, 2017

Probing and connection migration #880

Closed

martinthomson requested changes Dec 13, 2017

View reviewed changes

erickinnear reviewed Dec 13, 2017

View reviewed changes

MikeBishop previously requested changes Dec 14, 2017

View reviewed changes

janaiyengar commented Dec 14, 2017

View reviewed changes

huitema suggested changes Dec 28, 2017

View reviewed changes

ianswett reviewed Feb 23, 2018

View reviewed changes

martinthomson reviewed Feb 23, 2018

View reviewed changes

MikeBishop reviewed Feb 25, 2018

View reviewed changes

comments

0706fd9

janaiyengar commented Mar 7, 2018

View reviewed changes

sigh. whitespace.

b75ea84

MikeBishop approved these changes Mar 7, 2018

View reviewed changes

Mike's comments

5378c03

janaiyengar commented Mar 7, 2018

View reviewed changes

client connection migration

30025de

erickinnear reviewed Mar 7, 2018

View reviewed changes

eric's comments

b956ba8

janaiyengar commented Mar 8, 2018

View reviewed changes

ianswett approved these changes Mar 8, 2018

View reviewed changes

MikeBishop reviewed Mar 8, 2018

View reviewed changes

MikeBishop mentioned this pull request Mar 8, 2018

Packet Number Gap and Connection Probing #1174

Closed

comments

be2afd3

janaiyengar commented Mar 9, 2018

View reviewed changes

martinthomson requested changes Mar 9, 2018

View reviewed changes

martinthomson mentioned this pull request Mar 9, 2018

Endpoint symmetry #462

Closed

ianswett mentioned this pull request Mar 13, 2018

Connection migration symmetry #573

Closed

martinthomson mentioned this pull request Mar 13, 2018

5-tuple is stable during handshake #594

Closed

martin comments

441d6e9

MikeBishop mentioned this pull request Mar 15, 2018

Change CID after inactivity #1214

Merged

janaiyengar pushed a commit that referenced this pull request Mar 26, 2018

Create new branch for migration PR (#1012) because unicorns are not n…

4a81b91

…ice.

janaiyengar mentioned this pull request Mar 26, 2018

A more complete connection migration #1249

Merged

janaiyengar closed this in #1249 Mar 27, 2018

janaiyengar added a commit that referenced this pull request Mar 27, 2018

A more complete connection migration (#1249)

4a10b92

* Create new branch for migration PR (#1012) because unicorns are not nice. * remove overview. again. * sync * fix rebase * Martin's comments * fix ref * comments


		### Client Behavior {#migration-client}

		A client triggers connection migration to a new address by sending a


		#### Verifying the PMTU

		When the client intends to use a new local address, it MAY establish server



		The sender of this frame MUST include at least one octet of data in the Data
		field.

		@@ -1541,112 +1731,6 @@ number. "packet_number_secret" is derived from the TLS key exchange,
		as described in Section 5.6 of {{QUIC-TLS}}.

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

		## Connection Migration {#migration}


		A client SHOULD reset its congestion controller and roundtrip time estimator
		prior to sending any non-probing packets from a new local address.


		### Initiating Connection Migration {#initiating-migration}

		A client MAY initiate connection migration to a new local address in one of two

		validation of the address of the spurious migration to be abandoned.


		### Loss Detection and Congestion Control

A more complete connection migration #1012

A more complete connection migration #1012

Conversation

janaiyengar commented Dec 13, 2017 • edited Loading

martinthomson left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MikeBishop left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janaiyengar left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

huitema commented Dec 26, 2017

huitema commented Dec 26, 2017

huitema left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ianswett left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janaiyengar commented Dec 13, 2017 •

edited

Loading