Validation algorithms for a secure internet routing pki l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 18

Validation Algorithms for a Secure Internet Routing PKI PowerPoint PPT Presentation


  • 97 Views
  • Uploaded on
  • Presentation posted in: General

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. The Resource PKI: Motivation.

Download Presentation

Validation Algorithms for a Secure Internet Routing PKI

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Validation algorithms for a secure internet routing pki l.jpg

Validation Algorithms for a Secure Internet Routing PKI

David Montana

Mark Reynolds

BBN Technologies


Outline l.jpg

Outline

  • The Resource PKI (RPKI)

  • Challenges in the RPKI

  • Relying Party Software Design

  • Status & Future Work


The resource pki motivation l.jpg

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)


The resource pki strategy l.jpg

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


Address allocation hierarchy l.jpg

Address Allocation Hierarchy

IANA

Regional Registry

National Registry

ISP

Subscriber Organization

Subscriber Organization

ISP

ISP

Subscriber Organization

Subscriber Organization


As number assignment hierarchy l.jpg

AS Number Assignment Hierarchy

IANA

Regional Registry

National

Registry

Subscriber Organization

ISP

Subscriber Organization

ISP


Rpki top tiers l.jpg

RPKI Top Tiers

IANA

Reserved

allocations

LACNIC

ARIN

AFRINIC

APNIC

RIPE

NICBR

NICMX

JPNIC

CNNIC

TWNIC

KRNIC

APJII


Association of addresses to as s l.jpg

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


Roas certificates l.jpg

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


Certificate chain example l.jpg

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


Validation in the rpki l.jpg

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


Rpki software architecture l.jpg

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


Individual object validation l.jpg

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.


State change propagation in the database l.jpg

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


Roa processing l.jpg

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


Status l.jpg

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


Future work l.jpg

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


Questions l.jpg

Questions?


  • Login