]> Google LLC

1600 Amphitheatre Parkway Mountain View CA 94043 United States of America dschinazi.ietf@gmail.com

Zscaler

120 Holger Way San Jose CA 95134 United States of America yrosomakho@zscaler.com

Web and Internet Transport MASQUE quic http datagram udp tcp proxy tunnels quic in quic turtles all the way down masque http-ng dns Proxying IP in HTTP allows building a VPN through HTTP load balancers. However, at the time of writing, that mechanism lacks a way to communicate network configuration details such as DNS information or IPv6 NAT64 prefixes (PREF64). In contrast, most existing VPN protocols provide mechanisms to exchange such configuration information. This document defines extensions that convey DNS and PREF64 configuration using HTTP capsules. This mechanism supports encrypted DNS transports and can be used to inform peers about network translation prefixes for IPv6/IPv4 synthesis. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Multiplexed Application Substrate over QUIC Encryption Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Proxying IP in HTTP () allows building a VPN through HTTP load balancers. However, at the time of writing, that mechanism lacks a way to communicate network configuration details such as DNS information or IPv6 NAT64 prefixes (PREF64). In contrast, most existing VPN protocols provide mechanisms to exchange such configuration information (for example supports discovery of DNS servers). This document defines extensions that allow CONNECT-IP peers to convey DNS and PREF64 configuration information to its peer using HTTP capsules (). These extensions do not define any new way to transport DNS queries or responses, but instead enable the exchange of DNS resolver configuration and NAT64 prefix information inline with CONNECT-IP sessions. Note that these extensions are meant for cases where CONNECT-IP operates as a Remote Access VPN (see ) or a Site-to-Site VPN (see ), but not for cases like IP Flow Forwarding (see ). For DNS configuration, this specification uses Service Bindings () to exchange information about nameservers, such as which encrypted DNS transport is supported. This allows support for DNS over HTTPS (), DNS over QUIC (), DNS over TLS (), unencrypted DNS over UDP port 53 and TCP port 53 (), as well as potential future DNS transports. PREF64 configuration is represented in a way similar to Router Advertisement option defined in . Similar to how Proxying IP in HTTP exchanges IP address configuration information (), the mechanism defined in this document leverages capsules. Similarly, these mechanisms are bidirectional: either endpoint can send configuration information.

Conventions and Definitions 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. This document uses terminology from . Where this document defines protocol types, the definition format uses the notation from . This specification uses the variable-length integer encoding from . Variable-length integer values do not need to be encoded in the minimum number of bytes necessary. In this document, we use the term "nameserver" to refer to a DNS recursive resolver as defined in , and the term "domain name" is used as defined in .

DNS Configuration Mechanism Either endpoint can send DNS configuration information in a DNS_ASSIGN capsule. The capsule format is defined below.

Domain Structure

Domain Format

Each Domain contains the following fields:

Domain Length:

Length of the following Domain field, encoded as a variable-length integer.

Domain Name:

A Fully Qualified Domain Name (FQDN) in common display format (). The trailing dot representing the DNS root MUST be omitted. Internationalized labels MUST be encoded as IDNA A-labels ().

Since these are FQDNs, receivers MUST NOT append a search domain or any other suffix to non-empty values. Empty values have the meaning specified by the field containing the Domain structure.

Nameserver Structure

Nameserver Format

Each Nameserver structure contains the following fields:

Service Priority:

The priority of this attribute compared to other nameservers, as specified in . Since this specification relies on using Service Bindings in ServiceMode (), this field MUST NOT be set to 0.

IPv4 Address Count:

The number of IPv4 Address fields following this field. Encoded as a variable-length integer.

IPv4 Address:

Sequence of IPv4 Addresses that can be used to reach this nameserver. Encoded in network byte order.

IPv6 Address Count:

The number of IPv6 Address fields following this field. Encoded as a variable-length integer.

IPv6 Address:

Sequence of IPv6 Addresses that can be used to reach this nameserver. Encoded in network byte order.

Authentication Domain Name:

A Domain structure (see ) representing the domain name of the nameserver. This MAY be empty if the nameserver only supports unencrypted DNS (as traditionally sent over UDP port 53 and TCP port 53).

Service Parameters Length:

Length of the following Service Parameters field, encoded as a variable-length integer.

Service Parameters:

Set of service parameters that apply to this nameserver. Encoded using the wire format specified in .

Service parameters allow exchanging additional information about the nameserver:

• The "port" service parameter is used to indicate which port the nameserver is reachable on. If no "port" service parameter is included, this indicates that default port numbers should be used.
• The "alpn" service parameter is used to indicate which encrypted DNS transports are supported by this nameserver. If the "no-default-alpn" service parameter is omitted, that indicates that the nameserver supports unencrypted DNS, as is traditionally sent over UDP port 53 and TCP port 53. In that case, the sum of IPv4 Address Count and IPv6 Address Count MUST be nonzero. If Authentication Domain Name is empty, the "alpn" and "no-default-alpn" service parameter MUST be omitted.
• The "dohpath" service parameter is used to convey a relative DNS over HTTPS URI Template, see .
• The service parameters MUST NOT include "ipv4hint" or "ipv6hint" SvcParams, as they are superseded by the included IP addresses.

DNS Configuration Structure

DNS Configuration Format

Each DNS Configuration contains the following fields:

Nameserver Count:

The number of Nameserver structures following this field. Encoded as a variable-length integer. This field MUST NOT be zero.

Nameserver:

A series of Nameserver structures representing nameservers.

Internal Domain Count:

The number of Domain structures following this field. Encoded as a variable-length integer.

Internal Domain:

A series of Domain structures representing internal domain names.

Search Domain Count:

The number of Domain structures following this field. Encoded as a variable-length integer.

Search Domain:

A series of Domain structures representing search domains.

DNS_ASSIGN Capsule The DNS_ASSIGN capsule (see for the value of the capsule type) allows an endpoint to send DNS configuration to its peer.

DNS_ASSIGN Capsule Format

DNS_ASSIGN capsule MAY include multiple DNS configurations if different DNS servers are responsible for separate internal domains. If multiple DNS_ASSIGN capsules are sent in one direction, each DNS_ASSIGN capsule supersedes prior ones. An empty DNS_ASSIGN capsule indicates that there are no DNS services available; this can be used to withdraw previous configurations.

Handling Note that internal domains include subdomains. In other words, if the DNS configuration contains a domain, that indicates that the corresponding domain and all of its subdomains can be resolved by the nameservers exchanged in the same DNS configuration. Sending an empty string as an internal domain indicates the DNS root; i.e., that the corresponding nameserver can resolve all domain names. As with other IP Proxying capsules, the receiver can decide whether to use or ignore the configuration information. For example, in the consumer VPN scenario, clients will trust the IP proxy and apply received DNS configuration, whereas IP proxies will ignore any DNS configuration sent by the client. If the IP proxy sends a DNS_ASSIGN capsule containing a DNS over HTTPS nameserver, then the client can validate whether the IP proxy is authoritative for the origin of the URI template. If this validation succeeds, the client SHOULD send its DNS queries to that nameserver directly as independent HTTPS requests. When possible, those requests SHOULD be coalesced over the same HTTPS connection.

Examples

Full-Tunnel Consumer VPN A full-tunnel consumer VPN hosted at masque.example.org could configure the client to use DNS over HTTPS to the IP proxy itself by sending the following configuration.

Full Tunnel Example

Split-Tunnel Enterprise VPN An enterprise switching their preexisting IKEv2/IPsec split-tunnel VPN to connect-ip could use the following configuration.

Split Tunnel Example

PREF64 Configuration Mechanism This document defines a new capsule type, PREF64, that allows a CONNECT-IP peer to communicate the IPv6 NAT64 prefixes to be used for IPv6/IPv4 address synthesis. This information enables an endpoint operating in an IPv6-only environment to construct IPv4-reachable addresses from IPv6 literals when a NAT64 translator is in use.

PREF64 Capsule Each PREF64 capsule conveys zero or more NAT64 prefixes. If multiple capsules are sent in the same direction, the most recent one supersedes any previously advertised prefixes. Empty PREF64 capsule is used to inform that NAT64 prefixes are not available. The capsule has the following structure (see for the value of the capsule type):

PREF64 Capsule Format

Individual NAT64 prefix has the following structure:

NAT64 Prefix Format

NAT64 prefix fields are:

Prefix Length:

The length of the NAT64 prefix in bits encoded as a single byte. Valid values are 32, 40, 48, 56, 64, and 96. These lengths correspond to the prefix sizes permitted for the IPv6-to-IPv4 address synthesis algorithm described in .

Prefix:

The highest 96 bits of the IPv6 prefix, encoded in network byte order. Note that this field is always 96 bits long, regardless of the value in the Prefix Length field preceding it, see for details.

Handling Upon receiving a PREF64 capsule, a peer updates its local NAT64 configuration for the corresponding CONNECT-IP session. The newly received PREF64 capsule supersedes any previously received PREF64 capsules in the same direction. If an endpoint receives a capsule that does not meet one of the requirements listed in , or with a length that is not a multiple of 13 bytes, it MUST treat it as malformed. An empty PREF64 capsule invalidates any previously received NAT64 Prefixes.

Example A CONNECT-IP peer would use the following capsule to signal a single NAT64 prefix of 64:ff9b::/96

PREF64 Capsule Example

Security Considerations Acting on received DNS_ASSIGN capsules can have significant impact on endpoint security. Endpoints MUST ignore DNS_ASSIGN capsules unless it has reason to trust its peer and is expecting DNS configuration from it. This mechanism can cause an endpoint to use a nameserver that is outside of the connect-ip tunnel. While this is acceptable in some scenarios, in others it could break the privacy properties provided by the tunnel. To avoid this, implementations need to ensure that DNS_ASSIGN capsules are not sent before the corresponding ROUTE_ADVERTISEMENT capsule.

IANA Considerations This document, if approved, will request IANA add the following values to the "HTTP Capsule Types" registry maintained at <>.

Value	Capsule Type
0x1ACE79EC (if this document is approved, this value will be
replaced by a smaller one before publication)	DNS_ASSIGN
0x274C0FBC (if this document is approved, this value will be
replaced by a smaller one before publication)	PREF64

All of these new entries use the following values for these fields:

Status:

provisional (permanent if this document is approved)

Reference:

This document

Change Controller:

IETF

Contact:

masque@ietf.org

Notes:

None

References Normative References This document describes how to proxy IP packets in HTTP. This protocol is similar to UDP proxying in HTTP but allows transmitting arbitrary IP packets. More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an HTTP server that acts as an IP proxy. This document updates RFC 9298. This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, which is a more general convention for conveying data in HTTP connections. HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. 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. 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. 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 Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document obsoletes RFC 7719 and updates RFC 2308. This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK] The SVCB DNS resource record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a domain name. This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols. This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. [STANDARDS-TRACK] Informative References 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. This document specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate prefixes of Network Address and Protocol Translation from IPv6 clients to IPv4 servers (NAT64) to hosts. This document defines two Configuration Payload Attribute Types (INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key Exchange Protocol version 2 (IKEv2). These payloads add support for private (internal-only) DNS domains. These domains are intended to be resolved using non-public DNS servers that are only reachable through the IPsec connection. DNS resolution for other domains remains unchanged. These Configuration Payloads only apply to split- tunnel configurations. This document specifies new Internet Key Exchange Protocol Version 2 (IKEv2) Configuration Payload Attribute Types to assign DNS resolvers that support encrypted DNS protocols, such as DNS over HTTPS (DoH), DNS over TLS (DoT), and DNS over QUIC (DoQ).

Acknowledgments The mechanism in this document was inspired by , , and . The authors would like to thank , , , , and other enthusiasts in the MASQUE Working Group for their contributions.