Day 58 — BGP Roles and the Only-to-Customer (OTC) Attribute

1. Opening

Traditional route-leak prevention relies on operators correctly encoding business relationships in policy. RFC 9234 adds a machine-negotiated relationship concept—BGP Roles—and the Only-to-Customer attribute to help detect and prevent propagation that violates the expected customer-provider-peer model.

The recurring design principle in this security block is fail safely without confusing safety with availability. A routing control can prevent a leak and still cause an outage if thresholds, recovery logic or operator assumptions are wrong. The engineer must therefore define both the threat being contained and the service consequence of containment.

2. Concept and standards behavior

RFC 9234 defines roles such as Provider, Customer, Peer, Route Server and Route Server Client and introduces the OTC path attribute. Roles are mutually confirmed through a capability. OTC is intended to constrain where routes may be propagated according to relationship. It complements, rather than eliminates, explicit prefix and AS-path filtering.

Protocol behavior, standards recommendations, vendor implementation and local routing policy are deliberately separated. A standards document may define a capability or validation state; the router still needs explicit configuration to decide what operational action follows.

3. Scenario

Create a three-AS lab: Provider AS65020, Customer AS65010 and Peer AS65030. Establish the expected relationships. Then deliberately try to propagate a provider-learned route from AS65010 to its peer, which represents a classic valley-free policy violation.

Common lab topology

Customer AS65010 ---- Edge-1 ---- Transit-A AS65020
          |              |
          |              +---- Transit-B AS65030
          |
      203.0.113.0/24

Documentation prefixes and private ASNs are used throughout. The topology is intentionally small enough that every prefix and policy decision can be traced manually.

Success criteria

1. The protection mechanism detects the intended unsafe condition.
2. Normal routes remain reachable during the healthy state.
3. The failure action is predictable and documented.
4. A negative test proves that an unauthorized route or state is rejected/contained.
5. Rollback restores the captured baseline without weakening unrelated controls.

4. Topology diagram

A matching SVG and PNG are stored in media/diagrams/.

5. Prerequisites

• IOS XE 17.18.x documentation baseline.
• Stable eBGP sessions.
• Explicit prefix inventory and expected route counts where applicable.
• Independent management access.
• Logging and time synchronization.
• For RPKI labs: a separate validator/cache is assumed; no private keys or real production ROAs are distributed.

6. Baseline configuration

Topic-specific configuration excerpt — not a complete deployable configuration.

router bgp 65010
 ! BGP Role/OTC exact CLI is platform and release dependent.
 ! Verify support on the target IOS XE image before configuration.
 !
 ! Conventional explicit import/export filters remain required.

Any command whose exact support differs by platform must be checked against the target image before execution.

7. Verification before modification

show bgp ipv4 unicast summary
show bgp ipv4 unicast
show bgp ipv4 unicast neighbors
show logging

Topic-specific verification may add show bgp ... dampening, RPKI cache/validation output, received-prefix counts or neighbor capability/policy detail. The important question is always: what evidence proves the mechanism is acting on the intended object?

8. Controlled modification

Document the intended role on each side of every external session and compare the expected propagation matrix: customer routes may be exported broadly; provider/peer-learned routes should not be propagated to another provider/peer under normal valley-free policy.

Predict the effect on the BGP session, Loc-RIB, Adj-RIB-In/Out and forwarding state before applying the change.

9. Fault injection

Illustrative lab — not a real incident.

Simulate a customer misconfiguration that exports a provider-learned route toward a peer. Where the lab platform supports RFC 9234, inspect role/OTC handling. Otherwise model the protocol behavior and enforce the same relationship with conventional policy.

Inject exactly one fault and preserve the pre-fault evidence. Do not change multiple safety controls simultaneously.

10. Step-by-step troubleshooting

1. Confirm the affected peer and prefixes.
2. Confirm the BGP session state.
3. Confirm the expected baseline route count or route set.
4. Inspect the configured safety/validation mechanism.
5. Determine whether the mechanism changes state, rejects routes, or resets a session.
6. Inspect logs/NOTIFICATIONs/validation status.
7. Distinguish protocol state from operator policy.
8. Verify forwarding separately from BGP-table presence.
9. Test the approved positive case.
10. Test the forbidden/invalid case.
11. Correct the smallest proven cause.
12. Re-run the same evidence set and observe stability.

11. Root cause and correction

The leak exists because route propagation violates the configured business relationship. Correct the export policy and, where supported, align BGP Role/OTC configuration on both sides.

12. Post-fix verification

Verify BGP state, accepted prefix count, selected path, validation/policy state where relevant, forwarding, negative containment and recovery behavior.

13. Rollback

Restore the exact previous safety threshold or policy. Preserve evidence before clearing sessions. If rollback would re-open a known leak path or accept invalid routing data, use an approved temporary containment policy rather than blindly removing the control.

14. Deep-dive engineering notes

Roles are negotiated

A local label in documentation is not the same as a mutually confirmed BGP Role capability. Both sides need compatible role expectations for RFC 9234 behavior.

OTC is not prefix ownership

OTC addresses propagation relationship. It does not prove that the origin AS is authorized to originate a prefix. RPKI ROV solves a different problem.

Valley-free intuition

A customer can normally advertise its own/customer routes to providers and peers. A route learned from a provider or peer should not be exported to another provider or peer, because that would provide unintended transit.

Complex relationships

Some real relationships do not fit a single simple role. RFC 9234 explicitly discusses Complex relationships. Do not force a complex commercial arrangement into a false role just to enable a feature.

Defense in depth

Use Roles/OTC together with explicit import/export filters, max-prefix, RPKI/IRR data and monitoring.

15. Production lessons

• Treat role semantics as an additional leak-prevention signal.
• Do not confuse route relationship validation with origin authorization.
• Keep explicit filters even when Roles/OTC are supported.
• Document complex relationships as exceptions.
• Verify capability/attribute support on the exact platform.

16. Knowledge check

1. What failure mode is this control designed to contain?
2. What is the service consequence if it triggers incorrectly?
3. What evidence proves the control worked without causing unintended collateral damage?

Answers

1. The topic-specific leak, instability, invalid-origin or excessive-route condition.
2. Depending on the mechanism: route suppression, loss of prefixes, session shutdown or policy rejection.
3. Compare logs, route counts/validation state, forwarding and negative tests against the documented baseline.

17. Sources

• RFC 9234 — Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages
• RFC 4271 — BGP-4
• RFC 7454 — BGP Operations and Security