Transcript - Internet2 Wiki

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 integrity – anyone can claim to be any
address
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
client
ASN64818
ASN64515
ASN64717
ASN64612
ASN64616
ASN64919
legit
172.18.0.0/16
bad guy
172.18.0.0/16 - so am I!
BGP Hijacking – more specific
client
ASN64818
ASN64515
ASN64717
ASN64612
ASN64616
ASN64919
legit
172.18.0.0/16
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 selfsigned 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
Tr u s t A n c h o r
Lo c a t o r s
APNIC
RIR hosted crypto engine
Afrinic
ARIN*
Delegated/customer CA
LACNIC
RIPE
validator
router
router
router
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 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
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:
– 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
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
– show validation session
Resources
• RIR Resources
– ARIN (main) ARIN OT&E
– RIPE (main) RIPE Validator
• George Tech Research Network Operations
• NIST RPKI Monitor
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
THANK YOU
• Contact info
– Andrew Gallo
– [email protected]
– Pilot Wiki
– Slack Channel: i2rpkidemo.slack.com