Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages
Extracted elements (28)
BGP Role negotiation was designed as an in-band replacement for purely operator-driven, configuration-based route leak prevention, which had no mechanism to verify that both eBGP speakers agreed on the peering relationship. By encoding the role in OPEN messages, both sides must concur.
Strict mode (requiring the peer to also send a BGP Role Capability) is deliberately not the default; making strict mode default could cause eBGP sessions to fail after software updates against non-compliant peers. Implementations defaulting to strict mode are strongly discouraged.
The OTC Attribute value is set identically whether applied at the egress of the remote AS or at the ingress of the local AS, so if the remote AS is non-compliant the local AS compensates without disagreement. This makes the scheme robust and benefits early adopters before universal deployment.
In AS migration scenarios (RFC 7705) where a router may represent multiple ASes, OTC Attribute procedures remain valid because the egress procedures attach the OTC value equal to the ASN the router is currently representing, preserving correctness regardless of migration state.
The BGP Role negotiation and OTC Attribute procedures are NOT RECOMMENDED between ASes within an AS Confederation (RFC 5065). If an OTC Attribute exits the Confederation, its value MUST equal the AS Confederation Identifier, not any Member-AS Number.
Use of BGP Roles and OTC Attributes in networks with private AS numbers behind an Internet-facing ASN (e.g., data-center BGP per RFC 7938) is permitted, but on egress from the Internet-facing AS the OTC Attribute MUST NOT contain any value other than the Internet-facing ASN.
Customer and Peer roles MUST NOT propagate routes learned from Providers, Peers, or RSes to other Providers, Peers, or RSes. Only routes from Customers or locally originated routes MAY be propagated upward or laterally.
For backward compatibility, if the BGP Role Capability is sent but none is received, the BGP speaker SHOULD ignore the absence and proceed with session establishment using the locally configured role.
If a route is received from a Provider, Peer, or RS and the OTC Attribute is not present, it MUST be added with a value equal to the AS number of the remote AS (ingress procedure).
If a route with the OTC Attribute is received from a Customer or RS-Client, it MUST be considered ineligible (route leak detected). If received from a Peer with an OTC value not equal to the Peer's AS number, it also MUST be considered ineligible.
If both peers advertise BGP Role Capabilities, the roles MUST correspond to one of the allowed pairs in Table 2 (Provider/Customer, RS/RS-Client, Peer/Peer). If they do not correspond, the speaker MUST reject the connection using the Role Mismatch Notification (code 2, subcode 11).
If the BGP Role is locally configured, the eBGP speaker MUST advertise the BGP Role Capability in the BGP OPEN message, and MUST NOT advertise multiple versions of the BGP Role Capability.
In strict mode, if the BGP Role Capability is sent but none is received from the remote AS, the connection MUST be rejected using the Role Mismatch Notification (code 2, subcode 11).
Once the OTC Attribute has been set, it MUST be preserved unchanged, including within an AS Confederation.
Roles MUST NOT be configured on an eBGP session with a Complex peering relationship. If multiple eBGP sessions can segregate the Complex relationship into normal peering relationships, BGP Roles SHOULD be used on each resulting session.
The OTC Attribute is considered malformed if its length value is not 4. An UPDATE message with a malformed OTC Attribute SHALL be handled using the 'treat-as-withdraw' approach per RFC 7606.
The OTC ingress and egress procedures apply ONLY to AFI 1 (IPv4) and AFI 2 (IPv6) with SAFI 1 (unicast), and MUST NOT be applied to other address families by default. The operator MUST NOT have the ability to modify these procedures.
When advertising a route to a Customer, Peer, or RS-Client and the OTC Attribute is absent, an OTC Attribute MUST be added with a value equal to the local AS number (egress procedure). If a route already contains the OTC Attribute, it MUST NOT be propagated to Providers, Peers, or RSes.
BGP Role Capability (Capability Code 9) is a new BGP capability advertised in OPEN messages. It has a Length of 1 octet and a Value field encoding the speaker's role (0=Provider, 1=RS, 2=RS-Client, 3=Customer, 4=Peer, 5-255=Unassigned).
The Only to Customer (OTC) Attribute is an optional transitive BGP Path Attribute with Type Code 35 and a fixed length of 4 octets. Its value is an AS number indicating the AS at which the route was last propagated laterally or upward, enforcing downstream-only propagation thereafter.
IANA created the 'BGP Role Value' subregistry within the 'Capability Codes' registry, with values 0–4 assigned (Provider, RS, RS-Client, Customer, Peer) and values 5–255 unassigned. Future assignments require IETF Review.
IANA registered a new BGP Path Attribute named 'Only to Customer (OTC)' with Type Code 35 in the 'BGP Path Attributes' registry.
IANA registered BGP Capability Code 9 as 'BGP Role' in the 'Capability Codes' registry. IANA also registered OPEN Message Error subcode 11 as 'Role Mismatch' in the 'OPEN Message Error subcodes' registry, and marked subcodes 8–10 as Deprecated.
Adding an OTC Attribute on a Customer-to-Provider advertisement will cause the route to be considered ineligible by the Provider and its upstream peers, limiting propagation unpredictably. This could be exploited as a denial-of-reachability attack.
An on-path attacker can remove or modify the OTC Attribute to circumvent route leak detection, then re-advertise a leaked route upward. This threat is inherent to BGP attribute manipulation and is not addressed by this specification (BGPsec only protects AS_PATH).
Misconfiguration of BGP Role can affect prefix propagation: assigning Provider/Peer Role to a downstream link limits advertisements in that direction, while assigning Customer Role to an upstream provider may cause route leaks to other Providers or Peers. Role negotiation makes such misconfigurations unlikely but not impossible.
BGP Role negotiation during OPEN: if both peers send Role Capability, roles are checked against Table 2 allowed pairs — match leads to session establishment; mismatch triggers Role Mismatch Notification and session rejection. If only one peer sends Role Capability, default mode proceeds; strict mode rejects.
The BGP Role Capability encodes as: Code=9, Length=1 (octet), Value=integer from 0–4 (Provider/RS/RS-Client/Customer/Peer). Multiple BGP Role Capabilities with differing values in the same OPEN message are an error.