draft-ietf-tsvwg-transport-encrypt-16.txt   draft-ietf-tsvwg-transport-encrypt-17.txt 
TSVWG G. Fairhurst TSVWG G. Fairhurst
Internet-Draft University of Aberdeen Internet-Draft University of Aberdeen
Intended status: Informational C. Perkins Intended status: Informational C. Perkins
Expires: January 14, 2021 University of Glasgow Expires: March 12, 2021 University of Glasgow
July 13, 2020 September 08, 2020
Considerations around Transport Header Confidentiality, Network Considerations around Transport Header Confidentiality, Network
Operations, and the Evolution of Internet Transport Protocols Operations, and the Evolution of Internet Transport Protocols
draft-ietf-tsvwg-transport-encrypt-16 draft-ietf-tsvwg-transport-encrypt-17
Abstract Abstract
To protect user data and privacy, Internet transport protocols have To protect user data and privacy, Internet transport protocols have
supported payload encryption and authentication for some time. Such supported payload encryption and authentication for some time. Such
encryption and authentication is now also starting to be applied to encryption and authentication is now also starting to be applied to
the transport protocol headers. This helps avoid transport protocol the transport protocol headers. This helps avoid transport protocol
ossification by middleboxes, while also protecting metadata about the ossification by middleboxes, while also protecting metadata about the
communication. Current operational practice in some networks inspect communication. Current operational practice in some networks inspect
transport header information within the network, but this is no transport header information within the network, but this is no
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 January 14, 2021. This Internet-Draft will expire on March 12, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 49 skipping to change at page 2, line 49
5.2. Use of OAM across Multiple Maintenance Domains . . . . . 29 5.2. Use of OAM across Multiple Maintenance Domains . . . . . 29
6. Intentionally Exposing Transport Information to the Network . 30 6. Intentionally Exposing Transport Information to the Network . 30
6.1. Exposing Transport Information in Extension Headers . . . 30 6.1. Exposing Transport Information in Extension Headers . . . 30
6.2. Common Exposed Transport Information . . . . . . . . . . 31 6.2. Common Exposed Transport Information . . . . . . . . . . 31
6.3. Considerations for Exposing Transport Information . . . . 31 6.3. Considerations for Exposing Transport Information . . . . 31
7. Implications of Protecting the Transport Headers . . . . . . 31 7. Implications of Protecting the Transport Headers . . . . . . 31
7.1. Independent Measurement . . . . . . . . . . . . . . . . . 32 7.1. Independent Measurement . . . . . . . . . . . . . . . . . 32
7.2. Characterising "Unknown" Network Traffic . . . . . . . . 34 7.2. Characterising "Unknown" Network Traffic . . . . . . . . 34
7.3. Accountability and Internet Transport Protocols . . . . . 34 7.3. Accountability and Internet Transport Protocols . . . . . 34
7.4. Impact on Network Operations . . . . . . . . . . . . . . 35 7.4. Impact on Network Operations . . . . . . . . . . . . . . 35
7.5. Impact on Research, Development and Deployment . . . . . 35 7.5. Impact on Research, Development and Deployment . . . . . 36
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 37 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
12. Informative References . . . . . . . . . . . . . . . . . . . 42 12. Informative References . . . . . . . . . . . . . . . . . . . 42
Appendix A. Revision information . . . . . . . . . . . . . . . . 51 Appendix A. Revision information . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
skipping to change at page 6, line 47 skipping to change at page 6, line 47
When network devices rely on the presence of a header field or the When network devices rely on the presence of a header field or the
semantics of specific header information, this can lead to semantics of specific header information, this can lead to
ossification where an endpoint has to supply a specific header to ossification where an endpoint has to supply a specific header to
receive the network service that it desires. receive the network service that it desires.
In some cases, network-layer use of transport layer information can In some cases, network-layer use of transport layer information can
be benign or advantageous to the protocol (e.g., recognising the be benign or advantageous to the protocol (e.g., recognising the
start of a TCP connection, providing header compression for an SRTP start of a TCP connection, providing header compression for an SRTP
flow [RFC3711], or explicitly using exposed protocol information to flow [RFC3711], or explicitly using exposed protocol information to
provide consistent decisions by on-path devices). Header compression provide consistent decisions by on-path devices). Header compression
(e.g., [RFC5795]) depends on understanding of transport header and (e.g., [RFC5795], [RFC2508]) depends on understanding of transport
the way fields change packet-by-packet; as also do techniques to header and the way fields change packet-by-packet; as also do
improve TCP performance by transparent modification of techniques to improve TCP performance by transparent modification of
acknowledgement traffic [RFC3449]. Introducing a new transport acknowledgement traffic [RFC3449]. Introducing a new transport
protocol or changes to existing transport header information prevent protocol or changes to existing transport header information prevent
these methods being used or require the network devices to be these methods being used or require the network devices to be
updated. updated.
However, in other cases, ossification can have unwanted outcomes. However, in other cases, ossification can have unwanted outcomes.
Ossification can frustrate the evolution of a transport protocol. A Ossification can frustrate the evolution of a transport protocol. A
mechanism implemented in a network device, such as a firewall, that mechanism implemented in a network device, such as a firewall, that
requires a header field to have only a specific known set of values requires a header field to have only a specific known set of values
can prevent the device from forwarding packets using a different can prevent the device from forwarding packets using a different
skipping to change at page 25, line 48 skipping to change at page 25, line 48
information. However, the use of encryption has the desirable effect information. However, the use of encryption has the desirable effect
of preventing unintended observation of the payload data and these of preventing unintended observation of the payload data and these
tools seldom seek to observe the payload, or other application tools seldom seek to observe the payload, or other application
details. A flow that hides its transport header information could details. A flow that hides its transport header information could
imply "don't touch" to some operators. This might limit a trouble- imply "don't touch" to some operators. This might limit a trouble-
shooting response to "can't help, no trouble found". shooting response to "can't help, no trouble found".
3.5. To Support Header Compression 3.5. To Support Header Compression
Header compression saves link capacity by compressing network and Header compression saves link capacity by compressing network and
transport protocol headers on a per-hop basis. It was widely used transport protocol headers on a per-hop basis (e.g., [RFC5795]). It
with low bandwidth dial-up access links, and still finds application was widely used with low bandwidth dial-up access links, and still
on wireless links that are subject to capacity constraints. Examples finds application on wireless links that are subject to capacity
of header compression include use with TCP/IP and RTP/UDP/IP flows constraints. Examples of header compression include use with TCP/IP
[RFC2507], [RFC2508], [RFC4995]. and RTP/UDP/IP flows [RFC2507], [RFC6846], [RFC2508].
While it is possible to compress only the network layer headers, While it is possible to compress only the network layer headers,
significant savings can be made if both the network and transport significant savings can be made if both the network and transport
layer headers are compressed together as a single unit. The SRTP layer headers are compressed together as a single unit. The SRTP
extensions [RFC3711] were explicitly designed to leave the transport extensions [RFC3711] were explicitly designed to leave the transport
protocol headers unencrypted, but authenticated, since support for protocol headers unencrypted, but authenticated, since support for
header compression was considered important. Encrypting the header compression was considered important. Encrypting the
transport protocol headers does not break such header compression, transport protocol headers does not break such header compression,
but does cause a fall back to compressing only the network layer but does cause a fall back to compressing only the network layer
headers, with a significant reduction in efficiency. headers, with a significant reduction in efficiency.
skipping to change at page 31, line 19 skipping to change at page 31, line 19
There are opportunities for multiple transport protocols to There are opportunities for multiple transport protocols to
consistently supply common observable information [RFC8558]. A consistently supply common observable information [RFC8558]. A
common approach can result in an open definition of the observable common approach can result in an open definition of the observable
fields. This has the potential that the same information can be fields. This has the potential that the same information can be
utilised across a range of operational and analysis tools. utilised across a range of operational and analysis tools.
6.3. Considerations for Exposing Transport Information 6.3. Considerations for Exposing Transport Information
The motivation to reflect actual transport header information and the The motivation to reflect actual transport header information and the
implications of network devices using this information has to be implications of network devices using this information has to be
considered when proposing such a method. RFC8558 summarises this as considered when proposing such a method. RFC 8558 summarises this as
"When signals from endpoints to the path are independent from the "When signals from endpoints to the path are independent from the
signals used by endpoints to manage the flow's state mechanics, they signals used by endpoints to manage the flow's state mechanics, they
may be falsified by an endpoint without affecting the peer's may be falsified by an endpoint without affecting the peer's
understanding of the flow's state. For encrypted flows, this understanding of the flow's state. For encrypted flows, this
divergence is not detectable by on-path devices." [RFC8558]. divergence is not detectable by on-path devices." [RFC8558].
Considerations concerning the selection of appropriate information to Considerations concerning what information, if any, it is appropriate
expose include: to expose include:
o On the one hand, explicitly exposing derived fields containing o On the one hand, explicitly exposing derived fields containing
relevant transport information (e.g., metrics for loss, latency, relevant transport information (e.g., metrics for loss, latency,
etc) can avoid network devices needing to derive this information etc) can avoid network devices needing to derive this information
from other header fields. This could result in development and from other header fields. This could result in development and
evolution of transport-independent tools around a common evolution of transport-independent tools around a common
observable header, and permit transport protocols to also evolve observable header, and permit transport protocols to also evolve
independently of this ossified header [RFC8558]. independently of this ossified header [RFC8558].
o On the other hand, protocols and implementations may not o On the other hand, protocols and implementations might be designed
consistently expose external information that reflects the actual to avoid consistently exposing external information that reflects
internal information used by the protocol itself. An endpoint/ the actual internal information used by the protocol itself. An
protocol could choose to expose transport header information to endpoint/protocol could choose to expose transport header
optimise the benefit it gets from the network [RFC8558]. The information to optimise the benefit it gets from the network
value of this information would be enhanced if the exposed [RFC8558]. The value of this information would be enhanced if the
information could be verified to match the protocol's observed exposed information could be verified to match the protocol's
behavior. observed behavior.
7. Implications of Protecting the Transport Headers 7. Implications of Protecting the Transport Headers
The choice of which transport header fields to expose and which to The choice of which transport header fields to expose and which to
encrypt is a design decision for the transport protocol. Selective encrypt is a design decision for the transport protocol. Selective
encryption requires trading conflicting goals of observability and encryption requires trading conflicting goals of observability and
network support, privacy, and risk of ossification, to decide what network support, privacy, and risk of ossification, to decide what
header fields to protect and which to make visible. header fields to protect and which to make visible.
Security work typically employs a design technique that seeks to Security work typically employs a design technique that seeks to
expose only what is needed. This approach provides incentives to not expose only what is needed [RFC3552]. This approach provides
reveal any information that is not necessary for the end-to-end incentives to not reveal any information that is not necessary for
communication. However, there can be performance and operational the end-to-end communication. The IAB has provided guidelines for
benefits in exposing selected information to network tools. writing Security Considerations for IETF specifications [RFC3552].
This section explores key implications of working with encrypted Endpoint design choices impacting privacy also need to be considered
transport protocols. as a part of the design process [RFC6973]. The IAB has provided
guidance for analyzing and documenting privacy considerations within
IETF specifications [RFC6973].
There can also be performance and operational trade-offs in exposing
selected information to network tools. This section explores key
implications of working with encrypted transport protocols.
7.1. Independent Measurement 7.1. Independent Measurement
Independent observation by multiple actors is important if the Independent observation by multiple actors is important if the
transport community is to maintain an accurate understanding of the transport community is to maintain an accurate understanding of the
network. Encrypting transport header encryption changes the ability network. Encrypting transport header encryption changes the ability
to collect and independently analyse data. Internet transport to collect and independently analyse data. Internet transport
protocols employ a set of mechanisms. Some of these have to work in protocols employ a set of mechanisms. Some of these have to work in
cooperation with the network layer for loss detection and recovery, cooperation with the network layer for loss detection and recovery,
congestion detection and control. Others have to work only end-to- congestion detection and control. Others have to work only end-to-
skipping to change at page 33, line 9 skipping to change at page 33, line 14
necessary for the protocol's correct operation, therefore there is no necessary for the protocol's correct operation, therefore there is no
incentive for a TCP or RTP implementation to put incorrect incentive for a TCP or RTP implementation to put incorrect
information in this transport header. A network device can have information in this transport header. A network device can have
confidence that the well-known (and ossified) transport header confidence that the well-known (and ossified) transport header
information represents the actual state of the endpoints. information represents the actual state of the endpoints.
When encryption is used to hide some or all of the transport headers, When encryption is used to hide some or all of the transport headers,
the transport protocol chooses which information to reveal to the the transport protocol chooses which information to reveal to the
network about its internal state, what information to leave network about its internal state, what information to leave
encrypted, and what fields to grease to protect against future encrypted, and what fields to grease to protect against future
ossification. Such a transport could be designed (or an existing ossification [RFC8701]. Such a transport could be designed (or an
transport modified), for example, to provide summary data regarding existing transport modified), for example, to provide summary data
its performance, congestion control state, etc., or to make available regarding its performance, congestion control state, etc., or to make
explicit measurement information. For example, a QUIC endpoint can available explicit measurement information. For example, a QUIC
optionally set the spin bit to reflect to explicitly reveal the RTT endpoint can optionally set the spin bit to reflect to explicitly
of an encrypted transport session to the on-path network devices reveal the RTT of an encrypted transport session to the on-path
[I-D.ietf-quic-transport]). network devices [I-D.ietf-quic-transport]).
When providing or using such information, it is important to consider When providing or using such information, it is important to consider
the privacy of the user and their incentive for providing accurate the privacy of the user and their incentive for providing accurate
and detailed information. Protocols that selectively reveal some and detailed information. Protocols that selectively reveal some
transport state or measurable information are choosing to establish a transport state or measurable information are choosing to establish a
trust relationship with the network operators. There is no protocol trust relationship with the network operators. There is no protocol
mechanism that can guarantee that the information provided represents mechanism that can guarantee that the information provided represents
the actual transport state of the endpoints, since those endpoints the actual transport state of the endpoints, since those endpoints
can always send additional information in the encrypted part of the can always send additional information in the encrypted part of the
header, to update or replace whatever they reveal. This reduces the header, to update or replace whatever they reveal. This reduces the
skipping to change at page 40, line 22 skipping to change at page 40, line 27
are identified as Transport Features by [RFC8095]. As currently are identified as Transport Features by [RFC8095]. As currently
deployed in the Internet, these features are generally provided by a deployed in the Internet, these features are generally provided by a
protocol or layer on top of the transport protocol protocol or layer on top of the transport protocol
[I-D.ietf-taps-transport-security]. [I-D.ietf-taps-transport-security].
Confidentiality and strong integrity checks have properties that can Confidentiality and strong integrity checks have properties that can
also be incorporated into the design of a transport protocol or to also be incorporated into the design of a transport protocol or to
modify an existing transport. Integrity checks can protect an modify an existing transport. Integrity checks can protect an
endpoint from undetected modification of protocol fields by network endpoint from undetected modification of protocol fields by network
devices, whereas encryption and obfuscation or greasing can further devices, whereas encryption and obfuscation or greasing can further
prevent these headers being utilised by network devices. Preventing prevent these headers being utilised by network devices [RFC8701].
observation of headers provides an opportunity for greater freedom to Preventing observation of headers provides an opportunity for greater
update the protocols and can ease experimentation with new techniques freedom to update the protocols and can ease experimentation with new
and their final deployment in endpoints. A protocol specification techniques and their final deployment in endpoints. A protocol
needs to weigh the costs of ossifying common headers, versus the specification needs to weigh the costs of ossifying common headers,
potential benefits of exposing specific information that could be versus the potential benefits of exposing specific information that
observed along the network path to provide tools to manage new could be observed along the network path to provide tools to manage
variants of protocols. new variants of protocols.
Header encryption can provide confidentiality of some or all of the Header encryption can provide confidentiality of some or all of the
transport header information. This prevents an on-path device from transport header information. This prevents an on-path device from
knowledge of the header field. It therefore prevents mechanisms knowledge of the header field. It therefore prevents mechanisms
being built that directly rely on the information or seeks to infer being built that directly rely on the information or seeks to infer
semantics of an exposed header field. Reduces visibility into semantics of an exposed header field. Reduces visibility into
transport metadata can limit the ability to measure and characterise transport metadata can limit the ability to measure and characterise
traffic. It can also provide privacy benefits in some cases. traffic. It can also provide privacy benefits in some cases.
Extending the transport payload security context to also include the Extending the transport payload security context to also include the
skipping to change at page 43, line 6 skipping to change at page 43, line 6
Sciences Research Council under grant EP/R04144X/1. Sciences Research Council under grant EP/R04144X/1.
12. Informative References 12. Informative References
[bufferbloat] [bufferbloat]
Gettys, J. and K. Nichols, "Bufferbloat: dark buffers in Gettys, J. and K. Nichols, "Bufferbloat: dark buffers in
the Internet. Communications of the ACM, 55(1):57-65", the Internet. Communications of the ACM, 55(1):57-65",
January 2012. January 2012.
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in
P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, progress), July 2020.
"Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
data-06 (work in progress), July 2019.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-22 (work and Secure Transport", draft-ietf-quic-transport-29 (work
in progress), July 2019. in progress), June 2020.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-19 Browser-based Applications", draft-ietf-rtcweb-overview-19
(work in progress), November 2017. (work in progress), November 2017.
[I-D.ietf-taps-transport-security] [I-D.ietf-taps-transport-security]
Wood, C., Enghardt, T., Pauly, T., Perkins, C., and K. Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C.
Rose, "A Survey of Transport Security Protocols", draft- Wood, "A Survey of the Interaction Between Security
ietf-taps-transport-security-08 (work in progress), August Protocols and Transport Services", draft-ietf-taps-
2019. transport-security-12 (work in progress), April 2020.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-38 (work in progress), May 1.3", draft-ietf-tls-dtls13-38 (work in progress), May
2020. 2020.
[I-D.ietf-tsvwg-rtcweb-qos] [I-D.ietf-tsvwg-rtcweb-qos]
Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP
Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb-
skipping to change at page 45, line 35 skipping to change at page 45, line 35
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
Sooriyabandara, "TCP Performance Implications of Network Sooriyabandara, "TCP Performance Implications of Network
Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449,
December 2002, <https://www.rfc-editor.org/info/rfc3449>. December 2002, <https://www.rfc-editor.org/info/rfc3449>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
skipping to change at page 46, line 16 skipping to change at page 46, line 20
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006,
<https://www.rfc-editor.org/info/rfc4585>. <https://www.rfc-editor.org/info/rfc4585>.
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
S., and J. Perser, "Packet Reordering Metrics", RFC 4737, S., and J. Perser, "Packet Reordering Metrics", RFC 4737,
DOI 10.17487/RFC4737, November 2006, DOI 10.17487/RFC4737, November 2006,
<https://www.rfc-editor.org/info/rfc4737>. <https://www.rfc-editor.org/info/rfc4737>.
[RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust
Header Compression (ROHC) Framework", RFC 4995,
DOI 10.17487/RFC4995, July 2007,
<https://www.rfc-editor.org/info/rfc4995>.
[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful
Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
<https://www.rfc-editor.org/info/rfc5218>. <https://www.rfc-editor.org/info/rfc5218>.
[RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R. [RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R.
Whitner, "Improved Packet Reordering Metrics", RFC 5236, Whitner, "Improved Packet Reordering Metrics", RFC 5236,
DOI 10.17487/RFC5236, June 2008, DOI 10.17487/RFC5236, June 2008,
<https://www.rfc-editor.org/info/rfc5236>. <https://www.rfc-editor.org/info/rfc5236>.
[RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", [RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP",
skipping to change at page 47, line 28 skipping to change at page 47, line 28
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437, "IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011, DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>. <https://www.rfc-editor.org/info/rfc6437>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>. <https://www.rfc-editor.org/info/rfc6438>.
[RFC6846] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West,
"RObust Header Compression (ROHC): A Profile for TCP/IP
(ROHC-TCP)", RFC 6846, DOI 10.17487/RFC6846, January 2013,
<https://www.rfc-editor.org/info/rfc6846>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations [RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations
on Filtering of IPv4 Packets Containing IPv4 Options", on Filtering of IPv4 Packets Containing IPv4 Options",
BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014,
<https://www.rfc-editor.org/info/rfc7126>. <https://www.rfc-editor.org/info/rfc7126>.
skipping to change at page 51, line 5 skipping to change at page 50, line 38
[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals",
RFC 8558, DOI 10.17487/RFC8558, April 2019, RFC 8558, DOI 10.17487/RFC8558, April 2019,
<https://www.rfc-editor.org/info/rfc8558>. <https://www.rfc-editor.org/info/rfc8558>.
[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
Paasch, "TCP Extensions for Multipath Operation with Paasch, "TCP Extensions for Multipath Operation with
Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
2020, <https://www.rfc-editor.org/info/rfc8684>. 2020, <https://www.rfc-editor.org/info/rfc8684>.
[RFC8701] Benjamin, D., "Applying Generate Random Extensions And
Sustain Extensibility (GREASE) to TLS Extensibility",
RFC 8701, DOI 10.17487/RFC8701, January 2020,
<https://www.rfc-editor.org/info/rfc8701>.
Appendix A. Revision information Appendix A. Revision information
-00 This is an individual draft for the IETF community. -00 This is an individual draft for the IETF community.
-01 This draft was a result of walking away from the text for a few -01 This draft was a result of walking away from the text for a few
days and then reorganising the content. days and then reorganising the content.
-02 This draft fixes textual errors. -02 This draft fixes textual errors.
-03 This draft follows feedback from people reading this draft. -03 This draft follows feedback from people reading this draft.
skipping to change at page 53, line 29 skipping to change at page 53, line 29
-15 Feedback from D.L. Black, T. Herbert, J. Touch, S. Dawkins -15 Feedback from D.L. Black, T. Herbert, J. Touch, S. Dawkins
and M. Duke. Update to add reference to RFC7605. Clarify a focus and M. Duke. Update to add reference to RFC7605. Clarify a focus
on immutable transport fields, rather than modifying middleboxes with on immutable transport fields, rather than modifying middleboxes with
Tom H. Clarified Header Compression discusion only provides a list Tom H. Clarified Header Compression discusion only provides a list
of examples of HC methods for transport. Clarified port usage with of examples of HC methods for transport. Clarified port usage with
Tom H/Joe T. Removed some duplicated sentences, and minor edits. Tom H/Joe T. Removed some duplicated sentences, and minor edits.
Added NULL-ESP. Improved after initial feedback from Martin Duke. Added NULL-ESP. Improved after initial feedback from Martin Duke.
-16 Editorial comments from Mohamed Boucadair. Added DTLS 1.3. -16 Editorial comments from Mohamed Boucadair. Added DTLS 1.3.
-17 Revised to satisfy ID-NITs and updates REFs to latest rev,
updated HC REFs; cited IAB guidance on security and privacy within
IETF specs.
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
Department of Engineering Department of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen AB24 3UE Aberdeen AB24 3UE
Scotland Scotland
EMail: gorry@erg.abdn.ac.uk EMail: gorry@erg.abdn.ac.uk
 End of changes. 21 change blocks. 
61 lines changed or deleted 79 lines changed or added

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