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

From: janaiyengar <[email-masked]>
Date: Wed, 13 Dec 2017 00:16:09 +0000 (UTC)

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. The PR introduces PATH_CHALLENGE and PATH_RESPONSE frames for this purpose.
- Allow a client to do PMTU verification on a new path.
- Ensure that a server validates client ownership of a new address. The server also uses the PATH_CHALLENGE and PATH_RESPONSE frames for this purpose.

The new frames obviate the need for PING with data, so PING is now back to being what it used to be --
a frame with no data -- and PONG is gone as well. Note that this allows for a clean implementation and semantic separation. PING can be considered a "retransmittable" frame, with retransmission when not acknowledged, whereas PATH_CHALLENGE/RESPONSE are less onerous, since an implementation may choose to not retransmit (or limit retransmission attempts differently on) probing frames sent to alternate paths.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Initial text for new frame types
  * Replace ping/pong frame
  * Text for probing and connection migration
  * Text cleanup
  * Remove PATH_PROBE frame, cleanup text
  * Add change log
  * Clean up
  * Additional cleanup
  * initial changes
  * initial overview and some nits
  * wrapped up path probing section
  * section on committing
  * committing before I start pruning
  * first complete pass
  * change abandon behavior
  * more structure and some more text
  * editorial changes and added section on loss detection
  * added PING frame back in
  * ekinnear's comments and some wordsmithing
  * Merge pull request #1 from erickinnear/jri-mods
  * remove unnecessary normative
  * Merge remote-tracking branch 'origin/master' into dev/migration

-- File Changes --

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

-- Patch Links --

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1012

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Dec 2017 01:14:12 +0000 (UTC)

martinthomson requested changes on this pull request.

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

> -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 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.
+
+
+### Path Validation and PMTU Verification
+
+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.

> +
+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.
+
+Similarly, a client verifies the PMTU of a network path from a new client
+address to the server by sending a PMTU-sized packet carrying a PATH_CHALLENGE
+frame. The client considers the PMTU verified when a PATH_RESPONSE frame
+containing the same payload sent by the server to the new client address is
+received.
+
+
+### 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.

> +can perform more accurate measurements by associating the server's response with
+the causative PATH_CHALLENGE.
+
+When the client receives a PATH_RESPONSE from the server and verifies that the
+included data matches the data it sent in a previous PATH_CHALLENGE, the server
+is considered reachable from the new address and the PMTU of the new network
+path is considered verified.
+
+A client SHOULD abandon the new address if it does not receive a PATH_RESPONSE
+after sending some number of PATH_CHALLENGE frames and/or after some time has
+passed. Note that the client may be receiving data from the server during this
+period, but not receiving a PATH_RESPONSE may be indicative of a PMTU detection
+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.

> +is considered reachable from the new address and the PMTU of the new network
+path is considered verified.
+
+A client SHOULD abandon the new address if it does not receive a PATH_RESPONSE
+after sending some number of PATH_CHALLENGE frames and/or after some time has
+passed. Note that the client may be receiving data from the server during this
+period, but not receiving a PATH_RESPONSE may be indicative of a PMTU detection
+failure.
+
+
+#### Responding to a Server's Validation
+
+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.

> +frame. The client considers the PMTU verified when a PATH_RESPONSE frame
+containing the same payload sent by the server to the new client address is
+received.
+
+
+### 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
+address. The client SHOULD do PMTU verification before considering migration
+complete. The client also participates in an address validation that the server
+may initiate to confirm the client's ownership of its address (see
+{{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. 

> +but it MUST limit the rate at which data is sent to an unvalidated address, and
+it MUST limit the amount of time for which it sends data to an unvalidated
+address.
+
+
+#### Responding to a Client's Probe
+
+When a server receives a PATH_CHALLENGE frame from a client, it MUST generate a
+PATH_RESPONSE frame that contains the same data as the challenge. The server's
+PATH_RESPONSE MUST be sent to the address from which the client's PATH_CHALLENGE
+was received.
+
+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.

> +A server MAY skip address validation for a client address that it considers to
+be already valid.
+
+After validating a client address, the server MAY send an updated address
+validation token to the client ({{address-validation}}).
+
+
+#### 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.

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.

> +Before sending any other packets to a client address that is not yet considered
+valid, the server MUST send a PATH_CHALLENGE frame with its own validation data
+to this address to verify the client's ownership of it. The server's
+PATH_CHALLENGE MAY be bundled with other frames and does not require additional
+padding.
+
+When the server receives a PATH_RESPONSE from a client and verifies that the
+included data matches that sent by the server in a previous PATH_CHALLENGE to
+the client, the server considers the client address to which the corresponding
+PATH_CHALLENGE was sent as valid.
+
+A server MAY send additional PATH_CHALLENGE frames to handle packet loss,
+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.

> +
+~~~
+ 0                   1                   2                   3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|   Length(8)   |                 Data (*)                    ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~
+
+Length:
+
+: This 8-bit value describes the length of the Data field.
+
+Data:
+
+: This variable-length field contains arbitrary data.

Can we make this a fixed length?

-An endpoint that receives an unsolicited PONG frame - that is, a PONG frame
-containing a payload that is empty MUST generate a connection error of type
-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.

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

---

From: erickinnear <[email-masked]>
Date: Wed, 13 Dec 2017 03:22:45 +0000 (UTC)

erickinnear commented on this pull request.

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

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

---

From: janaiyengar <[email-masked]>
Date: Wed, 13 Dec 2017 06:51:10 +0000 (UTC)

janaiyengar commented on this pull request.

The client is verifying PMTU from its 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_r156575583

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Dec 2017 13:42:55 -0800

martinthomson commented on this pull request.

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

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

---

From: Mike Bishop <[email-masked]>
Date: Thu, 14 Dec 2017 00:46:35 +0000 (UTC)

MikeBishop requested changes on this pull request.

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.

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

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

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.

an => any

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

> +exactly 1200 octets unless the client has a reasonable assurance that the PMTU
+is larger.  Sending a packet of this size confirms that the network path from
+the client to the server supports an MTU of this size.
+
+A client MAY send additional PATH_CHALLENGE frames to handle packet loss or to
+get more measurements on the new network path, subject to the congestion
+controller's limits {{QUIC-RECOVERY}}.
+
+The client SHOULD use fresh random data in every PATH_CHALLENGE frame so that it
+can perform more accurate measurements by associating the server's response with
+the causative PATH_CHALLENGE.
+
+When the client receives a PATH_RESPONSE from the server and verifies that the
+included data matches the data it sent in a previous PATH_CHALLENGE, the server
+is considered reachable from the new address and the PMTU of the new network
+path is considered verified.

"the PMTU is considered verified" is a little too binary here.  You've mandated "exactly" 1200 bytes, which only verifies that 1200 is less than the PMTU.  The client would actually need to do a series of increasingly-large packets with PATH_CHALLENGEs before it actually knows the PMTU.  It might be worth integrating PATH_CHALLENGE into the existing PMTU section, referencing that, and simply saying that the client SHOULD re-probe PMTU whenever it becomes aware of a path change.

+#### Responding to a Server's Validation
+
+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.
+
+A client's PATH_RESPONSE MAY be bundled with other frames and does not require
+additional padding.
+
+A client MAY send more than one PATH_RESPONSE in response to a PATH_CHALLENGE,
+as allowed by the congestion controller, to ensure that packet loss does not
+unduly delay or cause failure of the server's validation process.
+
+A client may trigger the server's validation unwittingly when its public address

Even with the non-caps "may" no longer being considered possibly normative, switching to "might" or "could" would probably still be clearer.

+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.
+
+A client's PATH_RESPONSE MAY be bundled with other frames and does not require
+additional padding.
+
+A client MAY send more than one PATH_RESPONSE in response to a PATH_CHALLENGE,
+as allowed by the congestion controller, to ensure that packet loss does not
+unduly delay or cause failure of the server's validation process.
+
+A client may trigger the server's validation unwittingly when its public address
+changes, such as when a NAT rebinds the client's private address to a new public
+address.  Though the client may be oblivious of such an address change, it MUST

"oblivious to", or "unaware of"

+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.
+
+A client's PATH_RESPONSE MAY be bundled with other frames and does not require
+additional padding.
+
+A client MAY send more than one PATH_RESPONSE in response to a PATH_CHALLENGE,
+as allowed by the congestion controller, to ensure that packet loss does not
+unduly delay or cause failure of the server's validation process.
+
+A client may trigger the server's validation unwittingly when its public address
+changes, such as when a NAT rebinds the client's private address to a new public
+address.  Though the client may be oblivious of such an address change, it MUST
+respond to the consequent validation.  Receiving a PATH_CHALLENGE from the

"Consequent" is a totally cromulent word for this context, but it might be a mite opaque to some readers.

+#### Responding to a Client's Probe
+
+When a server receives a PATH_CHALLENGE frame from a client, it MUST generate a
+PATH_RESPONSE frame that contains the same data as the challenge. The server's
+PATH_RESPONSE MUST be sent to the address from which the client's PATH_CHALLENGE
+was received.
+
+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.
+
+The server need not retransmit its PATH_RESPONSE, since it is the client's
+responsibility to send more PATH_CHALLENGE frames when a response is not
+received for a prior one.

Making them not retransmittable risks false measures of PMTU, doesn't it?  It becomes unclear to the other side whether a drop was random packet loss or the result of oversize datagrams.

+
+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.
+
+The server need not retransmit its PATH_RESPONSE, since it is the client's
+responsibility to send more PATH_CHALLENGE frames when a response is not
+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.
+
+
+#### Validating an Unvalidated Client Address {#migration-validate}

Is the "unvalidated" in the title actually useful?  Other than the "don't send other packets" restriction, is anything else about this flow different from revalidating a previously validated client address?

+The server need not retransmit its PATH_RESPONSE, since it is the client's
+responsibility to send more PATH_CHALLENGE frames when a response is not
+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.
+
+
+#### Validating an Unvalidated Client Address {#migration-validate}
+
+Before sending any other packets to a client address that is not yet considered
+valid, the server MUST send a PATH_CHALLENGE frame with its own validation data
+to this address to verify the client's ownership of it. The server's
+PATH_CHALLENGE MAY be bundled with other frames and does not require additional
+padding.

This feels odd.  The server needs to re-probe PMTU as well; why no padding here?  Why can you bundle other frames if you're not supposed to be sending traffic to this unverified client?  You either need more symmetry here, or better explanation of why you're being asymmetric.

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

+When the server receives a PATH_RESPONSE from a client and verifies that the
+included data matches that sent by the server in a previous PATH_CHALLENGE to
+the client, the server considers the client address to which the corresponding
+PATH_CHALLENGE was sent as valid.
+
+A server MAY send additional PATH_CHALLENGE frames to handle packet loss,
+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.
+
+The server MUST use fresh random data in every PATH_CHALLENGE frame so that it
+can associate the client's response with the causative PATH_CHALLENGE.  Not
+using fresh random data risks exposing the server to an attacker defeating
+validation by sending a spoofed PATH_RESPONSE from a victim's address.

Clarify.  The attacker (hopefully) can't spoof a PATH_RESPONSE, but could capture and replay one from a spoofed source address.

+generated octets {{?RFC4086}}, making the payload sufficiently hard to guess.
+
+The server MUST use fresh random data in every PATH_CHALLENGE frame so that it
+can associate the client's response with the causative PATH_CHALLENGE.  Not
+using fresh random data risks exposing the server to an attacker defeating
+validation by sending a spoofed PATH_RESPONSE from a victim's address.
+
+Until a client address is deemed valid, the server MUST limit the rate at
+which it sends data to this address. The server SHOULD NOT send more than an
+initial window's worth of bytes (as defined in {{QUIC-RECOVERY}}}) per estimated
+roundtrip period.  In the absence of this limit, the server risks being used for
+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

How can this be absent?  The client must have had a previously valid address, or we wouldn't have a connection.  Now, it might be that the client can no longer receive traffic at that address, in which case the connection will time out anyway.  Again, I'd refer to that section rather than trying to re-specify it here.

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

This is going to interact oddly with the NEW_CONNECTION_ID and packet number gap stuff.

-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.
+### Loss Detection and Congestion Control
+
+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

round-trip

-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.
+### Loss Detection and Congestion Control
+
+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
+multiple paths will still send ACK frames covering all received packets.
+
+Both endpoints use one congestion control and one loss recovery context, as

"Each endpoint uses a single congestion control and loss recovery context...."

-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.
+### Loss Detection and Congestion Control
+
+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
+multiple paths will still send ACK frames covering all received packets.
+
+Both endpoints use one congestion control and one loss recovery context, as
+described in {{QUIC-RECOVERY}}.  A sender MAY make an exception for probe
+packets so that their loss detection is independent and does not unduly cause

Clarify "probe packets."  PMTU probing?  Address validation?  Both?

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

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

> @@ -2358,17 +2419,56 @@ Application Error Code:
   {{app-error-codes}}).

+## PATH_CHALLENGE Frame {#frame-path-challenge}
+
+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?

+~~~
+ 0                   1                   2                   3

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

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

+
+Data:
+
+: This variable-length field contains arbitrary data.
+
+
+The sender of this frame MUST include at least one octet of data in the Data
+field.
+
+The recipient of this frame MUST generate a PATH_RESPONSE frame
+({{frame-path-response}}) containing the same Data.  An endpoint that receives a
+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).

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 14 Dec 2017 01:16:32 +0000 (UTC)

mikkelfj commented on this pull request.

Is there sufficient text for guidance on how to handle a path that reverts to smaller PMTU during normal operation? I imagine a large stream frame in eternal futile retransmission because it isn't split into smaller frames in smaller packets.

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

---

From: janaiyengar <[email-masked]>
Date: Wed, 13 Dec 2017 23:36:10 -0800

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

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

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.

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. 

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

---

From: Christian Huitema <[email-masked]>
Date: Tue, 26 Dec 2017 00:12:16 +0000 (UTC)

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.

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

---

From: Christian Huitema <[email-masked]>
Date: Mon, 25 Dec 2017 17:27:52 -0800

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

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

---

From: Christian Huitema <[email-masked]>
Date: Wed, 27 Dec 2017 17:17:56 -0800

huitema requested changes on this pull request.

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.

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

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.

> @@ -1465,35 +1470,220 @@ 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

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.

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

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. 

Yes. Security consideration as to why?

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

+
+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
+multiple paths will still send ACK frames covering all received packets.
+
+Both endpoints use one congestion control and one loss recovery context, as
+described in {{QUIC-RECOVERY}}.  A sender MAY make an exception for probe
+packets so that their loss detection is independent and does not unduly cause
+the congestion controller to reduce its sending rate.
+
+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?

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

+
+Data:
+

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

-The PONG frame (type=0x0d) is sent in response to a PING frame that contains
-data.  Its format is identical to the PING frame ({{frame-ping}}).
+An endpoint that receives a PATH_RESPONSE frame containing an empty payload MUST
+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? 

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

---

From: Christian Huitema <[email-masked]>
Date: Sat, 30 Dec 2017 23:17:10 +0000 (UTC)

huitema commented on this pull request.

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.

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