skip to content

What is the valley-free rule in BGP routing, and how do RFC 9234's BGP Roles and Only-to-Customer attribute stop leaks that break it?

level: seniorimportance: should knowfreq 16%

answer

  1. customer, provider, lateral peer
  2. up, at most one across, then down
  3. Role pairs confirmed in OPEN
  4. capability code 9, attribute type 35
  5. OTC set once, never removed

basics

~20 s

A valley-free path climbs customer-to-provider links, crosses at most one peer link, then only descends: routes from a provider or peer go only to customers. BGP Roles confirm each session's relationship, and the OTC attribute marks routes that may only travel down.

solid answer

~50 s

Routes follow business relationships: an AS sends its customers everything, but sends providers and lateral peers only its own and its customers' routes. A path that obeys this goes up through providers, across at most one peer link, then down, so it has no **valley**; RFC 7908's leak types are valleys. RFC 9234 encodes the rule. Each side configures a **BGP Role** (Provider, Customer, Peer, RS, RS-Client) and advertises it in OPEN with capability code 9; mismatched pairs are refused with a Role Mismatch NOTIFICATION. The **Only to Customer** (`OTC`) attribute, optional transitive type 35, is added when a route is sent to a customer, peer or RS-client, or on ingress from a provider, peer or RS. A route carrying `OTC` must not go to providers, peers or route servers, and one arriving from a customer, or from a peer with a foreign value, is an ineligible leak.

go deeper

for a junior

Recall the three relationships, customer, provider and lateral peer, and that routes from providers or peers go only to customers.

for a middle

Explain the up, across once, down shape of a valley-free path and map the hairpin, lateral and peer-to-provider leaks onto it.

for a senior

Walk the OTC ingress and egress rules through a leak, explain Role negotiation and strict mode, and say what an operator gains as an early adopter.

for a principal

Position Roles and OTC as cheap protection against accidents and decide what covers the deliberate leaker and the complex relationship they cannot express.

## Relationships and the export rule Inter-domain routing follows a small set of relationships, sometimes called the Gao-Rexford model. A **customer** pays a **provider** for transit; two **lateral peers** exchange their own and their customers' traffic without payment; a **route server** at an exchange point redistributes routes among its **clients**. RFC 9234 turns the resulting export rule into protocol text: | Role of the local AS | May propagate to that neighbour | |---|---| | Provider | any available route, to its customer | | Customer | only locally originated routes and routes from its own customers, to its provider | | Peer | only locally originated routes and routes from its own customers, to the peer | | RS | any available route, to its RS-clients | | RS-Client | only locally originated routes and routes from its own customers, to the RS | ## What a valley looks like Read an AS path from the origin outward. A legitimate path goes **up** (customer to provider) zero or more times, crosses **at most one** peer link, then goes **down** (provider to customer). A route that goes down and then up again, or crosses a peer link and then goes up or across again, forms a valley. RFC 7908's first four leak types are exactly these valleys: - **Type 1, hairpin**: provider to customer, then customer to another provider. - **Type 2, lateral**: peer to peer, then on to another peer. - **Type 3**: provider's routes passed to a peer. - **Type 4**: peer's routes passed to a provider. Base BGP cannot see any of this: the `AS_PATH` lists ASes but not the relationships between them, and loop detection never fires. ## BGP Roles: agreeing on the relationship 1. Each eBGP session SHOULD be configured with one Role. 2. The speaker advertises it in the OPEN message as the BGP Role capability, code 9, one octet: Provider 0, RS 1, RS-Client 2, Customer 3, Peer 4. 3. The two Roles must pair as Provider with Customer, RS with RS-Client, or Peer with Peer; any other pair is rejected with the Role Mismatch NOTIFICATION, error code 2, subcode 11. 4. If the neighbour sends no Role, the session normally proceeds on the local Role; an operator may choose **strict mode**, which rejects such a session instead. ## The OTC attribute, step by step `OTC` is an optional transitive path attribute, type code 35, four octets holding an AS number. Ingress rules: 1. A route with `OTC` received from a Customer or RS-Client is a leak and MUST be ineligible. 2. A route with `OTC` received from a Peer whose value is not that peer's AS is a leak and MUST be ineligible. 3. A route received from a Provider, Peer or RS without `OTC` gets one, set to the neighbour's AS. Egress rules: 1. A route sent to a Customer, Peer or (by an RS) RS-Client without `OTC` gets one, set to the local AS. 2. A route that already carries `OTC` MUST NOT be sent to Providers, Peers or RSes. Once set, the value is preserved unchanged. ## A leak walked through AS 64500 has two lateral peers, AS 64501 and AS 64502, and one provider, AS 64503. 1. AS 64501 sends its customer's route `198.51.100.0/24` to peer AS 64500 and adds `OTC 64501` on egress. 2. If AS 64500 is compliant, egress rule 2 stops the route going to AS 64502 or AS 64503: prevention. 3. If AS 64500 is misconfigured and leaks it to its provider anyway, a compliant AS 64503 receives an `OTC` route from a customer: ineligible. 4. If AS 64500 leaks it to peer AS 64502, a compliant AS 64502 sees `OTC 64501` from peer AS 64500: value mismatch, ineligible. Because a compliant receiver adds the attribute itself when the sender did not, early adopters protect themselves without waiting for everyone else. ## Limits - **Accidents, not attacks.** An AS can strip `OTC` and then leak; RFC 9234 says so, and notes BGPsec protects only `AS_PATH`. - **Wrong Roles.** A session to an upstream provider wrongly labelled as a customer session would let routes from other providers and peers flow up it; Role confirmation makes that unlikely, not impossible. - **Scope.** The procedures apply to IPv4 and IPv6 unicast only, and are not recommended between members of a confederation. - **Complex relationships.** A neighbour that is a provider for some prefixes and a peer for others cannot be given a single Role.

  • Two BGP neighbours configure Customer and Peer roles for the same session. What happens?
    If both send the BGP Role capability, Customer-Peer is not an allowed pair, so RFC 9234 requires the speaker to reject the connection with the Role Mismatch NOTIFICATION, error code 2, subcode 11. The session stays down until one side fixes its Role. That is the point: a mislabelled relationship is caught before routes flow, not after a leak.
  • Can the OTC attribute stop an AS that leaks routes deliberately?
    No. A malicious AS can remove OTC from a received route and then announce it to its provider, and nothing in RFC 9234 detects the removal. OTC is designed for the common case, misconfiguration. ASPA, still an IETF draft, targets that gap: it checks a path against the providers each AS registered in the RPKI, so it does not depend on the leaker's cooperation.

saying these in an interview costs you the question

  • A valley-free path may cross any number of peer links.
  • A peer may pass routes learned from its providers on to another peer.
  • Only the AS that originates a prefix sets the OTC attribute.
  • A BGP Role is a local label that is never sent to the neighbour.
  • OTC still protects against an AS that deliberately strips it before leaking.