From c904daf2c14d46638e1ea0669fbb821cedac0132 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 16 Oct 2020 11:00:14 +1100 Subject: [PATCH 1/9] Pad when validating addresses This isn't obvious, but if you are validating an address, you are also validating the path to that address. If you don't pad these packets, then you don't know that the path supports a reasonable PMTU. Require padding of datagrams that carry packets that carry PATH_CHALLENGE. This neatly solves the problem. Closes #4216. --- draft-ietf-quic-transport.md | 97 +++++++++++++++++++----------------- 1 file changed, 51 insertions(+), 46 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 1b85be27ed..3ad247b1a2 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -368,7 +368,7 @@ The two least significant bits from a stream ID therefore identify a stream as one of four types, as summarized in {{stream-id-types}}. | Bits | Stream Type | -|:-----|:---------------------------------| +| :--- | :------------------------------- | | 0x0 | Client-Initiated, Bidirectional | | 0x1 | Server-Initiated, Bidirectional | | 0x2 | Client-Initiated, Unidirectional | @@ -729,7 +729,7 @@ one possibility for such a mapping; this mapping requires that data is acknowledged before the transition to a "closed" or "half-closed" state. | Sending Part | Receiving Part | Composite State | -|:-----------------------|:-----------------------|:---------------------| +| :--------------------- | :--------------------- | :------------------- | | No Stream/Ready | No Stream/Recv *1 | idle | | Ready/Send/Data Sent | Recv/Size Known | open | | Ready/Send/Data Sent | Data Recvd/Data Read | half-closed (remote) | @@ -2205,6 +2205,11 @@ connection. The endpoint MUST use unpredictable data in every PATH_CHALLENGE frame so that it can associate the peer's response with the corresponding PATH_CHALLENGE. +An endpoint MUST expand the payload of datagrams that contain a PATH_CHALLENGE +frame to at least the smallest allowed maximum packet size of 1200 bytes. +Sending UDP datagrams of this size ensures that the network path supports a +Path Maximum Transmission Unit (PMTU); see {{datagram-size}}. + ### Path Validation Responses @@ -3414,7 +3419,7 @@ other frames, the Frame Type field simply identifies the frame. These frames are explained in more detail in {{frame-formats}}. | Type Value | Frame Type Name | Definition | Pkts | Spec | -|:------------|:---------------------|:-------------------------------|------|------| +| :---------- | :------------------- | :----------------------------- | ---- | ---- | | 0x00 | PADDING | {{frame-padding}} | IH01 | NP | | 0x01 | PING | {{frame-ping}} | IH01 | | | 0x02 - 0x03 | ACK | {{frame-ack}} | IH_1 | NC | @@ -4321,7 +4326,7 @@ This means that integers are encoded on 1, 2, 4, or 8 bytes and can encode 6, encoding properties. | 2Bit | Length | Usable Bits | Range | -|:-----|:-------|:------------|:----------------------| +| :--- | :----- | :---------- | :-------------------- | | 00 | 1 | 6 | 0-63 | | 01 | 2 | 14 | 0-16383 | | 10 | 4 | 30 | 0-1073741823 | @@ -4475,12 +4480,12 @@ Source Connection ID: In this version of QUIC, the following packet types with the long header are defined: -| Type | Name | Section | -|-----:|:------------------------------|:----------------------------| -| 0x0 | Initial | {{packet-initial}} | -| 0x1 | 0-RTT | {{packet-0rtt}} | -| 0x2 | Handshake | {{packet-handshake}} | -| 0x3 | Retry | {{packet-retry}} | +| Type | Name | Section | +| ---: | :-------- | :------------------- | +| 0x0 | Initial | {{packet-initial}} | +| 0x1 | 0-RTT | {{packet-0rtt}} | +| 0x2 | Handshake | {{packet-handshake}} | +| 0x3 | Retry | {{packet-retry}} | {: #long-packet-types title="Long Header Packet Types"} The header form bit, Destination and Source Connection ID lengths, Destination @@ -7285,25 +7290,25 @@ Parameter Name: The initial contents of this registry are shown in {{iana-tp-table}}. -| Value| Parameter Name | Specification | -|:-----|:----------------------------|:------------------------------------| -| 0x00 | original_destination_connection_id | {{transport-parameter-definitions}} | -| 0x01 | max_idle_timeout | {{transport-parameter-definitions}} | -| 0x02 | stateless_reset_token | {{transport-parameter-definitions}} | -| 0x03 | max_udp_payload_size | {{transport-parameter-definitions}} | -| 0x04 | initial_max_data | {{transport-parameter-definitions}} | -| 0x05 | initial_max_stream_data_bidi_local | {{transport-parameter-definitions}} | -| 0x06 | initial_max_stream_data_bidi_remote | {{transport-parameter-definitions}} | -| 0x07 | initial_max_stream_data_uni | {{transport-parameter-definitions}} | -| 0x08 | initial_max_streams_bidi | {{transport-parameter-definitions}} | -| 0x09 | initial_max_streams_uni | {{transport-parameter-definitions}} | -| 0x0a | ack_delay_exponent | {{transport-parameter-definitions}} | -| 0x0b | max_ack_delay | {{transport-parameter-definitions}} | -| 0x0c | disable_active_migration | {{transport-parameter-definitions}} | -| 0x0d | preferred_address | {{transport-parameter-definitions}} | -| 0x0e | active_connection_id_limit | {{transport-parameter-definitions}} | -| 0x0f | initial_source_connection_id | {{transport-parameter-definitions}} | -| 0x10 | retry_source_connection_id | {{transport-parameter-definitions}} | +| Value | Parameter Name | Specification | +| :---- | :---------------------------------- | :---------------------------------- | +| 0x00 | original_destination_connection_id | {{transport-parameter-definitions}} | +| 0x01 | max_idle_timeout | {{transport-parameter-definitions}} | +| 0x02 | stateless_reset_token | {{transport-parameter-definitions}} | +| 0x03 | max_udp_payload_size | {{transport-parameter-definitions}} | +| 0x04 | initial_max_data | {{transport-parameter-definitions}} | +| 0x05 | initial_max_stream_data_bidi_local | {{transport-parameter-definitions}} | +| 0x06 | initial_max_stream_data_bidi_remote | {{transport-parameter-definitions}} | +| 0x07 | initial_max_stream_data_uni | {{transport-parameter-definitions}} | +| 0x08 | initial_max_streams_bidi | {{transport-parameter-definitions}} | +| 0x09 | initial_max_streams_uni | {{transport-parameter-definitions}} | +| 0x0a | ack_delay_exponent | {{transport-parameter-definitions}} | +| 0x0b | max_ack_delay | {{transport-parameter-definitions}} | +| 0x0c | disable_active_migration | {{transport-parameter-definitions}} | +| 0x0d | preferred_address | {{transport-parameter-definitions}} | +| 0x0e | active_connection_id_limit | {{transport-parameter-definitions}} | +| 0x0f | initial_source_connection_id | {{transport-parameter-definitions}} | +| 0x10 | retry_source_connection_id | {{transport-parameter-definitions}} | {: #iana-tp-table title="Initial QUIC Transport Parameters Entries"} Additionally, each value of the format `31 * N + 27` for integer values of N @@ -7367,23 +7372,23 @@ Description: The initial contents of this registry are shown in {{iana-error-table}}. -| Value | Error | Description | Specification | -|:------|:--------------------------|:------------------------------|:----------------| -| 0x0 | NO_ERROR | No error | {{error-codes}} | -| 0x1 | INTERNAL_ERROR | Implementation error | {{error-codes}} | -| 0x2 | CONNECTION_REFUSED | Server refuses a connection | {{error-codes}} | -| 0x3 | FLOW_CONTROL_ERROR | Flow control error | {{error-codes}} | -| 0x4 | STREAM_LIMIT_ERROR | Too many streams opened | {{error-codes}} | -| 0x5 | STREAM_STATE_ERROR | Frame received in invalid stream state | {{error-codes}} | -| 0x6 | FINAL_SIZE_ERROR | Change to final size | {{error-codes}} | -| 0x7 | FRAME_ENCODING_ERROR | Frame encoding error | {{error-codes}} | -| 0x8 | TRANSPORT_PARAMETER_ERROR | Error in transport parameters | {{error-codes}} | -| 0x9 | CONNECTION_ID_LIMIT_ERROR | Too many connection IDs received | {{error-codes}} | -| 0xa | PROTOCOL_VIOLATION | Generic protocol violation | {{error-codes}} | -| 0xb | INVALID_TOKEN | Invalid Token Received | {{error-codes}} | -| 0xc | APPLICATION_ERROR | Application error | {{error-codes}} | -| 0xd | CRYPTO_BUFFER_EXCEEDED | CRYPTO data buffer overflowed | {{error-codes}} | -| 0xe | KEY_UPDATE_ERROR | Invalid packet protection update | {{error-codes}} | +| Value | Error | Description | Specification | +| :---- | :------------------------ | :-------------------------------------- | :-------------- | +| 0x0 | NO_ERROR | No error | {{error-codes}} | +| 0x1 | INTERNAL_ERROR | Implementation error | {{error-codes}} | +| 0x2 | CONNECTION_REFUSED | Server refuses a connection | {{error-codes}} | +| 0x3 | FLOW_CONTROL_ERROR | Flow control error | {{error-codes}} | +| 0x4 | STREAM_LIMIT_ERROR | Too many streams opened | {{error-codes}} | +| 0x5 | STREAM_STATE_ERROR | Frame received in invalid stream state | {{error-codes}} | +| 0x6 | FINAL_SIZE_ERROR | Change to final size | {{error-codes}} | +| 0x7 | FRAME_ENCODING_ERROR | Frame encoding error | {{error-codes}} | +| 0x8 | TRANSPORT_PARAMETER_ERROR | Error in transport parameters | {{error-codes}} | +| 0x9 | CONNECTION_ID_LIMIT_ERROR | Too many connection IDs received | {{error-codes}} | +| 0xa | PROTOCOL_VIOLATION | Generic protocol violation | {{error-codes}} | +| 0xb | INVALID_TOKEN | Invalid Token Received | {{error-codes}} | +| 0xc | APPLICATION_ERROR | Application error | {{error-codes}} | +| 0xd | CRYPTO_BUFFER_EXCEEDED | CRYPTO data buffer overflowed | {{error-codes}} | +| 0xe | KEY_UPDATE_ERROR | Invalid packet protection update | {{error-codes}} | | 0xf | AEAD_LIMIT_REACHED | Excessive use of packet protection keys | {{error-codes}} | {: #iana-error-table title="Initial QUIC Transport Error Codes Entries"} From d21c32b5c77bf303553a0c2aa6c55ae56b8bb6d0 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 16 Oct 2020 11:23:53 +1100 Subject: [PATCH 2/9] A big caveat --- draft-ietf-quic-transport.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 3ad247b1a2..9d39679258 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2210,6 +2210,13 @@ frame to at least the smallest allowed maximum packet size of 1200 bytes. Sending UDP datagrams of this size ensures that the network path supports a Path Maximum Transmission Unit (PMTU); see {{datagram-size}}. +Note: + +: Probing with datagrams of 1200 bytes does not guarantee that the return path + also supports the same MTU. Migration to a path that can only carry a 1200 + byte UDP payload in one direction will result in the peer being unable to + validate the path. + ### Path Validation Responses From 2686b0aeb0cf854f7f3664c0cf5940bc5e5a47b2 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 16 Oct 2020 17:53:45 +1100 Subject: [PATCH 3/9] Datagrams, not packets Co-authored-by: Jana Iyengar --- 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 9d39679258..319df09db8 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2205,17 +2205,17 @@ connection. The endpoint MUST use unpredictable data in every PATH_CHALLENGE frame so that it can associate the peer's response with the corresponding PATH_CHALLENGE. -An endpoint MUST expand the payload of datagrams that contain a PATH_CHALLENGE -frame to at least the smallest allowed maximum packet size of 1200 bytes. -Sending UDP datagrams of this size ensures that the network path supports a -Path Maximum Transmission Unit (PMTU); see {{datagram-size}}. +An endpoint MUST expand datagrams that contain a PATH_CHALLENGE +frame to at least the smallest allowed maximum datagram size of 1200 bytes. +Sending UDP datagrams of this size ensures that the network path from the +endpoint to the peer can be used for QUIC; see {{datagram-size}}. Note: : Probing with datagrams of 1200 bytes does not guarantee that the return path - also supports the same MTU. Migration to a path that can only carry a 1200 - byte UDP payload in one direction will result in the peer being unable to - validate the path. + also supports the same datagram size. Migration to a path that can carry a + 1200-byte UDP payload in only one direction will result in the peer being unable to + validate the return path back to the endpoint. ### Path Validation Responses From b9bfce85e043a3ca7de712433415acb8eaf71d9f Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 16 Oct 2020 17:55:33 +1100 Subject: [PATCH 4/9] Revert automated formatting of tables, wrap Visual Studio code might need to be fired, though it's possible that this change is a good one. --- draft-ietf-quic-transport.md | 96 ++++++++++++++++++------------------ 1 file changed, 48 insertions(+), 48 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 319df09db8..e380aed450 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -368,7 +368,7 @@ The two least significant bits from a stream ID therefore identify a stream as one of four types, as summarized in {{stream-id-types}}. | Bits | Stream Type | -| :--- | :------------------------------- | +|:-----|:---------------------------------| | 0x0 | Client-Initiated, Bidirectional | | 0x1 | Server-Initiated, Bidirectional | | 0x2 | Client-Initiated, Unidirectional | @@ -729,7 +729,7 @@ one possibility for such a mapping; this mapping requires that data is acknowledged before the transition to a "closed" or "half-closed" state. | Sending Part | Receiving Part | Composite State | -| :--------------------- | :--------------------- | :------------------- | +|:-----------------------|:-----------------------|:---------------------| | No Stream/Ready | No Stream/Recv *1 | idle | | Ready/Send/Data Sent | Recv/Size Known | open | | Ready/Send/Data Sent | Data Recvd/Data Read | half-closed (remote) | @@ -2214,8 +2214,8 @@ Note: : Probing with datagrams of 1200 bytes does not guarantee that the return path also supports the same datagram size. Migration to a path that can carry a - 1200-byte UDP payload in only one direction will result in the peer being unable to - validate the return path back to the endpoint. + 1200-byte UDP payload in only one direction will result in the peer being + unable to validate the return path back to the endpoint. ### Path Validation Responses @@ -3426,7 +3426,7 @@ other frames, the Frame Type field simply identifies the frame. These frames are explained in more detail in {{frame-formats}}. | Type Value | Frame Type Name | Definition | Pkts | Spec | -| :---------- | :------------------- | :----------------------------- | ---- | ---- | +|:------------|:---------------------|:-------------------------------|------|------| | 0x00 | PADDING | {{frame-padding}} | IH01 | NP | | 0x01 | PING | {{frame-ping}} | IH01 | | | 0x02 - 0x03 | ACK | {{frame-ack}} | IH_1 | NC | @@ -4333,7 +4333,7 @@ This means that integers are encoded on 1, 2, 4, or 8 bytes and can encode 6, encoding properties. | 2Bit | Length | Usable Bits | Range | -| :--- | :----- | :---------- | :-------------------- | +|:-----|:-------|:------------|:----------------------| | 00 | 1 | 6 | 0-63 | | 01 | 2 | 14 | 0-16383 | | 10 | 4 | 30 | 0-1073741823 | @@ -4487,12 +4487,12 @@ Source Connection ID: In this version of QUIC, the following packet types with the long header are defined: -| Type | Name | Section | -| ---: | :-------- | :------------------- | -| 0x0 | Initial | {{packet-initial}} | -| 0x1 | 0-RTT | {{packet-0rtt}} | -| 0x2 | Handshake | {{packet-handshake}} | -| 0x3 | Retry | {{packet-retry}} | +| Type | Name | Section | +|-----:|:------------------------------|:----------------------------| +| 0x0 | Initial | {{packet-initial}} | +| 0x1 | 0-RTT | {{packet-0rtt}} | +| 0x2 | Handshake | {{packet-handshake}} | +| 0x3 | Retry | {{packet-retry}} | {: #long-packet-types title="Long Header Packet Types"} The header form bit, Destination and Source Connection ID lengths, Destination @@ -7297,25 +7297,25 @@ Parameter Name: The initial contents of this registry are shown in {{iana-tp-table}}. -| Value | Parameter Name | Specification | -| :---- | :---------------------------------- | :---------------------------------- | -| 0x00 | original_destination_connection_id | {{transport-parameter-definitions}} | -| 0x01 | max_idle_timeout | {{transport-parameter-definitions}} | -| 0x02 | stateless_reset_token | {{transport-parameter-definitions}} | -| 0x03 | max_udp_payload_size | {{transport-parameter-definitions}} | -| 0x04 | initial_max_data | {{transport-parameter-definitions}} | -| 0x05 | initial_max_stream_data_bidi_local | {{transport-parameter-definitions}} | -| 0x06 | initial_max_stream_data_bidi_remote | {{transport-parameter-definitions}} | -| 0x07 | initial_max_stream_data_uni | {{transport-parameter-definitions}} | -| 0x08 | initial_max_streams_bidi | {{transport-parameter-definitions}} | -| 0x09 | initial_max_streams_uni | {{transport-parameter-definitions}} | -| 0x0a | ack_delay_exponent | {{transport-parameter-definitions}} | -| 0x0b | max_ack_delay | {{transport-parameter-definitions}} | -| 0x0c | disable_active_migration | {{transport-parameter-definitions}} | -| 0x0d | preferred_address | {{transport-parameter-definitions}} | -| 0x0e | active_connection_id_limit | {{transport-parameter-definitions}} | -| 0x0f | initial_source_connection_id | {{transport-parameter-definitions}} | -| 0x10 | retry_source_connection_id | {{transport-parameter-definitions}} | +| Value| Parameter Name | Specification | +|:-----|:----------------------------|:------------------------------------| +| 0x00 | original_destination_connection_id | {{transport-parameter-definitions}} | +| 0x01 | max_idle_timeout | {{transport-parameter-definitions}} | +| 0x02 | stateless_reset_token | {{transport-parameter-definitions}} | +| 0x03 | max_udp_payload_size | {{transport-parameter-definitions}} | +| 0x04 | initial_max_data | {{transport-parameter-definitions}} | +| 0x05 | initial_max_stream_data_bidi_local | {{transport-parameter-definitions}} | +| 0x06 | initial_max_stream_data_bidi_remote | {{transport-parameter-definitions}} | +| 0x07 | initial_max_stream_data_uni | {{transport-parameter-definitions}} | +| 0x08 | initial_max_streams_bidi | {{transport-parameter-definitions}} | +| 0x09 | initial_max_streams_uni | {{transport-parameter-definitions}} | +| 0x0a | ack_delay_exponent | {{transport-parameter-definitions}} | +| 0x0b | max_ack_delay | {{transport-parameter-definitions}} | +| 0x0c | disable_active_migration | {{transport-parameter-definitions}} | +| 0x0d | preferred_address | {{transport-parameter-definitions}} | +| 0x0e | active_connection_id_limit | {{transport-parameter-definitions}} | +| 0x0f | initial_source_connection_id | {{transport-parameter-definitions}} | +| 0x10 | retry_source_connection_id | {{transport-parameter-definitions}} | {: #iana-tp-table title="Initial QUIC Transport Parameters Entries"} Additionally, each value of the format `31 * N + 27` for integer values of N @@ -7379,23 +7379,23 @@ Description: The initial contents of this registry are shown in {{iana-error-table}}. -| Value | Error | Description | Specification | -| :---- | :------------------------ | :-------------------------------------- | :-------------- | -| 0x0 | NO_ERROR | No error | {{error-codes}} | -| 0x1 | INTERNAL_ERROR | Implementation error | {{error-codes}} | -| 0x2 | CONNECTION_REFUSED | Server refuses a connection | {{error-codes}} | -| 0x3 | FLOW_CONTROL_ERROR | Flow control error | {{error-codes}} | -| 0x4 | STREAM_LIMIT_ERROR | Too many streams opened | {{error-codes}} | -| 0x5 | STREAM_STATE_ERROR | Frame received in invalid stream state | {{error-codes}} | -| 0x6 | FINAL_SIZE_ERROR | Change to final size | {{error-codes}} | -| 0x7 | FRAME_ENCODING_ERROR | Frame encoding error | {{error-codes}} | -| 0x8 | TRANSPORT_PARAMETER_ERROR | Error in transport parameters | {{error-codes}} | -| 0x9 | CONNECTION_ID_LIMIT_ERROR | Too many connection IDs received | {{error-codes}} | -| 0xa | PROTOCOL_VIOLATION | Generic protocol violation | {{error-codes}} | -| 0xb | INVALID_TOKEN | Invalid Token Received | {{error-codes}} | -| 0xc | APPLICATION_ERROR | Application error | {{error-codes}} | -| 0xd | CRYPTO_BUFFER_EXCEEDED | CRYPTO data buffer overflowed | {{error-codes}} | -| 0xe | KEY_UPDATE_ERROR | Invalid packet protection update | {{error-codes}} | +| Value | Error | Description | Specification | +|:------|:--------------------------|:------------------------------|:----------------| +| 0x0 | NO_ERROR | No error | {{error-codes}} | +| 0x1 | INTERNAL_ERROR | Implementation error | {{error-codes}} | +| 0x2 | CONNECTION_REFUSED | Server refuses a connection | {{error-codes}} | +| 0x3 | FLOW_CONTROL_ERROR | Flow control error | {{error-codes}} | +| 0x4 | STREAM_LIMIT_ERROR | Too many streams opened | {{error-codes}} | +| 0x5 | STREAM_STATE_ERROR | Frame received in invalid stream state | {{error-codes}} | +| 0x6 | FINAL_SIZE_ERROR | Change to final size | {{error-codes}} | +| 0x7 | FRAME_ENCODING_ERROR | Frame encoding error | {{error-codes}} | +| 0x8 | TRANSPORT_PARAMETER_ERROR | Error in transport parameters | {{error-codes}} | +| 0x9 | CONNECTION_ID_LIMIT_ERROR | Too many connection IDs received | {{error-codes}} | +| 0xa | PROTOCOL_VIOLATION | Generic protocol violation | {{error-codes}} | +| 0xb | INVALID_TOKEN | Invalid Token Received | {{error-codes}} | +| 0xc | APPLICATION_ERROR | Application error | {{error-codes}} | +| 0xd | CRYPTO_BUFFER_EXCEEDED | CRYPTO data buffer overflowed | {{error-codes}} | +| 0xe | KEY_UPDATE_ERROR | Invalid packet protection update | {{error-codes}} | | 0xf | AEAD_LIMIT_REACHED | Excessive use of packet protection keys | {{error-codes}} | {: #iana-error-table title="Initial QUIC Transport Error Codes Entries"} From b3ce9e647ba7e0344f852662c200c161a5030537 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 19 Oct 2020 11:02:07 +1100 Subject: [PATCH 5/9] Pad PATH_RESPONSE too --- draft-ietf-quic-transport.md | 37 +++++++++++++++++++----------------- 1 file changed, 20 insertions(+), 17 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index e380aed450..75812ef139 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2205,28 +2205,30 @@ connection. The endpoint MUST use unpredictable data in every PATH_CHALLENGE frame so that it can associate the peer's response with the corresponding PATH_CHALLENGE. -An endpoint MUST expand datagrams that contain a PATH_CHALLENGE -frame to at least the smallest allowed maximum datagram size of 1200 bytes. -Sending UDP datagrams of this size ensures that the network path from the -endpoint to the peer can be used for QUIC; see {{datagram-size}}. - -Note: - -: Probing with datagrams of 1200 bytes does not guarantee that the return path - also supports the same datagram size. Migration to a path that can carry a - 1200-byte UDP payload in only one direction will result in the peer being - unable to validate the return path back to the endpoint. +An endpoint MUST expand datagrams that contain a PATH_CHALLENGE frame to at +least the smallest allowed maximum datagram size of 1200 bytes. Sending UDP +datagrams of this size ensures that the network path from the endpoint to the +peer can be used for QUIC; see {{datagram-size}}. ### Path Validation Responses On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by echoing the -data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame. A -PATH_RESPONSE frame does not need to be sent on the network path where the -PATH_CHALLENGE was received; a PATH_RESPONSE can be sent on any network path. -An endpoint MUST NOT delay transmission of a packet containing a PATH_RESPONSE +data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame. An +endpoint MUST NOT delay transmission of a packet containing a PATH_RESPONSE frame unless constrained by congestion control. +A PATH_RESPONSE frame MUST be sent on the network path where the PATH_CHALLENGE +was received. This requirement MUST NOT be enforced by the endpoint that +initiates path validation as that would enable an attack on migration; see +{{off-path-forward}}. + +An endpoint MUST expand datagrams that contain a PATH_RESPONSE frame to at +least the smallest allowed maximum datagram size of 1200 bytes. This in +combination with sending on the same path allows the endpoint that initiated +path validation to verify that the path is able to carry datagrams of this size +in both directions. + An endpoint MUST NOT send more than one PATH_RESPONSE frame in response to one PATH_CHALLENGE frame; see {{retransmission-of-information}}. The peer is expected to send more PATH_CHALLENGE frames as necessary to evoke additional @@ -2236,8 +2238,9 @@ PATH_RESPONSE frames. ### Successful Path Validation Path validation succeeds when a PATH_RESPONSE frame is received that contains -the data that was sent in a previous PATH_CHALLENGE frame. This validates the -path on which the PATH_CHALLENGE was sent. +the data that was sent in a previous PATH_CHALLENGE frame. This PATH_RESPONSE +frame can be received on any network path. This validates the path on which +the PATH_CHALLENGE was sent. 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 From 663465c6c3679870ac476964ce79adbdd7a73d08 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 19 Oct 2020 14:11:53 +1100 Subject: [PATCH 6/9] Tweaks Co-authored-by: ianswett --- draft-ietf-quic-transport.md | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 75812ef139..c317629895 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2218,16 +2218,14 @@ data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame. An endpoint MUST NOT delay transmission of a packet containing a PATH_RESPONSE frame unless constrained by congestion control. -A PATH_RESPONSE frame MUST be sent on the network path where the PATH_CHALLENGE -was received. This requirement MUST NOT be enforced by the endpoint that -initiates path validation as that would enable an attack on migration; see -{{off-path-forward}}. +A PATH_RESPONSE frame SHOULD be sent on the network path where the PATH_CHALLENGE +was received. This ensures the path is functional in both directions. This requirement +MUST NOT be enforced by the endpoint that initiates path validation as that would enable +an attack on migration; see {{off-path-forward}}. An endpoint MUST expand datagrams that contain a PATH_RESPONSE frame to at -least the smallest allowed maximum datagram size of 1200 bytes. This in -combination with sending on the same path allows the endpoint that initiated -path validation to verify that the path is able to carry datagrams of this size -in both directions. +least the smallest allowed maximum datagram size of 1200 bytes. This verifies +that the path is able to carry datagrams of this size in both directions. An endpoint MUST NOT send more than one PATH_RESPONSE frame in response to one PATH_CHALLENGE frame; see {{retransmission-of-information}}. The peer is @@ -2238,9 +2236,9 @@ PATH_RESPONSE frames. ### Successful Path Validation Path validation succeeds when a PATH_RESPONSE frame is received that contains -the data that was sent in a previous PATH_CHALLENGE frame. This PATH_RESPONSE -frame can be received on any network path. This validates the path on which -the PATH_CHALLENGE was sent. +the data that was sent in a previous PATH_CHALLENGE frame. A PATH_RESPONSE +frame received on any network path validates the path on which the +PATH_CHALLENGE was sent. 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 From 80cbb76dcb5f1873a00047ed147282682ab53df3 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 19 Oct 2020 14:35:11 +1100 Subject: [PATCH 7/9] Wrap; make the other a SHOULD too --- draft-ietf-quic-transport.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index c317629895..68b999bb84 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2218,12 +2218,13 @@ data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame. An endpoint MUST NOT delay transmission of a packet containing a PATH_RESPONSE frame unless constrained by congestion control. -A PATH_RESPONSE frame SHOULD be sent on the network path where the PATH_CHALLENGE -was received. This ensures the path is functional in both directions. This requirement -MUST NOT be enforced by the endpoint that initiates path validation as that would enable -an attack on migration; see {{off-path-forward}}. +A PATH_RESPONSE frame SHOULD be sent on the network path where the +PATH_CHALLENGE was received. This ensures the path is functional in both +directions. This requirement MUST NOT be enforced by the endpoint that +initiates path validation as that would enable an attack on migration; see +{{off-path-forward}}. -An endpoint MUST expand datagrams that contain a PATH_RESPONSE frame to at +An endpoint SHOULD expand datagrams that contain a PATH_RESPONSE frame to at least the smallest allowed maximum datagram size of 1200 bytes. This verifies that the path is able to carry datagrams of this size in both directions. From abde090670ad22def944702d63ecde09600bd88b Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 20 Oct 2020 11:44:55 +1100 Subject: [PATCH 8/9] Peer path validation... --- 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 68b999bb84..78378df7e7 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2219,10 +2219,10 @@ endpoint MUST NOT delay transmission of a packet containing a PATH_RESPONSE frame unless constrained by congestion control. A PATH_RESPONSE frame SHOULD be sent on the network path where the -PATH_CHALLENGE was received. This ensures the path is functional in both -directions. This requirement MUST NOT be enforced by the endpoint that -initiates path validation as that would enable an attack on migration; see -{{off-path-forward}}. +PATH_CHALLENGE was received. This ensures that path validation by a peer only +succeeds if the path is functional in both directions. This requirement MUST +NOT be enforced by the endpoint that initiates path validation as that would +enable an attack on migration; see {{off-path-forward}}. An endpoint SHOULD expand datagrams that contain a PATH_RESPONSE frame to at least the smallest allowed maximum datagram size of 1200 bytes. This verifies From 1e95cb2f928835f5f932ea3ebdce2784a9b1fd0c Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 20 Oct 2020 17:43:41 +1100 Subject: [PATCH 9/9] MUST Co-authored-by: Jana Iyengar --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 78378df7e7..afe4ee029b 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2218,13 +2218,13 @@ data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame. An endpoint MUST NOT delay transmission of a packet containing a PATH_RESPONSE frame unless constrained by congestion control. -A PATH_RESPONSE frame SHOULD be sent on the network path where the +A PATH_RESPONSE frame MUST be sent on the network path where the PATH_CHALLENGE was received. This ensures that path validation by a peer only succeeds if the path is functional in both directions. This requirement MUST NOT be enforced by the endpoint that initiates path validation as that would enable an attack on migration; see {{off-path-forward}}. -An endpoint SHOULD expand datagrams that contain a PATH_RESPONSE frame to at +An endpoint MUST expand datagrams that contain a PATH_RESPONSE frame to at least the smallest allowed maximum datagram size of 1200 bytes. This verifies that the path is able to carry datagrams of this size in both directions.