Route Servers (RSes) are currently a critical piece of infrastructure in all the most important IXPs worldwide. This is especially true for those environments where a huge number of peers exists (often more than a hundred).
The main role of RSes is to facilitate interconnection between multiple routers. They are a value-added service offered by IXPs and a quick shortcut to full operational status for new members. We could also describe the RS as an “enabling” service, a real “accelerator” of peering.
It replaces the configuration of n bilateral peering sessions with a single BGP session by bringing several positive aspects: it allows to receive most of the IPv4 / IPv6 prefixes reachable through the IXP at first connection, so to maximize the benefit of peering from day zero, while also acting as a backup solution for established bilateral sessions. Not to forget that, in some cases, it is the only possible solution to peer with some “big” content providers that impose a limit on minimum exchanged traffic in order to establish an individual peering session.
Over the years IXPs have increasingly used RSes, which have become more and more popular, also by expanding the features offered, especially in terms of routing security.
Any RS performs initial filtering on routes received from its peers, thus guaranteeing greater reliability of announced routes (protection against hijacks, announcement of Bogons/Martians, and default routes). RS thus takes care of applying proper input filtering to all BGP announcements, enforcing the application of security criteria, and validating received prefixes according to several policies.
Filtering is based in general on information contained in the Internet Routing Registry system as well as RPKI architecture. At a basic stage, validation is usually done by checking BGP announcements against IRRs data then, routes received from each peer in the RS infrastructure can additionally be filtered according to their RPKI ROA status. In any case, the goal is to export to peers connected to the RS a clean set of prefixes, any of which has been validated according to its originating source and announcing peer and is thus legitimated to appear on the Internet.
Prefix filtering in a real world environment
Now, how to filter on IXP Route Servers infrastructure? There are several policies and approaches that can be followed, mostly depending on the desired level of control and also on the underlying technical architecture.
The following flows represent the validation chains on both OpenBGPd and BIRD, the two most common routing daemons used inside IXP environments. When it comes to filtering, the two software have a quite different approach to the configuration: while OpenBGPd uses a rule-based evaluation approach which is typical of filtering tools such as Packet Filter (PF) or Linux Netfilter, BIRD uses a function-based approach, exploiting a configuration language that mimics the workings of common programming languages such as C.
This difference may result in minor differences in the validation chain, in both cases the evaluation flow is split into two separate chains, one that determines which prefix from a peer has the right to be inserted into the global Routing Information Base (RIB) and the other determining a separate view of this RIB based on the peer to which this RIB is exported.
Terminology
Before starting with the description of the chains, here is some terminology to fully understand how it works:
- Martian/Bogon: a “Bogon” (plural: “bogons”) is a packet with an IP source address in an address block not yet allocated by IANA or the Regional Internet Registries (ARIN, RIPE, APNIC…) as well as all addresses reserved for private or special use by RFCs. Unallocated addresses are blocks of public address space that have not been allocated by the IANA to the RIRs yet, but that could be allocated in the future.
- Blackhole community: this community (65535:666) is the BGP community used to implement the RTBH (Remote-Triggered Black-Hole) mechanism. This mechanism is used by Route Servers to divert the flow of malicious data towards a specific next-hop.
- RPKI: RPKI proves the association between specific IP address blocks or ASNs and the holders of those Internet number resources. The certificates are proof of the resource holder’s right of use of their resources and can be validated cryptographically.
- ROA: Route Origin Authorisation is the key object of BGP RPKI architecture. They can be seen as an object who proves if an AS is allowed to announce a specific IP prefix.
RPKI validation process of a BGP update is based on the comparison between the information contained in the announcement, and the ROAs present in the database of the router itself which is periodically downloaded from a RPKI Validator. There are 3 possible results of the RPKI validation process:
- Valid = RPKI Validator contains a ROA with the same ASN, and the length of the prefix netmask updated is <= of the max length specified in the ROA.
- Invalid = RPKI Validator contains a ROA but either it has a different ASN or the netmask length is > that the one specified in the ROA.
- Not found = within RPKI Validator there are no ROAs matching the update.
Filtering chain (BIRD)
Note: we apply IRR-based filtering on updates from peers, and strict filtering of ROA invalids in the export phase. As IRR and RPKI information are completely independent, the filtering strategy can be modified.
The filtering chain can be divided into two parts: the first one filters the advertisements received from peers and saves them in the Route Server’s RIB (Routing Information Base). The second part that filters updates before they are exported to peers.
Import chain
First step checks if the prefix updated by a peer is a martian/bogon prefix. If it is drop it; else go to step 2)
- Check if the IP prefix updated is a martian/bogon (based on Team Cymru resources available here).
- Check if the update has the BGP blackhole community
Step two checks if the update received has the BGP blackhole community. If yes, the Route Server changes the next hop of the update with the one of the server dummy and the prefix is accepted and stored in the RS’s RIB; else go to step 3)
- Check if updated prefix origin AS belongs to the set of allowed ASes
A set of allowed ASes for a given peer is made of its own AS plus any additional AS which is listed as a customer in a registered AS-SET. If the origin AS of the updated prefix belongs to the allowed set then go to step 4, else reject the update.
- Check if updated prefix belongs to the set of allowed prefixes
The set of allowed prefixes for a peer is built by expanding any AS included in the corresponding set of allowed ASes for the peer: for any AS in the set we look for any ROUTE objects having that AS as an origin.
If the updated prefix exactly matches one of the prefixes included in the set of allowed prefixes, then the prefix is added to the RIB; otherwise, it is rejected.
Export chain
Before the prefixes stored in Route Server’s RIB are exported to the peers, other filters are applied. This process applies on a per-neighbor basis.
- Check if the update has blackhole BGP community
First of all, it checks if the update has the blackhole BGP community: if that is the case, it applies the “no-export” BGP community (which tells the peers who receive the update not to propagate it) and the prefix is announced to the neighbor. If it hasn’t, go to the next step.
- Check if there is ROA in RPKI Validator.
It checks if the update has a corresponding ROA according to the information found in the RPKI validator. If the result is an invalid ROA, it doesn’t export it to the neighbor; else go to the next step.
- Check if the update has a BGP blocking large community
If the update has a BGP large community blocking the prefix for the specific neighbor, it doesn’t export the prefix to the neighbor; else go to the next step.
- Check if the update has a BGP blocking standard community
If the update has a BGP blocking standard community for the specific neighbor, it doesn’t export the prefix to the neighbor; else go to the next step.
- Check if the update is custom filtered
If the update is custom filtered for the specific neighbor, it doesn’t export the prefix to the neighbor; else it is announced to the neighbor.
Filtering chain (OpenBGPd)
For sake of completeness, below is the processing flow diagram for the OpenBGPd instances of the Route Server architecture, as previously stated the order of evaluation is slightly different due to implementation differences with respect to the BIRD architecture.
