draft-ietf-taps-transport-security-11.txt   draft-ietf-taps-transport-security-12.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: 6 September 2020 Apple Inc. Expires: 25 October 2020 Apple Inc.
C. Perkins C. Perkins
University of Glasgow University of Glasgow
K. Rose K. Rose
Akamai Technologies, Inc. Akamai Technologies, Inc.
C.A. Wood, Ed. C.A. Wood
Apple Inc. Cloudflare
5 March 2020 23 April 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-11 draft-ietf-taps-transport-security-12
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 6 September 2020. This Internet-Draft will expire on 25 October 2020.
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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . 7
3.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Application-Specific Security Protocols . . . . . . . . . 7 3.2. Application-Specific Security Protocols . . . . . . . . . 8
3.2.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . 8
3.3. Transport-Layer Security Protocols . . . . . . . . . . . 7 3.3. Transport-Layer Security Protocols . . . . . . . . . . . 8
3.3.1. IETF QUIC . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. IETF QUIC . . . . . . . . . . . . . . . . . . . . . . 8
3.3.2. Google QUIC . . . . . . . . . . . . . . . . . . . . . 8 3.3.2. Google QUIC . . . . . . . . . . . . . . . . . . . . . 9
3.3.3. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . 8 3.3.3. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . 9
3.3.4. MinimalT . . . . . . . . . . . . . . . . . . . . . . 8 3.3.4. MinimaLT . . . . . . . . . . . . . . . . . . . . . . 9
3.3.5. CurveCP . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.5. CurveCP . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Packet Security Protocols . . . . . . . . . . . . . . . . 9 3.4. Packet Security Protocols . . . . . . . . . . . . . . . . 9
3.4.1. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . 9 3.4.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.2. WireGuard . . . . . . . . . . . . . . . . . . . . . . 9 3.4.2. WireGuard . . . . . . . . . . . . . . . . . . . . . . 10
3.4.3. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . 9 3.4.3. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . 10
4. Transport Dependencies . . . . . . . . . . . . . . . . . . . 9 4. Transport Dependencies . . . . . . . . . . . . . . . . . . . 10
4.1. Reliable Byte-Stream Transports . . . . . . . . . . . . . 10 4.1. Reliable Byte-Stream Transports . . . . . . . . . . . . . 10
4.2. Unreliable Datagram Transports . . . . . . . . . . . . . 10 4.2. Unreliable Datagram Transports . . . . . . . . . . . . . 11
4.2.1. Datagram Protocols with Defined Byte-Stream 4.2.1. Datagram Protocols with Defined Byte-Stream
Mappings . . . . . . . . . . . . . . . . . . . . . . 11 Mappings . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Transport-Specific Dependencies . . . . . . . . . . . . . 11 4.3. Transport-Specific Dependencies . . . . . . . . . . . . . 12
5. Application Interface . . . . . . . . . . . . . . . . . . . . 11 5. Application Interface . . . . . . . . . . . . . . . . . . . . 12
5.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 12 5.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 12
5.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 14 5.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 15
5.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 15 5.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 16
5.4. Summary of Interfaces Exposed by Protocols . . . . . . . 16 5.4. Summary of Interfaces Exposed by Protocols . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. Informative References . . . . . . . . . . . . . . . . . . . 18 10. Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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 interfaces between these protocols and both transport identifying the interfaces between these protocols and both transport
protocols and applications. It examines Transport Layer Security protocols and applications. It examines Transport Layer Security
(TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google
QUIC (gQUIC), tcpcrypt, Internet Key Exchange with Encapsulating QUIC (gQUIC), tcpcrypt, Internet Protocol Security (IPsec), Secure
Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, Real-time Transport Protocol (SRTP) with DTLS, WireGuard, CurveCP,
CurveCP, and MinimalT. For each protocol, this document provides a and MinimaLT. For each protocol, this document provides a brief
brief description. Then, it describes the interfaces between these description. Then, it describes the interfaces between these
protocols and transports in Section 4 and the interfaces between protocols and transports in Section 4 and the interfaces between
these protocols and applications in Section 5. these protocols and applications in Section 5.
Selected protocols represent a superset of functionality and features A Transport Services system exposes an interface for applications to
a Transport Services system may need to support, both internally and access various (secure) transport protocol features. The security
externally (via an API) for applications [I-D.ietf-taps-arch]. protocols included in this survey represent a superset of
Ubiquitous IETF protocols such as (D)TLS, as well as non-standard functionality and features a Transport Services system may need to
protocols such as gQUIC, are both included despite overlapping support, both internally and externally (via an API) for applications
features. As such, this survey is not limited to protocols developed [I-D.ietf-taps-arch]. Ubiquitous IETF protocols such as (D)TLS, as
within the scope or context of the IETF. Outside of this candidate well as non-standard protocols such as gQUIC, are included despite
set, protocols that do not offer new features are omitted. For overlapping features. As such, this survey is not limited to
example, newer protocols such as WireGuard make unique design choices protocols developed within the scope or context of the IETF. Outside
that have implications and limitations on application usage. In of this candidate set, protocols that do not offer new features are
contrast, protocols such as ALTS [ALTS] are omitted since they do not omitted. For example, newer protocols such as WireGuard make unique
provide interfaces deemed unique. design choices that have implications for and limitations on
application usage. In contrast, protocols such as SSH [RFC4253], GRE
[RFC2890], L2TP [RFC5641], and ALTS [ALTS] are omitted since they do
not 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
[RFC4302] are excluded from this survey. TCP-AO adds authenticity Authentication Header (AH) [RFC4302] are excluded from this survey.
protections to long-lived TCP connections, e.g., replay protection TCP-AO adds authentication to long-lived TCP connections, e.g.,
with per-packet Message Authentication Codes. (This protocol replay protection with per-packet Message Authentication Codes.
obsoletes TCP MD5 "signature" options specified in [RFC2385].) One (TCP-AO obsoletes TCP MD5 "signature" options specified in
prime use case of TCP-AO is for protecting BGP connections. [RFC2385].) One primary use case of TCP-AO is for protecting BGP
Similarly, AH adds per-datagram authenticity and adds similar replay connections. Similarly, AH adds per-datagram authentication and
protection. Despite these improvements, neither protocol sees integrity, along with replay protection. Despite these improvements,
general use and both lack critical properties important for emergent neither protocol sees general use and both lack critical properties
transport security protocols: confidentiality, privacy protections, important for emergent transport security protocols, such as
and agility. Such protocols are thus omitted from this survey. confidentiality and privacy protections. Such protocols are thus
omitted from this survey.
This document only surveys point-to-point protocols; multicast
protocols are out of scope.
1.1. Goals 1.1. Goals
This survey is intended to help identify the most common interface This survey is intended to help identify the most common interface
surfaces between security protocols and transport protocols, and surfaces between security protocols and transport protocols, and
between security protocols and applications. between security protocols and applications.
One of the goals of Transport Services is to define a common One of the goals of the Transport Services effort is to define a
interface for using transport protocols that allows software using common interface for using transport protocols that allows software
transport protocols to easily adopt new protocols that provide using transport protocols to easily adopt new protocols that provide
similar feature-sets. The survey of the dependencies security similar feature-sets. The survey of the dependencies security
protocols have upon transport protocols can guide implementations in protocols have upon transport protocols can guide implementations in
determining which transport protocols are appropriate to be able to determining which transport protocols are appropriate to be able to
use beneath a given security protocol. For example, a security use beneath a given security protocol. For example, a security
protocol that expects to run over a reliable stream of bytes, like protocol that expects to run over a reliable stream of bytes, like
TLS, restrict the set of transport protocols that can be used to TLS, restricts the set of transport protocols that can be used to
those that offer a reliable stream of bytes. those that offer a reliable stream of bytes.
Defining the common interfaces that security protocols provide to Defining the common interfaces that security protocols provide to
applications also allows interfaces to be designed in a way that applications also allows interfaces to be designed in a way that
common functionality can use the same APIs. For example, many common functionality can use the same APIs. For example, many
security protocols that provide authentication let the application be security protocols that provide authentication let the application be
involved in peer identity validation. Any interface to use a secure involved in peer identity validation. Any interface to use a secure
transport protocol stack thus needs to allow applications to perform transport protocol stack thus needs to allow applications to perform
this action during connection establishment. this action during connection establishment.
skipping to change at page 4, line 45 skipping to change at page 5, line 13
consideration. consideration.
It is not a goal to allow software implementations to automatically It is not a goal to allow software implementations to automatically
switch between different security protocols, even where their switch between different security protocols, even where their
interfaces to transport and applications are equivalent. Even interfaces to transport and applications are equivalent. Even
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.
Different security protocols also can use incompatible notions of
peer identity and authentication, and cryptographic options. It is
not a goal to identify a common set of representations for these
concepts.
The protocols surveyed in this document represent a superset of
functionality and features a Transport Services system may need to
support. It does not list all transport protocols that a Transport
Services system may need to implement, nor does it mandate that a
Transport Service system implement any particular protocol.
A Transport Services system may implement any secure transport
protocol that provides the described features. In doing so, it may
need to expose an interface to the application to configure these
features.
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 (some of which
are also defined in [RFC8095]):
* 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, and message-
versus-stream orientation, etc. versus-stream orientation.
* 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.
* Transport Services system: a software component that exposes an
interface to different Transport Services to an application.
* 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,
whether directly or in conjunction with a security protocol.
* 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.
* 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.
skipping to change at page 6, line 7 skipping to change at page 6, line 40
* Peer: an endpoint application party to a session. * Peer: an endpoint application party to a session.
* Client: the peer responsible for initiating a session. * Client: the peer responsible for initiating a session.
* 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 transport and security descriptions of
protocols currently used to protect data being sent over a network. various security protocols currently used to protect data being sent
These protocols are grouped based on where in the protocol stack they over a network. These protocols are grouped based on where in the
are implemented, which influences which parts of a packet they protocol stack they are implemented, which influences which parts of
protect: Generic application payload, application payload for a packet they protect: Generic application payload, application
specific application-layer protocols, both application payload and payload for specific application-layer protocols, both application
transport headers, or entire IP packets. payload and transport headers, or entire IP packets.
Note that not all security protocols can be easily categorized, e.g., Note that not all security protocols can be easily categorized, e.g.,
as some protocols can be used in different ways or in combination as some protocols can be used in different ways or in combination
with other protocols. One major reason for this is that channel with other protocols. One major reason for this is that channel
security protocols often consist of two components: security protocols often consist of two components:
* A handshake protocol, which is responsible for negotiating * A handshake protocol, which is responsible for negotiating
parameters, authenticating the endpoints, and establishing shared parameters, authenticating the endpoints, and establishing shared
keys. keys.
skipping to change at page 6, line 36 skipping to change at page 7, line 21
For some protocols, such as tcpcrypt, these two components are For some protocols, such as tcpcrypt, these two components are
tightly integrated. In contrast, for IPsec, these components are tightly integrated. In contrast, for IPsec, these components are
implemented in separate protocols: AH and ESP are record protocols, implemented in separate protocols: AH and ESP are record protocols,
which can use keys supplied by the handshake protocol IKEv2, by other which can use keys supplied by the handshake protocol IKEv2, by other
handshake protocols, or by manual configuration. Moreover, some handshake protocols, or by manual configuration. Moreover, some
protocols can be used in different ways: While the base TLS protocol protocols can be used in different ways: While the base TLS protocol
as defined in [RFC8446] has an integrated handshake and record as defined in [RFC8446] has an integrated handshake and record
protocol, TLS or DTLS can also be used to negotiate keys for other 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 protocols, as in DTLS-SRTP, or the handshake protocol can be used
with a separate record layer, as in QUIC. with a separate record layer, as in QUIC [I-D.ietf-quic-transport].
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
establish a secure session between two endpoints. Communication over establish a secure session between two endpoints. Communication over
this session "prevents eavesdropping, tampering, and message this session "prevents eavesdropping, tampering, and message
forgery." TLS consists of a tightly coupled handshake and record forgery." TLS consists of a tightly coupled handshake and record
protocol. The handshake protocol is used to authenticate peers, protocol. The handshake protocol is used to authenticate peers,
negotiate protocol options, such as cryptographic algorithms, and negotiate protocol options, such as cryptographic algorithms, and
derive session-specific keying material. The record protocol is used derive session-specific keying material. The record protocol is used
to marshal (possibly encrypted) data from one peer to the other. to marshal and, once the handshake has sufficiently progressed,
This data may contain handshake messages or raw application data. encrypt, data from one peer to the other. This data may contain
handshake messages or raw application data.
3.1.2. DTLS 3.1.2. DTLS
DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS, DTLS (Datagram Transport Layer Security) [RFC6347]
but differs in that it is designed to run over unreliable datagram [I-D.ietf-tls-dtls13] is based on TLS, but differs in that it is
protocols like UDP instead of TCP. DTLS modifies the protocol to designed to run over unreliable datagram protocols like UDP instead
make sure it can still provide the same security guarantees as TLS of TCP. DTLS modifies the protocol to make sure it can still provide
even without reliability from the transport. DTLS was designed to be equivalent security guarantees to TLS with the exception of order
as similar to TLS as possible, so this document assumes that all protection/non-replayability. DTLS was designed to be as similar to
properties from TLS are carried over except where specified. TLS as possible, so this document assumes that all properties from
TLS are carried over except where specified.
3.2. Application-Specific Security Protocols 3.2. Application-Specific Security Protocols
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
skipping to change at page 7, line 38 skipping to change at page 8, line 26
and RTP control protocol (RTCP) packets [RFC3711]. SRTP provides a and RTP control protocol (RTCP) packets [RFC3711]. SRTP provides a
record layer only, and requires a separate handshake protocol to record layer only, and requires a separate handshake protocol to
provide key agreement and identity management. provide key agreement and identity management.
The commonly used handshake protocol for SRTP is DTLS, in the form of The commonly used handshake protocol for SRTP is DTLS, in the form of
DTLS-SRTP [RFC5764]. This is an extension to DTLS that negotiates 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 the use of SRTP as the record layer, and describes how to export keys
for use with SRTP. for use with SRTP.
ZRTP [RFC6189] is an alternative key agreement and identity ZRTP [RFC6189] is an alternative key agreement and identity
management protocols for SRTP. ZRTP Key agreement is performed using management protocol for SRTP. ZRTP Key agreement is performed using
a Diffie-Hellman key exchange that runs on the media path. This a Diffie-Hellman key exchange that runs on the media path. This
generates a shared secret that is then used to generate the master generates a shared secret that is then used to generate the master
key and salt for SRTP. 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.
skipping to change at page 8, line 32 skipping to change at page 9, line 22
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
authentication, tcpcrypt is vulnerable to active attacks. authentication, tcpcrypt is vulnerable to active attacks.
3.3.4. MinimalT 3.3.4. MinimaLT
MinimalT is a UDP-based transport security protocol designed to offer MinimaLT [MinimaLT] is a UDP-based transport security protocol
confidentiality, mutual authentication, DoS prevention, and designed to offer confidentiality, mutual authentication, DoS
connection mobility [MinimalT]. One major goal of the protocol is to prevention, and connection mobility. One major goal of the protocol
leverage existing protocols to obtain server-side configuration is to 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 that, unlike many
Daniel J. Bernstein. Unlike many other security protocols, it is other security protocols, is based entirely upon public key
based entirely upon public key algorithms. CurveCP provides its own algorithms. CurveCP provides its own reliability for application
reliability for application data as part of its protocol. 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. IPsec
IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec
protocol suite that encrypts and authenticates IP packets, either for protocol suite that encrypts and authenticates IP packets, either for
creating tunnels (tunnel-mode) or for direct transport connections creating tunnels (tunnel-mode) or for direct transport connections
(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 [WireGuard] is an IP-layer protocol designed as an
[WireGuard] for certain use cases. It uses UDP to encapsulate IP alternative to IPsec for certain use cases. It uses UDP to
datagrams between peers. Unlike most transport security protocols, encapsulate IP datagrams between peers. Unlike most transport
which rely on Public Key Infrastructure (PKI) for peer security protocols, which rely on Public Key Infrastructure (PKI) for
authentication, WireGuard authenticates peers using pre-shared public peer authentication, WireGuard authenticates peers using pre-shared
keys delivered out-of-band, each of which is bound to one or more IP public keys delivered out-of-band, each of which is bound to one or
addresses. Moreover, as a protocol suited for VPNs, WireGuard offers more IP addresses. Moreover, as a protocol suited for VPNs,
no extensibility, negotiation, or cryptographic agility. WireGuard offers 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 either 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 For key establishment, OpenVPN can either use TLS as a handshake
pre-shared keys. protocol or use 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.
skipping to change at page 10, line 41 skipping to change at page 11, line 35
* DTLS * DTLS
* ZRTP * ZRTP
* SRTP * SRTP
Transport-Layer Security Protocols: Transport-Layer Security Protocols:
* QUIC * QUIC
* MinimalT * MinimaLT
* CurveCP * CurveCP
Packet Security Protocols: Packet Security Protocols:
* IKEv2 and ESP * IPsec
* WireGuard * WireGuard
* OpenVPN * 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:
* DTLS when used as a handshake protocol for SRTP [RFC7850] * DTLS when used as a handshake protocol for SRTP [RFC7850]
* ZRTP [RFC4571] * ZRTP [RFC6189]
* SRTP [RFC4571] * SRTP [RFC4571][RFC3711]
Packet Security Protocols: Packet Security Protocols:
* IKEv2 and ESP [RFC8229] * IPsec [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 Specifically, tcpcrypt is designed to run on top of TCP, and uses the
Encryption Negotiation Option (ENO) [RFC8547] to negotiate its TCP 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 depend on running over a framed
framed protocol like UDP, but they add their own layers of protocol like UDP, but they add their own layers of reliability and
reliability and other transport services. Thus, an application that other transport services. Thus, an application that uses one of
uses one of these protocols cannot decouple the security from these protocols cannot decouple the security from transport
transport functionality. functionality.
5. Application Interface 5. Application Interface
This section describes the interface surface exposed by the security This section describes the interface exposed by the security
protocols described above. We partition these interfaces into pre- protocols described above. We partition these interfaces into pre-
connection (configuration), connection, and post-connection connection (configuration), connection, and post-connection
interfaces, following conventions in [I-D.ietf-taps-interface] and interfaces, 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 Note that not all protocols support each interface. The table in
Section 5.4 summarizes which protocol exposes which of the Section 5.4 summarizes which protocol exposes which of the
interfaces. In the following sections, we provide abbreviations of interfaces. In the following sections, we provide abbreviations of
the interface names to use in the summary table. 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 keys are negotiated.
* Identities and Private Keys (IPK): The application can provide its * Identities and Private Keys (IPK): The application can provide its
identities (certificates) and private keys, or mechanisms to identity, credentials (e.g., certificates), and private keys, or
access these, to the security protocol to use during handshakes. mechanisms to access these, to the security protocol to use during
handshakes.
- TLS - TLS
- DTLS - DTLS
- ZRTP - ZRTP
- QUIC - QUIC
- MinimalT - MinimaLT
- CurveCP - CurveCP
- IKEv2 - IPsec
- WireGuard - WireGuard
- OpenVPN - OpenVPN
* Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) * Supported Algorithms (Key Exchange, Signatures, and Ciphersuites)
(ALG): The application can choose the algorithms that are (ALG): The application can choose the algorithms that are
supported for key exchange, signatures, and ciphersuites. supported for key exchange, signatures, and ciphersuites.
- TLS - TLS
- DTLS - DTLS
- ZRTP - ZRTP
- QUIC - QUIC
- tcpcrypt - tcpcrypt
- MinimalT - MinimaLT
- IKEv2 - IPsec
- OpenVPN - OpenVPN
* Extensions (Application-Layer Protocol Negotiation) (EXT): The * Extensions (EXT): The application enables or configures extensions
application enables or configures extensions that are to be that are to be negotiated by the security protocol, such as
negotiated by the security protocol, such as ALPN [RFC7301]. Application-Layer Protocol Negotiation (ALPN) [RFC7301].
- TLS - TLS
- DTLS - DTLS
- QUIC - QUIC
* Session Cache Management (CM): The application provides the * Session Cache Management (CM): The application provides the
ability to save and retrieve session state (such as tickets, ability to save and retrieve session state (such as tickets,
keying material, and server parameters) that may be used to resume keying material, and server parameters) that may be used to resume
the security session. the security session.
- TLS - TLS
skipping to change at page 13, line 30 skipping to change at page 14, line 23
- TLS - TLS
- DTLS - DTLS
- ZRTP - ZRTP
- QUIC - QUIC
- tcpcrypt - tcpcrypt
- MinimalT - MinimaLT
* Authentication Delegation (AD): The application provides access to * Authentication Delegation (AD): The application provides access to
a separate module that will provide authentication, using EAP for a separate module that will provide authentication, using
example. Extensible Authentication Protocol (EAP) [RFC3748] for example.
- IKEv2 - IPsec
- tcpcrypt - tcpcrypt
* Pre-Shared Key Import (PSKI): 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 use in application directly can supply pre-shared keys for use in
encrypting (and authenticating) communication with a peer. encrypting (and authenticating) communication with a peer.
- TLS - TLS
- DTLS - DTLS
- ZRTP - ZRTP
- QUIC - QUIC
- ESP
- IKEv2
- OpenVPN
- tcpcrypt - tcpcrypt
- MinimalT - MinimaLT
- IPsec
- WireGuard - WireGuard
- OpenVPN
5.2. Connection Interfaces 5.2. Connection Interfaces
* Identity Validation (IV): During a handshake, the security * Identity Validation (IV): During a handshake, the security
protocol will conduct identity validation of the peer. This can protocol will conduct identity validation of the peer. This can
call into the application to offload validation. offload validation or occur transparently to the application.
- TLS - TLS
- DTLS - DTLS
- ZRTP - ZRTP
- QUIC - QUIC
- MinimalT - MinimaLT
- CurveCP - CurveCP
- IKEv2 - IPsec
- WireGuard - WireGuard
- OpenVPN - OpenVPN
* Source Address Validation (SAV): The handshake protocol may * Source Address Validation (SAV): The handshake protocol may
delegate validation of the remote peer that has sent data to the interact with the transport protocol or application to validate
transport protocol or application. This involves sending a cookie the address of the remote peer that has sent data. This involves
exchange to avoid DoS attacks. sending a cookie exchange to avoid DoS attacks. (This list omits
protocols which depend on TCP and therefore implicitly perform
SAV.)
- DTLS - DTLS
- QUIC - QUIC
- IKEv2 - IPsec
- WireGuard - WireGuard
5.3. Post-Connection Interfaces 5.3. Post-Connection Interfaces
* Connection Termination (CT): The security protocol may be * Connection Termination (CT): The security protocol may be
instructed to tear down its connection and session information. instructed to tear down its connection and session information.
This is needed by some protocols, e.g., to prevent application This is needed by some protocols, e.g., to prevent application
data truncation attacks in which an attacker terminates an data truncation attacks in which an attacker terminates an
underlying insecure connection-oriented protocol to terminate the underlying insecure connection-oriented protocol to terminate the
skipping to change at page 15, line 24 skipping to change at page 16, line 24
- TLS - TLS
- DTLS - DTLS
- ZRTP - ZRTP
- QUIC - QUIC
- tcpcrypt - tcpcrypt
- MinimalT - MinimaLT
- IKEv2 - IPsec
- OpenVPN - OpenVPN
* Key Update (KU): The handshake protocol may be instructed to * Key Update (KU): The handshake protocol may be instructed to
update its keying material, either by the application directly or update its keying material, either by the application directly or
by the record protocol sending a key expiration event. by the record protocol sending a key expiration event.
- TLS - TLS
- DTLS - DTLS
- QUIC - QUIC
- tcpcrypt - tcpcrypt
- MinimalT - MinimaLT
- IKEv2 - IPsec
* Shared Secret Export (PSKE): The handshake protocol may provide an * Shared Secret Export (PSKE): The handshake protocol may provide an
interface for producing shared secrets for application-specific interface for producing shared secrets for application-specific
uses. uses.
- TLS - TLS
- DTLS - DTLS
- tcpcrypt - tcpcrypt
- IKEv2 - IPsec
- OpenVPN - OpenVPN
- MinimalT - MinimaLT
* Key Expiration (KE): The record protocol can signal that its keys * Key Expiration (KE): The record protocol can signal that its keys
are expiring due to reaching a time-based deadline, or a use-based 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 - IPsec
* Mobility Events (ME): The record protocol can be signaled that it * Mobility Events (ME): The record protocol can be signaled that it
is being migrated to another transport or interface due to is being migrated to another transport or interface due to
connection mobility, which may reset address and state validation connection mobility, which may reset address and state validation
and induce state changes such as use of a new Connection and induce state changes such as use of a new Connection
Identifier (CID). Identifier (CID).
- DTLS (version 1.3 only [I-D.ietf-tls-dtls13])
- QUIC - QUIC
- MinimalT - MinimaLT
- CurveCP - CurveCP
- IKEv2 [RFC4555] - IPsec [RFC4555]
- WireGuard - WireGuard
5.4. Summary of Interfaces Exposed by Protocols 5.4. Summary of Interfaces Exposed by Protocols
The following table summarizes which protocol exposes which The following table summarizes which protocol exposes which
interface. interface.
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| Protocol |IPK|ALG | EXT |CM|AD| PSKI |IV| SAV |CT|KU| PSKE |KE|ME| | Protocol |IPK|ALG | EXT |CM|AD| PSKI |IV| SAV |CT|KU| PSKE |KE|ME|
+===========+===+====+=====+==+==+======+==+=====+==+==+======+==+==+ +===========+===+====+=====+==+==+======+==+=====+==+==+======+==+==+
| TLS | x | x | x |x | | x |x | |x |x | x | | | | TLS | x | x | x |x | | x |x | |x |x | x | | |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| DTLS | x | x | x |x | | x |x | x |x |x | x | | | | DTLS | x | x | x |x | | x |x | x |x |x | x | |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| ZRTP | x | x | |x | | x |x | |x | | | | | | ZRTP | x | x | |x | | x |x | |x | | | | |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| QUIC | x | x | x |x | | 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 | | | | tcpcrypt | | x | |x |x | x | | |x |x | x | | |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| MinimalT | x | x | |x | | x |x | |x |x | x | |x | | MinimaLT | x | x | |x | | x |x | |x |x | x | |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| CurveCP | x | | | | | |x | | | | | |x | | CurveCP | x | | | | | |x | | | | | |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| IKEv2 | x | x | | |x | x |x | x |x |x | x | |x | | IPsec | x | x | | |x | x |x | x |x |x | x |x |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| ESP | | | | | | x | | | | | |x | |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| WireGuard | x | | | | | x |x | x | | | | |x | | WireGuard | x | | | | | x |x | x | | | | |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| OpenVPN | x | x | | | | x |x | |x | | x | | | | OpenVPN | x | x | | | | x |x | |x | | x | | |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
Table 1 Table 1
x=Interface is exposed (blank)=Interface is not exposed x=Interface is exposed (blank)=Interface is not exposed
skipping to change at page 18, line 9 skipping to change at page 19, line 9
made. For example, metadata leakage via timing side channels and made. For example, metadata leakage via timing side channels and
traffic analysis may compromise any protocol discussed in this traffic analysis may compromise any protocol discussed in this
survey. Applications using Security Interfaces should take such survey. Applications using Security Interfaces should take such
limitations into consideration when using a particular protocol limitations into consideration when using a particular protocol
implementation. implementation.
8. Privacy Considerations 8. Privacy Considerations
Analysis of how features improve or degrade privacy is intentionally Analysis of how features improve or degrade privacy is intentionally
omitted from this survey. All security protocols surveyed generally omitted from this survey. All security protocols surveyed generally
improve privacy by reducing information leakage via encryption. improve privacy by using encryption to reduce information leakage.
However, varying amounts of metadata remain in the clear across each However, varying amounts of metadata remain in the clear across each
protocol. For example, client and server certificates are sent in protocol. For example, client and server certificates are sent in
cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3 cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3
[RFC8446]. A survey of privacy features, or lack thereof, for [RFC8446]. A survey of privacy features, or lack thereof, for
various security protocols could be addressed in a separate document. various security protocols could be addressed in a separate document.
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja
Kuehlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for Kuehlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for
skipping to change at page 18, line 49 skipping to change at page 19, line 49
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft, and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-27, 21 February 2020, draft-ietf-quic-transport-27, 21 February 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic- <http://www.ietf.org/internet-drafts/draft-ietf-quic-
transport-27.txt>. 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", Work in Progress, Internet-Draft, Transport Services", Work in Progress, Internet-Draft,
draft-ietf-taps-arch-06, 23 December 2019, draft-ietf-taps-arch-07, 9 March 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-taps-arch- <http://www.ietf.org/internet-drafts/draft-ietf-taps-arch-
06.txt>. 07.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", Work in Progress, Internet-Draft, Transport Services", Work in Progress, Internet-Draft,
draft-ietf-taps-interface-05, 4 November 2019, draft-ietf-taps-interface-06, 9 March 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-taps- <http://www.ietf.org/internet-drafts/draft-ietf-taps-
interface-05.txt>. interface-06.txt>.
[MinimalT] Petullo, W.M., Zhang, X., Solworth, J.A., Bernstein, D.J., [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-37, 9 March 2020, <http://www.ietf.org/internet-
drafts/draft-ietf-tls-dtls13-37.txt>.
[MinimaLT] Petullo, W.M., Zhang, X., Solworth, J.A., Bernstein, D.J.,
and T. Lange, "MinimaLT -- Minimal-latency Networking and T. Lange, "MinimaLT -- Minimal-latency Networking
Through Better Security", Through 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>.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, DOI 10.17487/RFC2890, September 2000,
<https://www.rfc-editor.org/info/rfc2890>.
[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>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[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 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
skipping to change at page 20, line 5 skipping to change at page 21, line 27
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
and RTP Control Protocol (RTCP) Packets over Connection- and RTP Control Protocol (RTCP) Packets over Connection-
Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July
2006, <https://www.rfc-editor.org/info/rfc4571>. 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>.
[RFC5641] McGill, N. and C. Pignataro, "Layer 2 Tunneling Protocol
Version 3 (L2TPv3) Extended Circuit Status Values",
RFC 5641, DOI 10.17487/RFC5641, August 2009,
<https://www.rfc-editor.org/info/rfc5641>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010, DOI 10.17487/RFC5764, May 2010,
<https://www.rfc-editor.org/info/rfc5764>. <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>.
skipping to change at page 22, line 8 skipping to change at page 23, line 36
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
Apple Inc. Cloudflare
One Apple Park Way 101 Townsend St
Cupertino, California 95014, San Francisco,
United States of America United States of America
Email: cawood@apple.com Email: caw@heapingbits.net
 End of changes. 84 change blocks. 
172 lines changed or deleted 228 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/