<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.37 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-masque-ip-proxy-reqs-03" category="info" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.6.0 -->
  <front>
    <title abbrev="IP Proxying Requirements">Requirements for a MASQUE Protocol to Proxy IP Traffic</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-masque-ip-proxy-reqs-03"/>
    <author initials="A." surname="Chernyakhovsky" fullname="Alex Chernyakhovsky">
      <organization>Google LLC</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View, California 94043</city>
          <country>United States of America</country>
        </postal>
        <email>achernya@google.com</email>
      </address>
    </author>
    <author initials="D." surname="McCall" fullname="Dallas McCall">
      <organization>Google LLC</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View, California 94043</city>
          <country>United States of America</country>
        </postal>
        <email>dallasmccall@google.com</email>
      </address>
    </author>
    <author initials="D." surname="Schinazi" fullname="David Schinazi">
      <organization>Google LLC</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View, California 94043</city>
          <country>United States of America</country>
        </postal>
        <email>dschinazi.ietf@gmail.com</email>
      </address>
    </author>
    <date year="2021" month="August" day="27"/>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>There is interest among MASQUE working group participants in designing a
protocol that can proxy IP traffic over HTTP. This document describes the set
of requirements for such a protocol.</t>
      <t>Discussion of this work is encouraged to happen on the MASQUE IETF mailing
list <eref target="masque@ietf.org"/> or on the GitHub repository which contains the draft:
<eref target="https://github.com/ietf-wg-masque/draft-ietf-masque-ip-proxy-reqs"/>.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/ietf-wg-masque/draft-ietf-masque-ip-proxy-reqs"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>There exist several IETF standards for proxying IP in a way that is
authenticated and confidential, such as IKEv2/IPsec <xref target="IKEV2" format="default"/>.
However, those are distinguishable from common Internet traffic and often
blocked. Additionally, large server deployments have expressed interest in
using a VPN solution that leverages existing security protocols such as QUIC
<xref target="QUIC" format="default"/> or TLS <xref target="TLS" format="default"/> to avoid adding
another protocol to their security posture.</t>
      <t>This document describes the set of requirements for a protocol that can proxy
IP traffic over HTTP. The requirements outlined below are similar to the
considerations made in designing the CONNECT-UDP method
<xref target="CONNECT-UDP" format="default"/>, additionally including
IP-specific requirements, such as a means of negotiating the routes that should
be advertised on either end of the connection.</t>
      <t>Discussion of this work is encouraged to happen on the MASQUE IETF mailing list
<eref target="masque@ietf.org"/> or on the GitHub repository which contains the draft:
<eref target="https://github.com/ietf-wg-masque/draft-ietf-masque-ip-proxy-reqs"/>.</t>
      <section anchor="conventions" numbered="true" toc="default">
        <name>Conventions</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown here.</t>
      </section>
      <section anchor="definitions" numbered="true" toc="default">
        <name>Definitions</name>
        <ul spacing="normal">
          <li>Data Transport: The mechanism responsible for transmitting IP packets over
HTTP. This can involve streams or datagrams.</li>
          <li>IP Session: An association between client and server whereby both agree to
proxy IP traffic given certain configuration properties. This is similar to a
Child Security Association in IKEv2 terminology. An IP Session uses Data
Transports to transmit packets.</li>
        </ul>
      </section>
    </section>
    <section anchor="use-cases" numbered="true" toc="default">
      <name>Use Cases</name>
      <t>There are multiple reasons to deploy an IP proxying protocol. This section
discusses some examples of use cases that MUST be supported by the protocol.
Note that while the protocol needs to support these use cases, the protocol
elements that allow them may be optional.</t>
      <section anchor="consumer-vpn" numbered="true" toc="default">
        <name>Consumer VPN</name>
        <t>Consumer VPNs refer to network applications that allow a user to hide some
properties of their traffic from some network observers. In particular, it can
hide the identity of servers the client is connecting to from the client's
network provider, and can hide the client's IP address (and derived geographical
information) from the servers they are communicating with. Note that this hidden
information is now available to the VPN service provider, so is only beneficial
for clients who trust the VPN service provider more than other entities.</t>
      </section>
      <section anchor="point-to-point-connectivity" numbered="true" toc="default">
        <name>Point to Point Connectivity</name>
        <t>Point-to-point connectivity creates a private, encrypted and authenticated
network between two IP addresses. This is useful, for example, with container
networking to provide a virtual (overlay) network with addressing separate from
the physical transport. An example of this is Wireguard.</t>
      </section>
      <section anchor="point-to-network-connectivity" numbered="true" toc="default">
        <name>Point to Network Connectivity</name>
        <t>Point-to-Network connectivity is the more traditional remote-access "VPN" use
case, frequently used when a user needs to connect to a different network (such
as an enterprise network) for access to resources that are not exposed to the
public Internet.</t>
      </section>
    </section>
    <section anchor="requirements" numbered="true" toc="default">
      <name>Requirements</name>
      <t>This section lists requirements for a protocol that can proxy IP over an HTTP
connection.</t>
      <section anchor="ip-session-establishment" numbered="true" toc="default">
        <name>IP Session Establishment</name>
        <t>The protocol will allow the client to request establishment of an IP Session,
along with configuration options and one or more associated Data Transports.
The server will have the ability to accept or deny the client's request.</t>
      </section>
      <section anchor="proxying-of-ip-packets" numbered="true" toc="default">
        <name>Proxying of IP packets</name>
        <t>The protocol will establish Data Transports, which will be able to
forward IP packets. The Data Transports MUST be able to take IP
datagrams input on one side and egress them unmodified in their
entirety on the other side, although extensions may enable
IP packets to be modified in transit. The protocol will support
both IPv6 <xref target="IPV6" format="default"/> and IPv4 <xref target="IPV4" format="default"/>.</t>
      </section>
      <section anchor="maximum-transmission-unit" numbered="true" toc="default">
        <name>Maximum Transmission Unit</name>
        <t>The protocol will allow tunnel endpoints to inform each other of the Maximum
Transmission Unit (MTU) they are willing to forward. This will allow avoiding
some IP fragmentation, especially as IPv6 does not allow IP fragmentation by
nodes along the path. In cases where the tunnel endpoint is not the same as the
communication endpoint, tunnel endpoints are expected to apply the guidance on
UDP tunnels in <xref target="TUNNELS" format="default"/>.</t>
      </section>
      <section anchor="ip-assignment" numbered="true" toc="default">
        <name>IP Assignment</name>
        <t>The client will be able to request to be assigned an IP address range,
optionally specifying a preferred range. In response to that request, the server
will either assign a range of its choosing to the client, or decline the
request. For symmetry, the server may request assignment of an IP address range
from the client, and the client will either assign a range or decline the
request. Endpoints will also have the ability to assign an IP address range to
their peer, and to communicate that assignment to the peer, without having
received a request.</t>
      </section>
      <section anchor="identity" numbered="true" toc="default">
        <name>Identity</name>
        <t>When negotiating the creation of an IP Session, the protocol will allow both
endpoints to exchange an identifier. As examples, the identity could be a user
name, an email address, a token, or a fully-qualified domain name. Note that
this requirement does not cover authenticating the identifier.</t>
      </section>
      <section anchor="transport-security" numbered="true" toc="default">
        <name>Transport Security</name>
        <t>The protocol MUST be run over a protocol that provides mutual authentication,
confidentiality and integrity. Using QUIC or TLS would meet this requirement.</t>
      </section>
      <section anchor="flow-control" numbered="true" toc="default">
        <name>Flow Control</name>
        <t>The protocol will allow the ability to proxy IP packets without flow control,
at least when HTTP/3 is in use. QUIC DATAGRAM frames are not flow controlled
and would meet this requirement. The document defining the protocol will
provide guidance on how best to use flow control to improve IP Session
performance.</t>
      </section>
      <section anchor="indistinguishability" numbered="true" toc="default">
        <name>Indistinguishability</name>
        <t>A passive network observer not participating in the encrypted connection should
not be able to distinguish IP proxying from regular encrypted HTTP Web traffic
by only observing non-encrypted parts of the traffic. Specifically, any data
sent unencrypted (such as headers, or parts of the handshake) should look like
the same unencrypted data that would be present for Web traffic. Traffic
analysis is out of scope for this requirement.</t>
      </section>
      <section anchor="support-http2-and-http3" numbered="true" toc="default">
        <name>Support HTTP/2 and HTTP/3</name>
        <t>The IP proxying protocol discussed in this document will run over HTTP. The
protocol SHOULD strongly prefer to use HTTP/3 <xref target="H3" format="default"/> and
SHOULD use the QUIC DATAGRAM frames <xref target="DGRAM" format="default"/> when
available to improve performance. The protocol MUST also support HTTP/2
<xref target="H2" format="default"/> as a fallback when UDP is blocked on the network path. Proxying
IP over HTTP/2 MAY result in lower performance than over HTTP/3.</t>
      </section>
      <section anchor="multiplexing" numbered="true" toc="default">
        <name>Multiplexing</name>
        <t>Since recent HTTP versions support concurrently running multiple requests over
the same connection, the protocol SHOULD support multiple independent instances
of IP proxying over a given HTTP connection.</t>
      </section>
      <section anchor="statefulness" numbered="true" toc="default">
        <name>Statefulness</name>
        <t>The protocol should limit the amount of state a MASQUE client or server needs to
operate. Keeping minimal state simplifies reconnection in the presence of
failures and can facilitate extensibility.</t>
      </section>
    </section>
    <section anchor="extensibility" numbered="true" toc="default">
      <name>Extensibility</name>
      <t>The protocol will provide a mechanism by which clients and servers can add
extension information to the exchange that establishes the IP Session. If the
solution uses an HTTP request and response, this could be accomplished using
HTTP headers.</t>
      <t>Once the IP Session is established, the protocol will provide a mechanism that
allows reliably exchanging extension messages in both directions at any point
in the lifetime of the IP Session.</t>
      <t>The subsections below list possible extensions that designers of the protocol
will keep in mind to ensure it will be possible to design such extensions.</t>
      <section anchor="authentication" numbered="true" toc="default">
        <name>Authentication</name>
        <t>Since the protocol will offer a way to convey identity, extensions will allow
authenticating that identity, from both the client and server, during the
establishment of the IP Session. For example, an extension could allow a client
to offer an OAuth Access Token <xref target="OAUTH" format="default"/> when requesting an IP
Session. As another example, another extension could allow an endpoint to
demonstrate knowledge of a cryptographic secret.</t>
      </section>
      <section anchor="reliable-transmission-of-ip-packets" numbered="true" toc="default">
        <name>Reliable Transmission of IP Packets</name>
        <t>While it is desirable to transmit IP packets unreliably in most cases, an
extension could provide a mechanism to allow forwarding some packets reliably.
For example, when using HTTP/3, this can be accomplished by allowing Data
Transports to run over both DATAGRAM and STREAM frames.</t>
      </section>
      <section anchor="configuration-of-congestion-and-flow-control" numbered="true" toc="default">
        <name>Configuration of Congestion and Flow Control</name>
        <t>An extension will allow exchanging congestion and flow control parameters to
improve performance. For example, an extension could disable congestion control
for non-retransmitted Data Transports if it knows that the proxied traffic is
itself congestion-controlled.</t>
      </section>
      <section anchor="data-transport-compression" numbered="true" toc="default">
        <name>Data Transport Compression</name>
        <t>While the core protocol Data Transports will transmit IP packets in their
unmodified entirety, an extension can allow compressing these packets.</t>
      </section>
    </section>
    <section anchor="non-requirements" numbered="true" toc="default">
      <name>Non-requirements</name>
      <t>This section discusses topics that are explicitly out of scope for the IP
Proxying protocol. These topics MAY be handled by implementers or future
extensions.</t>
      <section anchor="addressing-architecture" numbered="true" toc="default">
        <name>Addressing Architecture</name>
        <t>This document only describes the requirements for a protocol that allows IP
proxying. It does not discuss how the IPs assigned are determined, managed, or
translated. While these details are important for producing a functional
system, they do not need to be handled by the protocol beyond the ability to
convey those assignments.</t>
        <t>Similarly, "ownership" of an IP range is out of scope. If an endpoint
communicates to its peer that it can allocate addresses from a range, or route
traffic to a range, the peer has no obligation to trust that information.
Whether or not to trust this information is left to individual implementations
and extensions: the protocol will be extensible enough to allow the
development of extensions that assist in assessing this trust.</t>
      </section>
      <section anchor="translation" numbered="true" toc="default">
        <name>Translation</name>
        <t>Some servers may wish to perform Network Address Translation (NAT) or any other
modification to packets they forward. Doing so is out of scope for the proxying
protocol. In particular, the ability to discover the presence of a NAT,
negotiate NAT bindings, or check connectivity through a NAT is explicitly out
of scope and left to future extensions.</t>
        <t>Servers that do not perform NAT will commonly forward packets similarly to how
a traditional IP router would, but the specific of that are considered out of
scope. In particular, decrementing the Hop Limit (or TTL) field of the IP header
is out of scope for MASQUE and expected to be performed by a router behind the
MASQUE server, or collocated with it.</t>
      </section>
      <section anchor="ip-packet-extraction" numbered="true" toc="default">
        <name>IP Packet Extraction</name>
        <t>How packets are forwarded between the IP proxying connection and the physical
network is out of scope. For example, this can be accomplished on some
operating systems using a TUN interface. How this is done is deliberately not
specified and will be left to individual implementations.</t>
      </section>
      <section anchor="trust" numbered="true" toc="default">
        <name>Trust</name>
        <t>All the use-cases described in <xref target="use-cases" format="default"/> require some level of trust
between endpoints. However, how this trust is established and what decisions
endpoints make based on this trust is considered out of scope. For example, if
an endpoint doesn't sufficiently trust its peer, it would be well advised to
validate the IP addresses used by that peer - however that is considered out of
scope for the document that will describe an IP proxying protocol.</t>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document only discusses requirements on a protocol that allows IP
proxying. That protocol will need to document its security considerations.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document requests no actions from IANA.</t>
    </section>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank participants of the MASQUE working group for
their feedback.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="QUIC">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="Jana Iyengar">
              <organization>Fastly</organization>
            </author>
            <author fullname="Martin Thomson">
              <organization>Mozilla</organization>
            </author>
            <date day="14" month="January" year="2021"/>
            <abstract>
              <t>This document defines the core of the QUIC transport protocol.  QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration.  QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.
              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-transport-34"/>
        </reference>
        <reference anchor="TLS">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <date month="August" year="2018"/>
            <abstract>
              <t>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>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="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="IPV6">
          <front>
            <title>Internet Protocol, Version 6 (IPv6) Specification</title>
            <author fullname="S. Deering" initials="S." surname="Deering">
              <organization/>
            </author>
            <author fullname="R. Hinden" initials="R." surname="Hinden">
              <organization/>
            </author>
            <date month="July" year="2017"/>
            <abstract>
              <t>This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="86"/>
          <seriesInfo name="RFC" value="8200"/>
          <seriesInfo name="DOI" value="10.17487/RFC8200"/>
        </reference>
        <reference anchor="IPV4">
          <front>
            <title>Internet Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel">
              <organization/>
            </author>
            <date month="September" year="1981"/>
          </front>
          <seriesInfo name="STD" value="5"/>
          <seriesInfo name="RFC" value="791"/>
          <seriesInfo name="DOI" value="10.17487/RFC0791"/>
        </reference>
        <reference anchor="H3">
          <front>
            <title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>
            <author fullname="Mike Bishop">
              <organization>Akamai</organization>
            </author>
            <date day="2" month="February" year="2021"/>
            <abstract>
              <t>   The QUIC transport protocol has several features that are desirable
   in a transport for HTTP, such as stream multiplexing, per-stream flow
   control, and low-latency connection establishment.  This document
   describes a mapping of HTTP semantics over QUIC.  This document also
   identifies HTTP/2 features that are subsumed by QUIC, and describes
   how HTTP/2 extensions can be ported to HTTP/3.

DO NOT DEPLOY THIS VERSION OF HTTP

   DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC.  This
   version is still a work in progress.  For trial deployments, please
   use earlier versions.

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/-http.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"/>
        </reference>
        <reference anchor="DGRAM">
          <front>
            <title>An Unreliable Datagram Extension to QUIC</title>
            <author fullname="Tommy Pauly">
              <organization>Apple Inc.</organization>
            </author>
            <author fullname="Eric Kinnear">
              <organization>Apple Inc.</organization>
            </author>
            <author fullname="David Schinazi">
              <organization>Google LLC</organization>
            </author>
            <date day="12" month="July" year="2021"/>
            <abstract>
              <t>   This document defines an extension to the QUIC transport protocol to
   add support for sending and receiving unreliable datagrams over a
   QUIC connection.

   Discussion of this work is encouraged to happen on the QUIC IETF
   mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub
   repository which contains the draft: https://github.com/quicwg/
   datagram (https://github.com/quicwg/datagram).

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-datagram-03"/>
        </reference>
        <reference anchor="H2">
          <front>
            <title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
            <author fullname="M. Belshe" initials="M." surname="Belshe">
              <organization/>
            </author>
            <author fullname="R. Peon" initials="R." surname="Peon">
              <organization/>
            </author>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
              <organization/>
            </author>
            <date month="May" year="2015"/>
            <abstract>
              <t>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.  It also introduces unsolicited push of representations from servers to clients.</t>
              <t>This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7540"/>
          <seriesInfo name="DOI" value="10.17487/RFC7540"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="IKEV2">
          <front>
            <title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
            <author fullname="C. Kaufman" initials="C." surname="Kaufman">
              <organization/>
            </author>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman">
              <organization/>
            </author>
            <author fullname="Y. Nir" initials="Y." surname="Nir">
              <organization/>
            </author>
            <author fullname="P. Eronen" initials="P." surname="Eronen">
              <organization/>
            </author>
            <author fullname="T. Kivinen" initials="T." surname="Kivinen">
              <organization/>
            </author>
            <date month="October" year="2014"/>
            <abstract>
              <t>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="CONNECT-UDP">
          <front>
            <title>The CONNECT-UDP HTTP Method</title>
            <author fullname="David Schinazi">
              <organization>Google LLC</organization>
            </author>
            <date day="12" month="July" year="2021"/>
            <abstract>
              <t>   This document describes the CONNECT-UDP HTTP method.  CONNECT-UDP is
   similar to the HTTP CONNECT method, but it uses UDP instead of TCP.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the MASQUE WG mailing list
   (masque@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/masque/.

   Source for this draft and an issue tracker can be found at
   https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-masque-connect-udp-04"/>
        </reference>
        <reference anchor="TUNNELS">
          <front>
            <title>IP Tunnels in the Internet Architecture</title>
            <author fullname="Joe Touch">
              <organization>Independent consultant</organization>
            </author>
            <author fullname="Mark Townsley">
              <organization>Cisco</organization>
            </author>
            <date day="12" month="September" year="2019"/>
            <abstract>
              <t>   This document discusses the role of IP tunnels in the Internet
   architecture. An IP tunnel transits IP datagrams as payloads in non-
   link layer protocols. This document explains the relationship of IP
   tunnels to existing protocol layers and the challenges in supporting
   IP tunneling, based on the equivalence of tunnels to links. The
   implications of this document are used to derive recommendations that
   update MTU and fragment issues in RFC 4459.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-intarea-tunnels-10"/>
        </reference>
        <reference anchor="OAUTH">
          <front>
            <title>The OAuth 2.0 Authorization Framework</title>
            <author fullname="D. Hardt" initials="D." role="editor" surname="Hardt">
              <organization/>
            </author>
            <date month="October" year="2012"/>
            <abstract>
              <t>The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.  This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6749"/>
          <seriesInfo name="DOI" value="10.17487/RFC6749"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIACf6KGEAA9VbbW8bOZL+zl/B9XzY5CApzstmNgYGOzrbGRsbO95YnmCx
WByobkoi3N3saXbL0Qb57/dU8aW7ZXlyB9yHvcEAltRNsliseuqpKmY6nYrW
tIU+kZ/0b51pdKmr1smVbaSSV/Pbv92dy5vGtjazhWwtff6yk5c3ctGo1cpk
Qi2Xjd6e0E/8zFTr0VQit1mlSiyQY0Q7NbpdTUvlfuv01NTTmsZMG/2bmx6/
Fplq9do2uxNpqpUVwtTNiWybzrWvjo/fHb8S93r3YJscy1WtbirdTs9oViFc
q6r8v1RhK6y0007U5kT+A2JPpLNN2+iVw6ddSR/+KYTq2o1tToScCon/TOVO
5NF8Jk83mHWn7jd26+53R/zQS380L/SXg89ts1aV+Zdqja3w3i/WrgstP3w4
9Y8dFtctHrx8e3ws52W9Me1GK/wqb1Rz/6DCNJlpse+jK9tVrTKV/NXoh4k8
VYXBYVRGyXdvjt+8Du/SS6Smo7vKtDqXty0056RdYQHdmEz593SpTHEiVebF
/nnNss0yW453fjaTVxmWKkY7PsMPyo2e/PvvNWehyyzD39/b7222MZX6l9nb
8dbke4/+H2zZBYFn5Fw/r+lX3rMQ0+lUqiVkVFkrFrACLY2DEuA82rVSlRbu
GtwcjnVP3rtubFfLWjWtyUytCA4gb66dWVf0XIk6AcJGtTJTlawjLLQeFqTd
6kZeLBY3M7nYYEmgQEd4QPNkjVliN1CTdLoV2FWzjz2uyzYAoLjQTIgz47LO
ORwCqaGlOUlg2o6uoLBGraEoINRG1bXGSxUvEPZ2eb54L0kv2IAoDLb+j38+
8yj0MylthlN+jqOOw34x7UW3hFy1daYFIsmHjYFImeXT88IzoJ0IzLRp29qd
vHixxtl3S9L9C8a5h3WAuhffAb/ns3BYpcnzQgvxAyFcY/MuI7sLR6e/kORO
Q7eq8Hti3FNN7tVWRwTGSeDMlIT5+UMyjjEPCjYEsrnEMNrNyuT0myomQedO
Xv71fPvqxeWN05n8+vUv+Prrq58+vT/98dW7t9++zcSFfSAJJpjYOi0VBMsh
F5btjNuoJbxj1dgSs5cwr4TUyTRoZbtqdSWWhc3udT6T8zw3tE/47G4iC9Ws
yTQasqFc14XdecvYqC0poYbtOmwhmbGpROfYNOWvN9cA/KKj2fzOC1bXGgbH
6qPXsLOugT8m+3Jp83+7uzwVX7/+gf7+dDk9Y5eawjqzKeSvXI1g8u0bWcri
wy3U8wf8IeX8+c0bKIfsT20tMERhRzA1VVkovZH1IITiB9MMZLCu7RoNA/iO
o8hDjqLkE84onnJGPZ7Edi2cAtpc6sI+8Gk6UxqcQZBVwEocrKRhBHTwolyP
AYHkO/14fX1+upjend3IUsMycmjxL4Nfe2UG+8e0lc7aaZfX375NWGHRBDB9
VnSswMubqat1ZmgbQ7l7c1VYDwdD2qlAHmDLbRQKQNay/qAYt7FdkYslDDaH
OlpDFgQb0YYPSLNR8qggGGT5P4UdSbAj/v1g54cf5KmttoQCOF6yQi1Bs2ib
QJWjq7vbxdHE/5XXH/nzp3O4x6fzM/p8ezH/8CF9iG/cXny8+4DnInzqR55+
vLo6vz7zg/Gr3Pvpav53/CGMOPp4s7j8eD3/cETmRqoXyTnITKH0pfYgAERg
THPJawgd5H+e3siXb8hL4aGvXr58Bw/1X/788sc3376JBwCiX8xWBSmbvkLH
O0mnCRcgEC0KeFVtWlXA6rAELOmhkgTIXntnemUqE7T3H/JMtYrYsceKE/a4
UmcbkAhX4mjxM/yJURIHz6BSmrYNqF0rICK5JWwUMX4QQcmzTbW1BTCQSIcq
HVlOjuXWDb7MaHHMcKvZXE/kHLI7ZzPDjgtdtQ8aFpoVhjWITQeIfaC9LHdy
CaySmEyTbrH4o6C+NluaAN5DDIajx7rzuEAv1+RW2gV58f8ASBTmO92YAlwm
At98IBym47AjcZilqWxh17sZ7aDfkOwcfJm0i6mSfh2jVFBi1B6di7xDbDpV
GCNC9CSbKbuiNXVBGKgcoRlG+wgDhbD+YwRN1MPvxnlEELnHA0jibEnBSJWY
jtEH8uGQXAQcdhgYqOtqEpQQdsf+25Oaa9tq/zLcvNCjpwAznbN8YQJ6ihXS
KpPR60IXAdB5PhgtwBwvlICfHYlha4+uyeMdPKmheCnE8JuDalaazwxBm7EO
vlAQa2D4H0yvSBh+c4P4wAoRvRkEODVNMh9mBay2OLNdehOEzVxWgXJ2sJiJ
NBzKBE9M+/Q0BVaDWcMYD9bemsk/AmwT9lu/Vv/CH52Ia0LCLYUz7/fkVWmR
+C4ZAuIR0Qz5jN7C6zD9XK61ha+B4iO7EJSiNiWr5Xm/3kC4HZsc0aCuYv1B
tAdA9Uz2B88RBQJge8MJaUMVqXiL4MGUygdjz2+whMn0YCfO0gDGsKWugEfw
q0IQvvgtIWhtrE+kn5xFlrZhoRDEQkiEwsmf2WJuLJCWKwD84TRoe4szEYJ/
m7Z2WvPDbPBQZnA1isLEVMwWHycUOZtdHVnoiJemY4pwhW+D4xiiC4xv1YG3
0jaDH05YvzFcAkHDbMEowlYhytY0bQcO/YxwtlC758kkeYKwmueKMEtIxics
2OU2O0cGIBMhZKQKIiSagP8/g62sO7DzPRVeh7WeUGJ8PFKj8fbuD6lRkSzB
W0sY01RlGVnrEU72iDQjCCOgG+JMUC4MoyPCQxEu+m0CmLAOwzSo/AruTz4V
NfKMmJYgplWRTVC0BXmKj597GuqXxwzQG1hRFlGQPAAcmFi7dZ4pEaesuyUg
JeUGDNijqpEYoi5TJ/e/IL9kMUx68QOFUDHidDiKQVg5RwoFYdyG5vX0J836
YBD8E5ZGsOFdQq1wJj0cTEevhiFrIqggtU5GOQiXHo5d4B6aIjkfbYzYUNWY
SMANFwlevGCcDpFcagmGCRuhA8RB1C0TA13txqgWhA7GGAMdhO55x6H9pz3u
SzQJ7JTfImLtcYpw5wFGP5jW5x17w1OETPim7jUGiURpQAvqriVyTCpy7LrQ
l14zMnN066rSwmSNJ3wcbwSBCQjhLrJqD2c0HJhfIDfp1hsYJDJQFzKaHQyb
pBADBubp5Wh2Et20fjNjHYUYLZhCXd5s3xLPvLz59S3nhq+Oj8E8SXQ8ehMe
vaFHxz++e0k5NZ3Ilfpiyq70GiqNt04qAP2OUXYw64KSFwZeFtpHEakVTsbv
POQ1YX7xaH757Gpx97yPWLRADKP+KAPoDlbmLJcSNI7nUNsKmRA5AZs3IJ6z
Nk7mqKRAGsmtdowFfob9MaBHorI5RQp2GoZaRdES1MDzKiaq/GBv4z5c+tjm
VEluFFLXFHsp1QtvTx7rTXF1BSK3HqOI8njvWXcmVxXiJMgfJbd+KJfEkOAu
7pDgfrjtk1vMhrnUNLwWzxabBd1FvtyDTACTPedJyOLNT/EgDpRDUoITXOuJ
iJwOovokeeeLIDVTuAbD+EXWYEg8ApEAWIaFJgPWIry/+4zYL43ZeA4yIgNF
ZRtrXTCOHlwmHnAyqiSw4iPUyPdUzNuVpW6b3XApdrq4V5VU00PoaKtij855
7tbuafEJwZ+Q7DwdfjBrZw8japjusVSEdZ7h1jrySQ6n0egCxxtsL2jNv09h
wQLfsCp5UqMzzSxTjZH6MlBfIT5T9N4vcjC/CvWJcfQZ5xMD5yWUEiPQ0F8o
QV0TvgaqDdBrwGtcSnEmYx6eUTmFTZTZhKAK+oQpAtU7oqLwC6a/p7Sa4zUI
W7Gb/tZR2ZtQNbclpZI0eMCKBROoQbjvsSPzYb2njFENA6lZaynOpIRzD0Zj
9Gm6KnCFPTYR2CLiQ8dccbgoxfZh9ZQ0QsdP1Yg1LTZD/kmiUR0xVgsfWGWl
1oH2DzboZX5PhwNS2DZI6H6XiQzsMxGeGLiiWa3o5czPBiZClVDlWk8BiRS9
eO17AXR+My/o2Xwx/+XT/IqQudQusbfhVAVIOm3193bDEXJQyaQCSYT04Y5E
ZOQDlJUbstAAgZTtDhfnAFfSKD2wdIGUk1MnzBB8phqVpFlZQsyhIwzYPk5A
eZep5cFG5enEIFfpOWQsJtKgAXQPlhyVEhi8KBOgWkg/H52B/KyXMT8Wy51P
4bxQNLKy1bQfQPLFtDoOmsnbUB71tXMF0kf8STjSfFf1o5/FgulGK6R7jj1y
NCUQIIe27vXzsEFZWHsP8n2vRYqswylpoVC/iGhAtXlamej5YG+zvl+MeIX8
ifMjslLK5zNbh2rYQbe4DQUQNtpX7Gfefr2PHKrayFinyWPtsDdHdqXk9aks
3ne1QsnSweCqdbEL4TSaY3AdkLiL13sdAqrHeqInwhw0gFR30LswxRl935sl
0l/MRL4qRjWAaPxDi5ePcY2jmRvpjboaF76R86c3zEcpJ1/BbJYADg8LRHCg
qtCXifw5VU6YjcXEQcQcKxzL1fzvRDK6gvoxsJwHanv0UobKQhrwOpDeUJD7
QjOKW0NvUiCsvNiSailM0uNm4IWA88bntDhFBpZBWY8DZ6ifJqPtXXcvKMaj
DpOneUyV6xoRkmtLFTXZkNGKkCqlzMlHDV8VZWn300zu2yLmVcCpPUCPHmao
bsmQXlLXl/2BRvXXLwLFISIVsCok7oJKbXh1Jv+qdc16AM6WCFV+Bgdj4ThL
PjVAr4Bs3lUJc1diBRPrGu1STWylMgJNmiZkSh5EOVM/H/5yKFD1hZa+8r1M
zYxQkuor0L64DcogUlYmh8WwwJoSSWHISWlp6JD14QB8lwFNpEYgl45DLaBn
nVg/suKJx4ie1GRgcTXPnkvuLQoeG7ATWvjobXq4LjeFklT5If51SDHMeDi0
0zkVBuN3ca90qL1OABqOO5k4Qc40c+BkFgoJLWM/UzoRThiHr1tT6gjwAxX5
U3Pd0sUJfP+Pe+O1db5DMUiSWee+50cHFmZM5Wfe3T3MkGSDGTITxtiObhz0
WU6amevuTKw5LPULeceZj7hWBIbH+rRUrIp9bq5kbZHERpI6GW6gZ1DiEX2k
Bnkaw+Ga1TtIMHpjncgcdNKzGfGo/rNvie+HxUlix+kwva3FSrpfRmAPYUuV
/EhKkHNfWVsQiaaM8+P8bnFBKP72xzfvQoiIJs3ZH6UAIq0/J7sP9dxejPjD
QVn6RJkwJtcltNdyCfS+sg+gfz4bhMxEA2JBnGp1jQ4R+5M3Yz2uZXj4vImV
ps/c8zCcvJMtNKkOFNs5A1LbVck1yMCsa2MXRFVifyMHvcyG/YWSBtd2qXYR
V4jzz8TozFi//naBj1sRKlT1CCgAcbwGvcyNqnGbKnEONq7EBsi0bhefzhMx
SC2aYb1wRT+s6ZBtxUPGycJ8aFqDZGGAI9l4/IhWU40bOTo3Lqw4SDK+Z8lg
XHyAg2XC7NyIICoL+4jtzsf1TWmowsA25mJvhN39CyWKsYdknDCt08VqsM60
z0xCR3Y0M5RU8pURRpLPqdOWUb01wcm+NKzDQ5aYyoyD0mOsOO4rRlXhGLIo
gscNp0etymvWzZPV777n2NraZIPKuv5CnTlDVOgAl+Zi6s2hhqbmOhDPRbRt
6bl/4U2YWAPLwTjfIGen+yniEUT3PZJ5k21MC2npvb1rLJzRjO+yfLeOH4Ih
pI9cCyF9UAQICuFM0W/TDSpldB9J+z4yBWGYL93RoHRH8HkWVF2fyWQIjt8H
AfL5LrYPA1Ahh6n5DpYvq626KvMFN+F2rtVluCuQW5aKaFko2w20OYpZS72z
oXDVZ/AiRK1wnSoVi0jPt76DTpndkX2gyLsx9VFf6vF1qL1UivnPAMYHZVDt
S8TQO5WgQuRrk6FyzSq12nwkDHU0Thf5Qo2Ivsj9ovAwVrWwdToj5LCFWffs
LXQeabWe182ooOUr1D4BH7zJlYlRO7TQq9bXt3MDdKeKTLJU35vmskRvpicH
+MKyp7NEbypuBaTQQBE911sQoTrG830GRMfDN87oU3Joas6R4HSLL9aeikhd
KMhEnktVzweqD1DhxqNr6gYGhxqOls+u5wu+IETcjqO28KCTJd2mfgWZYqrX
n1kf4J5Is3XKYkSPC3st+L06EzkdR6+93AE2ACEnItYlNX2VSzqmau2rDNlG
Z3vtzHbTsO55MBPnEZSJJC+daTx6j0Rjsnib+u3ET70nJs1iaj52fxWxSPpJ
SnPRv/gWA1HDUXOVPIxMvvEFjolcdqHJEO+kMeULaBwvylHmzCoX0R3His2J
KZGBxZrYha3lB04En1GpcPHhuURYKfIBofSJhzh0miFN9MbftzCWKX4HZhK3
stQb40FIhKGR2NJR2QADue9amjY1MDxxo+SPbhOzbV/AaaIqSQNBvXybMLTv
9wo0gzQ0lvBjPz21/h/B2Yh6PMm+qC5HV1B8VszmzyjtZLwcuri79vfFkN1i
2gt2eV+KyqnDyES0QJwitgubgC2JcNLhrkIEke+DUaxCAxXAzohLbPjyztS3
skb31L5+TQ/A6EN49OyUbq8WbAc8U1RrKt7zLvx13E3cjsfQcTLqpfc5XGbY
eQYdgJI6r0vlYs1nOMkjqz54KmYlhokDherqjy2SO4oUxldrwpQh+PAdn1Q3
fNBEWfOt8ZcExFYVJvcdFD26/+HvMSzDtWYOOVPaut6meHZAZjEGv8ROfPGS
DjUeyJP3wAja+8trp6NLsYdJT6Jt4wu31f+I7yxCC2IQvCLBSMuQKtM94vE1
XeaVl/Pr+XckTQWziu4O+EoAh30ay5PMs5j2eW769aTqyiXp9qejlSqcPvrm
iwn+39S4cKZUNQ69xup+/K8JYj/60D87WNkm9NRW2C1VJmfivwHjkLRQpTQA
AA==

-->

</rfc>
