From 3b5d42990cecf5ae3ae0033660fdcf1bfaa2dfaf Mon Sep 17 00:00:00 2001 From: Eric Kinnear Date: Mon, 4 Dec 2017 15:06:04 -0800 Subject: [PATCH 01/33] Initial text for new frame types --- draft-ietf-quic-transport.md | 190 ++++++++++++++++++++++++++--------- 1 file changed, 140 insertions(+), 50 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0cec3acbf0..890b7dffe6 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -289,6 +289,7 @@ decrypting packets. The consistent connection ID can be used to allow migration of the connection to a new server IP address as well, since the Connection ID remains consistent across changes in the client's and the server's network addresses. +<< Do we want to change the above sentence?>> ## Version Negotiation {#benefit-version-negotiation} @@ -693,6 +694,8 @@ 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 about connection id selected by client during connection migration >> + ## Packet Numbers {#packet-numbers} @@ -843,6 +846,9 @@ explained in more detail as they are referenced later in the document. | 0x0d | PONG | {{frame-pong}} | | 0x0e | ACK | {{frame-ack}} | | 0x10 - 0x17 | STREAM | {{frame-stream}} | +| 0x18 | PATH_PROBE | {{frame-path-probe}} | +| 0x19 | PATH_CHALLENGE | {{frame-path-challenge}} | +| 0x1a | PATH_RESPONSE | {{frame-path-response}} | {: #frame-types title="Frame Types"} # Life of a Connection @@ -1470,15 +1476,53 @@ has not yet been used can start sending new packets with those as a destination IP address and port. Packets exchanged between endpoints can then follow the new path. +A client may want to establish the validity of a potential path through the +network before migrating the connection, perhaps to avoid switching to a network +with undesirable properties. This can be achieved by probing the new network +with a PATH_PROBE frame. The client will generate a PATH_PROBE frame, which is +padded to allow MTU discovery of the new path, and send it on the new network. +Upon receipt of any PATH_PROBE frame, a server generates a PATH_RESPONSE, +similarly padded, indicating to the client that it is reachable over this new +network path. + +When it receives the PATH_RESPONSE frame, the client may choose to migrate the +connection to use the new network path. If so, it sends packets containing any +frame type other than PATH_PROBE or PATH_RESPONSE to the server. This commits +the client to using the new path through the network and the client MUST stop +sending packets on the old path. + +The client may also choose to migrate the connection at any time without sending +a PATH_PROBE frame. + + + + +- We switch over to a new connection ID and packet number (including gap) when + we migrate connections. + + +- Reasons why a connection might want to be migrated + +- General flow of connections migrating + - The two modes + + + + Due to variations in path latency or packet reordering, packets from different source addresses might be reordered. The packet with the highest packet number MUST be used to determine which path to use. Endpoints also need to be prepared to receive packets from an older source address. +- Additional discussion on how the reordering can affect congestion needs to go + in the loss recovery draft. + 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. +- Keep the above note. + ### Privacy Implications of Connection Migration {#migration-linkability} @@ -1556,15 +1600,17 @@ consider the possibility that packets are sent without congestion feedback. Once a connection is established, address validation is relatively simple (see {{address-validation}} for the process that is used during the handshake). An -endpoint validates a remote address by sending a PING frame containing a payload -that is hard to guess. This frame MUST be sent in a packet that is sent to the -new address. Once a PONG frame containing the same payload is received, the -address is considered to be valid. The PONG frame can use any path on its -return. A PING frame containing 12 randomly generated {{?RFC4086}} octets is -sufficient to ensure that it is easier to receive the packet than it is to guess -the value correctly. - -If the PING frame is determined to be lost, a new PING frame SHOULD be +endpoint validates a remote address by sending a PATH_CHALLENGE frame containing +a payload that is hard to guess. This frame MUST be sent in a packet to the new +address. Once a PATH_RESPONSE frame containing the same payload is received, +the address is considered to be valid. The PATH_RESPONSE frame can use any path +on its return. << Do we want this to still be true?>> A PATH_CHALLENGE frame +containing 12 randomly generated {{?RFC4086}} octets is sufficient to ensure +that it is easier to receive the packet than it is to guess the value correctly. + +Because a PATH_CHALLENGE frame is not + +If the PATH_CHALLENGE frame is determined to be lost, a new PING frame SHOULD be generated. This PING frame MUST include a new Data field that is similarly difficult to guess. @@ -2131,47 +2177,10 @@ than it has sent, unless this is a result of a change in the initial limits (see Endpoints can use PING frames (type=0x07) to verify that their peers are still alive or to check reachability to the peer. -The PING frame contains a variable-length payload. - -~~~ - 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. - -A PING frame with an empty Data field causes the packet containing it to be -acknowledged as normal. No other action is required of the recipient. - -An empty PING frame can be used to keep a connection alive when an application -or application protocol wishes to prevent the connection from timing out. An -application protocol SHOULD provide guidance about the conditions under which -generating a PING is recommended. This guidance SHOULD indicate whether it is -the client or the server that is expected to send the PING. Having both -endpoints send PING frames without coordination can produce an excessive number -of packets and poor performance. +The PING frame does not contain a payload. -If the Data field is not empty, the recipient of this frame MUST generate a PONG -frame ({{frame-pong}}) containing the same Data. A PING frame with data is not -appropriate for use in keeping a connection alive, because the PONG frame -elicits an acknowledgement, causing the sender of the original PING to send two -packets. - -A connection will time out if no packets are sent or received for a period -longer than the time specified in the idle_timeout transport parameter (see -{{termination}}). However, state in middleboxes might time out earlier than -that. Though REQ-5 in {{?RFC4787}} recommends a 2 minute timeout interval, -experience shows that sending packets every 15 to 30 seconds is necessary to -prevent the majority of middleboxes from losing state for UDP flows. +- Should you still be able to exchange data so you know which ping/pong is +- which? ## BLOCKED Frame {#frame-blocked} @@ -2303,7 +2312,7 @@ 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 an unsolicited PONG frame - that is, a PONG frame -containing a payload that is empty MUST generate a connection error of type +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. @@ -2617,6 +2626,87 @@ blocks all those streams from making progress. An implementation is therefore advised to bundle as few streams as necessary in outgoing packets without losing transmission efficiency to underfilled packets. +## PATH_PROBE Frame {#frame-path-probe} + + +A client sends a PATH_PROBE frame (type=0x18) to probe a network path during +connection migration. This allows the client to verify connectivity over a +potential network prior to committing to the new path. + +The PATH_PROBE frame does not contain a payload. + +A PATH_PROBE frame MAY be sent using a new connection ID previously provided by +the server in a NEW_CONNECTION_ID frame ({{frame-new-connection-id}}) that the +client wishes to use on the new path. If so, the packet containing the +PATH_PROBE frame MUST use the next packet number after the appropriate packet +number gap as described in {{packet-number-gap}}. + +A packet containing a PATH_PROBE frame MUST be padded to the maximum possible +size. This allows the client to perform MTU discovery, and also prevents +amplification attacks by requiring that packets containing PATH_PROBE frames and +packets containing their resulting PATH_RESPONSE frames are of equivalent size. + +## PATH_CHALLENGE Frame {#frame-path-challenge} + +A server sends a PATH_CHALLENGE frame (type=0x19) to perform address +validation during connection migration. + +PATH_CHALLENGE frames contain a variable-length payload. + +~~~ + 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. + +A PATH_CHALLENGE frame is sent by the server in response to incoming packets +from an unvalidated client. + +If the Data field is not empty, the recipient of this frame MUST generate a +PATH_RESPONSE frame ({{frame-path-response}}) containing the same Data. A +PATH_CHALLENGE frame with data is not appropriate for use in keeping a +connection alive, because the PONG frame elicits an acknowledgement, causing the +sender of the original PING to send two packets. + +- Seems like it actually is appropriate because it (a) generates no acks and (b) + serves to validate that the mapping hasn't changed/the other side is who they + say they are. + +An endpoint MUST NOT generate more than one PATH_CHALLENGE frame per incoming +packet. + +A PATH_CHALLENGE frame MUST NOT generate acknowledgements, as a valid +PATH_RESPONSE serves to indicate receipt of the PATH_CHALLENGE. + +- To pad this frame? +- Allow data field to be empty or say MUST be > 0 length. SHOULD? + +## PATH_RESPONSE Frame {#frame-path-response} + +The PATH_RESPONSE frame (type=0x1a) is sent in response to a PATH_PROBE frame or +a PATH_CHALLENGE frame. Its format is identical to the PATH_CHALLENGE frame +({{frame-path-challenge}}). + +A packet containing a PATH_RESPONSE frame generated in response to a PATH_PROBE +frame MUST be padded to the maximum size. However, a PATH_RESPONSE frame +generated in response to a PATH_CHALLENGE frame does not require any padding. + +- Multiple places to update how to refer to max padding size # Packetization and Reliability {#packetization} From 24bcd24196d2ba68da3c38d811e1139a0b6e6f45 Mon Sep 17 00:00:00 2001 From: Eric Kinnear Date: Mon, 4 Dec 2017 16:11:36 -0800 Subject: [PATCH 02/33] Replace ping/pong frame --- draft-ietf-quic-transport.md | 136 +++++++++++++++-------------------- 1 file changed, 57 insertions(+), 79 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 890b7dffe6..10390cfe41 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -837,18 +837,15 @@ explained in more detail as they are referenced later in the document. | 0x04 | MAX_DATA | {{frame-max-data}} | | 0x05 | MAX_STREAM_DATA | {{frame-max-stream-data}} | | 0x06 | MAX_STREAM_ID | {{frame-max-stream-id}} | -| 0x07 | PING | {{frame-ping}} | +| 0x07 | PATH_CHALLENGE | {{frame-path-challenge}} | | 0x08 | BLOCKED | {{frame-blocked}} | | 0x09 | STREAM_BLOCKED | {{frame-stream-blocked}} | | 0x0a | STREAM_ID_BLOCKED | {{frame-stream-id-blocked}} | | 0x0b | NEW_CONNECTION_ID | {{frame-new-connection-id}} | | 0x0c | STOP_SENDING | {{frame-stop-sending}} | -| 0x0d | PONG | {{frame-pong}} | +| 0x0d | PATH_RESPONSE | {{frame-path-response}} | | 0x0e | ACK | {{frame-ack}} | | 0x10 - 0x17 | STREAM | {{frame-stream}} | -| 0x18 | PATH_PROBE | {{frame-path-probe}} | -| 0x19 | PATH_CHALLENGE | {{frame-path-challenge}} | -| 0x1a | PATH_RESPONSE | {{frame-path-response}} | {: #frame-types title="Frame Types"} # Life of a Connection @@ -2172,15 +2169,50 @@ than it has sent, unless this is a result of a change in the initial limits (see {{zerortt-parameters}}). -## PING Frame {#frame-ping} +## PATH_CHALLENGE Frame {#frame-path-challenge} + +Endpoints can use PATH_CHALLENGE frames (type=0x07) to verify that their peers +are still alive or to check reachability to the peer. A PATH_CHALLENGE frame can +also carry arbitrary data to perform address validation during connection +migration. + +PATH_CHALLENGE frames contain a variable-length payload. + +~~~ + 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. + +If the Data field is not empty, the recipient of this frame MUST generate a +PATH_RESPONSE frame ({{frame-path-response}}) containing the same Data. A +PATH_CHALLENGE frame with data is not appropriate for use in keeping a +connection alive, because the PATH_RESPONSE frame elicits an acknowledgement, +causing the sender of the original PATH_CHALLENGE to send two packets. + +- PATH_RESPONSE no longer elicits an ack, right? + +A PATH_CHALLENGE frame MUST NOT elicit acknowledgements, as a valid +PATH_RESPONSE serves to indicate receipt of the PATH_CHALLENGE. -Endpoints can use PING frames (type=0x07) to verify that their peers are still -alive or to check reachability to the peer. +- Re-work the above to properly specify its stance with regards to: + - Flow control + - Congestion control -The PING frame does not contain a payload. +A packet containing a PATH_CHALLENGE frame with a non-empty Data field MUST be +padded such that it has a QUIC packet size of least 1200 octets. -- Should you still be able to exchange data so you know which ping/pong is -- which? +- Multiple places to update how to refer to max padding size ## BLOCKED Frame {#frame-blocked} @@ -2305,17 +2337,18 @@ Application Error Code: {{app-error-codes}}). +## PATH_RESPONSE Frame {#frame-path-response} -## PONG Frame {#frame-pong} - -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}}). +The PATH_RESPONSE frame (type=0x0d) is sent in response to a PATH_CHALLENGE +frame that contains data. Its format is identical to the PATH_CHALLENGE frame +({{frame-path-challenge}}). -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. +An endpoint that receives an unsolicited PATH_RESPONSE frame - that is, a +PATH_RESPONSE frame containing a payload that is empty - MUST generate a +connection error of type FRAME_ERROR, indicating the PATH_RESPONSE frame (that +is, 0x0d). 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. ## ACK Frame {#frame-ack} @@ -2651,62 +2684,7 @@ size. This allows the client to perform MTU discovery, and also prevents amplification attacks by requiring that packets containing PATH_PROBE frames and packets containing their resulting PATH_RESPONSE frames are of equivalent size. -## PATH_CHALLENGE Frame {#frame-path-challenge} - -A server sends a PATH_CHALLENGE frame (type=0x19) to perform address -validation during connection migration. -PATH_CHALLENGE frames contain a variable-length payload. - -~~~ - 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. - -A PATH_CHALLENGE frame is sent by the server in response to incoming packets -from an unvalidated client. - -If the Data field is not empty, the recipient of this frame MUST generate a -PATH_RESPONSE frame ({{frame-path-response}}) containing the same Data. A -PATH_CHALLENGE frame with data is not appropriate for use in keeping a -connection alive, because the PONG frame elicits an acknowledgement, causing the -sender of the original PING to send two packets. - -- Seems like it actually is appropriate because it (a) generates no acks and (b) - serves to validate that the mapping hasn't changed/the other side is who they - say they are. - -An endpoint MUST NOT generate more than one PATH_CHALLENGE frame per incoming -packet. - -A PATH_CHALLENGE frame MUST NOT generate acknowledgements, as a valid -PATH_RESPONSE serves to indicate receipt of the PATH_CHALLENGE. - -- To pad this frame? -- Allow data field to be empty or say MUST be > 0 length. SHOULD? - -## PATH_RESPONSE Frame {#frame-path-response} - -The PATH_RESPONSE frame (type=0x1a) is sent in response to a PATH_PROBE frame or -a PATH_CHALLENGE frame. Its format is identical to the PATH_CHALLENGE frame -({{frame-path-challenge}}). - -A packet containing a PATH_RESPONSE frame generated in response to a PATH_PROBE -frame MUST be padded to the maximum size. However, a PATH_RESPONSE frame -generated in response to a PATH_CHALLENGE frame does not require any padding. - -- Multiple places to update how to refer to max padding size # Packetization and Reliability {#packetization} @@ -3532,10 +3510,10 @@ PROTOCOL_VIOLATION (0xA): : An endpoint detected an error with protocol compliance that was not covered by more specific error codes. -UNSOLICITED_PONG (0xB): +UNSOLICITED_PATH_RESPONSE (0xB): -: An endpoint received a PONG frame that did not correspond to any PING frame - that it previously sent. +: An endpoint received a PATH_RESPONSE frame that did not correspond to any + PATH_CHALLENGE frame that it previously sent. FRAME_ERROR (0x1XX): @@ -3741,7 +3719,7 @@ the range from 0xFE00 to 0xFFFF. | 0x8 | TRANSPORT_PARAMETER_ERROR | Error in transport parameters | {{error-codes}} | | 0x9 | VERSION_NEGOTIATION_ERROR | Version negotiation failure | {{error-codes}} | | 0xA | PROTOCOL_VIOLATION | Generic protocol violation | {{error-codes}} | -| 0xB | UNSOLICITED_PONG | Unsolicited PONG frame | {{error-codes}} | +| 0xB | UNSOLICITED_PATH_RESPONSE | Unsolicited PATH_RESPONSE frame | {{error-codes}} | | 0x100-0x1FF | FRAME_ERROR | Specific frame format error | {{error-codes}} | {: #iana-error-table title="Initial QUIC Transport Error Codes Entries"} From 84266aef4cdf8df521983c4608fe3191c43c8cb2 Mon Sep 17 00:00:00 2001 From: Eric Kinnear Date: Tue, 5 Dec 2017 02:11:15 -0800 Subject: [PATCH 03/33] Text for probing and connection migration --- draft-ietf-quic-transport.md | 281 ++++++++++++++++++++++------------- 1 file changed, 176 insertions(+), 105 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 10390cfe41..bf0af72f33 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1378,7 +1378,7 @@ connection. TLS provides the tools that support the feature, but basic validation is performed by the core transport protocol. A different type of source address validation is performed after a connection -migration, see {{migrate-validate}}. +migration, see {{migration-validate}}. ### Client Address Validation Procedure @@ -1460,51 +1460,116 @@ connection if the integrity check fails with a PROTOCOL_VIOLATION error code. ## Connection Migration {#migration} -QUIC connections are identified by their 64-bit Connection ID. QUIC's -consistent connection ID allows connections to survive changes to the client's -IP and/or port, such as those caused by client or server migrating to a new -network. Connection migration allows a client to retain any shared state with a -connection when they move networks. This includes state that can be hard to -recover such as outstanding requests, which might otherwise be lost with no easy -way to retry them. - -An endpoint that receives packets that contain a source IP address and port that -has not yet been used can start sending new packets with those as a destination -IP address and port. Packets exchanged between endpoints can then follow the -new path. - -A client may want to establish the validity of a potential path through the -network before migrating the connection, perhaps to avoid switching to a network -with undesirable properties. This can be achieved by probing the new network -with a PATH_PROBE frame. The client will generate a PATH_PROBE frame, which is -padded to allow MTU discovery of the new path, and send it on the new network. -Upon receipt of any PATH_PROBE frame, a server generates a PATH_RESPONSE, -similarly padded, indicating to the client that it is reachable over this new -network path. - -When it receives the PATH_RESPONSE frame, the client may choose to migrate the -connection to use the new network path. If so, it sends packets containing any -frame type other than PATH_PROBE or PATH_RESPONSE to the server. This commits -the client to using the new path through the network and the client MUST stop -sending packets on the old path. - -The client may also choose to migrate the connection at any time without sending -a PATH_PROBE frame. - - - - -- We switch over to a new connection ID and packet number (including gap) when - we migrate connections. - - -- Reasons why a connection might want to be migrated - -- General flow of connections migrating - - The two modes - - - +QUIC's use of connection IDs allows a client to switch between network paths of +communication with a server while retaining any shared state between the +endpoints. Optionally, NEW_CONNECTION_ID frames may be used by the server to +provide the client with additional connection IDs to be used during migration +(see {{migration-linkability}}). Each endpoint involved in migration will +validate the reachability over the network path to the other, and it MUST +validate the identity of the remote endpoint found on that path +({{migration-validate}}). + +An endpoint may choose to probe a network path before migrating the connection, +or it may choose to migrate the connection immediately. For example, a client +that detects that its current network path is degraded may choose to probe +alternate paths and only migrate if an alternate path is considered better (as +defined by the implementation) than the current one. A client may also find +that a path suddenly becomes inoperable, such as when a user unplugs a cable or +other network state changes, and may elect to migrate without probing since it +has no alternative if it wishes to maintain the connection. + + +### Probing a Network Path {#migration-probe} + +To establish the reachability of a server over a new network path, a client may +optionally send a probe packet to which the server will respond. This process +is optional, as the client may choose to migrate the connection without using a +probe. The probe, among other potential uses, serves to establish reachability, +validates the new endpoints, helps the client measure timing over the new path, +and provides validation of the remote endpoint. + +A probe consists of a PATH_PROBE packet, which is defined as a QUIC packet +containing a PATH_CHALLENGE frame ({{frame-path-challenge}}) and a PADDING frame +({{frame-padding}}) such that the QUIC packet size is at least 1200 bytes. + +When a server receives a PATH_PROBE packet, it generates a response to the +PATH_CHALLENGE frame by echoing the Data from the PATH_CHALLENGE frame in a +PATH_RESPONSE frame. In addition to echoing the client's validation data, a +server MUST also include a PATH_CHALLENGE frame with its own validation data, +performing address validation (see {{migration-validate}}) on the new address +provided by the client. + +This response consists of a PATH_PROBE_REPLY packet, which is defined as a QUIC +packet containing a PATH_RESPONSE ({{frame-path-response}}) frame, a +PATH_CHALLENGE ({{frame-path-challenge}}) frame, and a PADDING frame +({{frame-padding}}) such that the QUIC packet size is at least 1200 bytes. + +A client responds to the PATH_CHALLENGE from the server with its own +PATH_RESPONSE frame, which can be sent in any QUIC packet and does not require +additional padding. When the server receives and validates that the echoed Data +field matches the Data field that was sent, the server is considered to have +completed validation. + +All PATH_PROBE packets and PATH_PROBE_REPLY packets MUST be padded to at least +1200 bytes to prevent amplification attacks against unsuspecting endpoints. In +this way, an endpoint that modifies its source address can cause +PATH_PROBE_REPLY packets to be generated and sent to an arbitrary victim only by +generating equally sized PATH_PROBE packets. + +Once the server and client have both validated that their Data field was +properly echoed by the other endpoint, the probe is complete. A client may +choose to send additional probes as necessary to collect additional data, for +example timing data about the new network path. It should be careful to balance +the resources and bandwidth required for such additional probes with the +benefits provided by the additional data. + +PATH_PROBE packets SHOULD <> be subject to loss recovery via an +independent timer-based recovery mechanism, as defined in as defined in +{{QUIC-RECOVERY}}. PATH_PROBE_REPLY packets MUST NOT be retransmitted and are +not subject to loss recovery, as a lost PATH_PROBE_REPLY will trigger a +generation of a new PATH_PROBE by the client, in turn triggering the generation +of a new PATH_PROBE_REPLY. After some delay, as discussed in +{{migration-validate}}, if the client never receives a reply in response to its +probes, the client SHOULD abandon the new path and stop transmitting PATH_PROBE +packets. + +- TODO: sections in {{QUIC-RECOVERY}} +- Mention here instead of just below (and - +alluding to it here) that we generate a new Data field for a new PATH_PROBE and +never retransmit the old one. +- Mention MTU discovery? + + +### Migrating the Connection {#migration-commit} + +When the client chooses to perform the migration, it sends a QUIC packet +containing any frame type other than PATH_CHALLENGE, PATH_RESPONSE, or PADDING. +Upon receipt of such a packet from a different source IP address and port, the +server MUST begin sending all new packets with those as a destination IP address +and port. Similarly, once such a packet has been sent, the client has committed +to using the new path through the network and MUST stop sending new packets on +the old path. A client that continues to send new packets on the old path with +higher packet numbers than those sent on the new path will trigger an entirely +new migration back to that path. + +Upon migration to a new path, a server MUST validate the client over the new +path if it has not already done so, for example by completing the probing +mechanism in {{migration-probe}}. If the probing process has not yet completed, +or the client elected not to probe, the server can validate the client's new +source IP and port by sending a PATH_CHALLENGE frame containing a Data field for +the client to echo. Note that the QUIC packet that includes this PATH_CHALLENGE +frame does not require additional padding. When the server receives the +corresponding PATH_RESPONSE frame containing the correctly echoed data, +validation of the client is complete. + +- How often to retransmit said PATH_CHALLENGE? + +Until an endpoint has validated the its peer's new address and port, it MUST +limit the amount of data that it sends to an unvalidated peer, as described with +more detail in {{migration-validate}}. Without this limit, the endpoint risks +being used for denial of service. + +- Put this back as client/server or leave as endpoint/peer? Due to variations in path latency or packet reordering, packets from different source addresses might be reordered. The packet with the highest packet number @@ -1513,12 +1578,7 @@ to receive packets from an older source address. - Additional discussion on how the reordering can affect congestion needs to go in the loss recovery draft. - -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. - -- Keep the above note. +- Switch to using endpoint/peer more than client/server? ### Privacy Implications of Connection Migration {#migration-linkability} @@ -1526,7 +1586,7 @@ being used for denial of service. See {{migrate-validate}} for details. Using a stable connection ID on multiple network paths allows a passive observer to correlate activity between those paths. A client that moves between networks might not wish to have their activity correlated by any entity other than a -server. The NEW_CONNECTION_ID message can be sent by a server to provide an +server. The NEW_CONNECTION_ID message can be sent by a server to provide an unlinkable connection ID for use in case the client wishes to explicitly break linkability between two points of network attachment. @@ -1540,7 +1600,7 @@ used in the order in which they are numbered. A client which wishes to break linkability upon changing networks MUST use the connection ID provided by the server as well as incrementing the packet sequence number by an externally unpredictable value computed as described in -{{packet-number-gap}}. Packet number gaps are cumulative. A client might skip +{{packet-number-gap}}. Packet number gaps are cumulative. A client might skip connection IDs, but it MUST ensure that it applies the associated packet number gaps for connection IDs that it skips in addition to the packet number gap associated with the connection ID that it does use. @@ -1574,7 +1634,7 @@ number. "packet_number_secret" is derived from the TLS key exchange, as described in Section 5.6 of {{QUIC-TLS}}. -### Address Validation for Migrated Connections {#migrate-validate} +### Address Validation for Migrated Connections {#migration-validate} An endpoint that receives a packet from a new remote IP address and port (or just a new remote port) on packets from its peer is likely seeing a connection @@ -1589,35 +1649,39 @@ generate toward a victim. Thus, when seeing a new remote transport address, an endpoint MUST verify that its peer can receive and respond to packets at that new address. By providing copies of the data that it receives, the peer proves that it is receiving -packets at the new address and consents to receive data. - -Prior to validating the new remote address, and endpoint MUST limit the amount -of data and packets that it sends to its peer. At a minimum, this needs to -consider the possibility that packets are sent without congestion feedback. - -Once a connection is established, address validation is relatively simple (see -{{address-validation}} for the process that is used during the handshake). An -endpoint validates a remote address by sending a PATH_CHALLENGE frame containing -a payload that is hard to guess. This frame MUST be sent in a packet to the new -address. Once a PATH_RESPONSE frame containing the same payload is received, -the address is considered to be valid. The PATH_RESPONSE frame can use any path -on its return. << Do we want this to still be true?>> A PATH_CHALLENGE frame +packets at the new address and consents to receiving data. + +Prior to validating the new remote address, an endpoint MUST limit the amount +of data and packets that it sends to its peer. + +Retransmissions of packets that were originally sent on the previous path MUST +instead be sent on the new path, and they SHOULD NOT count against the +outstanding data relative to the congestion window, and they SHOULD NOT incur a +loss event for the congestion control algorithm. However, care should be taken +not to overwhelm the (potentially unknown) capacity of the new link. + +- TODO: Put some of this in recovery draft instead + +- Describe what this means. Old packets from the previous + +An endpoint validates a remote address by sending a PATH_CHALLENGE frame +containing a payload that is hard to guess. This frame MUST be sent in a packet +to the new address. Once a PATH_RESPONSE frame containing the same payload is +received, the address is considered to be valid. A PATH_CHALLENGE frame containing 12 randomly generated {{?RFC4086}} octets is sufficient to ensure that it is easier to receive the packet than it is to guess the value correctly. -Because a PATH_CHALLENGE frame is not - -If the PATH_CHALLENGE frame is determined to be lost, a new PING frame SHOULD be -generated. This PING frame MUST include a new Data field that is similarly -difficult to guess. +If the PATH_CHALLENGE frame is determined to be lost, a new PATH_CHALLENGE frame +SHOULD be generated. This PATH_CHALLENGE frame MUST include a new Data field +that is similarly difficult to guess. If validation of the new remote address fails, after allowing enough time for -possible loss and recovery of packets carrying PING and PONG frames, the -endpoint MUST terminate the connection. When setting this timer, -implementations are cautioned that the new path could have a longer round trip -time than the original. The endpoint MUST NOT send a CONNECTION_CLOSE frame in -this case; it has to assume that the remote peer does not want to receive any -more packets. +possible loss and recovery of packets carrying PATH_CHALLENGE and their +associated PATH_RESPONSE frames, the endpoint MUST terminate the connection. +When setting this timer, implementations are cautioned that the new path could +have a longer round trip time than the original. The endpoint MUST NOT send a +CONNECTION_CLOSE frame in this case; it has to assume that the remote peer does +not want to receive any more packets. If the remote address is validated successfully, the endpoint MAY increase the rate that it sends on the new path using the state from the previous path. The @@ -1627,27 +1691,34 @@ path is the same as the previous path. For instance, a change in only port number is likely indicative of a rebinding in a middlebox and not a complete change in path. This determination likely depends on heuristics, which could be imperfect; if the new path capacity is significantly reduced, ultimately this -relies on the congestion controller responding to congestion signals and reduce -send rates appropriately. +relies on the congestion controller responding to congestion signals and +reducing send rates appropriately. After verifying an address, the endpoint SHOULD update any address validation tokens ({{address-validation}}) that it has issued to its peer if those are no longer valid based on the changed address. -Address validation using the PING frame MAY be used at any time by either peer. -For instance, an endpoint might check that a peer is still in possession of its -address after a period of quiescence. +Address validation using the PATH_CHALLENGE frame MAY be used at any time by +either peer. For instance, an endpoint might check that a peer is still in +possession of its address after a period of quiescence. Additionally, a client +may choose to send a PATH_PROBE packet at any time, eliciting a PATH_PROBE_REPLY +which can be statelessly generated by the server. + +- The above paragraph (pre-existing) breaks the ability to treat a unsolicited +PATH_CHALLENGE as an indication of a middlebox being bad. That's probably okay, +or we could instead say "MAY treat as sign of bad middlebox/NAT rebinding" and +leave the existing part out. Upon seeing a connection migration, an endpoint that sees a new address MUST abandon any address validation it is performing with other addresses on the expectation that the validation is likely to fail. Abandoning address -validation primarily means not closing the connection when a PONG frame is not -received, but it could also mean ceasing retransmissions of the PING frame. An -endpoint that doesn't retransmit a PING frame might receive a PONG frame, which -it MUST ignore. +validation primarily means not closing the connection when a PATH_RESPONSE frame +is not received, but it could also mean ceasing retransmissions of the +PATH_CHALLENGE frame. An endpoint that doesn't retransmit a PATH_CHALLENGE +frame might receive a PATH_RESPONSE frame, which it MUST ignore. -## Spurious Connection Migrations +### Spurious Connection Migrations {#migrate-spurious} A connection migration could be triggered by an attacker that is able to capture and forward a packet such that it arrives before the legitimate copy of that @@ -1656,10 +1727,10 @@ the legitimate copy will be dropped as a duplicate. After a spurious migration, validation of the source address will fail because the entity at the source address does not have the necessary cryptographic keys -to read or respond to the PING frame that is sent to it, even if it wanted to. -Such a spurious connection migration could result in the connection being -dropped when the source address validation fails. This grants an attacker the -ability to terminate the connection. +to read or respond to the PATH_CHALLENGE frame that is sent to it, even if it +wanted to. Such a spurious connection migration could result in the connection +being dropped when the source address validation fails. This grants an attacker +the ability to terminate the connection. Receipt of packets with higher packet numbers from the legitimate address will trigger another connection migration. This will cause the validation of the @@ -1671,10 +1742,13 @@ the old remote address before attempting to validate the new address. If the connection migration is spurious, then the legitimate address will be used to respond and the connection will migrate back to the old address. -As with any address validation, packets containing retransmissions of the PING -frame validating an address MUST be sent to the address being validated. -Consequently, during a migration of a peer, an endpoint could be sending to -multiple remote addresses. +- This means that above we need to say "MUST NOT" send any frames other than +PATH_CHALLENGE, not just MUST switch. This gets ugly really quickly. + +As with any address validation, packets containing retransmissions of the +PATH_CHALLENGE frame validating an address MUST be sent to the address being +validated. Consequently, during a migration of a peer, an endpoint could be +sending to multiple remote addresses. An endpoint MAY abandon address validation for an address that it considers to be already valid. That is, if successive connection migrations occur in quick @@ -2195,15 +2269,11 @@ Data: : This variable-length field contains arbitrary data. If the Data field is not empty, the recipient of this frame MUST generate a -PATH_RESPONSE frame ({{frame-path-response}}) containing the same Data. A -PATH_CHALLENGE frame with data is not appropriate for use in keeping a -connection alive, because the PATH_RESPONSE frame elicits an acknowledgement, -causing the sender of the original PATH_CHALLENGE to send two packets. - -- PATH_RESPONSE no longer elicits an ack, right? +PATH_RESPONSE frame ({{frame-path-response}}) containing the same Data. A PATH_CHALLENGE frame MUST NOT elicit acknowledgements, as a valid -PATH_RESPONSE serves to indicate receipt of the PATH_CHALLENGE. +PATH_RESPONSE serves to indicate receipt of the PATH_CHALLENGE. These frames are +included in loss recovery, as they will be retransmitted separately. - Re-work the above to properly specify its stance with regards to: - Flow control @@ -2525,7 +2595,8 @@ acknowledged again. A receiver that is only sending ACK frames will not receive acknowledgments for its packets. Sending an occasional MAX_DATA or MAX_STREAM_DATA frame as data is received will ensure that acknowledgements are generated by a peer. Otherwise, -an endpoint MAY send a PING frame once per RTT to solicit an acknowledgment. +an endpoint MAY send a PATH_CHALLENGE frame once per RTT to solicit an +acknowledgment. To limit receiver state or the size of ACK frames, a receiver MAY limit the number of ACK blocks it sends. A receiver can do this even without receiving From ebcf6d5134d201c8b912abb2ea5387d3b89c756e Mon Sep 17 00:00:00 2001 From: Tommy Pauly Date: Tue, 5 Dec 2017 09:22:34 -0800 Subject: [PATCH 04/33] Text cleanup --- draft-ietf-quic-transport.md | 121 +++++++++++++++++++---------------- 1 file changed, 66 insertions(+), 55 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index bf0af72f33..78c22314a6 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1460,82 +1460,96 @@ connection if the integrity check fails with a PROTOCOL_VIOLATION error code. ## Connection Migration {#migration} -QUIC's use of connection IDs allows a client to switch between network paths of -communication with a server while retaining any shared state between the -endpoints. Optionally, NEW_CONNECTION_ID frames may be used by the server to -provide the client with additional connection IDs to be used during migration -(see {{migration-linkability}}). Each endpoint involved in migration will -validate the reachability over the network path to the other, and it MUST -validate the identity of the remote endpoint found on that path -({{migration-validate}}). - -An endpoint may choose to probe a network path before migrating the connection, -or it may choose to migrate the connection immediately. For example, a client -that detects that its current network path is degraded may choose to probe -alternate paths and only migrate if an alternate path is considered better (as -defined by the implementation) than the current one. A client may also find -that a path suddenly becomes inoperable, such as when a user unplugs a cable or -other network state changes, and may elect to migrate without probing since it -has no alternative if it wishes to maintain the connection. +Since QUIC uses connection IDs to distinguish connections, the IP addresses and +ports associated with a given connection may change over time without losing +shared state. Any instance of connections moving to new addresses or ports is +referred to as connection migration. This occurs either when a client chooses to +send traffic from a different local endpoint, or when a NAT changes address or +port mappings. + +In order to make it more difficult for passive eavesdroppers to track a +connection as it migrates, a client can use different connection IDs when +sending from different addresses. The server can send NEW_CONNECTION_ID +frames to provide the client with additional connection IDs to be used during +migration ({{migration-linkability}}). + +Any time a new remote endpoint is detected, such as when a server +receives a packet for a known connection ID from a different address, the remote +endpoint MUST be validated ({{migration-validate}}). + +Any time a new local endpoint is used, such as when a client chooses +to migrate a connection onto a different network interface, the path can be +probed to check reachability ({{migration-probe}}). An endpoint may choose to +probe a network path before migrating the connection, or it may choose to +migrate the connection immediately. For example, a client that detects that its +current network path is degraded may choose to probe alternate paths and only +migrate if an alternate path is preferred over the current one. A client may +also find that a path suddenly becomes inoperable, such as when a user +unplugs a cable or other network state changes, and may elect to migrate +without probing since it has no alternative if it wishes to maintain the +connection. ### Probing a Network Path {#migration-probe} -To establish the reachability of a server over a new network path, a client may +To check the reachability of a server over a new network path, a client may optionally send a probe packet to which the server will respond. This process is optional, as the client may choose to migrate the connection without using a probe. The probe, among other potential uses, serves to establish reachability, validates the new endpoints, helps the client measure timing over the new path, and provides validation of the remote endpoint. -A probe consists of a PATH_PROBE packet, which is defined as a QUIC packet +A probe consists of a "Path Probe" packet, which is defined as a QUIC packet containing a PATH_CHALLENGE frame ({{frame-path-challenge}}) and a PADDING frame ({{frame-padding}}) such that the QUIC packet size is at least 1200 bytes. -When a server receives a PATH_PROBE packet, it generates a response to the -PATH_CHALLENGE frame by echoing the Data from the PATH_CHALLENGE frame in a +When a server receives a Path Probe packet, it generates a response to the +PATH_CHALLENGE frame by echoing the data from the PATH_CHALLENGE frame in a PATH_RESPONSE frame. In addition to echoing the client's validation data, a server MUST also include a PATH_CHALLENGE frame with its own validation data, performing address validation (see {{migration-validate}}) on the new address provided by the client. -This response consists of a PATH_PROBE_REPLY packet, which is defined as a QUIC -packet containing a PATH_RESPONSE ({{frame-path-response}}) frame, a -PATH_CHALLENGE ({{frame-path-challenge}}) frame, and a PADDING frame +This response consists of a "Path Probe Reply" packet, which is defined as a +QUIC packet containing a PATH_RESPONSE ({{frame-path-response}}) frame, +a PATH_CHALLENGE ({{frame-path-challenge}}) frame, and a PADDING frame ({{frame-padding}}) such that the QUIC packet size is at least 1200 bytes. A client responds to the PATH_CHALLENGE from the server with its own PATH_RESPONSE frame, which can be sent in any QUIC packet and does not require -additional padding. When the server receives and validates that the echoed Data -field matches the Data field that was sent, the server is considered to have -completed validation. - -All PATH_PROBE packets and PATH_PROBE_REPLY packets MUST be padded to at least +additional padding. This may be sent as a standalone packet without other +frames, in which case the connection is not yet migrated, or else along with +a packet that includes other frames as part of migrating the connection +({{migration-commit}}). When the server receives and validates that the +echoed data field matches the data field that was sent, the server is +considered to have completed validation. + +All Path Probe packets and Path Probe Reply packets MUST be padded to at least 1200 bytes to prevent amplification attacks against unsuspecting endpoints. In this way, an endpoint that modifies its source address can cause -PATH_PROBE_REPLY packets to be generated and sent to an arbitrary victim only by -generating equally sized PATH_PROBE packets. +Path Probe Reply packets to be generated and sent to an arbitrary victim only by +generating equally sized Path Probe packets. -Once the server and client have both validated that their Data field was -properly echoed by the other endpoint, the probe is complete. A client may -choose to send additional probes as necessary to collect additional data, for -example timing data about the new network path. It should be careful to balance -the resources and bandwidth required for such additional probes with the -benefits provided by the additional data. +Once the server and client have both validated that the data in their +PATH_CHALLENGE frames was echoed by the other endpoint, the probe is +complete. A client may choose to send additional probes as necessary to collect +additional data, for example timing data about the new network path. It should +be careful to balance the resources and bandwidth required for such +additional probes with the benefits provided by the additional data. -PATH_PROBE packets SHOULD <> be subject to loss recovery via an +Path Probe packets MUST be subject to loss recovery via an independent timer-based recovery mechanism, as defined in as defined in -{{QUIC-RECOVERY}}. PATH_PROBE_REPLY packets MUST NOT be retransmitted and are -not subject to loss recovery, as a lost PATH_PROBE_REPLY will trigger a -generation of a new PATH_PROBE by the client, in turn triggering the generation -of a new PATH_PROBE_REPLY. After some delay, as discussed in +{{QUIC-RECOVERY}}. Path Probe Reply packets MUST NOT be retransmitted and are +not subject to loss recovery, as a lost Path Probe Reply will trigger a +generation of a new Path Probe by the client, in turn triggering the generation +of a new Path Probe Reply. After some delay, as discussed in {{migration-validate}}, if the client never receives a reply in response to its -probes, the client SHOULD abandon the new path and stop transmitting PATH_PROBE +probes, the client SHOULD abandon the new path and stop transmitting Path Probe packets. - TODO: sections in {{QUIC-RECOVERY}} - Mention here instead of just below (and - -alluding to it here) that we generate a new Data field for a new PATH_PROBE and +alluding to it here) that we generate a new Data field for a new Path Probe and never retransmit the old one. - Mention MTU discovery? @@ -1556,20 +1570,18 @@ Upon migration to a new path, a server MUST validate the client over the new path if it has not already done so, for example by completing the probing mechanism in {{migration-probe}}. If the probing process has not yet completed, or the client elected not to probe, the server can validate the client's new -source IP and port by sending a PATH_CHALLENGE frame containing a Data field for +source IP and port by sending a PATH_CHALLENGE frame containing a data field for the client to echo. Note that the QUIC packet that includes this PATH_CHALLENGE frame does not require additional padding. When the server receives the corresponding PATH_RESPONSE frame containing the correctly echoed data, -validation of the client is complete. - -- How often to retransmit said PATH_CHALLENGE? - -Until an endpoint has validated the its peer's new address and port, it MUST -limit the amount of data that it sends to an unvalidated peer, as described with -more detail in {{migration-validate}}. Without this limit, the endpoint risks -being used for denial of service. +validation of the client is complete. The server MAY send multiple +PATH_CHALLENGE frames in separate packets until it receives a +PATH_RESPONSE. -- Put this back as client/server or leave as endpoint/peer? +Until the server has validated the the client's new address and port, it MUST +limit the amount of data that it sends to an unvalidated client, as described +with more detail in {{migration-validate}}. Without this limit, the server +risks being used for denial of service. Due to variations in path latency or packet reordering, packets from different source addresses might be reordered. The packet with the highest packet number @@ -1578,7 +1590,6 @@ to receive packets from an older source address. - Additional discussion on how the reordering can affect congestion needs to go in the loss recovery draft. -- Switch to using endpoint/peer more than client/server? ### Privacy Implications of Connection Migration {#migration-linkability} From 9eeabbc53c009b9ca1835be1cf33bcdf520d935b Mon Sep 17 00:00:00 2001 From: Tommy Pauly Date: Tue, 5 Dec 2017 10:45:30 -0800 Subject: [PATCH 05/33] Remove PATH_PROBE frame, cleanup text --- draft-ietf-quic-transport.md | 43 ++++++------------------------------ 1 file changed, 7 insertions(+), 36 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 78c22314a6..1c10553cc9 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1709,16 +1709,13 @@ After verifying an address, the endpoint SHOULD update any address validation tokens ({{address-validation}}) that it has issued to its peer if those are no longer valid based on the changed address. -Address validation using the PATH_CHALLENGE frame MAY be used at any time by -either peer. For instance, an endpoint might check that a peer is still in -possession of its address after a period of quiescence. Additionally, a client -may choose to send a PATH_PROBE packet at any time, eliciting a PATH_PROBE_REPLY -which can be statelessly generated by the server. - -- The above paragraph (pre-existing) breaks the ability to treat a unsolicited -PATH_CHALLENGE as an indication of a middlebox being bad. That's probably okay, -or we could instead say "MAY treat as sign of bad middlebox/NAT rebinding" and -leave the existing part out. +A client MAY treat an incoming PATH_CHALLENGE frame that includes data as +an indication that the server’s view of the client’s endpoint has changed. +This acts as a hint to the client that the network path may have changed, +such as when a NAT rebinding occurs. Because of this, servers SHOULD NOT +send PATH_CHALLENGE frames that include data unless there is a need to +re-validate the client’s address (such as any address or port change, or an +extended period without traffic). Upon seeing a connection migration, an endpoint that sees a new address MUST abandon any address validation it is performing with other addresses on the @@ -2741,32 +2738,6 @@ blocks all those streams from making progress. An implementation is therefore advised to bundle as few streams as necessary in outgoing packets without losing transmission efficiency to underfilled packets. -## PATH_PROBE Frame {#frame-path-probe} - - -A client sends a PATH_PROBE frame (type=0x18) to probe a network path during -connection migration. This allows the client to verify connectivity over a -potential network prior to committing to the new path. - -The PATH_PROBE frame does not contain a payload. - -A PATH_PROBE frame MAY be sent using a new connection ID previously provided by -the server in a NEW_CONNECTION_ID frame ({{frame-new-connection-id}}) that the -client wishes to use on the new path. If so, the packet containing the -PATH_PROBE frame MUST use the next packet number after the appropriate packet -number gap as described in {{packet-number-gap}}. - -A packet containing a PATH_PROBE frame MUST be padded to the maximum possible -size. This allows the client to perform MTU discovery, and also prevents -amplification attacks by requiring that packets containing PATH_PROBE frames and -packets containing their resulting PATH_RESPONSE frames are of equivalent size. - - # Packetization and Reliability {#packetization} From 95d7f866f9cd6ce03951acaf4d6a1103db0b4d43 Mon Sep 17 00:00:00 2001 From: Eric Kinnear Date: Tue, 5 Dec 2017 12:43:38 -0800 Subject: [PATCH 06/33] Add change log --- draft-ietf-quic-transport.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 1c10553cc9..be233cfa18 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1551,7 +1551,6 @@ packets. - Mention here instead of just below (and - alluding to it here) that we generate a new Data field for a new Path Probe and never retransmit the old one. -- Mention MTU discovery? ### Migrating the Connection {#migration-commit} @@ -3814,6 +3813,8 @@ Issue and pull request numbers are listed with a leading octothorp. - Employ variable-length integer encodings throughout (#595) - Draining period can terminate early (#869) +- Replace PING and PONG frames with PATH_CHALLENGE and PATH_RESPONSE frames, + clarify connection migration text (#000) ## Since draft-ietf-quic-transport-06 From 6b6d18c110f888f13cbffea81472eb766e94558a Mon Sep 17 00:00:00 2001 From: Eric Kinnear Date: Tue, 5 Dec 2017 13:36:12 -0800 Subject: [PATCH 07/33] Clean up --- draft-ietf-quic-transport.md | 23 +---------------------- 1 file changed, 1 insertion(+), 22 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index be233cfa18..d0008758f0 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1547,11 +1547,6 @@ of a new Path Probe Reply. After some delay, as discussed in probes, the client SHOULD abandon the new path and stop transmitting Path Probe packets. -- TODO: sections in {{QUIC-RECOVERY}} -- Mention here instead of just below (and - -alluding to it here) that we generate a new Data field for a new Path Probe and -never retransmit the old one. - ### Migrating the Connection {#migration-commit} @@ -1587,9 +1582,6 @@ source addresses might be reordered. The packet with the highest packet number MUST be used to determine which path to use. Endpoints also need to be prepared to receive packets from an older source address. -- Additional discussion on how the reordering can affect congestion needs to go - in the loss recovery draft. - ### Privacy Implications of Connection Migration {#migration-linkability} @@ -1670,10 +1662,6 @@ outstanding data relative to the congestion window, and they SHOULD NOT incur a loss event for the congestion control algorithm. However, care should be taken not to overwhelm the (potentially unknown) capacity of the new link. -- TODO: Put some of this in recovery draft instead - -- Describe what this means. Old packets from the previous - An endpoint validates a remote address by sending a PATH_CHALLENGE frame containing a payload that is hard to guess. This frame MUST be sent in a packet to the new address. Once a PATH_RESPONSE frame containing the same payload is @@ -1749,9 +1737,6 @@ the old remote address before attempting to validate the new address. If the connection migration is spurious, then the legitimate address will be used to respond and the connection will migrate back to the old address. -- This means that above we need to say "MUST NOT" send any frames other than -PATH_CHALLENGE, not just MUST switch. This gets ugly really quickly. - As with any address validation, packets containing retransmissions of the PATH_CHALLENGE frame validating an address MUST be sent to the address being validated. Consequently, during a migration of a peer, an endpoint could be @@ -2280,17 +2265,11 @@ PATH_RESPONSE frame ({{frame-path-response}}) containing the same Data. A PATH_CHALLENGE frame MUST NOT elicit acknowledgements, as a valid PATH_RESPONSE serves to indicate receipt of the PATH_CHALLENGE. These frames are -included in loss recovery, as they will be retransmitted separately. - -- Re-work the above to properly specify its stance with regards to: - - Flow control - - Congestion control +not included in loss recovery, as they will be retransmitted separately. A packet containing a PATH_CHALLENGE frame with a non-empty Data field MUST be padded such that it has a QUIC packet size of least 1200 octets. -- Multiple places to update how to refer to max padding size - ## BLOCKED Frame {#frame-blocked} From 040ae7b7059ba8c066071fa3622de5b018542916 Mon Sep 17 00:00:00 2001 From: Eric Kinnear Date: Tue, 5 Dec 2017 13:41:36 -0800 Subject: [PATCH 08/33] Additional cleanup --- draft-ietf-quic-transport.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index d0008758f0..a2e7fe2009 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -289,7 +289,6 @@ decrypting packets. The consistent connection ID can be used to allow migration of the connection to a new server IP address as well, since the Connection ID remains consistent across changes in the client's and the server's network addresses. -<< Do we want to change the above sentence?>> ## Version Negotiation {#benefit-version-negotiation} @@ -694,7 +693,9 @@ 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 about connection id selected by client during connection migration >> +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}}). ## Packet Numbers {#packet-numbers} From c2f0bde391ed1e4d3d76edc66f13da39d020a32e Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Tue, 5 Dec 2017 17:07:45 -0800 Subject: [PATCH 09/33] initial changes --- draft-ietf-quic-transport.md | 54 +++++++++++++++++------------------- 1 file changed, 25 insertions(+), 29 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index a2e7fe2009..5f7537b0c1 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1461,24 +1461,23 @@ connection if the integrity check fails with a PROTOCOL_VIOLATION error code. ## Connection Migration {#migration} -Since QUIC uses connection IDs to distinguish connections, the IP addresses and -ports associated with a given connection may change over time without losing -shared state. Any instance of connections moving to new addresses or ports is -referred to as connection migration. This occurs either when a client chooses to -send traffic from a different local endpoint, or when a NAT changes address or -port mappings. - -In order to make it more difficult for passive eavesdroppers to track a -connection as it migrates, a client can use different connection IDs when -sending from different addresses. The server can send NEW_CONNECTION_ID -frames to provide the client with additional connection IDs to be used during -migration ({{migration-linkability}}). - -Any time a new remote endpoint is detected, such as when a server +QUIC connections are identified by their 64-bit Connection ID, which allows +connections to survive changes to the client's IP address and/or port. Any +instance of connections moving to new addresses or ports is referred to as +connection migration. This occurs either when a client chooses to send traffic +over a different network, or when a NAT changes address or port mappings. + +If a new connection ID is provided by the server to be used during connection +migration, a client that is choosing to use a new address MUST use a new +connection ID on packets sent from this address. As discussed in +{{migration-validate}}, this makes it more difficult for passive observers +to track a connection as it migrates across networks. + +Any time a new remote address is detected, such as when a server receives a packet for a known connection ID from a different address, the remote -endpoint MUST be validated ({{migration-validate}}). +address MUST be validated ({{migration-validate}}). -Any time a new local endpoint is used, such as when a client chooses +Any time a new local address is used, such as when a client chooses to migrate a connection onto a different network interface, the path can be probed to check reachability ({{migration-probe}}). An endpoint may choose to probe a network path before migrating the connection, or it may choose to @@ -1497,8 +1496,8 @@ To check the reachability of a server over a new network path, a client may optionally send a probe packet to which the server will respond. This process is optional, as the client may choose to migrate the connection without using a probe. The probe, among other potential uses, serves to establish reachability, -validates the new endpoints, helps the client measure timing over the new path, -and provides validation of the remote endpoint. +validates the new addresses, helps the client measure timing over the new path, +and provides validation of the remote address. A probe consists of a "Path Probe" packet, which is defined as a QUIC packet containing a PATH_CHALLENGE frame ({{frame-path-challenge}}) and a PADDING frame @@ -1658,10 +1657,9 @@ Prior to validating the new remote address, an endpoint MUST limit the amount of data and packets that it sends to its peer. Retransmissions of packets that were originally sent on the previous path MUST -instead be sent on the new path, and they SHOULD NOT count against the -outstanding data relative to the congestion window, and they SHOULD NOT incur a -loss event for the congestion control algorithm. However, care should be taken -not to overwhelm the (potentially unknown) capacity of the new link. +instead be sent on the new path, as allowed by the congestion controller. Any +losses detected on packets that were not sent on the new path SHOULD not count +as a loss event for the congestion control purposes. An endpoint validates a remote address by sending a PATH_CHALLENGE frame containing a payload that is hard to guess. This frame MUST be sent in a packet @@ -1697,13 +1695,11 @@ After verifying an address, the endpoint SHOULD update any address validation tokens ({{address-validation}}) that it has issued to its peer if those are no longer valid based on the changed address. -A client MAY treat an incoming PATH_CHALLENGE frame that includes data as -an indication that the server’s view of the client’s endpoint has changed. -This acts as a hint to the client that the network path may have changed, -such as when a NAT rebinding occurs. Because of this, servers SHOULD NOT -send PATH_CHALLENGE frames that include data unless there is a need to -re-validate the client’s address (such as any address or port change, or an -extended period without traffic). +A client MAY treat an incoming PATH_CHALLENGE frame that includes data as an +indication that the server’s view of the client’s address has changed. This +acts as a hint to the client that the network path may have changed, such as +when a NAT rebinding occurs. A server SHOULD NOT send a PATH_CHALLENGE frames +unless there is an observed change in the client’s address. Upon seeing a connection migration, an endpoint that sees a new address MUST abandon any address validation it is performing with other addresses on the From e8409fc675827ee8f44492539187e3ed20e82217 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Wed, 6 Dec 2017 00:51:23 -0800 Subject: [PATCH 10/33] initial overview and some nits --- draft-ietf-quic-transport.md | 56 +++++++++++++++++++----------------- 1 file changed, 29 insertions(+), 27 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 5f7537b0c1..0a10a49a52 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1461,33 +1461,35 @@ 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, which allows -connections to survive changes to the client's IP address and/or port. Any -instance of connections moving to new addresses or ports is referred to as -connection migration. This occurs either when a client chooses to send traffic -over a different network, or when a NAT changes address or port mappings. - -If a new connection ID is provided by the server to be used during connection -migration, a client that is choosing to use a new address MUST use a new -connection ID on packets sent from this address. As discussed in -{{migration-validate}}, this makes it more difficult for passive observers -to track a connection as it migrates across networks. - -Any time a new remote address is detected, such as when a server -receives a packet for a known connection ID from a different address, the remote -address MUST be validated ({{migration-validate}}). - -Any time a new local address is used, such as when a client chooses -to migrate a connection onto a different network interface, the path can be -probed to check reachability ({{migration-probe}}). An endpoint may choose to -probe a network path before migrating the connection, or it may choose to -migrate the connection immediately. For example, a client that detects that its -current network path is degraded may choose to probe alternate paths and only -migrate if an alternate path is preferred over the current one. A client may -also find that a path suddenly becomes inoperable, such as when a user -unplugs a cable or other network state changes, and may elect to migrate -without probing since it has no alternative if it wishes to maintain the -connection. +QUIC connections are identified by 64-bit Connection IDs. QUIC's connection IDs +allow connections to survive changes to the client's IP address and/or port - +collectively referred to as the client's address - such as those caused by a +client migrating to a new network or a NAT rebinding changing the publicly +observable client address. + +A high-level summary of connection migration follows. A client desiring +migration to a new network may probe the new network for reachability and to get +a roundtrip time measurement, while continuing to send and receive packets over +the extant network, see {{migration-probe}}. When the probe succeeds and if the +client decides to migrate, the client latches to the new network, sending all +packets over the new network. Alternatively, a client may latch to the new +network immediately without probing, such as would be the case when the only +network available to the client is the new network. A server that receives a +probe packet from a new client address simply responds to the probe. +Additionally, when a non-probe packet is received from a client on a new +address, the server issues a challenge: it sends random bytes to the client on +the new address. The server limits its rate to the new address until the client +echoes back the random bytes, validating the new address. + +A client migrating to a new network MUST use a new connection ID for packets +sent from the new address if an additional connection ID has been provided by +the server, see {{migration-linkability}}. Using a new connection ID on +migration makes it harder for passive observers to track connections migrating +across networks. A client may be unaware of connection migration due to NAT +rebinding and may consequently not change its connection ID on NAT rebindings. + +A server that receives a oacket for a known connection ID from an unknown client +address MUST validate this new address, see {{migration-validate}}, ### Probing a Network Path {#migration-probe} From 1f439d0f834b3f6cefd53579da072d8434be85af Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Thu, 7 Dec 2017 01:38:59 -0800 Subject: [PATCH 11/33] wrapped up path probing section --- draft-ietf-quic-transport.md | 122 ++++++++++++++++++----------------- 1 file changed, 62 insertions(+), 60 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0a10a49a52..382fe2092f 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1469,7 +1469,7 @@ observable client address. A high-level summary of connection migration follows. A client desiring migration to a new network may probe the new network for reachability and to get -a roundtrip time measurement, while continuing to send and receive packets over +a roundtrip-time measurement, while continuing to send and receive packets over the extant network, see {{migration-probe}}. When the probe succeeds and if the client decides to migrate, the client latches to the new network, sending all packets over the new network. Alternatively, a client may latch to the new @@ -1488,69 +1488,71 @@ migration makes it harder for passive observers to track connections migrating across networks. A client may be unaware of connection migration due to NAT rebinding and may consequently not change its connection ID on NAT rebindings. -A server that receives a oacket for a known connection ID from an unknown client -address MUST validate this new address, see {{migration-validate}}, +A server that receives a packet for a known connection ID from a new client +address SHOULD validate this new address, see {{migration-validate}}, ### Probing a Network Path {#migration-probe} -To check the reachability of a server over a new network path, a client may -optionally send a probe packet to which the server will respond. This process -is optional, as the client may choose to migrate the connection without using a -probe. The probe, among other potential uses, serves to establish reachability, -validates the new addresses, helps the client measure timing over the new path, -and provides validation of the remote address. - -A probe consists of a "Path Probe" packet, which is defined as a QUIC packet -containing a PATH_CHALLENGE frame ({{frame-path-challenge}}) and a PADDING frame -({{frame-padding}}) such that the QUIC packet size is at least 1200 bytes. - -When a server receives a Path Probe packet, it generates a response to the -PATH_CHALLENGE frame by echoing the data from the PATH_CHALLENGE frame in a -PATH_RESPONSE frame. In addition to echoing the client's validation data, a -server MUST also include a PATH_CHALLENGE frame with its own validation data, -performing address validation (see {{migration-validate}}) on the new address -provided by the client. - -This response consists of a "Path Probe Reply" packet, which is defined as a -QUIC packet containing a PATH_RESPONSE ({{frame-path-response}}) frame, -a PATH_CHALLENGE ({{frame-path-challenge}}) frame, and a PADDING frame -({{frame-padding}}) such that the QUIC packet size is at least 1200 bytes. - -A client responds to the PATH_CHALLENGE from the server with its own -PATH_RESPONSE frame, which can be sent in any QUIC packet and does not require -additional padding. This may be sent as a standalone packet without other -frames, in which case the connection is not yet migrated, or else along with -a packet that includes other frames as part of migrating the connection -({{migration-commit}}). When the server receives and validates that the -echoed data field matches the data field that was sent, the server is -considered to have completed validation. - -All Path Probe packets and Path Probe Reply packets MUST be padded to at least -1200 bytes to prevent amplification attacks against unsuspecting endpoints. In -this way, an endpoint that modifies its source address can cause -Path Probe Reply packets to be generated and sent to an arbitrary victim only by -generating equally sized Path Probe packets. - -Once the server and client have both validated that the data in their -PATH_CHALLENGE frames was echoed by the other endpoint, the probe is -complete. A client may choose to send additional probes as necessary to collect -additional data, for example timing data about the new network path. It should -be careful to balance the resources and bandwidth required for such -additional probes with the benefits provided by the additional data. - -Path Probe packets MUST be subject to loss recovery via an -independent timer-based recovery mechanism, as defined in as defined in -{{QUIC-RECOVERY}}. Path Probe Reply packets MUST NOT be retransmitted and are -not subject to loss recovery, as a lost Path Probe Reply will trigger a -generation of a new Path Probe by the client, in turn triggering the generation -of a new Path Probe Reply. After some delay, as discussed in -{{migration-validate}}, if the client never receives a reply in response to its -probes, the client SHOULD abandon the new path and stop transmitting Path Probe -packets. - - -### Migrating the Connection {#migration-commit} +When a new local address is available, a client MAY send a packet containing a +PATH_CHALLENGE frame ({{frame-path-challenge}}) from this address to detect +server reachability from it and to measure the roundtrip-time to the server from +it. This packet SHOULD be padded to 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 and helps reduce the amplitude of amplification attacks caused by +server responses toward an unverified client address. + +A client MAY send additional packets containing PATH_CHALLENGE frames to handle +packet loss or to get more measurements on the new network path. The client MUST +limit the number of such probes it considers outstanding in the network to limit +load on an untested network path. + +For example, a client may send a PATH_CHALLENGE frame and arm an alarm for the +handshake timeout period {{QUIC-RECOVERY}}. When a corresponding PATH_RESPONSE +is received, the alarm is canceled. If the alarm fires without the client having +received a PATH_RESPONSE, the client may send a new PATH_CHALLENGE frame with +fresh random data and set the alarm again, but for twice the previous +period. Sending fresh random data allows a client to know which PATH_CHALLENGE +succeeded when a PATH_RESPONSE is received, yielding an unambiguous roundtrip +time sample. + +A client may conclude that it is unable to reach the server from the new address +and SHOULD abandon the new address when it does not receive a server's +PATH_RESPONSE after sending some number of PATH_CHALLENGE frames and/or after +some elapsed time. + +Servers MUST ignore a PATH_CHALLENGE frame from a client if the packet +containing it is smaller than 1200 octets. + +A server that receives a PATH_CHALLENGE frame responds by echoing the data from +the PATH_CHALLENGE frame in a PATH_RESPONSE frame (see +{{frame-path-response}}). In addition, the server MUST send a PATH_CHALLENGE +frame with its own validation data to verify the client's ownership of this new +address (see {{migration-validate}}). The server MUST bundle its PATH_RESPONSE +and its PATH_CHALLENGE in the same packet. + +The packet containing the server's PATH_RESPONSE and PATH_CHALLENGE MUST be +padded to the same size as the client's packet carrying the PATH_CHALLENGE, +enabling a client to confirm that this MTU size is supported by the network path +from the server to the client. + +The server need not retransmit its PATH_RESPONSE, since an interested client is +expected to persist and send a new PATH_CHALLENGE when a response is not +received for a prior one. + +Upon receiving a PATH_CHALLENGE frame from the server, a client responds by +echoing the data from the PATH_CHALLENGE frame in a PATH_RESPONSE frame. This +response MAY be bundled with other frames and does not require additional +padding. The client MAY send this response immediately to let a server finish +validation of the client's new address. Alternatively, the client MAY send this +response eventually when it commits to the migration ({{migration-commit}}). + +Upon receiving and validating the PATH_RESPONSE from the client, the server +considers the client's new address as valid. + + +### Committing to a Network Path {#migration-commit} When the client chooses to perform the migration, it sends a QUIC packet containing any frame type other than PATH_CHALLENGE, PATH_RESPONSE, or PADDING. From 5320b27b9744606d95fb53d25705609bf05fdbae Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Thu, 7 Dec 2017 03:09:27 -0800 Subject: [PATCH 12/33] section on committing --- draft-ietf-quic-transport.md | 86 ++++++++++++++++++++---------------- 1 file changed, 49 insertions(+), 37 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 382fe2092f..dee7806510 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1525,12 +1525,12 @@ some elapsed time. Servers MUST ignore a PATH_CHALLENGE frame from a client if the packet containing it is smaller than 1200 octets. -A server that receives a PATH_CHALLENGE frame responds by echoing the data from -the PATH_CHALLENGE frame in a PATH_RESPONSE frame (see -{{frame-path-response}}). In addition, the server MUST send a PATH_CHALLENGE -frame with its own validation data to verify the client's ownership of this new -address (see {{migration-validate}}). The server MUST bundle its PATH_RESPONSE -and its PATH_CHALLENGE in the same packet. +A server that receives a PATH_CHALLENGE frame from a client responds by echoing +the data in the frame in a PATH_RESPONSE frame (see {{frame-path-response}}). In +addition, the server MUST send a PATH_CHALLENGE frame with its own validation +data to verify the client's ownership of this new address (see +{{migration-validate}}). The server MUST bundle its PATH_RESPONSE and its +PATH_CHALLENGE in the same packet. The packet containing the server's PATH_RESPONSE and PATH_CHALLENGE MUST be padded to the same size as the client's packet carrying the PATH_CHALLENGE, @@ -1554,37 +1554,49 @@ considers the client's new address as valid. ### Committing to a Network Path {#migration-commit} -When the client chooses to perform the migration, it sends a QUIC packet -containing any frame type other than PATH_CHALLENGE, PATH_RESPONSE, or PADDING. -Upon receipt of such a packet from a different source IP address and port, the -server MUST begin sending all new packets with those as a destination IP address -and port. Similarly, once such a packet has been sent, the client has committed -to using the new path through the network and MUST stop sending new packets on -the old path. A client that continues to send new packets on the old path with -higher packet numbers than those sent on the new path will trigger an entirely -new migration back to that path. - -Upon migration to a new path, a server MUST validate the client over the new -path if it has not already done so, for example by completing the probing -mechanism in {{migration-probe}}. If the probing process has not yet completed, -or the client elected not to probe, the server can validate the client's new -source IP and port by sending a PATH_CHALLENGE frame containing a data field for -the client to echo. Note that the QUIC packet that includes this PATH_CHALLENGE -frame does not require additional padding. When the server receives the -corresponding PATH_RESPONSE frame containing the correctly echoed data, -validation of the client is complete. The server MAY send multiple -PATH_CHALLENGE frames in separate packets until it receives a -PATH_RESPONSE. - -Until the server has validated the the client's new address and port, it MUST -limit the amount of data that it sends to an unvalidated client, as described -with more detail in {{migration-validate}}. Without this limit, the server -risks being used for denial of service. - -Due to variations in path latency or packet reordering, packets from different -source addresses might be reordered. The packet with the highest packet number -MUST be used to determine which path to use. Endpoints also need to be prepared -to receive packets from an older source address. +A cient may commit to using a new address for sending all packets when it is the +only available address or after the client has established reachability from +that address. + +Upon receiving a packet from a new client address with a packet number that is +the largest seen thus far on the connection, containing a frame other than +PATH_CHALLENGE, PATH_RESPONSE, and PADDING, the server commits to the client's +new address. The server MUST send all subsequent packets, with the exception of +those containing PATH_RESPONSE and PATH_CHALLENGE frames, to the new address. + +Once committed to a new address, the client should stop sending any subsequent +packets from the old address. A client that sends new packets from the old +address with higher packet numbers than those sent from the new address will +cause the server to commit back to old address. + +Upon committing to a new address, a server MUST validate that the client is +reachable at the new address, if it has not already done so. This can happen if +the client-initiated probing process from the new address has not yet completed, +or if the client elected not to probe the server from the new address. + +When sending a packet carrying a frame other than PATH_CHALLENGE, PATH_RESPONSE, +or PADDING to a new client address that has not yet been validated, the server +MUST also send a PATH_CHALLENGE frame with random bytes to verify the client's +ownership of this new address (see {{migration-validate}}). + +The PATH_CHALLENGE frame need not be bundled with any other frame, and the +packet carrying this PATH_CHALLENGE frame does not need to be padded. + +(XXX I think we need to pad these packets for PMTU) + +When the server subsequently receives and verifies the contents of a +PATH_RESPONSE from the client against a previously sent PATH_CHALLENGE, the new +address is considered valid. + +The server MUST respond to every packet received from a not-yet-validated client +address with a PATH_CHALLENGE frame. The PATH_CHALLENGE MAY be bundled with +other frames, but one packet MUST NOT contain more than one PATH_CHALLENGE +frame. + +Until the client's new address is deemed valid, the server MUST limit the rate +at which it sends data to the new address; see {{migration-validate}}. In the +absence of this limit, the server risks being used for launching a denial of +service attack against an unsuspecting victim. ### Privacy Implications of Connection Migration {#migration-linkability} From 516f0100ff52a79ce152911443903e7575008ca2 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Thu, 7 Dec 2017 22:18:25 -0800 Subject: [PATCH 13/33] committing before I start pruning --- draft-ietf-quic-transport.md | 197 +++++++++++++++++++++++++++++------ 1 file changed, 163 insertions(+), 34 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index dee7806510..72f20b61a3 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1467,20 +1467,6 @@ collectively referred to as the client's address - such as those caused by a client migrating to a new network or a NAT rebinding changing the publicly observable client address. -A high-level summary of connection migration follows. A client desiring -migration to a new network may probe the new network for reachability and to get -a roundtrip-time measurement, while continuing to send and receive packets over -the extant network, see {{migration-probe}}. When the probe succeeds and if the -client decides to migrate, the client latches to the new network, sending all -packets over the new network. Alternatively, a client may latch to the new -network immediately without probing, such as would be the case when the only -network available to the client is the new network. A server that receives a -probe packet from a new client address simply responds to the probe. -Additionally, when a non-probe packet is received from a client on a new -address, the server issues a challenge: it sends random bytes to the client on -the new address. The server limits its rate to the new address until the client -echoes back the random bytes, validating the new address. - A client migrating to a new network MUST use a new connection ID for packets sent from the new address if an additional connection ID has been provided by the server, see {{migration-linkability}}. Using a new connection ID on @@ -1492,8 +1478,117 @@ A server that receives a packet for a known connection ID from a new client address SHOULD validate this new address, see {{migration-validate}}, +### Path Validation and PMTU Verification + +PATH_CHALLENGE ({{frame-path-challenge}}) and PATH_RESPONSE +({{frame-path-response}}) frames MAY be used for confirming that an endpoint +owns an address, or to verify the PMTU to/from an address. + +An endpoint validates a peer's address by sending a PATH_CHALLENGE frame +containing a payload that is hard to guess. This frame MUST be sent in a packet +to the new address. Once a PATH_RESPONSE frame containing the same payload is +received from the peer, the address is considered to be valid. A PATH_CHALLENGE +frame MUST contain at least 12 randomly generated octets {{?RFC4086}}, making +the payload sufficiently hard to guess. + +An endpoint SHOULD not generate two PATH_CHALLENGE frames with the same payload. + + +### Client Behavior {{migration-client}} + +When a new local address is available, a client MUST first send a packet +containing a PATH_CHALLENGE frame from this new address before sending any other +packets. The PATH_CHALLENGE frame MAY be bundled with other frames, but this +packet MUST be padded to 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 and +helps reduce the amplitude of amplification attacks caused by server responses +toward an unverified client address. + +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. The client SHOULD use fresh random data in each +PATH_CHALLENGE frame so that it can associate 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 that sent by the client 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 when 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. + +A client may receive a PATH challenge from a server that is validating the +client's ownership of an address. A client responds to this frame by echoing the +data from the PATH_CHALLENGE frame in a PATH_RESPONSE frame. This response MAY +be bundled with other frames and does not require additional padding. + + +### Server Behavior {{migration-server}} + +When a server receives a PATH_CHALLENGE frame from a client, it MUST respond by +copying the included data in a PATH_RESPONSE frame, and send it in a packet +padded to the size of the packet carrying the PATH_CHALLENGE. This PATH_RESPONSE +MUST be sent to the address that the PATH_CHALLENGE was received from. + +The server need not retransmit its PATH_RESPONSE, since an interested client is +expected to send more PATH_CHALLENGE frames when a response is not received for +a prior one. + +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 verify the client's ownership of this address. The server's PATH_CHALLENGE +MAY be bundled with other frames in a packet that does not need to be padded. + +When the server receives a PATH_RESPONSE from the client and verifies that the +included data matches that sent by the server in a previous PATH_CHALLENGE, the +server considers the client's 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. The server MUST use fresh random +data in each PATH_CHALLENGE frame so that it can associate the client's response +with the causative PATH_CHALLENGE. + +Until the client's new address is deemed valid, the server MUST limit the rate +at which it sends data to the new address to . In the absence of this limit, the +server risks being used for launching a denial of service attack against an +unsuspecting victim. + +Until a client's address is deemed valid, the server MUST limit the rate at +which it sends data to the address. The server SHOULD NOT send more than an +initial window's worth of bytes (as defined in {{QUIC-RECOVERY}}}) per roundtrip +time. In the absence of this limit, the server risks being used for launching a +denial of service attack against an unsuspecting victim. + +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, with the exception of +those containing PATH_RESPONSE and PATH_CHALLENGE frames, to this address. + + ### Probing a Network Path {#migration-probe} +A high-level summary of connection migration follows. A client desiring +migration to a new network may start sending data from a new address. A client +may also probe the new network for reachability and to get a roundtrip-time +measurement, while continuing to send and receive other packets over the extant +network, see {{migration-probe}}. When the probe succeeds and if the client +decides to migrate, the client latches to the new network, sending all packets +over the new network. Alternatively, a client may latch to the new network +immediately without probing, such as would be the case when the only network +available to the client is the new network. A server that receives a probe +packet from a new client address simply responds to the probe. Additionally, +when a non-probe packet is received from a client on a new address, the server +issues a challenge: it sends random bytes to the client on the new address. The +server limits its rate to the new address until the client echoes back the +random bytes, validating the new address. + When a new local address is available, a client MAY send a packet containing a PATH_CHALLENGE frame ({{frame-path-challenge}}) from this address to detect server reachability from it and to measure the roundtrip-time to the server from @@ -1503,10 +1598,18 @@ confirms that the network path from the client to the server supports an MTU of this size and helps reduce the amplitude of amplification attacks caused by server responses toward an unverified client address. -A client MAY send additional packets containing PATH_CHALLENGE frames to handle -packet loss or to get more measurements on the new network path. The client MUST -limit the number of such probes it considers outstanding in the network to limit -load on an untested network path. +A server that receives a PATH_CHALLENGE from a client responds by echoing the +data in the frame in a PATH_RESPONSE frame (see {{frame-path-response}}). The +server additionally sends its own PATH_CHALLENGE to the client, as discussed +further in {{migration-validate}}. + +When the client receives a PATH_RESPONSE from the server and verifies the +included data, the path is considered reachable. + +A client MAY send additional PATH_CHALLENGEs to handle packet loss or to get +more measurements on the new network path. The client MUST limit the number of +such probes it considers outstanding in the network to limit load on an untested +network path. For example, a client may send a PATH_CHALLENGE frame and arm an alarm for the handshake timeout period {{QUIC-RECOVERY}}. When a corresponding PATH_RESPONSE @@ -1525,11 +1628,37 @@ some elapsed time. Servers MUST ignore a PATH_CHALLENGE frame from a client if the packet containing it is smaller than 1200 octets. + +### Validating a New Client Address {#migration-validate} + + + with a PATH_CHALLENGE frame. The PATH_CHALLENGE MAY be bundled +with other frames, but one packet MUST NOT contain more than one PATH_CHALLENGE +frame. + +The server +MUST also send a PATH_CHALLENGE frame with random bytes to verify the client's +ownership of this new address (see {{migration-validate}}). + +The PATH_CHALLENGE frame need not be bundled with any other frame, and the +packet carrying this PATH_CHALLENGE frame does not need to be padded. + +(XXX I think we need to pad these packets for PMTU) + +When the server subsequently receives and verifies the contents of a +PATH_RESPONSE from the client against a previously sent PATH_CHALLENGE, the new +address is considered valid. + +Until the client's new address is deemed valid, the server MUST limit the rate +at which it sends data to the new address; see {{migration-validate}}. In the +absence of this limit, the server risks being used for launching a denial of +service attack against an unsuspecting victim. + A server that receives a PATH_CHALLENGE frame from a client responds by echoing the data in the frame in a PATH_RESPONSE frame (see {{frame-path-response}}). In addition, the server MUST send a PATH_CHALLENGE frame with its own validation data to verify the client's ownership of this new address (see -{{migration-validate}}). The server MUST bundle its PATH_RESPONSE and its +{{migration-validate}}). The server should bundle its PATH_RESPONSE and its PATH_CHALLENGE in the same packet. The packet containing the server's PATH_RESPONSE and PATH_CHALLENGE MUST be @@ -1552,17 +1681,18 @@ Upon receiving and validating the PATH_RESPONSE from the client, the server considers the client's new address as valid. -### Committing to a Network Path {#migration-commit} +### Committing to a New Address {#migration-commit} A cient may commit to using a new address for sending all packets when it is the only available address or after the client has established reachability from that address. -Upon receiving a packet from a new client address with a packet number that is -the largest seen thus far on the connection, containing a frame other than -PATH_CHALLENGE, PATH_RESPONSE, and PADDING, the server commits to the client's -new address. The server MUST send all subsequent packets, with the exception of -those containing PATH_RESPONSE and PATH_CHALLENGE frames, to the new address. +Upon receiving a packet containing a frame other than PATH_CHALLENGE, +PATH_RESPONSE, or PADDING from a new client address with a packet number that +is the largest seen thus far on the connection, the server commits to the +client's new address. The server MUST send all subsequent packets, with the +exception of those containing PATH_RESPONSE and PATH_CHALLENGE frames, to the +new address. Once committed to a new address, the client should stop sending any subsequent packets from the old address. A client that sends new packets from the old @@ -1580,9 +1710,7 @@ MUST also send a PATH_CHALLENGE frame with random bytes to verify the client's ownership of this new address (see {{migration-validate}}). The PATH_CHALLENGE frame need not be bundled with any other frame, and the -packet carrying this PATH_CHALLENGE frame does not need to be padded. - -(XXX I think we need to pad these packets for PMTU) +packet carrying this PATH_CHALLENGE frame is not required to be padded. When the server subsequently receives and verifies the contents of a PATH_RESPONSE from the client against a previously sent PATH_CHALLENGE, the new @@ -1593,10 +1721,11 @@ address with a PATH_CHALLENGE frame. The PATH_CHALLENGE MAY be bundled with other frames, but one packet MUST NOT contain more than one PATH_CHALLENGE frame. -Until the client's new address is deemed valid, the server MUST limit the rate -at which it sends data to the new address; see {{migration-validate}}. In the -absence of this limit, the server risks being used for launching a denial of -service attack against an unsuspecting victim. +Until a client's address is deemed valid, the server MUST limit the rate at +which it sends data to the address. The server SHOULD NOT send more than an +initial window's worth of bytes (as defined in {{QUIC-RECOVERY}}}) per roundtrip +time. In the absence of this limit, the server risks being used for launching a +denial of service attack against an unsuspecting victim. ### Privacy Implications of Connection Migration {#migration-linkability} @@ -1652,9 +1781,9 @@ number. "packet_number_secret" is derived from the TLS key exchange, as described in Section 5.6 of {{QUIC-TLS}}. -### Address Validation for Migrated Connections {#migration-validate} +### Validating a Client's New Address {#migration-validate} -An endpoint that receives a packet from a new remote IP address and port (or +A server that receives a packet from a new remote IP address and port (or just a new remote port) on packets from its peer is likely seeing a connection migration at the peer. From da2b65e01744fd2497d2a51999fa7565a32f53db Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Fri, 8 Dec 2017 00:17:56 -0800 Subject: [PATCH 14/33] first complete pass --- draft-ietf-quic-transport.md | 282 ++--------------------------------- 1 file changed, 14 insertions(+), 268 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 72f20b61a3..3d6e07003c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1554,178 +1554,33 @@ subject to the congestion controller's limits. The server MUST use fresh random data in each PATH_CHALLENGE frame so that it can associate the client's response with the causative PATH_CHALLENGE. -Until the client's new address is deemed valid, the server MUST limit the rate -at which it sends data to the new address to . In the absence of this limit, the -server risks being used for launching a denial of service attack against an -unsuspecting victim. - Until a client's address is deemed valid, the server MUST limit the rate at which it sends data to the address. The server SHOULD NOT send more than an initial window's worth of bytes (as defined in {{QUIC-RECOVERY}}}) per roundtrip time. In the absence of this limit, the server risks being used for launching a denial of service attack against an unsuspecting victim. +A server MAY skip address validation for a client address that it considers to +be already valid. + +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. + +After validating a client address, the server MAY send an updated address +validation token to the client ({{address-validation}}). + 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, with the exception of those containing PATH_RESPONSE and PATH_CHALLENGE frames, to this address. +When a server receives a packet from a new client address that causes it to +commit to this new address, it MUST abandon any address validation that may be +in progress to a different client address. The server MAY ignore any +subsequently received PATH_RESPONSE frames from the abandoned address. -### Probing a Network Path {#migration-probe} - -A high-level summary of connection migration follows. A client desiring -migration to a new network may start sending data from a new address. A client -may also probe the new network for reachability and to get a roundtrip-time -measurement, while continuing to send and receive other packets over the extant -network, see {{migration-probe}}. When the probe succeeds and if the client -decides to migrate, the client latches to the new network, sending all packets -over the new network. Alternatively, a client may latch to the new network -immediately without probing, such as would be the case when the only network -available to the client is the new network. A server that receives a probe -packet from a new client address simply responds to the probe. Additionally, -when a non-probe packet is received from a client on a new address, the server -issues a challenge: it sends random bytes to the client on the new address. The -server limits its rate to the new address until the client echoes back the -random bytes, validating the new address. - -When a new local address is available, a client MAY send a packet containing a -PATH_CHALLENGE frame ({{frame-path-challenge}}) from this address to detect -server reachability from it and to measure the roundtrip-time to the server from -it. This packet SHOULD be padded to 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 and helps reduce the amplitude of amplification attacks caused by -server responses toward an unverified client address. - -A server that receives a PATH_CHALLENGE from a client responds by echoing the -data in the frame in a PATH_RESPONSE frame (see {{frame-path-response}}). The -server additionally sends its own PATH_CHALLENGE to the client, as discussed -further in {{migration-validate}}. - -When the client receives a PATH_RESPONSE from the server and verifies the -included data, the path is considered reachable. - -A client MAY send additional PATH_CHALLENGEs to handle packet loss or to get -more measurements on the new network path. The client MUST limit the number of -such probes it considers outstanding in the network to limit load on an untested -network path. - -For example, a client may send a PATH_CHALLENGE frame and arm an alarm for the -handshake timeout period {{QUIC-RECOVERY}}. When a corresponding PATH_RESPONSE -is received, the alarm is canceled. If the alarm fires without the client having -received a PATH_RESPONSE, the client may send a new PATH_CHALLENGE frame with -fresh random data and set the alarm again, but for twice the previous -period. Sending fresh random data allows a client to know which PATH_CHALLENGE -succeeded when a PATH_RESPONSE is received, yielding an unambiguous roundtrip -time sample. - -A client may conclude that it is unable to reach the server from the new address -and SHOULD abandon the new address when it does not receive a server's -PATH_RESPONSE after sending some number of PATH_CHALLENGE frames and/or after -some elapsed time. - -Servers MUST ignore a PATH_CHALLENGE frame from a client if the packet -containing it is smaller than 1200 octets. - - -### Validating a New Client Address {#migration-validate} - - - with a PATH_CHALLENGE frame. The PATH_CHALLENGE MAY be bundled -with other frames, but one packet MUST NOT contain more than one PATH_CHALLENGE -frame. - -The server -MUST also send a PATH_CHALLENGE frame with random bytes to verify the client's -ownership of this new address (see {{migration-validate}}). - -The PATH_CHALLENGE frame need not be bundled with any other frame, and the -packet carrying this PATH_CHALLENGE frame does not need to be padded. - -(XXX I think we need to pad these packets for PMTU) - -When the server subsequently receives and verifies the contents of a -PATH_RESPONSE from the client against a previously sent PATH_CHALLENGE, the new -address is considered valid. - -Until the client's new address is deemed valid, the server MUST limit the rate -at which it sends data to the new address; see {{migration-validate}}. In the -absence of this limit, the server risks being used for launching a denial of -service attack against an unsuspecting victim. - -A server that receives a PATH_CHALLENGE frame from a client responds by echoing -the data in the frame in a PATH_RESPONSE frame (see {{frame-path-response}}). In -addition, the server MUST send a PATH_CHALLENGE frame with its own validation -data to verify the client's ownership of this new address (see -{{migration-validate}}). The server should bundle its PATH_RESPONSE and its -PATH_CHALLENGE in the same packet. - -The packet containing the server's PATH_RESPONSE and PATH_CHALLENGE MUST be -padded to the same size as the client's packet carrying the PATH_CHALLENGE, -enabling a client to confirm that this MTU size is supported by the network path -from the server to the client. - -The server need not retransmit its PATH_RESPONSE, since an interested client is -expected to persist and send a new PATH_CHALLENGE when a response is not -received for a prior one. - -Upon receiving a PATH_CHALLENGE frame from the server, a client responds by -echoing the data from the PATH_CHALLENGE frame in a PATH_RESPONSE frame. This -response MAY be bundled with other frames and does not require additional -padding. The client MAY send this response immediately to let a server finish -validation of the client's new address. Alternatively, the client MAY send this -response eventually when it commits to the migration ({{migration-commit}}). - -Upon receiving and validating the PATH_RESPONSE from the client, the server -considers the client's new address as valid. - - -### Committing to a New Address {#migration-commit} - -A cient may commit to using a new address for sending all packets when it is the -only available address or after the client has established reachability from -that address. - -Upon receiving a packet containing a frame other than PATH_CHALLENGE, -PATH_RESPONSE, or PADDING from a new client address with a packet number that -is the largest seen thus far on the connection, the server commits to the -client's new address. The server MUST send all subsequent packets, with the -exception of those containing PATH_RESPONSE and PATH_CHALLENGE frames, to the -new address. - -Once committed to a new address, the client should stop sending any subsequent -packets from the old address. A client that sends new packets from the old -address with higher packet numbers than those sent from the new address will -cause the server to commit back to old address. - -Upon committing to a new address, a server MUST validate that the client is -reachable at the new address, if it has not already done so. This can happen if -the client-initiated probing process from the new address has not yet completed, -or if the client elected not to probe the server from the new address. - -When sending a packet carrying a frame other than PATH_CHALLENGE, PATH_RESPONSE, -or PADDING to a new client address that has not yet been validated, the server -MUST also send a PATH_CHALLENGE frame with random bytes to verify the client's -ownership of this new address (see {{migration-validate}}). - -The PATH_CHALLENGE frame need not be bundled with any other frame, and the -packet carrying this PATH_CHALLENGE frame is not required to be padded. - -When the server subsequently receives and verifies the contents of a -PATH_RESPONSE from the client against a previously sent PATH_CHALLENGE, the new -address is considered valid. - -The server MUST respond to every packet received from a not-yet-validated client -address with a PATH_CHALLENGE frame. The PATH_CHALLENGE MAY be bundled with -other frames, but one packet MUST NOT contain more than one PATH_CHALLENGE -frame. - -Until a client's address is deemed valid, the server MUST limit the rate at -which it sends data to the address. The server SHOULD NOT send more than an -initial window's worth of bytes (as defined in {{QUIC-RECOVERY}}}) per roundtrip -time. In the absence of this limit, the server risks being used for launching a -denial of service attack against an unsuspecting victim. ### Privacy Implications of Connection Migration {#migration-linkability} @@ -1781,115 +1636,6 @@ number. "packet_number_secret" is derived from the TLS key exchange, as described in Section 5.6 of {{QUIC-TLS}}. -### Validating a Client's New Address {#migration-validate} - -A server that receives a packet from a new remote IP address and port (or -just a new remote port) on packets from its peer is likely seeing a connection -migration at the peer. - -However, it is also possible that the peer is spoofing its source address in -order to cause the endpoint to send excessive amounts of data to an unwilling -host. If the endpoint sends significantly more data than the peer, connection -migration might be used to amplify the volume of data that an attacker can -generate toward a victim. - -Thus, when seeing a new remote transport address, an endpoint MUST verify that -its peer can receive and respond to packets at that new address. By providing -copies of the data that it receives, the peer proves that it is receiving -packets at the new address and consents to receiving data. - -Prior to validating the new remote address, an endpoint MUST limit the amount -of data and packets that it sends to its peer. - -Retransmissions of packets that were originally sent on the previous path MUST -instead be sent on the new path, as allowed by the congestion controller. Any -losses detected on packets that were not sent on the new path SHOULD not count -as a loss event for the congestion control purposes. - -An endpoint validates a remote address by sending a PATH_CHALLENGE frame -containing a payload that is hard to guess. This frame MUST be sent in a packet -to the new address. Once a PATH_RESPONSE frame containing the same payload is -received, the address is considered to be valid. A PATH_CHALLENGE frame -containing 12 randomly generated {{?RFC4086}} octets is sufficient to ensure -that it is easier to receive the packet than it is to guess the value correctly. - -If the PATH_CHALLENGE frame is determined to be lost, a new PATH_CHALLENGE frame -SHOULD be generated. This PATH_CHALLENGE frame MUST include a new Data field -that is similarly difficult to guess. - -If validation of the new remote address fails, after allowing enough time for -possible loss and recovery of packets carrying PATH_CHALLENGE and their -associated PATH_RESPONSE frames, the endpoint MUST terminate the connection. -When setting this timer, implementations are cautioned that the new path could -have a longer round trip time than the original. The endpoint MUST NOT send a -CONNECTION_CLOSE frame in this case; it has to assume that the remote peer does -not want to receive any more packets. - -If the remote address is validated successfully, the endpoint MAY increase the -rate that it sends on the new path using the state from the previous path. The -capacity available on the new path might not be the same as the old path. An -endpoint MUST NOT restore its send rate unless it is reasonably sure that the -path is the same as the previous path. For instance, a change in only port -number is likely indicative of a rebinding in a middlebox and not a complete -change in path. This determination likely depends on heuristics, which could be -imperfect; if the new path capacity is significantly reduced, ultimately this -relies on the congestion controller responding to congestion signals and -reducing send rates appropriately. - -After verifying an address, the endpoint SHOULD update any address validation -tokens ({{address-validation}}) that it has issued to its peer if those are no -longer valid based on the changed address. - -A client MAY treat an incoming PATH_CHALLENGE frame that includes data as an -indication that the server’s view of the client’s address has changed. This -acts as a hint to the client that the network path may have changed, such as -when a NAT rebinding occurs. A server SHOULD NOT send a PATH_CHALLENGE frames -unless there is an observed change in the client’s address. - -Upon seeing a connection migration, an endpoint that sees a new address MUST -abandon any address validation it is performing with other addresses on the -expectation that the validation is likely to fail. Abandoning address -validation primarily means not closing the connection when a PATH_RESPONSE frame -is not received, but it could also mean ceasing retransmissions of the -PATH_CHALLENGE frame. An endpoint that doesn't retransmit a PATH_CHALLENGE -frame might receive a PATH_RESPONSE frame, which it MUST ignore. - - -### Spurious Connection Migrations {#migrate-spurious} - -A connection migration could be triggered by an attacker that is able to capture -and forward a packet such that it arrives before the legitimate copy of that -packet. Such a packet will appear to be a legitimate connection migration and -the legitimate copy will be dropped as a duplicate. - -After a spurious migration, validation of the source address will fail because -the entity at the source address does not have the necessary cryptographic keys -to read or respond to the PATH_CHALLENGE frame that is sent to it, even if it -wanted to. Such a spurious connection migration could result in the connection -being dropped when the source address validation fails. This grants an attacker -the ability to terminate the connection. - -Receipt of packets with higher packet numbers from the legitimate address will -trigger another connection migration. This will cause the validation of the -address of the spurious migration to be abandoned. - -To ensure that a peer sends packets from the legitimate address before the -validation of the new address can fail, an endpoint SHOULD attempt to validate -the old remote address before attempting to validate the new address. If the -connection migration is spurious, then the legitimate address will be used to -respond and the connection will migrate back to the old address. - -As with any address validation, packets containing retransmissions of the -PATH_CHALLENGE frame validating an address MUST be sent to the address being -validated. Consequently, during a migration of a peer, an endpoint could be -sending to multiple remote addresses. - -An endpoint MAY abandon address validation for an address that it considers to -be already valid. That is, if successive connection migrations occur in quick -succession with the final remote address being identical to the initial remote -address, the endpoint MAY abandon address validation for that address. - - ## Connection Termination {#termination} Connections should remain open until they become idle for a pre-negotiated From 88c44273583a424ebd32b86248b9c012c60073f3 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Fri, 8 Dec 2017 00:30:52 -0800 Subject: [PATCH 15/33] change abandon behavior --- draft-ietf-quic-transport.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 3d6e07003c..7790da9315 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1563,13 +1563,13 @@ denial of service attack against an unsuspecting victim. 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}}). + 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. -After validating a client address, the server MAY send an updated address -validation token to the client ({{address-validation}}). - 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 @@ -1577,10 +1577,10 @@ address. The server MUST send all subsequent packets, with the exception of those containing PATH_RESPONSE and PATH_CHALLENGE frames, to this address. When a server receives a packet from a new client address that causes it to -commit to this new address, it MUST abandon any address validation that may be -in progress to a different client address. The server MAY ignore any -subsequently received PATH_RESPONSE frames from the abandoned address. - +commit to this new address, it MAY abandon any address validation that may be in +progress to a different client address. The server however SHOULD NOT ignore +any subsequently received PATH_RESPONSE frames from the abandoned address, since +the server may need to revert back to this address if the new validation fails. ### Privacy Implications of Connection Migration {#migration-linkability} From 54283b860e4ccdd24e71e4729295f4c550c42374 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Fri, 8 Dec 2017 18:18:04 -0800 Subject: [PATCH 16/33] more structure and some more text --- draft-ietf-quic-transport.md | 88 ++++++++++++++++++++++++++++-------- 1 file changed, 69 insertions(+), 19 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 7790da9315..2f90963fbe 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1491,23 +1491,33 @@ received from the peer, the address is considered to be valid. A PATH_CHALLENGE frame MUST contain at least 12 randomly generated octets {{?RFC4086}}, making the payload sufficiently hard to guess. -An endpoint SHOULD not generate two PATH_CHALLENGE frames with the same payload. +An endpoint SHOULD generate a new random payload for every PATH_CHALLENGE frame +it sends, irrespective of the address it is sending from/to. ### Client Behavior {{migration-client}} -When a new local address is available, a client MUST first send a packet -containing a PATH_CHALLENGE frame from this new address before sending any other -packets. The PATH_CHALLENGE frame MAY be bundled with other frames, but this -packet MUST be padded to 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 and -helps reduce the amplitude of amplification attacks caused by server responses -toward an unverified client address. +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 a validation check that the server may +initiate to confirm the client's ownership of the new address. + + +#### Verifying the PMTU + +When the client intends to use a new local address, a client MUST first send a +packet containing a PATH_CHALLENGE frame from this new address before sending +any other packets. The PATH_CHALLENGE frame MAY be bundled with other frames, +but this packet MUST be padded to 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 and helps reduce the amplitude of amplification attacks caused by +server responses toward an unverified client address. 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. The client SHOULD use fresh random data in each +controller's limits. The client SHOULD use fresh random data in every PATH_CHALLENGE frame so that it can associate the server's response with the causative PATH_CHALLENGE. @@ -1522,23 +1532,45 @@ 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. -A client may receive a PATH challenge from a server that is validating the + +#### Responding to Server Validation + +A client may receive a PATH_CHALLENGE from a server that is validating the client's ownership of an address. A client responds to this frame by echoing the -data from the PATH_CHALLENGE frame in a PATH_RESPONSE frame. This response MAY -be bundled with other frames and does not require additional padding. +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. ### Server Behavior {{migration-server}} -When a server receives a PATH_CHALLENGE frame from a client, it MUST respond by -copying the included data in a PATH_RESPONSE frame, and send it in a packet -padded to the size of the packet carrying the PATH_CHALLENGE. This PATH_RESPONSE -MUST be sent to the address that the PATH_CHALLENGE was received from. +The server responds to any probes sent by the client from a new address, +participates in the client's PMTU verification, and MUST validate that the +client owns the new address. The server may choose to validate at any time, but +it MUST limit the rate at which data is sent to an unvalidated address, and it +MUST time bound the validation process. + + +#### Responding to 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, and send it in +a packet padded to the size of the client's packet that included the +PATH_CHALLENGE. This PATH_RESPONSE MUST be sent to the address from which the +PATH_CHALLENGE was received. The server need not retransmit its PATH_RESPONSE, since an interested client is expected to send more PATH_CHALLENGE frames when a response is not received for a prior one. + +#### Validating an Unvalidated Client Address + 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 verify the client's ownership of this address. The server's PATH_CHALLENGE @@ -1551,8 +1583,10 @@ was sent as valid. A server MAY send additional PATH_CHALLENGE frames to handle packet loss, subject to the congestion controller's limits. The server MUST use fresh random -data in each PATH_CHALLENGE frame so that it can associate the client's response -with the causative PATH_CHALLENGE. +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 the victim's address. Until a client's address is deemed valid, the server MUST limit the rate at which it sends data to the address. The server SHOULD NOT send more than an @@ -1570,12 +1604,28 @@ 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. + +#### 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, with the exception of those containing PATH_RESPONSE and PATH_CHALLENGE frames, to this address. +PATH_CHALLENGE, PATH_RESPONSE, and PADDING frames are used for probing a network +path, and a client MAY use them arbitrarily to check reachability to the server +from specific client addresses. 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 this packet is reordered, and therefore MUST +NOT cause the server to change its commitment. + +Upon committing to a new address, absent other information about the new path, +the server SHOULD reset its congestion controller and roundtrip time estimator +to start new estimations. + When a server receives a packet from a new client address that causes it to commit to this new address, it MAY abandon any address validation that may be in progress to a different client address. The server however SHOULD NOT ignore From 3a53131837dc3bdd4fa81d97db9c9b4b100048c1 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Sun, 10 Dec 2017 22:35:33 -0800 Subject: [PATCH 17/33] editorial changes and added section on loss detection --- draft-ietf-quic-transport.md | 201 +++++++++++++++++++++-------------- 1 file changed, 120 insertions(+), 81 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 2f90963fbe..8799777050 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1462,37 +1462,37 @@ connection if the integrity check fails with a PROTOCOL_VIOLATION error code. ## Connection Migration {#migration} QUIC connections are identified by 64-bit Connection IDs. QUIC's connection IDs -allow connections to survive changes to the client's IP address and/or port - -collectively referred to as the client's address - such as those caused by a -client migrating to a new network or a NAT rebinding changing the publicly -observable client address. - -A client migrating to a new network MUST use a new connection ID for packets -sent from the new address if an additional connection ID has been provided by -the server, see {{migration-linkability}}. Using a new connection ID on -migration makes it harder for passive observers to track connections migrating -across networks. A client may be unaware of connection migration due to NAT -rebinding and may consequently not change its connection ID on NAT rebindings. +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. + +A client migrating to a new network SHOULD use a new connection ID for packets +sent from the new address if at all possible, as discussed in +{{migration-linkability}}. A client may be unaware of connection migration due +to NAT rebinding and may consequently not change its connection ID on NAT +rebindings. A server that receives a packet for a known connection ID from a new client -address SHOULD validate this new address, see {{migration-validate}}, +address SHOULD validate this new address, as discussed in +{{migration-validate}}, ### Path Validation and PMTU Verification PATH_CHALLENGE ({{frame-path-challenge}}) and PATH_RESPONSE -({{frame-path-response}}) frames MAY be used for confirming that an endpoint +({{frame-path-response}}) frames MAY be used for validating that an endpoint owns an address, or to verify the PMTU to/from an address. -An endpoint validates a peer's address by sending a PATH_CHALLENGE frame -containing a payload that is hard to guess. This frame MUST be sent in a packet -to the new address. Once a PATH_RESPONSE frame containing the same payload is -received from the peer, the address is considered to be valid. A PATH_CHALLENGE -frame MUST contain at least 12 randomly generated octets {{?RFC4086}}, making -the payload sufficiently hard to guess. +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. -An endpoint SHOULD generate a new random payload for every PATH_CHALLENGE frame -it sends, irrespective of the address it is sending from/to. +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}} @@ -1500,44 +1500,48 @@ it sends, irrespective of the address it is sending from/to. 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 a validation check that the server may -initiate to confirm the client's ownership of the new address. +complete. The client also participates in a validation that the server may +initiate to confirm the client's ownership of its address (see +{{migration-server}}). #### Verifying the PMTU -When the client intends to use a new local address, a client MUST first send a -packet containing a PATH_CHALLENGE frame from this new address before sending -any other packets. The PATH_CHALLENGE frame MAY be bundled with other frames, -but this packet MUST be padded to 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 and helps reduce the amplitude of amplification attacks caused by -server responses toward an unverified client address. +When the client intends to use a new local address, it MAY establish server +reachability from the new address, and it SHOULD verify the new path's MTU. To +achieve these ends, the client sends a packet containing a PATH_CHALLENGE frame +from this new address before sending any other packets. The PATH_CHALLENGE +frame MAY be bundled with other frames, but this packet MUST be padded to +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. The client SHOULD use fresh random data in every -PATH_CHALLENGE frame so that it can associate the server's response with the -causative PATH_CHALLENGE. +controller's limits. + +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 that sent by the client 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. +included data matches that sent by the client in a previously sent +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 when it does not receive a PATH_RESPONSE +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 Server Validation +#### Responding to Server's Validation A client may receive a PATH_CHALLENGE from a server that is validating the -client's ownership of an address. A client responds to this frame by echoing the -data from the server's PATH_CHALLENGE frame in a PATH_RESPONSE frame. +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. @@ -1546,14 +1550,24 @@ 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 +server when the client is not actively changing addresses may be indicative of +other network activity causing its public address to change, or it may be +indicative of a server choosing to validate a client's address after a period of +quiescence. + ### Server Behavior {{migration-server}} The server responds to any probes sent by the client from a new address, participates in the client's PMTU verification, and MUST validate that the -client owns the new address. The server may choose to validate at any time, but -it MUST limit the rate at which data is sent to an unvalidated address, and it -MUST time bound the validation process. +client owns its new address. The server MAY validate any client's address at +any time, 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 Client's Probe @@ -1564,35 +1578,45 @@ a packet padded to the size of the client's packet that included the PATH_CHALLENGE. This PATH_RESPONSE MUST be sent to the address from which the PATH_CHALLENGE was received. -The server need not retransmit its PATH_RESPONSE, since an interested client is -expected to send more PATH_CHALLENGE frames when a response is not received for -a prior one. +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. #### Validating an Unvalidated Client Address 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 verify the client's ownership of this address. The server's PATH_CHALLENGE -MAY be bundled with other frames in a packet that does not need to be padded. +to this address to verify the client's ownership of it. The server's +PATH_CHALLENGE MAY be bundled with other frames in a packet that does not need +to be padded. -When the server receives a PATH_RESPONSE from the client and verifies that the -included data matches that sent by the server in a previous PATH_CHALLENGE, the -server considers the client's address to which the corresponding PATH_CHALLENGE -was sent as valid. +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. 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 the victim's address. - -Until a client's address is deemed valid, the server MUST limit the rate at -which it sends data to the address. The server SHOULD NOT send more than an -initial window's worth of bytes (as defined in {{QUIC-RECOVERY}}}) per roundtrip -time. In the absence of this limit, the server risks being used for launching a -denial of service attack against an unsuspecting victim. +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. + +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 +silently, and discard any further packets received from the client for this +connection. A server MAY skip address validation for a client address that it considers to be already valid. @@ -1600,37 +1624,52 @@ be already valid. After validating a client address, the server MAY send an updated address validation token to the client ({{address-validation}}). -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. - #### 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 +largest seen thus far on the connection, the server "commits" to this client address. The server MUST send all subsequent packets, with the exception of those containing PATH_RESPONSE and PATH_CHALLENGE frames, to this address. PATH_CHALLENGE, PATH_RESPONSE, and PADDING frames are used for probing a network -path, and a client MAY use them arbitrarily to check reachability to the server -from specific client addresses. Receiving only these frames MUST NOT cause the -server to commit to a new address. +path. Receiving 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 this packet is reordered, and therefore MUST -NOT cause the server to change its commitment. +largest seen thus far suggests that a reordered packet was received and MUST NOT +cause the server to change its commitment. + +Upon committing to a new address, the server SHOULD reset its congestion +controller and roundtrip time estimator to start new estimations. -Upon committing to a new address, absent other information about the new path, -the server SHOULD reset its congestion controller and roundtrip time estimator -to start new estimations. When a server receives a packet from a new client address that causes it to -commit to this new address, it MAY abandon any address validation that may be in -progress to a different client address. The server however SHOULD NOT ignore -any subsequently received PATH_RESPONSE frames from the abandoned address, since -the server may need to revert back to this address if the new validation fails. +commit to this new address, it may still need to validate the new client +address. The server MAY abandon any address validation already in progress to a +different client address. The server however SHOULD NOT ignore any subsequently +received PATH_RESPONSE frames from the abandoned address, since the server may +need to revert back to a validated but abandoned address if the later validation +fails. + + +### 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 +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. ### Privacy Implications of Connection Migration {#migration-linkability} From c18d79c9214b2eff26ed9abc877763b2f4913fa7 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Sun, 10 Dec 2017 23:01:51 -0800 Subject: [PATCH 18/33] added PING frame back in --- draft-ietf-quic-transport.md | 115 +++++++++++++++++++++-------------- 1 file changed, 71 insertions(+), 44 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 8799777050..4c911c7d99 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -838,14 +838,15 @@ explained in more detail as they are referenced later in the document. | 0x04 | MAX_DATA | {{frame-max-data}} | | 0x05 | MAX_STREAM_DATA | {{frame-max-stream-data}} | | 0x06 | MAX_STREAM_ID | {{frame-max-stream-id}} | -| 0x07 | PATH_CHALLENGE | {{frame-path-challenge}} | +| 0x07 | PING | {{frame-ping}} | | 0x08 | BLOCKED | {{frame-blocked}} | | 0x09 | STREAM_BLOCKED | {{frame-stream-blocked}} | | 0x0a | STREAM_ID_BLOCKED | {{frame-stream-id-blocked}} | | 0x0b | NEW_CONNECTION_ID | {{frame-new-connection-id}} | | 0x0c | STOP_SENDING | {{frame-stop-sending}} | -| 0x0d | PATH_RESPONSE | {{frame-path-response}} | -| 0x0e | ACK | {{frame-ack}} | +| 0x0d | ACK | {{frame-ack}} | +| 0x0e | PATH_CHALLENGE | {{frame-path-challenge}} | +| 0x0f | PATH_RESPONSE | {{frame-path-response}} | | 0x10 - 0x17 | STREAM | {{frame-stream}} | {: #frame-types title="Frame Types"} @@ -2212,40 +2213,29 @@ than it has sent, unless this is a result of a change in the initial limits (see {{zerortt-parameters}}). -## PATH_CHALLENGE Frame {#frame-path-challenge} +## PING Frame {#frame-ping} -Endpoints can use PATH_CHALLENGE frames (type=0x07) to verify that their peers -are still alive or to check reachability to the peer. A PATH_CHALLENGE frame can -also carry arbitrary data to perform address validation during connection -migration. +Endpoints can use PING frames (type=0x07) to verify that their peers are still +alive or to check reachability to the peer. The PING frame contains no +additional fields. The receiver of a PING frame simply needs to acknowledge the +packet containing this frame. -PATH_CHALLENGE frames contain a variable-length payload. +A PING frame has no additional fields. -~~~ - 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 (*) ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~~~ +The PING frame can be used to keep a connection alive when an application or +application protocol wishes to prevent the connection from timing out. An +application protocol SHOULD provide guidance about the conditions under which +generating a PING is recommended. This guidance SHOULD indicate whether it is +the client or the server that is expected to send the PING. Having both +endpoints send PING frames without coordination can produce an excessive number +of packets and poor performance. -Length: - -: This 8-bit value describes the length of the Data field. - -Data: - -: This variable-length field contains arbitrary data. - -If the Data field is not empty, the recipient of this frame MUST generate a -PATH_RESPONSE frame ({{frame-path-response}}) containing the same Data. - -A PATH_CHALLENGE frame MUST NOT elicit acknowledgements, as a valid -PATH_RESPONSE serves to indicate receipt of the PATH_CHALLENGE. These frames are -not included in loss recovery, as they will be retransmitted separately. - -A packet containing a PATH_CHALLENGE frame with a non-empty Data field MUST be -padded such that it has a QUIC packet size of least 1200 octets. +A connection will time out if no packets are sent or received for a period +longer than the time specified in the idle_timeout transport parameter (see +{{termination}}). However, state in middleboxes might time out earlier than +that. Though REQ-5 in {{?RFC4787}} recommends a 2 minute timeout interval, +experience shows that sending packets every 15 to 30 seconds is necessary to +prevent the majority of middleboxes from losing state for UDP flows. ## BLOCKED Frame {#frame-blocked} @@ -2370,18 +2360,56 @@ Application Error Code: {{app-error-codes}}). +## PATH_CHALLENGE Frame {#frame-path-challenge} + +Endpoints can use PATH_CHALLENGE frames (type=0x07) to check reachability to the +peer, to verify a new path's PMTU, and to perform address validation during +connection migration. + +PATH_CHALLENGE frames contain a variable-length payload. + +~~~ + 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. + + +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, 0x0d). + +A PATH_CHALLENGE frame MUST NOT elicit acknowledgements; the corresponding +PATH_RESPONSE serves to indicate receipt of the PATH_CHALLENGE. + + ## PATH_RESPONSE Frame {#frame-path-response} The PATH_RESPONSE frame (type=0x0d) is sent in response to a PATH_CHALLENGE -frame that contains data. Its format is identical to the PATH_CHALLENGE frame +frame. Its format is identical to the PATH_CHALLENGE frame ({{frame-path-challenge}}). -An endpoint that receives an unsolicited PATH_RESPONSE frame - that is, a -PATH_RESPONSE frame containing a payload that is empty - MUST generate a -connection error of type FRAME_ERROR, indicating the PATH_RESPONSE frame (that -is, 0x0d). 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. +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. + +A PATH_RESPONSE frame MUST NOT elicit acknowledgements. ## ACK Frame {#frame-ack} @@ -2558,8 +2586,7 @@ acknowledged again. A receiver that is only sending ACK frames will not receive acknowledgments for its packets. Sending an occasional MAX_DATA or MAX_STREAM_DATA frame as data is received will ensure that acknowledgements are generated by a peer. Otherwise, -an endpoint MAY send a PATH_CHALLENGE frame once per RTT to solicit an -acknowledgment. +an endpoint MAY send a PING frame once per RTT to solicit an acknowledgment. To limit receiver state or the size of ACK frames, a receiver MAY limit the number of ACK blocks it sends. A receiver can do this even without receiving @@ -3769,8 +3796,8 @@ Issue and pull request numbers are listed with a leading octothorp. - Employ variable-length integer encodings throughout (#595) - Draining period can terminate early (#869) -- Replace PING and PONG frames with PATH_CHALLENGE and PATH_RESPONSE frames, - clarify connection migration text (#000) +- Added PATH_CHALLENGE and PATH_RESPONSE frames, removed PING with Data, + and rewrote connection migration (#000) ## Since draft-ietf-quic-transport-06 From b98920aaa001f37da8011301e05eb63864c20b57 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 11 Dec 2017 22:29:42 -0800 Subject: [PATCH 19/33] ekinnear's comments and some wordsmithing --- draft-ietf-quic-transport.md | 95 ++++++++++++++++++------------------ 1 file changed, 47 insertions(+), 48 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 4c911c7d99..7245b0ae8a 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1462,21 +1462,11 @@ connection if the integrity check fails with a PROTOCOL_VIOLATION error code. ## Connection Migration {#migration} -QUIC connections are identified by 64-bit Connection IDs. QUIC's connection IDs +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. -A client migrating to a new network SHOULD use a new connection ID for packets -sent from the new address if at all possible, as discussed in -{{migration-linkability}}. A client may be unaware of connection migration due -to NAT rebinding and may consequently not change its connection ID on NAT -rebindings. - -A server that receives a packet for a known connection ID from a new client -address SHOULD validate this new address, as discussed in -{{migration-validate}}, - ### Path Validation and PMTU Verification @@ -1496,15 +1486,20 @@ containing the same payload sent by the server to the new client address is received. -### Client Behavior {{migration-client}} +### 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 a validation that the server may -initiate to confirm the client's ownership of its address (see +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 SHOULD use a new connection ID for packets +sent from the new address if at all possible, see {{migration-linkability}} for +further discussion. A client may be unaware of connection migration due to NAT +rebinding and may consequently not change its connection ID on NAT rebindings. + #### Verifying the PMTU @@ -1519,16 +1514,16 @@ 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. +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 that sent by the client in a previously sent -PATH_CHALLENGE, the server is considered reachable from the new address and the -PMTU of the new network path is considered verified. +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 @@ -1537,7 +1532,7 @@ period, but not receiving a PATH_RESPONSE may be indicative of a PMTU detection failure. -#### Responding to Server's Validation +#### 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 @@ -1561,36 +1556,43 @@ indicative of a server choosing to validate a client's address after a period of quiescence. -### Server Behavior {{migration-server}} +### Server Behavior {#migration-server} The server responds to any probes sent by the client from a new address, -participates in the client's PMTU verification, and MUST validate that the -client owns its new address. The server MAY validate any client's address at -any time, 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. +participates in the client's PMTU verification, and validates that the client +owns the new address. The server MAY validate any client's address at any time, +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 Client's Probe +#### 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, and send it in -a packet padded to the size of the client's packet that included the -PATH_CHALLENGE. This PATH_RESPONSE MUST be sent to the address from which the -PATH_CHALLENGE was received. +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. +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 +#### 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 in a packet that does not need -to be padded. +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 @@ -1631,12 +1633,10 @@ validation token to the client ({{address-validation}}). 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, with the exception of -those containing PATH_RESPONSE and PATH_CHALLENGE frames, to this address. - -PATH_CHALLENGE, PATH_RESPONSE, and PADDING frames are used for probing a network -path. Receiving these frames MUST NOT cause the server to commit to a new -address. +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 @@ -1645,7 +1645,6 @@ cause the server to change its commitment. Upon committing to a new address, the server SHOULD reset its congestion controller and roundtrip time estimator to start new estimations. - When a server receives a packet from a new client address that causes it to commit to this new address, it may still need to validate the new client address. The server MAY abandon any address validation already in progress to a @@ -2217,10 +2216,10 @@ than it has sent, unless this is a result of a change in the initial limits (see Endpoints can use PING frames (type=0x07) to verify that their peers are still alive or to check reachability to the peer. The PING frame contains no -additional fields. The receiver of a PING frame simply needs to acknowledge the -packet containing this frame. +additional fields. -A PING frame has no additional fields. +The receiver of a PING frame simply needs to acknowledge the packet containing +this frame. The PING frame can be used to keep a connection alive when an application or application protocol wishes to prevent the connection from timing out. An @@ -2362,7 +2361,7 @@ Application Error Code: ## PATH_CHALLENGE Frame {#frame-path-challenge} -Endpoints can use PATH_CHALLENGE frames (type=0x07) to check reachability to the +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. @@ -2391,7 +2390,7 @@ 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, 0x0d). +error of type FRAME_ERROR, indicating the PATH_CHALLENGE frame (that is, 0x0e). A PATH_CHALLENGE frame MUST NOT elicit acknowledgements; the corresponding PATH_RESPONSE serves to indicate receipt of the PATH_CHALLENGE. @@ -2399,7 +2398,7 @@ PATH_RESPONSE serves to indicate receipt of the PATH_CHALLENGE. ## PATH_RESPONSE Frame {#frame-path-response} -The PATH_RESPONSE frame (type=0x0d) is sent in response to a PATH_CHALLENGE +The PATH_RESPONSE frame (type=0x0f) is sent in response to a PATH_CHALLENGE frame. Its format is identical to the PATH_CHALLENGE frame ({{frame-path-challenge}}). @@ -3796,8 +3795,8 @@ Issue and pull request numbers are listed with a leading octothorp. - Employ variable-length integer encodings throughout (#595) - Draining period can terminate early (#869) -- Added PATH_CHALLENGE and PATH_RESPONSE frames, removed PING with Data, - and rewrote connection migration (#000) +- Added PATH_CHALLENGE and PATH_RESPONSE frames, removed PING with Data, removed + PONG frame and rewrote connection migration (#000) ## Since draft-ietf-quic-transport-06 From 3e8b8411882d9411bc0ede7bc1d51cad3909b371 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Tue, 12 Dec 2017 14:17:06 -0800 Subject: [PATCH 20/33] remove unnecessary normative --- draft-ietf-quic-transport.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 7245b0ae8a..64fbfc88c3 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -282,7 +282,7 @@ processing. QUIC connections are identified by a Connection ID, a 64-bit unsigned number randomly generated by the server. QUIC's consistent connection ID allows connections to survive changes to the client's IP and port, such as those caused -by NAT rebindings or by the client changing network connectivity to a new +by NAT rebinding or by the client changing network connectivity to a new address. QUIC provides automatic cryptographic verification of a rebound client, since the client continues to use the same session key for encrypting and decrypting packets. The consistent connection ID can be used to allow migration @@ -1495,10 +1495,8 @@ 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 SHOULD use a new connection ID for packets -sent from the new address if at all possible, see {{migration-linkability}} for -further discussion. A client may be unaware of connection migration due to NAT -rebinding and may consequently not change its connection ID on NAT rebindings. +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. #### Verifying the PMTU From d7c94457c027844feeb7bd00c6b15d69df57f4bd Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Thu, 8 Feb 2018 19:32:29 -0800 Subject: [PATCH 21/33] sync --- draft-ietf-quic-transport.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 9e96ea7914..4336e90f74 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1481,11 +1481,9 @@ connection if the integrity check fails with a PROTOCOL_VIOLATION error code. ## Connection Migration {#migration} -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. - +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. ### Path Validation and PMTU Verification From 138ed423d7365ab73d2676e08917cff3bf3e1d96 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Thu, 8 Feb 2018 23:14:58 -0800 Subject: [PATCH 22/33] first cut at rewrite --- draft-ietf-quic-transport.md | 378 +++++++++++------------------------ 1 file changed, 116 insertions(+), 262 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 4336e90f74..f719eda303 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1483,194 +1483,163 @@ connection if the integrity check fails with a PROTOCOL_VIOLATION error code. 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. +migrating to a new network. This specification covers connection migration to a +new client address; connection migration to a new server address is explicitly +not specified. -### Path Validation and PMTU Verification +### Address Validation {#migrate-validate} -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. +Address validation is used by a server to confirm client ownership of a new +address, and by a client to establish reachability to the server from a new +local address. -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. +To start address validation, an endpoint sends a PATH_CHALLENGE frame containing +a payload that is hard to guess from or to the address to be validated. -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. +On receiving a PATH_CHALLENGE frame, the peer MUST immediately respond by +echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame. +The PATH_RESPONSE MUST be sent on the same path: from the same local address on +which the PATH_CHALLENGE was received, and to the same remote address from which +the PATH_CHALLENGE was received. +The endpoint considers the address to be valid when a PATH_RESPONSE frame +containing the same payload is received from the peer. -### 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. - - -#### Verifying the PMTU - -When the client intends to use a new local address, it MAY establish server -reachability from the new address, and it SHOULD verify the new path's MTU. To -achieve these ends, the client sends a packet containing a PATH_CHALLENGE frame -from this new address before sending any other packets. The PATH_CHALLENGE -frame MAY be bundled with other frames, but this packet MUST be padded to -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. - -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. - -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 -server when the client is not actively changing addresses may be indicative of -other network activity causing its public address to change, or it may be -indicative of a server choosing to validate a client's address after a period of -quiescence. +The new address is not considered valid until a PATH_RESPONSE frame containing +the same payload is received, even if the packet containing the PATH_CHALLENGE +frame is acknowledged. +The PATH_RESPONSE frame MUST be received from the same peer address to which the +corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received from +a different peer address than the one to which the PATH_CHALLENGE was sent, +address validation is considered to have failed, even if the data matches that +sent in the PATH_CHALLENGE. -### Server Behavior {#migration-server} +The PATH_RESPONSE frame MUST be received on the same local address from which +the corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received +on a different local address than the one from which the PATH_CHALLENGE was +sent, address validation is considered to have failed, even if the data matches +that sent in the PATH_CHALLENGE. -The server responds to any probes sent by the client from a new address, -participates in the client's PMTU verification, and validates that the client -owns the new address. The server MAY validate any client's address at any time, -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. +The endpoint MAY send additional PATH_CHALLENGE frames to handle packet loss, +subject to the congestion controller's limits. +The endpoint MUST use fresh random data in every PATH_CHALLENGE frame so that it +can associate the peer's response with the causative PATH_CHALLENGE. Not using +fresh random data risks exposing the endpoint to an attacker defeating +validation by sending a spoofed PATH_RESPONSE from a victim's address. -#### Responding to a Client's Probe +The endpoint 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 peer's address validation. -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 endpoint SHOULD abandon address validation after sending some number of +PATH_CHALLENGE frames or after some time has passed. When setting this timer, +implementations are cautioned that the new path could have a longer roundtrip +time than the original. The endpoint may receive packets containing other frames +during this period, but a PATH_RESPONSE frame with appropriate data is required +for the address validation to succeed. -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. +Address validation using the PATH_CHALLENGE frame MAY be used at any time by +either endpoint. For instance, an endpoint might check that a peer is still in +possession of its address after a period of quiescence. -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. +### Client Behavior +A client with a new address may migrate the connection by simply sending all +packets to the new address. -#### Validating an Unvalidated Client Address {#migration-validate} +Before sending data from the new address, a client MAY check server reachability +from the new address using address validation {{address-validation}}. -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. +A client migrating to a new address SHOULD use a new connection ID for packets +sent from the new address, see {{migration-linkability}} for further discussion. -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. +### Server Behavior -A PATH_CHALLENGE frame used for validation MUST contain at least 12 randomly -generated octets {{?RFC4086}}, making the payload sufficiently hard to guess. +A server that receives a packet from a new client address is likely seeing a +connection migration at the client. -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. +However, it is also possible that the client is spoofing its source address in +order to cause the server to send excessive amounts of data to an unwilling +host. If the server sends significantly more data than the client, connection +migration might be used to amplify the volume of data that an attacker can +generate toward a victim. -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. +Thus, on receiving and decrypting a packet with a known connection ID but from +an unvalidated address, the server MUST immediately validate the client's new +address to confirm the client's possession of the new address. -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 -silently, and discard any further packets received from the client for this -connection. +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 +bytes per estimated initial RTO period (as defined in {{QUIC-RECOVERY}}). In +the absence of this limit, the server risks being used for a denial of service +attack against an unsuspecting victim. 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. +address. The server MUST send all subsequent packets to this address. +PATH_CHALLENGE, PATH_RESPONSE, and PADDING frames are used for reachability +checks, and receiving only these frames from a new address MUST NOT cause the +server to commit to that address. Receiving a packet from a new address but with a packet number that is not the largest seen thus far suggests that a reordered packet was received and MUST NOT cause the server to change its commitment. -Upon committing to a new address, the server SHOULD reset its congestion -controller and roundtrip time estimator to start new estimations. +A client that has ownership of only the new address may switch to sending all +data from that address. The server MAY commit to the new client address prior to +validating that address. + +Upon receiving packets from a new client address, the server MUST abandon any +address validation it is performing with other addresses on the expectation that +those validations are likely to fail. Abandoning address validation primarily +means ceasing subsequent transmissions of the PATH_CHALLENGE frame. An endpoint +MUST ignore any subsequently received PATH_RESPONSE frames from abandoned +addresses. + +An attacker could cause a spurious connection migration by capturing and +forwarding a packet such that it arrives before the legitimate copy of that +packet. Such a packet will appear to be a legitimate connection migration and +the legitimate copy will be dropped as a duplicate. After a spurious migration, +validation of the source address will fail because the entity at the source +address does not have the necessary cryptographic keys to read or respond to the +PATH_CHALLENGE frame that is sent to it, even if it wanted to. + +To protect the connection from failing due to such a spurious migration, the +server MUST revert to using the last validated client address when validation of +a new client address fails. If the server has no state about the last validated +client address, it MUST close the connection silently and discard any further +packets received from the client for this connection. -When a server receives a packet from a new client address that causes it to -commit to this new address, it may still need to validate the new client -address. The server MAY abandon any address validation already in progress to a -different client address. The server however SHOULD NOT ignore any subsequently -received PATH_RESPONSE frames from the abandoned address, since the server may -need to revert back to a validated but abandoned address if the later validation -fails. +We note that receipt of packets with higher packet numbers from the legitimate +address will trigger another connection migration. This will cause the +validation of the address of the spurious migration to be abandoned. + +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. ### Loss Detection and Congestion Control +The capacity available on the new path might not be the same as the old path. +If the peer's address is validated successfully, the endpoint SHOULD reset its +congestion controller and roundtrip time estimator prior to sending any data to +the new address. An endpoint MUST NOT restore its send rate unless it is +reasonably sure that the path is the same as the previous path. For instance, a +change in only port number is likely indicative of a rebinding in a middlebox +and not a complete change in path. This determination likely depends on +heuristics, which could be imperfect; if the new path capacity is significantly +reduced, ultimately this relies on the congestion controller responding to +congestion signals and reduce send rates appropriately. + There may be apparent reordering at the receiver when an endpoint sends data and probes from/to multiple addresses during the migration period, since the two resulting paths may have different rountrip times. A receiver of packets on @@ -1740,121 +1709,6 @@ number. "packet_number_secret" is derived from the TLS key exchange, as described in Section 5.6 of {{QUIC-TLS}}. -### Address Validation for Migrated Connections {#migrate-validate} - -An endpoint that receives a packet from a new remote IP address and port (or -just a new remote port) on packets from its peer is likely seeing a connection -migration at the peer. - -However, it is also possible that the peer is spoofing its source address in -order to cause the endpoint to send excessive amounts of data to an unwilling -host. If the endpoint sends significantly more data than the peer, connection -migration might be used to amplify the volume of data that an attacker can -generate toward a victim. - -Thus, when seeing a new remote transport address, an endpoint MUST verify that -its peer can receive and respond to packets at that new address. By providing -copies of the data that it receives, the peer proves that it is receiving -packets at the new address and consents to receive data. - -Prior to validating the new remote address, and endpoint MUST limit the amount -of data and packets that it sends to its peer. At a minimum, this needs to -consider the possibility that packets are sent without congestion feedback. - -Once a connection is established, address validation is relatively simple (see -{{address-validation}} for the process that is used during the handshake). An -endpoint validates a remote address by sending a PATH_CHALLENGE frame containing -a payload that is hard to guess. This frame MUST be sent in a packet that is -sent to the new address. Once a PATH_RESPONSE frame containing the same payload -is received, the address is considered to be valid. - -The new address is not considered valid until a PATH_RESPONSE frame containing -the same payload is received, even if the packet containing the PATH_CHALLENGE -frame is acknowledged. - -The PATH_RESPONSE frame can use any path on its return. - -An endpoint MAY send multiple PATH_CHALLENGE frames to handle packet loss or to -make additional measurements on a new network path. - -An endpoint MUST use fresh random data in every PATH_CHALLENGE frame so that it -can associate the peer's response with the causative PATH_CHALLENGE. - -If the PATH_CHALLENGE frame is determined to be lost, a new PATH_CHALLENGE frame -SHOULD be generated. This PATH_CHALLENGE frame MUST include new data that is -similarly difficult to guess. - -If validation of the new remote address fails, after allowing enough time for -recovering from possible loss of packets carrying PATH_CHALLENGE and -PATH_RESPONSE frames, the endpoint MUST terminate the connection. When setting -this timer, implementations are cautioned that the new path could have a longer -round trip time than the original. The endpoint MUST NOT send a -CONNECTION_CLOSE frame in this case; it has to assume that the remote peer -cannot want to receive any more packets. - -If the remote address is validated successfully, the endpoint MAY increase the -rate that it sends on the new path using the state from the previous path. The -capacity available on the new path might not be the same as the old path. An -endpoint MUST NOT restore its send rate unless it is reasonably sure that the -path is the same as the previous path. For instance, a change in only port -number is likely indicative of a rebinding in a middlebox and not a complete -change in path. This determination likely depends on heuristics, which could be -imperfect; if the new path capacity is significantly reduced, ultimately this -relies on the congestion controller responding to congestion signals and reduce -send rates appropriately. - -After verifying an address, the endpoint SHOULD update any address validation -tokens ({{address-validation}}) that it has issued to its peer if those are no -longer valid based on the changed address. - -Address validation using the PATH_CHALLENGE frame MAY be used at any time by -either peer. For instance, an endpoint might check that a peer is still in -possession of its address after a period of quiescence. - -Upon seeing a connection migration, an endpoint that sees a new address MUST -abandon any address validation it is performing with other addresses on the -expectation that the validation is likely to fail. Abandoning address -validation primarily means not closing the connection when a PATH_RESPONSE frame -is not received, but it could also mean ceasing subsequent transmissions of the -PATH_CHALLENGE frame. An endpoint MUST ignore any subsequently received -PATH_RESPONSE frames from that address. - - -## Spurious Connection Migrations - -A connection migration could be triggered by an attacker that is able to capture -and forward a packet such that it arrives before the legitimate copy of that -packet. Such a packet will appear to be a legitimate connection migration and -the legitimate copy will be dropped as a duplicate. - -After a spurious migration, validation of the source address will fail because -the entity at the source address does not have the necessary cryptographic keys -to read or respond to the PATH_CHALLENGE frame that is sent to it, even if it -wanted to. Such a spurious connection migration could result in the connection -being dropped when the source address validation fails. This grants an attacker -the ability to terminate the connection. - -Receipt of packets with higher packet numbers from the legitimate address will -trigger another connection migration. This will cause the validation of the -address of the spurious migration to be abandoned. - -To ensure that a peer sends packets from the legitimate address before the -validation of the new address can fail, an endpoint SHOULD attempt to validate -the old remote address before attempting to validate the new address. If the -connection migration is spurious, then the legitimate address will be used to -respond and the connection will migrate back to the old address. - -As with any address validation, packets containing a PATH_CHALLENGE frame -validating an address MUST be sent to the address being validated. -Consequently, during a migration of a peer, an endpoint could be sending to -multiple remote addresses. - -An endpoint MAY abandon address validation for an address that it considers to -be already valid. That is, if successive connection migrations occur in quick -succession with the final remote address being identical to the initial remote -address, the endpoint MAY abandon address validation for that address. - - ## Connection Termination {#termination} Connections should remain open until they become idle for a pre-negotiated From e46264c021398d430792a01c1b47fbb29073b54c Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Fri, 9 Feb 2018 16:02:17 -0800 Subject: [PATCH 23/33] sync --- draft-ietf-quic-transport.md | 74 ++++++++++++++++++++---------------- 1 file changed, 42 insertions(+), 32 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index f719eda303..c725ab1d1e 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1481,26 +1481,30 @@ connection if the integrity check fails with a PROTOCOL_VIOLATION error code. ## Connection Migration {#migration} -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. This specification covers connection migration to a -new client address; connection migration to a new server address is explicitly -not specified. +QUIC allows connections to survive changes to endpoint addresses (that is, IP +address and/or port), such as those caused by a client migrating to a new +network. This section describes the protocol for migrating a connection to a +new client address. + +Migrating a connection to a new server address is left for future work. If a +client receives packets from a new server address that are decryptable, the +client MAY discard these packets. + ### Address Validation {#migrate-validate} -Address validation is used by a server to confirm client ownership of a new -address, and by a client to establish reachability to the server from a new +Address validation is used by a server to confirm the client's ownership of a +new address and by a client to establish reachability to the server from a new local address. To start address validation, an endpoint sends a PATH_CHALLENGE frame containing -a payload that is hard to guess from or to the address to be validated. +a payload that is hard to guess from or to the address to be validated. On receiving a PATH_CHALLENGE frame, the peer MUST immediately respond by echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame. The PATH_RESPONSE MUST be sent on the same path: from the same local address on -which the PATH_CHALLENGE was received, and to the same remote address from which -the PATH_CHALLENGE was received. +which the PATH_CHALLENGE was received, to the same remote address from which the +PATH_CHALLENGE was received. The endpoint considers the address to be valid when a PATH_RESPONSE frame containing the same payload is received from the peer. @@ -1509,11 +1513,11 @@ The new address is not considered valid until a PATH_RESPONSE frame containing the same payload is received, even if the packet containing the PATH_CHALLENGE frame is acknowledged. -The PATH_RESPONSE frame MUST be received from the same peer address to which the -corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received from -a different peer address than the one to which the PATH_CHALLENGE was sent, -address validation is considered to have failed, even if the data matches that -sent in the PATH_CHALLENGE. +The PATH_RESPONSE frame MUST be received from the same remote address to which +the corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received +from a different remote address than the one to which the PATH_CHALLENGE was +sent, address validation is considered to have failed, even if the data matches +that sent in the PATH_CHALLENGE. The PATH_RESPONSE frame MUST be received on the same local address from which the corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received @@ -1525,9 +1529,7 @@ The endpoint MAY send additional PATH_CHALLENGE frames to handle packet loss, subject to the congestion controller's limits. The endpoint MUST use fresh random data in every PATH_CHALLENGE frame so that it -can associate the peer's response with the causative PATH_CHALLENGE. Not using -fresh random data risks exposing the endpoint to an attacker defeating -validation by sending a spoofed PATH_RESPONSE from a victim's address. +can associate the peer's response with the causative PATH_CHALLENGE. The endpoint MAY send more than one PATH_RESPONSE in response to a PATH_CHALLENGE, as allowed by the congestion controller, to ensure that packet @@ -1545,19 +1547,25 @@ either endpoint. For instance, an endpoint might check that a peer is still in possession of its address after a period of quiescence. -### Client Behavior +### Initiating Connection Migration -A client with a new address may migrate the connection by simply sending all -packets to the new address. +A client with a new address may migrate an active connection by simply sending +all packets from the new address. Receiving acknowledgments for this data serves +as proof of the server's reachability from the new address. -Before sending data from the new address, a client MAY check server reachability -from the new address using address validation {{address-validation}}. +Prior to sending data from a new address, a client MAY check server reachability +from the new address using address validation {{migrate-validate}}. Failure of +address validation simply means that the new address is not usable for this +connection and should not be fatal to the connection when alternative +addresses are available. A client migrating to a new address SHOULD use a new connection ID for packets sent from the new address, see {{migration-linkability}} for further discussion. +A client MUST not initiate connection migration during the handshake. + -### Server Behavior +### Responding to a Migrating Client A server that receives a packet from a new client address is likely seeing a connection migration at the client. @@ -1572,14 +1580,7 @@ Thus, on receiving and decrypting a packet with a known connection ID but from an unvalidated address, the server MUST immediately validate the client's new address to confirm the client's possession of the new address. -Until a client's address is deemed valid, the server MUST limit the rate at -which it sends data to this address. The server MUST NOT send more than 4 * MSS -bytes per estimated initial RTO period (as defined in {{QUIC-RECOVERY}}). In -the absence of this limit, the server risks being used for a denial of service -attack against an unsuspecting victim. - -A server MAY skip address validation for a client address that it considers to -be already valid. +Receiving a PATH_CHALLENGE frame from the client ... 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 @@ -1589,6 +1590,15 @@ PATH_CHALLENGE, PATH_RESPONSE, and PADDING frames are used for reachability checks, and receiving only these frames from a new address MUST NOT cause the server to commit to that 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 +bytes per estimated initial RTO period (as defined in {{QUIC-RECOVERY}}). In +the absence of this limit, the server risks being used for a denial of service +attack against an unsuspecting victim. + +A server MAY skip address validation for a client address that it considers to +be already valid. + 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. From 8ebb6ae4a599395f32f372351d0ed5c44126b3e5 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Sun, 11 Feb 2018 17:49:00 -0800 Subject: [PATCH 24/33] complete rewrite --- draft-ietf-quic-transport.md | 215 +++++++++++++++++++++-------------- 1 file changed, 127 insertions(+), 88 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index c725ab1d1e..548187fed6 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1491,14 +1491,14 @@ client receives packets from a new server address that are decryptable, the client MAY discard these packets. -### Address Validation {#migrate-validate} +### Path Validation {#migrate-validate} -Address validation is used by a server to confirm the client's ownership of a +Path validation is used by a server to confirm the client's ownership of a new address and by a client to establish reachability to the server from a new local address. -To start address validation, an endpoint sends a PATH_CHALLENGE frame containing -a payload that is hard to guess from or to the address to be validated. +To start path validation, an endpoint sends a PATH_CHALLENGE frame containing +a payload that is hard to guess on the path to be validated. On receiving a PATH_CHALLENGE frame, the peer MUST immediately respond by echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame. @@ -1506,9 +1506,6 @@ The PATH_RESPONSE MUST be sent on the same path: from the same local address on which the PATH_CHALLENGE was received, to the same remote address from which the PATH_CHALLENGE was received. -The endpoint considers the address to be valid when a PATH_RESPONSE frame -containing the same payload is received from the peer. - The new address is not considered valid until a PATH_RESPONSE frame containing the same payload is received, even if the packet containing the PATH_CHALLENGE frame is acknowledged. @@ -1516,79 +1513,135 @@ frame is acknowledged. The PATH_RESPONSE frame MUST be received from the same remote address to which the corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received from a different remote address than the one to which the PATH_CHALLENGE was -sent, address validation is considered to have failed, even if the data matches +sent, path validation is considered to have failed, even if the data matches that sent in the PATH_CHALLENGE. The PATH_RESPONSE frame MUST be received on the same local address from which the corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received on a different local address than the one from which the PATH_CHALLENGE was -sent, address validation is considered to have failed, even if the data matches +sent, path validation is considered to have failed, even if the data matches that sent in the PATH_CHALLENGE. +Thus, the endpoint considers the path to be valid when a PATH_RESPONSE frame is +received on the same path with the same payload as the PATH_CHALLENGE frame. + The endpoint MAY send additional PATH_CHALLENGE frames to handle packet loss, -subject to the congestion controller's limits. +but is subject to the following limit to avoid excessive network load: an +endpoint SHOULD NOT send more than one PATH_CHALLENGE frame in 200ms. This +limit is approximately equivalent to the network load due to a new connection, +and is based on the initial Handshake Timeout defined in {{QUIC-RECOVERY}}. The endpoint MUST use fresh random data in every PATH_CHALLENGE frame so that it can associate the peer's response with the causative PATH_CHALLENGE. -The endpoint 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 peer's address validation. - -The endpoint SHOULD abandon address validation after sending some number of +The endpoint SHOULD abandon path validation after sending some number of PATH_CHALLENGE frames or after some time has passed. When setting this timer, implementations are cautioned that the new path could have a longer roundtrip time than the original. The endpoint may receive packets containing other frames during this period, but a PATH_RESPONSE frame with appropriate data is required -for the address validation to succeed. +for the path validation to succeed. -Address validation using the PATH_CHALLENGE frame MAY be used at any time by +Path validation using the PATH_CHALLENGE frame MAY be used at any time by either endpoint. For instance, an endpoint might check that a peer is still in possession of its address after a period of quiescence. +An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames with other +frames, as appropriate. For instance, an endpoint may pad a packet carrying a +PATH_CHALLENGE for PMTU discovery, or an endpoint may bundle a PATH_RESPONSE +with its own PATH_CHALLENGE. + + +### Initiating Connection Migration {#initiating-migration} + +A client MAY initiate connection migration to a new local address in one of two +ways. + +The client may immediately migrate the connection by sending all packets from +the new local address. Receiving acknowledgments for this data serves as proof +of the server's reachability from the new address. + +Alternatively, the client may probe for server reachability from the new local +address first using path validation {{migrate-validate}} and migrate the +connection to the new address at a later time. Failure of path validation +simply means that the new local address is not usable for this connection and +should not be fatal to the connection when alternative local addresses are +available. + +A client migrating to a new local address SHOULD use a new connection ID for +packets sent from that address, see {{migration-linkability}} for further +discussion. + +A client MUST NOT initiate connection migration before the handshake is +finished and the client has 1-RTT keys. + + +### Responding to Connection Migration + +A server may receive a packet from a new client address at any time during the +connection after the handshake is complete. If the packet is decryptable, the +client may be either probing from a new address or migrating immediately, as +described in {{initiating-migration}}. + +#### Responding to a Client Probe + +Receiving a PATH_CHALLENGE frame from the client indicates that the client is +probing for server reachability on this new path. The server sends a +PATH_RESPONSE to the new client address as per {{migrate-validate}}, but the +server MUST continue using the current client address for sending all other +packets. + +PATH_CHALLENGE, PATH_RESPONSE, and PADDING frames are "probing" frames, and +receiving only these frames from a new client address MUST NOT result in the +server sending any other frames to that address. -### Initiating Connection Migration +#### Responding to an Immediate Migration -A client with a new address may migrate an active connection by simply sending -all packets from the new address. Receiving acknowledgments for this data serves -as proof of the server's reachability from the new address. +Receiving a packet from a new client address indicates that the client may be +immediately migrating if -Prior to sending data from a new address, a client MAY check server reachability -from the new address using address validation {{migrate-validate}}. Failure of -address validation simply means that the new address is not usable for this -connection and should not be fatal to the connection when alternative -addresses are available. +* the packet is a "non-probing" packet. That is, it contains a frame other than +PATH_CHALLENGE, PATH_RESPONSE, or PADDING; and -A client migrating to a new address SHOULD use a new connection ID for packets -sent from the new address, see {{migration-linkability}} for further discussion. +* the packet carries a packet number that is the largest seen thus far. -A client MUST not initiate connection migration during the handshake. +Upon receiving such a packet, the server MUST abandon any path validation it is +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. +In response to such a packet, the server MUST start sending subsequent packets +to this client address and MUST initiate path validation to verify client +ownership of the unvalidated address. -### Responding to a Migrating Client +A server MAY skip validation of a client address that it considers to be already +valid. -A server that receives a packet from a new client address is likely seeing a -connection migration at the client. +Note that the server MAY send data to an unvalidated client address, but it MUST +protect against potential attacks as described in {{address-spoofing}} and +{{on-path-spoofing}}. -However, it is also possible that the client is spoofing its source address in -order to cause the server to send excessive amounts of data to an unwilling -host. If the server sends significantly more data than the client, connection -migration might be used to amplify the volume of data that an attacker can -generate toward a victim. +If a non-probing packet is received from a new client address but with a packet +number that is not the largest seen thus far, the server must process the packet +as usual, but it MUST ignore this client address under the assumption that it is +not the client's most recent address. + +After verifying a new client address, the server SHOULD update any address +validation tokens ({{address-validation}}) that it has issued to the client if +those are no longer valid based on the changed address. -Thus, on receiving and decrypting a packet with a known connection ID but from -an unvalidated address, the server MUST immediately validate the client's new -address to confirm the client's possession of the new address. -Receiving a PATH_CHALLENGE frame from the client ... +### Handling Address Spoofing by a Client {#address-spoofing} -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. -PATH_CHALLENGE, PATH_RESPONSE, and PADDING frames are used for reachability -checks, and receiving only these frames from a new address MUST NOT cause the -server to commit to that address. +It is possible that the client is spoofing its source address to cause the +server to send excessive amounts of data to an unwilling host. If the server +sends significantly more data than the client, connection migration might be +used to amplify the volume of data that an attacker can generate toward a +victim. + +Thus, on receiving and decrypting a packet from an unvalidated address, the +server MUST immediately validate the client's new address to confirm the +client's possession of the new address. Until a client's address is deemed valid, the server MUST limit the rate at which it sends data to this address. The server MUST NOT send more than 4 * MSS @@ -1596,25 +1649,10 @@ bytes per estimated initial RTO period (as defined in {{QUIC-RECOVERY}}). In the absence of this limit, the server risks being used for a denial of service attack against an unsuspecting victim. -A server MAY skip address validation for a client address that it considers to -be already valid. - -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. -A client that has ownership of only the new address may switch to sending all -data from that address. The server MAY commit to the new client address prior to -validating that address. - -Upon receiving packets from a new client address, the server MUST abandon any -address validation it is performing with other addresses on the expectation that -those validations are likely to fail. Abandoning address validation primarily -means ceasing subsequent transmissions of the PATH_CHALLENGE frame. An endpoint -MUST ignore any subsequently received PATH_RESPONSE frames from abandoned -addresses. +### Handling Address Spoofing by an On-path Attacker {#on-path-spoofing} -An attacker could cause a spurious connection migration by capturing and +An on-path attacker could cause a spurious connection migration by capturing and forwarding a packet such that it arrives before the legitimate copy of that packet. Such a packet will appear to be a legitimate connection migration and the legitimate copy will be dropped as a duplicate. After a spurious migration, @@ -1629,41 +1667,42 @@ 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 -address will trigger another connection migration. This will cause the +client address will trigger another connection migration. This will cause the validation of the address of the spurious migration to be abandoned. -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. - ### Loss Detection and Congestion Control The capacity available on the new path might not be the same as the old path. -If the peer's address is validated successfully, the endpoint SHOULD reset its -congestion controller and roundtrip time estimator prior to sending any data to -the new address. An endpoint MUST NOT restore its send rate unless it is -reasonably sure that the path is the same as the previous path. For instance, a -change in only port number is likely indicative of a rebinding in a middlebox -and not a complete change in path. This determination likely depends on -heuristics, which could be imperfect; if the new path capacity is significantly -reduced, ultimately this relies on the congestion controller responding to -congestion signals and reduce send rates appropriately. + +A client SHOULD reset its congestion controller and roundtrip time estimator +prior to sending any non-probing packets from a new local address. + +After successful validation of the client's new address, the server SHOULD reset +its congestion controller and roundtrip time estimator prior to sending any +further non-probing packets. + +An endpoint MUST NOT restore its send rate unless it is reasonably sure that the +path is the same as the previous path. For instance, a change in the client's +port number is likely indicative of a rebinding in a middlebox and not a +complete change in path. This determination likely depends on heuristics, which +could be imperfect; if the new path capacity is significantly reduced, +ultimately this relies on the congestion controller responding to congestion +signals and reducing send rates appropriately. There may be apparent reordering at the receiver when an endpoint sends data and probes from/to multiple addresses during the migration period, since the two resulting paths may have different rountrip times. A receiver of packets on 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 +An endpoint MAY use a single congestion control context and a single loss +recovery context, as described in {{QUIC-RECOVERY}}. A sender MAY make +exceptions 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. +PATH_CHALLENGE, and restart the alarm for a longer period of time. ### Privacy Implications of Connection Migration {#migration-linkability} @@ -2634,7 +2673,7 @@ to decipher the packet. ## PATH_CHALLENGE Frame {#frame-path-challenge} Endpoints can use PATH_CHALLENGE frames (type=0x0e) to check reachability to the -peer and for address validation during connection establishment and connection +peer and for path validation during connection establishment and connection migration. PATH_CHALLENGE frames contain an 8-byte payload. From 440db50738ff8d9a30cc7f601b84de0954cd54b7 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Sun, 11 Feb 2018 22:44:26 -0800 Subject: [PATCH 25/33] nits --- draft-ietf-quic-transport.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 548187fed6..bc09d99240 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1399,7 +1399,7 @@ connection. TLS provides the tools that support the feature, but basic validation is performed by the core transport protocol. A different type of source address validation is performed after a connection -migration, see {{migration-validate}}. +migration, see {{migrate-validate}}. ### Client Address Validation Procedure @@ -1602,7 +1602,7 @@ immediately migrating if * the packet is a "non-probing" packet. That is, it contains a frame other than PATH_CHALLENGE, PATH_RESPONSE, or PADDING; and -* the packet carries a packet number that is the largest seen thus far. +* the packet carries a packet number that is the largest seen thus far. Upon receiving such a packet, the server MUST abandon any path validation it is performing with other addresses on the expectation that those validations are @@ -1825,9 +1825,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 -{{migration-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 +server in the closing state MAY instead choose to discard packets received from +a new source address. ### Idle Timeout From 5760cbea406c439c387b4c23021839437cc0f9e3 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Tue, 20 Feb 2018 14:44:07 -0800 Subject: [PATCH 26/33] comments --- draft-ietf-quic-transport.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index bc09d99240..4b55dca837 100644 --- a/draft-ietf-quic-transport.md +++ b/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 +MAY discard these packets. ### Path Validation {#migrate-validate} @@ -1558,7 +1558,10 @@ ways. The client may immediately migrate the connection by sending all packets from the new local address. Receiving acknowledgments for this data serves as proof -of the server's reachability from the new address. +of the server's reachability from the new address. Note that since +acknowledgments may be received on any path, return reachability on the new path +is not established. To establish return reachability on the new path, a client +MAY concurrently initiate path validation {{migrate-validate}} on the new path. Alternatively, the client may probe for server reachability from the new local address first using path validation {{migrate-validate}} and migrate the @@ -1674,8 +1677,9 @@ validation of the address of the spurious migration to be abandoned. ### Loss Detection and Congestion Control The capacity available on the new path might not be the same as the old path. - -A client SHOULD reset its congestion controller and roundtrip time estimator +Packets sent on the old path SHOULD NOT contribute to the state of the +congestion control and RTT estimation on the new path. If it is using a single +congestion controller and roundtrip time estimator, the client SHOULD reset them prior to sending any non-probing packets from a new local address. After successful validation of the client's new address, the server SHOULD reset From 0706fd99f2f853e0b5c585d7cc19fdefd118e674 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Tue, 6 Mar 2018 18:34:43 -0800 Subject: [PATCH 27/33] comments --- draft-ietf-quic-transport.md | 164 +++++++++++++++++++++-------------- 1 file changed, 97 insertions(+), 67 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 4b55dca837..ba6329815f 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -233,7 +233,7 @@ retransmissions from those for original transmissions, avoiding TCP's retransmission ambiguity problem. QUIC acknowledgments also explicitly encode the delay between the receipt of a packet and its acknowledgment being sent, and together with the monotonically-increasing packet numbers, this allows for -precise network roundtrip-time (RTT) calculation. QUIC's ACK frames support +precise network round-trip time (RTT) calculation. QUIC's ACK frames support multiple ACK blocks, so QUIC is more resilient to reordering than TCP with SACK support, as well as able to keep more bytes on the wire when there is reordering or loss. @@ -1493,18 +1493,53 @@ MAY discard these packets. ### Path Validation {#migrate-validate} -Path validation is used by a server to confirm the client's ownership of a -new address and by a client to establish reachability to the server from a new -local address. +Path validation is used by the migrating endpoint to verify reachability of +its peer from a new local address. Path validation is 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 +not carry a spoofed source address. -To start path validation, an endpoint sends a PATH_CHALLENGE frame containing +Path validation MAY be used at any time by either endpoint. For instance, an +endpoint might check that a peer is still in possession of its address after a +period of quiescence. + +An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames with other +frames, as appropriate. For instance, an endpoint may pad a packet carrying a +PATH_CHALLENGE for PMTU discovery, or an endpoint may bundle a PATH_RESPONSE +with its own PATH_CHALLENGE. + + +#### Initiation + +To initiate path validation, an endpoint sends a PATH_CHALLENGE frame containing a payload that is hard to guess on the path to be validated. -On receiving a PATH_CHALLENGE frame, the peer MUST immediately respond by -echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame. -The PATH_RESPONSE MUST be sent on the same path: from the same local address on -which the PATH_CHALLENGE was received, to the same remote address from which the -PATH_CHALLENGE was received. +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 +establishing a new connection. + +The endpoint MUST use fresh random data in every PATH_CHALLENGE frame so that it +can associate the peer's response with the causative PATH_CHALLENGE. + + +#### Response + +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 +spoofed address, an endpoint MAY limit the rate at which it sends PATH_RESPONSE +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 +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. + + +#### Completion The new address is not considered valid until a PATH_RESPONSE frame containing the same payload is received, even if the packet containing the PATH_CHALLENGE @@ -1520,35 +1555,24 @@ The PATH_RESPONSE frame MUST be received on the same local address from which the corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received on a different local address than the one from which the PATH_CHALLENGE was sent, path validation is considered to have failed, even if the data matches -that sent in the PATH_CHALLENGE. - -Thus, the endpoint considers the path to be valid when a PATH_RESPONSE frame is -received on the same path with the same payload as the PATH_CHALLENGE frame. +that sent in the PATH_CHALLENGE. Thus, the endpoint considers the path to be +valid when a PATH_RESPONSE frame is received on the same path with the same +payload as the PATH_CHALLENGE frame. -The endpoint MAY send additional PATH_CHALLENGE frames to handle packet loss, -but is subject to the following limit to avoid excessive network load: an -endpoint SHOULD NOT send more than one PATH_CHALLENGE frame in 200ms. This -limit is approximately equivalent to the network load due to a new connection, -and is based on the initial Handshake Timeout defined in {{QUIC-RECOVERY}}. -The endpoint MUST use fresh random data in every PATH_CHALLENGE frame so that it -can associate the peer's response with the causative PATH_CHALLENGE. +#### Abandonment The endpoint SHOULD abandon path validation after sending some number of PATH_CHALLENGE frames or after some time has passed. When setting this timer, -implementations are cautioned that the new path could have a longer roundtrip -time than the original. The endpoint may receive packets containing other frames -during this period, but a PATH_RESPONSE frame with appropriate data is required -for the path validation to succeed. +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, +ensuring that connection migration is no more load on a new path than +establishing a new connection. -Path validation using the PATH_CHALLENGE frame MAY be used at any time by -either endpoint. For instance, an endpoint might check that a peer is still in -possession of its address after a period of quiescence. - -An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames with other -frames, as appropriate. For instance, an endpoint may pad a packet carrying a -PATH_CHALLENGE for PMTU discovery, or an endpoint may bundle a PATH_RESPONSE -with its own PATH_CHALLENGE. +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. ### Initiating Connection Migration {#initiating-migration} @@ -1556,19 +1580,20 @@ with its own PATH_CHALLENGE. A client MAY initiate connection migration to a new local address in one of two ways. -The client may immediately migrate the connection by sending all packets from -the new local address. Receiving acknowledgments for this data serves as proof -of the server's reachability from the new address. Note that since +The client MAY immediately migrate the connection by sending all packets from +the new local address. Since the server's address is validated during +connection establishment, receiving acknowledgments for this data serves as +proof of the server's reachability from the new address. Note that since acknowledgments may be received on any path, return reachability on the new path is not established. To establish return reachability on the new path, a client MAY concurrently initiate path validation {{migrate-validate}} on the new path. -Alternatively, the client may probe for server reachability from the new local +Alternatively, the client could probe for server reachability from the new local address first using path validation {{migrate-validate}} and migrate the -connection to the new address at a later time. Failure of path validation -simply means that the new local address is not usable for this connection and -should not be fatal to the connection when alternative local addresses are -available. +connection to the new address later. Failure of path validation simply means +that the new local address is not usable for this connection. Failure to +validate a path does not cause the connection to end unless there are no valid +alternative paths available. A client migrating to a new local address SHOULD use a new connection ID for packets sent from that address, see {{migration-linkability}} for further @@ -1581,8 +1606,8 @@ finished and the client has 1-RTT keys. ### Responding to Connection Migration A server may receive a packet from a new client address at any time during the -connection after the handshake is complete. If the packet is decryptable, the -client may be either probing from a new address or migrating immediately, as +connection after the handshake is complete. If the packet is authenticated, the +client might be either probing from a new address or migrating immediately, as described in {{initiating-migration}}. #### Responding to a Client Probe @@ -1617,21 +1642,23 @@ In response to such a packet, the server MUST start sending subsequent packets to this client address and MUST initiate path validation to verify client ownership of the unvalidated address. -A server MAY skip validation of a client address that it considers to be already -valid. +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. Note that the server MAY send data to an unvalidated client address, but it MUST protect against potential attacks as described in {{address-spoofing}} and {{on-path-spoofing}}. If a non-probing packet is received from a new client address but with a packet -number that is not the largest seen thus far, the server must process the packet -as usual, but it MUST ignore this client address under the assumption that it is -not the client's most recent address. +number that is not the largest seen thus far, it is likely that it is a +reordered packet sent from an older client address. The server processes this +packet as usual, but it MUST ignore this client address under the assumption +that it is not the client's most recent address. -After verifying a new client address, the server SHOULD update any address -validation tokens ({{address-validation}}) that it has issued to the client if -those are no longer valid based on the changed address. +After verifying a new client address, the server SHOULD send new address +validation tokens ({{address-validation}}) to the client if the current ones +will not be adequate to validate the new client address. ### Handling Address Spoofing by a Client {#address-spoofing} @@ -1647,10 +1674,13 @@ server MUST immediately validate the client's new address to confirm the client's possession of the new address. Until a client's address is deemed valid, the server MUST limit the rate at -which it sends data to this address. The server MUST NOT send more than 4 * MSS -bytes per estimated initial RTO period (as defined in {{QUIC-RECOVERY}}). In -the absence of this limit, the server risks being used for a denial of service -attack against an unsuspecting victim. +which it sends data to this address. The server MUST NOT send more than a +minimum congestion window's worth of data per estimated RTO period (as defined +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 +{{QUIC-RECOVERY}}). ### Handling Address Spoofing by an On-path Attacker {#on-path-spoofing} @@ -1669,9 +1699,9 @@ a new client address fails. If the server has no state about the last validated client address, it MUST close the connection silently and discard any further packets received from the client for this connection. -We note that receipt of packets with higher packet numbers from the legitimate -client address will trigger another connection migration. This will cause the -validation of the address of the spurious migration to be abandoned. +Receipt of packets with higher packet numbers from the legitimate client address +will trigger another connection migration. This will cause the validation of +the address of the spurious migration to be abandoned. ### Loss Detection and Congestion Control @@ -1679,11 +1709,11 @@ validation of the address of the spurious migration to be abandoned. The capacity available on the new path might not be the same as the old path. Packets sent on the old path SHOULD NOT contribute to the state of the congestion control and RTT estimation on the new path. If it is using a single -congestion controller and roundtrip time estimator, the client SHOULD reset them -prior to sending any non-probing packets from a new local address. +congestion controller and round-trip time estimator, the client SHOULD reset +them prior to sending any non-probing packets from a new local address. After successful validation of the client's new address, the server SHOULD reset -its congestion controller and roundtrip time estimator prior to sending any +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 @@ -1696,7 +1726,7 @@ signals and reducing send rates appropriately. There may be apparent reordering at the receiver when an endpoint sends data and probes from/to multiple addresses during the migration period, since the two -resulting paths may have different rountrip times. A receiver of packets on +resulting paths may have different round-trip times. A receiver of packets on multiple paths will still send ACK frames covering all received packets. An endpoint MAY use a single congestion control context and a single loss @@ -1829,9 +1859,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 since the address is 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 until the address is validated (see {{migrate-validate}}). A server +in the closing state MAY instead choose to discard packets received from a new +source address. ### Idle Timeout @@ -3553,7 +3583,7 @@ tradeoff between resource commitment and overhead when determining how large a limit is advertised. A receiver MAY use an autotuning mechanism to tune the frequency and amount that -it increases data limits based on a roundtrip time estimate and the rate at +it increases data limits based on a round-trip time estimate and the rate at which the receiving application consumes data, similar to common TCP implementations. @@ -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 expects the sender to get blocked. A sender sends a single BLOCKED or STREAM_BLOCKED frame only once when it From b75ea84ae7cac2c324d697d38720af121245aafa Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Tue, 6 Mar 2018 18:37:23 -0800 Subject: [PATCH 28/33] sigh. whitespace. --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index ba6329815f..4a2287e77f 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1568,7 +1568,7 @@ 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, ensuring that connection migration is no more load on a new path than -establishing a new connection. +establishing a new connection. 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 From 5378c0305884dddb12aa4ee775fcee2b99adc6af Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Wed, 7 Mar 2018 12:02:42 -0800 Subject: [PATCH 29/33] Mike's comments --- draft-ietf-quic-transport.md | 49 ++++++++++++++++++------------------ 1 file changed, 24 insertions(+), 25 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 4a2287e77f..585c680ee9 100644 --- a/draft-ietf-quic-transport.md +++ b/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 in the connection from a new server address, the client -MAY discard these packets. +client receives packets from a new server address, the client MAY discard these +packets. ### Path Validation {#migrate-validate} @@ -1514,11 +1514,10 @@ with its own PATH_CHALLENGE. To initiate path validation, an endpoint sends a PATH_CHALLENGE frame containing a payload that is hard to guess on the path to be validated. -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 -establishing a new connection. +An endpoint MAY send additional PATH_CHALLENGE frames to handle packet loss. An +endpoint SHOULD NOT send a PATH_CHALLENGE more frequently than it would an +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 can associate the peer's response with the causative PATH_CHALLENGE. @@ -1528,7 +1527,7 @@ can associate the peer's response with the causative PATH_CHALLENGE. 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 +with the following stipulation. Since a PATH_CHALLENGE might be sent from a spoofed address, an endpoint MAY limit the rate at which it sends PATH_RESPONSE frames and MAY silently discard PATH_CHALLENGE frames that would cause it to respond at a higher rate. @@ -1577,23 +1576,20 @@ to succeed. ### Initiating Connection Migration {#initiating-migration} -A client MAY initiate connection migration to a new local address in one of two -ways. - -The client MAY immediately migrate the connection by sending all packets from -the new local address. Since the server's address is validated during +A client can migrate a connection to a new local address by sending all packets +from the new local address. Since the server's address is validated during connection establishment, receiving acknowledgments for this data serves as proof of the server's reachability from the new address. Note that since acknowledgments may be received on any path, return reachability on the new path is not established. To establish return reachability on the new path, a client MAY concurrently initiate path validation {{migrate-validate}} on the new path. -Alternatively, the client could probe for server reachability from the new local -address first using path validation {{migrate-validate}} and migrate the -connection to the new address later. Failure of path validation simply means -that the new local address is not usable for this connection. Failure to -validate a path does not cause the connection to end unless there are no valid -alternative paths available. +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 +local address is not usable for this connection. Failure to validate a path +does not cause the connection to end unless there are no valid alternative paths +available. A client migrating to a new local address SHOULD use a new connection ID for packets sent from that address, see {{migration-linkability}} for further @@ -1695,13 +1691,16 @@ PATH_CHALLENGE frame that is sent to it, even if it wanted to. To protect the connection from failing due to such a spurious migration, the server MUST revert to using the last validated client address when validation of -a new client address fails. If the server has no state about the last validated -client address, it MUST close the connection silently and discard any further -packets received from the client for this connection. +a new client address fails. + +If the server has no state about the last validated client address, it MUST +close the connection silently by discarding all connection state. This results +in new packets on the connection being handled generically. For instance, an +endpoint MAY send a stateless reset in response to any further incoming packets. -Receipt of packets with higher packet numbers from the legitimate client address -will trigger another connection migration. This will cause the validation of -the address of the spurious migration to be abandoned. +Note that receipt of packets with higher packet numbers from the legitimate +client address will trigger another connection migration. This will cause the +validation of the address of the spurious migration to be abandoned. ### Loss Detection and Congestion Control From 30025deb9f23233a56f2846fd39ba2a38c0e4f1e Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Wed, 7 Mar 2018 12:06:01 -0800 Subject: [PATCH 30/33] client connection migration --- draft-ietf-quic-transport.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 585c680ee9..c4b5c48c87 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -193,7 +193,7 @@ strengths of QUIC include: * Stream and connection flow control -* Connection migration and resilience to NAT rebinding +* Client connection migration and resilience to NAT rebinding * Version negotiation @@ -273,7 +273,7 @@ unencrypted handshake packets is later verified as part of cryptographic processing. -## Connection Migration and Resilience to NAT Rebinding +## Client Connection Migration and Resilience to NAT Rebinding QUIC connections are identified by a Connection ID, a 64-bit unsigned number randomly generated by the server. QUIC's consistent connection ID allows @@ -1479,7 +1479,7 @@ failure. If integrity protection is performed by QUIC, QUIC MUST abort the connection if the integrity check fails with a PROTOCOL_VIOLATION error code. -## Connection Migration {#migration} +## Client Connection Migration {#migration} QUIC allows connections to survive changes to endpoint addresses (that is, IP address and/or port), such as those caused by a client migrating to a new @@ -1855,7 +1855,7 @@ An endpoint is not expected to handle key updates when it is closing or draining. A key update might prevent the endpoint from moving from the closing state to draining, but it otherwise has no impact. -An endpoint could receive packets from a new source address, indicating a +An endpoint could receive packets from a new source address, indicating a client 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 until the address is validated (see {{migrate-validate}}). A server From b956ba8ca800f805e4e6d92ae4134da51df2e13b Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Wed, 7 Mar 2018 18:17:36 -0800 Subject: [PATCH 31/33] eric's comments --- draft-ietf-quic-transport.md | 81 ++++++++++++++++++------------------ 1 file changed, 41 insertions(+), 40 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index c4b5c48c87..a95eae1921 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1512,7 +1512,7 @@ with its own PATH_CHALLENGE. #### Initiation To initiate path validation, an endpoint sends a PATH_CHALLENGE frame containing -a payload that is hard to guess on the path to be validated. +a random payload that is hard to guess on the path to be validated. An endpoint MAY send additional PATH_CHALLENGE frames to handle packet loss. An endpoint SHOULD NOT send a PATH_CHALLENGE more frequently than it would an @@ -1540,28 +1540,29 @@ received, to the same remote address from which the PATH_CHALLENGE was received. #### Completion -The new address is not considered valid until a PATH_RESPONSE frame containing -the same payload is received, even if the packet containing the PATH_CHALLENGE -frame is acknowledged. +A new address is considered valid when a PATH_RESPONSE frame is received +containing data that was sent in a previous PATH_CHALLENGE. Receipt of an +acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate +validation, since the acknowledgment can be spoofed by a malicious client. -The PATH_RESPONSE frame MUST be received from the same remote address to which -the corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received -from a different remote address than the one to which the PATH_CHALLENGE was -sent, path validation is considered to have failed, even if the data matches -that sent in the PATH_CHALLENGE. +For path validation to be successful, a PATH_RESPONSE frame MUST be received +from the same remote address to which the corresponding PATH_CHALLENGE was +sent. If a PATH_RESPONSE frame is received from a different remote address than +the one to which the PATH_CHALLENGE was sent, path validation is considered to +have failed, even if the data matches that sent in the PATH_CHALLENGE. -The PATH_RESPONSE frame MUST be received on the same local address from which -the corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received -on a different local address than the one from which the PATH_CHALLENGE was -sent, path validation is considered to have failed, even if the data matches -that sent in the PATH_CHALLENGE. Thus, the endpoint considers the path to be -valid when a PATH_RESPONSE frame is received on the same path with the same -payload as the PATH_CHALLENGE frame. +Additionally, the PATH_RESPONSE frame MUST be received on the same local address +from which the corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame +is received on a different local address than the one from which the +PATH_CHALLENGE was sent, path validation is considered to have failed, even if +the data matches that sent in the PATH_CHALLENGE. Thus, the endpoint considers +the path to be valid when a PATH_RESPONSE frame is received on the same path +with the same payload as the PATH_CHALLENGE frame. #### Abandonment -The endpoint SHOULD abandon path validation after sending some number of +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 @@ -1569,9 +1570,9 @@ 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. -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. +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. ### Initiating Connection Migration {#initiating-migration} @@ -1584,12 +1585,12 @@ 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. -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 -local address is not usable for this connection. Failure to validate a path -does not cause the connection to end unless there are no valid alternative paths -available. +If it has an opportunity, a client MAY probe for server reachability from a new +local address using path validation {{migrate-validate}} prior to migrating the +connection to the new local address. Failure of path validation simply means +that the new local address is not usable for this connection. Failure to +validate a path does not cause the connection to end unless there are no valid +alternative paths available. A client migrating to a new local address SHOULD use a new connection ID for packets sent from that address, see {{migration-linkability}} for further @@ -1618,20 +1619,20 @@ PATH_CHALLENGE, PATH_RESPONSE, and PADDING frames are "probing" frames, and receiving only these frames from a new client address MUST NOT result in the server sending any other frames to that address. -#### Responding to an Immediate Migration +#### Responding to an Immediate Migration {#migration-response} Receiving a packet from a new client address indicates that the client may be immediately migrating if * the packet is a "non-probing" packet. That is, it contains a frame other than -PATH_CHALLENGE, PATH_RESPONSE, or PADDING; and +PATH_CHALLENGE, PATH_RESPONSE, and PADDING; and * the packet carries a packet number that is the largest seen thus far. Upon receiving such a packet, the server MUST abandon any path validation it is 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 +transmissions of the PATH_CHALLENGE frame. An endpoint MAY ignore any subsequently received PATH_RESPONSE frames from abandoned addresses. In response to such a packet, the server MUST start sending subsequent packets @@ -1665,10 +1666,8 @@ sends significantly more data than the client, connection migration might be used to amplify the volume of data that an attacker can generate toward a victim. -Thus, on receiving and decrypting a packet from an unvalidated address, the -server MUST immediately validate the client's new address to confirm the -client's possession of the new address. - +As described in {{migration-response}}, a server is required to validate the +client's new address to confirm the client's possession of the new address. Until a client's address is deemed valid, the server MUST limit the rate at which it sends data to this address. The server MUST NOT send more than a minimum congestion window's worth of data per estimated RTO period (as defined @@ -1678,6 +1677,8 @@ 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 {{QUIC-RECOVERY}}). +A server SHOULD NOT apply this rate limit when the server skips validation of a +client address, as described in {{migration-response}}. ### Handling Address Spoofing by an On-path Attacker {#on-path-spoofing} @@ -1715,13 +1716,13 @@ After successful validation of the client's new address, the server SHOULD reset 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 -path is the same as the previous path. For instance, a change in the client's -port number is likely indicative of a rebinding in a middlebox and not a -complete change in path. This determination likely depends on heuristics, which -could be imperfect; if the new path capacity is significantly reduced, -ultimately this relies on the congestion controller responding to congestion -signals and reducing send rates appropriately. +An endpoint MUST NOT return to the send rate used for the previous path unless +it is reasonably sure that the previous send rate is valid for the new path. +For instance, a change in the client's port number is likely indicative of a +rebinding in a middlebox and not a complete change in path. This determination +likely depends on heuristics, which could be imperfect; if the new path capacity +is significantly reduced, ultimately this relies on the congestion controller +responding to congestion signals and reducing send rates appropriately. There may be apparent reordering at the receiver when an endpoint sends data and probes from/to multiple addresses during the migration period, since the two From be2afd3628dea564e019dc816d20e1aa0b4a17ca Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Thu, 8 Mar 2018 17:24:30 -0800 Subject: [PATCH 32/33] comments --- draft-ietf-quic-transport.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index a95eae1921..f5f0d594ec 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1494,7 +1494,7 @@ packets. ### Path Validation {#migrate-validate} 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 +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 not carry a spoofed source address. @@ -1565,10 +1565,7 @@ with the same payload as the PATH_CHALLENGE frame. 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 -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. +time than the original. 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 From 441d6e9b555ef3265eaa33342ec51a94e8b9860a Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Wed, 14 Mar 2018 00:04:20 +0000 Subject: [PATCH 33/33] martin comments --- draft-ietf-quic-transport.md | 108 +++++++++++++++++++++-------------- 1 file changed, 66 insertions(+), 42 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index f5f0d594ec..954fae7f40 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -716,10 +716,9 @@ 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 could change over the lifetime of a connection, especially in +response to connection migration ({{migration}}). NEW_CONNECTION_ID frames +({{frame-new-connection-id}}) are used to provide new connection ID values. ## Packet Numbers {#packet-numbers} @@ -1479,37 +1478,39 @@ failure. If integrity protection is performed by QUIC, QUIC MUST abort the connection if the integrity check fails with a PROTOCOL_VIOLATION error code. -## Client Connection Migration {#migration} +## Path Validation {#migrate-validate} -QUIC allows connections to survive changes to endpoint addresses (that is, IP -address and/or port), such as those caused by a client migrating to a new -network. This section describes the protocol for migrating a connection to a -new client address. +Path validation is used by an endpoint to verify reachability of a peer over a +specific path. That is, it tests reachability between a specific local address +and a specific peer address, where an address is the two-tuple of IP address and +port. Path validation tests that packets can be both sent to and received from +a peer. -Migrating a connection to a new server address is left for future work. If a -client receives packets from a new server address, the client MAY discard these -packets. - - -### Path Validation {#migrate-validate} - -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 -not carry a spoofed source address. +Path validation is used during connection migration (see {{migration}}) 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 the its new address. That is, that the +packets received from the migrating endpoint do not carry a spoofed source +address. -Path validation MAY be used at any time by either endpoint. For instance, an +Path validation can be used at any time by either endpoint. For instance, an endpoint might check that a peer is still in possession of its address after a period of quiescence. -An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames with other -frames, as appropriate. For instance, an endpoint may pad a packet carrying a -PATH_CHALLENGE for PMTU discovery, or an endpoint may bundle a PATH_RESPONSE -with its own PATH_CHALLENGE. +Path validation is not designed as a NAT traversal mechanism. Though the +mechanism described here might be effective for the creation of NAT bindings +that support NAT traversal, the expectation is that one or other peer 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. + +An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames that are used for +path validation with other frames. 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. -#### Initiation +### Initiation To initiate path validation, an endpoint sends a PATH_CHALLENGE frame containing a random payload that is hard to guess on the path to be validated. @@ -1523,7 +1524,7 @@ The endpoint MUST use fresh random data in every PATH_CHALLENGE frame so that it can associate the peer's response with the causative PATH_CHALLENGE. -#### Response +### Response 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, @@ -1532,13 +1533,13 @@ spoofed address, an endpoint MAY limit the rate at which it sends PATH_RESPONSE 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 -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. +To ensure that packets can be both sent to and received from the peer, 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. -#### Completion +### Completion A new address is considered valid when a PATH_RESPONSE frame is received containing data that was sent in a previous PATH_CHALLENGE. Receipt of an @@ -1560,7 +1561,7 @@ the path to be valid when a PATH_RESPONSE frame is received on the same path with the same payload as the PATH_CHALLENGE frame. -#### Abandonment +### Abandonment An endpoint SHOULD abandon path validation after sending some number of PATH_CHALLENGE frames or after some time has passed. When setting this timer, @@ -1571,6 +1572,27 @@ 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. +If path validation fails, the path is deemed unusable. This does not +necessarily imply a failure of the connection - endpoints can continue sending +packets over other paths as appropriate. If no paths are available, an endpoint +can wait for a new path to become available or close the connection. + +A path validation might be abandoned for other reasons besides +failure. Primarily, this happens if a connection migration to a new path is +initiated while a path validation on the old path is in progress. + + +## Client Connection Migration {#migration} + +QUIC allows connections to survive changes to endpoint addresses (that is, IP +address and/or port), such as those caused by a client migrating to a new +network. This section describes the protocol for migrating a connection to a +new client address. + +Migrating a connection to a new server address is left for future work. If a +client receives packets from a new server address, the client MAY discard these +packets. + ### Initiating Connection Migration {#initiating-migration} @@ -1589,7 +1611,7 @@ that the new local address is not usable for this connection. Failure to validate a path does not cause the connection to end unless there are no valid alternative paths available. -A client migrating to a new local address SHOULD use a new connection ID for +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. @@ -1604,6 +1626,7 @@ connection after the handshake is complete. If the packet is authenticated, the client might be either probing from a new address or migrating immediately, as described in {{initiating-migration}}. + #### Responding to a Client Probe Receiving a PATH_CHALLENGE frame from the client indicates that the client is @@ -1655,7 +1678,7 @@ validation tokens ({{address-validation}}) to the client if the current ones will not be adequate to validate the new client address. -### Handling Address Spoofing by a Client {#address-spoofing} +#### Handling Address Spoofing by a Client {#address-spoofing} It is possible that the client is spoofing its source address to cause the server to send excessive amounts of data to an unwilling host. If the server @@ -1667,17 +1690,18 @@ As described in {{migration-response}}, a server is required to validate the client's new address to confirm the client's possession of the new address. Until a client's address is deemed valid, the server MUST limit the rate at which it sends data to this address. The server MUST NOT send more than a -minimum congestion window's worth of data per estimated RTO period (as defined -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 +minimum congestion window's worth of data per estimated round-trip time (as +defined 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 measurements to the new +address, the estimate SHOULD be the default initial value (see {{QUIC-RECOVERY}}). A server SHOULD NOT apply this rate limit when the server skips validation of a client address, as described in {{migration-response}}. -### Handling Address Spoofing by an On-path Attacker {#on-path-spoofing} + +#### Handling Address Spoofing by an On-path Attacker {#on-path-spoofing} An on-path attacker could cause a spurious connection migration by capturing and forwarding a packet such that it arrives before the legitimate copy of that