A BGP route can carry a valid origin and still travel beyond the scope intended by the networks that exchanged it. That distinction matters because origin authorization and route-leak control address different properties. RFC 7908 defines a route leak as propagation of routing announcements beyond their intended scope, commonly in conflict with policies tied to customer, provider, or peer relationships.
RFC 9234 adds protocol machinery for that relationship context. BGP Roles identify the relationship at an eBGP session, while the Only to Customer attribute, abbreviated OTC, marks routes whose subsequent propagation is constrained. The mechanism targets route propagation policy; it does not turn BGP into a cryptographically authenticated path protocol.
Roles make relationship context explicit
RFC 9234 defines roles including Provider, Customer, Peer, RS, and RS-Client. Peers advertise their configured roles during BGP OPEN capability negotiation. A normal relationship has a compatible role pair, such as Provider-to-Customer or Peer-to-Peer.
This explicit context permits software to enforce propagation rules that otherwise depend heavily on operator configuration. A route received from a customer may normally be sent to customers, peers, or providers. A route received from a provider or peer has a narrower export scope: it is normally sent only toward customers.
The role mechanism does not remove local policy. An operator can still reduce the set of routes accepted or advertised. Its security value comes from giving implementations a protocol-visible relationship that can support consistent checks.
OTC carries the propagation boundary
OTC is an optional transitive BGP path attribute with type code 35. Its value is a four-octet ASN. RFC 9234 uses it to record that a route has crossed a relationship boundary after which propagation should continue only toward customers.
The central invariant is compact:
route from Provider / Peer / RS
|
OTC present
|
subsequent export
|
Customers onlyThe exact procedures depend on the local and remote BGP Roles. For example, a route carrying OTC that arrives from a Customer or RS-Client is treated as a route leak and made ineligible. A route carrying OTC from a Peer is also ineligible when the OTC ASN does not equal the remote peer ASN.
OTC can also expose a leak several AS hops after the attribute was set. If a compliant AS marks a route before sending it across a constrained relationship and that route later returns from a customer-facing direction, the retained attribute provides evidence that the propagation boundary was crossed incorrectly.
Early deployment does not require universal support
RFC 9234 includes procedures that allow a compliant local AS to add OTC when the remote side does not implement the specification. That property gives partial deployment practical value: two adjacent networks can apply the relationship model without waiting for every AS on the Internet to support it.
Partial deployment still has limits. An AS can remove OTC, alter it, or propagate routes contrary to the specified rules. RFC 9234 explicitly notes that removing or changing OTC can reduce downstream detection opportunities. OTC is therefore a policy signal carried in BGP, not a cryptographic proof that every preceding AS followed the rules.
Strict role negotiation has an availability tradeoff
BGP Role negotiation can detect incompatible role configurations at session establishment. Strict enforcement may prevent a session from coming up when the configured roles conflict or one side lacks expected support.
That behavior can catch configuration errors before route exchange, but RFC 9234 discourages implementations from making strict mode the default when a software update could unexpectedly stop an existing eBGP session. Route-leak controls sit on a critical availability path, so deployment policy has to account for both routing safety and session continuity.
OTC complements origin validation
RPKI origin validation asks whether validated authorization data permits the observed prefix and origin AS combination. A route leak can preserve that legitimate origin while violating the intended export scope somewhere later in the path. Such a route may therefore remain origin-valid.
BGP Roles and OTC operate on the propagation relationship instead. They encode whether a route has crossed a boundary after which further export is restricted. The two controls cover different failure modes and can be deployed together without treating either as a substitute for the other.
BGPsec also has a different claim. RFC 9234 notes that BGPsec protects the AS_PATH attribute, whereas OTC itself can still be removed or changed by an on-path AS. Route-origin authorization, path protection, and propagation-policy enforcement are separate security properties.
The useful claim stays narrow
OTC is effective when relationship configuration is correct and participating routers apply the specified import and export procedures. Incorrect roles can encode the wrong policy, while non-compliant or hostile ASes can disregard the signal.
That boundary is also what makes the mechanism operationally clear. BGP Roles state the relationship used for route exchange. OTC carries a propagation constraint across subsequent hops. Import checks can reject routes that arrive from a direction inconsistent with that constraint.
The result is not a general proof of BGP correctness. It is a protocol-visible guardrail for a specific class of policy violations: routes escaping the scope implied by interdomain relationships.