Outbound Route Filtering Capability for BGP-4
Extracted elements (23)
A single ROUTE-REFRESH message may carry multiple ORF entries in one or more ORFs provided all entries share the same AFI/SAFI. A speaker can distinguish an ORF-carrying ROUTE-REFRESH from a plain one by inspecting the BGP message header's Length field.
ORF was introduced because BGP speakers commonly receive and then filter out unwanted routes from peers, wasting resources on both the sender (generating/transmitting updates) and receiver (processing them). Allowing the receiver to push filters to the sender avoids generating unwanted updates in the first place.
A BGP speaker advertising the Outbound Route Filtering Capability is not required to also advertise the BGP Route Refresh Capability to the same peer, even though ORF entries are carried in ROUTE-REFRESH messages.
A BGP speaker that implements the Outbound Route Filtering Capability MUST support the BGP ROUTE-REFRESH message. A speaker advertising the ORF Capability does not have to separately advertise the BGP Route Refresh Capability to that peer.
After a speaker changes previously-sent ORF entries, it MUST send updated ORF entries with either When-to-refresh=IMMEDIATE, or When-to-refresh=DEFER followed by a plain ROUTE-REFRESH. The latter MUST be used when other policy changes also require the peer to re-advertise all routes.
If a route does not match any ORF entry of any non-empty ORF associated with a peer, that route SHOULD NOT be advertised to the peer.
If an <AFI/SAFI, ORF-type> in a received ROUTE-REFRESH message does not match what the speaker advertised willingness to receive, those ORF entries are ignored. If any field of an ORF entry contains an unrecognized value, the entire previously-received ORF for that type is removed.
When a speaker maintains multiple ORFs of different ORF-Types for a peer, the decision to advertise a route is made by passing it through each ORF and combining results such that any DENY result combined with PERMIT yields DENY.
When a speaker willing to receive a set of <AFI/SAFI, ORF-Type> and a peer desiring to send that same set have a non-empty intersection for a given AFI/SAFI, the speaker SHOULD NOT advertise routes with that AFI/SAFI prior to receiving a ROUTE-REFRESH from the peer for that AFI/SAFI (with or without ORF entries, or with When-to-refresh=IMMEDIATE).
When an ORF is defined, an ORF-specific matching rule MUST be specified so that there is no ambiguity regarding which ORF entry is considered the matching entry when a route is passed through the ORF.
When When-to-refresh is DEFER, re-advertisement is deferred until the speaker receives a subsequent ROUTE-REFRESH for the same AFI/SAFI either without ORF entries or with When-to-refresh=IMMEDIATE. ORF entries with REMOVE or REMOVE-ALL cannot remove locally configured outbound route filters.
When When-to-refresh is IMMEDIATE, after processing all ORF entries the speaker MUST re-advertise all routes from Adj-RIB-Out affected by those entries, and MAY also re-advertise unaffected routes with the same AFI/SAFI.
An ORF entry is a tuple of <AFI/SAFI, ORF-Type, Action, Match, ORF-value>. An ORF consists of one or more entries sharing the same AFI/SAFI and ORF-Type, and is identified by <AFI/SAFI, ORF-Type>. The AFI/SAFI component limits the ORF to routes whose NLRI matches it.
The Action component of an ORF entry controls handling by the remote peer: ADD adds an entry to the ORF, REMOVE deletes a previously installed entry, and REMOVE-ALL deletes all previously installed entries for the specified ORF type.
The lifetime of an ORF is bounded to the duration of the BGP session during which it is exchanged. An ORF is removed when the last ORF entry is removed, either via REMOVE-ALL or via a sequence of REMOVE operations.
The Match component specifies per-entry matching semantics: PERMIT asks the peer to pass updates for routes matching the entry, and DENY asks the peer not to pass updates for routes matching the entry.
The Send/Receive field in the ORF Capability indicates whether the sender is willing to receive ORF entries from the peer (value 1), would like to send ORF entries to the peer (value 2), or both (value 3) for the specified ORF-Type.
The When-to-refresh field (1 octet) in the ROUTE-REFRESH message takes the value IMMEDIATE (0x01) or DEFER (0x02), controlling whether the peer re-advertises affected routes immediately after processing the ORF entries or waits for a subsequent trigger.
IANA created the 'BGP Outbound Route Filtering (ORF) Types' registry. Value 0 is reserved; 1–63 require Standards Action or Early IANA Allocation; 64–127 are First Come First Served; 128–255 are vendor-specific and not assigned by IANA. The ORF Capability itself is assigned Capability Code 3.
This extension to BGP does not change the underlying security issues of BGP-4. No new security vulnerabilities or mitigations are introduced by the ORF mechanism.
Each ORF entry begins with a common one-octet header: Action (2 bits, 0=ADD/1=REMOVE/2=REMOVE-ALL), Match (1 bit, 0=PERMIT/1=DENY), Reserved (5 bits set to 0 on transmit). When Action is REMOVE-ALL, the entry consists of only this common part.
ORF entries are carried in the BGP ROUTE-REFRESH message. The message header contains AFI (2 octets), Reserved (1 octet), SAFI (1 octet), When-to-refresh (1 octet), followed by groups of ORF-Type (1 octet), Length of ORF entries (2 octets), and the variable-length ORF entries.
The Outbound Route Filtering Capability (Capability Code 3) encodes one or more entries each containing: AFI (2 octets), Reserved (1 octet), SAFI (1 octet), Number of ORFs (1 octet), and per ORF-Type: ORF-Type (1 octet) and Send/Receive (1 octet).