Initial Experiences Route Filtering at the Edge AS15169

1. Initial Experiences Route Filtering at
the Edge AS15169
Peering Asia 3.0
Arturo Servin / Ray Estrada

2. It is hard ...
Harder, longer and more complex than we
initially thought.

3. Summary
AS15169 will start to apply
stricter filters to BGP
announcements on all
peering sessions …
Sometime …
Very soon we hope ..

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. 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. 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. 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. 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. 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. 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. Apply changes to network devices
● Pilot to a small group of networks
● Measure device impact
● Mark today
● Drop tomorrow

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. Some stats

14. Total prefixes / Valid - Global

15. Total prefixes / Valid - Global vs APAC

16. Total prefixes / Valid - Global (All)

17. Total prefixes / Valid - APAC per Country
CN: 70,487 Avg
Announced / 59.12%
valid

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. 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. BGP View at Google ISP Portal

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. 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. Thanks!