Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Initial Experiences Route Filtering at the Edge AS15169 by Arturo L. Servin

22 views

Published on

Initial Experiences Route Filtering at the Edge AS15169

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Initial Experiences Route Filtering at the Edge AS15169 by Arturo L. Servin

  1. 1. Initial Experiences Route Filtering at the Edge AS15169 Peering Asia 3.0 Arturo Servin / Ray Estrada
  2. 2. It is hard ... Harder, longer and more complex than we initially thought.
  3. 3. Summary AS15169 will start to apply stricter filters to BGP announcements on all peering sessions … Sometime … Very soon we hope ..
  4. 4. Why? ● Pretty much self explanatory why routing security matters, but if you ask me to say … ● Sending/receiving route hijacks, leaks, mitms, etc hurts We want to be part of the solution, not the problem
  5. 5. Which problems we want to solve? My prefixes announced/leaked by others me leaking other’s prefixes Others sending leak/hijacks to me Others sending leak/hijacks of others with impact This talk is about what AS15169 intends to do here indirect sessions direct sessions me others PeerLock (Others) PeerLock (me) Better Operational practices
  6. 6. BGP-Filtering sources IRR, RPKI, <internal TE> ● IRR data for what peers think they will be sending (Today) ● RPKI data where available to validate IRR data (Tomorrow) ● Internal TE sources to limit further if required (The day after tomorrow)
  7. 7. Why IRR and not RPKI? ● IRR data is not perfect but it covers more prefixes than RPKI today ● RPKI only provides Origin Validation, we also need “Routing Intent” (i.e. what a peer intents to announce to us or it is allowed to announce) ● We are planning to use RPKI in the near future, but we want to get the first step right
  8. 8. Our Strategy ● Notify peers (almost a year by now) ● Clean our IRR data (we need to do what we are asking others to do) and publish our Routing Intent ● Collect, Parse and Process data regularly from IRR repositories ● Parse and place into internal data service and Create per-ASN filter content ● Algorithmically mark prefixes and inform our peers ● Apply changes to network device(s)
  9. 9. Routing Intent - Publishing ours ● Make sure our “Routing Intent” is available and correct ● Use of IRR (RADB) and RPKI hosted model ○ Automate and Minimize manual configuration ○ Use of APIs to publish new data to RPKI and IRR ● Work in process
  10. 10. Collect, Parse and Process ● Collect data regularly from IRR repositories 1 ● Parse and place into internal data service ● Create per-ASN filter content 1 ALTDB, APNIC, ARIN, BBOI, BELL Canada, CANARIE, EASYNET, HOST, JPIRR, Level3, NESTEGG, NTT, OPENFACE, OTTIX, PANIX, REACH, RADB, RGNET, RIPE, RISQ, ROGERS, TC
  11. 11. Apply changes to network devices ● Pilot to a small group of networks ● Measure device impact ● Mark today ● Drop tomorrow
  12. 12. Main issues (so far ...) ● Selling the project ● Missing IRR data for a given prefix ○ No object at all (ASN or Route) ○ No routing intent (AS-SET) ○ Duplicated entries ● Parsing AS-SET record ○ AS-SET vs IRR:AS-SET vs ORGNAME::ASN:AS-SET ● Fast and reliable configuration of network devices is hard
  13. 13. Some stats
  14. 14. Total prefixes / Valid - Global
  15. 15. Total prefixes / Valid - Global vs APAC
  16. 16. Total prefixes / Valid - Global (All)
  17. 17. Total prefixes / Valid - APAC per Country CN: 70,487 Avg Announced / 59.12% valid
  18. 18. Other interesting findings ● Large transit providers have large number of invalids ○ Most of those are missing customers ASNs in AS-SETs ○ <review if some accept invalid origins, etc.> ●
  19. 19. Tools to check your prefix validity ● Google ISP Portal ○ https://isp.google.com/bgp/ ● IRR Explorer NLNOG ○ http://irrexplorer.nlnog.net/ ● RIPE RIS Routing Consistency ○ https://stat.ripe.net/widget/as-routing-consistency
  20. 20. BGP View at Google ISP Portal
  21. 21. Other lines of work ● Preventing ourselves from being the leaker ● Publishing RPKI data ○ Using RIRs hosted model ○ Working to automate ROA publishing using ARIN’s RPKI system ○ Evaluating to do the same with others RIRs (initially we will do it manually) ● MANRS
  22. 22. Final recommendations when peering with AS15169 ● Review the correctness of your ASN, Route and AS-SET objects ● Check that your AS-SET is correctly configured in your PeeringDB record ● Check that everything looks ok (ISP Portal or other online validators)
  23. 23. Thanks!

×