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/