Internet Exchange BGP Route Server
Extracted elements (21)
A route server exchanges routing information using EBGP but does not forward traffic itself and is therefore not a router. It is analogous to a route reflector (RFC 4456) but operates using EBGP instead of IBGP.
ADD-PATH (RFC 7911) on a route server should enforce send-only mode with clients to prevent route server clients from propagating multiple paths—including inactive or suboptimal ones—back to the route server, which could cause loss of reachability to other clients.
Attribute transparency is the default because modification of BGP attributes could cause route server clients to alter their BGP Decision Process, thereby changing the intended routing policies of exchange participants. The route server acts as a broker, not a policy enforcer.
The AS_PATH non-prepend behavior is a SHOULD rather than a MUST solely to provide backwards compatibility with legacy route server client implementations that do not support accepting UPDATE messages where the leftmost AS differs from the route server's AS.
The diverse BGP path approach (RFC 6774) distributes multiple paths via separate BGP sessions per path, but is constrained by the number of configured sessions and may not eliminate path hiding in all cases; it can also significantly increase the number of BGP sessions the route server must handle.
The most portable mitigation for path hiding is to use per-client Loc-RIBs, performing the best path calculation separately for each client after applying that client's policies. Implementations can optimize by storing per-client Loc-RIBs as deltas from a global Loc-RIB.
If ADD-PATH capability is negotiated bidirectionally between a route server and a client, and the client propagates multiple paths for the same prefix to the route server, this can cause propagation of invalid or suboptimal paths; ADD-PATH should therefore be negotiated in send-only mode from the route server.
Route server clients must be able to accept UPDATE messages where the leftmost AS in the AS_PATH attribute is not equal to the AS number of the route server that sent the message, as route servers typically do not prepend their own AS number.
A route server MUST accept all UPDATE messages received from each of its clients for inclusion in its Adj-RIB-In. These UPDATE messages MAY be omitted from the route server's Loc-RIB or Loc-RIBs due to policy filters.
BGP Communities and Extended Communities attributes on an NLRI UPDATE sent to a route server SHOULD NOT be modified, processed, or removed except as defined by local policy; if intended for processing by the route server itself, they MAY be modified or removed.
Optional recognized and unrecognized BGP attributes, whether transitive or non-transitive, SHOULD NOT be updated by the route server and SHOULD be passed on to other route server clients.
Route server client BGP implementations that perform a check that the leftmost AS in AS_PATH equals the sending peer's AS MUST allow this check to be disabled, and SHOULD allow it to be disabled on a per-peer basis.
Route servers SHOULD NOT by default update well-known BGP attributes received from route server clients before redistributing them to other route server clients, unless explicitly configured to do so.
The AS_PATH leftmost-AS check SHOULD NOT be disabled by IXP participants unless it is needed to establish BGP sessions with a route server and, if possible, should only be disabled for peers that are route servers.
The MULTI_EXIT_DISC attribute applied to an NLRI UPDATE sent to a route server SHOULD be propagated to other route server clients, and the route server SHOULD NOT modify its value, contrary to RFC 4271 Section 5.1.4.
The NEXT_HOP attribute MUST be passed unmodified to route server clients, similar to the third-party next-hop feature in RFC 4271 Section 5.1.3, because the route server does not participate in actual traffic routing.
The route server SHOULD NOT prepend its own AS number to the AS_PATH segment nor modify the AS_PATH segment in any other way, differing from the behavior required by RFC 4271 Section 5.1.2.
The route server SHOULD perform one or more BGP Decision Processes to select routes for subsequent advertisement to its clients, and SHOULD forward UPDATE messages from its Loc-RIB or Loc-RIBs to clients as determined by local policy.
Path hiding occurs when a route server applies per-client policy to filter the calculated best path from reaching a particular client, while an alternate policy-compliant path exists but is never selected because the BGP Decision Process runs only once for all clients.
Disabling the AS_PATH leftmost-AS check removes a safeguard against malformed UPDATE messages and BGP loop detection. Operators should only disable it when necessary to peer with a route server and, if possible, only on a per-peer basis for route server peers.
The path-hiding problem can be exploited to proactively block third-party path announcements from other route server clients. Route server operators should be aware of this risk and take steps to mitigate against path hiding.