draft-ietf-taps-transport-security-10.txt   draft-ietf-taps-transport-security-11.txt 
Network Working Group T. Enghardt Network Working Group T. Enghardt
Internet-Draft TU Berlin Internet-Draft TU Berlin
Intended status: Informational T. Pauly Intended status: Informational T. Pauly
Expires: May 21, 2020 Apple Inc. Expires: 6 September 2020 Apple Inc.
C. Perkins C. Perkins
University of Glasgow University of Glasgow
K. Rose K. Rose
Akamai Technologies, Inc. Akamai Technologies, Inc.
C. Wood, Ed. C.A. Wood, Ed.
Apple Inc. Apple Inc.
November 18, 2019 5 March 2020
A Survey of the Interaction Between Security Protocols and Transport A Survey of the Interaction Between Security Protocols and Transport
Services Services
draft-ietf-taps-transport-security-10 draft-ietf-taps-transport-security-11
Abstract Abstract
This document provides a survey of commonly used or notable network This document provides a survey of commonly used or notable network
security protocols, with a focus on how they interact and integrate security protocols, with a focus on how they interact and integrate
with applications and transport protocols. Its goal is to supplement with applications and transport protocols. Its goal is to supplement
efforts to define and catalog transport services by describing the efforts to define and catalog transport services by describing the
interfaces required to add security protocols. This survey is not interfaces required to add security protocols. This survey is not
limited to protocols developed within the scope or context of the limited to protocols developed within the scope or context of the
IETF, and those included represent a superset of features a Transport IETF, and those included represent a superset of features a Transport
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 May 21, 2020. This Internet-Draft will expire on 6 September 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Transport Security Protocol Descriptions . . . . . . . . . . 6 3. Transport Security Protocol Descriptions . . . . . . . . . . 6
3.1. Application Payload Security Protocols . . . . . . . . . 6 3.1. Application Payload Security Protocols . . . . . . . . . 6
3.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Application-Specific Security Protocols . . . . . . . . . 6 3.2. Application-Specific Security Protocols . . . . . . . . . 7
3.2.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . 6 3.2.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. ZRTP for Media Path Key Agreement . . . . . . . . . . 7
3.3. Transport-Layer Security Protocols . . . . . . . . . . . 7 3.3. Transport-Layer Security Protocols . . . . . . . . . . . 7
3.3.1. QUIC with TLS . . . . . . . . . . . . . . . . . . . . 7 3.3.1. IETF QUIC . . . . . . . . . . . . . . . . . . . . . . 8
3.3.2. Google QUIC . . . . . . . . . . . . . . . . . . . . . 7 3.3.2. Google QUIC . . . . . . . . . . . . . . . . . . . . . 8
3.3.3. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . 7 3.3.3. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . 8
3.3.4. MinimalT . . . . . . . . . . . . . . . . . . . . . . 7 3.3.4. MinimalT . . . . . . . . . . . . . . . . . . . . . . 8
3.3.5. CurveCP . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.5. CurveCP . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Packet Security Protocols . . . . . . . . . . . . . . . . 8 3.4. Packet Security Protocols . . . . . . . . . . . . . . . . 9
3.4.1. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . 8 3.4.1. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . 9
3.4.2. WireGuard . . . . . . . . . . . . . . . . . . . . . . 8 3.4.2. WireGuard . . . . . . . . . . . . . . . . . . . . . . 9
3.4.3. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . 8 3.4.3. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . 9
4. Transport Dependencies . . . . . . . . . . . . . . . . . . . 9 4. Transport Dependencies . . . . . . . . . . . . . . . . . . . 9
4.1. Reliable Byte-Stream Transports . . . . . . . . . . . . . 9 4.1. Reliable Byte-Stream Transports . . . . . . . . . . . . . 10
4.2. Unreliable Datagram Transports . . . . . . . . . . . . . 9 4.2. Unreliable Datagram Transports . . . . . . . . . . . . . 10
4.2.1. Datagram Protocols with Defined Byte-Stream Mappings 10 4.2.1. Datagram Protocols with Defined Byte-Stream
4.3. Transport-Specific Dependencies . . . . . . . . . . . . . 10 Mappings . . . . . . . . . . . . . . . . . . . . . . 11
5. Application Interface . . . . . . . . . . . . . . . . . . . . 10 4.3. Transport-Specific Dependencies . . . . . . . . . . . . . 11
5.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 11 5. Application Interface . . . . . . . . . . . . . . . . . . . . 11
5.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 13 5.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 12
5.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 13 5.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5.4. Summary of Interfaces Exposed by Protocols . . . . . . . 16
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Informative References . . . . . . . . . . . . . . . . . . . 15 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Services and features provided by transport protocols have been Services and features provided by transport protocols have been
cataloged in [RFC8095]. This document supplements that work by cataloged in [RFC8095]. This document supplements that work by
surveying commonly used and notable network security protocols, and surveying commonly used and notable network security protocols, and
identifying the services and features a Transport Services system (a identifying the interfaces between these protocols and both transport
system that provides a transport API) needs to provide in order to protocols and applications. It examines Transport Layer Security
add transport security. It examines Transport Layer Security (TLS), (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google
Datagram Transport Layer Security (DTLS), QUIC + TLS, tcpcrypt, QUIC (gQUIC), tcpcrypt, Internet Key Exchange with Encapsulating
Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard,
ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT. For each CurveCP, and MinimalT. For each protocol, this document provides a
protocol, this document provides a brief description, the brief description. Then, it describes the interfaces between these
dependencies it has on the underlying transports, and the interfaces protocols and transports in Section 4 and the interfaces between
provided to applications. these protocols and applications in Section 5.
Selected protocols represent a superset of functionality and features Selected protocols represent a superset of functionality and features
a Transport Services system may need to support, both internally and a Transport Services system may need to support, both internally and
externally (via an API) for applications [I-D.ietf-taps-arch]. externally (via an API) for applications [I-D.ietf-taps-arch].
Ubiquitous IETF protocols such as (D)TLS, as well as non-standard Ubiquitous IETF protocols such as (D)TLS, as well as non-standard
protocols such as Google QUIC, are both included despite overlapping protocols such as gQUIC, are both included despite overlapping
features. As such, this survey is not limited to protocols developed features. As such, this survey is not limited to protocols developed
within the scope or context of the IETF. Outside of this candidate within the scope or context of the IETF. Outside of this candidate
set, protocols that do not offer new features are omitted. For set, protocols that do not offer new features are omitted. For
example, newer protocols such as WireGuard make unique design choices example, newer protocols such as WireGuard make unique design choices
that have implications and limitations on application usage. In that have implications and limitations on application usage. In
contrast, protocols such as ALTS [ALTS] are omitted since they do not contrast, protocols such as ALTS [ALTS] are omitted since they do not
provide interfaces deemed unique. provide interfaces deemed unique.
Authentication-only protocols such as TCP-AO [RFC5925] and IPsec AH Authentication-only protocols such as TCP-AO [RFC5925] and IPsec AH
[RFC4302] are excluded from this survey. TCP-AO adds authenticity [RFC4302] are excluded from this survey. TCP-AO adds authenticity
skipping to change at page 4, line 50 skipping to change at page 4, line 50
between versions, security protocols have subtly different guarantees between versions, security protocols have subtly different guarantees
and vulnerabilities. Thus, any implementation needs to only use the and vulnerabilities. Thus, any implementation needs to only use the
set of protocols and algorithms that are requested by applications or set of protocols and algorithms that are requested by applications or
by a system policy. by a system policy.
2. Terminology 2. Terminology
The following terms are used throughout this document to describe the The following terms are used throughout this document to describe the
roles and interactions of transport security protocols: roles and interactions of transport security protocols:
o Transport Feature: a specific end-to-end feature that the * Transport Feature: a specific end-to-end feature that the
transport layer provides to an application. Examples include transport layer provides to an application. Examples include
confidentiality, reliable delivery, ordered delivery, message- confidentiality, reliable delivery, ordered delivery, message-
versus-stream orientation, etc. versus-stream orientation, etc.
o Transport Service: a set of Transport Features, without an * Transport Service: a set of Transport Features, without an
association to any given framing protocol, which provides association to any given framing protocol, which provides
functionality to an application. functionality to an application.
o Transport Protocol: an implementation that provides one or more * Transport Protocol: an implementation that provides one or more
different transport services using a specific framing and header different transport services using a specific framing and header
format on the wire. A Transport Protocol services an application. format on the wire. A Transport Protocol services an application.
o Application: an entity that uses a transport protocol for end-to- * Application: an entity that uses a transport protocol for end-to-
end delivery of data across the network. This may also be an end delivery of data across the network. This may also be an
upper layer protocol or tunnel encapsulation. upper layer protocol or tunnel encapsulation.
o Security Protocol: a defined network protocol that implements one * Security Protocol: a defined network protocol that implements one
or more security features, such as authentication, encryption, key or more security features, such as authentication, encryption, key
generation, session resumption, and privacy. Security protocols generation, session resumption, and privacy. Security protocols
may be used alongside transport protocols, and in combination with may be used alongside transport protocols, and in combination with
other security protocols when appropriate. other security protocols when appropriate.
o Handshake Protocol: a protocol that enables peers to validate each * Handshake Protocol: a protocol that enables peers to validate each
other and to securely establish shared cryptographic context. other and to securely establish shared cryptographic context.
o Record: Framed protocol messages. * Record: Framed protocol messages.
o Record Protocol: a security protocol that allows data to be * Record Protocol: a security protocol that allows data to be
divided into manageable blocks and protected using shared divided into manageable blocks and protected using shared
cryptographic context. cryptographic context.
o Session: an ephemeral security association between applications. * Session: an ephemeral security association between applications.
o Connection: the shared state of two or more endpoints that * Connection: the shared state of two or more endpoints that
persists across messages that are transmitted between these persists across messages that are transmitted between these
endpoints. A connection is a transient participant of a session, endpoints. A connection is a transient participant of a session,
and a session generally lasts between connection instances. and a session generally lasts between connection instances.
o Peer: an endpoint application party to a session. * Peer: an endpoint application party to a session.
o Client: the peer responsible for initiating a session. * Client: the peer responsible for initiating a session.
o Server: the peer responsible for responding to a session * Server: the peer responsible for responding to a session
initiation. initiation.
3. Transport Security Protocol Descriptions 3. Transport Security Protocol Descriptions
This section contains brief descriptions of the various security This section contains brief descriptions of the various security
protocols currently used to protect data being sent over a network. protocols currently used to protect data being sent over a network.
The interfaces between these protocols and transports are described These protocols are grouped based on where in the protocol stack they
in Section 4; the interfaces between these protocols and applications are implemented, which influences which parts of a packet they
are described in Section 5. protect: Generic application payload, application payload for
specific application-layer protocols, both application payload and
transport headers, or entire IP packets.
Note that not all security protocols can be easily categorized, e.g.,
as some protocols can be used in different ways or in combination
with other protocols. One major reason for this is that channel
security protocols often consist of two components:
* A handshake protocol, which is responsible for negotiating
parameters, authenticating the endpoints, and establishing shared
keys.
* A record protocol, which is used to encrypt traffic using keys and
parameters provided by the handshake protocol.
For some protocols, such as tcpcrypt, these two components are
tightly integrated. In contrast, for IPsec, these components are
implemented in separate protocols: AH and ESP are record protocols,
which can use keys supplied by the handshake protocol IKEv2, by other
handshake protocols, or by manual configuration. Moreover, some
protocols can be used in different ways: While the base TLS protocol
as defined in [RFC8446] has an integrated handshake and record
protocol, TLS or DTLS can also be used to negotiate keys for other
protocols, as in DTLS-SRTP, or the handshake protocol can be used
with a separate record layer, as in QUIC.
3.1. Application Payload Security Protocols 3.1. Application Payload Security Protocols
The following protocols provide security that protects application The following protocols provide security that protects application
payloads sent over a transport. They do not specifically protect any payloads sent over a transport. They do not specifically protect any
headers used for transport-layer functionality. headers used for transport-layer functionality.
3.1.1. TLS 3.1.1. TLS
TLS (Transport Layer Security) [RFC8446] is a common protocol used to TLS (Transport Layer Security) [RFC8446] is a common protocol used to
skipping to change at page 6, line 52 skipping to change at page 7, line 28
The following protocols provide application-specific security by The following protocols provide application-specific security by
protecting application payloads used for specific use-cases. Unlike protecting application payloads used for specific use-cases. Unlike
the protocols above, these are not intended for generic application the protocols above, these are not intended for generic application
use. use.
3.2.1. Secure RTP 3.2.1. Secure RTP
Secure RTP (SRTP) is a profile for RTP that provides confidentiality, Secure RTP (SRTP) is a profile for RTP that provides confidentiality,
message authentication, and replay protection for RTP data packets message authentication, and replay protection for RTP data packets
and RTP control protocol (RTCP) packets [RFC3711]. and RTP control protocol (RTCP) packets [RFC3711]. SRTP provides a
record layer only, and requires a separate handshake protocol to
provide key agreement and identity management.
3.2.2. ZRTP for Media Path Key Agreement The commonly used handshake protocol for SRTP is DTLS, in the form of
DTLS-SRTP [RFC5764]. This is an extension to DTLS that negotiates
the use of SRTP as the record layer, and describes how to export keys
for use with SRTP.
ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It ZRTP [RFC6189] is an alternative key agreement and identity
uses standard SRTP to protect RTP data packets and RTCP packets, but management protocols for SRTP. ZRTP Key agreement is performed using
provides alternative key agreement and identity management protocols. a Diffie-Hellman key exchange that runs on the media path. This
Key agreement is performed using a Diffie-Hellman key exchange that generates a shared secret that is then used to generate the master
runs on the media path. This generates a shared secret that is then key and salt for SRTP.
used to generate the master key and salt for SRTP.
3.3. Transport-Layer Security Protocols 3.3. Transport-Layer Security Protocols
The following security protocols provide protection for both The following security protocols provide protection for both
application payloads and headers that are used for transport application payloads and headers that are used for transport
services. services.
3.3.1. QUIC with TLS 3.3.1. IETF QUIC
QUIC is a new standards-track transport protocol that runs over UDP, QUIC is a new standards-track transport protocol that runs over UDP,
loosely based on Google's original proprietary gQUIC protocol loosely based on Google's original proprietary gQUIC protocol
[I-D.ietf-quic-transport] (See Section 3.3.2 for more details). The [I-D.ietf-quic-transport] (See Section 3.3.2 for more details). The
QUIC transport layer itself provides support for data confidentiality QUIC transport layer itself provides support for data confidentiality
and integrity. This requires keys to be derived with a separate and integrity. This requires keys to be derived with a separate
handshake protocol. A mapping for QUIC of TLS 1.3 handshake protocol. A mapping for QUIC of TLS 1.3
[I-D.ietf-quic-tls] has been specified to provide this handshake. [I-D.ietf-quic-tls] has been specified to provide this handshake.
3.3.2. Google QUIC 3.3.2. Google QUIC
Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol
designed and deployed by Google following experience from deploying designed and deployed by Google following experience from deploying
SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally
known as "QUIC": this document uses gQUIC to unambiguously known as "QUIC": this document uses gQUIC to unambiguously
distinguish it from the standards-track IETF QUIC. The proprietary distinguish it from the standards-track IETF QUIC. The proprietary
technical forebear of IETF QUIC, gQUIC was originally designed with technical forebear of IETF QUIC, gQUIC was originally designed with
tightly-integrated security and application data transport protocols. tightly-integrated security and application data transport protocols.
3.3.3. tcpcrypt 3.3.3. tcpcrypt
Tcpcrypt [RFC8548] is a lightweight extension to the TCP protocol for Tcpcrypt [RFC8548] is a lightweight extension to the TCP protocol for
opportunistic encryption. Applications may use tcpcrypt's unique opportunistic encryption. Applications may use tcpcrypt's unique
session ID for further application-level authentication. Absent this session ID for further application-level authentication. Absent this
skipping to change at page 8, line 10 skipping to change at page 8, line 44
MinimalT is a UDP-based transport security protocol designed to offer MinimalT is a UDP-based transport security protocol designed to offer
confidentiality, mutual authentication, DoS prevention, and confidentiality, mutual authentication, DoS prevention, and
connection mobility [MinimalT]. One major goal of the protocol is to connection mobility [MinimalT]. One major goal of the protocol is to
leverage existing protocols to obtain server-side configuration leverage existing protocols to obtain server-side configuration
information used to more quickly bootstrap a connection. MinimalT information used to more quickly bootstrap a connection. MinimalT
uses a variant of TCP's congestion control algorithm. uses a variant of TCP's congestion control algorithm.
3.3.5. CurveCP 3.3.5. CurveCP
CurveCP [CurveCP] is a UDP-based transport security protocol from CurveCP [CurveCP] is a UDP-based transport security protocol from
Daniel J. Bernstein. Unlike other security protocols, it is based Daniel J. Bernstein. Unlike many other security protocols, it is
entirely upon highly efficient public key algorithms. This removes based entirely upon public key algorithms. CurveCP provides its own
many pitfalls associated with nonce reuse and key synchronization. reliability for application data as part of its protocol.
CurveCP provides its own reliability for application data as part of
its protocol.
3.4. Packet Security Protocols 3.4. Packet Security Protocols
The following protocols provide protection for IP packets. These are The following protocols provide protection for IP packets. These are
generally used as tunnels, such as for Virtual Private Networks generally used as tunnels, such as for Virtual Private Networks
(VPNs). Often, applications will not interact directly with these (VPNs). Often, applications will not interact directly with these
protocols. However, applications that implement tunnels will protocols. However, applications that implement tunnels will
interact directly with these protocols. interact directly with these protocols.
3.4.1. IKEv2 with ESP 3.4.1. IKEv2 with ESP
skipping to change at page 8, line 39 skipping to change at page 9, line 28
(transport-mode). This suite of protocols separates out the key (transport-mode). This suite of protocols separates out the key
generation protocol (IKEv2) from the transport encryption protocol generation protocol (IKEv2) from the transport encryption protocol
(ESP). Each protocol can be used independently, but this document (ESP). Each protocol can be used independently, but this document
considers them together, since that is the most common pattern. considers them together, since that is the most common pattern.
3.4.2. WireGuard 3.4.2. WireGuard
WireGuard is an IP-layer protocol designed as an alternative to IPsec WireGuard is an IP-layer protocol designed as an alternative to IPsec
[WireGuard] for certain use cases. It uses UDP to encapsulate IP [WireGuard] for certain use cases. It uses UDP to encapsulate IP
datagrams between peers. Unlike most transport security protocols, datagrams between peers. Unlike most transport security protocols,
which rely on PKI for peer authentication, WireGuard authenticates which rely on Public Key Infrastructure (PKI) for peer
peers using pre-shared public keys delivered out-of-band, each of authentication, WireGuard authenticates peers using pre-shared public
which is bound to one or more IP addresses. Moreover, as a protocol keys delivered out-of-band, each of which is bound to one or more IP
suited for VPNs, WireGuard offers no extensibility, negotiation, or addresses. Moreover, as a protocol suited for VPNs, WireGuard offers
cryptographic agility. no extensibility, negotiation, or cryptographic agility.
3.4.3. OpenVPN 3.4.3. OpenVPN
OpenVPN [OpenVPN] is a commonly used protocol designed as an OpenVPN [OpenVPN] is a commonly used protocol designed as an
alternative to IPsec. A major goal of this protocol is to provide a alternative to IPsec. A major goal of this protocol is to provide a
VPN that is simple to configure and works over a variety of VPN that is simple to configure and works over a variety of
transports. OpenVPN encapsulates either IP packets or Ethernet transports. OpenVPN encapsulates either IP packets or Ethernet
frames within a secure tunnel and can run over UDP or TCP. frames within a secure tunnel and can run over either UDP or TCP.
For key establishment, OpenVPN can use TLS as a handshake protocol or
pre-shared keys.
4. Transport Dependencies 4. Transport Dependencies
Across the different security protocols listed above, the primary Across the different security protocols listed above, the primary
dependency on transport protocols is the presentation of data: either dependency on transport protocols is the presentation of data: either
an unbounded stream of bytes, or framed messages. Within protocols an unbounded stream of bytes, or framed messages. Within protocols
that rely on the transport for message framing, most are built to run that rely on the transport for message framing, most are built to run
over transports that inherently provide framing, like UDP, but some over transports that inherently provide framing, like UDP, but some
also define how their messages can be framed over byte-stream also define how their messages can be framed over byte-stream
transports. transports.
4.1. Reliable Byte-Stream Transports 4.1. Reliable Byte-Stream Transports
The following protocols all depend upon running on a transport The following protocols all depend upon running on a transport
protocol that provides a reliable, in-order stream of bytes. This is protocol that provides a reliable, in-order stream of bytes. This is
typically TCP. typically TCP.
Application Payload Security Protocols: Application Payload Security Protocols:
o TLS * TLS
Transport-Layer Security Protocols: Transport-Layer Security Protocols:
o tcpcrypt * tcpcrypt
Packet Security Protocols:
o OpenVPN
4.2. Unreliable Datagram Transports 4.2. Unreliable Datagram Transports
The following protocols all depend on the transport protocol to The following protocols all depend on the transport protocol to
provide message framing to encapsulate their data. These protocols provide message framing to encapsulate their data. These protocols
are built to run using UDP, and thus do not have any requirement for are built to run using UDP, and thus do not have any requirement for
reliability. Running these protocols over a protocol that does reliability. Running these protocols over a protocol that does
provide reliability will not break functionality, but may lead to provide reliability will not break functionality, but may lead to
multiple layers of reliability if the security protocol is multiple layers of reliability if the security protocol is
encapsulating other transport protocol traffic. encapsulating other transport protocol traffic.
Application Payload Security Protocols: Application Payload Security Protocols:
o DTLS * DTLS
o SRTP * ZRTP
o ZRTP * SRTP
Transport-Layer Security Protocols: Transport-Layer Security Protocols:
o QUIC * QUIC
o MinimalT * MinimalT
o CurveCP * CurveCP
Packet Security Protocols: Packet Security Protocols:
o IKEv2 and ESP * IKEv2 and ESP
o WireGuard * WireGuard
* OpenVPN
4.2.1. Datagram Protocols with Defined Byte-Stream Mappings 4.2.1. Datagram Protocols with Defined Byte-Stream Mappings
Of the protocols listed above that depend on the transport for Of the protocols listed above that depend on the transport for
message framing, some do have well-defined mappings for sending their message framing, some do have well-defined mappings for sending their
messages over byte-stream transports like TCP. messages over byte-stream transports like TCP.
Application Payload Security Protocols: Application Payload Security Protocols:
o SRTP [RFC7201] * DTLS when used as a handshake protocol for SRTP [RFC7850]
* ZRTP [RFC4571]
* SRTP [RFC4571]
Packet Security Protocols: Packet Security Protocols:
o IKEv2 and ESP [RFC8229] * IKEv2 and ESP [RFC8229]
4.3. Transport-Specific Dependencies 4.3. Transport-Specific Dependencies
One protocol surveyed, tcpcrypt, has an direct dependency on a One protocol surveyed, tcpcrypt, has an direct dependency on a
feature in the transport that is needed for its functionality. feature in the transport that is needed for its functionality.
Specific, tcpcrypt is designed to run on top of TCP, and uses the TCP Specific, tcpcrypt is designed to run on top of TCP, and uses the TCP
Encryption Negotiation Option (ENO) [RFC8547] to negotiate its Encryption Negotiation Option (ENO) [RFC8547] to negotiate its
protocol support. protocol support.
QUIC, CurveCP, and MinimalT provide both transport functionality and QUIC, CurveCP, and MinimalT provide both transport functionality and
security functionality. They have a dependencies on running over a security functionality. They have a dependencies on running over a
framed protocol like UDP, but they add their own layers of framed protocol like UDP, but they add their own layers of
reliability and other transport services. Thus, an application that reliability and other transport services. Thus, an application that
uses one of these protocols cannot decouple the security from uses one of these protocols cannot decouple the security from
transport functionality. transport functionality.
5. Application Interface 5. Application Interface
This section describes the interface surface exposed by the security This section describes the interface surface exposed by the security
protocols described above. Note that not all protocols support each protocols described above. We partition these interfaces into pre-
interface. We partition these interfaces into pre-connection connection (configuration), connection, and post-connection
(configuration), connection, and post-connection interfaces, interfaces, following conventions in [I-D.ietf-taps-interface] and
following conventions in [I-D.ietf-taps-interface] and
[I-D.ietf-taps-arch]. [I-D.ietf-taps-arch].
Note that not all protocols support each interface. The table in
Section 5.4 summarizes which protocol exposes which of the
interfaces. In the following sections, we provide abbreviations of
the interface names to use in the summary table.
5.1. Pre-Connection Interfaces 5.1. Pre-Connection Interfaces
Configuration interfaces are used to configure the security protocols Configuration interfaces are used to configure the security protocols
before a handshake begins or the keys are negotiated. before a handshake begins or the keys are negotiated.
o Identities and Private Keys: The application can provide its * Identities and Private Keys (IPK): The application can provide its
identities (certificates) and private keys, or mechanisms to identities (certificates) and private keys, or mechanisms to
access these, to the security protocol to use during handshakes. access these, to the security protocol to use during handshakes.
* TLS - TLS
* DTLS - DTLS
* SRTP - ZRTP
* QUIC - QUIC
* MinimalT - MinimalT
* CurveCP - CurveCP
* IKEv2 - IKEv2
* WireGuard - WireGuard
o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites): - OpenVPN
The application can choose the algorithms that are supported for
key exchange, signatures, and ciphersuites.
* TLS * Supported Algorithms (Key Exchange, Signatures, and Ciphersuites)
(ALG): The application can choose the algorithms that are
supported for key exchange, signatures, and ciphersuites.
* DTLS - TLS
* SRTP - DTLS
* QUIC - ZRTP
* tcpcrypt - QUIC
* MinimalT - tcpcrypt
* IKEv2 - MinimalT
o Extensions (Application-Layer Protocol Negotiation): The - IKEv2
- OpenVPN
* Extensions (Application-Layer Protocol Negotiation) (EXT): The
application enables or configures extensions that are to be application enables or configures extensions that are to be
negotiated by the security protocol, such as ALPN [RFC7301]. negotiated by the security protocol, such as ALPN [RFC7301].
* TLS - TLS
* DTLS - DTLS
* QUIC - QUIC
o Session Cache Management: The application provides the ability to * Session Cache Management (CM): The application provides the
save and retrieve session state (such as tickets, keying material, ability to save and retrieve session state (such as tickets,
and server parameters) that may be used to resume the security keying material, and server parameters) that may be used to resume
session. the security session.
* TLS - TLS
* DTLS - DTLS
* QUIC - ZRTP
* MinimalT - QUIC
o Authentication Delegation: The application provides access to a - tcpcrypt
separate module that will provide authentication, using EAP for
- MinimalT
* Authentication Delegation (AD): The application provides access to
a separate module that will provide authentication, using EAP for
example. example.
* SRTP - IKEv2
* IKEv2 - tcpcrypt
o Pre-Shared Key Import: Either the handshake protocol or the * Pre-Shared Key Import (PSKI): Either the handshake protocol or the
application directly can supply pre-shared keys for the record application directly can supply pre-shared keys for use in
protocol use for encryption/decryption and authentication. If the encrypting (and authenticating) communication with a peer.
application can supply keys directly, this is considered explicit
import; if the handshake protocol traditionally provides the keys
directly, it is considered direct import; if the keys can only be
shared by the handshake, they are considered non-importable.
* Explicit import: QUIC, ESP - TLS
* Direct import: TLS, DTLS, tcpcrypt, MinimalT, WireGuard - DTLS
* Non-importable: CurveCP - ZRTP
- QUIC
- ESP
- IKEv2
- OpenVPN
- tcpcrypt
- MinimalT
- WireGuard
5.2. Connection Interfaces 5.2. Connection Interfaces
o Identity Validation: During a handshake, the security protocol * Identity Validation (IV): During a handshake, the security
will conduct identity validation of the peer. This can call into protocol will conduct identity validation of the peer. This can
the application to offload validation. call into the application to offload validation.
* TLS - TLS
* DTLS - DTLS
* SRTP - ZRTP
* QUIC - QUIC
* MinimalT - MinimalT
* CurveCP - CurveCP
* IKEv2 - IKEv2
* WireGuard - WireGuard
* OpenVPN - OpenVPN
o Source Address Validation: The handshake protocol may delegate * Source Address Validation (SAV): The handshake protocol may
validation of the remote peer that has sent data to the transport delegate validation of the remote peer that has sent data to the
protocol or application. This involves sending a cookie exchange transport protocol or application. This involves sending a cookie
to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard exchange to avoid DoS attacks.
* DTLS - DTLS
* QUIC - QUIC
* WireGuard - IKEv2
- WireGuard
5.3. Post-Connection Interfaces 5.3. Post-Connection Interfaces
o Connection Termination: The security protocol may be instructed to * Connection Termination (CT): The security protocol may be
tear down its connection and session information. This is needed instructed to tear down its connection and session information.
by some protocols to prevent application data truncation attacks. This is needed by some protocols, e.g., to prevent application
data truncation attacks in which an attacker terminates an
underlying insecure connection-oriented protocol to terminate the
session.
* TLS - TLS
* DTLS - DTLS
* QUIC - ZRTP
* tcpcrypt - QUIC
* MinimalT
* IKEv2 - tcpcrypt
o Key Update: The handshake protocol may be instructed to update its - MinimalT
keying material, either by the application directly or by the
record protocol sending a key expiration event.
* TLS - IKEv2
* DTLS - OpenVPN
* QUIC * Key Update (KU): The handshake protocol may be instructed to
update its keying material, either by the application directly or
by the record protocol sending a key expiration event.
* tcpcrypt - TLS
* MinimalT - DTLS
* IKEv2 - QUIC
o Pre-Shared Key Export: The handshake protocol will generate one or - tcpcrypt
more keys to be used for record encryption/decryption and
authentication. These may be explicitly exportable to the
application, traditionally limited to direct export to the record
protocol, or inherently non-exportable because the keys must be
used directly in conjunction with the record protocol.
* Explicit export: TLS (for QUIC), DTLS (for SRTP), tcpcrypt, - MinimalT
IKEv2
* Direct export: TLS, DTLS, MinimalT - IKEv2
* Non-exportable: CurveCP * Shared Secret Export (PSKE): The handshake protocol may provide an
interface for producing shared secrets for application-specific
uses.
o Key Expiration: The record protocol can signal that its keys are - TLS
expiring due to reaching a time-based deadline, or a use-based
- DTLS
- tcpcrypt
- IKEv2
- OpenVPN
- MinimalT
* Key Expiration (KE): The record protocol can signal that its keys
are expiring due to reaching a time-based deadline, or a use-based
deadline (number of bytes that have been encrypted with the key). deadline (number of bytes that have been encrypted with the key).
This interaction is often limited to signaling between the record This interaction is often limited to signaling between the record
layer and the handshake layer. layer and the handshake layer.
* ESP - ESP
o Mobility Events: The record protocol can be signaled that it is * Mobility Events (ME): The record protocol can be signaled that it
being migrated to another transport or interface due to connection is being migrated to another transport or interface due to
mobility, which may reset address and state validation and induce connection mobility, which may reset address and state validation
state changes such as use of a new Connection Identifier (CID). and induce state changes such as use of a new Connection
Identifier (CID).
* QUIC - QUIC
* MinimalT
* CurveCP - MinimalT
* ESP - CurveCP
* WireGuard - IKEv2 [RFC4555]
- WireGuard
5.4. Summary of Interfaces Exposed by Protocols
The following table summarizes which protocol exposes which
interface.
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| Protocol |IPK|ALG | EXT |CM|AD| PSKI |IV| SAV |CT|KU| PSKE |KE|ME|
+===========+===+====+=====+==+==+======+==+=====+==+==+======+==+==+
| TLS | x | x | x |x | | x |x | |x |x | x | | |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| DTLS | x | x | x |x | | x |x | x |x |x | x | | |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| ZRTP | x | x | |x | | x |x | |x | | | | |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| QUIC | x | x | x |x | | x |x | x |x |x | | |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| tcpcrypt | | x | |x |x | x | | |x |x | x | | |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| MinimalT | x | x | |x | | x |x | |x |x | x | |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| CurveCP | x | | | | | |x | | | | | |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| IKEv2 | x | x | | |x | x |x | x |x |x | x | |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| ESP | | | | | | x | | | | | |x | |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| WireGuard | x | | | | | x |x | x | | | | |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| OpenVPN | x | x | | | | x |x | |x | | x | | |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
Table 1
x=Interface is exposed (blank)=Interface is not exposed
6. IANA Considerations 6. IANA Considerations
This document has no request to IANA. This document has no request to IANA.
7. Security Considerations 7. Security Considerations
This document summarizes existing transport security protocols and This document summarizes existing transport security protocols and
their interfaces. It does not propose changes to or recommend usage their interfaces. It does not propose changes to or recommend usage
of reference protocols. Moreover, no claims of security and privacy of reference protocols. Moreover, no claims of security and privacy
skipping to change at page 16, line 5 skipping to change at page 18, line 29
Kuehlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for Kuehlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for
their input and feedback on this draft. their input and feedback on this draft.
10. Informative References 10. Informative References
[ALTS] Ghali, C., Stubblefield, A., Knapp, E., Li, J., Schmidt, [ALTS] Ghali, C., Stubblefield, A., Knapp, E., Li, J., Schmidt,
B., and J. Boeuf, "Application Layer Transport Security", B., and J. Boeuf, "Application Layer Transport Security",
<https://cloud.google.com/security/encryption-in-transit/ <https://cloud.google.com/security/encryption-in-transit/
application-layer-transport-security/>. application-layer-transport-security/>.
[CurveCP] Bernstein, D., "CurveCP -- Usable security for the [CurveCP] Bernstein, D.J., "CurveCP -- Usable security for the
Internet", <http://curvecp.org>. Internet", <http://curvecp.org>.
[I-D.ietf-quic-tls] [I-D.ietf-quic-tls]
Thomson, M. and S. Turner, "Using TLS to Secure QUIC", Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
draft-ietf-quic-tls-23 (work in progress), September 2019. Work in Progress, Internet-Draft, draft-ietf-quic-tls-27,
21 February 2020, <http://www.ietf.org/internet-drafts/
draft-ietf-quic-tls-27.txt>.
[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-23 (work and Secure Transport", Work in Progress, Internet-Draft,
in progress), September 2019. draft-ietf-quic-transport-27, 21 February 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic-
transport-27.txt>.
[I-D.ietf-taps-arch] [I-D.ietf-taps-arch]
Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,
Perkins, C., Tiesel, P., and C. Wood, "An Architecture for Perkins, C., Tiesel, P., and C. Wood, "An Architecture for
Transport Services", draft-ietf-taps-arch-04 (work in Transport Services", Work in Progress, Internet-Draft,
progress), July 2019. draft-ietf-taps-arch-06, 23 December 2019,
<http://www.ietf.org/internet-drafts/draft-ietf-taps-arch-
06.txt>.
[I-D.ietf-taps-interface] [I-D.ietf-taps-interface]
Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,
Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T.
Pauly, "An Abstract Application Layer Interface to Pauly, "An Abstract Application Layer Interface to
Transport Services", draft-ietf-taps-interface-04 (work in Transport Services", Work in Progress, Internet-Draft,
progress), July 2019. draft-ietf-taps-interface-05, 4 November 2019,
<http://www.ietf.org/internet-drafts/draft-ietf-taps-
interface-05.txt>.
[MinimalT] [MinimalT] Petullo, W.M., Zhang, X., Solworth, J.A., Bernstein, D.J.,
Petullo, W., Zhang, X., Solworth, J., Bernstein, D., and and T. Lange, "MinimaLT -- Minimal-latency Networking
T. Lange, "MinimaLT -- Minimal-latency Networking Through Through Better Security",
Better Security",
<http://dl.acm.org/citation.cfm?id=2516737>. <http://dl.acm.org/citation.cfm?id=2516737>.
[OpenVPN] "OpenVPN cryptographic layer", <https://openvpn.net/ [OpenVPN] "OpenVPN cryptographic layer", <https://openvpn.net/
community-resources/openvpn-cryptographic-layer/>. community-resources/openvpn-cryptographic-layer/>.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, DOI 10.17487/RFC2385, August Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
1998, <https://www.rfc-editor.org/info/rfc2385>. 1998, <https://www.rfc-editor.org/info/rfc2385>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
skipping to change at page 17, line 9 skipping to change at page 19, line 39
<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)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
<https://www.rfc-editor.org/info/rfc4555>.
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
and RTP Control Protocol (RTCP) Packets over Connection-
Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July
2006, <https://www.rfc-editor.org/info/rfc4571>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010,
<https://www.rfc-editor.org/info/rfc5764>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>. June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
Media Path Key Agreement for Unicast Secure RTP", Media Path Key Agreement for Unicast Secure RTP",
RFC 6189, DOI 10.17487/RFC6189, April 2011, RFC 6189, DOI 10.17487/RFC6189, April 2011,
<https://www.rfc-editor.org/info/rfc6189>. <https://www.rfc-editor.org/info/rfc6189>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<https://www.rfc-editor.org/info/rfc7201>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7850] Nandakumar, S., "Registering Values of the SDP 'proto'
Field for Transporting RTP Media over TCP under Various
RTP Profiles", RFC 7850, DOI 10.17487/RFC7850, April 2016,
<https://www.rfc-editor.org/info/rfc7850>.
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
Ed., "Services Provided by IETF Transport Protocols and Ed., "Services Provided by IETF Transport Protocols and
Congestion Control Mechanisms", RFC 8095, Congestion Control Mechanisms", RFC 8095,
DOI 10.17487/RFC8095, March 2017, DOI 10.17487/RFC8095, March 2017,
<https://www.rfc-editor.org/info/rfc8095>. <https://www.rfc-editor.org/info/rfc8095>.
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
August 2017, <https://www.rfc-editor.org/info/rfc8229>. August 2017, <https://www.rfc-editor.org/info/rfc8229>.
skipping to change at page 18, line 20 skipping to change at page 21, line 16
Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547, Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547,
DOI 10.17487/RFC8547, May 2019, DOI 10.17487/RFC8547, May 2019,
<https://www.rfc-editor.org/info/rfc8547>. <https://www.rfc-editor.org/info/rfc8547>.
[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, [RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
Q., and E. Smith, "Cryptographic Protection of TCP Streams Q., and E. Smith, "Cryptographic Protection of TCP Streams
(tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019,
<https://www.rfc-editor.org/info/rfc8548>. <https://www.rfc-editor.org/info/rfc8548>.
[WireGuard] [WireGuard]
Donenfeld, J., "WireGuard -- Next Generation Kernel Donenfeld, J.A., "WireGuard -- Next Generation Kernel
Network Tunnel", Network Tunnel",
<https://www.wireguard.com/papers/wireguard.pdf>. <https://www.wireguard.com/papers/wireguard.pdf>.
Authors' Addresses Authors' Addresses
Theresa Enghardt Theresa Enghardt
TU Berlin TU Berlin
Marchstr. 23 Marchstr. 23
10587 Berlin 10587 Berlin
Germany Germany
Email: theresa@inet.tu-berlin.de Email: ietf@tenghardt.net
Tommy Pauly Tommy Pauly
Apple Inc. Apple Inc.
One Apple Park Way One Apple Park Way
Cupertino, California 95014 Cupertino, California 95014,
United States of America United States of America
Email: tpauly@apple.com Email: tpauly@apple.com
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
skipping to change at page 19, line 4 skipping to change at page 21, line 45
Email: tpauly@apple.com Email: tpauly@apple.com
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
Kyle Rose Kyle Rose
Akamai Technologies, Inc. Akamai Technologies, Inc.
150 Broadway 150 Broadway
Cambridge, MA 02144 Cambridge, MA 02144,
United States of America United States of America
Email: krose@krose.org Email: krose@krose.org
Christopher A. Wood (editor) Christopher A. Wood (editor)
Apple Inc. Apple Inc.
One Apple Park Way One Apple Park Way
Cupertino, California 95014 Cupertino, California 95014,
United States of America United States of America
Email: cawood@apple.com Email: cawood@apple.com
 End of changes. 136 change blocks. 
232 lines changed or deleted 356 lines changed or added

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