Overview of the Resource PKI (RPKI) Dr. Stephen Kent VP & Chief Scientist BBN Technologies

Size: px

Start display at page:

Download "Overview of the Resource PKI (RPKI) Dr. Stephen Kent VP & Chief Scientist BBN Technologies"

Noel Allen
5 years ago
Views:

1 Overview of the Resource PKI (RPKI) Dr. Stephen Kent VP & Chief Scientist BBN Technologies

2 Presentation Outline The BGP security problem RPKI overiew Address & AS number allocation system Certificates Repository system ROAs Manifests SIDR standards RPKI software RPKI status 2

3 BGP Security Problems & Solutions BGP lacks systemic security mechanisms that can prevent propagation of AS configuration errors or maliciously-injected routes Securing the AS path data in a BGP update counters a such attacks Authentication of the origin AS in a route is the first step toward this goal Route origin authentication requires a secure, distributed, reference database attesting to Internet resource holdings and authorizations for route origination 3

4 The Resource PKI (RPKI) The RPKI is is designed to support the validation of assertions about address space & AS number holdings The RPKI is an architecture, a set of standards, and software to enable more secure BGP routing in the public Internet The architecture is an X.509-based PKI to bind resources to resource holders Certificates use extensions (from RFC 3779) to represent address space and AS number resources The RPKI (mostly) parallels the extant resource allocation scheme Standards defining the RPKI are being developed in the IETF, in the Secure Inter-Domain Routing (SIDR) WG 4

5 What Does the RPKI Look Like? The RPKI consists of two major parts: X.509 certificates that attest to address space and AS number holdings A repository system for these certificates, CRLs, and other signed objects that are globally useful The RPKI leverages the existing address space and AS number allocation system The RPKI also embodies the principle of least privilege, which constrains the impact of errors or security compromise at each entity in the PKI, relative to the authorization of that entity 5

6 Matching the PKI to Reality The intent in this PKI is to issue certificates that attest to resource holdings by regional and national registries, ISPs, and subscribers (where needed) Because the allocation of these resources is done via a simple, hierarchic scheme, the PKI parallels this scheme Each entity that participates in the allocation process will act as a CA, issuing certificates to match the resource allocation records of that entity 6

7 Address & AS # Allocation Hierarchy IANA Regional Registry Subscriber Organization ISP ISP Subscriber Organization National/Local Registry ISP Subscriber Organization Subscriber Organization Subscriber Organization 7

8 How Does the PKI Work? IANA and the the 5 RIRs are the obvious trust anchors but, ultimately, RPs will select their own trust anchors Each RIR issues certificates to national/local registries (if applicable) and to ISPs and subscribers ISPs issue certificates to downstream providers and to subscribers Each organization issues certificates that match the address space (and AS number) allocations in its records All resource holders are CAs Each certificate path represents sub-allocation by the organizations noted above, a subset constraint that can be verified by ISPs downloading these certificates 8

9 IANA s Special Role IANA Unallocated addresses & AS numbers Reserved, non-routable Addresses 9

10 PKI Top Tier Example (for APNIC) AFRINIC ARIN APNIC LACNIC RIPE JPNIC CNNIC) TWNIC KRNIC APJII 10

11 Names in Certificates IANA, RIRs, NIRs, and ISPs are NOT naming authorities (unlike DNS registrars) So, we don t want them to act as CAs that vouch for the right of an entity to use a name To avoid this problem, all Subject and Issuer names in resource certificates are not meaningful They consist of a common name and, if needed, a serial number CommonName = F57320B9A926F819 SerialNumber =

12 The RPKI Repository System This repository is unusual in that ALL of the data is signed and verifiable via certificate path validation Most repositories used for certificates and CRLs, e.g., LDAP, assume searching & selective retrieval of entries The RPKI retrieval model is very different EVERY ISP will request ALL changed entries since the last time it checked Most ISPs will access the repository system several times a day This suggests a different repository model 12

13 Repository System Elements Distributed database of signed objects A publication point for each resource holder, but aggregation will help reduce fetching burden on ISPs Certificates & CRLs Route Origination Authorizations Statements by an address space holder about which ASes are authorized to originate routes to its address space Manifests Statements about what objects belong at each publication point and which version is current 13

14 ROAs A ROA authorizes an AS (ISP) to originate a route to a set of one or more prefixes A ROA is a CMS signed object containing List of address prefixes (IPv4 and/or IPv6) An AS number An ISP receiving a BGP update can verify the origin AS against the ROA The use (issuance and validation) of ROAs should reduce the impact of ISP configuration errors

15 What s a Manifest? The repository system holds only signed objects, which is good, but tampering is still possible! An older version of a valid object can be put in place of the current version, if that version has not expired A valid entry can be removed from the repository, without detection by a relying party A manifest is a signed object that enumerates all the other signed objects at a publication point It uses a CRL-like validity interval It has the hash of each file as well as the file name Error conditions are tricky! 15

16 RPKI Operations Model Each ISP uploads new certificates, CRLs, ROAs, and manifests, to a repository as needed, e.g., daily Each ISP downloads all certificates, CRLs, ROAs, and manifests from all repositories (at least daily) Relying party software (e.g., in a server) verifies these digitally signed objects, and extracts the ROA data Servers distribute the ROA data to BGP routers, enabling these routers to check the origin AS in BGP UPDATE messages An ISP could, instead, use the validated ROA data to generate route filters for its routers 16

17 Frequency of Repository Updates A resource holder needs to upload changed certificates, CRLs, and globally useful signed objects (e.g., ROAs) to the repository Certificates will usually change infrequently, only when new allocations are received An ISP decides how frequently to issue its own CRL, so he control the update frequency for that data item ROAs change only when allocations change, or when origination authorization changes, presumably not too often For smaller ISPs and subscribers, changes to the data will be very infrequent For large ISPs, daily updates will probably suffice 17

18 Who s Doing What? APNIC, ARIN, LACNIC & RIPE developed software to issue certificates to their members, integrated into their resource allocation systems They also created repository software, for use by themselves and their members BBN & ISC have created open source relying party software The SIDR WG is creating standards to describe the PKI, the system architecture, major data structures, the repository, etc. 18

19 SIDR Documents Architecture Certificate Profile Certificate Policy Certification Practice Statement (template) ROA format Manifest Algorithms & Key Sizes Origin Validation Trust Anchor Locator Key rollover Repository system structure Signed object format GhostBusters object RPKI/Router Protocol Provisioning Protocol Local TA Management 19

20 RPKI Status APNIC, RIPE, LACNIC & AfriNIC began production service (based on managed CA services) in January, 2011 About 330 certificates covering about 700 prefixes have been issued ARIN will be ready in the 2 nd quarter of 2011 More complete support (ISPs as CAs) will become available from all 5 RIRs throughout 2011 The SIDR WG has > 10 documents in process to be issued as RFCs NIRs and large and mid-sized ISPs need to sign up to do their part as CAs, and to make use of the RPKI (as RPs) Router vendors have working code that receives processed RPKI data (from a server) and validates BGP UPDATE messages with respect to origin AS assertions (and its fast!) 20

21 Questions?

Update on Resource Certification. Geoff Huston, APNIC Mark Kosters, ARIN IEPG, March 2008

Update on Resource Certification Geoff Huston, APNIC Mark Kosters, ARIN IEPG, March 2008 Address and Routing Security What we have had for many years is a relatively insecure interdomain routing system