The core BGP Security recommendation is for all BGP Ingress & Egress Filtering to follow BCPs. These BGP Best Common Practices (BCPs) are not confidential. Your peers would be open to share what they do and help you deploy better policies. It is recommended that you inspect your network’s practices and procedures. Review the BCP gaps, areas of improvement, then build an action plan to iterate improvements.
Remember, most of the common BGP Hijacking Risk can be minimized through practical BGP BCPs for deployment and operations. A typical BGP Peering session would have the policy applied in two directions:
- Ingress BGP Policy to control all prefixes which are sent to the ASN. This Ingress filter should be in sync with the peer’s Egress BGP Policy. The Ingress BGP policy is designed to be explicit deny. The only prefixes which are accepted are those which are explicitly permitted.
- Egress BGP Policy to control all prefixes which are sent to the ASN’s peer and the Internet. The Egress BGP Policy would mirror the Ingress BGP Policy of their peer. The Egress BGP Policy would be set up as an explicitly deny filter. The only prefixes exported (egress) would those explicitly permitted in the policy.
Two core principles apply to today’s BGP Best Common Practices. First, the Ingress and Egress Policies on the peered session mirror each other. This requires coordination with the peer to ensure the filtering matches. Second, both the ingress and egress filters use an explicit deny policy. That means everything is filtered when there are no “permit” statements. Explicit deny (i.e. deny all) minimizes risk if there is something wrong with the prefix filter or an unexpected prefix injection happen on the Internet.
BGP Ingress Policy Checklist
INGRESS Policy allows BGP routes to come into your organization. BGP Ingress Policy is applied in stages with each stage with a different policy role. The stages depend on the vendor’s BGP implementation (or the BGP Open Source implementation). As a general rule of thumb, the following policy flow can be used as a guide. Through all these checks, remember that the policy would be a default deny, requiring an explicit permit.
1. Dynamic Maximum Prefix Sessions
It is not logical to have 20,000,000 prefixes received from the Internet. Max Prefix rule will look at the total number of prefixes received from the peer and set a threshold that will stop all further updates. The Operator would set this threshold as a “safeguard” for maximum prefix injection attacks or mistakes. Max Prefix Attack’s is where someone intentionally sends millions of prefixes into the Internet to cause instability. Max Prefix injection mistakes happen when there is a human, machine, or equipment error. Both will cause damage if there are no maximum prefix limits set on the ingress session.
2. Reject Bogon & RIR Minimum Prefixes
Bogon Prefixes are those reserved routes and unallocated prefixes which should not be advertised to the Internet. Bogons are defined as Martians (private and reserved addresses defined by RFC 1918, RFC 5735, and RFC 6598) and netblocks that have not been allocated to a regional internet registry (RIR) by the Internet Assigned Numbers Authority. A “full Bogon” prefixes beyond the Regional Internet Registry “Minimal Allocatable Prefixes.” Filtering on the RIR Minimums prevent operators advertising /26, /27, /28, and other large IPv4 prefixes. This route filter has been called the “Net Police” approach and proved operationally beneficial.
3. Reject Bogon ASNs
There are ASNs which should never appear on the Internet. These Bogon ASNs have been and can be used for malicious activities. They can also appear from human error (connecting a lab network to the Internet by mistake.). NTT has provided a leadership example illustrating how BGP ASN filtering can be used to minimize risk on the Internet. NTT, AS 2914, will not accept route announcements from any eBGP neighbor which contains a Bogon ASN anywhere in the AS_PATH or its atomic aggregate attribute. NTT’s state reasoning behind this policy is twofold and helps illustrate the risk:
- Private or Reserved ASNs have no place in the public DFZ. Barring these from the DFZ helps improve accountability and dampen accidental exposure of internal routing artifacts (minimizing human error).
- All AS2914 devices support 4-byte ASNs. Any occurrence of “23456” in the DFZ is either a misconfiguration or software issue.
NTT (and others) are undertaking this effort to improve the quality of routing data as part of the global ecosystem. This should improve the security posture and provide additional certainty to those undertaking network troubleshooting (see The Harmful Consequences of Postel’s Maxim). Bogon ASNs are currently defined as follows:
| 0 | # Reserved RFC7607 |
| 23456 | # AS_TRANS RFC6793 |
| 64496-64511 | # Reserved for use in docs and code RFC5398 |
| 64512-65534 | # Reserved for Private Use RFC6996 |
| 65535 | # Reserved RFC7300 |
| 65536-65551 | # Reserved for use in docs and code RFC5398 |
| 65552-131071 | # Reserved |
| 4200000000-4294967294 | # Reserved for Private Use RFC6996 |
| 4294967295 | # Reserved RFC7300 |
A current overview of what are considered Bogon ASNs is maintained at NTT’s Routing Policies page. The IANA Autonomous System Number Registry is closely tracked and the NTT Bogon ASN definitions are updated accordingly. NTT encourage network operators to consider deploying similar policies. Configuration examples for various platforms can be found here:
- http://as2914.net/bogon_asns/configuration_examples.txt
- http://bgpfilterguide.nlnog.net/guides/bogon_asns/
- BOGON ASNs MUST DIE (presentation by Job Snijders)
4. Reject IXP Prefixes
Internet Exchange Points (IXPs) will have IPv4/IPv6 prefixes for the IXP fabric. Many of these prefixes are specifically allocated to the IXPs as critical infrastructure. They should not appear in the global routing table. It is best practice to include all IXP prefixes for which you are connected in the ingress and egress route filters.
There are no standard templates for IXP Prefix filters. Each operator will have a list depending on the IXPs for which they have peered.
5. Reject Leakage with the Peer Locking Filter
Peer Locking is an emerging technique for projecting routing security one AS deeper into the Internet. Peer Locking uses a “secure what are within your zone of influence” approach. Operators who participate with Peer Locking enter into an agreement with their Peering partners who are directly connected (private connections or IXP connections).
The partner provides to pieces of information, their ASN which is to be protected (and connected) and any upstream operator who they authorize to route their ASN’s prefixes. As Job Snijders explains its operation in NTT (see below), Peering partner A is in “Peer Locking” with NTT. Peering Partner A states that prefixes with their ASN or via Peering Partner B are OK AS paths. If NTT sees their ASN from any other path, it would be seen as invalid and dropped. Peering Partner A has just expanded their “zone of prefix trust” one ASN deeper into NTT. Vice Versa, NTT has expanded their “zone of prefix trust” one ASN deeper into Peering Partner A.
Note, there is nothing wrong with NTT’s peering connections with Peer C, D, or E. In the illustration, if there is a human/machine mistake and a route is leaked out of Peer A, then NTT will contain that mistake with the PeerLock rules. In addition, if there is a BGP Prefix Hijack over Peers C or D, with Peer A’s AS path, that would also be “contained.”
This approach expands the zone for which an organization’s trust is now one ASN deeper into the organization. The power of Peerlock is in the numbers who participate. If Peer A peer locks with NTT, your areas of routing security are now two ASNs deep in both directions. Now if Peer A expand to Peer Z while NTT expands Peer Locking Peer B the result is a BGP prefix security depth has expanded 4 deep. This continues with Peer B expanding their Peer Locking to Peer M.
In essence, Peer Locking allows for Operators to take control over their BGP Prefix Hijacking and Route Leak Risk. The approach slowly expands their zone of prefix trust, adding resilience to their network interconnections.
NTT through Job Snijders has validated, documented, and deployed Peerlock with public material all Operators can use for their own Peerlock processes. The following are excellent resources to review to learn more about Peerlock. The good news for any Operator is that there are people who are willing to help with your organization’s Peerlock approach.
6. Match against the IRR Whitelist (only customers)
All customer connections must have an explicit permission of their prefixes. Notice that up to this point, all the REJECTS. This is the first place where prefixes are PERMITTED. The Internet community has posted a wide range of open source IRR Tools that would manage the BGP Peering sessions for all customers. There are Operators in the world who have scripts set up to deploy customer BGP sessions for thousands of BGP sessions. Many of the engineers in their Operator share their experience of how they are doing this automation, with many posting their scripts/code via Open Source Repositories.
7. Mark as Customer Route (or as peer route)
One a customer route is permitted, it would be marked with a BGP Community. This allows additional policies and services to apply to the customer prefixes. The new BGP Large Communities Attribute (RFC 8092) provides operators with more than enough BGP community space to create unique BGP Community policies. The first step is to mark all customers BGP prefixes with a community.
8. Scrub Internally Significant BGP Communities
There will be BGP Communities that are used inside the Operator’s network but are not authorized by the Customer. These could also come in from other Operators by mistake or abused by miscreants as part of BGP Prefix injection community attacks.
For example, NTT would not want some route to come in with 2914:666 that kicks in a Black Hole for that prefix (see a detailed list of NTT’s routing policies).
This step is also a place to remove excess BGP communities. BGP communities have a potential to be abused. Adding 20 BGP Communities to 10,000 de-aggregated prefixes will consume memory and CPU on routers. If something like this happens, the “removing internally significant BGP communities” filtering phase would be the perfect place to mitigate the incident.
9. Apply BGP Features
BGP Features are Local Pref, BGP Black Holes, and other functionality the Operator will provide their customers and peers. NTT provides a good example on their Routing Policies and Procedures Page.
BGP Egress Policy Checklist
EGRESS Policy is applied to BGP routes coming into your organization. Egress BGP Policy communicates how people get to your network. BGP Egress Policy is applied in stages with each stage with a different policy role. The stages depend on the vendor’s BGP implementation (or the BGP Open Source implementation). As a general rule of thumb, the following policy flow can be used as a guide. Through all these checks, remember that the policy would be a default deny, requiring an explicit permit.
1. Reject Bogon & RIR Minimum Prefixes
The EGRESS Bogon and RIR Minimum prefix filter is a safety net. The role is to protect the organization from “asking” for a DOS attack. The “DOS attack” would happen when a threat-actor gets into your network and finds a way to advertise Bogon and really large (more than /24) prefixes.
Bogon Prefixes are those reserved routes and unallocated prefixes which should not be advertised to the Internet. Bogons are defined as Martians (private and reserved addresses defined by RFC 1918, RFC 5735, and RFC 6598) and netblocks that have not been allocated to a regional internet registry (RIR) by the Internet Assigned Numbers Authority. A “full Bogon” prefixes beyond the Regional Internet Registry “Minimal Allocatable Prefixes.” Filtering on the RIR Minimums prevent operators advertising /26, /27, /28, and other large IPv4 prefixes. This route filter has been called the “Net Police” approach and proved operationally beneficial.
2. Remove Private ASNs
Private Autonomous Systems Numbers (ASNs) are using inside network infrastructure. They are a productive tool for building network architectures. Private ASNs should never appear on the Internet. The Egress policy would remote private ASNs. Some vendors have special commands which when turned on will remote private ASNs. Others will require an explicit AS filter.
3. Reject “bad” security incident routes (they Murphy Filter)
BGP is used as a security tool within a large organization. BGP Remote Triggered Black Hole Routing (RTBH), Sinkholes, and BGP Shunts are all important tools to protect the network. The Best Practice is to place Egress filters on your BGP policy to ensure these actions do not leak out into the Internet.
The famous “Pakistan Hijacked YouTube” incident was an RTBH leaking to the Internet. The ASN in Pakistan did not have a “Reject “bad” security incident routes in their Egress Policy.
4. Accept/Permit Peer Routes (on customer sessions)
Egress BGP sessions to customers would include the routes from your peers. This sets up the shortest path between the customer and your peer (for example on a local Internet Exchange Point (IXP). If you did not do this, the customer would be routing out your transit connection, taking the longer and more expensive path.
Peer routes would NOT be permitted on the Egress connection to your upstream/transit connections. It is not advisable to provide your peers with free transit.
5. Accept/Permit Customer Routes (on every session)
Permit all customer routes on the Egress to your peers and your transit. These should be EXPLICIT PERMIT filters. That means you explicitly permitted specific prefixes from your customers and deny all others. That minimizes the risk of your customer’s leaking routes through your network, into the Internet, and causing your organization problems.
6. Do AS-Prepending (if requested & applicable)
Autonomous System prepending (AS-Prepending) is a tool used on the Internet to shape the routing decisions of other ASNs in remote parts of the Internet (more than two ASNs away). This is the stage where the AS-Prepending happens. It is placed in this order to ensure that the “policing” and “security” does not impact traffic engineering.
7. Scrub Internal BGP Communities
BGP Extended Communities allows Operators more flexibility. Sometimes Operator does not want these extended communities used for internal traffic engineering to be passed on to the entire Internet. This and other “internal use” BGP communities would be ‘scrubbed’ at this stage.
8. Set NEXT-HOP-SELF
Setting the BGP Next Hop to be the same peering router ensures that another router is not mistakenly used. This is a BCP for BGP peering configuration.
9. Normalize BGP MED
BGP Multi-Exit Discriminator (MED) is a traffic engineering tool to influence the path selection logic one ASN hop away (the adjacent peers). Many times these BGP MED settings will drift apart from router to router. This step is a reminder to review and normalize the BGP MED settings.
Back to the main guide BGP Route Hijacks & Routing Mistakes – What can be done Today?
These BGP security materials are provided to help people around the Internet understand how do their part to deploy a more resilient BGP infrastructure. Seek out more information on www.senki.org via the Operators Security Toolkit. You can also subscribe to the Senki update mailing list here: Stay Connected with Senki’s Updates