The document discusses the challenges of internet routing security, particularly focusing on the Border Gateway Protocol (BGP) and its vulnerabilities due to a lack of identity verification mechanisms. It highlights the introduction of Resource Public Key Infrastructure (RPKI) as a solution to provide cryptographic confirmation of address ownership, aiming to mitigate route hijacking issues. The document concludes by emphasizing ongoing challenges in deploying RPKI and the need for organizations to take proactive measures to protect their internet resources.

1. Resource Public Key
Infrastructure
A Step Towards a More Secure
Internet Routing Infrastructure
Andrew Gallo

2. The Basics
• The Internet is a self organizing network of
networks.
• How do you find
your way around?
• Over 500k
‘destinations’ in
the current
Internet routing
table

3. BGP to the Rescue
• The Border Gateway Protocol (BGP) runs
between network operators to share
reachability information.
• Wildly successful and
stable Internet protocol:
• First standardized in 1989
• Current version (4)
standardized in 1994

4. BGP – a protocol built on trust
• Very few mechanisms in BGP for security
– MD5 hash for session passwords
– TTL security
– ACLs
• These mechanisms protect the control plane
but say nothing about the payload.
• About the time of BGP standardization, table
size 20k routes and < 1500ASNs
(source:http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_4-1/bgp_routing_table.html)

5. What about Identity – who is who
• No hierarchical addressing or routing on the
Internet backbone
• Any address can appear at any location
• Opposite of the predecessor mass
communications network – PSTN
• Solved the problem of decoupling location and
identity
• Created the problem table size (different talk) and
topology integrity – anyone can claim to be any
address

6. How are address blocks assigned?
• In the old days (according to
legend), in Jon Postel’s notebook
Today, there is the
IANA, the RIRs, LIRs,
etc

7. If that’s how they’re assigned, how are
they Validated?
• They aren’t. There is nothing in BGP or its
operation that prevents anyone from claiming
to be any address.
• There is no relationship between prefix, ASN,
organization, etc.
• Current state- use Internet Routing Registry
(IRR) (eg, RADB), whois data, to filter improper
advertisements.

8. When Things go Wrong
• Pakistan claims to be Youtube (2008)
– Mistake or intentional?
• CTBC (Brazilian ISP) leaks full table (2008)
• China Telecom claims 37,000 routes (2010)
• Bitcoin hijacking (2014)
Why does this happen
•Mistakes
•Clobber target network (blackhole target’s
network)
•Fun and profit (Bitcoin example)
•Observe, capture, sniff, MITM (more
advanced)

9. Hijacking – shortest path
ASN64515
ASN64612
ASN64616
ASN64717
ASN64818
ASN64919
legit
172.18.0.0/16
client
bad guy
172.18.0.0/16 - so am I!

10. BGP Hijacking – more specific
ASN64515
ASN64612
ASN64616
ASN64717
ASN64818
ASN64919
legit
172.18.0.0/16
client
bad guy
172.18.122.0/24 - I'm more specific!

11. Current State of the Art
• Rely on filtering (whois data, LOAs)
– Semi-automated and error prone
• (poor input data)
• Detect
– BGP monitoring services
• BGPMon
• Cyclpos
• Thousand Eyes
• Mitigate
– Call your upstream
– Post to NANOG (haha)
– Advertise more specific networks (as done with YouTube)

12. RPKI is the Answer
(to some of the issues)
• Resource Public Key Infrastructure
– Relatively new technology
– Cryptographically assures an ASN is authorized to
announce prefixes
• Extension to X.509 to carry IP prefix
information
– Route Origin Attestation (ROA)

13. RPKI structure
• The IANA is the source of all addresses
• But rather than being the single root of the
trust chain, each of the 5 Regionals hold self-
signed certs for the resources they hold.
• Two modes of operation-
– Hosted (RIRs run the PKI infrastructure)
– Delegated (RIRs issue Resource Certificates to orgs
that further sub-delegate IP space)

14. ROA Contents
• Origin Autonomous System Number
• Prefix (with optional max mask length)
• Validity dates
• When a ROA is signed, it has a
cryptographically provable chain to the source
of authority allowing that IP to be advertised
by that ASN.
• No more outdated, erroneous, or missing
whois or IRR data

15. I’ve signed my routes, now what?
• Go collect ROAs from the TALs, process them,
feed digested data to router for policy
processing.
– RPKI-to-rtr protocol (RFC 6180)
• No crypto processing in the routers
– Not with origin validation
– SIDR (path validation)

16. What it looks like- block diag
APNIC
Afrinic
ARIN*
LACNIC
RIPE
Tr us t Anchor
Loca t or s
router
router
router
validator
RIR hosted crypto engine
Delegated/customer CA

17. Three Route States
• Valid
– Prefix is covered by a valid ROA
• Unknown
– No ROA exists for this prefix
• Invalid
– Unauthorized announcement
• Mismatch between authorized ASN and originating ASN,
split origin
• More specific announcement than valid ROA allows
• Expired ROA

18. What to do with this data
• With 95% of the table in an unknown state,
probably nothing
• In a fully deployed RPKI environment, do you
– Reject unknown, invalid routes?
– Set LOCALPREF low??
– Set Community, put in a VRF?
• Still under operational development
• Study RFC 6483

19. Public resources
In this case, what is probably a valid /24 announcement has been
invalidated by the summary route signed by the ISP

20. More public resources
rpki@lr1.ham1.de> show route 72.52.2.0/24
inet.0: 511848 destinations, 511849 routes (511848 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
72.52.2.0/24 *[BGP/170] 1d 11:54:16, localpref 90, from 79.141.168.1
AS path: 33926 32787 45757 I, validation-state: invalid
> to 193.34.50.1 via em0.0
agallo@foghorn:~$ whois -h whois.bgpmon.net " --roa 33926 72.52.2.0/24"
2 - Not Valid: Invalid Origin ASN, expected 32787
agallo@foghorn:~$ whois -h whois.bgpmon.net " --roa 32787 72.52.2.0/24"
0 - Valid
------------------------
ROA Details
------------------------
Origin ASN: AS32787
Not valid Before: 2012-09-25 04:00:00
Not valid After: 2022-09-25 04:00:00 Expires in 7y256d16h34m26.2000000178814s
Trust Anchor: rpki.arin.net
Prefixes: 209.200.128.0/18 (max length /32)
72.52.0.0/18 (max length /32)
2606:6c00::/32 (max length /64)

21. So, we’ve solved everything, right?
• RPKI provides origin validation only
• See SIDR working group for path validation
• Still some work to be done on RPKI
– Secure transport of the RPKI data
– Operational best practices
– And, the best part……

22. RPKI introduces vulnerabilities
• TALs become valuable targets
– Wasn’t the decentralized design of the Internet a
reaction to the PSTN (either explicitly or implicitly)
– How do I trust the prefixes the TALs are using are
properly originated?
• Bootstrap problem of using the network itself to
validate its own topology (Gödel strikes the Internet?)

23. Slow adoption
• About 10% of the table
•LACNIC has more ROAs than ARIN
•Chicken-and-egg problem (but not
like IPv6)
•Do we need to start a fight by
bringing up ARIN’s RPA??

24. Don’t Speak BGP, you’re not off the
hook
• Your space can still hijacked or clobbered by a
fat finger
• Using hosted applications (what the kids call
The Cloud) – look at the Bitcoin hijacking case
• Ask your providers about RPKI plans
• Demand your resources be protected
– Not if, but when will the be protected

25. Resources
• RIPE
– https://www.ripe.net/lir-services/resource-management/certification/tools-and-resources
• Public RIPE Validator
– http://mvuy10.labs.lacnic.net:8080
• Publically accessible routers
– 193.34.50.25
– 193.34.50.26

26. THANK YOU
• Contact info
– Andrew Gallo
– @akg1330
– agallo@gmail.com