Validation Algorithms for a Secure Internet Routing PKI

1. Validation Algorithms for a Secure Internet Routing PKI David Montana Mark Reynolds BBN Technologies

2. Outline • The Resource PKI (RPKI) • Challenges in the RPKI • Relying Party Software Design • Status & Future Work

3. The Resource PKI: Motivation • Border Gateway Protocol (BGP) is the inter-domain 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)

4. 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#)

5. Address Allocation Hierarchy IANA Regional Registry National Registry ISP Subscriber Organization Subscriber Organization ISP ISP Subscriber Organization Subscriber Organization

6. AS Number Assignment Hierarchy IANA Regional Registry National Registry Subscriber Organization ISP Subscriber Organization ISP

7. RPKI Top Tiers IANA Reserved allocations LACNIC ARIN AFRINIC APNIC RIPE NICBR NICMX JPNIC CNNIC TWNIC KRNIC APJII

8. 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

9. ROAs & Certificates Public key used to verify certificates issued 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) Public key used to verify a ROA generated by the ISP ROA ROA Signed objects authorizing route origination

10. 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

11. 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

12. Certs CRLs ROAs aa aa aa aa aa aa aa aa RPKI Software Architecture rsync load prune translate Remote Repositories Local Repository RPKI Database BGP Filters APNIC Root Addr AS# APNIC RIPE RIPE Remote Local

13. 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.

14. 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

15. 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

16. 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 • Certificate and CRL Profile • Certificate Policy • Certification Practices Statement • Infrastructure Architecture • ROA format & semantics • Manifest format & semantics • Repository system • Initial operational capability by the end of 2008 by some of the RIRs • The RPKI Wiki is at: • 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

17. 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

18. Questions?