BGP Signaling of MASQUE Tunnel Encapsulation

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 31 December 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The BGP Tunnel Encapsulation Attribute [BGP-TUNNEL-ENCAP-ATTR] 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 [CONNECT-UDP], proxying IP packets using CONNECT-IP [CONNECT-IP], proxying TCP connections using CONNECT-TCP [CONNECT-TCP], and proxying Ethernet frames using CONNECT-ETHERNET [CONNECT-ETHERNET]. These mechanisms allow traffic to be carried over HTTP/1.1 [HTTP/1.1], HTTP/2 [HTTP/2], or HTTP/3 [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.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses terminology from [BGP-TUNNEL-ENCAP-ATTR], [CONNECT-UDP], [CONNECT-IP], [CONNECT-TCP], and [CONNECT-ETHERNET].¶

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 [URI-TEMPLATE]. 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 [ALPN].¶

3. 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 Section 4. 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 Section 5, 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:¶

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.¶

4. 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:¶

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Type=TBD5   |           Length              |               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
 ~                     URI Template Value                        ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:

TBD5¶

Length:

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

URI Template Value:

A UTF-8 encoded URI Template [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 [BGP-TUNNEL-ENCAP-ATTR] 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.¶

5. 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:¶

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Type=TBD6   |           Length              |               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
 ~                       ALPN ProtocolNameList                   ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 Section 3.1 of [ALPN].¶

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.¶

6. 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.¶

7. 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 [BGP-TUNNEL-ENCAP-ATTR] 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.¶

8. IANA Considerations

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

9. References

Acknowledgments

TODO acknowledge.¶

Authors' Addresses