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

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)

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 (identity) integrity – anyone can claim to be any address at any location

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

ASN64515

ASN64612

ASN64616

ASN64717

ASN64818

ASN64919

legit

172.18.0.0/16

client

bad guy

172.18.0.0/16 - so am I!

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!

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 created ROAs for 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)• Hop-by-hop, with crypto processing on the router

What it looks like- block diag

APNIC

Afrinic

ARIN*

LACNIC

RIPE

Tr us t An chor Loca t o r s

router

router

router

valid

ator

RIR hosted crypto engine

Delegated/customer CA

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

What to do with this data

• With 89% of the table in an unknown state, probably nothing1

• 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 64831Source: https://rpki-monitor.antd.nist.gov/12-OCT-2018

Checking validation - CLI• VALID

agallo@foghorn:~$ whois -h whois.bgpmon.net " --roa 4901 162.250.136.0/22"0 - Valid------------------------ROA Details------------------------Origin ASN: AS4901Not valid Before: 2018-07-06 04:00:00Not valid After: 2022-08-01 04:00:00 Expires in 3y291d19h14m42Trust Anchor: rpki.arin.netPrefixes: 2620:118:5000::/44

162.250.136.0/22

• Invalid***** 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

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?– This is changing to RRPD

• Also, doesn’t prevent– Improper advertisement with correct ASN– Reasoning behind not using max mask length in ROA “loose ROA”

Slow adoption• About 10% of the table•Chicken-and-egg problem

•but not like IPv6•Europe is kicking our butts!

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 ARINOverview

• Generate Key pair

Step 1

• Submit Certificate Request

Step 2• Submit

ROA Request

Step 3

Hosted RPKI with ARIN

• Basic workflow:– Initial (one-time)• Request hosted RPKI with ARIN, provide public key that

matches the private 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 ARINStep 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 ARINStep 3: Create ROA (web)

• Log into ARIN online, navigate to the Org owning the resource

• Log into ARIN online• Left menu, click Search• In View Your Associated Networks• Click on a Net Handle

• Click on Actions and select Manage RPKI

Hosted RPKI with ARINStep 4: Create ROA (web)

• Click on Create ROA

• Fill in Information

Hosted RPKI with ARINStep 5: Create ROA (web)

• This is the private key that was created in step 1

Hosted RPKI with ARINStep 5: Manual ROA request (alternate method)

• 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” athttps://www.arin.net/resources/rpki/faq.html

• Last step – review• Once submitted, a ticket is automatically created• Can be viewed under “Tickets”• Usually takes a minute or two to create ROA• May take 24 hours to be available via TAL

Hosted RPKI with ARINStep 6: Create ROA (web)

ARIN OT&E

• Operational Test and Evaluation environment– Environment for testing various ARIN services–Monthly refresh of data from production– See wiki for details setting up RPKI access in the

OT&E

ARIN OT&E – Key Differences

• All ROAs in the OT&E are signed using a key at:https://www.arin.net/resources/ote.html#rpki• The keypair used in the OT&E for signing

requests is public:– https://www.arin.net/resources/ote.html#rpki

Route Validation

• Second ‘half’ of RPKI:– 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 validating

cache)• Under routing-options validation

– Import policy to trigger database lookup• Under policy-options policy-statement

Junos ConfigurationValidation Session

• Basic configuration to establish session with validator

• There are other options (time outs, etc)

Junos ConfigurationPolicy

• This is a simple policy to trigger validation database lookup• Policy is open to operational need– Accept?– Reject?– LocalPref?– Send to VRF?

Junos OperationShow commands

• Useful show commands– show route validation-state

– show validation session

State Description Meansinvalid Invalid route validation state Mismatch in ASN/prefix mapping; more

specific not covered by valid ROA

unknown Unknown route validation state No ROA found

valid Valid route validation state Matching ROA found

unverified Unverified route validation state *Junos specific; no policy triggers database lookup

Barriers to Adoption

• Lack of familiarity– Hopefully we’ve at least started to address that

today• RPKI doesn’t address a high risk problem– Low priority

• Legal– No (L)RSA with ARIN– RPA

THANK YOU

• Contact info– Andrew Gallo– agallo@gwu.edu– Pilot Wiki