draft-ietf-taps-transport-security-04.txt		draft-ietf-taps-transport-security-05.txt
	Network Working Group T. Pauly		Network Working Group C. Wood, Ed.
	Internet-Draft Apple Inc.		Internet-Draft Apple Inc.
	Intended status: Informational C. Perkins		Intended status: Informational T. Enghardt
	Expires: May 9, 2019 University of Glasgow		Expires: August 30, 2019 TU Berlin
			T. Pauly
			Apple Inc.
			C. Perkins
			University of Glasgow
	K. Rose		K. Rose
	Akamai Technologies, Inc.		Akamai Technologies, Inc.
	C. Wood		February 26, 2019
	Apple Inc.
	November 05, 2018
	A Survey of Transport Security Protocols		A Survey of Transport Security Protocols
	draft-ietf-taps-transport-security-04		draft-ietf-taps-transport-security-05
	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 [RFC8095] by		efforts to define and catalog transport services [RFC8095] by
	describing the interfaces required to add security protocols. It		describing the interfaces required to add security protocols. It
	examines Transport Layer Security (TLS), Datagram Transport Layer		examines Transport Layer Security (TLS), Datagram Transport Layer
	Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +		Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +
	TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with		TLS), tcpcrypt, Internet Key Exchange with Encapsulating Security
	Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and		Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP,
	WireGuard. This survey is not limited to protocols developed within		MinimalT. This survey is not limited to protocols developed within
	the scope or context of the IETF, and those included represent a		the scope or context of the IETF, and those included represent a
	superset of features a TAPS system may need to support.		superset of features a TAPS system may need to support.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 9, 2019.		This Internet-Draft will expire on August 30, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	3. Security Features . . . . . . . . . . . . . . . . . . . . . . 5		3. Security Features . . . . . . . . . . . . . . . . . . . . . . 5
	4. Transport Security Protocol Descriptions . . . . . . . . . . 7		4. Transport Security Protocol Descriptions . . . . . . . . . . 7
	4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.1.1. Protocol Description . . . . . . . . . . . . . . . . 7		4.1.1. Protocol Description . . . . . . . . . . . . . . . . 7
	4.1.2. Security Features . . . . . . . . . . . . . . . . . . 8		4.1.2. Security Features . . . . . . . . . . . . . . . . . . 8
	4.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9		4.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9
	4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.2.1. Protocol Description . . . . . . . . . . . . . . . . 9		4.2.1. Protocol Description . . . . . . . . . . . . . . . . 9
	4.2.2. Security Features . . . . . . . . . . . . . . . . . . 10		4.2.2. Security Features . . . . . . . . . . . . . . . . . . 10
	4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10		4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10
	4.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 10		4.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 11
	4.3.1. Protocol Description . . . . . . . . . . . . . . . . 11		4.3.1. Protocol Description . . . . . . . . . . . . . . . . 11
	4.3.2. Security Features . . . . . . . . . . . . . . . . . . 11		4.3.2. Security Features . . . . . . . . . . . . . . . . . . 11
	4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 11		4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 12
	4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 11		4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 12
	4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12		4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12
	4.4.1. Protocol descriptions . . . . . . . . . . . . . . . . 12		4.4.1. Protocol descriptions . . . . . . . . . . . . . . . . 12
	4.4.2. Security Features . . . . . . . . . . . . . . . . . . 13		4.4.2. Security Features . . . . . . . . . . . . . . . . . . 14
	4.4.3. Protocol Dependencies . . . . . . . . . . . . . . . . 14		4.4.3. Protocol Dependencies . . . . . . . . . . . . . . . . 14
	4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 14		4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 15
	4.5.1. Protocol description . . . . . . . . . . . . . . . . 14		4.5.1. Protocol description . . . . . . . . . . . . . . . . 15
	4.5.2. Security Features . . . . . . . . . . . . . . . . . . 15		4.5.2. Security Features . . . . . . . . . . . . . . . . . . 16
	4.5.3. Protocol Dependencies . . . . . . . . . . . . . . . . 16		4.5.3. Protocol Dependencies . . . . . . . . . . . . . . . . 16
	4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 16		4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 16
	4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 16		4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 17
	4.6.1. Protocol Description . . . . . . . . . . . . . . . . 16		4.6.1. Protocol Description . . . . . . . . . . . . . . . . 17
	4.6.2. Security Features . . . . . . . . . . . . . . . . . . 17		4.6.2. Security Features . . . . . . . . . . . . . . . . . . 18
	4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18		4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18
	4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18		4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18
	4.7.1. Protocol description . . . . . . . . . . . . . . . . 18		4.7.1. Protocol description . . . . . . . . . . . . . . . . 18
	4.7.2. Security Features . . . . . . . . . . . . . . . . . . 19		4.7.2. Security Features . . . . . . . . . . . . . . . . . . 19
	4.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 19		4.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 19
	4.8. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 19		4.8. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20
	4.8.1. Protocol Description . . . . . . . . . . . . . . . . 19		4.8.1. Protocol Description . . . . . . . . . . . . . . . . 20
	4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 20		4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 21
	4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 20		4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 21
	4.9. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20		4.9. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 21
	4.9.1. Protocol Description . . . . . . . . . . . . . . . . 20		4.9.1. Protocol Description . . . . . . . . . . . . . . . . 22
	4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 22		4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 22
	4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 22		4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 23
	5. Security Features and Transport Dependencies . . . . . . . . 22		4.10. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . 23
	5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 22		4.10.1. Protocol Description . . . . . . . . . . . . . . . . 23
	5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 23		4.10.2. Protocol Features . . . . . . . . . . . . . . . . . 24
	5.3. Optional Feature Availability . . . . . . . . . . . . . . 24		4.10.3. Protocol Dependencies . . . . . . . . . . . . . . . 24
	6. Transport Security Protocol Interfaces . . . . . . . . . . . 26		5. Security Features and Application Dependencies . . . . . . . 24
	6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 26		5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 25
	6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 27		5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 25
	6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 27		5.3. Optional Feature Availability . . . . . . . . . . . . . . 27
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		6. Transport Security Protocol Interfaces . . . . . . . . . . . 29
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 28		6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 29
	9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28		6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 30
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28		6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 30
	11. Normative References . . . . . . . . . . . . . . . . . . . . 28		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33		8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
			9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
			10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
			11. Normative References . . . . . . . . . . . . . . . . . . . . 31
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
	1. Introduction		1. Introduction
	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 [RFC8095] by		efforts to define and catalog transport services [RFC8095] by
	describing the interfaces required to add security protocols. It		describing the interfaces required to add security protocols. It
	examines Transport Layer Security (TLS), Datagram Transport Layer		examines Transport Layer Security (TLS), Datagram Transport Layer
	Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +		Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +
	TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with		TLS), tcpcrypt, Internet Key Exchange with Encapsulating Security
	Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and		Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, and
	WireGuard. For each protocol, this document provides a brief		MinimalT. For each protocol, this document provides a brief
	description, the security features it provides, and the dependencies		description, the security features it provides, and the dependencies
	it has on the underlying transport. This is followed by defining the		it has on the underlying transport. This is followed by defining the
	set of transport security features shared by these protocols.		set of transport security features shared by these protocols.
	Finally, we distill the application and transport interfaces provided		Finally, we distill the application and transport interfaces provided
	by the transport security protocols.		by the transport security protocols.
	Selected protocols represent a superset of functionality and features		Selected protocols represent a superset of functionality and features
	a TAPS system may need to support, both internally and externally -		a TAPS system may need to support, both internally and externally -
	via an API - for applications [I-D.ietf-taps-arch]. Ubiquitous IETF		via an API - for applications [I-D.ietf-taps-arch]. Ubiquitous IETF
	protocols such as (D)TLS, as well as non-standard protocols such as		protocols such as (D)TLS, as well as non-standard protocols such as
	skipping to change at page 5, line 49 ¶		skipping to change at page 6, line 5 ¶
	initiation.		initiation.
	3. Security Features		3. Security Features
	In this section, we enumerate Security Features exposed by protocols		In this section, we enumerate Security Features exposed by protocols
	discussed in the remainder of this document. Protocol security (and		discussed in the remainder of this document. Protocol security (and
	privacy) properties that are unrelated to the API surface exposed by		privacy) properties that are unrelated to the API surface exposed by
	such protocols, such as client or server identity hiding, are not		such protocols, such as client or server identity hiding, are not
	listed here as features.		listed here as features.
	o Forward-secure key establishment: Cryptographic key establishment		o Forward-secure session key establishment: Cryptographic key
	with forward secure properties.		establishment with forward secure properties.
	o Cryptographic algorithm negotiation: Negotiate support of protocol		o Cryptographic algorithm negotiation: Negotiate support of protocol
	algorithms, including: encryption, hash, MAC (PRF), and digital		algorithms, including: encryption, hash, MAC (PRF), and digital
	signature algorithms.		signature algorithms.
	o Session caching and management: Manage session state cache used		o Session caching and management: Manage session state cache used
	for subsequent connections aimed towards amortizing connection		for subsequent connections aimed towards amortizing connection
	establishment costs.		establishment costs.
	o Peer authentication (certificate, raw public key, pre-shared key,		o Peer authentication (certificate, raw public key, pre-shared key,
	or EAP-based): Peer authentication using select or protocol-		or EAP-based): Peer authentication using select or protocol-
	specific mechanisms.		specific mechanisms.
			o Unilateral responder authentication: Required authentication for
			the responder of a connection.
	o Mutual authentication: Connection establishment wherein both		o Mutual authentication: Connection establishment wherein both
	endpoints are authenticated.		endpoints are authenticated.
	o Application-layer authentication delegation: Out-of-band peer		o Application authentication delegation: Out-of-band peer
	authentication performed by applications outside of the connection		authentication performed by applications outside of the connection
	establishment.		establishment.
	o Record (channel or datagram) confidentiality and integrity:		o Record (channel or datagram) confidentiality and integrity:
	Encryption and authentication of application plaintext bytes sent		Encryption and authentication of application plaintext bytes sent
	between peers over a channel or in individual datagrams.		between peers over a channel or in individual datagrams.
	o Partial record confidentiality: Encryption of some portion of		o Partial record confidentiality: Encryption of some portion of
	records.		records.
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 46 ¶
	Once a session is disconnected all session keying material must be		Once a session is disconnected all session keying material must be
	destroyed, with the exception of secrets previously established		destroyed, with the exception of secrets previously established
	expressly for purposes of session resumption. TLS supports stateful		expressly for purposes of session resumption. TLS supports stateful
	and stateless resumption. (Here, "state" refers to bookkeeping on a		and stateless resumption. (Here, "state" refers to bookkeeping on a
	per-session basis by the server. It is assumed that the client must		per-session basis by the server. It is assumed that the client must
	always store some state information in order to resume a session.)		always store some state information in order to resume a session.)
	4.1.2. Security Features		4.1.2. Security Features
	o Forward-secure key establishment.		o Forward-secure session key establishment.
	o Cryptographic algorithm negotiation.		o Cryptographic algorithm negotiation.
	o Stateful and stateless cross-connection session resumption.		o Stateful and stateless cross-connection session resumption.
	o Session caching and management.		o Session caching and management.
	o Peer authentication (Certificate, raw public key, and pre-shared		o Peer authentication (Certificate, raw public key, and pre-shared
	key).		key).
	o Mandatory server authentication, optional client authentication.		o Unilateral responder authentication.
			o Mutual authentication.
	o Application authentication delegation.		o Application authentication delegation.
	o Record (channel) confidentiality and integrity.		o Record (channel) confidentiality and integrity.
	o Record replay prevention.		o Record replay prevention.
	o Application-layer feature negotiation.		o Application-layer feature negotiation.
	o Configuration extensions.		o Configuration extensions.
	skipping to change at page 10, line 30 ¶		skipping to change at page 10, line 39 ¶
	o Record (datagram) confidentiality and integrity.		o Record (datagram) confidentiality and integrity.
	o Out-of-order record receipt.		o Out-of-order record receipt.
	o DoS mitigation (cookie-based).		o DoS mitigation (cookie-based).
	See also the features from TLS.		See also the features from TLS.
	4.2.3. Protocol Dependencies		4.2.3. Protocol Dependencies
			o DTLS relies on UDP.
	o The DTLS record protocol explicitly encodes record lengths, so		o The DTLS record protocol explicitly encodes record lengths, so
	although it runs over a datagram transport, it does not rely on		although it runs over a datagram transport, it does not rely on
	the transport protocol's framing beyond requiring transport-level		the transport protocol's framing beyond requiring transport-level
	reconstruction of datagrams fragmented over packets. (Note: DTLS		reconstruction of datagrams fragmented over packets. (Note: DTLS
	1.3 short header records omit the explicit length field.)		1.3 short header records omit the explicit length field.)
	o UDP 4-tuple uniqueness, or the connection identifier extension,		o UDP 4-tuple uniqueness, or the connection identifier extension,
	for demultiplexing.		for demultiplexing.
	o Path MTU discovery.		o Path MTU discovery.
			o For the handshake: Reliable, in-order transport. DTLS provides
			its own reliability.
	4.3. (IETF) QUIC with TLS		4.3. (IETF) QUIC with TLS
	QUIC (Quick UDP Internet Connections) is a new standards-track		QUIC (Quick UDP Internet Connections) is a new standards-track
	transport protocol that runs over UDP, loosely based on Google's		transport protocol that runs over UDP, loosely based on Google's
	original proprietary gQUIC protocol [I-D.ietf-quic-transport]. (See		original proprietary gQUIC protocol [I-D.ietf-quic-transport]. (See
	Section 4.3.4 for more details.) The QUIC transport layer itself		Section 4.3.4 for more details.) The QUIC transport layer itself
	provides support for data confidentiality and integrity. This		provides support for data confidentiality and integrity. This
	requires keys to be derived with a separate handshake protocol. A		requires keys to be derived with a separate handshake protocol. A
	mapping for QUIC over TLS 1.3 [I-D.ietf-quic-tls] has been specified		mapping for QUIC over TLS 1.3 [I-D.ietf-quic-tls] has been specified
	to provide this handshake.		to provide this handshake.
	skipping to change at page 11, line 47 ¶		skipping to change at page 12, line 12 ¶
	See also the properties of TLS.		See also the properties of TLS.
	4.3.3. Protocol Dependencies		4.3.3. Protocol Dependencies
	o QUIC transport relies on UDP.		o QUIC transport relies on UDP.
	o QUIC transport relies on TLS 1.3 for key exchange, peer		o QUIC transport relies on TLS 1.3 for key exchange, peer
	authentication, and shared secret derivation.		authentication, and shared secret derivation.
			o For the handshake: Reliable, in-order transport. QUIC provides
			its own reliability.
	4.3.4. Variant: Google QUIC		4.3.4. Variant: Google QUIC
	Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol		Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol
	designed and deployed by Google following experience from deploying		designed and deployed by Google following experience from deploying
	SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally		SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally
	known as "QUIC": this document uses gQUIC to unambiguously		known as "QUIC": this document uses gQUIC to unambiguously
	distinguish it from the standards-track IETF QUIC. The proprietary		distinguish it from the standards-track IETF QUIC. The proprietary
	technical forebear of IETF QUIC, gQUIC was originally designed with		technical forebear of IETF QUIC, gQUIC was originally designed with
	tightly-integrated security and application data transport protocols.		tightly-integrated security and application data transport protocols.
	skipping to change at page 12, line 22 ¶		skipping to change at page 12, line 39 ¶
	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.
	4.4.1. Protocol descriptions		4.4.1. Protocol descriptions
	4.4.1.1. IKEv2		4.4.1.1. IKEv2
	IKEv2 is a control protocol that runs on UDP port 500. Its primary		IKEv2 is a control protocol that runs on UDP ports 500 or 4500 and
	goal is to generate keys for Security Associations (SAs). An SA		TCP port 4500. Its primary goal is to generate keys for Security
	contains shared (cryptographic) information used for establishing		Associations (SAs). An SA contains shared (cryptographic)
	other SAs or keying ESP; See Section 4.4.1.2. IKEv2 first uses a		information used for establishing other SAs or keying ESP; See
	Diffie-Hellman key exchange to generate keys for the "IKE SA", which		Section 4.4.1.2. IKEv2 first uses a Diffie-Hellman key exchange to
	is a set of keys used to encrypt further IKEv2 messages. It then		generate keys for the "IKE SA", which is a set of keys used to
	goes through a phase of authentication in which both peers present		encrypt further IKEv2 messages. IKE then performs a phase of
	blobs signed by a shared secret or private key, after which another		authentication in which both peers present blobs signed by a shared
	set of keys is derived, referred to as the "Child SA". These Child		secret or private key that authenticates the entire IKE exchange and
	SA keys are used by ESP.		the IKE identities. IKE then derives further sets of keys on demand,
			which together with traffic policies are referred to as the "Child
			SA". These Child SA keys are used by ESP.
	IKEv2 negotiates which protocols are acceptable to each peer for both		IKEv2 negotiates which protocols are acceptable to each peer for both
	the IKE and Child SAs using "Proposals". Each proposal may contain		the IKE and Child SAs using "Proposals". Each proposal specifies an
	an encryption algorithm, an authentication algorithm, a Diffie-		encryption and authentication algorithm, or an AEAD algorithm, a
	Hellman group, and (for IKE SAs only) a pseudorandom function		Diffie-Hellman group, and (for IKE SAs only) a pseudorandom function
	algorithm. Each peer may support multiple proposals, and the most		algorithm. Each peer may support multiple proposals, and the most
	preferred mutually supported proposal is chosen during the handshake.		preferred mutually supported proposal is chosen during the handshake.
	The authentication phase of IKEv2 may use Shared Secrets,		The authentication phase of IKEv2 may use Shared Secrets,
	Certificates, Digital Signatures, or an EAP (Extensible		Certificates, Digital Signatures, or an EAP (Extensible
	Authentication Protocol) method. At a minimum, IKEv2 takes two round		Authentication Protocol) method. At a minimum, IKEv2 takes two round
	trips to set up both an IKE SA and a Child SA. If EAP is used, this		trips to set up both an IKE SA and a Child SA. If EAP is used, this
	exchange may be expanded.		exchange may be expanded.
	Any SA used by IKEv2 can be rekeyed upon expiration, which is usually		Any SA used by IKEv2 can be rekeyed before expiration, which is
	based either on time or number of bytes encrypted.		usually based either on time or number of bytes encrypted.
	There is an extension to IKEv2 that allows session resumption		There is an extension to IKEv2 that allows session resumption
	[RFC5723].		[RFC5723].
	MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a		MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a
	set of Security Associations to migrate over different addresses and		set of Security Associations to migrate over different outer IP
	interfaces [RFC4555].		addresses and interfaces [RFC4555].
	When UDP is not available or well-supported on a network, IKEv2 may		When UDP is not available or well-supported on a network, IKEv2 may
	be encapsulated in TCP [RFC8229].		be encapsulated in TCP [RFC8229].
	4.4.1.2. ESP		4.4.1.2. ESP
	ESP is a protocol that encrypts and authenticates IPv4 and IPv6		ESP is a protocol that encrypts and authenticates IPv4 and IPv6
	packets. The keys used for both encryption and authentication can be		packets. The keys used for both encryption and authentication can be
	derived from an IKEv2 exchange. ESP Security Associations come as		derived from an IKEv2 exchange. ESP Security Associations come as
	pairs, one for each direction between two peers. Each SA is		pairs, one for each direction between two peers. Each SA is
	skipping to change at page 13, line 43 ¶		skipping to change at page 14, line 14 ¶
	ESP packets may be sent directly over IP, but where network		ESP packets may be sent directly over IP, but where network
	conditions warrant (e.g., when a NAT is present or when a firewall		conditions warrant (e.g., when a NAT is present or when a firewall
	blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP		blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP
	[RFC8229].		[RFC8229].
	4.4.2. Security Features		4.4.2. Security Features
	4.4.2.1. IKEv2		4.4.2.1. IKEv2
	o Forward-secure key establishment.		o Forward-secure session key establishment.
	o Cryptographic algorithm negotiation.		o Cryptographic algorithm negotiation.
	o Peer authentication (Certificate, raw public key, pre-shared key,		o Peer authentication (certificate, raw public key, pre-shared key,
	and EAP).		and EAP).
			o Unilateral responder authentication.
	o Mutual authentication.		o Mutual authentication.
	o Record (datagram) confidentiality and integrity.		o Record (datagram) confidentiality and integrity.
	o Session resumption.		o Session resumption.
	o Connection mobility.		o Connection mobility.
	o DoS mitigation (cookie-based).		o DoS mitigation (cookie-based).
	skipping to change at page 15, line 44 ¶		skipping to change at page 16, line 20 ¶
	the signaling plane. The combination of a mutually authenticated		the signaling plane. The combination of a mutually authenticated
	DTLS key exchange on the media path and a fingerprint sent in the		DTLS key exchange on the media path and a fingerprint sent in the
	signalling channel protects against active attacks on the media,		signalling channel protects against active attacks on the media,
	provided the signalling can be trusted. Signalling needs to be		provided the signalling can be trusted. Signalling needs to be
	protected as described in, for example, SIP [RFC3261] Authenticated		protected as described in, for example, SIP [RFC3261] Authenticated
	Identity Management [RFC4474] or the WebRTC security architecture		Identity Management [RFC4474] or the WebRTC security architecture
	[I-D.ietf-rtcweb-security-arch], to provide complete system security.		[I-D.ietf-rtcweb-security-arch], to provide complete system security.
	4.5.2. Security Features		4.5.2. Security Features
	o Forward-secure key establishment.		o Forward-secure session key establishment.
	o Cryptographic algorithm negotiation.		o Cryptographic algorithm negotiation.
	o Mutual authentication.		o Mutual authentication.
	o Partial datagram confidentiality. (Packet headers are not		o Partial datagram confidentiality. (Packet headers are not
	encrypted.)		encrypted.)
	o Optional authentication of data packets.		o Optional authentication of data packets.
	o Mandatory authentication of control packets.		o Mandatory authentication of control packets.
	o Out-of-order record receipt.		o Out-of-order record receipt.
	4.5.3. Protocol Dependencies		4.5.3. Protocol Dependencies
			o Secure RTP can run over UDP or TCP.
	o External key derivation and management protocol, e.g., DTLS		o External key derivation and management protocol, e.g., DTLS
	[RFC5763].		[RFC5763].
	o External identity management protocol, e.g., SIP Authenticated		o External identity management protocol, e.g., SIP Authenticated
	Identity Management [RFC4474], WebRTC Security Architecture		Identity Management [RFC4474], WebRTC Security Architecture
	[I-D.ietf-rtcweb-security-arch].		[I-D.ietf-rtcweb-security-arch].
	4.5.4. Variant: ZRTP for Media Path Key Agreement		4.5.4. Variant: ZRTP for Media Path Key Agreement
	ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It		ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It
	skipping to change at page 16, line 43 ¶		skipping to change at page 17, line 22 ¶
	requires endpoints to display a short authentication string that the		requires endpoints to display a short authentication string that the
	users must read and verbally compare to validate the hashes and		users must read and verbally compare to validate the hashes and
	ensure security. Endpoints cache some key material after the first		ensure security. Endpoints cache some key material after the first
	call to use in subsequent calls; this is mixed in with the Diffie-		call to use in subsequent calls; this is mixed in with the Diffie-
	Hellman shared secret, so the short authentication string need only		Hellman shared secret, so the short authentication string need only
	be checked once for a given user. This gives key continuity		be checked once for a given user. This gives key continuity
	properties analogous to the secure shell (ssh) [RFC4253].		properties analogous to the secure shell (ssh) [RFC4253].
	4.6. tcpcrypt		4.6. tcpcrypt
	Tcpcrypt is a lightweight extension to the TCP protocol to enable		Tcpcrypt is a lightweight extension to the TCP protocol for
	opportunistic encryption with hooks available to the application		opportunistic encryption. Applications may use tcpcrypt's unique
	layer for implementation of endpoint authentication.		session ID for further application-level authentication. Absent this
			authentication, tcpcrypt is vulnerable to active attacks.
	4.6.1. Protocol Description		4.6.1. Protocol Description
	Tcpcrypt extends TCP to enable opportunistic encryption between the		Tcpcrypt extends TCP to enable opportunistic encryption between the
	two ends of a TCP connection [I-D.ietf-tcpinc-tcpcrypt]. It is a		two ends of a TCP connection [I-D.ietf-tcpinc-tcpcrypt]. It is a
	family of TCP encryption protocols (TEP), distinguished by key		family of TCP encryption protocols (TEP), distinguished by key
	exchange algorithm. The use of a TEP is negotiated with a TCP option		exchange algorithm. The use of a TEP is negotiated with a TCP option
	during the initial TCP handshake via the mechanism described by TCP		during the initial TCP handshake via the mechanism described by TCP
	Encryption Negotiation Option (ENO) [I-D.ietf-tcpinc-tcpeno]. In the		Encryption Negotiation Option (ENO) [I-D.ietf-tcpinc-tcpeno]. In the
	case of initial session establishment, once a tcpcrypt TEP has been		case of initial session establishment, once a tcpcrypt TEP has been
	skipping to change at page 17, line 36 ¶		skipping to change at page 18, line 16 ¶
	option during the TCP handshake. Given the length constraints		option during the TCP handshake. Given the length constraints
	imposed by TCP options, unlike stateless resumption mechanisms (such		imposed by TCP options, unlike stateless resumption mechanisms (such
	as that provided by session tickets in TLS) resumption in tcpcrypt		as that provided by session tickets in TLS) resumption in tcpcrypt
	requires the maintenance of state on the server, and so successful		requires the maintenance of state on the server, and so successful
	resumption across a pool of servers implies shared state.		resumption across a pool of servers implies shared state.
	Owing to middlebox ossification issues, tcpcrypt only protects the		Owing to middlebox ossification issues, tcpcrypt only protects the
	payload portion of a TCP packet. It does not encrypt any header		payload portion of a TCP packet. It does not encrypt any header
	information, such as the TCP sequence number.		information, such as the TCP sequence number.
	Tcpcrypt exposes a universally-unique connection-specific session ID
	to the application, suitable for application-level endpoint
	authentication either in-band or out-of-band.
	4.6.2. Security Features		4.6.2. Security Features
	o Forward-secure key establishment.		o Forward-secure session key establishment.
	o Record (channel) confidentiality and integrity.		o Record (channel) confidentiality and integrity.
	o Stateful cross-connection session resumption.		o Stateful cross-connection session resumption.
	o Session caching and management.		o Session caching and management.
	o Application authentication delegation.		o Application authentication delegation.
	4.6.3. Protocol Dependencies		4.6.3. Protocol Dependencies
	o TCP.		o TCP.
	o TCP Encryption Negotiation Option (ENO).		o TCP Encryption Negotiation Option (ENO).
	4.7. WireGuard		4.7. WireGuard
	WireGuard is a layer 3 protocol designed to complement or replace		WireGuard is a layer 3 protocol designed as an alternative to IPsec
	IPsec [WireGuard] for certain use cases. It uses UDP to encapsulate		[WireGuard] for certain use cases. It uses UDP to encapsulate IP
	IP datagrams between peers. Unlike most transport security		datagrams between peers. Unlike most transport security protocols,
	protocols, which rely on PKI for peer authentication, WireGuard		which rely on PKI for peer authentication, WireGuard authenticates
	authenticates peers using pre-shared public keys delivered out-of-		peers using pre-shared public keys delivered out-of-band, each of
	band, each of which is bound to one or more IP addresses. Moreover,		which is bound to one or more IP addresses. Moreover, as a protocol
	as a protocol suited for VPNs, WireGuard offers no extensibility,		suited for VPNs, WireGuard offers no extensibility, negotiation, or
	negotiation, or cryptographic agility.		cryptographic agility.
	4.7.1. Protocol description		4.7.1. Protocol description
	WireGuard is a simple VPN protocol that binds a pre-shared public key		WireGuard is a simple VPN protocol that binds a pre-shared public key
	to one or more IP addresses. Users configure WireGuard by		to one or more IP addresses. Users configure WireGuard by
	associating peer public keys with IP addresses. These mappings are		associating peer public keys with IP addresses. These mappings are
	stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard]		stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard]
	for more details and sample configurations.) These keys are used		for more details and sample configurations.) These keys are used
	upon WireGuard packet transmission and reception. For example, upon		upon WireGuard packet transmission and reception. For example, upon
	receipt of a Handshake Initiation message, receivers use the static		receipt of a Handshake Initiation message, receivers use the static
	skipping to change at page 19, line 11 ¶		skipping to change at page 19, line 35 ¶
	WireGuard is designed to be entirely stateless, modulo the CryptoKey		WireGuard is designed to be entirely stateless, modulo the CryptoKey
	routing table, which has size linear with the number of trusted		routing table, which has size linear with the number of trusted
	peers. If a WireGuard receiver is under heavy load and cannot		peers. If a WireGuard receiver is under heavy load and cannot
	process a packet, e.g., cannot spare CPU cycles for point		process a packet, e.g., cannot spare CPU cycles for point
	multiplication, it can reply with a cookie similar to DTLS and IKEv2.		multiplication, it can reply with a cookie similar to DTLS and IKEv2.
	This cookie only proves IP address ownership. Any rate limiting		This cookie only proves IP address ownership. Any rate limiting
	scheme can be applied to packets coming from non-spoofed addresses.		scheme can be applied to packets coming from non-spoofed addresses.
	4.7.2. Security Features		4.7.2. Security Features
	o Forward-secure key establishment.		o Forward-secure session key establishment.
	o Peer authentication (Public-key and PSK).		o Peer authentication (public-key and PSK).
	o Mutual authentication.		o Mutual authentication.
	o Record replay prevention (Stateful, timestamp-based).		o Record replay prevention (Stateful, timestamp-based).
	o DoS mitigation (cookie-based).		o DoS mitigation (cookie-based).
	4.7.3. Protocol Dependencies		4.7.3. Protocol Dependencies
	o Datagram transport.		o Datagram transport.
	o Out-of-band key distribution and management.		o Out-of-band key distribution and management.
	4.8. MinimalT		4.8. CurveCP
	MinimalT is a UDP-based transport security protocol designed to offer
	confidentiality, mutual authentication, DoS prevention, and
	connection mobility [MinimalT]. One major goal of the protocol is to
	leverage existing protocols to obtain server-side configuration
	information used to more quickly bootstrap a connection. MinimalT
	uses a variant of TCP's congestion control algorithm.
	4.8.1. Protocol Description
	MinimalT is a secure transport protocol built on top of a widespread
	directory service. Clients and servers interact with local directory
	services to (a) resolve server information and (b) public ephemeral
	state information, respectively. Clients connect to a local resolver
	once at boot time. Through this resolver they recover the IP
	address(es) and public key(s) of each server to which they want to
	connect.
	Connections are instances of user-authenticated, mobile sessions
	between two endpoints. Connections run within tunnels between hosts.
	A tunnel is a server-authenticated container that multiplexes
	multiple connections between the same hosts. All connections in a
	tunnel share the same transport state machine and encryption. Each
	tunnel has a dedicated control connection used to configure and
	manage the tunnel over time. Moreover, since tunnels are independent
	of the network address information, they may be reused as both ends
	of the tunnel move about the network. This does however imply that
	connection establishment and packet encryption mechanisms are
	coupled.
	Before a client connects to a remote service, it must first establish
	a tunnel to the host providing or offering the service. Tunnels are
	established in 1-RTT using an ephemeral key obtained from the
	directory service. Tunnel initiators provide their own ephemeral key
	and, optionally, a DoS puzzle solution such that the recipient
	(server) can verify the authenticity of the request and derive a
	shared secret. Within a tunnel, new connections to services may be
	established.
	4.8.2. Protocol Features
	o Forward-secure key establishment.
	o DoS mitigation (puzzle-based).
	o Connection mobility (based on tunnel identifiers).
	Additional (orthogonal) transport features include: connection
	multiplexing between hosts across shared tunnels, and congestion
	control state is shared across connections between the same host
	pairs.
	4.8.3. Protocol Dependencies
	o A DNS-like resolution service to obtain location information (an
	IP address) and ephemeral keys.
	o A PKI trust store for certificate validation.
	4.9. CurveCP
	CurveCP [CurveCP] is a UDP-based transport security protocol from		CurveCP [CurveCP] is a UDP-based transport security protocol from
	Daniel J. Bernstein. Unlike other transport security protocols, it		Daniel J. Bernstein. Unlike other transport security protocols, it
	is based entirely upon highly efficient public key algorithms. This		is based entirely upon highly efficient public key algorithms. This
	removes many pitfalls associated with nonce reuse and key		removes many pitfalls associated with nonce reuse and key
	synchronization.		synchronization.
	4.9.1. Protocol Description		4.8.1. Protocol Description
	CurveCP is a UDP-based transport security protocol. It is built on		CurveCP is a UDP-based transport security protocol. It is built on
	three principal features: exclusive use of public key authenticated		three principal features: exclusive use of public key authenticated
	encryption of packets, server-chosen cookies to prohibit memory and		encryption of packets, server-chosen cookies to prohibit memory and
	computation DoS at the server, and connection mobility with a client-		computation DoS at the server, and connection mobility with a client-
	chosen ephemeral identifier.		chosen ephemeral identifier.
	There are two rounds in CurveCP. In the first round, the client		There are two rounds in CurveCP. In the first round, the client
	sends its first initialization packet to the server, carrying its		sends its first initialization packet to the server, carrying its
	(possibly fresh) ephemeral public key C', with zero-padding encrypted		(possibly fresh) ephemeral public key C', with zero-padding encrypted
	under the server's long-term public key. The server replies with a		under the server's long-term public key. The server replies with a
	cookie and its own ephemeral key S' and a cookie that is to be used		cookie and its own ephemeral key S' and a cookie that is to be used
	by the client. Upon receipt, the client then generates its second		by the client. Upon receipt, the client then generates its second
	initialization packet carrying: the ephemeral key C', cookie, and an		initialization packet carrying: the ephemeral key C', cookie, and an
	encryption of C', the server's domain name, and, optionally, some		encryption of C', the server's domain name, and, optionally, some
	message data. The server verifies the cookie and the encrypted		message data. The server verifies the cookie and the encrypted
	payload and, if valid, proceeds to send data in return. At this		payload and, if valid, proceeds to send data in return. At this
	point, the connection is established and the two parties can		point, the connection is established and the two parties can
	communicate.		communicate.
	The use of public-key encryption and authentication, or "boxing", is		The use of public-key encryption and authentication, or "boxing",
	done to simplify problems that come with symmetric key management and		simplifies problems that come with symmetric key management and nonce
	synchronization. For example, it allows the sender of a message to		synchronization. For example, it allows the sender of a message to
	be in complete control of each message's nonce. It does not require		be in complete control of each message's nonce. It does not require
	either end to share secret keying material. Furthermore, it allows		either end to share secret keying material. Furthermore, it allows
	connections (or sessions) to be associated with unique ephemeral		connections (or sessions) to be associated with unique ephemeral
	public keys as a mechanism for enabling forward secrecy given the		public keys as a mechanism for enabling forward secrecy given the
	risk of long-term private key compromise.		risk of long-term private key compromise.
	The client and server do not perform a standard key exchange.		The client and server do not perform a standard key exchange.
	Instead, in the initial exchange of packets, each party provides its		Instead, in the initial exchange of packets, each party provides its
	own ephemeral key to the other end. The client can choose a new		own ephemeral key to the other end. The client can choose a new
	skipping to change at page 21, line 48 ¶		skipping to change at page 21, line 13 ¶
	client's initial packet, encrypted under the server's long-term		client's initial packet, encrypted under the server's long-term
	public key, a server generates and returns a stateless cookie that		public key, a server generates and returns a stateless cookie that
	must be echoed back in the client's following message. This cookie		must be echoed back in the client's following message. This cookie
	is encrypted under the client's ephemeral public key. This stateless		is encrypted under the client's ephemeral public key. This stateless
	technique prevents attackers from hijacking client initialization		technique prevents attackers from hijacking client initialization
	packets to obtain cookie values to flood clients. (A client would		packets to obtain cookie values to flood clients. (A client would
	detect the duplicate cookies and reject the flooded packets.)		detect the duplicate cookies and reject the flooded packets.)
	Similarly, replaying the client's second packet, carrying the cookie,		Similarly, replaying the client's second packet, carrying the cookie,
	will be detected by the server.		will be detected by the server.
	CurveCP supports a weak form of client authentication. Clients are		CurveCP supports client authentication by allowing clients to send
	permitted to send their long-term public keys in the second		their long-term public keys in the second initialization packet. A
	initialization packet. A server can verify this public key and, if		server can verify this public key and, if untrusted, drop the
	untrusted, drop the connection and subsequent data.		connection and subsequent data.
	Unlike some other protocols, CurveCP data packets leave only the		Unlike some other protocols, CurveCP data packets leave only the
	ephemeral public key, the connection ID, and the per-message nonce in		ephemeral public key, connection ID, and per-message nonce in the
	the clear. Everything else is encrypted.		clear. All other data is encrypted.
	4.9.2. Protocol Features		4.8.2. Protocol Features
	o Datagram confidentiality and integrity (via public key		o Datagram confidentiality and integrity (via public key
	encryption).		encryption).
			o Peer authentication (public-key).
			o Unilateral responder authentication.
			o Mutual authentication.
	o Connection mobility (based on a client-chosen ephemeral		o Connection mobility (based on a client-chosen ephemeral
	identifier).		identifier).
	o Optional length-hiding and anti-amplification padding.		o Optional length-hiding and anti-amplification padding.
			o Source validation (cookie-based)
			4.8.3. Protocol Dependencies
			o An unreliable transport protocol such as UDP.
			4.9. MinimalT
			MinimalT is a UDP-based transport security protocol designed to offer
			confidentiality, mutual authentication, DoS prevention, and
			connection mobility [MinimalT]. One major goal of the protocol is to
			leverage existing protocols to obtain server-side configuration
			information used to more quickly bootstrap a connection. MinimalT
			uses a variant of TCP's congestion control algorithm.
			4.9.1. Protocol Description
			MinimalT is a secure transport protocol built on top of a widespread
			directory service. Clients and servers interact with local directory
			services to (a) resolve server information and (b) publish ephemeral
			state information, respectively. Clients connect to a local resolver
			once at boot time. Through this resolver they recover the IP
			address(es) and public key(s) of each server to which they want to
			connect.
			Connections are instances of user-authenticated, mobile sessions
			between two endpoints. Connections run within tunnels between hosts.
			A tunnel is a server-authenticated container that multiplexes
			multiple connections between the same hosts. All connections in a
			tunnel share the same transport state machine and encryption. Each
			tunnel has a dedicated control connection used to configure and
			manage the tunnel over time. Moreover, since tunnels are independent
			of the network address information, they may be reused as both ends
			of the tunnel move about the network. This does however imply that
			connection establishment and packet encryption mechanisms are
			coupled.
			Before a client connects to a remote service, it must first establish
			a tunnel to the host providing or offering the service. Tunnels are
			established in 1-RTT using an ephemeral key obtained from the
			directory service. Tunnel initiators provide their own ephemeral key
			and, optionally, a DoS puzzle solution such that the recipient
			(server) can verify the authenticity of the request and derive a
			shared secret. Within a tunnel, new connections to services may be
			established.
			Additional (orthogonal) transport features include: connection
			multiplexing between hosts across shared tunnels, and congestion
			control state is shared across connections between the same host
			pairs.
			4.9.2. Protocol Features
			o Record or datagram confidentiality and integrity.
			o Forward-secure session key establishment.
			o Peer authentication (public-key).
			o Unilateral responder authentication.
			o DoS mitigation (puzzle-based).
			o Out-of-order receipt record.
			o Connection mobility (based on tunnel identifiers).
	4.9.3. Protocol Dependencies		4.9.3. Protocol Dependencies
	o An unreliable transport protocol such as UDP.		o An unreliable transport protocol such as UDP.
	5. Security Features and Transport Dependencies		o A DNS-like resolution service to obtain location information (an
			IP address) and ephemeral keys.
			o A PKI trust store for certificate validation.
			4.10. OpenVPN
			OpenVPN [OpenVPN] is a commonly used protocol designed as an
			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
			transports. OpenVPN encapsulates either IP packets or Ethernet
			frames within a secure tunnel and can run over UDP or TCP.
			4.10.1. Protocol Description
			OpenVPN facilitates authentication using either a pre-shared static
			key or using X.509 certificates and TLS. In pre-shared key mode,
			OpenVPN derives keys for encryption and authentication directly from
			one or multiple symmetric keys. In TLS mode, OpenVPN encapsulates a
			TLS handshake, in which both peers must present a certificate for
			authentication. After the handshake, both sides contribute random
			source material to derive keys for encryption and authentication
			using the TLS pseudo random function (PRF). OpenVPN provides the
			possibility to authenticate and encrypt the TLS handshake itself
			using a pre-shared key or passphrase. Furthermore, it supports
			rekeying using TLS.
			After authentication and key exchange, OpenVPN encrypts payload data,
			i.e., IP packets or Ethernet frames, and signs the payload using an
			HMAC function. The default cipher is BlowFish [BlowFish] and the
			default message digest algorithm is SHA1, but an application can
			select an arbitrary cipher, key size, and message digest algorithm
			for the HMAC. OpenVPN peers support cipher negotiation (NCP) since
			version 2.4, in which case they will upgrade the cipher to AES-
			256-GCM by default.
			OpenVPN can run over TCP or UDP. When running over UDP, OpenVPN
			provides a simple reliability layer for control packets such as the
			TLS handshake and key exchange. It assigns sequence numbers to
			packets, acknowledges packets it receives, and retransmits packets it
			deems lost. Similar to DTLS, this reliability layer is not used for
			data packets, which prevents the problem of two reliability
			mechanisms being encapsulated within each other. When running over
			TCP, OpenVPN includes the packet length in the header, which allows
			the peer to deframe the TCP stream into messages.
			For replay protection, OpenVPN assigns an identifier to each outgoing
			packet, which is unique for the packet and the currently used key.
			In pre-shared key mode or with a CFB or OFB mode cipher, OpenVPN
			combines a timestamp with an incrementing sequence number into a
			64-bit identifier. In TLS mode with CBC cipher mode, OpenVPN omits
			the timestamp, so identifiers are only 32-bit. This is sufficient
			since OpenVPN can guarantee the uniqueness of this identifier for
			each key, as it can trigger rekeying if needed.
			OpenVPN supports connection mobility by allowing a peer to change its
			IP address during an ongoing session. When configured accordingly, a
			host will accept authenticated packets for a session from any IP
			address.
			4.10.2. Protocol Features
			o Peer authentication using certificates or pre-shared key.
			o Mandatory mutual authentication.
			o Connection mobility.
			o Out-of-order record receipt.
			o Length-hiding padding.
			See also the properties of TLS.
			4.10.3. Protocol Dependencies
			o For control packets such as handshake and key exchange: Reliable,
			in-order transport. Reliability is provided either by TCP, or by
			OpenVPN's own reliability layer when using UDP.
			5. Security Features and Application Dependencies
	There exists a common set of features shared across the transport		There exists a common set of features shared across the transport
	protocols surveyed in this document. Mandatory features constitute a		protocols surveyed in this document. Mandatory features constitute a
	baseline of functionality that an application may assume for any TAPS		baseline of functionality that an application may assume for any TAPS
	implementation. They were selected on the basis that they are either		implementation. They were selected on the basis that they are either
	(a) required for any secure transport protocol or (b) nearly		(a) required for any secure transport protocol or (b) nearly
	ubiquitous amongst common secure transport protocols.		ubiquitous amongst common secure transport protocols.
	Optional features by contrast may vary from implementation to		Optional features by contrast may vary from implementation to
	implementation, and so an application cannot simply assume they are		implementation, and so an application cannot simply assume they are
	available. Applications learn of and use optional features by		available. Applications learn of and use optional features by
	querying for their presence and support. Optional features may not		querying for their presence and support. Optional features may not
	be implemented, or may be disabled if their presence impacts		be implemented, or may be disabled if their presence impacts
	transport services or if a necessary transport service or application		transport services or if a necessary transport service or application
	dependency is unavailable. In this context, an application		dependency is unavailable.
	dependency is one required from an application in order to function.
			In this context, an application dependency is an aspect of the
			security feature which can be exposed to the application. An
			application dependency may be required for the security feature to
			function, or it may provide additional information and control to the
			application. For example, an application may need to provide
			information such as keying material or authentication credentials, or
			it may want to restrict which cryptographic algorithms to allow for
			negotiation.
	5.1. Mandatory Features		5.1. Mandatory Features
	Mandatory features must be supported regardless of transport and		Mandatory features must be supported regardless of transport and
	application services available.		application services available. Note that not all mandatory features
			are provided by each surveyed protocol above. For example, tcpcrypt
			does not provide responder authentication and CurveCP does not
			provide forward-secure session key establishment.
	o Record or datagram confidentiality and integrity.		o Record or datagram confidentiality and integrity.
	o Forward-secure key establishment.		* Application dependency: None.
	o Public-key certificate based authentication.		o Forward-secure session key establishment.
			* Application dependency: None.
	o Unilateral responder authentication.		o Unilateral responder authentication.
	Note that most systems provide defailt trust stores used to		* (Optional) Application dependency: Application-provided trust
	authenticate peers based on certificates. In such systems,		information. System trust stores may also be used to
	applications need not provide any trust information. Applications		authenticate responders.
	running on systems without such a feature must necessary depend on
	applications for this information so as to authenticate peers.
	5.2. Optional Features		5.2. Optional Features
	In this section we list optional features along with their necessary		In this section we list optional features along with their necessary
	application dependencies, if any.		application dependencies, if any.
	o Pre-shared key support (PSK):		o Pre-shared key support (PSK):
	* Application dependency: Application provisioning and		* Application dependency: Application provisioning and
	distribution of pre-shared keys.		distribution of pre-shared keys.
			o Mutual authentication (MA):
			* Application dependency: Mutual authentication credentials
			required.
	o Cryptographic algorithm negotiation (AN):		o Cryptographic algorithm negotiation (AN):
	* Application dependency: Application awareness of supported or		* Application dependency: Application awareness of supported or
	desired algorithms.		desired algorithms.
	o Application authentication delegation (AD):		o Application authentication delegation (AD):
	* Application dependency: Application opt-in and policy for		* Application dependency: Application opt-in and policy for
	endpoint authentication.		endpoint authentication.
	o Mutual authentication (MA):
	* Application dependency: Mutual authentication credentials
	required for application support.
	o DoS mitigation (DM):		o DoS mitigation (DM):
	* Application dependency: None.		* Application dependency: None.
	o Connection mobility (CM):		o Connection mobility (CM):
	* Application dependency: None.		* Application dependency: None.
	o Source validation (SV):		o Source validation (SV):
	skipping to change at page 24, line 14 ¶		skipping to change at page 26, line 46 ¶
	o Configuration extensions (CX):		o Configuration extensions (CX):
	* Application dependency: Specification of application-specific		* Application dependency: Specification of application-specific
	extensions.		extensions.
	o Session caching and management (SC):		o Session caching and management (SC):
	* Application dependency: None.		* Application dependency: None.
	o Length-hiding padding (LHP):		o Length-hiding padding (LHP): (Optional) Application dependency:
			Knowledge of desired padding policies. Some protocols, such as
	* Application dependency: Knowledge of desired padding policies.		IKE, can negotiate application-agnostic padding policies.
	o Early data support (ED):		o Early data support (ED):
	* Application dependency: Anti-replay protections or hints of		* Application dependency: Anti-replay protections or hints of
	data idempotency.		data idempotency.
	o Record replay prevention (RP):		o Record replay prevention (RP):
	* Application dependency: None.		* Application dependency: None.
	skipping to change at page 27, line 25 ¶		skipping to change at page 30, line 25 ¶
	o Source Address Validation The handshake protocol may delegate		o Source Address Validation The handshake protocol may delegate
	validation of the remote peer that has sent data to the transport		validation of the remote peer that has sent data to the transport
	protocol or application. This involves sending a cookie exchange		protocol or application. This involves sending a cookie exchange
	to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard		to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard
	6.3. Post-Connection Interfaces		6.3. Post-Connection Interfaces
	o Connection Termination The security protocol may be instructed to		o Connection Termination The security protocol may be instructed to
	tear down its connection and session information. This is needed		tear down its connection and session information. This is needed
	by some protocols to prevent application data truncation attacks.		by some protocols to prevent application data truncation attacks.
	Protocols: TLS, DTLS, QUIC, MinimalT, tcpcrypt, IKEv2		Protocols: TLS, DTLS, QUIC, tcpcrypt, IKEv2, MinimalT
	o Key Update The handshake protocol may be instructed to update its		o Key Update The handshake protocol may be instructed to update its
	keying material, either by the application directly or by the		keying material, either by the application directly or by the
	record protocol sending a key expiration event. Protocols: TLS,		record protocol sending a key expiration event. Protocols: TLS,
	DTLS, QUIC, MinimalT, tcpcrypt, IKEv2		DTLS, QUIC, tcpcrypt, IKEv2, MinimalT
	o Pre-Shared Key Export The handshake protocol will generate one or		o Pre-Shared Key Export The handshake protocol will generate one or
	more keys to be used for record encryption/decryption and		more keys to be used for record encryption/decryption and
	authentication. These may be explicitly exportable to the		authentication. These may be explicitly exportable to the
	application, traditionally limited to direct export to the record		application, traditionally limited to direct export to the record
	protocol, or inherently non-exportable because the keys must be		protocol, or inherently non-exportable because the keys must be
	used directly in conjunction with the record protocol.		used directly in conjunction with the record protocol.
	* Explicit export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for		* Explicit export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for
	SRTP)		SRTP)
	skipping to change at page 28, line 50 ¶		skipping to change at page 31, line 50 ¶
	The authors would like to thank Bob Bradley, Theresa Enghardt,		The authors would like to thank Bob Bradley, Theresa Enghardt,
	Frederic Jacobs, Mirja Kuehlewind, Yannick Sierra, and Brian Trammell		Frederic Jacobs, Mirja Kuehlewind, Yannick Sierra, and Brian Trammell
	for their input and feedback on earlier versions of this draft.		for their input and feedback on earlier versions of this draft.
	11. Normative References		11. Normative References
	[ALTS] "Application Layer Transport Security", n.d..		[ALTS] "Application Layer Transport Security", n.d..
	[BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d..		[BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d..
			[BlowFish]
			"The Blowfish Encryption Algorithm", n.d..
	[Curve25519]		[Curve25519]
	"Curve25519 - new Diffie-Hellman speed records", n.d..		"Curve25519 - new Diffie-Hellman speed records", n.d..
	[CurveCP] "CurveCP -- Usable security for the Internet", n.d..		[CurveCP] "CurveCP -- Usable security for the Internet", n.d..
	[I-D.ietf-quic-tls]		[I-D.ietf-quic-tls]
	Thomson, M. and S. Turner, "Using Transport Layer Security		Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
	(TLS) to Secure QUIC", draft-ietf-quic-tls-16 (work in		draft-ietf-quic-tls-18 (work in progress), January 2019.
	progress), October 2018.
	[I-D.ietf-quic-transport]		[I-D.ietf-quic-transport]
	Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed		Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
	and Secure Transport", draft-ietf-quic-transport-16 (work		and Secure Transport", draft-ietf-quic-transport-18 (work
	in progress), October 2018.		in progress), January 2019.
	[I-D.ietf-rtcweb-security-arch]		[I-D.ietf-rtcweb-security-arch]
	Rescorla, E., "WebRTC Security Architecture", draft-ietf-		Rescorla, E., "WebRTC Security Architecture", draft-ietf-
	rtcweb-security-arch-16 (work in progress), October 2018.		rtcweb-security-arch-18 (work in progress), February 2019.
	[I-D.ietf-taps-arch]		[I-D.ietf-taps-arch]
	Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,		Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,
	Perkins, C., Tiesel, P., and C. Wood, "An Architecture for		Perkins, C., Tiesel, P., and C. Wood, "An Architecture for
	Transport Services", draft-ietf-taps-arch-02 (work in		Transport Services", draft-ietf-taps-arch-02 (work in
	progress), October 2018.		progress), October 2018.
	[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., and C. Wood, "An		Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An
	Abstract Application Layer Interface to Transport		Abstract Application Layer Interface to Transport
	Services", draft-ietf-taps-interface-02 (work in		Services", draft-ietf-taps-interface-02 (work in
	progress), October 2018.		progress), October 2018.
	[I-D.ietf-tcpinc-tcpcrypt]		[I-D.ietf-tcpinc-tcpcrypt]
	Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,		Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
	Q., and E. Smith, "Cryptographic protection of TCP Streams		Q., and E. Smith, "Cryptographic protection of TCP Streams
	(tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-14 (work in		(tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-15 (work in
	progress), November 2018.		progress), December 2018.
	[I-D.ietf-tcpinc-tcpeno]		[I-D.ietf-tcpinc-tcpeno]
	Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E.		Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E.
	Smith, "TCP-ENO: Encryption Negotiation Option", draft-		Smith, "TCP-ENO: Encryption Negotiation Option", draft-
	ietf-tcpinc-tcpeno-19 (work in progress), June 2018.		ietf-tcpinc-tcpeno-19 (work in progress), June 2018.
	[I-D.ietf-tls-dtls-connection-id]		[I-D.ietf-tls-dtls-connection-id]
	Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom,		Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom,
	"Connection Identifiers for DTLS 1.2", draft-ietf-tls-		"Connection Identifiers for DTLS 1.2", draft-ietf-tls-
	dtls-connection-id-02 (work in progress), October 2018.		dtls-connection-id-02 (work in progress), October 2018.
	[I-D.ietf-tls-dtls13]		[I-D.ietf-tls-dtls13]
	Rescorla, E., Tschofenig, H., and N. Modadugu, "The		Rescorla, E., Tschofenig, H., and N. Modadugu, "The
	Datagram Transport Layer Security (DTLS) Protocol Version		Datagram Transport Layer Security (DTLS) Protocol Version
	1.3", draft-ietf-tls-dtls13-29 (work in progress), October		1.3", draft-ietf-tls-dtls13-30 (work in progress),
	2018.		November 2018.
	[I-D.ietf-tls-record-limit]		[I-D.ietf-tls-record-limit]
	Thomson, M., "Record Size Limit Extension for Transport		Thomson, M., "Record Size Limit Extension for Transport
	Layer Security (TLS)", draft-ietf-tls-record-limit-03		Layer Security (TLS)", draft-ietf-tls-record-limit-03
	(work in progress), May 2018.		(work in progress), May 2018.
	[I-D.ietf-tls-tls13]		[I-D.ietf-tls-tls13]
	Rescorla, E., "The Transport Layer Security (TLS) Protocol		Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", draft-ietf-tls-tls13-28 (work in progress),		Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
	March 2018.		March 2018.
	[MinimalT]		[MinimalT]
	"MinimaLT -- Minimal-latency Networking Through Better		"MinimaLT -- Minimal-latency Networking Through Better
	Security", n.d..		Security", n.d..
	[Noise] "The Noise Protocol Framework", n.d..		[Noise] "The Noise Protocol Framework", n.d..
			[OpenVPN] "OpenVPN cryptographic layer", n.d..
	[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>.
	[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP		[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
	Headers for Low-Speed Serial Links", RFC 2508,		Headers for Low-Speed Serial Links", RFC 2508,
	DOI 10.17487/RFC2508, February 1999, <https://www.rfc-		DOI 10.17487/RFC2508, February 1999,
	editor.org/info/rfc2508>.		<https://www.rfc-editor.org/info/rfc2508>.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002, <https://www.rfc-		DOI 10.17487/RFC3261, June 2002,
	editor.org/info/rfc3261>.		<https://www.rfc-editor.org/info/rfc3261>.
	[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and		[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and
	P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with		P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with
	High Delay, Packet Loss and Reordering", RFC 3545,		High Delay, Packet Loss and Reordering", RFC 3545,
	DOI 10.17487/RFC3545, July 2003, <https://www.rfc-		DOI 10.17487/RFC3545, July 2003,
	editor.org/info/rfc3545>.		<https://www.rfc-editor.org/info/rfc3545>.
	[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>.
	[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.		[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
	Stenberg, "UDP Encapsulation of IPsec ESP Packets",		Stenberg, "UDP Encapsulation of IPsec ESP Packets",
	RFC 3948, DOI 10.17487/RFC3948, January 2005,		RFC 3948, DOI 10.17487/RFC3948, January 2005,
	<https://www.rfc-editor.org/info/rfc3948>.		<https://www.rfc-editor.org/info/rfc3948>.
	[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)		[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
	Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,		Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
	January 2006, <https://www.rfc-editor.org/info/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, <https://www.rfc-		DOI 10.17487/RFC4302, December 2005,
	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>.
	[RFC4474] Peterson, J. and C. Jennings, "Enhancements for		[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
	Authenticated Identity Management in the Session		Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 4474,		Initiation Protocol (SIP)", RFC 4474,
	DOI 10.17487/RFC4474, August 2006, <https://www.rfc-		DOI 10.17487/RFC4474, August 2006,
	editor.org/info/rfc4474>.		<https://www.rfc-editor.org/info/rfc4474>.
	[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,
	<https://www.rfc-editor.org/info/rfc4555>.		<https://www.rfc-editor.org/info/rfc4555>.
	[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, <https://www.rfc-		DOI 10.17487/RFC5246, August 2008,
	editor.org/info/rfc5246>.		<https://www.rfc-editor.org/info/rfc5246>.
	[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange		[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
	Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,		Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
	DOI 10.17487/RFC5723, January 2010, <https://www.rfc-		DOI 10.17487/RFC5723, January 2010,
	editor.org/info/rfc5723>.		<https://www.rfc-editor.org/info/rfc5723>.
	[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework		[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
	for Establishing a Secure Real-time Transport Protocol		for Establishing a Secure Real-time Transport Protocol
	(SRTP) Security Context Using Datagram Transport Layer		(SRTP) Security Context Using Datagram Transport Layer
	Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May		Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
	2010, <https://www.rfc-editor.org/info/rfc5763>.		2010, <https://www.rfc-editor.org/info/rfc5763>.
	[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, <https://www.rfc-		DOI 10.17487/RFC5764, May 2010,
	editor.org/info/rfc5764>.		<https://www.rfc-editor.org/info/rfc5764>.
	[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand		[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
	Key Derivation Function (HKDF)", RFC 5869,		Key Derivation Function (HKDF)", RFC 5869,
	DOI 10.17487/RFC5869, May 2010, <https://www.rfc-		DOI 10.17487/RFC5869, May 2010,
	editor.org/info/rfc5869>.		<https://www.rfc-editor.org/info/rfc5869>.
	[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>.
	[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)		[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
	Extensions: Extension Definitions", RFC 6066,		Extensions: Extension Definitions", RFC 6066,
	DOI 10.17487/RFC6066, January 2011, <https://www.rfc-		DOI 10.17487/RFC6066, January 2011,
	editor.org/info/rfc6066>.		<https://www.rfc-editor.org/info/rfc6066>.
	[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:		[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
	Media Path Key Agreement for Unicast Secure RTP",		Media Path Key Agreement for Unicast Secure RTP",
	RFC 6189, DOI 10.17487/RFC6189, April 2011,		RFC 6189, DOI 10.17487/RFC6189, April 2011,
	<https://www.rfc-editor.org/info/rfc6189>.		<https://www.rfc-editor.org/info/rfc6189>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
	January 2012, <https://www.rfc-editor.org/info/rfc6347>.		January 2012, <https://www.rfc-editor.org/info/rfc6347>.
	skipping to change at page 32, line 51 ¶		skipping to change at page 36, line 8 ¶
	Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,		Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
	July 2014, <https://www.rfc-editor.org/info/rfc7301>.		July 2014, <https://www.rfc-editor.org/info/rfc7301>.
	[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF		[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
	Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,		Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
	<https://www.rfc-editor.org/info/rfc7539>.		<https://www.rfc-editor.org/info/rfc7539>.
	[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,		[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
	Ed., "Services Provided by IETF Transport Protocols and		Ed., "Services Provided by IETF Transport Protocols and
	Congestion Control Mechanisms", RFC 8095,		Congestion Control Mechanisms", RFC 8095,
	DOI 10.17487/RFC8095, March 2017, <https://www.rfc-		DOI 10.17487/RFC8095, March 2017,
	editor.org/info/rfc8095>.		<https://www.rfc-editor.org/info/rfc8095>.
	[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation		[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
	of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,		of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
	August 2017, <https://www.rfc-editor.org/info/rfc8229>.		August 2017, <https://www.rfc-editor.org/info/rfc8229>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	[SIGMA] "SIGMA -- The 'SIGn-and-MAc' Approach to Authenticated		[SIGMA] "SIGMA -- The 'SIGn-and-MAc' Approach to Authenticated
	Diffie-Hellman and Its Use in the IKE-Protocols", n.d..		Diffie-Hellman and Its Use in the IKE-Protocols", n.d..
	[WireGuard]		[WireGuard]
	"WireGuard -- Next Generation Kernel Network Tunnel",		"WireGuard -- Next Generation Kernel Network Tunnel",
	n.d..		n.d..
	Authors' Addresses		Authors' Addresses
			Christopher A. Wood (editor)
			Apple Inc.
			One Apple Park Way
			Cupertino, California 95014
			United States of America
			Email: cawood@apple.com
			Theresa Enghardt
			TU Berlin
			Marchstr. 23
			10587 Berlin
			Germany
			Email: theresa@inet.tu-berlin.de
	Tommy Pauly		Tommy Pauly
	Apple Inc.		Apple Inc.
	One Apple Park Way		One Apple Park Way
	Cupertino, California 95014		Cupertino, California 95014
	United States of America		United States of America
	Email: tpauly@apple.com		Email: tpauly@apple.com
	Colin Perkins		Colin Perkins
	University of Glasgow		University of Glasgow
	School of Computing Science		School of Computing Science
	Glasgow G12 8QQ		Glasgow G12 8QQ
	United Kingdom		United Kingdom
	Email: csp@csperkins.org		Email: csp@csperkins.org
	Kyle Rose		Kyle Rose
	Akamai Technologies, Inc.		Akamai Technologies, Inc.
	skipping to change at page 34, line 4 ¶		skipping to change at line 1708 ¶
	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
	Apple Inc.
	One Apple Park Way
	Cupertino, California 95014
	United States of America
	Email: cawood@apple.com
End of changes. 80 change blocks.
	216 lines changed or deleted		361 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/