From 159063288265d7a581e2170672194f29d672e984 Mon Sep 17 00:00:00 2001 From: martinduke Date: Wed, 21 Dec 2016 16:08:06 -0800 Subject: [PATCH 1/8] Update draft-ietf-quic-transport.md Rewrote the PMTUD section as discussed in Issue #64: https://github.com/quicwg/base-drafts/issues/64 Because of concern about user-space implementations controlling kernel PMTU mechanisms, and interest in PLPMTUD as an alternative to tradition ICMP PMTUD, this is a thick web of different options, MUSTs and SHOULDs. In my truest heart I would like to sweep a lot of this away and do a MUST based on around the ICMP system, but though wordy this is more likely to please everyone. --- draft-ietf-quic-transport.md | 91 +++++++++++++++++++++++++++++++++--- 1 file changed, 85 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 711b941034..52657f9bd4 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1198,12 +1198,91 @@ The fields of a GOAWAY frame are as follows: # Packetization and Reliability {#packetization} -The maximum packet size for QUIC is the maximum size of the encrypted payload of -the resulting UDP datagram. All QUIC packets SHOULD be sized to fit within the -path's MTU to avoid IP fragmentation. The recommended default maximum packet -size is 1350 bytes for IPv6 and 1370 bytes for IPv4. To optimize better, -endpoints MAY use PLPMTUD {{!RFC4821}} for detecting the path's MTU and setting -the maximum packet size appropriately. +The maximum packet size for QUIC is the maximum size of the entire UDP payload, +including the public header, encrypted payload, and any authentication fields. +All QUIC packets SHOULD be sized to fit within the path's MTU to avoid IP +fragmentation. To optimize bandwidth efficiency, endpoints SHOULD use Path MTU +Discovery ({{!RFC1191}}, {{!RFC1981}}) or Packetization Layer Path MTU +Discovery ({{!RFC4821}}) for detecting the path's MTU, setting the maximum +packet size appropriately, and storing the result of previous PMTU +determinations. In the absence of these mechanisms, the recommended default +maximum packet size is 1350 bytes for IPv6 and 1370 bytes for IPv4. + +(TODO: Should there be a high minimum MTU for QUIC to avoid ICMP attacks? If so, +does the endpoint fail over to TCP or simply allow fragmentation?) + +QUIC endpoints MUST maintain a separate PMTU estimate for each IP address the +peer is using in the connection. Endpoints SHOULD maintain an estimate for each +combination of local and remote IP addresses (as each pairing may have a different +minimum MTU in the path). + +## Packet MTU Determination + +QUIC endpoints SHOULD set the Don't Fragment (DF) bit in the IP header of selected +QUIC datagrams. These packets MUST use PADDING frames, as necessary, to raise the +overall packet size to the expected maximum. + +### DF Marking {#dfmarking} + +The first packet from the client MUST be maximum-size and SHOULD set the DF bit. + +The last server-generated packet in the Transport Handshake SHOULD be padded to +maximum-size with the DF bit set. Earlier packets may be smaller to save server +resources until various handshake mechanisms have validated the client. + +QUIC endpoints SHOULD set the DF bit on the first packet sent to or from an IP address +new to the QUIC connection, and pad the payload appropriately. + +QUIC endpoints MAY set DF and pad packets when implementing probes as described in +{{!RFC1191}}, {{!RFC1981}}, or {{!RFC4821}}. + +QUIC endpoints MAY set DF and pad packets when it has evidence that the path between two +previously used IP addresses has changed. + +### Special Considerations for Path MTU Discovery + +Traditional ICMP-based path MTU discovery ({{!RFC1191}}, {{!RFC1981}}) is +potentially vulnerable to off-path attacks that succesfully guess the IP/port 4-tuple +and reduce the MTU to a bandwidth-inefficient value. TCP connections mitigate this +risk by using the (at minimum) 8 bytes of transport header echoed in the ICMP message +to validate the TCP sequence number as valid for the current connection. However, as +QUIC operates over UDP, this echoed information may consist only of the IP and UDP +headers, which hold no connection-specific context except the IP/port 4-tuple. + +Furthermore, PMTUD also performs poorly with misbehaving routers that do not send +ICMP Packet Too Big messages {{!RFC2923}}. + +To mitigate this, QUIC endpoints MAY use PLPMTUD, {{!RFC4821}}, either in place of, or +in addition to, PMTUD. This avoids the off-path attack and misbehaving router problems +while potentially introducing multiple packet losses and long timeouts. + +Due to the drawbacks of PLPMTUD, QUIC endpoints MAY use ICMP-based PTMU discovery. +This is optional, and some user-space QUIC implementations may have limited ability to +control the PTMUD process in the kernel. As a result, the following requirements +apply only to PMTUD-enabled implementations and do not exceed the force of a SHOULD: + +The endpoint SHOULD maintain a list of all unacknowledged packet numbers with the DF +flag set. Aside from the requirements in {#dfmarking} above, DF-marked packets SHOULD +NOT be sent more often than every 20 RTTs (implying that the chance of a blind attack +succeeding is less than 5% without a storm of ICMP packets). + +The endpoint SHOULD remove packet numbers from the list when the loss detection algorithm +declares the packet lost, or the packet is acknowledged. + +The endpoint SHOULD ignore any Packet Too Big message that arrives when there are no +unacknowledged packet numbers in the list. + +Incoming Packet Too Big messages SHOULD be applied to all QUIC connections that share +the same local and remote IP addresses, assuming they are valid for one connection. + +Valid Packet Too Big messages SHOULD trigger immediate retransmission of +retransmittable data from packet numbers in the list, with no adjustment in congestion +control parameters consistent with a congestion-induced loss. + +The endpoint MAY store additional information from the IP or UDP headers (for example, +the IP ID or UDP checksum) to further authenticate incoming Packet Too Big messages. + +## Packet Construction A sender bundles one or more frames in a Regular QUIC packet. A sender MAY bundle any set of frames in a packet. All QUIC packets MUST contain a packet From 2021025b266b9ab983c22e3b428ea878db45f58c Mon Sep 17 00:00:00 2001 From: martinduke Date: Tue, 10 Jan 2017 15:34:17 -0800 Subject: [PATCH 2/8] Update draft-ietf-quic-transport.md Substantial edits for #106 to reflect comments for both it and #105. --- draft-ietf-quic-transport.md | 105 ++++++++++------------------------- 1 file changed, 30 insertions(+), 75 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 52657f9bd4..de1810d843 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1201,88 +1201,22 @@ The fields of a GOAWAY frame are as follows: The maximum packet size for QUIC is the maximum size of the entire UDP payload, including the public header, encrypted payload, and any authentication fields. All QUIC packets SHOULD be sized to fit within the path's MTU to avoid IP -fragmentation. To optimize bandwidth efficiency, endpoints SHOULD use Path MTU +fragmentation. To optimize bandwidth efficiency, endpoints MAY use Path MTU Discovery ({{!RFC1191}}, {{!RFC1981}}) or Packetization Layer Path MTU Discovery ({{!RFC4821}}) for detecting the path's MTU, setting the maximum packet size appropriately, and storing the result of previous PMTU determinations. In the absence of these mechanisms, the recommended default maximum packet size is 1350 bytes for IPv6 and 1370 bytes for IPv4. -(TODO: Should there be a high minimum MTU for QUIC to avoid ICMP attacks? If so, -does the endpoint fail over to TCP or simply allow fragmentation?) +QUIC endpoints that implement any kind of MTU discovery SHOULD maintain a +separate PMTU estimate for each IP address the peer is using in the +connection. Endpoints SHOULD maintain an estimate for each combination of +local and remote IP addresses (as each pairing may have a different minimum +MTU in the path). -QUIC endpoints MUST maintain a separate PMTU estimate for each IP address the -peer is using in the connection. Endpoints SHOULD maintain an estimate for each -combination of local and remote IP addresses (as each pairing may have a different -minimum MTU in the path). - -## Packet MTU Determination - -QUIC endpoints SHOULD set the Don't Fragment (DF) bit in the IP header of selected -QUIC datagrams. These packets MUST use PADDING frames, as necessary, to raise the -overall packet size to the expected maximum. - -### DF Marking {#dfmarking} - -The first packet from the client MUST be maximum-size and SHOULD set the DF bit. - -The last server-generated packet in the Transport Handshake SHOULD be padded to -maximum-size with the DF bit set. Earlier packets may be smaller to save server -resources until various handshake mechanisms have validated the client. - -QUIC endpoints SHOULD set the DF bit on the first packet sent to or from an IP address -new to the QUIC connection, and pad the payload appropriately. - -QUIC endpoints MAY set DF and pad packets when implementing probes as described in -{{!RFC1191}}, {{!RFC1981}}, or {{!RFC4821}}. - -QUIC endpoints MAY set DF and pad packets when it has evidence that the path between two -previously used IP addresses has changed. - -### Special Considerations for Path MTU Discovery - -Traditional ICMP-based path MTU discovery ({{!RFC1191}}, {{!RFC1981}}) is -potentially vulnerable to off-path attacks that succesfully guess the IP/port 4-tuple -and reduce the MTU to a bandwidth-inefficient value. TCP connections mitigate this -risk by using the (at minimum) 8 bytes of transport header echoed in the ICMP message -to validate the TCP sequence number as valid for the current connection. However, as -QUIC operates over UDP, this echoed information may consist only of the IP and UDP -headers, which hold no connection-specific context except the IP/port 4-tuple. - -Furthermore, PMTUD also performs poorly with misbehaving routers that do not send -ICMP Packet Too Big messages {{!RFC2923}}. - -To mitigate this, QUIC endpoints MAY use PLPMTUD, {{!RFC4821}}, either in place of, or -in addition to, PMTUD. This avoids the off-path attack and misbehaving router problems -while potentially introducing multiple packet losses and long timeouts. - -Due to the drawbacks of PLPMTUD, QUIC endpoints MAY use ICMP-based PTMU discovery. -This is optional, and some user-space QUIC implementations may have limited ability to -control the PTMUD process in the kernel. As a result, the following requirements -apply only to PMTUD-enabled implementations and do not exceed the force of a SHOULD: - -The endpoint SHOULD maintain a list of all unacknowledged packet numbers with the DF -flag set. Aside from the requirements in {#dfmarking} above, DF-marked packets SHOULD -NOT be sent more often than every 20 RTTs (implying that the chance of a blind attack -succeeding is less than 5% without a storm of ICMP packets). - -The endpoint SHOULD remove packet numbers from the list when the loss detection algorithm -declares the packet lost, or the packet is acknowledged. - -The endpoint SHOULD ignore any Packet Too Big message that arrives when there are no -unacknowledged packet numbers in the list. - -Incoming Packet Too Big messages SHOULD be applied to all QUIC connections that share -the same local and remote IP addresses, assuming they are valid for one connection. - -Valid Packet Too Big messages SHOULD trigger immediate retransmission of -retransmittable data from packet numbers in the list, with no adjustment in congestion -control parameters consistent with a congestion-induced loss. - -The endpoint MAY store additional information from the IP or UDP headers (for example, -the IP ID or UDP checksum) to further authenticate incoming Packet Too Big messages. - -## Packet Construction +All handshake packets MUST include enough PADDING frames to bring the packet +to the maximum size the endpoint is enforcing. Furthermore, all IPv4 handshake +packets MUST have the DF bit set. A sender bundles one or more frames in a Regular QUIC packet. A sender MAY bundle any set of frames in a packet. All QUIC packets MUST contain a packet @@ -1336,6 +1270,27 @@ frames), the receiving peer MAY send an ACK frame after a reasonable number Strategies and implications of the frequency of generating acknowledgments are discussed in more detail in {{QUIC-RECOVERY}}. +## Special Considerations for Path MTU Discovery + +Traditional ICMP-based path MTU discovery ({{!RFC1191}}, {{!RFC1981}}) is +potentially vulnerable to off-path attacks that succesfully guess the IP/port +4-tuple and reduce the MTU to a bandwidth-inefficient value. TCP connections +mitigate this risk by using the (at minimum) 8 bytes of transport header +echoed in the ICMP message to validate the TCP sequence number as valid for +the current connection. However, as QUIC operates over UDP, the echoed +information may consist only of the IP and UDP headers, which usually has +insufficient entropy to mitigate off-path attacks. + +As a result, endpoints that implement PMTUD SHOULD take steps to mitigate this +risk, which may include: + +* Set the IPv4 Don't Fragment (DF) bit on a small number of packets per RTT, so +that most invalid ICMP messages arrive when there are no DF packets +outstanding. + +* Store additional information from the IP or UDP headers (for example, the IP +ID or UDP checksum) to further authenticate incoming Packet Too Big messages. + # Streams: QUIC's Data Structuring Abstraction {#streams} Streams in QUIC provide a lightweight, ordered, and bidirectional byte-stream From 6ef293130e793f8a5ec4459f4fa55a801cf99c66 Mon Sep 17 00:00:00 2001 From: martinduke Date: Wed, 11 Jan 2017 16:48:15 -0800 Subject: [PATCH 3/8] Update draft-ietf-quic-transport.md - Clarified that packet number ambiguity only exists in IPv4, as RFC 1885 requires IPv6 packet-too-big messages to be quite a bit longer. - Addressed all of Ian's comments, except... - I'm sticking with the MUST set DF for IPv4 handshake packets, because I don't see how the basic test-the-MTU mechanism works without it. --- draft-ietf-quic-transport.md | 37 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 19 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index de1810d843..db2eb49294 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1205,18 +1205,17 @@ fragmentation. To optimize bandwidth efficiency, endpoints MAY use Path MTU Discovery ({{!RFC1191}}, {{!RFC1981}}) or Packetization Layer Path MTU Discovery ({{!RFC4821}}) for detecting the path's MTU, setting the maximum packet size appropriately, and storing the result of previous PMTU -determinations. In the absence of these mechanisms, the recommended default +determinations. In the absence of these mechanisms, the recommended default maximum packet size is 1350 bytes for IPv6 and 1370 bytes for IPv4. QUIC endpoints that implement any kind of MTU discovery SHOULD maintain a -separate PMTU estimate for each IP address the peer is using in the -connection. Endpoints SHOULD maintain an estimate for each combination of -local and remote IP addresses (as each pairing may have a different minimum -MTU in the path). +separate PMTU estimate for each IP address the peer is using in a connection. +Endpoints MAY maintain an estimate for each combination of local and remote IP +addresses (as each pairing may have a different minimum MTU in the path). -All handshake packets MUST include enough PADDING frames to bring the packet -to the maximum size the endpoint is enforcing. Furthermore, all IPv4 handshake -packets MUST have the DF bit set. +All handshake packets MUST include a PADDING frame if necessary to bring the +packet to the maximum size the endpoint is enforcing. Furthermore, all IPv4 +handshake packets MUST have the DF bit set. A sender bundles one or more frames in a Regular QUIC packet. A sender MAY bundle any set of frames in a packet. All QUIC packets MUST contain a packet @@ -1272,17 +1271,17 @@ discussed in more detail in {{QUIC-RECOVERY}}. ## Special Considerations for Path MTU Discovery -Traditional ICMP-based path MTU discovery ({{!RFC1191}}, {{!RFC1981}}) is -potentially vulnerable to off-path attacks that succesfully guess the IP/port -4-tuple and reduce the MTU to a bandwidth-inefficient value. TCP connections -mitigate this risk by using the (at minimum) 8 bytes of transport header -echoed in the ICMP message to validate the TCP sequence number as valid for -the current connection. However, as QUIC operates over UDP, the echoed -information may consist only of the IP and UDP headers, which usually has -insufficient entropy to mitigate off-path attacks. - -As a result, endpoints that implement PMTUD SHOULD take steps to mitigate this -risk, which may include: +Traditional ICMP-based path MTU discovery in IPv4 ({{!RFC1191}} is potentially +vulnerable to off-path attacks that succesfully guess the IP/port 4-tuple and +reduce the MTU to a bandwidth-inefficient value. TCP connections mitigate this +risk by using the (at minimum) 8 bytes of transport header echoed in the ICMP +message to validate the TCP sequence number as valid for the current +connection. However, as QUIC operates over UDP, in IPv4 the echoed information +may consist only of the IP and UDP headers, which usually has insufficient +entropy to mitigate off-path attacks. + +As a result, endpoints that implement PMTUD in IPv4 SHOULD take steps to mitigate +this risk, which may include: * Set the IPv4 Don't Fragment (DF) bit on a small number of packets per RTT, so that most invalid ICMP messages arrive when there are no DF packets From 9fbcca385dbf5a43916b4f217ec4d4b62407a458 Mon Sep 17 00:00:00 2001 From: martinduke Date: Thu, 12 Jan 2017 09:16:04 -0800 Subject: [PATCH 4/8] Revised PMTU section Addressed Jana's comments. --- draft-ietf-quic-transport.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index db2eb49294..634cfc2e7b 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1208,14 +1208,13 @@ packet size appropriately, and storing the result of previous PMTU determinations. In the absence of these mechanisms, the recommended default maximum packet size is 1350 bytes for IPv6 and 1370 bytes for IPv4. -QUIC endpoints that implement any kind of MTU discovery SHOULD maintain a -separate PMTU estimate for each IP address the peer is using in a connection. -Endpoints MAY maintain an estimate for each combination of local and remote IP -addresses (as each pairing may have a different minimum MTU in the path). - All handshake packets MUST include a PADDING frame if necessary to bring the packet to the maximum size the endpoint is enforcing. Furthermore, all IPv4 -handshake packets MUST have the DF bit set. +handshake packets SHOULD have the DF bit set. + +QUIC endpoints that implement any kind of MTU discovery SHOULD maintain an +estimate for each combination of local and remote IP addresses (as each pairing +may have a different maximum MTU in the path). A sender bundles one or more frames in a Regular QUIC packet. A sender MAY bundle any set of frames in a packet. All QUIC packets MUST contain a packet @@ -1281,7 +1280,7 @@ may consist only of the IP and UDP headers, which usually has insufficient entropy to mitigate off-path attacks. As a result, endpoints that implement PMTUD in IPv4 SHOULD take steps to mitigate -this risk, which may include: +this risk. For instance, an application may: * Set the IPv4 Don't Fragment (DF) bit on a small number of packets per RTT, so that most invalid ICMP messages arrive when there are no DF packets From e7b455c745f1c2da93b1b393cad030e818e986e1 Mon Sep 17 00:00:00 2001 From: martinduke Date: Fri, 13 Jan 2017 10:35:27 -0800 Subject: [PATCH 5/8] Update draft-ietf-quic-transport.md Addressed Martin T's 01/12 comments. --- draft-ietf-quic-transport.md | 51 ++++++++++++++++++++---------------- 1 file changed, 28 insertions(+), 23 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 634cfc2e7b..f68a7a0367 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1198,23 +1198,28 @@ The fields of a GOAWAY frame are as follows: # Packetization and Reliability {#packetization} -The maximum packet size for QUIC is the maximum size of the entire UDP payload, -including the public header, encrypted payload, and any authentication fields. -All QUIC packets SHOULD be sized to fit within the path's MTU to avoid IP -fragmentation. To optimize bandwidth efficiency, endpoints MAY use Path MTU -Discovery ({{!RFC1191}}, {{!RFC1981}}) or Packetization Layer Path MTU -Discovery ({{!RFC4821}}) for detecting the path's MTU, setting the maximum -packet size appropriately, and storing the result of previous PMTU -determinations. In the absence of these mechanisms, the recommended default -maximum packet size is 1350 bytes for IPv6 and 1370 bytes for IPv4. - -All handshake packets MUST include a PADDING frame if necessary to bring the -packet to the maximum size the endpoint is enforcing. Furthermore, all IPv4 +The Path Maximum Transmission Unit (PTMU) is the maximum size of the entire IP +header, UDP header, and UDP payload. The UDP payload includes the QUIC public +header, encrypted payload, and any authentication fields. + +All QUIC packets SHOULD be sized to fit within the estimated PMTU to avoid IP +fragmentation or packet drops. To optimize bandwidth efficiency, endpoints MAY +use PMTU Discovery ({{!RFC1191}}, {{!RFC1981}}) or Packetization Layer PMTU +Discovery ({{!RFC4821}}) for detecting the PMTU, setting the PMTU appropriately, +and storing the result of previous PMTU determinations. + +In the absence of these mechanisms, QUIC endpoints SHOULD use a default PMTU of +1398 octets. Assuming the minimum IP header size, this results in a UDP payload +length of 1350 octets for IPv6 and 1370 octets for IPv4. + +Both the QUIC client and server MUST send at least one handshake packet of size +equal to the estimated PMTU, and receive an acknowledgment for that packet. This +could require a PADDING frame to increase the packet size. PMTU-size, IPv4 handshake packets SHOULD have the DF bit set. -QUIC endpoints that implement any kind of MTU discovery SHOULD maintain an +QUIC endpoints that implement any kind of PMTU discovery SHOULD maintain an estimate for each combination of local and remote IP addresses (as each pairing -may have a different maximum MTU in the path). +could have a different maximum MTU in the path). A sender bundles one or more frames in a Regular QUIC packet. A sender MAY bundle any set of frames in a packet. All QUIC packets MUST contain a packet @@ -1268,26 +1273,26 @@ frames), the receiving peer MAY send an ACK frame after a reasonable number Strategies and implications of the frequency of generating acknowledgments are discussed in more detail in {{QUIC-RECOVERY}}. -## Special Considerations for Path MTU Discovery +## Special Considerations for PMTU Discovery Traditional ICMP-based path MTU discovery in IPv4 ({{!RFC1191}} is potentially -vulnerable to off-path attacks that succesfully guess the IP/port 4-tuple and +vulnerable to off-path attacks that successfully guess the IP/port 4-tuple and reduce the MTU to a bandwidth-inefficient value. TCP connections mitigate this risk by using the (at minimum) 8 bytes of transport header echoed in the ICMP message to validate the TCP sequence number as valid for the current connection. However, as QUIC operates over UDP, in IPv4 the echoed information -may consist only of the IP and UDP headers, which usually has insufficient +could consist only of the IP and UDP headers, which usually has insufficient entropy to mitigate off-path attacks. As a result, endpoints that implement PMTUD in IPv4 SHOULD take steps to mitigate -this risk. For instance, an application may: +this risk. For instance, an application could: -* Set the IPv4 Don't Fragment (DF) bit on a small number of packets per RTT, so -that most invalid ICMP messages arrive when there are no DF packets -outstanding. +* Set the IPv4 Don't Fragment (DF) bit on a small proportion of packets, so that +most invalid ICMP messages arrive when there are no DF packets outstanding. -* Store additional information from the IP or UDP headers (for example, the IP -ID or UDP checksum) to further authenticate incoming Packet Too Big messages. +* Store additional information from the IP or UDP headers from DF packets (for +example, the IP ID or UDP checksum) to further authenticate incoming Packet Too +Big messages. # Streams: QUIC's Data Structuring Abstraction {#streams} From e7683255809c372d2de7a4355a94036f384943b1 Mon Sep 17 00:00:00 2001 From: martinduke Date: Tue, 17 Jan 2017 08:45:50 -0800 Subject: [PATCH 6/8] Update draft-ietf-quic-transport.md Removed the paragraph on handshake padding (now in Issue #164) so that the rest can be merged into the document. --- draft-ietf-quic-transport.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index f68a7a0367..b4b5fb866d 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1212,11 +1212,6 @@ In the absence of these mechanisms, QUIC endpoints SHOULD use a default PMTU of 1398 octets. Assuming the minimum IP header size, this results in a UDP payload length of 1350 octets for IPv6 and 1370 octets for IPv4. -Both the QUIC client and server MUST send at least one handshake packet of size -equal to the estimated PMTU, and receive an acknowledgment for that packet. This -could require a PADDING frame to increase the packet size. PMTU-size, IPv4 -handshake packets SHOULD have the DF bit set. - QUIC endpoints that implement any kind of PMTU discovery SHOULD maintain an estimate for each combination of local and remote IP addresses (as each pairing could have a different maximum MTU in the path). From 5bf31689873343f75f8e7f7d854c360dc602a884 Mon Sep 17 00:00:00 2001 From: martinduke Date: Thu, 26 Jan 2017 12:43:17 -0800 Subject: [PATCH 7/8] Update draft-ietf-quic-transport.md Added all the changes decided on in Tokyo for #64, #69, #139, #164. I imagine any remaining comments will be editorial. --- draft-ietf-quic-transport.md | 38 ++++++++++++++++++++++++++++++------ 1 file changed, 32 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index b4b5fb866d..ac91ff8687 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1203,19 +1203,41 @@ header, UDP header, and UDP payload. The UDP payload includes the QUIC public header, encrypted payload, and any authentication fields. All QUIC packets SHOULD be sized to fit within the estimated PMTU to avoid IP -fragmentation or packet drops. To optimize bandwidth efficiency, endpoints MAY -use PMTU Discovery ({{!RFC1191}}, {{!RFC1981}}) or Packetization Layer PMTU -Discovery ({{!RFC4821}}) for detecting the PMTU, setting the PMTU appropriately, -and storing the result of previous PMTU determinations. +fragmentation or packet drops. To optimize bandwidth efficiency, endpoints +SHOULD use Packetization Layer PMTU Discovery ({{!RFC4821}}) and MAY use PMTU +Discovery ({{!RFC1191}}, {{!RFC1981}}) for detecting the PMTU, setting the PMTU +appropriately, and storing the result of previous PMTU determinations. In the absence of these mechanisms, QUIC endpoints SHOULD use a default PMTU of -1398 octets. Assuming the minimum IP header size, this results in a UDP payload -length of 1350 octets for IPv6 and 1370 octets for IPv4. +1280 octets. Assuming the minimum IP header size, this results in a UDP payload +length of 1232 octets for IPv6 and 1252 octets for IPv4. QUIC endpoints that implement any kind of PMTU discovery SHOULD maintain an estimate for each combination of local and remote IP addresses (as each pairing could have a different maximum MTU in the path). +QUIC connnections MUST NOT operate over a network path with an estimated PMTU +below 1280 octets. This is equal to the IPv6 minimum. Most modern IPv4 networks +support at least this packet size. A large packet size allows the first client +handshake packet to fit in a single datagram, which in turn enables stateless +rejects by the server. + +If a QUIC endpoint determines that the PMTU between any pair of local and remote +IP addresses has fallen below 1280 octets, it MUST immediately cease sending +QUIC packets between those IP addresses. This may result in abrupt termination +of the connection if all pairs are affected. In this case, an endpoint SHOULD +send a Public Reset packet to indicate the failure. The application SHOULD +attempt to use TLS over TCP instead. + +Clients MUST ensure that the first packet in a connection, and any +retransmissions of those octets, has a total size (including IP and UDP headers) +of at least 1280 bytes. This might require inclusion of a PADDING frame. Clients +MAY use a larger first packet size if it has reasonable assurance of a higher +PMTU through out-of-band information. + +Servers MUST reject the first plaintext packet received from a client if it its +total size is less than 1280 octets, to mitigate amplification attacks. + A sender bundles one or more frames in a Regular QUIC packet. A sender MAY bundle any set of frames in a packet. All QUIC packets MUST contain a packet number and MAY contain one or more frames ({{frames}}). Packet numbers MUST be @@ -1289,6 +1311,10 @@ most invalid ICMP messages arrive when there are no DF packets outstanding. example, the IP ID or UDP checksum) to further authenticate incoming Packet Too Big messages. +* Any reduction in PMTU due to a report contained in an ICMP packet is +provisional until QUIC's loss detection algorithm determines that the packet is +actually lost. + # Streams: QUIC's Data Structuring Abstraction {#streams} Streams in QUIC provide a lightweight, ordered, and bidirectional byte-stream From cfaeff689a7d3d9a8204939c2cdea61f7e75077d Mon Sep 17 00:00:00 2001 From: martinduke Date: Tue, 7 Feb 2017 16:34:53 -0800 Subject: [PATCH 8/8] Update draft-ietf-quic-transport.md Addressed Martin Thomson's issues. Changes are not quite verbatim from his suggestions. --- draft-ietf-quic-transport.md | 43 +++++++++++++++++++----------------- 1 file changed, 23 insertions(+), 20 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index ac91ff8687..5777c75038 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1208,19 +1208,30 @@ SHOULD use Packetization Layer PMTU Discovery ({{!RFC4821}}) and MAY use PMTU Discovery ({{!RFC1191}}, {{!RFC1981}}) for detecting the PMTU, setting the PMTU appropriately, and storing the result of previous PMTU determinations. -In the absence of these mechanisms, QUIC endpoints SHOULD use a default PMTU of -1280 octets. Assuming the minimum IP header size, this results in a UDP payload -length of 1232 octets for IPv6 and 1252 octets for IPv4. +In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP packets +larger than 1280 octets. Assuming the minimum IP header size, this results in +a UDP payload length of 1232 octets for IPv6 and 1252 octets for IPv4. QUIC endpoints that implement any kind of PMTU discovery SHOULD maintain an estimate for each combination of local and remote IP addresses (as each pairing could have a different maximum MTU in the path). -QUIC connnections MUST NOT operate over a network path with an estimated PMTU -below 1280 octets. This is equal to the IPv6 minimum. Most modern IPv4 networks -support at least this packet size. A large packet size allows the first client -handshake packet to fit in a single datagram, which in turn enables stateless -rejects by the server. +QUIC depends on the network path supporting a MTU of at least 1280 octets. This +is the IPv6 minimum and therefore also supported by most modern IPv4 networks. +An endpoint MUST NOT reduce their MTU below this number, even if it receives +signals that indicate a smaller limit might exist. + +Clients MUST ensure that the first packet in a connection, and any +retransmissions of those octets, has a total size (including IP and UDP headers) +of at least 1280 bytes. This might require inclusion of a PADDING frame. It is +RECOMMENDED that a packet be padded to exactly 1280 octets unless the client has +a reasonable assurance that the PMTU is larger. Sending a packet of this size +ensures that the network path supports an MTU of this size and helps mitigate +amplification attacks caused by server responses toward an unverified client +address. + +Servers MUST reject the first plaintext packet received from a client if it its +total size is less than 1280 octets, to mitigate amplification attacks. If a QUIC endpoint determines that the PMTU between any pair of local and remote IP addresses has fallen below 1280 octets, it MUST immediately cease sending @@ -1229,15 +1240,6 @@ of the connection if all pairs are affected. In this case, an endpoint SHOULD send a Public Reset packet to indicate the failure. The application SHOULD attempt to use TLS over TCP instead. -Clients MUST ensure that the first packet in a connection, and any -retransmissions of those octets, has a total size (including IP and UDP headers) -of at least 1280 bytes. This might require inclusion of a PADDING frame. Clients -MAY use a larger first packet size if it has reasonable assurance of a higher -PMTU through out-of-band information. - -Servers MUST reject the first plaintext packet received from a client if it its -total size is less than 1280 octets, to mitigate amplification attacks. - A sender bundles one or more frames in a Regular QUIC packet. A sender MAY bundle any set of frames in a packet. All QUIC packets MUST contain a packet number and MAY contain one or more frames ({{frames}}). Packet numbers MUST be @@ -1305,11 +1307,12 @@ As a result, endpoints that implement PMTUD in IPv4 SHOULD take steps to mitigat this risk. For instance, an application could: * Set the IPv4 Don't Fragment (DF) bit on a small proportion of packets, so that -most invalid ICMP messages arrive when there are no DF packets outstanding. +most invalid ICMP messages arrive when there are no DF packets outstanding, and +can therefore be identified as spurious. * Store additional information from the IP or UDP headers from DF packets (for -example, the IP ID or UDP checksum) to further authenticate incoming Packet Too -Big messages. +example, the IP ID or UDP checksum) to further authenticate incoming Datagram +Too Big messages. * Any reduction in PMTU due to a report contained in an ICMP packet is provisional until QUIC's loss detection algorithm determines that the packet is