<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="true" docName="draft-ietf-taps-transport-security-12" indexInclude="true" ipr="trust200902" number="8922" prepTime="2020-10-21T15:53:15" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security-12" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8922" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Transport Security Survey">A Survey of the Interaction between Security Protocols and Transport Services</title>
    <seriesInfo name="RFC" value="8922" stream="IETF"/>
    <author initials="T." surname="Enghardt" fullname="Theresa Enghardt">
      <organization showOnFrontPage="true">TU Berlin</organization>
      <address>
        <postal>
          <street>Marchstr. 23</street>
          <city>Berlin</city>
          <code>10587</code>
          <country>Germany</country>
        </postal>
        <email>ietf@tenghardt.net</email>
      </address>
    </author>
    <author initials="T." surname="Pauly" fullname="Tommy Pauly">
      <organization showOnFrontPage="true">Apple Inc.</organization>
      <address>
        <postal>
          <street>One Apple Park Way</street>
          <city>Cupertino</city>
          <region>California</region>
          <code>95014</code>
          <country>United States of America</country>
        </postal>
        <email>tpauly@apple.com</email>
      </address>
    </author>
    <author initials="C." surname="Perkins" fullname="Colin Perkins">
      <organization showOnFrontPage="true">University of Glasgow</organization>
      <address>
        <postal>
          <street>School of Computing Science</street>
          <city>Glasgow</city>
          <code>G12 8QQ</code>
          <country>United Kingdom</country>
        </postal>
        <email>csp@csperkins.org</email>
      </address>
    </author>
    <author initials="K." surname="Rose" fullname="Kyle Rose">
      <organization showOnFrontPage="true">Akamai Technologies, Inc.</organization>
      <address>
        <postal>
          <street>150 Broadway</street>
          <city>Cambridge</city>
          <region>MA</region>
          <code>02144</code>
          <country>United States of America</country>
        </postal>
        <email>krose@krose.org</email>
      </address>
    </author>
    <author initials="C." surname="Wood" fullname="Christopher A. Wood">
      <organization showOnFrontPage="true">Cloudflare</organization>
      <address>
        <postal>
          <street>101 Townsend St</street>
          <city>San Francisco</city>
          <country>United States of America</country>
        </postal>
        <email>caw@heapingbits.net</email>
      </address>
    </author>
    <date month="10" year="2020"/>
    <keyword>Transport Protocols</keyword>
    <keyword>Transport Security</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document provides a survey of commonly used or notable network
      security protocols, with a focus on how they interact and integrate with
      applications and transport protocols. Its goal is to supplement efforts
      to define and catalog Transport Services by describing the interfaces
      required to add security protocols. This survey is not limited to
      protocols developed within the scope or context of the IETF, and those
      included represent a superset of features a Transport Services system
      may need to support.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8922" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-goals">Goals</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-non-goals">Non-goals</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-transport-security-protocol">Transport Security Protocol Descriptions</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-application-payload-securit">Application Payload Security Protocols</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.1.2">
                  <li pn="section-toc.1-1.3.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.1.2.1.1"><xref derivedContent="3.1.1" format="counter" sectionFormat="of" target="section-3.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tls">TLS</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.1.2.2.1"><xref derivedContent="3.1.2" format="counter" sectionFormat="of" target="section-3.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dtls">DTLS</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-application-specific-securi">Application-Specific Security Protocols</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.2.2">
                  <li pn="section-toc.1-1.3.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.1.1"><xref derivedContent="3.2.1" format="counter" sectionFormat="of" target="section-3.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-secure-rtp">Secure RTP</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-transport-layer-security-pr">Transport-Layer Security Protocols</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.3.2">
                  <li pn="section-toc.1-1.3.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.1.1"><xref derivedContent="3.3.1" format="counter" sectionFormat="of" target="section-3.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ietf-quic">IETF QUIC</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.2.1"><xref derivedContent="3.3.2" format="counter" sectionFormat="of" target="section-3.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-google-quic">Google QUIC</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.3.1"><xref derivedContent="3.3.3" format="counter" sectionFormat="of" target="section-3.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tcpcrypt">tcpcrypt</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.3.2.4">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.4.1"><xref derivedContent="3.3.4" format="counter" sectionFormat="of" target="section-3.3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-minimalt">MinimaLT</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.3.2.5">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.5.1"><xref derivedContent="3.3.5" format="counter" sectionFormat="of" target="section-3.3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-curvecp">CurveCP</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-packet-security-protocols">Packet Security Protocols</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.4.2">
                  <li pn="section-toc.1-1.3.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.4.2.1.1"><xref derivedContent="3.4.1" format="counter" sectionFormat="of" target="section-3.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ipsec">IPsec</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.4.2.2.1"><xref derivedContent="3.4.2" format="counter" sectionFormat="of" target="section-3.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-wireguard">WireGuard</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.4.2.3">
                    <t indent="0" pn="section-toc.1-1.3.2.4.2.3.1"><xref derivedContent="3.4.3" format="counter" sectionFormat="of" target="section-3.4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-openvpn">OpenVPN</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-transport-dependencies">Transport Dependencies</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reliable-byte-stream-transp">Reliable Byte-Stream Transports</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-unreliable-datagram-transpo">Unreliable Datagram Transports</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-datagram-protocols-with-def">Datagram Protocols with Defined Byte-Stream Mappings</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-transport-specific-dependen">Transport-Specific Dependencies</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-application-interface">Application Interface</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pre-connection-interfaces">Pre-connection Interfaces</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-connection-interfaces">Connection Interfaces</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-post-connection-interfaces">Post-connection Interfaces</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-summary-of-interfaces-expos">Summary of Interfaces Exposed by Protocols</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-considerations">Privacy Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Services and features provided by transport protocols have been
      cataloged in <xref target="RFC8095" format="default" sectionFormat="of" derivedContent="RFC8095"/>. This document
      supplements that work by surveying commonly used and notable network
      security protocols, and identifying the interfaces between these
      protocols and both transport protocols and applications.  It examines
      Transport Layer Security (TLS), Datagram Transport Layer Security
      (DTLS), IETF QUIC, Google QUIC (gQUIC), tcpcrypt, Internet Protocol
      Security (IPsec), Secure Real-time Transport Protocol (SRTP) with DTLS,
      WireGuard, CurveCP, and MinimaLT. For each protocol, this document
      provides a brief description.  Then, it describes the interfaces between
      these protocols and transports in <xref target="transport-interface" format="default" sectionFormat="of" derivedContent="Section 4"/> and the interfaces between these protocols and
      applications in <xref target="application-interface" format="default" sectionFormat="of" derivedContent="Section 5"/>.</t>
      <t indent="0" pn="section-1-2">A Transport Services system exposes an interface for applications to
      access various (secure) transport protocol features.  The security
      protocols included in this survey represent a superset of functionality
      and features a Transport Services system may need to support both
      internally and externally (via an API) for applications <xref target="I-D.ietf-taps-arch" format="default" sectionFormat="of" derivedContent="TAPS-ARCH"/>. Ubiquitous IETF
      protocols such as (D)TLS, as well as non-standard protocols such as
      gQUIC, are included despite overlapping features. As such, this survey
      is not limited to protocols developed within the scope or context of the
      IETF. Outside of this candidate set, protocols that do not offer new
      features are omitted. For example, newer protocols such as WireGuard
      make unique design choices that have implications for and limitations on
      application usage. In contrast, protocols such as secure shell (SSH)
      <xref target="RFC4253" format="default" sectionFormat="of" derivedContent="RFC4253"/>, GRE <xref target="RFC2890" format="default" sectionFormat="of" derivedContent="RFC2890"/>, the Layer 2 Tunneling Protocol (L2TP) <xref target="RFC5641" format="default" sectionFormat="of" derivedContent="RFC5641"/>, and Application Layer Transport
      Security (ALTS) <xref target="ALTS" format="default" sectionFormat="of" derivedContent="ALTS"/> are omitted since they do not provide interfaces
      deemed unique.</t>
      <t indent="0" pn="section-1-3">Authentication-only protocols such as the TCP Authentication Option
      (TCP-AO) <xref target="RFC5925" format="default" sectionFormat="of" derivedContent="RFC5925"/> and the IPsec
      Authentication Header (AH) <xref target="RFC4302" format="default" sectionFormat="of" derivedContent="RFC4302"/> are
      excluded from this survey. TCP-AO adds authentication to long-lived TCP
      connections, e.g., replay protection with per-packet Message
      Authentication Codes. (TCP-AO obsoletes TCP MD5 "signature" options
      specified in <xref target="RFC2385" format="default" sectionFormat="of" derivedContent="RFC2385"/>.) One primary use
      case of TCP-AO is for protecting BGP connections.  Similarly, AH adds
      per-datagram authentication and integrity, along with replay
      protection. Despite these improvements, neither protocol sees general
      use and both lack critical properties important for emergent transport
      security protocols, such as confidentiality and privacy
      protections. Such protocols are thus omitted from this survey.</t>
      <t indent="0" pn="section-1-4">This document only surveys point-to-point protocols; multicast protocols are out of scope.</t>
      <section anchor="goals" numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-goals">Goals</name>
        <t indent="0" pn="section-1.1-1">This survey is intended to help identify the most common interface
        surfaces between security protocols and transport protocols, and
        between security protocols and applications.</t>
        <t indent="0" pn="section-1.1-2">One of the goals of the Transport Services effort is to define a
        common interface for using transport protocols that allows software
        using transport protocols to easily adopt new protocols that provide
        similar feature sets. The survey of the dependencies security
        protocols have upon transport protocols can guide implementations in
        determining which transport protocols are appropriate to be able to
        use beneath a given security protocol. For example, a security
        protocol that expects to run over a reliable stream of bytes, like
        TLS, restricts the set of transport protocols that can be used to
        those that offer a reliable stream of bytes.</t>
        <t indent="0" pn="section-1.1-3">Defining the common interfaces that security protocols provide to
        applications also allows interfaces to be designed in a way that
        common functionality can use the same APIs. For example, many security
        protocols that provide authentication let the application be involved
        in peer identity validation. Any interface to use a secure transport
        protocol stack thus needs to allow applications to perform this action
        during connection establishment.</t>
      </section>
      <section anchor="non-goals" numbered="true" toc="include" removeInRFC="false" pn="section-1.2">
        <name slugifiedName="name-non-goals">Non-goals</name>
        <t indent="0" pn="section-1.2-1">While this survey provides similar analysis to that which was performed for transport protocols in <xref target="RFC8095" format="default" sectionFormat="of" derivedContent="RFC8095"/>,
it is important to distinguish that the use of security protocols requires more consideration.</t>
        <t indent="0" pn="section-1.2-2">It is not a goal to allow software implementations to automatically
        switch between different security protocols, even where their
        interfaces to transport and applications are equivalent. Even between
        versions, security protocols have subtly different guarantees and
        vulnerabilities. Thus, any implementation needs to only use the set of
        protocols and algorithms that are requested by applications or by a
        system policy.</t>
        <t indent="0" pn="section-1.2-3">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.</t>
        <t indent="0" pn="section-1.2-4">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.</t>
        <t indent="0" pn="section-1.2-5">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.</t>
      </section>
    </section>
    <section anchor="terminology" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">The following terms are used throughout this document to describe the
      roles and interactions of transport security protocols (some of which
      are also defined in <xref target="RFC8095" format="default" sectionFormat="of" derivedContent="RFC8095"/>):</t>
      <dl indent="3" newline="false" spacing="normal" pn="section-2-2">
        <dt pn="section-2-2.1">Transport Feature:</dt>
        <dd pn="section-2-2.2">a specific end-to-end feature that the
        transport layer provides to an application.  Examples include
        confidentiality, reliable delivery, ordered delivery, and
        message-versus-stream orientation.</dd>
        <dt pn="section-2-2.3">Transport Service:</dt>
        <dd pn="section-2-2.4">a set of Transport Features, without an
        association to any given framing protocol, that provides
        functionality to an application.</dd>
        <dt pn="section-2-2.5">Transport Services system:</dt>
        <dd pn="section-2-2.6">a software component that exposes an
        interface to different Transport Services to an application.</dd>
        <dt pn="section-2-2.7">Transport Protocol:</dt>
        <dd pn="section-2-2.8">an implementation that provides one or more
        different Transport Services using a specific framing and header
        format on the wire. A Transport Protocol services an application,
        whether directly or in conjunction with a security protocol.</dd>
        <dt pn="section-2-2.9">Application:</dt>
        <dd pn="section-2-2.10">an entity that uses a transport protocol for
        end-to-end delivery of data across the network.  This may also be an
        upper layer protocol or tunnel encapsulation.</dd>
        <dt pn="section-2-2.11">Security Protocol:</dt>
        <dd pn="section-2-2.12">a defined network protocol that implements one
        or more security features, such as authentication, encryption, key
        generation, session resumption, and privacy. Security protocols may be
        used alongside transport protocols, and in combination with other
        security protocols when appropriate.</dd>
        <dt pn="section-2-2.13">Handshake Protocol:</dt>
        <dd pn="section-2-2.14">a protocol that enables peers to validate each
        other and to securely establish shared cryptographic context.</dd>
        <dt pn="section-2-2.15">Record:</dt>
        <dd pn="section-2-2.16">framed protocol messages.</dd>
        <dt pn="section-2-2.17">Record Protocol:</dt>
        <dd pn="section-2-2.18">a security protocol that allows data to be
        divided into manageable blocks and protected using shared
        cryptographic context.</dd>
        <dt pn="section-2-2.19">Session:</dt>
        <dd pn="section-2-2.20">an ephemeral security association between
        applications.</dd>
        <dt pn="section-2-2.21">Connection:</dt>
        <dd pn="section-2-2.22">the shared state of two or more endpoints that
        persists across messages that are transmitted between these
        endpoints. A connection is a transient participant of a session, and a
        session generally lasts between connection instances.</dd>
        <dt pn="section-2-2.23">Peer:</dt>
        <dd pn="section-2-2.24">an endpoint application party to a session.</dd>
        <dt pn="section-2-2.25">Client:</dt>
        <dd pn="section-2-2.26">the peer responsible for initiating a session.</dd>
        <dt pn="section-2-2.27">Server:</dt>
        <dd pn="section-2-2.28">the peer responsible for responding to a session initiation.</dd>
      </dl>
    </section>
    <section anchor="transport-security-protocol-descriptions" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-transport-security-protocol">Transport Security Protocol Descriptions</name>
      <t indent="0" pn="section-3-1">This section contains brief transport and security descriptions of
      various security protocols currently used to protect data being sent
      over a network. These protocols are grouped based on where in the
      protocol stack they are implemented, which influences which parts of a
      packet they protect: Generic application payload, application payload
      for specific application-layer protocols, both application payload and
      transport headers, or entire IP packets.</t>
      <t indent="0" pn="section-3-2">Note that not all security protocols can be easily categorized, e.g.,
      as some protocols can be used in different ways or in combination with
      other protocols.  One major reason for this is that channel security
      protocols often consist of two components:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-3">
        <li pn="section-3-3.1">A handshake protocol, which is responsible for negotiating parameters, authenticating the
endpoints, and establishing shared keys.</li>
        <li pn="section-3-3.2">A record protocol, which is used to encrypt traffic using keys and parameters provided by the
handshake protocol.</li>
      </ul>
      <t indent="0" pn="section-3-4">For some protocols, such as tcpcrypt, these two components are
      tightly integrated. In contrast, for IPsec, these components are
      implemented in separate protocols: AH and the Encapsulating Security Payload
      (ESP) are record protocols, which can use keys supplied by the handshake
      protocol Internet Key Exchange Protocol Version 2 (IKEv2), by other
      handshake protocols, or by manual configuration. Moreover, some
      protocols can be used in different ways: While the base TLS protocol as
      defined in <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/> has an integrated
      handshake and record protocol, TLS or DTLS can also be used to negotiate
      keys for other protocols, as in DTLS-SRTP, or the handshake protocol can
      be used with a separate record layer, as in QUIC <xref target="I-D.ietf-quic-transport" format="default" sectionFormat="of" derivedContent="QUIC-TRANSPORT"/>.</t>
      <section anchor="application-payload-security-protocols" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-application-payload-securit">Application Payload Security Protocols</name>
        <t indent="0" pn="section-3.1-1">The following protocols provide security that protects application payloads sent over a
transport. They do not specifically protect any headers used for transport-layer functionality.</t>
        <section anchor="tls" numbered="true" toc="include" removeInRFC="false" pn="section-3.1.1">
          <name slugifiedName="name-tls">TLS</name>
          <t indent="0" pn="section-3.1.1-1">TLS (Transport Layer Security) <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/> is a common protocol used to establish a secure
          session between two endpoints. Communication over this session
          prevents "eavesdropping, tampering, and message forgery." TLS
          consists of a tightly coupled handshake and record protocol. The
          handshake protocol is used to authenticate peers, negotiate protocol
          options such as cryptographic algorithms, and derive
          session-specific keying material. The record protocol is used to
          marshal and, once the handshake has sufficiently progressed,
          encrypt data from one peer to the other. This data may contain
          handshake messages or raw application data.</t>
        </section>
        <section anchor="dtls" numbered="true" toc="include" removeInRFC="false" pn="section-3.1.2">
          <name slugifiedName="name-dtls">DTLS</name>
          <t indent="0" pn="section-3.1.2-1">DTLS (Datagram Transport Layer Security) <xref target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/> <xref target="I-D.ietf-tls-dtls13" format="default" sectionFormat="of" derivedContent="DTLS-1.3"/> is based on TLS, but differs in that it is
          designed to run over unreliable datagram protocols like UDP instead
          of TCP.  DTLS modifies the protocol to make sure it can still
          provide equivalent security guarantees to TLS with the exception of
          order protection/non-replayability. DTLS was designed to be as
          similar to TLS as possible, so this document assumes that all
          properties from TLS are carried over except where specified.</t>
        </section>
      </section>
      <section anchor="application-specific-security-protocols" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-application-specific-securi">Application-Specific Security Protocols</name>
        <t indent="0" pn="section-3.2-1">The following protocols provide application-specific security by protecting
application payloads used for specific use cases. Unlike the protocols above,
these are not intended for generic application use.</t>
        <section anchor="secure-rtp" numbered="true" toc="include" removeInRFC="false" pn="section-3.2.1">
          <name slugifiedName="name-secure-rtp">Secure RTP</name>
          <t indent="0" pn="section-3.2.1-1">Secure RTP (SRTP) is a profile for RTP that provides confidentiality,
message authentication, and replay protection for RTP data packets
and RTP control protocol (RTCP) packets <xref target="RFC3711" format="default" sectionFormat="of" derivedContent="RFC3711"/>.
SRTP provides a record layer only, and requires a separate handshake
protocol to provide key agreement and identity management.</t>
          <t indent="0" pn="section-3.2.1-2">The commonly used handshake protocol for SRTP is DTLS, in the form of
DTLS-SRTP <xref target="RFC5764" format="default" sectionFormat="of" derivedContent="RFC5764"/>.  This is an extension to DTLS that negotiates
the use of SRTP as the record layer and describes how to export keys
for use with SRTP.</t>
          <t indent="0" pn="section-3.2.1-3">ZRTP <xref target="RFC6189" format="default" sectionFormat="of" derivedContent="RFC6189"/> is an alternative key agreement and identity management
protocol for SRTP.  ZRTP Key agreement is performed using a Diffie-Hellman
key exchange that runs on the media path. This generates a shared secret
that is then used to generate the master key and salt for SRTP.</t>
        </section>
      </section>
      <section anchor="transport-layer-security-protocols" numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-transport-layer-security-pr">Transport-Layer Security Protocols</name>
        <t indent="0" pn="section-3.3-1">The following security protocols provide protection for both application payloads and
headers that are used for Transport Services.</t>
        <section anchor="quic" numbered="true" toc="include" removeInRFC="false" pn="section-3.3.1">
          <name slugifiedName="name-ietf-quic">IETF QUIC</name>
          <t indent="0" pn="section-3.3.1-1">QUIC is a new standards-track transport protocol that runs over UDP, loosely based on Google's
original proprietary gQUIC protocol <xref target="I-D.ietf-quic-transport" format="default" sectionFormat="of" derivedContent="QUIC-TRANSPORT"/> (See <xref target="gquic" format="default" sectionFormat="of" derivedContent="Section 3.3.2"/> for more details).
The QUIC transport layer itself provides support for data confidentiality and integrity. This requires
keys to be derived with a separate handshake protocol. A mapping for QUIC of TLS 1.3 <xref target="I-D.ietf-quic-tls" format="default" sectionFormat="of" derivedContent="QUIC-TLS"/>
has been specified to provide this handshake.</t>
        </section>
        <section anchor="gquic" numbered="true" toc="include" removeInRFC="false" pn="section-3.3.2">
          <name slugifiedName="name-google-quic">Google QUIC</name>
          <t indent="0" pn="section-3.3.2-1">Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol
          designed and deployed by Google following experience from deploying
          SPDY, the proprietary predecessor to HTTP/2.  gQUIC was originally
          known as "QUIC"; this document uses gQUIC to unambiguously
          distinguish it from the standards-track IETF QUIC. The proprietary
          technical forebear of IETF QUIC, gQUIC was originally designed with
          tightly integrated security and application data transport
          protocols.</t>
        </section>
        <section anchor="tcpcrypt" numbered="true" toc="include" removeInRFC="false" pn="section-3.3.3">
          <name slugifiedName="name-tcpcrypt">tcpcrypt</name>
          <t indent="0" pn="section-3.3.3-1">Tcpcrypt <xref target="RFC8548" format="default" sectionFormat="of" derivedContent="RFC8548"/> is a lightweight extension to the TCP protocol for opportunistic encryption. Applications may
use tcpcrypt's unique session ID for further application-level authentication. Absent this authentication,
tcpcrypt is vulnerable to active attacks.</t>
        </section>
        <section anchor="minimalt" numbered="true" toc="include" removeInRFC="false" pn="section-3.3.4">
          <name slugifiedName="name-minimalt">MinimaLT</name>
          <t indent="0" pn="section-3.3.4-1">MinimaLT <xref target="MinimaLT" format="default" sectionFormat="of" derivedContent="MinimaLT"/> is a UDP-based transport security protocol designed to offer confidentiality,
mutual authentication, DoS prevention, and connection mobility. 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.</t>
        </section>
        <section anchor="curvecp" numbered="true" toc="include" removeInRFC="false" pn="section-3.3.5">
          <name slugifiedName="name-curvecp">CurveCP</name>
          <t indent="0" pn="section-3.3.5-1">CurveCP <xref target="CurveCP" format="default" sectionFormat="of" derivedContent="CurveCP"/> is a UDP-based
          transport security that, unlike many other security protocols, is
          based entirely upon public key algorithms. CurveCP provides its own
          reliability for application data as part of its protocol.</t>
        </section>
      </section>
      <section anchor="packet-security-protocols" numbered="true" toc="include" removeInRFC="false" pn="section-3.4">
        <name slugifiedName="name-packet-security-protocols">Packet Security Protocols</name>
        <t indent="0" pn="section-3.4-1">The following protocols provide protection for IP packets. These
        are generally used as tunnels, such as for Virtual Private Networks
        (VPNs). Often, applications will not interact directly with these
        protocols. However, applications that implement tunnels will interact
        directly with these protocols.</t>
        <section anchor="ipsec" numbered="true" toc="include" removeInRFC="false" pn="section-3.4.1">
          <name slugifiedName="name-ipsec">IPsec</name>
          <t indent="0" pn="section-3.4.1-1">IKEv2 <xref target="RFC7296" format="default" sectionFormat="of" derivedContent="RFC7296"/> and ESP <xref target="RFC4303" format="default" sectionFormat="of" derivedContent="RFC4303"/> together form the modern IPsec
          protocol suite that encrypts and authenticates IP packets, either
          for creating tunnels (tunnel-mode) or for direct transport
          connections (transport-mode). This suite of protocols separates out
          the key generation protocol (IKEv2) from the transport encryption
          protocol (ESP). Each protocol can be used independently, but this
          document considers them together, since that is the most common
          pattern.</t>
        </section>
        <section anchor="wireguard" numbered="true" toc="include" removeInRFC="false" pn="section-3.4.2">
          <name slugifiedName="name-wireguard">WireGuard</name>
          <t indent="0" pn="section-3.4.2-1">WireGuard <xref target="WireGuard" format="default" sectionFormat="of" derivedContent="WireGuard"/> is an IP-layer protocol designed as an alternative to IPsec
for certain use cases. It uses UDP to encapsulate IP datagrams between peers.
Unlike most transport security protocols, which rely on Public Key Infrastructure (PKI)
for peer authentication, WireGuard authenticates peers using pre-shared public keys
delivered out of band, each of which is bound to one or more IP addresses.
Moreover, as a protocol suited for VPNs, WireGuard offers no extensibility, negotiation,
or cryptographic agility.</t>
        </section>
        <section anchor="openvpn" numbered="true" toc="include" removeInRFC="false" pn="section-3.4.3">
          <name slugifiedName="name-openvpn">OpenVPN</name>
          <t indent="0" pn="section-3.4.3-1">OpenVPN <xref target="OpenVPN" format="default" sectionFormat="of" derivedContent="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 either UDP or TCP.
For key establishment, OpenVPN can either use TLS as a handshake protocol or use pre-shared keys.</t>
        </section>
      </section>
    </section>
    <section anchor="transport-interface" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-transport-dependencies">Transport Dependencies</name>
      <t indent="0" pn="section-4-1">Across the different security protocols listed above, the primary dependency on transport
protocols is the presentation of data: either an unbounded stream of bytes, or framed
messages. Within protocols that rely on the transport for message framing, most are
built to run over transports that inherently provide framing, like UDP, but some also define
how their messages can be framed over byte-stream transports.</t>
      <section anchor="reliable-byte-stream-transports" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-reliable-byte-stream-transp">Reliable Byte-Stream Transports</name>
        <t indent="0" pn="section-4.1-1">The following protocols all depend upon running on a transport protocol that provides
a reliable, in-order stream of bytes. This is typically TCP.</t>
        <t indent="0" pn="section-4.1-2">Application Payload Security Protocols:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-3">
          <li pn="section-4.1-3.1">TLS</li>
        </ul>
        <t indent="0" pn="section-4.1-4">Transport-Layer Security Protocols:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-5">
          <li pn="section-4.1-5.1">tcpcrypt</li>
        </ul>
      </section>
      <section anchor="unreliable-datagram-transports" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-unreliable-datagram-transpo">Unreliable Datagram Transports</name>
        <t indent="0" pn="section-4.2-1">The following protocols all depend on the transport protocol to provide message framing
to encapsulate their data. These protocols are built to run using UDP, and thus do not
have any requirement for reliability. Running these protocols over a protocol that
does provide reliability will not break functionality but may lead to multiple layers
of reliability if the security protocol is encapsulating other transport protocol traffic.</t>
        <t indent="0" pn="section-4.2-2">Application Payload Security Protocols:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2-3">
          <li pn="section-4.2-3.1">DTLS</li>
          <li pn="section-4.2-3.2">ZRTP</li>
          <li pn="section-4.2-3.3">SRTP</li>
        </ul>
        <t indent="0" pn="section-4.2-4">Transport-Layer Security Protocols:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2-5">
          <li pn="section-4.2-5.1">QUIC</li>
          <li pn="section-4.2-5.2">MinimaLT</li>
          <li pn="section-4.2-5.3">CurveCP</li>
        </ul>
        <t indent="0" pn="section-4.2-6">Packet Security Protocols:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2-7">
          <li pn="section-4.2-7.1">IPsec</li>
          <li pn="section-4.2-7.2">WireGuard</li>
          <li pn="section-4.2-7.3">OpenVPN</li>
        </ul>
        <section anchor="datagram-protocols-with-defined-byte-stream-mappings" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.1">
          <name slugifiedName="name-datagram-protocols-with-def">Datagram Protocols with Defined Byte-Stream Mappings</name>
          <t indent="0" pn="section-4.2.1-1">Of the protocols listed above that depend on the transport for message framing, some
do have well-defined mappings for sending their messages over byte-stream transports
like TCP.</t>
          <t indent="0" pn="section-4.2.1-2">Application Payload Security Protocols:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.1-3">
            <li pn="section-4.2.1-3.1">DTLS when used as a handshake protocol for SRTP <xref target="RFC7850" format="default" sectionFormat="of" derivedContent="RFC7850"/></li>
            <li pn="section-4.2.1-3.2">ZRTP <xref target="RFC6189" format="default" sectionFormat="of" derivedContent="RFC6189"/></li>
            <li pn="section-4.2.1-3.3">SRTP <xref target="RFC4571" format="default" sectionFormat="of" derivedContent="RFC4571"/><xref target="RFC3711" format="default" sectionFormat="of" derivedContent="RFC3711"/></li>
          </ul>
          <t indent="0" pn="section-4.2.1-4">Packet Security Protocols:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.1-5">
            <li pn="section-4.2.1-5.1">IPsec <xref target="RFC8229" format="default" sectionFormat="of" derivedContent="RFC8229"/></li>
          </ul>
        </section>
      </section>
      <section anchor="transport-specific-dependencies" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-transport-specific-dependen">Transport-Specific Dependencies</name>
        <t indent="0" pn="section-4.3-1">One protocol surveyed, tcpcrypt, has a direct dependency on a
        feature in the transport that is needed for its
        functionality. Specifically, tcpcrypt is designed to run on top of
        TCP and uses the TCP Encryption Negotiation Option (TCP-ENO) <xref target="RFC8547" format="default" sectionFormat="of" derivedContent="RFC8547"/> to negotiate its protocol
        support.</t>
        <t indent="0" pn="section-4.3-2">QUIC, CurveCP, and MinimaLT provide both transport functionality and security functionality. They
depend on running over a framed protocol like UDP, but they add their own layers of
reliability and other Transport Services. Thus, an application that uses one of these protocols
cannot decouple the security from transport functionality.</t>
      </section>
    </section>
    <section anchor="application-interface" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-application-interface">Application Interface</name>
      <t indent="0" pn="section-5-1">This section describes the interface exposed by the security protocols described above.
We partition these interfaces into
pre-connection (configuration), connection, and post-connection interfaces, following
conventions in <xref target="I-D.ietf-taps-interface" format="default" sectionFormat="of" derivedContent="TAPS-INTERFACE"/> and <xref target="I-D.ietf-taps-arch" format="default" sectionFormat="of" derivedContent="TAPS-ARCH"/>.</t>
      <t indent="0" pn="section-5-2">Note that not all protocols support each interface.
The table in <xref target="interface-protocols-table" format="default" sectionFormat="of" derivedContent="Section 5.4"/> summarizes which protocol exposes which of the interfaces.
In the following sections, we provide abbreviations of the interface names to use in the summary table.</t>
      <section anchor="pre-connection-interfaces" numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-pre-connection-interfaces">Pre-connection Interfaces</name>
        <t indent="0" pn="section-5.1-1">Configuration interfaces are used to configure the security protocols before a
handshake begins or keys are negotiated.</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-5.1-2">
          <dt pn="section-5.1-2.1">Identities and Private Keys (IPK):</dt>
          <dd pn="section-5.1-2.2">
            <t indent="0" pn="section-5.1-2.2.1">The application can provide its identity, credentials (e.g.,
	  certificates), and private keys, or mechanisms to access these, to
	  the security protocol to use during handshakes.
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-2.2.2">
              <li pn="section-5.1-2.2.2.1">TLS</li>
              <li pn="section-5.1-2.2.2.2">DTLS</li>
              <li pn="section-5.1-2.2.2.3">ZRTP</li>
              <li pn="section-5.1-2.2.2.4">QUIC</li>
              <li pn="section-5.1-2.2.2.5">MinimaLT</li>
              <li pn="section-5.1-2.2.2.6">CurveCP</li>
              <li pn="section-5.1-2.2.2.7">IPsec</li>
              <li pn="section-5.1-2.2.2.8">WireGuard</li>
              <li pn="section-5.1-2.2.2.9">OpenVPN</li>
            </ul>
          </dd>
          <dt pn="section-5.1-2.3">Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) (ALG):</dt>
          <dd pn="section-5.1-2.4">
            <t indent="0" pn="section-5.1-2.4.1">
The application can choose the algorithms that are supported for key exchange,
signatures, and ciphersuites.
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-2.4.2">
              <li pn="section-5.1-2.4.2.1">TLS</li>
              <li pn="section-5.1-2.4.2.2">DTLS</li>
              <li pn="section-5.1-2.4.2.3">ZRTP</li>
              <li pn="section-5.1-2.4.2.4">QUIC</li>
              <li pn="section-5.1-2.4.2.5">tcpcrypt</li>
              <li pn="section-5.1-2.4.2.6">MinimaLT</li>
              <li pn="section-5.1-2.4.2.7">IPsec</li>
              <li pn="section-5.1-2.4.2.8">OpenVPN</li>
            </ul>
          </dd>
          <dt pn="section-5.1-2.5">Extensions (EXT):</dt>
          <dd pn="section-5.1-2.6">
            <t indent="0" pn="section-5.1-2.6.1">
The application enables or configures extensions that are to be negotiated by
the security protocol, such as Application-Layer Protocol Negotiation (ALPN) <xref target="RFC7301" format="default" sectionFormat="of" derivedContent="RFC7301"/>.
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-2.6.2">
              <li pn="section-5.1-2.6.2.1">TLS</li>
              <li pn="section-5.1-2.6.2.2">DTLS</li>
              <li pn="section-5.1-2.6.2.3">QUIC</li>
            </ul>
          </dd>
          <dt pn="section-5.1-2.7">Session Cache Management (CM):</dt>
          <dd pn="section-5.1-2.8">
            <t indent="0" pn="section-5.1-2.8.1">The application provides the
            ability to save and retrieve session state (such as tickets,
            keying material, and server parameters) that may be used to resume
            the security session.
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-2.8.2">
              <li pn="section-5.1-2.8.2.1">TLS</li>
              <li pn="section-5.1-2.8.2.2">DTLS</li>
              <li pn="section-5.1-2.8.2.3">ZRTP</li>
              <li pn="section-5.1-2.8.2.4">QUIC</li>
              <li pn="section-5.1-2.8.2.5">tcpcrypt</li>
              <li pn="section-5.1-2.8.2.6">MinimaLT</li>
            </ul>
          </dd>
          <dt pn="section-5.1-2.9">Authentication Delegation (AD):</dt>
          <dd pn="section-5.1-2.10">
            <t indent="0" pn="section-5.1-2.10.1">
The application provides access to a separate module that will provide authentication,
using the Extensible Authentication Protocol (EAP) <xref target="RFC3748" format="default" sectionFormat="of" derivedContent="RFC3748"/> for example.
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-2.10.2">
              <li pn="section-5.1-2.10.2.1">IPsec</li>
              <li pn="section-5.1-2.10.2.2">tcpcrypt</li>
            </ul>
          </dd>
          <dt pn="section-5.1-2.11">Pre-Shared Key Import (PSKI):</dt>
          <dd pn="section-5.1-2.12">
            <t indent="0" pn="section-5.1-2.12.1">
Either the handshake protocol or the application directly can supply pre-shared keys for use
in encrypting (and authenticating) communication with a peer.
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-2.12.2">
              <li pn="section-5.1-2.12.2.1">TLS</li>
              <li pn="section-5.1-2.12.2.2">DTLS</li>
              <li pn="section-5.1-2.12.2.3">ZRTP</li>
              <li pn="section-5.1-2.12.2.4">QUIC</li>
              <li pn="section-5.1-2.12.2.5">tcpcrypt</li>
              <li pn="section-5.1-2.12.2.6">MinimaLT</li>
              <li pn="section-5.1-2.12.2.7">IPsec</li>
              <li pn="section-5.1-2.12.2.8">WireGuard</li>
              <li pn="section-5.1-2.12.2.9">OpenVPN</li>
            </ul>
          </dd>
        </dl>
      </section>
      <section anchor="connection-interfaces" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-connection-interfaces">Connection Interfaces</name>
        <dl spacing="normal" indent="3" newline="false" pn="section-5.2-1">
          <dt pn="section-5.2-1.1">Identity Validation (IV):</dt>
          <dd pn="section-5.2-1.2">
            <t indent="0" pn="section-5.2-1.2.1">
During a handshake, the security protocol will conduct identity validation of the peer.
This can offload validation or occur transparently to the application.
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.2-1.2.2">
              <li pn="section-5.2-1.2.2.1">TLS</li>
              <li pn="section-5.2-1.2.2.2">DTLS</li>
              <li pn="section-5.2-1.2.2.3">ZRTP</li>
              <li pn="section-5.2-1.2.2.4">QUIC</li>
              <li pn="section-5.2-1.2.2.5">MinimaLT</li>
              <li pn="section-5.2-1.2.2.6">CurveCP</li>
              <li pn="section-5.2-1.2.2.7">IPsec</li>
              <li pn="section-5.2-1.2.2.8">WireGuard</li>
              <li pn="section-5.2-1.2.2.9">OpenVPN</li>
            </ul>
          </dd>
          <dt pn="section-5.2-1.3">Source Address Validation (SAV):</dt>
          <dd pn="section-5.2-1.4">
            <t indent="0" pn="section-5.2-1.4.1">
The handshake protocol may interact with the transport protocol or application to
validate the address of the remote peer that has sent data. This involves sending a cookie
exchange to avoid DoS attacks. (This list omits protocols that depend on TCP and therefore
implicitly perform SAV.)
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.2-1.4.2">
              <li pn="section-5.2-1.4.2.1">DTLS</li>
              <li pn="section-5.2-1.4.2.2">QUIC</li>
              <li pn="section-5.2-1.4.2.3">IPsec</li>
              <li pn="section-5.2-1.4.2.4">WireGuard</li>
            </ul>
          </dd>
        </dl>
      </section>
      <section anchor="post-connection-interfaces" numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-post-connection-interfaces">Post-connection Interfaces</name>
        <dl spacing="normal" indent="3" newline="false" pn="section-5.3-1">
          <dt pn="section-5.3-1.1">Connection Termination (CT):</dt>
          <dd pn="section-5.3-1.2">
            <t indent="0" pn="section-5.3-1.2.1">
The security protocol may be instructed to tear down its connection and session information.
This is needed by some protocols, e.g., to prevent application data truncation attacks in
which an attacker terminates an underlying insecure connection-oriented protocol to terminate
the session.
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.3-1.2.2">
              <li pn="section-5.3-1.2.2.1">TLS</li>
              <li pn="section-5.3-1.2.2.2">DTLS</li>
              <li pn="section-5.3-1.2.2.3">ZRTP</li>
              <li pn="section-5.3-1.2.2.4">QUIC</li>
              <li pn="section-5.3-1.2.2.5">tcpcrypt</li>
              <li pn="section-5.3-1.2.2.6">MinimaLT</li>
              <li pn="section-5.3-1.2.2.7">IPsec</li>
              <li pn="section-5.3-1.2.2.8">OpenVPN</li>
            </ul>
          </dd>
          <dt pn="section-5.3-1.3">Key Update (KU):</dt>
          <dd pn="section-5.3-1.4">
            <t indent="0" pn="section-5.3-1.4.1">
The handshake protocol may be instructed to update its keying material, either
by the application directly or by the record protocol sending a key expiration event.
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.3-1.4.2">
              <li pn="section-5.3-1.4.2.1">TLS</li>
              <li pn="section-5.3-1.4.2.2">DTLS</li>
              <li pn="section-5.3-1.4.2.3">QUIC</li>
              <li pn="section-5.3-1.4.2.4">tcpcrypt</li>
              <li pn="section-5.3-1.4.2.5">MinimaLT</li>
              <li pn="section-5.3-1.4.2.6">IPsec</li>
            </ul>
          </dd>
          <dt pn="section-5.3-1.5">Shared Secret Key Export (SSKE):</dt>
          <dd pn="section-5.3-1.6">
            <t indent="0" pn="section-5.3-1.6.1">
The handshake protocol may provide an interface for producing shared secrets for application-specific uses.
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.3-1.6.2">
              <li pn="section-5.3-1.6.2.1">TLS</li>
              <li pn="section-5.3-1.6.2.2">DTLS</li>
              <li pn="section-5.3-1.6.2.3">tcpcrypt</li>
              <li pn="section-5.3-1.6.2.4">IPsec</li>
              <li pn="section-5.3-1.6.2.5">OpenVPN</li>
              <li pn="section-5.3-1.6.2.6">MinimaLT</li>
            </ul>
          </dd>
          <dt pn="section-5.3-1.7">Key Expiration (KE):</dt>
          <dd pn="section-5.3-1.8">
            <t indent="0" pn="section-5.3-1.8.1">The record protocol can signal that its
            keys are expiring due to reaching a time-based deadline or a
            use-based deadline (number of bytes that have been encrypted with
            the key). This interaction is often limited to signaling between
            the record layer and the handshake layer.
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.3-1.8.2">
              <li pn="section-5.3-1.8.2.1">IPsec</li>
            </ul>
          </dd>
          <dt pn="section-5.3-1.9">Mobility Events (ME):</dt>
          <dd pn="section-5.3-1.10">
            <t indent="0" pn="section-5.3-1.10.1"> The record protocol can be signaled that
it is being migrated to another transport or interface due to connection
mobility, which may reset address and state validation and induce state
changes such as use of a new Connection Identifier (CID).
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.3-1.10.2">
              <li pn="section-5.3-1.10.2.1">DTLS (version 1.3 only <xref target="I-D.ietf-tls-dtls13" format="default" sectionFormat="of" derivedContent="DTLS-1.3"/>)</li>
              <li pn="section-5.3-1.10.2.2">QUIC</li>
              <li pn="section-5.3-1.10.2.3">MinimaLT</li>
              <li pn="section-5.3-1.10.2.4">CurveCP</li>
              <li pn="section-5.3-1.10.2.5">IPsec <xref target="RFC4555" format="default" sectionFormat="of" derivedContent="RFC4555"/></li>
              <li pn="section-5.3-1.10.2.6">WireGuard</li>
            </ul>
          </dd>
        </dl>
      </section>
      <section anchor="interface-protocols-table" numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-summary-of-interfaces-expos">Summary of Interfaces Exposed by Protocols</name>
        <t indent="0" pn="section-5.4-1">The following table summarizes which protocol exposes which interface.</t>
        <table align="center" pn="table-1">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Protocol</th>
              <th align="center" colspan="1" rowspan="1">IPK</th>
              <th align="center" colspan="1" rowspan="1">ALG</th>
              <th align="center" colspan="1" rowspan="1">EXT</th>
              <th align="center" colspan="1" rowspan="1">CM</th>
              <th align="center" colspan="1" rowspan="1">AD</th>
              <th align="center" colspan="1" rowspan="1">PSKI</th>
              <th align="center" colspan="1" rowspan="1">IV</th>
              <th align="center" colspan="1" rowspan="1">SAV</th>
              <th align="center" colspan="1" rowspan="1">CT</th>
              <th align="center" colspan="1" rowspan="1">KU</th>
              <th align="center" colspan="1" rowspan="1">SSKE</th>
              <th align="center" colspan="1" rowspan="1">KE</th>
              <th align="center" colspan="1" rowspan="1">ME</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">TLS</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">DTLS</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">ZRTP</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">QUIC</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">tcpcrypt</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">MinimaLT</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">CurveCP</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">IPsec</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">WireGuard</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">OpenVPN</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1">x</td>
              <td align="center" colspan="1" rowspan="1"> </td>
              <td align="center" colspan="1" rowspan="1"> </td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-5.4-3">x = Interface is exposed<br/> 
(blank) = Interface is not exposed</t>
      </section>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-6-1">This document has no IANA actions.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">This document summarizes existing transport security protocols and their interfaces.
It does not propose changes to or recommend usage of reference protocols. Moreover,
no claims of security and privacy properties beyond those guaranteed by the protocols
discussed are made. For example, metadata leakage via timing side channels and traffic
analysis may compromise any protocol discussed in this survey. Applications using
Security Interfaces should take such limitations into consideration when using a particular
protocol implementation.</t>
    </section>
    <section anchor="privacy-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
      <t indent="0" pn="section-8-1">Analysis of how features improve or degrade privacy is intentionally omitted from this survey.
All security protocols surveyed generally improve privacy by using encryption to reduce information
leakage. However, varying amounts of metadata remain in the clear across each
protocol. For example, client and server certificates are sent in cleartext in TLS
1.2 <xref target="RFC5246" format="default" sectionFormat="of" derivedContent="RFC5246"/>, whereas they are encrypted in TLS 1.3 <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>. A survey of privacy
features, or lack thereof, for various security protocols could be addressed in a
separate document.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-taps-arch" to="TAPS-ARCH"/>
    <displayreference target="I-D.ietf-quic-transport" to="QUIC-TRANSPORT"/>
    <displayreference target="I-D.ietf-tls-dtls13" to="DTLS-1.3"/>
    <displayreference target="I-D.ietf-quic-tls" to="QUIC-TLS"/>
    <displayreference target="I-D.ietf-taps-interface" to="TAPS-INTERFACE"/>
    <references pn="section-9">
      <name slugifiedName="name-informative-references">Informative References</name>
      <reference anchor="ALTS" target="https://cloud.google.com/security/encryption-in-transit/application-layer-transport-security/" quoteTitle="true" derivedAnchor="ALTS">
        <front>
          <title>Application Layer Transport Security</title>
          <author initials="C" surname="Ghali">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A" surname="Stubblefield">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="E" surname="Knapp">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="J" surname="Li">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="B" surname="Schmidt">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="J" surname="Boeuf">
            <organization showOnFrontPage="true"/>
          </author>
        </front>
      </reference>
      <reference anchor="CurveCP" target="https://curvecp.org/" quoteTitle="true" derivedAnchor="CurveCP">
        <front>
          <title>CurveCP: Usable security for the Internet</title>
          <author initials="D" surname="Bernstein">
            <organization showOnFrontPage="true">CurveCP</organization>
          </author>
        </front>
      </reference>
      <reference anchor="I-D.ietf-tls-dtls13" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-tls-dtls13-38" derivedAnchor="DTLS-1.3">
        <front>
          <title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
          <author fullname="Eric Rescorla">
            <organization showOnFrontPage="true">RTFM, Inc.</organization>
          </author>
          <author fullname="Hannes Tschofenig">
            <organization showOnFrontPage="true">Arm Limited</organization>
          </author>
          <author fullname="Nagendra Modadugu">
            <organization showOnFrontPage="true">Google, Inc.</organization>
          </author>
          <date month="May" day="29" year="2020"/>
          <abstract>
            <t indent="0">   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees with the exception of order protection/non-replayability.
   Datagram semantics of the underlying transport are preserved by the
   DTLS protocol.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-tls-dtls13-38"/>
        <format type="TXT" target="https://www.ietf.org/internet-drafts/draft-ietf-tls-dtls13-38.txt"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="MinimaLT" target="https://dl.acm.org/citation.cfm?id=2516737" quoteTitle="true" derivedAnchor="MinimaLT">
        <front>
          <title>MinimaLT: minimal-latency networking through better security</title>
          <author initials="W" surname="Petullo">
            <organization showOnFrontPage="true">United States Military Academy, West Point, NY, USA</organization>
          </author>
          <author initials="X" surname="Zhang">
            <organization showOnFrontPage="true">University of Illinois at Chicago, Chicago, IL, USA</organization>
          </author>
          <author initials="J" surname="Solworth">
            <organization showOnFrontPage="true">University of Illinois at Chicago, Chicago, IL, USA</organization>
          </author>
          <author initials="D" surname="Bernstein">
            <organization showOnFrontPage="true">University of Illinois at Chicago, Chicago, IL, USA</organization>
          </author>
          <author initials="T" surname="Lange">
            <organization showOnFrontPage="true">TU Eindhoven, Eindhoven, Netherlands</organization>
          </author>
        </front>
        <seriesInfo name="DOI" value="10.1145/2508859.2516737"/>
      </reference>
      <reference anchor="OpenVPN" target="https://openvpn.net/community-resources/openvpn-cryptographic-layer/" quoteTitle="true" derivedAnchor="OpenVPN">
        <front>
          <title>OpenVPN cryptographic layer</title>
          <author>
            <organization showOnFrontPage="true">OpenVPN</organization>
          </author>
        </front>
      </reference>
      <reference anchor="I-D.ietf-quic-tls" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-quic-tls-31" derivedAnchor="QUIC-TLS">
        <front>
          <title>Using TLS to Secure QUIC</title>
          <author fullname="Martin Thomson">
            <organization showOnFrontPage="true">Mozilla</organization>
          </author>
          <author fullname="Sean Turner">
            <organization showOnFrontPage="true">sn3rd</organization>
          </author>
          <date month="September" day="24" year="2020"/>
          <abstract>
            <t indent="0">   This document describes how Transport Layer Security (TLS) is used to
   secure QUIC.

Note to Readers

   Discussion of this draft takes place on the QUIC working group
   mailing list (quic@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/search/?email_list=quic.

   Working Group information can be found at https://github.com/quicwg;
   source code and issues list for this draft can be found at
   https://github.com/quicwg/base-drafts/labels/-tls.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-quic-tls-31"/>
        <format type="TXT" target="https://www.ietf.org/internet-drafts/draft-ietf-quic-tls-31.txt"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="I-D.ietf-quic-transport" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-quic-transport-31" derivedAnchor="QUIC-TRANSPORT">
        <front>
          <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
          <author fullname="Jana Iyengar">
            <organization showOnFrontPage="true">Fastly</organization>
          </author>
          <author fullname="Martin Thomson">
            <organization showOnFrontPage="true">Mozilla</organization>
          </author>
          <date month="September" day="24" year="2020"/>
          <abstract>
            <t indent="0">   This document defines the core of the QUIC transport protocol.
   Accompanying documents describe QUIC's loss detection and congestion
   control and the use of TLS for key negotiation.

Note to Readers

   Discussion of this draft takes place on the QUIC working group
   mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is
   archived at https://mailarchive.ietf.org/arch/search/?email_list=quic

   Working Group information can be found at https://github.com/quicwg;
   source code and issues list for this draft can be found at
   https://github.com/quicwg/base-drafts/labels/-transport.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-quic-transport-31"/>
        <format type="TXT" target="https://www.ietf.org/internet-drafts/draft-ietf-quic-transport-31.txt"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="RFC2385" target="https://www.rfc-editor.org/info/rfc2385" quoteTitle="true" derivedAnchor="RFC2385">
        <front>
          <title>Protection of BGP Sessions via the TCP MD5 Signature Option</title>
          <author initials="A." surname="Heffernan" fullname="A. Heffernan">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="1998" month="August"/>
          <abstract>
            <t indent="0">This memo describes a TCP extension to enhance security for BGP. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="2385"/>
        <seriesInfo name="DOI" value="10.17487/RFC2385"/>
      </reference>
      <reference anchor="RFC2890" target="https://www.rfc-editor.org/info/rfc2890" quoteTitle="true" derivedAnchor="RFC2890">
        <front>
          <title>Key and Sequence Number Extensions to GRE</title>
          <author initials="G." surname="Dommety" fullname="G. Dommety">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2000" month="September"/>
          <abstract>
            <t indent="0">This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="2890"/>
        <seriesInfo name="DOI" value="10.17487/RFC2890"/>
      </reference>
      <reference anchor="RFC3711" target="https://www.rfc-editor.org/info/rfc3711" quoteTitle="true" derivedAnchor="RFC3711">
        <front>
          <title>The Secure Real-time Transport Protocol (SRTP)</title>
          <author initials="M." surname="Baugher" fullname="M. Baugher">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="D." surname="McGrew" fullname="D. McGrew">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="M." surname="Naslund" fullname="M. Naslund">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="E." surname="Carrara" fullname="E. Carrara">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="K." surname="Norrman" fullname="K. Norrman">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2004" month="March"/>
          <abstract>
            <t indent="0">This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP).   [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="3711"/>
        <seriesInfo name="DOI" value="10.17487/RFC3711"/>
      </reference>
      <reference anchor="RFC3748" target="https://www.rfc-editor.org/info/rfc3748" quoteTitle="true" derivedAnchor="RFC3748">
        <front>
          <title>Extensible Authentication Protocol (EAP)</title>
          <author initials="B." surname="Aboba" fullname="B. Aboba">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="L." surname="Blunk" fullname="L. Blunk">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="J." surname="Vollbrecht" fullname="J. Vollbrecht">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="J." surname="Carlson" fullname="J. Carlson">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="H." surname="Levkowetz" fullname="H. Levkowetz" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2004" month="June"/>
          <abstract>
            <t indent="0">This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods.  EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP.  EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees.  Fragmentation is not supported within EAP itself; however, individual EAP methods may support this.  This document obsoletes RFC 2284.  A summary of the changes between this document and RFC 2284 is available in Appendix A.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="3748"/>
        <seriesInfo name="DOI" value="10.17487/RFC3748"/>
      </reference>
      <reference anchor="RFC4253" target="https://www.rfc-editor.org/info/rfc4253" quoteTitle="true" derivedAnchor="RFC4253">
        <front>
          <title>The Secure Shell (SSH) Transport Layer Protocol</title>
          <author initials="T." surname="Ylonen" fullname="T. Ylonen">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C." surname="Lonvick" fullname="C. Lonvick" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2006" month="January"/>
          <abstract>
            <t indent="0">The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.</t>
            <t indent="0">This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP.  The protocol can be used as a basis for a number of secure network services.  It provides strong encryption, server authentication, and integrity protection.  It may also provide compression.</t>
            <t indent="0">Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated.</t>
            <t indent="0">This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="4253"/>
        <seriesInfo name="DOI" value="10.17487/RFC4253"/>
      </reference>
      <reference anchor="RFC4302" target="https://www.rfc-editor.org/info/rfc4302" quoteTitle="true" derivedAnchor="RFC4302">
        <front>
          <title>IP Authentication Header</title>
          <author initials="S." surname="Kent" fullname="S. Kent">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2005" month="December"/>
          <abstract>
            <t indent="0">This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6.  This document obsoletes RFC 2402 (November 1998).  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="4302"/>
        <seriesInfo name="DOI" value="10.17487/RFC4302"/>
      </reference>
      <reference anchor="RFC4303" target="https://www.rfc-editor.org/info/rfc4303" quoteTitle="true" derivedAnchor="RFC4303">
        <front>
          <title>IP Encapsulating Security Payload (ESP)</title>
          <author initials="S." surname="Kent" fullname="S. Kent">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2005" month="December"/>
          <abstract>
            <t indent="0">This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6.  ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality.  This document obsoletes RFC 2406 (November 1998).  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="4303"/>
        <seriesInfo name="DOI" value="10.17487/RFC4303"/>
      </reference>
      <reference anchor="RFC4555" target="https://www.rfc-editor.org/info/rfc4555" quoteTitle="true" derivedAnchor="RFC4555">
        <front>
          <title>IKEv2 Mobility and Multihoming Protocol (MOBIKE)</title>
          <author initials="P." surname="Eronen" fullname="P. Eronen">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2006" month="June"/>
          <abstract>
            <t indent="0">This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2).  MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations to change.  A mobile Virtual Private Network (VPN) client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another.  Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="4555"/>
        <seriesInfo name="DOI" value="10.17487/RFC4555"/>
      </reference>
      <reference anchor="RFC4571" target="https://www.rfc-editor.org/info/rfc4571" quoteTitle="true" derivedAnchor="RFC4571">
        <front>
          <title>Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport</title>
          <author initials="J." surname="Lazzaro" fullname="J. Lazzaro">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2006" month="July"/>
          <abstract>
            <t indent="0">This memo defines a method for framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets onto connection-oriented transport (such as TCP).  The memo also defines how session descriptions may specify RTP streams that use the framing method.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="4571"/>
        <seriesInfo name="DOI" value="10.17487/RFC4571"/>
      </reference>
      <reference anchor="RFC5246" target="https://www.rfc-editor.org/info/rfc5246" quoteTitle="true" derivedAnchor="RFC5246">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
          <author initials="T." surname="Dierks" fullname="T. Dierks">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="E." surname="Rescorla" fullname="E. Rescorla">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2008" month="August"/>
          <abstract>
            <t indent="0">This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5246"/>
        <seriesInfo name="DOI" value="10.17487/RFC5246"/>
      </reference>
      <reference anchor="RFC5641" target="https://www.rfc-editor.org/info/rfc5641" quoteTitle="true" derivedAnchor="RFC5641">
        <front>
          <title>Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values</title>
          <author initials="N." surname="McGill" fullname="N. McGill">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C." surname="Pignataro" fullname="C. Pignataro">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2009" month="August"/>
          <abstract>
            <t indent="0">This document defines additional Layer 2 Tunneling Protocol Version 3 (L2TPv3) bit values to be used within the "Circuit Status" Attribute Value Pair (AVP) to communicate finer-grained error states for Attachment Circuits (ACs) and pseudowires (PWs).  It also generalizes the Active bit and deprecates the use of the New bit in the Circuit Status AVP, updating RFC 3931, RFC 4349, RFC 4454, RFC 4591, and RFC 4719.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5641"/>
        <seriesInfo name="DOI" value="10.17487/RFC5641"/>
      </reference>
      <reference anchor="RFC5764" target="https://www.rfc-editor.org/info/rfc5764" quoteTitle="true" derivedAnchor="RFC5764">
        <front>
          <title>Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)</title>
          <author initials="D." surname="McGrew" fullname="D. McGrew">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="E." surname="Rescorla" fullname="E. Rescorla">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2010" month="May"/>
          <abstract>
            <t indent="0">This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows.  DTLS keying happens on the media path, independent of any out-of-band signalling channel present. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5764"/>
        <seriesInfo name="DOI" value="10.17487/RFC5764"/>
      </reference>
      <reference anchor="RFC5925" target="https://www.rfc-editor.org/info/rfc5925" quoteTitle="true" derivedAnchor="RFC5925">
        <front>
          <title>The TCP Authentication Option</title>
          <author initials="J." surname="Touch" fullname="J. Touch">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A." surname="Mankin" fullname="A. Mankin">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="R." surname="Bonica" fullname="R. Bonica">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2010" month="June"/>
          <abstract>
            <t indent="0">This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5).  TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5.  TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints.  The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes.  TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously.  TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5925"/>
        <seriesInfo name="DOI" value="10.17487/RFC5925"/>
      </reference>
      <reference anchor="RFC6189" target="https://www.rfc-editor.org/info/rfc6189" quoteTitle="true" derivedAnchor="RFC6189">
        <front>
          <title>ZRTP: Media Path Key Agreement for Unicast Secure RTP</title>
          <author initials="P." surname="Zimmermann" fullname="P. Zimmermann">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A." surname="Johnston" fullname="A. Johnston" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="J." surname="Callas" fullname="J. Callas">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2011" month="April"/>
          <abstract>
            <t indent="0">This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications.  The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol.  ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices.  For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication.  ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel.  To provide best effort SRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles. ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature.  This document is not an Internet  Standards Track specification; it is published for informational purposes.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="6189"/>
        <seriesInfo name="DOI" value="10.17487/RFC6189"/>
      </reference>
      <reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6347" quoteTitle="true" derivedAnchor="RFC6347">
        <front>
          <title>Datagram Transport Layer Security Version 1.2</title>
          <author initials="E." surname="Rescorla" fullname="E. Rescorla">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="N." surname="Modadugu" fullname="N. Modadugu">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2012" month="January"/>
          <abstract>
            <t indent="0">This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.  This document updates DTLS 1.0 to work with TLS version 1.2.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="6347"/>
        <seriesInfo name="DOI" value="10.17487/RFC6347"/>
      </reference>
      <reference anchor="RFC7296" target="https://www.rfc-editor.org/info/rfc7296" quoteTitle="true" derivedAnchor="RFC7296">
        <front>
          <title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
          <author initials="C." surname="Kaufman" fullname="C. Kaufman">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="P." surname="Hoffman" fullname="P. Hoffman">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="Y." surname="Nir" fullname="Y. Nir">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="P." surname="Eronen" fullname="P. Eronen">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="T." surname="Kivinen" fullname="T. Kivinen">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2014" month="October"/>
          <abstract>
            <t indent="0">This document describes version 2 of the Internet Key Exchange (IKE) protocol.  IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs).  This document obsoletes RFC 5996, and includes all of the errata for it.  It advances IKEv2 to be an Internet Standard.</t>
          </abstract>
        </front>
        <seriesInfo name="STD" value="79"/>
        <seriesInfo name="RFC" value="7296"/>
        <seriesInfo name="DOI" value="10.17487/RFC7296"/>
      </reference>
      <reference anchor="RFC7301" target="https://www.rfc-editor.org/info/rfc7301" quoteTitle="true" derivedAnchor="RFC7301">
        <front>
          <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
          <author initials="S." surname="Friedl" fullname="S. Friedl">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A." surname="Popov" fullname="A. Popov">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A." surname="Langley" fullname="A. Langley">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="E." surname="Stephan" fullname="E. Stephan">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2014" month="July"/>
          <abstract>
            <t indent="0">This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7301"/>
        <seriesInfo name="DOI" value="10.17487/RFC7301"/>
      </reference>
      <reference anchor="RFC7850" target="https://www.rfc-editor.org/info/rfc7850" quoteTitle="true" derivedAnchor="RFC7850">
        <front>
          <title>Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles</title>
          <author initials="S." surname="Nandakumar" fullname="S. Nandakumar">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2016" month="April"/>
          <abstract>
            <t indent="0">The Real-time Transport Protocol (RTP) specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), to refer to the transport methods.  This specification describes the following new SDP transport protocol identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', and 'TCP/TLS/RTP/AVPF'.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7850"/>
        <seriesInfo name="DOI" value="10.17487/RFC7850"/>
      </reference>
      <reference anchor="RFC8095" target="https://www.rfc-editor.org/info/rfc8095" quoteTitle="true" derivedAnchor="RFC8095">
        <front>
          <title>Services Provided by IETF Transport Protocols and Congestion Control Mechanisms</title>
          <author initials="G." surname="Fairhurst" fullname="G. Fairhurst" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="B." surname="Trammell" fullname="B. Trammell" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="M." surname="Kuehlewind" fullname="M. Kuehlewind" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2017" month="March"/>
          <abstract>
            <t indent="0">This document describes, surveys, and classifies the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services.  It examines the Transmission Control Protocol (TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Datagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the Internet Control Message Protocol (ICMP), the Real-Time Transport Protocol (RTP), File Delivery over Unidirectional Transport / Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast, NACK- Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), when HTTP is used as a pseudotransport.  This survey provides background for the definition of transport services within the TAPS working group.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8095"/>
        <seriesInfo name="DOI" value="10.17487/RFC8095"/>
      </reference>
      <reference anchor="RFC8229" target="https://www.rfc-editor.org/info/rfc8229" quoteTitle="true" derivedAnchor="RFC8229">
        <front>
          <title>TCP Encapsulation of IKE and IPsec Packets</title>
          <author initials="T." surname="Pauly" fullname="T. Pauly">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="S." surname="Touati" fullname="S. Touati">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="R." surname="Mantha" fullname="R. Mantha">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2017" month="August"/>
          <abstract>
            <t indent="0">This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP.  This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and Encapsulating Security Payload (ESP) packets over a TCP connection.  This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8229"/>
        <seriesInfo name="DOI" value="10.17487/RFC8229"/>
      </reference>
      <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
          <author initials="E." surname="Rescorla" fullname="E. Rescorla">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2018" month="August"/>
          <abstract>
            <t indent="0">This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
            <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8446"/>
        <seriesInfo name="DOI" value="10.17487/RFC8446"/>
      </reference>
      <reference anchor="RFC8547" target="https://www.rfc-editor.org/info/rfc8547" quoteTitle="true" derivedAnchor="RFC8547">
        <front>
          <title>TCP-ENO: Encryption Negotiation Option</title>
          <author initials="A." surname="Bittau" fullname="A. Bittau">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="D." surname="Giffin" fullname="D. Giffin">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="M." surname="Handley" fullname="M. Handley">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="D." surname="Mazieres" fullname="D. Mazieres">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="E." surname="Smith" fullname="E. Smith">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2019" month="May"/>
          <abstract>
            <t indent="0">Despite growing adoption of TLS, a significant fraction of TCP traffic on the Internet remains unencrypted.  The persistence of unencrypted traffic can be attributed to at least two factors. First, some legacy protocols lack a signaling mechanism (such as a STARTTLS command) by which to convey support for encryption, thus making incremental deployment impossible.  Second, legacy applications themselves cannot always be upgraded and therefore require a way to implement encryption transparently entirely within the transport layer.  The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems through a new TCP option kind providing out-of-band, fully backward-compatible negotiation of encryption.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8547"/>
        <seriesInfo name="DOI" value="10.17487/RFC8547"/>
      </reference>
      <reference anchor="RFC8548" target="https://www.rfc-editor.org/info/rfc8548" quoteTitle="true" derivedAnchor="RFC8548">
        <front>
          <title>Cryptographic Protection of TCP Streams (tcpcrypt)</title>
          <author initials="A." surname="Bittau" fullname="A. Bittau">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="D." surname="Giffin" fullname="D. Giffin">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="M." surname="Handley" fullname="M. Handley">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="D." surname="Mazieres" fullname="D. Mazieres">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="Q." surname="Slack" fullname="Q. Slack">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="E." surname="Smith" fullname="E. Smith">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2019" month="May"/>
          <abstract>
            <t indent="0">This document specifies "tcpcrypt", a TCP encryption protocol designed for use in conjunction with the TCP Encryption Negotiation Option (TCP-ENO).  Tcpcrypt coexists with middleboxes by tolerating resegmentation, NATs, and other manipulations of the TCP header.  The protocol is self-contained and specifically tailored to TCP implementations, which often reside in kernels or other environments in which large external software dependencies can be undesirable. Because the size of TCP options is limited, the protocol requires one additional one-way message latency to perform key exchange before application data can be transmitted.  However, the extra latency can be avoided between two hosts that have recently established a previous tcpcrypt connection.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8548"/>
        <seriesInfo name="DOI" value="10.17487/RFC8548"/>
      </reference>
      <reference anchor="I-D.ietf-taps-arch" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-taps-arch-08" derivedAnchor="TAPS-ARCH">
        <front>
          <title>An Architecture for Transport Services</title>
          <author fullname="Tommy Pauly">
            <organization showOnFrontPage="true">Apple Inc.</organization>
          </author>
          <author fullname="Brian Trammell">
            <organization showOnFrontPage="true">Google Switzerland GmbH</organization>
          </author>
          <author fullname="Anna Brunstrom">
            <organization showOnFrontPage="true">Karlstad University</organization>
          </author>
          <author fullname="Godred Fairhurst">
            <organization showOnFrontPage="true">University of Aberdeen</organization>
          </author>
          <author fullname="Colin Perkins">
            <organization showOnFrontPage="true">University of Glasgow</organization>
          </author>
          <author fullname="Philipp S. Tiesel">
            <organization showOnFrontPage="true">TU Berlin</organization>
          </author>
          <author fullname="Christopher A. Wood">
            <organization showOnFrontPage="true">Cloudflare</organization>
          </author>
          <date month="July" day="13" year="2020"/>
          <abstract>
            <t indent="0">   This document describes an architecture for exposing transport
   protocol features to applications for network communication, the
   Transport Services architecture.  The Transport Services Application
   Programming Interface (API) is based on an asynchronous, event-driven
   interaction pattern.  It uses messages for representing data transfer
   to applications, and it describes how implementations can use
   multiple IP addresses, multiple protocols, and multiple paths, and
   provide multiple application streams.  This document further defines
   common terminology and concepts to be used in definitions of
   Transport Services APIs and implementations.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-taps-arch-08"/>
        <format type="TXT" target="https://www.ietf.org/internet-drafts/draft-ietf-taps-arch-08.txt"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="I-D.ietf-taps-interface" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-taps-interface-09" derivedAnchor="TAPS-INTERFACE">
        <front>
          <title>An Abstract Application Layer Interface to Transport Services</title>
          <author fullname="Brian Trammell">
            <organization showOnFrontPage="true">Google Switzerland GmbH</organization>
          </author>
          <author fullname="Michael Welzl">
            <organization showOnFrontPage="true">University of Oslo</organization>
          </author>
          <author fullname="Theresa Enghardt">
            <organization showOnFrontPage="true">Netflix</organization>
          </author>
          <author fullname="Godred Fairhurst">
            <organization showOnFrontPage="true">University of Aberdeen</organization>
          </author>
          <author fullname="Mirja Kuehlewind">
            <organization showOnFrontPage="true">Ericsson</organization>
          </author>
          <author fullname="Colin Perkins">
            <organization showOnFrontPage="true">University of Glasgow</organization>
          </author>
          <author fullname="Philipp S. Tiesel">
            <organization showOnFrontPage="true">TU Berlin</organization>
          </author>
          <author fullname="Christopher A. Wood">
            <organization showOnFrontPage="true">Cloudflare</organization>
          </author>
          <author fullname="Tommy Pauly">
            <organization showOnFrontPage="true">Apple Inc.</organization>
          </author>
          <date month="July" day="27" year="2020"/>
          <abstract>
            <t indent="0">   This document describes an abstract application programming
   interface, API, to the transport layer, following the Transport
   Services Architecture.  It supports the asynchronous, atomic
   transmission of messages over transport protocols and network paths
   dynamically selected at runtime.  It is intended to replace the
   traditional BSD sockets API as the common interface to the transport
   layer, in an environment where endpoints could select from multiple
   interfaces and potential transport protocols.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-taps-interface-09"/>
        <format type="TXT" target="https://www.ietf.org/internet-drafts/draft-ietf-taps-interface-09.txt"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="WireGuard" target="https://www.wireguard.com/papers/wireguard.pdf" quoteTitle="true" derivedAnchor="WireGuard">
        <front>
          <title>WireGuard: Next Generation Kernel Network Tunnel</title>
          <author initials="J" surname="Donenfeld">
            <organization showOnFrontPage="true">WireGuard</organization>
          </author>
        </front>
      </reference>
    </references>
    <section anchor="acknowledgments" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank <contact fullname="Bob Bradley"/>,
      <contact fullname="Frederic Jacobs"/>, <contact fullname="Mirja       Kühlewind"/>, <contact fullname="Yannick Sierra"/>, <contact fullname="Brian Trammell"/>, and <contact fullname="Magnus Westerlund"/>
      for their input and feedback on this document.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="T." surname="Enghardt" fullname="Theresa Enghardt">
        <organization showOnFrontPage="true">TU Berlin</organization>
        <address>
          <postal>
            <street>Marchstr. 23</street>
            <city>Berlin</city>
            <code>10587</code>
            <country>Germany</country>
          </postal>
          <email>ietf@tenghardt.net</email>
        </address>
      </author>
      <author initials="T." surname="Pauly" fullname="Tommy Pauly">
        <organization showOnFrontPage="true">Apple Inc.</organization>
        <address>
          <postal>
            <street>One Apple Park Way</street>
            <city>Cupertino</city>
            <region>California</region>
            <code>95014</code>
            <country>United States of America</country>
          </postal>
          <email>tpauly@apple.com</email>
        </address>
      </author>
      <author initials="C." surname="Perkins" fullname="Colin Perkins">
        <organization showOnFrontPage="true">University of Glasgow</organization>
        <address>
          <postal>
            <street>School of Computing Science</street>
            <city>Glasgow</city>
            <code>G12 8QQ</code>
            <country>United Kingdom</country>
          </postal>
          <email>csp@csperkins.org</email>
        </address>
      </author>
      <author initials="K." surname="Rose" fullname="Kyle Rose">
        <organization showOnFrontPage="true">Akamai Technologies, Inc.</organization>
        <address>
          <postal>
            <street>150 Broadway</street>
            <city>Cambridge</city>
            <region>MA</region>
            <code>02144</code>
            <country>United States of America</country>
          </postal>
          <email>krose@krose.org</email>
        </address>
      </author>
      <author initials="C." surname="Wood" fullname="Christopher A. Wood">
        <organization showOnFrontPage="true">Cloudflare</organization>
        <address>
          <postal>
            <street>101 Townsend St</street>
            <city>San Francisco</city>
            <country>United States of America</country>
          </postal>
          <email>caw@heapingbits.net</email>
        </address>
      </author>
    </section>
  </back>
</rfc>