BGP filtering best practice
0 likes117 views
The document discusses best practices for BGP filtering and securing Internet routing. It recommends prefix filtering over AS path filtering due to risks of accidental or malicious hijacking with AS path rules. Maintaining prefix filters can be difficult so many IXPs still use AS path rules. The document outlines how the Resource Public Key Infrastructure (RPKI) system of cryptographically signing routing data with regional Internet registries can help automate and validate prefix filters. However, RPKI adoption is still limited as not all network operators have signed their prefix objects or enforced validation of received routes. The document proposes methods to automate RPKI in network configurations to improve routing security.
BGP filtering best practice
- 1. Jimmy Lim TWNOG 3 jhalim@cloudflare.com Taipei, 21 June 2019 BGP filtering best practice
- 2. Cloudflare in a glance
- 3. Protect and accelerate any website online ● Direct visitors to nearest entry point ○ Fast ■ Lesser hops ■ Reduced latency ● Save bandwidth ○ Lesser requests to origin ○ Mitigate DDoS ● Resiliency ○ 150+ locations
- 5. AS Path vs Prefix filtering
- 6. Different type of inbound filtering ● No filtering? ○ No inbound policy filtering ○ Not acceptable ● AS path filtering ○ Filtering based on AS path - a series of autonomous system (AS) numbers with originator’s AS number at the end of the path ○ Using regular expression ● Prefix filtering ○ Filtering based on the matching prefixes defined in the prefix list or route filter
- 7. Many local IXPs are still doing AS path filtering ● Allow all prefixes that are originated by the ASN ○ No proper validation ● Prone to accidental/wrong announcement ● High risk of prefix hijacking and blackholing
- 8. Sample of bad thing about AS Path filtering ISP/IXP AS65501 Originate 10.0.0.0/24 AS_PATH _65501$ Send packet to 10.0.0.1 Hijacking routerLegitimate router AS65001 Originate 10.0.0.0/23
- 9. Sample of bad thing about AS Path ● What is so bad about the previous example? permit _65501$ ● That implies accept any prefixes that are originated by AS65501 ○ High chance to create accidental hijacking ○ High risk to hijack or blackhole maliciously
- 10. Another sample of bad thing about AS Path filtering ● RTBH feature by ISP/IXPs ○ Allow customers or participants to remotely trigger blackhole to prefixes under their own ASN ■ eBGP multihop blackhole peering with ISPs ■ Direct transit BGP session ■ Using ISP/IXPs blackhole BGP community ○ Accept up to /32 Internet ISPCustomer router ISPCustomer router eBGP multihop IXP Participants
- 11. Why AS Path filtering still exist? ● Difficult to maintain prefix filter ○ Troublesome to validate ● No expertise to configure, too complex? ● IXPs reluctant to do strict filtering ○ Not able to attract all traffic ■ Participants do not update filter regularly/properly
- 12. Prefix list filtering ● Prefix based filtering ○ More validation is done ● Allow up to /24 for IPv4 prefix ● Allow up to /48 for IPv6 prefix ● Automatic update via IRR database
- 13. IRR and RPKI
- 14. Internet Routing Registry ● Globally distributed routing information database ○ Ensure stability and consistency of Internet-wide routing ○ Sharing information between network operators ● Why use IRR? ○ Route filtering ○ Network troubleshooting ○ Router configuration ○ Global view of Internet routing ● List of IRRs ○ http://www.irr.net/docs/list.html
- 15. AS-SET information in IRR as-set: AS-CLOUDFLARE descr: Cloudflare, Inc members: AS13335 members: AS3557, AS21556 members: AS132892, AS133877 members: AS202623, AS203898 members: AS394536, AS395747, AS14789 mnt-by: MNT-CLOUD14 source: ARIN
- 16. Route object information in IRR route: 1.1.1.0/24 descr: Cloudflare, Inc. origin: AS13335 mnt-by: MNT-CLOUD14 notify: rir@cloudflare.com remarks: --------------- remarks: All Cloudflare abuse reporting can be done via remarks: https://www.cloudflare.com/abuse remarks: --------------- source: ARIN
- 17. Automation to generate prefix filter
- 18. IRRs have a very loose security model ● Some database maintainers do not check the authenticity of the entry ○ Records exist within IRRs can be wrong and/or missing ● There are lots of IRRs ○ Mirrors are not always up to date ● No cryptographic signing of records ● Let’s talk about RPKI
- 19. Resource Public Key Infrastructure ● Cryptographic method of signing records ● Regional Internet Registry (RIR) has a root certificate ○ Generate a signed certificate for Local Internet Registry (network operator) ■ All resources they are assigned with (IPs and ASNs) ● LIR then signs the prefix containing origin AS that they intend to use ○ ROA (Route Object Authorization) is created
- 20. Resource Public Key Infrastructure
- 21. Resource Public Key Infrastructure
- 22. Signing prefixes ● Each LIRs own and manage Internet resources has access to RIR portal ○ Signing their prefixes through the portal or API of their RIR is the easisest way to start with RPKI ● Cloudflare has resources in each of the 5 RIR regions ○ About 800 pefixes announcement over different ASNs ○ We need to ensure the first step is done
- 23. Automation to create ROA
- 24. Enforcing validated prefixes ● Signing the prefixes is one thing ● Ensuring the prefixes we receive match their certificates is another ● Validation is done by synchronizing the RIR databases of ROAs ○ Check the signature of every ROA against the RIR’s certification public key ○ Once valid records are known, it is sent to the routers ● Major vendors support a protocol called RPKI to Router Protocol (RTR) ○ A simple protocol for passing a list of valid prefixes with their origin ASN and expected mask length
- 25. RPKI to Router Protocol is insecure ● Vendors implement the insecure transport methods ● Routes sent in clear text over TCP can be tampered with
- 26. Introducing GoRTR ● A lightweight local RTR server ● Distribute it via our own Content Delivery Network ● Fetch the cache file over HTTPS and pass the routes over RTR
- 27. Cloudflare enforcing validated prefixes
- 28. Cloudflare enforcing validated prefixes
- 29. Summary
- 30. Wrapping up ● No filtering and AS Path filtering is not acceptable ● Prefix filtering via IRR automation is required ○ Challenge to have this applied in all IXPs ● RPKI is not a replacement yet for IRR ○ Not many has signed their prefixes ○ Not many has enforced validating the prefixes ● Implementing RPKI is achivable ○ Plenty of efforts are needed ○ It is not a bullet proof solution on securing the routing in Internet, but the impact of BGP attacks will be greatly reduced
- 31. Q&A