Gateway Auto-Discovery and Route Advertisement for Site Interconnection Using Segment Routing
Extracted elements (24)
BGP Add-Paths is insufficient for multi-gateway site interconnection because ASBRs reset the next hop when redistributing routes across AS boundaries, causing the original gateway identity to be lost. Additionally, Add-Paths experiences scaling issues across multiple ASes. The Tunnel Encapsulation attribute approach preserves all gateway information regardless of next-hop changes.
BGP peerings between gateways and ASBRs are not discovered automatically but always arise from explicit configuration. This is intentional and consistent with standard BGP operation, ensuring that the auto-discovery mechanism for gateways within a site does not weaken the security model of inter-AS BGP sessions.
Each gateway advertises a Tunnel Encapsulation attribute that is the union of all active gateways' Tunnel Encapsulation attributes for the same site. This ensures that even if only one route to a prefix reaches a remote site (due to BGP best-path selection), the remote site still learns all possible gateways and can load-balance or select among them.
Remote gateways use Tunnel Egress Endpoint sub-TLVs to identify gateways for a prefix, then compute SR TE paths using SR BGP-LS (RFC 9085). SR Egress Peer Engineering (RFC 9086) can supplement BGP-LS information for path computation across the backbone.
The Prefix-SID sub-TLV (RFC 9012) is only defined for IPv4/IPv6 Labeled Unicast routes, so the site interconnection solution described in this document only applies to routes of those types. Future use with other route types would require additional documents.
The solution is agnostic as to whether transit ASes have SR capabilities. SR is used to stitch path segments between gateways and ASBRs, requiring that gateways and ASBRs are SR capable, but transit AS internals may use IP, MPLS, SR-MPLS, or SRv6 technologies.
When using Route Target Constraint (RFC 4684) with the mechanisms in this document, operators should carefully consider the effects of filtering routes, as RTC-based filtering may limit the effectiveness of the gateway auto-discovery and route advertisement procedures.
A route target MUST be attached to each gateway's auto-discovery route, and its value MUST be set to a value that indicates the site identifier. It is RECOMMENDED that a Type x00 or x02 route target be used.
Data center operators using this approach MUST consider using gateway-to-gateway encryption to protect data center traffic, given that gateways and ASBRs are connected by tunnels that may run across untrusted network segments. Due consideration MUST also be given to encrypting end-to-end traffic.
Each gateway MUST construct an import filtering rule to import any route that carries a route target with the same site identifier that the gateway itself uses, ensuring only gateways for the same site auto-discover each other.
If a gateway becomes disconnected from the backbone network or if the site operator decides to terminate the gateway's activity, it MUST withdraw the auto-discovery and route advertisements so that remote gateways stop seeing advertisements from or about this gateway.
Site identifiers MUST be the same across all gateways to the same site, and MUST be unique across all sites that are interconnected. These identifiers are set through configuration and require coordination across gateways.
The address advertised for auto-discovery MUST be a different loopback address than is advertised for packets directed to the gateway itself, to avoid the side effect of applying the Tunnel Encapsulation attribute to packets addressed to the gateway.
The same site identifier MUST be assigned to every gateway to the same site, and each site MUST have a different identifier. This requires coordination, probably through a central management agent, as misconfiguration results in gateways failing to auto-discover each other.
Each gateway includes a Tunnel Encapsulation attribute with encapsulation information for all of the site's active gateways (including itself) in every route advertised externally. When the set of active gateways changes, each externally advertised route is re-advertised with a new Tunnel Encapsulation attribute reflecting the current set.
Each Tunnel TLV in the Tunnel Encapsulation attribute contains a Tunnel Egress Endpoint sub-TLV that identifies the gateway for that Tunnel TLV, preserving gateway identity across AS boundaries even as next-hop addresses change.
For MPLS SR, each gateway to an egress site may compute an SR TE path through the egress site to prefix X and place it in an MPLS Label Stack sub-TLV (RFC 9012) in the SR Tunnel TLV for that gateway, allowing ingress sites to perform SR TE through the egress site.
If a site is configured to allow native encapsulation, each gateway to the site includes multiple instances of a Tunnel TLV for the native encapsulation in externally advertised routes — one per gateway — each containing a Tunnel Egress Endpoint sub-TLV with the gateway's address.
The auto-discovery route advertised by each gateway consists of IPv4 or IPv6 NLRI containing one of the gateway's loopback addresses (AFI/SAFI: 1/1, 2/1, 1/4, or 2/4), plus a Tunnel Encapsulation attribute containing the gateway's encapsulation information in one or more Tunnel TLVs.
To carry the receiving gateway's SID for prefix X, each Tunnel TLV in the Tunnel Encapsulation attribute contains a Prefix-SID sub-TLV (per RFC 9012) for X. This SID becomes the next SID processed before the gateway completes packet processing.
IANA maintains the 'BGP Tunnel Encapsulation Attribute Tunnel Types' registry in the 'Border Gateway Protocol (BGP) Tunnel Encapsulation' registry. The previously assigned value 17 for 'SR Tunnel' referencing this document has been marked as deprecated; IANA may reclaim that codepoint when the registry is depleted.
A malicious internal node without external BGP peering may get itself advertised as a gateway by speaking BGP to genuine gateways within the site, causing those gateways to include it in externally advertised Tunnel Encapsulation attributes. This allows the malicious node to attract traffic without requiring secure BGP peerings with out-of-site nodes.
If BGP messages within the backbone can be modified, it may be possible to spoof the existence of a gateway, causing traffic to be attracted to a specific node and potentially resulting in traffic not being delivered. Existing protocol mechanisms such as securing TCP sessions over which BGP flows SHOULD be used to protect against these exposures.
The gateway auto-discovery mechanism exposes the full set of gateways to a site across the backbone and into remote sites, enabling more comprehensive attacks. An attacker knowing all gateways could mount a coordinated Denial-of-Service attack against all gateways simultaneously, negating the resiliency benefit of multiple gateways.