Requirements for a MASQUE Protocol to Proxy IP Traffic
Google LLC
1600 Amphitheatre Parkway
Mountain View, California 94043
United States of America
achernya@google.com
Google LLC
1600 Amphitheatre Parkway
Mountain View, California 94043
United States of America
dallasmccall@google.com
Google LLC
1600 Amphitheatre Parkway
Mountain View, California 94043
United States of America
dschinazi.ietf@gmail.com
Internet-Draft
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.
Discussion of this work is encouraged to happen on the MASQUE IETF mailing
list or on the GitHub repository which contains the draft:
.
Discussion Venues
Source for this draft and an issue tracker can be found at
.
Introduction
There exist several IETF standards for proxying IP in a way that is
authenticated and confidential, such as IKEv2/IPsec .
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
or TLS to avoid adding
another protocol to their security posture.
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
, additionally including
IP-specific requirements, such as a means of negotiating the routes that should
be advertised on either end of the connection.
Discussion of this work is encouraged to happen on the MASQUE IETF mailing list
or on the GitHub repository which contains the draft:
.
Conventions
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
when, and only when, they appear in all capitals, as shown here.
Definitions
- Data Transport: The mechanism responsible for transmitting IP packets over
HTTP. This can involve streams or datagrams.
- 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.
Use Cases
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.
Consumer VPN
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.
Point to Point Connectivity
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.
Point to Network Connectivity
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.
Requirements
This section lists requirements for a protocol that can proxy IP over an HTTP
connection.
IP Session Establishment
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.
Proxying of IP packets
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 and IPv4 .
Maximum Transmission Unit
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 .
IP Assignment
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.
Identity
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.
Transport Security
The protocol MUST be run over a protocol that provides mutual authentication,
confidentiality and integrity. Using QUIC or TLS would meet this requirement.
Flow Control
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.
Indistinguishability
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.
Support HTTP/2 and HTTP/3
The IP proxying protocol discussed in this document will run over HTTP. The
protocol SHOULD strongly prefer to use HTTP/3 and
SHOULD use the QUIC DATAGRAM frames when
available to improve performance. The protocol MUST also support HTTP/2
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.
Multiplexing
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.
Statefulness
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.
Extensibility
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.
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.
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.
Authentication
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 when requesting an IP
Session. As another example, another extension could allow an endpoint to
demonstrate knowledge of a cryptographic secret.
Reliable Transmission of IP Packets
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.
Configuration of Congestion and Flow Control
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.
Data Transport Compression
While the core protocol Data Transports will transmit IP packets in their
unmodified entirety, an extension can allow compressing these packets.
Non-requirements
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.
Addressing Architecture
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.
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.
Translation
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.
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.
IP Packet Extraction
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.
Trust
All the use-cases described in 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.
Security Considerations
This document only discusses requirements on a protocol that allows IP
proxying. That protocol will need to document its security considerations.
IANA Considerations
This document requests no actions from IANA.
Acknowledgments
The authors would like to thank participants of the MASQUE working group for
their feedback.
References
Normative References
QUIC: A UDP-Based Multiplexed and Secure Transport
Fastly
Mozilla
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.
The Transport Layer Security (TLS) Protocol Version 1.3
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.
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.
Key words for use in RFCs to Indicate Requirement Levels
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.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
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.
Internet Protocol, Version 6 (IPv6) Specification
This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.
Internet Protocol
Hypertext Transfer Protocol Version 3 (HTTP/3)
Akamai
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.
An Unreliable Datagram Extension to QUIC
Apple Inc.
Apple Inc.
Google LLC
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).
Hypertext Transfer Protocol Version 2 (HTTP/2)
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.
This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
Informative References
Internet Key Exchange Protocol Version 2 (IKEv2)
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.
The CONNECT-UDP HTTP Method
Google LLC
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.
IP Tunnels in the Internet Architecture
Independent consultant
Cisco
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.
The OAuth 2.0 Authorization Framework
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]