APNIC Infrastructure and Development Director Che-Hoo Cheng gives an overview of the RPKI, why it is important, and how to create ROAs and ROVs to secure routing announcements.

1. RPKI –
Industry Trends & Initiatives
Che-Hoo Cheng
Infrastructure & Development Director, APNIC
@APAN50 on 2020-08-05

2. Security matters as your network is
connecting to Internet
• You do NOT want your own routes to be hijacked by anyone, maliciously or
accidentally
• You also do NOT want to receive bad routing information from any of your
BGP neighbors or propagate bad routing information to any of them
• Basic measures include:
– Bogons and martians filtering
– Max prefix count
– IRR (Internet Routing Registry) database checking
– Plus doing MANRS
– So on and so forth
• Additional measure should include:
– RPKI (Resource Public Key Infrastructure) / ROV (Route Origin Validation)

3. Routing security is becoming more
important than ever
• Route-hijacking cases (malicious and accidental) are more and more
common
– Big incentive for hackers
• Hijack DNS, hijack websites, steal passwords and so on
– Misconfiguration does happen from time to time
• And, it is extremely easy to do route-hijacking, if protection measure is
not implemented
• A lot of route objects on IRR-DB are not authenticated properly and so
cannot be fully trusted
• Need better authenticity for routing info, i.e. need to make sure that the
route originators are the true “owners” of the relevant IP resources

4. Routing security breaches
4
Facebook, Mar 2019 Google, Nov 2018
Google, Nov 2012
YouTube, Feb 2008
Amazon, Apr 2018
Google JP, Aug 2017

5. RPKI
• RPKI is a Public Key Infrastructure (PKI) framework for
Internet Number Resources (INR)
– Based on X.509 PKI standards
– Cryptographic public/private key security
• RPKI adds Internet Number Resources (INR) information to
X.509 certificates issued to resource holders
– Representing “ownership” and other status
– Certification hierarchy follows INR delegation hierarchy
IANA ➔ RIR (➔ NIR) ➔ ISP ➔ …

6. RPKI hierarchy
Source : http://isoc.org/wp/ietfjournal/?p=2438
IANA
RIPE-NCCLACNICARIN APNICAFRINIC
NIR
ISP ISP ISP ISP
Allocation
Hierarchy
Trust Anchor
Certificate
Certificate
chain
mirrors
allocation
hierarchy
Cert
(CA)
Cert
(EE)
Cert
(EE)
Cert
(EE)
Cert
(EE)
Cert
(CA)
Cert
(CA)
Cert
(CA)
Cert
(CA)
Cert
(CA)
Cert
(CA)

7. RPKI
• Verifiable “ownership” of IPv4/IPv6 and ASN resources
– Resource information added to X.509 certificates
– RPKI Certificates issued with resource allocations
• Verifiable authorisation to route IPv4/IPv6 addresses
– Route Origin Authorisation (ROA) objects
– Signed by resource holder with RPKI cert

8. RPKI service models
• Hosted model
– APNIC performs CA functions on behalf of members
– Manage keys, repository etc
– Generate certificates for resource delegations
– This “Member CA” is separate from the “APNIC CA”
• Provisioning model
– Member operates full RPKI system including CA
– Communication with APNIC via “up-down” provisioning protocol
• Either rsync (to be deprecated) or RRDP (preferred)
– This is live at some NIRs such as JPNIC, CNNIC and TWNIC

9. RPKI objects
• Resource certificates
– Extended X.509 certificates listing IPv4/IPv6/ASN
– Representing authority for use of those resources
– Issued/Signed by IP address registry (RIR/NIR/LIR as CA)
• Route Origin Authorisation (ROA)
– Giving a specific ASN authority to route specific IP blocks
– Issued/Signed by resource certificate holder

10. RPKI – ROA
• Route Origin Authorization
– List of prefixes with ASN authorized to announce
– Signed by the resource holder with RPKI certificate
– Multiple ROAs can exist for the same prefix
• RPKI systems validates the integrity of the ROA
– Was it signed by the holder of the prefix, using valid RPKI cert?
– If so, can now be used to construct route filters in BGP
Prefix 203.176.32.0/19
Max-length /24
Origin ASN AS17821

11. Internet routing
The Internet
Global Routing Table
4.128/9
60.100/16
60.100.0/20
135.22/16
…
Global Routing Table
4.128/9
60.100/16
60.100.0/20
135.22/16
203.176.32.0/19
…
AS17821
203.176.32.0/19
?
??
Announcement
Traffic

12. Route Origin Validation (ROV)
• Using RPKI Route Origin Authorization (ROA)
AS17821
203.176.32.0/19
Peer/Upstream
or IXP
☺
LOAROA

13. RPKI Validator
• Gathers and validates ROAs from the distributed RPKI databases
– Using rsync or RRDP “delta protocol” (preferable)
– Maintains a validated cache representing complete global state
• Can then perform ROV for routers using RPKI-Router (RTR) protocol
rpki.apnic.net
IANA
APNIC RIPE
NIR ISP
RRDP
Cache
Validator

14. RPKI Validator options
• Dragon Research RPKI toolkit -
https://github.com/dragonresearch/rpki.net
• RIPE Validator - https://github.com/RIPE-NCC/rpki-validator-3
• Routinator - https://github.com/NLnetLabs/routinator/releases/tag/v0.7.1
• OctoRPKI/GoRTR (Cloudflare’s toolkit) -
https://github.com/cloudflare/cfrpki
• Fort (NIC Mexico’s Validator) - https://nicmx.github.io/FORT-validator/
• Reference: https://blog.apnic.net/2019/10/28/how-to-installing-an-rpki-
validator/

15. Route validation states
• Not Found (Unknown)
– No ROA found, probably not created yet
– This will be “default” for some time.
• Valid
– ROA exists
– Prefix, Origin ASN and prefix-length match those found in validated cache
• Invalid
– ROA exists
– Prefix found, but Origin ASN is wrong, Prefix-length longer than Max-length, or
certificates are expired or otherwise invalid.
– Some action needed…

16. Options when seeing invalid routes
• Drop them
• Give them lower LOCAL_PREF
• Do nothing (not recommended)
• Tag them before re-distributing them to customers
– Allow customers to make their own choices
– Apply community tags based on the validation state
• Not Found (ASN:65XX1)
• Valid (ASN:65XX2)
• Invalid (ASN:65XX3)

17. ROV at Border Routers
ISP
Validated
cache
Validator
RPKI-to-Router (RTR)
RPKI-to-Router (RTR)

18. ISP 3
ISP 1 ISP 2
ISP 3
ROV at IXPs
Validated
cache
Validator
RPKI-to-Router (RTR)
Routes
Tagged/filtered
routes
Route
Server

19. Possible deployment steps
• Create your own ROAs at relevant registries to better
protect your own networks
– And encourage your peers/customers to do the same
– For APNIC members, it is easy to do it on MyAPNIC
• You can contact APNIC Helpdesk at any time (https://www.apnic.net/get-
ip/helpdesk/)
• Next step is to do Route Origin Validation (ROV) at your
border routers
– Firstly to play around with LOCAL_PREF
– Later to implement route filtering when you feel comfortable

20. RPKI Status Globally – Snapshot
• Source: https://rpki-monitor.antd.nist.gov/?p=0&s=0

21. RPKI Status Globally – Trend
• Source: https://rpki-monitor.antd.nist.gov/?p=0&s=0

22. RPKI Status of APNIC Region – Snapshot
• Source: https://rpki-monitor.antd.nist.gov/?p=3&s=0

23. RPKI Status of APNIC Region – Trend
• Source: https://rpki-monitor.antd.nist.gov/?p=3&s=0

24. ROA Creation Statistics of APNIC Region
• Source: https://lirportal.ripe.net/certification/content/static/statistics/world-roas.html

25. Best Performing Economy in APNIC Region
Source: https://observatory.manrs.org/

26. ROV Deployment Status of Major Operators
Source: https://isbgpsafeyet.com

27. ROV Deployment Status of Cloud Providers
Source: https://isbgpsafeyet.com

28. More Incentives for Creating ROAs
• Industry push:
– AWS – BYOIP requires customers to set up ROAs
– More and more IXPs are implementing ROV on their
route servers
• But this does not help your direct bilateral peering over the IXPs

29. ROA vs IRR
• IRR-DB is full of garbage
– Many Routing Registries, which may mirror data from others
– Anybody can create any route objects without proper authorization
• But still a lot of transit providers and IXPs are using it to construct
their incoming route filters, especially for their customers
• Some providers are starting to prefer route objects with relevant
ROAs as they have proper authorization
– You can say ROAs are helping clean up IRR-DB
– Note that APNIC is offering RR service for members with proper
authorization so you can create/manage your ROAs and relevant route
objects on MyAPNIC at the same time

30. Measurement on ROV Route Filtering
• https://stats.labs.apnic.net/rpki/XA
• End-user’s viewpoint
• More about effective ROV
– Not really about ROV deployment by network

31. ROV route filtering at stub networks
• Transit networks (e.g. NRENs) should consider doing ROV route
filtering seriously to protect their downstream networks better
• Simple stub networks (e.g. normal universities) may not need to
implement ROV route filtering if they only have upstream/transit
connections because their transit networks should help protect
them
• But stub networks which do a lot of direct bilateral peering (e.g.
large universities) should consider doing ROV route filtering as
well for better protection of themselves because their
upstream/transit providers cannot protect them fully

32. Default Route
• If you want to do ROV route filtering, you would better not
have default route at your border routers (unless your
default route is surely pointing to a transit provider which
does ROV route filtering)
– In other words, you should need full routes from your transit providers
if you want to reach the whole Internet

33. Implications to networks which are
announcing invalid routes inadvertently
• Will get to fewer and fewer networks on Internet
– Similar to being disconnected from bigger and bigger part of
Internet
• If it is just a mistake, updating the relevant ROA records
(supposedly with proper authority) will solve the problem
– Should always keep your ROA records updated
• All can be managed at one place so should be easy
– Can have ROA records for the same prefix under multiple Origin
ASes at one time to help the cases of network migration and so on

34. How do you know you are announcing
invalid routes inadvertently?
• Some transit providers help notify their customers when
they see invalid routes from their customers
• There are tools on Internet which can help you check it by
yourself:
– E.g. https://bgp.he.net
• Note that only you as the “owner” of the IP address blocks
(or network prefixes) can change the relevant ROAs

35. Effect to blackholing service
• Some transit providers and IXPs are offering blackholing service to
mitigate DDoS attacks for their customers
• They rely on /32 announcements with proper BGP community tags to
trigger blackholing
• ROAs with standing max_length of /32 are defeating the purpose of
having max_length on ROAs
• Possible solutions:
– Ignore ROAs just for those /32 announcements with specific BGP community
tags but have to care about the possible security loopholes
– Add ad-hoc ROAs of /32 only when needed but the propagation time does not
have guarantee
– Any other ideas?

36. Validator considerations
• VRP output

37. ROA with AS0 origin (RFC6483/RFC7607)
• Negative attestation
– No valid ASN has been granted authority
– Not to be routed (e.g. IXP LAN prefixes)
• Overridden by another ROA
– with an origin AS other than AS0
• Prop-132: unallocated/unassigned APNIC space
– Similar to RFC6491 for special-use/reserved/unallocated

38. MyAPNIC access under ROV
• MyAPNIC behind AS4608 is used for creating ROAs for APNIC members
choosing the hosted model offered by APNIC
• If AS4608 does ROV Route Filtering, those APNIC members announcing
invalid routes cannot login to modify their ROAs from the networks filtered
– For cases of human errors, it may be an issue
• AS4608 will not do ROV Route Filtering for now but what if all of AS4608’s
transit providers are doing it?
– Direct peering with AS4608 should help but it will not be for everybody
– The last resort is to call APNIC for help
• In any case, make sure your ROAs are created according to your
actual route announcements

39. RPKI is NOT a bullet-proof solution
• But it helps improve the situation for route hijacking,
especially if everybody does it
• Coupled with more and more direct peering, the protection
for routing security should be more effective

40. More and more serious RPKI / ROA /
ROV deployments are being observed
in the industry –
You should at least create your own
valid ROAs to better protect your own
networks…

41. Questions?