draft-ietf-quic-manageability-12.txt   draft-ietf-quic-manageability-13.txt 
Network Working Group M. Kuehlewind Network Working Group M. Kuehlewind
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational B. Trammell Intended status: Informational B. Trammell
Expires: 1 January 2022 Google Switzerland GmbH Expires: 6 March 2022 Google Switzerland GmbH
30 June 2021 2 September 2021
Manageability of the QUIC Transport Protocol Manageability of the QUIC Transport Protocol
draft-ietf-quic-manageability-12 draft-ietf-quic-manageability-13
Abstract Abstract
This document discusses manageability of the QUIC transport protocol, This document discusses manageability of the QUIC transport protocol,
focusing on the implications of QUIC's design and wire image on focusing on the implications of QUIC's design and wire image on
network operations involving QUIC traffic. Its intended audience is network operations involving QUIC traffic. Its intended audience is
network operators and equipment vendors who rely on the use of network operators and equipment vendors who rely on the use of
transport-aware network functions. transport-aware network functions.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 January 2022. This Internet-Draft will expire on 6 March 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 39 skipping to change at page 2, line 39
3.8. Round-Trip Time (RTT) Measurement . . . . . . . . . . . . 17 3.8. Round-Trip Time (RTT) Measurement . . . . . . . . . . . . 17
3.8.1. Measuring Initial RTT . . . . . . . . . . . . . . . . 18 3.8.1. Measuring Initial RTT . . . . . . . . . . . . . . . . 18
3.8.2. Using the Spin Bit for Passive RTT Measurement . . . 18 3.8.2. Using the Spin Bit for Passive RTT Measurement . . . 18
4. Specific Network Management Tasks . . . . . . . . . . . . . . 20 4. Specific Network Management Tasks . . . . . . . . . . . . . . 20
4.1. Passive Network Performance Measurement and 4.1. Passive Network Performance Measurement and
Troubleshooting . . . . . . . . . . . . . . . . . . . . 20 Troubleshooting . . . . . . . . . . . . . . . . . . . . 20
4.2. Stateful Treatment of QUIC Traffic . . . . . . . . . . . 20 4.2. Stateful Treatment of QUIC Traffic . . . . . . . . . . . 20
4.3. Address Rewriting to Ensure Routing Stability . . . . . . 22 4.3. Address Rewriting to Ensure Routing Stability . . . . . . 22
4.4. Server Cooperation with Load Balancers . . . . . . . . . 22 4.4. Server Cooperation with Load Balancers . . . . . . . . . 22
4.5. Filtering Behavior . . . . . . . . . . . . . . . . . . . 23 4.5. Filtering Behavior . . . . . . . . . . . . . . . . . . . 23
4.6. UDP Blocking or Throttling . . . . . . . . . . . . . . . 23 4.6. UDP Blocking, Throttling, and NAT Binding . . . . . . . . 23
4.7. DDoS Detection and Mitigation . . . . . . . . . . . . . . 24 4.7. DDoS Detection and Mitigation . . . . . . . . . . . . . . 24
4.8. Quality of Service Handling and ECMP Routing . . . . . . 25 4.8. Quality of Service Handling and ECMP Routing . . . . . . 25
4.9. Handling ICMP Messages . . . . . . . . . . . . . . . . . 25 4.9. Handling ICMP Messages . . . . . . . . . . . . . . . . . 26
4.10. Guiding Path MTU . . . . . . . . . . . . . . . . . . . . 26 4.10. Guiding Path MTU . . . . . . . . . . . . . . . . . . . . 26
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . 28 9.1. Normative References . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . 29 9.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
QUIC [QUIC-TRANSPORT] is a new transport protocol that is QUIC [QUIC-TRANSPORT] is a new transport protocol that is
encapsulated in UDP. QUIC integrates TLS [QUIC-TLS] to encrypt all encapsulated in UDP. QUIC integrates TLS [QUIC-TLS] to encrypt all
payload data and most control information. QUIC version 1 was payload data and most control information. QUIC version 1 was
designed primarily as a transport for HTTP, with the resulting designed primarily as a transport for HTTP, with the resulting
protocol being known as HTTP/3 [QUIC-HTTP]. protocol being known as HTTP/3 [QUIC-HTTP].
This document provides guidance for network operations that manage This document provides guidance for network operations that manage
skipping to change at page 15, line 38 skipping to change at page 15, line 38
used if the connection continues. used if the connection continues.
Work is currently underway in the TLS working group to encrypt the Work is currently underway in the TLS working group to encrypt the
contents of the ClientHello in TLS 1.3 [TLS-ECH]. This would make contents of the ClientHello in TLS 1.3 [TLS-ECH]. This would make
SNI-based application identification impossible by on-path SNI-based application identification impossible by on-path
observation for QUIC and other protocols that use TLS. observation for QUIC and other protocols that use TLS.
3.4.1. Extracting Server Name Indication (SNI) Information 3.4.1. Extracting Server Name Indication (SNI) Information
If the ClientHello is not encrypted, SNI can be derived from the If the ClientHello is not encrypted, SNI can be derived from the
client's Initial packet by calculating the Initial secret to decrypt client's Initial packet(s) by calculating the Initial secret to
the packet payload and parsing the QUIC CRYPTO frame(s) containing decrypt the packet payload and parsing the QUIC CRYPTO frame(s)
the TLS ClientHello. containing the TLS ClientHello.
As both the derivation of the Initial secret and the structure of the As both the derivation of the Initial secret and the structure of the
Initial packet itself are version-specific, the first step is always Initial packet itself are version-specific, the first step is always
to parse the version number (the second through fifth bytes of the to parse the version number (the second through fifth bytes of the
long header). Note that only long header packets carry the version long header). Note that only long header packets carry the version
number, so it is necessary to also check if the first bit of the QUIC number, so it is necessary to also check if the first bit of the QUIC
packet is set to 1, indicating a long header. packet is set to 1, indicating a long header.
Note that proprietary QUIC versions, that have been deployed before Note that proprietary QUIC versions, that have been deployed before
standardization, might not set the first bit in a QUIC long header standardization, might not set the first bit in a QUIC long header
skipping to change at page 16, line 20 skipping to change at page 16, line 20
as described in Section 5.2 of [QUIC-TLS]. The length of the as described in Section 5.2 of [QUIC-TLS]. The length of the
connection ID is indicated in the 6th byte of the header followed by connection ID is indicated in the 6th byte of the header followed by
the connection ID itself. the connection ID itself.
Note that subsequent Initial packets might contain a Destination Note that subsequent Initial packets might contain a Destination
Connection ID other than the one used to generate the Initial secret. Connection ID other than the one used to generate the Initial secret.
Therefore, attempts to decrypt these packets using the procedure Therefore, attempts to decrypt these packets using the procedure
above might fail unless the Initial secret is retained by the above might fail unless the Initial secret is retained by the
observer. observer.
To determine the end of the header and find the start of the payload, To determine the end of the packet header and find the start of the
the packet number length, the source connection ID length, and the payload, the packet number length, the source connection ID length,
token length need to be extracted. The packet number length is and the token length need to be extracted. The packet number length
defined by the seventh and eight bits of the header as described in is defined by the seventh and eight bits of the header as described
Section 17.2 of [QUIC-TRANSPORT], but is obfuscated as described in in Section 17.2 of [QUIC-TRANSPORT], but is obfuscated as described
Section 5.4 of [QUIC-TLS]. The source connection ID length is in Section 5.4 of [QUIC-TLS]. The source connection ID length is
specified in the byte after the destination connection ID. The token specified in the byte after the destination connection ID. The token
length, which follows the source connection ID, is a variable-length length, which follows the source connection ID, is a variable-length
integer as specified in Section 16 of [QUIC-TRANSPORT]. integer as specified in Section 16 of [QUIC-TRANSPORT].
After decryption, the client's Initial packet can be parsed to detect After decryption, the client's Initial packet(s) can be parsed to
the CRYPTO frame(s) that contains the TLS ClientHello, which then can detect the CRYPTO frame(s) that contains the TLS ClientHello, which
be parsed similarly to TLS over TCP connections. Note that there can then can be parsed similarly to TLS over TCP connections. Note that
be multiple CRYPTO frames, and they might not be in order, so there can be multiple CRYPTO frames spread out over one or mor
reassembling the CRYPTO stream by parsing offsets and lengths is Initial packets, and they might not be in order, so reassembling the
required. Further, the client's Initial packet may contain other CRYPTO stream by parsing offsets and lengths is required. Further,
frames, so the first bytes of each frame need to be checked to the client's Initial packet(s) may contain other frames, so the first
identify the frame type, and if needed skipped over it. Note that bytes of each frame need to be checked to identify the frame type,
the length of the frames is dependent on the frame type; see and if needed skipped over it. Note that the length of the frames is
Section 18 of [QUIC-TRANSPORT]. E.g. PADDING frames, each dependent on the frame type; see Section 18 of [QUIC-TRANSPORT].
consisting of a single zero byte, may occur before, after, or between E.g. PADDING frames, each consisting of a single zero byte, may
CRYPTO frames. However, extensions might define additional frame occur before, after, or between CRYPTO frames. However, extensions
types. If an unknown frame type is encountered, it is impossible to might define additional frame types. If an unknown frame type is
know the length of that frame which prevents skipping over it, and encountered, it is impossible to know the length of that frame which
therefore parsing fails. prevents skipping over it, and therefore parsing fails.
3.5. Flow Association 3.5. Flow Association
The QUIC connection ID (see Section 2.6) is designed to allow a The QUIC connection ID (see Section 2.6) is designed to allow a
coordinating on-path device, such as a load-balancer, to associate coordinating on-path device, such as a load-balancer, to associate
two flows when one of the endpoints changes address. This change can two flows when one of the endpoints changes address. This change can
be due to NAT rebinding or address migration. be due to NAT rebinding or address migration.
The connection ID must change upon intentional address change by an The connection ID must change upon intentional address change by an
endpoint, and connection ID negotiation is encrypted, so it is not endpoint, and connection ID negotiation is encrypted, so it is not
skipping to change at page 23, line 20 skipping to change at page 23, line 20
particularly unwise behavior admits a handful of UDP packets and then particularly unwise behavior admits a handful of UDP packets and then
makes a decision to whether or not filter later packets in the same makes a decision to whether or not filter later packets in the same
connection. QUIC applications are encouraged to fail over to TCP if connection. QUIC applications are encouraged to fail over to TCP if
early packets do not arrive at their destination early packets do not arrive at their destination
[I-D.ietf-quic-applicability], as QUIC is based on UDP and there are [I-D.ietf-quic-applicability], as QUIC is based on UDP and there are
known blocks of UDP traffic (see Section 4.6). Admitting a few known blocks of UDP traffic (see Section 4.6). Admitting a few
packets allows the QUIC endpoint to determine that the path accepts packets allows the QUIC endpoint to determine that the path accepts
QUIC. Sudden drops afterwards will result in slow and costly QUIC. Sudden drops afterwards will result in slow and costly
timeouts before abandoning the connection. timeouts before abandoning the connection.
4.6. UDP Blocking or Throttling 4.6. UDP Blocking, Throttling, and NAT Binding
Today, UDP is the most prevalent DDoS vector, since it is easy for Today, UDP is the most prevalent DDoS vector, since it is easy for
compromised non-admin applications to send a flood of large UDP compromised non-admin applications to send a flood of large UDP
packets (while with TCP the attacker gets throttled by the congestion packets (while with TCP the attacker gets throttled by the congestion
controller) or to craft reflection and amplification attacks. Some controller) or to craft reflection and amplification attacks. Some
networks therefore block UDP traffic. With increased deployment of networks therefore block UDP traffic. With increased deployment of
QUIC, there is also an increased need to allow UDP traffic on ports QUIC, there is also an increased need to allow UDP traffic on ports
used for QUIC. However, if UDP is generally enabled on these ports, used for QUIC. However, if UDP is generally enabled on these ports,
UDP flood attacks may also use the same ports. One possible response UDP flood attacks may also use the same ports. One possible response
to this threat is to throttle UDP traffic on the network, allocating to this threat is to throttle UDP traffic on the network, allocating
skipping to change at page 24, line 5 skipping to change at page 24, line 5
Section 4.5). Therefore, UDP throttling should be realized by per- Section 4.5). Therefore, UDP throttling should be realized by per-
flow policing, as opposed to per-packet policing. Note that this flow policing, as opposed to per-packet policing. Note that this
per-flow policing should be stateless to avoid problems with stateful per-flow policing should be stateless to avoid problems with stateful
treatment of QUIC flows (see Section 4.2), for example blocking a treatment of QUIC flows (see Section 4.2), for example blocking a
portion of the space of values of a hash function over the addresses portion of the space of values of a hash function over the addresses
and ports in the UDP datagram. While QUIC endpoints are often able and ports in the UDP datagram. While QUIC endpoints are often able
to survive address changes, e.g. by NAT rebindings, blocking a to survive address changes, e.g. by NAT rebindings, blocking a
portion of the traffic based on 5-tuple hashing increases the risk of portion of the traffic based on 5-tuple hashing increases the risk of
black-holing an active connection when the address changes. black-holing an active connection when the address changes.
Note that some source ports are assumed to be reflection attack
vectors by some servers; see Section 8.1 of
[I-D.ietf-quic-applicability]. As a result, NAT binding to these
source ports can result in that traffic being blocked.
4.7. DDoS Detection and Mitigation 4.7. DDoS Detection and Mitigation
On-path observation of the transport headers of packets can be used On-path observation of the transport headers of packets can be used
for various security functions. For example, Denial of Service (DOS) for various security functions. For example, Denial of Service (DOS)
and Distributed DOS (DDOS) attacks against the infrastructure or and Distributed DOS (DDOS) attacks against the infrastructure or
against an endpoint can be detected and mitigated by characterising against an endpoint can be detected and mitigated by characterising
anomalous traffic. Other uses include support for security audits anomalous traffic. Other uses include support for security audits
(e.g., verifying the compliance with ciphersuites); client and (e.g., verifying the compliance with ciphersuites); client and
application fingerprinting for inventory; and to provide alerts for application fingerprinting for inventory; and to provide alerts for
network intrusion detection and other next generation firewall network intrusion detection and other next generation firewall
skipping to change at page 28, line 14 skipping to change at page 28, line 19
Version Negotiation packets do not contain any mechanism to prevent Version Negotiation packets do not contain any mechanism to prevent
version downgrade attacks. However, future versions of QUIC that use version downgrade attacks. However, future versions of QUIC that use
Version Negotiation packets are required to define a mechanism that Version Negotiation packets are required to define a mechanism that
is robust against version downgrade attacks. Therefore, a network is robust against version downgrade attacks. Therefore, a network
node should not attempt to impact version selection, as version node should not attempt to impact version selection, as version
downgrade may result in connection failure. downgrade may result in connection failure.
7. Contributors 7. Contributors
The following people have contributed text to sections of this The following people have contributed significant text to and/or
document: feedback on this document:
* Chris Box
* Dan Druta * Dan Druta
* Martin Duke * David Schinazi
* Gorry Fairhurst
* Ian Swett
* Igor Lubashev * Igor Lubashev
* David Schinazi * Jana Iyengar
* Gorry Fairhurst * Jared Mauch
* Chris Box * Lars Eggert
8. Acknowledgments * Lucas Purdue
Thanks to Thomas Fossati, Jana Iygengar, Marcus Ihlar for their early * Marcus Ilhar
reviews and feedback. Special thanks also to Martin Thomson and
Martin Duke for their detailed reviews and input. And thanks to Sean
Turner, Mike Bishop, Ian Swett, and Nick Banks for their last call
reviews.
This work is partially supported by the European Commission under * Mark Nottingham
* Martin Duke
* Martin Thomson
* Matt Joras
* Mike Bishop
* Nick Banks
* Thomas Fossati
* Sean Turner
8. Acknowledgments
This work was partially supported by the European Commission under
Horizon 2020 grant agreement no. 688421 Measurement and Architecture Horizon 2020 grant agreement no. 688421 Measurement and Architecture
for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat
for Education, Research, and Innovation under contract no. 15.0268. for Education, Research, and Innovation under contract no. 15.0268.
This support does not imply endorsement. This support does not imply endorsement.
9. References 9. References
9.1. Normative References 9.1. Normative References
[QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
skipping to change at page 29, line 28 skipping to change at page 30, line 8
August 2020, <https://www.rfc-editor.org/rfc/rfc8811>. August 2020, <https://www.rfc-editor.org/rfc/rfc8811>.
[DPLPMTUD] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. [DPLPMTUD] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
Völker, "Packetization Layer Path MTU Discovery for Völker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/rfc/rfc8899>. September 2020, <https://www.rfc-editor.org/rfc/rfc8899>.
[I-D.ietf-quic-applicability] [I-D.ietf-quic-applicability]
Kuehlewind, M. and B. Trammell, "Applicability of the QUIC Kuehlewind, M. and B. Trammell, "Applicability of the QUIC
Transport Protocol", Work in Progress, Internet-Draft, Transport Protocol", Work in Progress, Internet-Draft,
draft-ietf-quic-applicability-11, 21 April 2021, draft-ietf-quic-applicability-12, 30 June 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
applicability-11>. applicability-12>.
[I-D.ietf-tsvwg-transport-encrypt] [I-D.ietf-tsvwg-transport-encrypt]
Fairhurst, G. and C. Perkins, "Considerations around Fairhurst, G. and C. Perkins, "Considerations around
Transport Header Confidentiality, Network Operations, and Transport Header Confidentiality, Network Operations, and
the Evolution of Internet Transport Protocols", Work in the Evolution of Internet Transport Protocols", Work in
Progress, Internet-Draft, draft-ietf-tsvwg-transport- Progress, Internet-Draft, draft-ietf-tsvwg-transport-
encrypt-21, 20 April 2021, encrypt-21, 20 April 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg- <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
transport-encrypt-21>. transport-encrypt-21>.
[IPIM] Allman, M., Beverly, R., and B. Trammell, "In-Protocol [IPIM] Allman, M., Beverly, R., and B. Trammell, "In-Protocol
Internet Measurement (arXiv preprint 1612.02902)", 9 Internet Measurement (arXiv preprint 1612.02902)", 9
December 2016, <https://arxiv.org/abs/1612.02902>. December 2016, <https://arxiv.org/abs/1612.02902>.
[QUIC-APPLICABILITY] [QUIC-APPLICABILITY]
Kuehlewind, M. and B. Trammell, "Applicability of the QUIC Kuehlewind, M. and B. Trammell, "Applicability of the QUIC
Transport Protocol", Work in Progress, Internet-Draft, Transport Protocol", Work in Progress, Internet-Draft,
draft-ietf-quic-applicability-11, 21 April 2021, draft-ietf-quic-applicability-12, 30 June 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
applicability-11>. applicability-12>.
[QUIC-HTTP] [QUIC-HTTP]
Bishop, M., "Hypertext Transfer Protocol Version 3 Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-34, 2 February 2021, quic-http-34, 2 February 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
http-34>. http-34>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
skipping to change at page 30, line 28 skipping to change at page 31, line 7
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J. and I. Swett, "QUIC Loss Detection and Iyengar, J. and I. Swett, "QUIC Loss Detection and
Congestion Control", Work in Progress, Internet-Draft, Congestion Control", Work in Progress, Internet-Draft,
draft-ietf-quic-recovery-34, 14 January 2021, draft-ietf-quic-recovery-34, 14 January 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
recovery-34>. recovery-34>.
[QUIC_LB] Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC [QUIC_LB] Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC
Connection IDs", Work in Progress, Internet-Draft, draft- Connection IDs", Work in Progress, Internet-Draft, draft-
ietf-quic-load-balancers-06, 4 February 2021, ietf-quic-load-balancers-07, 9 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
load-balancers-06>. load-balancers-07>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/rfc/rfc1191>. <https://www.rfc-editor.org/rfc/rfc1191>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/rfc/rfc1812>. <https://www.rfc-editor.org/rfc/rfc1812>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
skipping to change at page 32, line 21 skipping to change at page 32, line 45
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/rfc/rfc8504>. January 2019, <https://www.rfc-editor.org/rfc/rfc8504>.
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
Völker, "Packetization Layer Path MTU Discovery for Völker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/rfc/rfc8899>. September 2020, <https://www.rfc-editor.org/rfc/rfc8899>.
[TLS-ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS [TLS-ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft, Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-11, 14 June 2021, draft-ietf-tls-esni-13, 12 August 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls- <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
esni-11>. esni-13>.
[TMA-QOF] Trammell, B., Gugelmann, D., and N. Brownlee, "Inline Data [TMA-QOF] Trammell, B., Gugelmann, D., and N. Brownlee, "Inline Data
Integrity Signals for Passive Measurement (in Proc. TMA Integrity Signals for Passive Measurement (in Proc. TMA
2014)", April 2014. 2014)", April 2014.
[WIRE-IMAGE] [WIRE-IMAGE]
Trammell, B. and M. Kuehlewind, "The Wire Image of a Trammell, B. and M. Kuehlewind, "The Wire Image of a
Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April
2019, <https://www.rfc-editor.org/rfc/rfc8546>. 2019, <https://www.rfc-editor.org/rfc/rfc8546>.
 End of changes. 28 change blocks. 
56 lines changed or deleted 80 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/