]> Zscaler

yrosomakho@zscaler.com

Futurewei Technologies, Inc.

aretana@futurewei.com

Routing IDR Working Group bgp masque tunnel This document defines BGP Tunnel Encapsulation Attribute tunnel types for MASQUE CONNECT-TCP, CONNECT-UDP, CONNECT-IP, and CONNECT-ETHERNET. It also defines URI Template and ALPN Sub-TLVs for advertising the MASQUE proxy endpoint, the HTTP request target template, and the application-layer protocol constraints used to establish the corresponding MASQUE tunnel. 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 IDR Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The BGP Tunnel Encapsulation Attribute allows BGP speakers to advertise the tunnel encapsulation information associated with reachability information carried in BGP UPDATE messages. It is used to indicate that traffic associated with a route can be carried using a particular tunnel encapsulation and to provide the parameters needed to establish or use that tunnel. MASQUE defines mechanisms for proxying traffic using HTTP. These mechanisms include proxying UDP payloads using CONNECT-UDP , proxying IP packets using CONNECT-IP , proxying TCP connections using CONNECT-TCP , and proxying Ethernet frames using CONNECT-ETHERNET . These mechanisms allow traffic to be carried over HTTP/1.1 , HTTP/2 , or HTTP/3 connections to a MASQUE proxy and are applicable to environments such as SD-WAN, data center interconnect, VPN services, and other overlay connectivity deployments. In some deployments, BGP is already used as the control plane for advertising reachability and associated tunnel encapsulation information. Allowing BGP to advertise MASQUE tunnel encapsulation parameters enables a BGP speaker to signal that traffic associated with a route is reachable through a MASQUE proxy using one of the template-driven CONNECT mechanisms. This document defines BGP Tunnel Encapsulation Attribute tunnel types for CONNECT-TCP, CONNECT-UDP, CONNECT-IP, and CONNECT-ETHERNET. This document also defines a URI Template Sub-TLV for the BGP Tunnel Encapsulation Attribute. The URI Template identifies the MASQUE proxy endpoint and provides the template used to construct the HTTP request target for the corresponding CONNECT request. In addition, because MASQUE tunnels can be established over different HTTP versions, this document defines an ALPN Sub-TLV that can be used to indicate the application-layer protocols supported or preferred for use with the advertised tunnel. This document does not define new BGP NLRI, does not define a new MASQUE protocol mechanism, and does not define a new proxy authentication or authorization mechanism. The NLRI to which the Tunnel Encapsulation Attribute is attached identifies the traffic, service, or reachability information to which the MASQUE tunnel applies. Authentication and authorization of the MASQUE proxy remain the responsibility of the endpoints and the applicable HTTP and TLS mechanisms.

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 , , , , and .

MASQUE proxy:

An HTTP proxy that supports one or more of the MASQUE CONNECT mechanisms identified by the tunnel types defined in this document.

MASQUE tunnel:

A tunnel established using one of the CONNECT mechanisms identified by the tunnel types defined in this document.

URI Template:

A URI Template as defined by . In this document, a URI Template is carried in the URI Template Sub-TLV and is used to construct the HTTP request target for a MASQUE tunnel.

ALPN:

Application-Layer Protocol Negotiation, as defined by .

MASQUE Tunnel Encapsulation A Tunnel Encapsulation TLV using one of the tunnel types defined in this document identifies a MASQUE proxy and the corresponding HTTP request target using the URI Template Sub-TLV defined in . The URI Template determines the MASQUE proxy endpoint and is used to construct the HTTP request for the corresponding CONNECT mechanism. An ALPN Sub-TLV, defined in , MAY be included to indicate the application-layer protocols supported or preferred for use when connecting to the MASQUE proxy. The tunnel types defined in this section identify the MASQUE mechanism used to carry the traffic associated with the BGP route. The NLRI to which the Tunnel Encapsulation Attribute is attached determines the traffic, service, or reachability information to which the MASQUE tunnel applies. A Tunnel Encapsulation TLV whose tunnel type is one of the MASQUE tunnel types defined in this document is referred to as a MASQUE Tunnel Encapsulation TLV. A MASQUE Tunnel Encapsulation TLV MUST contain exactly one URI Template Sub-TLV and MAY contain at most one ALPN Sub-TLV. Only the following Sub-TLVs are applicable to MASQUE Tunnel Encapsulation TLVs: Sub-TLVs allowed for use with MASQUE Tunnel Encapsulation TLVs

Sub-TLV	Code
Color	4
DS Field	7
URI Template	TBD5
ALPN	TBD6

All other Sub-TLVs not explicitly listed above are not defined for use with MASQUE Tunnel Encapsulation TLVs. Receivers MUST ignore these Sub-TLVs when validating MASQUE-specific semantics. Future specifications MAY define additional Sub-TLVs for use with MASQUE Tunnel Encapsulation TLVs. If a MASQUE Tunnel Encapsulation TLV contains no URI Template Sub-TLV, or contains more than one URI Template Sub-TLV, it MUST be ignored.

CONNECT-TCP Tunnel Type The CONNECT-TCP Tunnel Type indicates that traffic associated with the route is to be carried using CONNECT-TCP . This tunnel type is applicable to routes or service-specific information that identify TCP connectivity or TCP flow steering.

• Name: MASQUE CONNECT-TCP Tunnel Type: TBD1 Length: 0

CONNECT-UDP Tunnel Type The CONNECT-UDP Tunnel Type indicates that traffic associated with the route is to be carried using CONNECT-UDP . This tunnel type is applicable to routes or service-specific information that identify UDP connectivity or UDP flow steering.

• Name: MASQUE CONNECT-UDP Tunnel Type: TBD2 Length: 0

CONNECT-IP Tunnel Type The CONNECT-IP Tunnel Type indicates that traffic associated with the route is to be carried using CONNECT-IP . This tunnel type is applicable to routes that identify IP reachability, such as IP prefixes, VPN-IP routes, or other service-specific IP reachability information.

• Name: MASQUE CONNECT-IP Tunnel Type: TBD3 Length: 0

CONNECT-ETHERNET Tunnel Type The CONNECT-ETHERNET Tunnel Type indicates that traffic associated with the route is to be carried using CONNECT-ETHERNET . This tunnel type is applicable to routes that identify Ethernet or Layer 2 service reachability, such as EVPN or other service-specific Layer 2 reachability information.

• Name: MASQUE CONNECT-ETHERNET Tunnel Type: TBD4 Length: 0

URI Template Sub-TLV The URI Template Sub-TLV identifies the MASQUE proxy endpoint and provides the template used to construct the HTTP request target for the MASQUE tunnel. The URI Template Sub-TLV is carried in a MASQUE Tunnel Encapsulation TLV. The URI Template Sub-TLV has the following format:

URI Template Sub-TLV

Type:

TBD5

Length:

The length, in octets, of the URI Template Value field.

URI Template Value:

A UTF-8 encoded URI Template .

The URI Template Value MUST be a syntactically valid URI Template. The URI Template MUST be in absolute form and MUST include non-empty scheme, authority, and path components. The URI Template MUST satisfy the URI Template requirements of the MASQUE mechanism identified by the enclosing MASQUE Tunnel Encapsulation TLV. The authority component of the URI Template identifies the MASQUE proxy endpoint to which the receiver establishes the HTTP connection. The path and query components of the expanded URI identify the request target used for the corresponding CONNECT mechanism. If the URI Template Value is not a syntactically valid URI Template, if it is not in absolute form, if it does not include non-empty scheme, authority, and path components, or if it is otherwise not usable with the MASQUE mechanism identified by the enclosing MASQUE Tunnel Encapsulation TLV, the MASQUE Tunnel Encapsulation TLV MUST be ignored. The Tunnel Egress Endpoint Sub-TLV defined by is not used with MASQUE Tunnel Encapsulation TLVs because the authority component of the URI Template identifies the MASQUE proxy endpoint and provides the information necessary to establish the corresponding HTTP connection.

ALPN Sub-TLV The ALPN Sub-TLV indicates the application-layer protocol or protocols that are supported or preferred for use with the tunnel described by the enclosing Tunnel Encapsulation TLV. When used with a MASQUE Tunnel Encapsulation TLV, the ALPN Sub-TLV identifies the HTTP version or versions that can be used to establish the corresponding MASQUE tunnel. The ALPN Sub-TLV has the following format:

ALPN Sub-TLV

Type:

TBD6

Length:

The length, in octets, of the ALPN ProtocolNameList field.

ALPN ProtocolNameList:

A sequence of one or more ALPN protocol identifiers, encoded as a TLS ALPN ProtocolNameList as defined in .

The ALPN ProtocolNameList field contains one or more non-empty ALPN protocol identifiers. The order of ALPN protocol identifiers indicates preference, with the most preferred protocol listed first. When the ALPN Sub-TLV is present in a MASQUE Tunnel Encapsulation TLV, the receiver MUST use one of the advertised ALPN protocol identifiers when establishing the HTTP connection to the MASQUE proxy. If none of the advertised protocol identifiers is supported by the receiver, the MASQUE Tunnel Encapsulation TLV MUST be ignored. A MASQUE Tunnel Encapsulation TLV MUST contain at most one ALPN Sub-TLV. If more than one ALPN Sub-TLV is present, the MASQUE Tunnel Encapsulation TLV MUST be ignored. If the ALPN Sub-TLV is malformed, including if it contains an empty ProtocolNameList or an empty protocol identifier, the MASQUE Tunnel Encapsulation TLV MUST be ignored.

Use with BGP NLRI The tunnel types and Sub-TLVs defined in this document are used with the BGP Tunnel Encapsulation Attribute. This document does not define new BGP NLRI or new procedures for associating tunnel encapsulation information with routes. The NLRI to which the Tunnel Encapsulation Attribute is attached identifies the traffic, service, or reachability information to which the MASQUE tunnel applies. The tunnel type in the Tunnel Encapsulation TLV identifies the MASQUE mechanism used to carry that traffic. The following examples illustrate possible uses:

• A route that identifies IP reachability, such as an IP prefix or VPN-IP route, can use the CONNECT-IP, CONNECT-TCP, or CONNECT-UDP Tunnel Types to indicate that matching IP, TCP, or UDP traffic packets are carried using the correspondind CONNECT mechanism.
• A route that identifies Ethernet or Layer 2 service reachability, such as an EVPN route, can use the CONNECT-ETHERNET Tunnel Type to indicate that matching Ethernet frames are carried using CONNECT-ETHERNET.

Specifications or deployment profiles that use the tunnel types defined in this document may define additional rules for their use with particular AFI/SAFI combinations or service models.

Operational Considerations The tunnel types and Sub-TLVs defined in this document allow BGP to advertise MASQUE tunnel encapsulation parameters associated with BGP routes. Operators MUST ensure that these attributes are propagated only within routing domains where the advertised MASQUE proxy information is intended to be used. A URI Template carried in BGP can reveal information about proxy names, service structure, or internal topology. Operators MUST apply BGP import and export policy to avoid leaking MASQUE tunnel encapsulation information outside the intended administrative scope. Multiple MASQUE tunnel candidates can be advertised by including multiple Tunnel Encapsulation TLVs, each containing a single URI Template Sub-TLV. This can be used to advertise alternative MASQUE proxies. Selection among available tunnel candidates is left to local policy and outside the scope of this specification. A BGP Tunnel Encapsulation Attribute MAY contain both MASQUE Tunnel Encapsulation TLVs and Tunnel Encapsulation TLVs of other tunnel types defined by or subsequent specifications. This document does not define any preference between MASQUE and non-MASQUE tunnel types. Selection among available tunnel types is determined by local policy and the procedures applicable to the associated AFI/SAFI. Operators should consider the stability of URI Template values when attaching MASQUE Tunnel Encapsulation TLVs to routes. Frequent changes to URI Templates, can increase route churn. Deployments that advertise the same MASQUE proxy parameters for many routes should consider existing BGP mechanisms and service-specific profiles that avoid unnecessary repetition.

URI Template Length does not define a general maximum length for a URI Template. When a URI Template is carried in the URI Template Sub-TLV, the length of the URI Template Value is constrained by the Sub-TLV encoding and by the size of the BGP UPDATE message in which the Sub-TLV is carried. The URI Template Sub-TLV uses a two-octet Length field. This allows the URI Template Value to be longer than 255 octets. However, long URI Template Values can significantly increase the size of the enclosing BGP UPDATE message and can affect propagation across BGP sessions where BGP Extended Messages are not used. URI Template Values SHOULD NOT exceed 1024 octets and should be kept as short as practical. Deployments that carry URI Template Sub-TLVs SHOULD use BGP Extended Messages on the BGP sessions over which the corresponding routes are propagated. If BGP Extended Messages are not available, URI Template Values MUST be kept small enough that the complete BGP UPDATE message, including all path attributes, NLRI, and protocol overhead, does not exceed 4096 octets. If the URI Template Value exceeds the receiver's supported or configured limit, the receiver SHOULD ignore the enclosing MASQUE Tunnel Encapsulation TLV. If the length of the URI Template results in the BGP UPDATE exceeding the maximum message size, the result may include a lack of reachability, as detailed in . If BGP Extended Messages are partially supported, the BGP Tunnel Encapsulation Attribute may be discarded , as it is eligible under the "attribute discard" approach of , which would result in the information not reaching the intended recipients. # Security Considerations The security considerations of , , , , , , and apply. This document defines BGP signaling for MASQUE tunnel encapsulation parameters. It does not define a new authentication or authorization mechanism for MASQUE proxies, and it does not change the security properties of the MASQUE mechanisms identified by the tunnel types defined in this document. Authorization to use the MASQUE proxy, including authorization to reach the requested target or to carry the traffic associated with the route, is enforced by the MASQUE proxy and the applicable mechanisms. Implementations MUST NOT treat possession of a BGP route or Tunnel Encapsulation Attribute as sufficient authorization to use a MASQUE proxy. Misconfiguration, route leaks, or malicious injection of BGP routes carrying MASQUE tunnel encapsulation information can cause traffic to be directed to an unintended MASQUE proxy. This can result in traffic interception, denial of service, policy bypass, or loss of connectivity. Operators should apply the same route filtering, origin validation, session protection, and import/export policy controls used for other BGP routes carrying tunnel encapsulation information. For more details, see Section 11 of . The URI Template Sub-TLV can reveal information about proxy hostnames, service structure, tenant identifiers, or internal topology. Such information can be sensitive. Operators should ensure that routes carrying MASQUE Tunnel Encapsulation TLVs are distributed only within the administrative scope where the corresponding MASQUE proxy information is intended to be visible. The URI Template carried in BGP is used to construct an HTTP request target. Implementations MUST validate the URI Template before use and MUST apply the processing rules in this document and in the applicable MASQUE specification. Implementations MUST NOT expand or use a URI Template in a way that creates a request target outside the scope intended by the received route and local policy. The ALPN Sub-TLV can constrain the application-layer protocols used to establish a MASQUE tunnel. If an ALPN Sub-TLV is present, receivers MUST use only one of the advertised ALPN protocol identifiers for the corresponding tunnel. Ignoring an ALPN constraint could cause a receiver to use an HTTP version or transport that the advertising speaker did not intend to support for that tunnel.

IANA Considerations IANA is requested to update the "BGP Tunnel Encapsulation" registry group as specified in the following sections.

BGP Tunnel Encapsulation Attribute Tunnel Types IANA is requested to allocate the following values from the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry: MASQUE BGP Tunnel Encapsulation Attribute Tunnel Types

Value	Description	Reference
TBD1	CONNECT-TCP	this document
TBD2	CONNECT-UDP	this document
TBD3	CONNECT-IP	this document
TBD4	CONNECT-ETHERNET	this document

BGP Tunnel Encapsulation Attribute Sub-TLVs IANA is requested to allocate the following values from the 192-252 range in the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry: MASQUE BGP Tunnel Encapsulation Attribute Sub-TLVs

Value	Description	Reference
TBD5	URI Template	this document
TBD6	ALPN	this document

References Normative References This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels. This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired. This document describes how to proxy UDP in HTTP, similar to how the HTTP CONNECT method allows proxying TCP in HTTP. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel for UDP communications through an HTTP server that acts as a proxy. 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. Meta Platforms, Inc. TCP proxying using HTTP CONNECT has long been part of the core HTTP specification. However, this proxying functionality has several important deficiencies in modern HTTP environments. This specification defines an alternative HTTP proxy service configuration for TCP connections. This configuration is described by a URI Template, similar to the CONNECT-UDP and CONNECT-IP protocols. Google LLC This document describes how to proxy Ethernet frames in HTTP. This protocol is similar to IP proxying in HTTP, but for Layer 2 instead of Layer 3. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel to exchange Layer 2 Ethernet frames through an HTTP server with an attached physical or virtual Ethernet segment. 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. A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK] 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. Informative References The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. This document obsoletes portions of RFC 7230. 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 latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. 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. The BGP specification (RFC 4271) mandates a maximum BGP message size of 4,096 octets. As BGP is extended to support new Address Family Identifiers (AFIs), Subsequent AFIs (SAFIs), and other features, there is a need to extend the maximum message size beyond 4,096 octets. This document updates the BGP specification by extending the maximum message size from 4,096 octets to 65,535 octets for all messages except for OPEN and KEEPALIVE messages. According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368.

Acknowledgments TODO acknowledge.