Resource Public Key Infrastructure A pilot for the Internet2 Community to secure the global route table Andrew Gallo

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 Define destinations as prefixes – ie networks such as 172.16.0.0/16 There are over 500k v4 destinations and about 20k v6 prefixes; depending on how your connected to other networks, this could represent well over a million paths.

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

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) Why BGP and not something else – BGP is very policy driven. Lots of knobs for operators to turn to determine what is sent and what to do with what is received

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 Decoupling location --- local number portability, multihoming. LERG LERG LERG

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

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.

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)

Hijacking – shortest path Bad guy can be either wil

BGP Hijacking – more specific

Current State of the Art Rely on filtering (whois data, IRR 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 Advertise more specific networks (as done with YouTube)

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 Authorization(ROA)

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)

ROA Contents Origin Autonomous System Number Prefix (with optional max mask length) Validity dates When a ROA is created, 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

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)

What it looks like- block diag

Three Route States Valid Unknown Invalid 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

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

Checking validation - CLI agallo@foghorn:~$ whois -h whois.bgpmon.net " --roa 4901 162.250.136.0/22" 0 - Valid ------------------------ ROA Details Origin ASN: AS4901 Not valid Before: 2015-07-22 04:00:00 Not valid After: 2018-07-22 04:00:00 Expires in 1y154d1h12m27.6000000014901s Trust Anchor: rpki.arin.net Prefixes: 162.250.136.0/22 (max length /24) ***** Wrong origin AS ↓↓↓↓↓ agallo@foghorn:~$ whois -h whois.bgpmon.net " --roa 65033 162.250.136.0/22" 2 - Not Valid: Invalid Origin ASN, expected 4901 Add resource slide for 193.34.50.25 and 193.34.50.26.

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……

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?) Currently, rsync is used to collect ROAs, is there a better way? Also, doesn’t prevent Improper advertisement with correct ASN

Slow adoption About 10% of the table LACNIC has more ROAs than ARIN Chicken-and-egg problem (but not like IPv6)

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

Hosted RPKI with ARIN Basic workflow: Initial (one-time) Request hosted RPKI with ARIN, provide public key that will be used to sign requests This is NOT the keypair used to create the ROA, just to authenticate communication between you and ARIN This take about 24 hours for ARIN to enable RPKI for your resources. Once enabled, everything is self-service.

Hosted RPKI with ARIN Step 1: Key generation See https://www.arin.net/resources/rpki/faq.html#keypairgeneration Generate key Extract Public Key

Hosted RPKI with ARIN Step 2: Requested Hosted RPKI Log into ARIN Online, ‘Ask ARIN’ Create ticket for ‘Create Hosted Resource Certificate’ Include public key created in previous step Wait. During this time ARIN is configuring the RPKI infrastructure to allow you to create ROAs

Hosted RPKI with ARIN Step 3: Create ROA (web) Log into ARIN online, navigate to the Org owning the resource Click on ‘Manage rpki’ Next screen, click on ‘Create ROA’

Hosted RPKI with ARIN Step 4: Provide Details Fill in details

Hosted RPKI with ARIN Step 4: Manual ROA request There is an option to create the signed request via CLI, and paste the data in this form, in the ‘Signed’ tab. See “Using OpenSSL” at https://www.arin.net/resources/rpki/faq.html

ARIN OT&E Operational Test and Evaluation environment Environment for testing various ARIN services Monthly refresh of data from production Restricted to specific hosts Access valid for six months Request access through ticketing system

ARIN OT&E – Key Differences You don’t request a host resource record to be created (first step above). All ROAs in the OT&E are signed using a key at: https://www.arin.net/resources/ote.html#rpki

ROA Creation – Live Demo Valid ROA Invalid ROA (should fail) Prefix outside Org’s assignment or allocation

Route Validation Second ‘half’ of RPKI: Three common validators Collect ROAs from Trust Anchors Cryptographic processing Feed digested route list to router Three common validators RIPE’s Validator* Dragon Research Labs: rcynic Validator Raytheon BBN RPSTIR Project (current??)

Route Validation – Validator Demo RIPE Validator Java, requires JRE 8 ARIN Trust Anchor Locator (TAL) must be manually added (We can hold the discussion about the legal ramifications of RPKI for another time!)

Junos Configuration Two areas to configure Validation session (connection to the validator) Under routing-options Import policy to trigger database lookup Under policy-options

Junos Configuration Validation Session Basic configuration to establish session with validator There are other options (time outs, etc)

Junos Configuration Policy This is a simple policy to trigger validation database lookup Policy is open to operational need Accept? Reject? LocalPref?

Junos Operation Show commands Useful show commands show route validation-state show validation session State Description Means invalid Invalid route validation state Mismatch in ASN/prefix mapping; more specific not covered by valid ROA unknown Unknown route validation state No ROA found unverified Unverified route validation state *Junos specific; no policy triggers database lookup valid Valid route validation state Matching ROA found

Resources RIR Resources George Tech Research Network Operations ARIN (main) ARIN OT&E RIPE (main) RIPE Validator George Tech Research Network Operations NIST RPKI Monitor

Resources RIPE Public RIPE Validator Publically accessible routers 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

THANK YOU Contact info Andrew Gallo agallo@gwu.edu Pilot Wiki Slack Channel: i2rpkidemo.slack.com