btNOG 6: Securing Internet Routing
0 likes221 views
The document discusses the vulnerabilities in internet routing and the lack of a single authority leading to frequent routing errors. It explores tools and techniques for verifying route authenticity and suggests improvements like digital signatures and the Resource Public Key Infrastructure (RPKI) to enhance routing security. The importance of industry initiatives and basic operational security measures are emphasized to mitigate risks in routing practices.
btNOG 6: Securing Internet Routing
- 1. 1 v1.01 Securing Internet Routing Tashi Phuntsho (tashi@apnic.net) Senior Network Janitor/Technical Trainer
- 2. 2 v1.02 Why should we bother? • As a Manager q I don’t want to be front page news of a IT paper, or an actual newspaper for routing errors
- 5. 5 v1.05 Headlines After leak (JP->JP) After leak (EU->EU) https://dyn.com/blog/large-bgp-leak-by-google-disrupts-internet-in-japan/
- 7. 7 v1.07 Why do we keep seeing these? • Because NO ONE is in charge? q No single authority model for the Internet q No reference point for what’s right in routing
- 8. 8 v1.08 Why do we keep seeing these? • Routing works by RUMOUR q Tell what you know to your neighbors, and Learn what your neighbors know q Assume everyone is correct (and honest) § Is the originating network the rightful owner?
- 9. 9 v1.09 Why do we keep seeing these? • Routing is VARIABLE q The view of the network depends on where you are § Different routing outcomes at different locations q ~ no reference view to compare the local view L
- 10. 10 v1.010 Why do we keep seeing these? • Routing works in REVERSE q Outbound advertisement affects inbound traffic q Inbound (Accepted) advertisement influence outbound traffic
- 11. 11 v1.011 Why do we keep seeing these? • And as always, there is no E-bit q A bad routing update does not identify itself as BAD • So tools/techniques try to identify GOOD updates
- 12. 12 v1.012 Why should we worry? • Because it’s just so easy to do bad in routing! By Source (WP:NFCC#4), Fair use, https://en.wikipedia.org/w/index.php?curid=42515224
- 13. 13 v1.013 Why should we bother? • As a Engineer q I don’t want to be told at 3AM my routing is broken q Or while on a holiday
- 14. 14 v1.014 Current practice Peering/Transit Request LOA Check Filters (in/out)
- 15. 15 v1.015 Tools & Techniques LOA Check Whois (manual) Letter of Authority IRR (RPSL)
- 16. 16 v1.016 Tools & Techniques • Look up whois q verify holder of a resource
- 17. 17 v1.017 Tools & Techniques • Ask for a Letter of Authority q Absolve from any liabilities
- 18. 18 v1.018 Tools & Techniques • Look up/ask to enter details in internet routing registries (IRR) q describes route origination and inter-AS routing policies
- 19. 19 v1.019 Tools & Techniques • IRR q Helps auto generate network (prefix/as-path) filters using RPSL tools § Filter out route advertisements not described in the registry
- 20. 20 v1.020 Tools & Techniques • Problem(s) with IRR q No single authority model § How do I know if a RR entry is genuine and correct? § How do I differentiate between a current and a lapsed entry? q Many RRs § If two RRs contain conflicting data, which one do I trust and use? q Incomplete data - Not all resources are registered in an IRR § If a route is not in a RR, is the route invalid or is the RR just missing data? q Scaling § How do I apply IRR filters to upstream(s)?
- 21. 21 v1.021 Back to basics – identifying GOOD • Using digital signatures to convey the “authority to use”? q A private key to sign the authority, and q the public key to validate that authority
- 22. 22 v1.022 How about trust in this framework? • Follows the resource allocation/delegation hierarchy IANA à RIRs à NIRs/LIRs à End Holders | V End Holders
- 23. 23 v1.023 RPKI Chain of Trust IANA RIPE-NCCLACNICARIN APNICAFRINIC NIR ISP ISP ISP ISP Allocation Hierarchy Trust Anchor Certificate Certificate chain mirrors the allocation hierarchy Cert (CA) Cert (EE) Cert (EE) Cert (EE) Cert (EE) Cert (CA) Cert (CA) Image 4
- 24. 24 v1.024 Resource Certificates • When an address holder A (*IRs) allocates resources (IP address/ASN) to B (end holders) q A issues a resource certificate that binds the allocated address with B’s public key, all signed by A’s (CA) private key q proves the holder of the private key (B) is the legitimate holder of the resource!
- 25. 25 v1.025 Route Origin Authorization (ROA) • B can now sign authorities using its private key, which can be validated by any third party against the TA • For routing, the address holder can authorize a network (ASN) to originate a route, and sign this permission with its private key (ROA) Prefix 203.176.32.0/19 Max-length /24 Origin ASN AS17821
- 26. 26 v1.026 Route Origin Validation (ROV) RPKI-to-Router (RtR) rsync/RRDP RPKI Validator/ RPKI Cache server 2406:6400::/32-48 17821 .1/:1 .2/:2 AS17821 ASXXXX Global (RPKI) Repository ROA 2406:6400::/32-48 17821 TA TA TA 2406:6400::/48
- 27. 27 v1.027 Are ROAs enough? • What if I forge the origin AS in the AS path? q Would be accepted as “good” – pass origin validation! • Which means, we need to secure the AS path as well q Need AS path validation (per-prefix)
- 28. 28 v1.028 AS path validation - BGPsec AS1 AS2 AS3 AS4 AS1 -> AS2 (Signed AS1) AS1 -> AS2 (Signed AS1) AS2->AS3 (signed AS2) AS1 -> AS2 (Signed AS1) AS2->AS4 (signed AS2) q A BGPsec speaker validates the received update by checking: § If there is a ROA that describes the prefix and origin AS § If the received AS path can be validated as a chain of signatures (for each AS in the AS path) using the AS keys
- 29. 29 v1.029 AS path validation issues… • More resources q CPU - high crypto overhead to validate signatures, and q Memory § Updates in BGPsec would be per prefix § New attributes carrying signatures and certs/key-id for every AS in the AS path • How do we distribute the certificates required? • Can we have partial adoption? • Given so much overhead, can it do more - Route leaks?
- 30. 30 v1.030 What can we do? • Basic BGP OpSec hygiene – RFC7454/RFC8212 q RFC 8212 – BGP default reject or something similar q Filters with your customers and peers § Prefix filters, Prefix limit § AS-PATH filters, AS-PATH limit § Use IRR objects (source option) or ROA-to-IRR q Filter what you receive from your upstream(s) q Create ROAs for your resources q Filter inbound routes based on ROAs -> ROV • Join industry initiatives like MANRS § https://www.manrs.org/
- 31. 31 v1.031 ROV – Industry trends dropping Invalids!
- 32. 32 v1.032 Acknowledgement 5280 • Geoff Huston, APNIC • Randy Bush, IIJ Labs/Arrcus