Transcript Validation Algorithms for a Secure Internet Routing PKI

Validation Algorithms for a
Secure Internet Routing PKI
David Montana
Mark Reynolds
BBN Technologies
Outline
•
•
•
•
The Resource PKI (RPKI)
Challenges in the RPKI
Relying Party Software Design
Status & Future Work
2
The Resource PKI: Motivation
• Border Gateway Protocol (BGP) is the interdomain routing protocol in the public Internet
– “The glue that holds the Internet together”
• BGP is woefully insecure
• Address space hijacking is becoming
increasingly common
– Pakistan Telecom’s recent unintentional hijacking of
YouTube
• Making BGP secure is challenging
– Changes to router software/hardware would be a
financial burden for ISPs and router vendors
– Must allow for incremental deployment (no flag day)
3
The Resource PKI: Strategy
• Enable ISPs to generate BGP route filters (an
offline activity) using data authenticated by this
RPKI
• Create an infrastructure that is a prerequisite for
securing BGP without changing BGP itself
• Use an X.509-based PKI to bind resources to
resource holders
– IP address blocks
– Autonomous System numbers (AS#)
4
Address Allocation Hierarchy
IANA
Regional
Registry
National
Registry
ISP
Subscriber
Organization
Subscriber
Organization
ISP
ISP
Subscriber
Organization
Subscriber
Organization
5
AS Number Assignment Hierarchy
IANA
Regional
Registry
Subscriber
Organization
ISP
Subscriber
Organization
National
Registry
ISP
6
RPKI Top Tiers
IANA
LACNIC
NICBR
ARIN
AFRINIC
APNIC
RIPE
TWNIC
KRNIC
Reserved
allocations
NICMX
JPNIC
CNNIC
APJII
7
Association of Addresses to AS#s
• Create a new type of digitally signed object, a
Route Origin Authorization (ROA)
• Every ROA is signed by an address space
holder and contains
– The AS# of the ISP
– The IP address block(s)
– An expiration date
• ROA allows an address space holder to identify
an AS number that is authorized to originate a
route for one or more IP address blocks
8
ROAs & Certificates
Public key used to verify
certificates issued by the ISP
Public key used to verify
a ROA generated by the ISP
ISP
(CA)
An ISP will usually create a
distinct EE certificate per ROA,
to make ROA revocation easy
ISP
(EE)
ISP
(EE)
ROA
ROA
Signed objects authorizing
route origination
9
Certificate Chain Example
(self signed root certificate)
Issuer = IANA
Subject = IANA
Addr: 0/0
ASN: 0…232-1
Issuer = IANA
Subject = APNIC
Addr: W,X,Y,Z, …
ASN: A,B,C,D, …
Issuer = APNIC
Subject = JPNIC
Addr: W,X,Y
ASN: A,B
Issuer = JPNIC
Subject = ISP
Addr: X,Y
ASN: A
Issuer = ISP
Subject = Subscriber
Addr: X
10
Validation in the RPKI
• Typical PKI application context
– A relying party (RP) receives an End Entity (EE) certificate which
must be validated
– It discovers a certification path to a trust anchor (TA)
– Only a small fraction of all the certificates in the PKI will need to
be validated in a given time interval by a given RP
• Resource PKI context
– The complete collection of valid ROAs is needed in order to
generate BGP routing filters
– Every relying party must validate every certificate within a given
time interval (nominally 1 day)
– Each ROA needs a certification path to a TA in order to be
validated
– This is an authorization PKI, not an identification PKI
11
RPKI Software Architecture
rsync
Remote Repositories
aa
APNIC
load
Local
aa
aa Repository
prune
RPKI
aaaa
aaaaDatabase
Root
APNIC
translate
BGPaa
Filters
AS# Addr
RIPE
Certs
RIPE
CRLs
ROAs
Remote
Local
12
Individual Object Validation
•
•
•
•
•
Syntax check
Expiration check (certificates and ROAs)
Staleness check (certificate revocation lists)
Revocation check (certificates)
Deferred validation
– If an object’s parent is present in the database, check its
signature
– If an object’s parent is not present in the database, then label it
as in the NO CHAIN state
• Deferred validation is necessary because we are
fetching from multiple remote repositories in parallel. For
a given object a certification path to a TA may not be
present in our local repository at any given time.
13
State Change Propagation in the Database
• If a previously valid certificate or ROA expires, delete it from the
database and recursively examine all descendents to see if they
can be reparented, otherwise put them in the NO CHAIN state
• If a previously valid certificate is revoked, proceed as above
• If a Certificate Revocation List (CRL) has not been replaced by its
nextUpdate time, that CRL and all the descendents of the issuer of
that CRL enter the STALE state
• If a new certificate arrives, see if it is the parent of any object in the
NO CHAIN state
• If a new CRL arrives, see if it replaces a previously STALE one
• Database changes propagate downward, path discovery
propagates upward
14
ROA Processing
• To be valid a ROA:
– Must have a complete, validated, non-expired, non-revoked
chain to a trust anchor
– Can optionally include or exclude ROAs that have a STALE
object in their chain
• In the current Internet, the set of all route filter entries
may depend on ~1,000,000 objects
• We can initialize the database with that number of
objects in < 10 hours
• Daily processing of route filter updates is incremental
– Processing a few thousand objects
– Total processing time << 1 hour
15
Status
•
•
•
APNIC, RIPE, ARIN and LACNIC are all producing software that will allow them at act
as CAs and repositories in the RPKI
ARIN has sponsored development of software that ISPs can use as CAs and relying
parties
IETF Secure Inter-Domain Routing (SIDR) working group is in place producing
standards for the RPKI
–
–
–
–
–
–
–
•
•
Initial operational capability by the end of 2008 by some of the RIRs
The RPKI Wiki is at:
–
•
Certificate and CRL Profile
Certificate Policy
Certification Practices Statement
Infrastructure Architecture
ROA format & semantics
Manifest format & semantics
Repository system
http://mirin.apnic.net/resourcecerts/wiki
The software is at:
–
–
–
svn://mirin.apnic.net/bbn-svn/BBN_RPKI_software/trunk
Thanks to George Michaelson of APNIC for hosting our software
This work funded by US DHS contract FA8750-07-C-0006
16
Future Work
• The current implementation is a solid foundation for
future efforts to make BGP more secure
• The infrastructure is extensible
• V2 of the software is currently under development
– Cache validation results on partial chains
– Directly generate Routing Policy Specification Language (RPSL)
to offer ISPs an authenticated input compatible with the inputs
they already use for route filter generation
– Incorporate processing for another new digitally signed object, a
Manifest, which provides cryptographic validation of the contents
of a repository
• Detect Man-In-The-Middle (MITM) attacks
• Detect missing objects
17
Questions?
18