Internet Resource Certification (RPKI) Building a More Secure - - PowerPoint PPT Presentation

Sint-Maarten Internet Week

Carlos Mar2nez Cagnazzo carlos @ lacnic.net

Internet Resource Certification (RPKI) Building a More Secure Internet

A9acks on rou;ng: IP hijacks

How Internet number resources are managed

IANA ARIN ISP End users LACNIC NIC.br NIC.MX ISP mx ISP #1 APNIC LIRs/ISPs RIPE NCC LIRs/ISPs AfriNIC

How Internet number resources are managed (ii)

• What do we mean by resources

– IPv4 Addresses – IPv6 Addresses – Autonomous System Numbers

• Both 16 and 32 bits
• Founda;onal document: RFC 2050

– “IP Registry Alloca1on Guidelines”

• Each RIR is the authorita(ve source on the

rela;onship between users/holders and resources

– Each RIR operates a registry database

ASN 10 ASN 20

ASN1 ASN 2 ASN 3

Rou;ng in the Internet

ASN 20 announces 10.1.0.0/16 The 10.1.0.016 prefix propagates across ASs (via BGP sessions) ASN 10 receives the prefix 10.1.0.0/16 A9ributes: 10.1.0.0/16 AS_PATH ASN1 ASN3 ASN20

Rou;ng in the Internet (ii)

• BGP chooses routes using a

decision algorithm and the values of the available a=ributes

• AS_PATH is a list of the

autonomous systems a given UPDATE has traversed

– The first entry is the AS

• rigina;ng the route ("origin-

as")

In this case ASN 20 is the "origin-as" for 10.1/16

ASN 10 ASN 20

ASN1 ASN 2 ASN 3

Who has the "right" to use resources?

• When an ISP obtains resources from its RIR (IPv6/IPv4/

ASN):

– The ISP has to no;fy its upstream ASNs which prefixes are going to be announced via BGP – This is usually done via e-mail, web forms or by upda;ng an IRR (Internet Rou1ng Registry)

• Upstreams verify (or at least they should) the right of

use for the announced resources

– RIR WHOIS Text-based and not really suitable for automa;c usage – IRR WHOIS Non-signed informa;on, li9le addi;onal tools provided for verifica;on of usage rights except for names, phone numbers and email POCs

• This verifica;on process is some;mes not as thorough

as it should be

Checking usage rights for a resource

• Network administrators

– Local checks in rou;ng infrastructure

• Require previous step (registering the route object with an IRR)

– Router protec;on – Rou;ng protocol integrity

• Peer authen;ca;on
• Filtering known-invalid routes

– RFC 1918 prefix filtering – Bogon filtering

• In the end the integrity of the rou;ng system depends
• n ad-hoc trust rela(onships between peers

Route Hijacking

• When an en;ty par;cipa;ng in Internet rou;ng

announces a prefix without authoriza;on we face a route hijack

• It can be either malicious or due to opera;onal

mistakes

• Some well-known cases:

– Pakistan Telecom vs. You Tube (2008) – China Telecom (2010) – Google in Eastern Europe (various ASs, 2010) – Some ocurrences in our region (January/February 2011)

Route Hijacking (ii)

AS 15358 announces 200.40/24 AS 8158 gets 200.40.0.0/16 and 200.40.235.0/24 200.40.0.0/16 AS_PATH ASN1 ASN3 ASN6057 200.40.235.0/24 AS_PATH ASN1 ASN3 ASN6057 AS 6057 announces 200.40/16 AS 8158 gets 200.40.0.0/16

Route Hijacking (iii)

• RIPE NCC Video

– h9p://www.youtube.com/watch?v=IzLPKuAOe50

Resource PKI

• Resource Public Key Infraestructure

– Goal: create a system that allows the cer;fica;on of usage rights for Internet numbering resources – High-level overview

• Use of X.509 v3 cer;ficates
• Apply RFC 3779 extensions to these cer;ficates. These

extensions allow Internet resources (IPv4/IPv6/ASNs) fields within cer;ficates

• A way to automa;cally validate the origin-as of a BGP UPDATE

– Standardiza;on Ac;vi;es

• IETF SIDR working group

– Implementa;on Ac;vi;es

• RIRs

Resource PKI (ii)

• Automated origin valida(on for route

announcements

• The en;ty with usage rights for a resource signs the
• rigin-as field of a PKI object
• The following procedures are applied to validate

RPKI cer;ficates and rou;ng informa;on objects:

– The cryptographic validity of the RPKI cer;ficate chain (just like any other PKI) – The CIDR inclusion proper;es of IP addresses

• In this way it becomes more difficult for a third

party to inject invalid data into the rou;ng system

Resource PKI (iii)

Cache RPKI Management System Repository

Resource PKI (iv)

• All RPKI signed objects are listed in public

repositories

• Aqer verifica;on, these objects can be used to

configure filtering in routers

• Valida;on Process

– Signed objects have references to the cer;ficate used to sign them – Each cer;ficate has a pointer to an upper level cer;ficate – The resources listed in a cer;ficate MUST be valid subsets

• f the resources listed in its parent's cer;ficate

– In this way a trust chain can be traced to a "trust anchor" both cryptographically as well as in CIDR terms

RPKI Structure

LACNIC RTA

LACNIC resources

LACNIC Produc;on

<<INHERITED>>

ISP #2

ISP #2 Resources

ROA

End En;ty cert.

ROA

End En;ty cert.

ISP #1

ISP #1 Resources

End User CA #1

(EU #1 Resources)

ROA

End En;ty cert.

ROA

End En;ty cert.

RTA is the self- signed cer;ficate in the hierarchy Signature chain

RPKI Structure (ii)

• CAs

– Cer;ficate-signing en;ty (CA bit = 1)

• ISPs can use this cer;ficate to sign their client's cer;ficates
• Cer;ficate Repository

– The repository contains cer;ficates, CRLs, ROAs and manifests – Accesible via “rsync”

• Management Interface

– Web interface for those who prefer "hosted" mode

RPKI Management for Users

• "Hosted" mode

– LACNIC emits the resource cer;ficate for an organiza;on and guards both private and public keys

• Cer;ficates are emi9ed when requested by LACNIC member
• rganiza;ons

– Users can manage their RPKI objects using a user-friendly web interface provided by LACNIC

• "Delegated" mode

– An organiza;on creates its own resource cer;ficate – This cer;ficate is submi9ed to LACNIC for signing. LACNIC returns the signed cer;ficate.

• "Up-down" protocol

Services provided by the RPKI CA

• Emiung child resource cer;ficates when changes to

the registry database occur or when solicited by a resource holder

• Child cer;ficate revoca;on when solicited by a

resource holder

• CRL periodic update
• Publishing child cer;ficates, trust anchor and

auxiliary objects in a public repository (rsync)

Resource Cer;ficate

ROAs

• ROAs: Rou;ng Origin Authoriza;on

– ROAs contain data on the allowed origin-as for a set of prefixes – ROAs are signed using the cer;ficates generated by the RPKI – Signed ROAs are copied to the repository

ROAs (ii)

• A simplified ROA contains the following

informa;on:

• These ROAs states that:

– "The prefix 200.40.0.0/17 will be originated by ASN 6057 and could be de-aggregated up to /20" "This statement is valid star1ng on Jan 2, 2011 un1l Jan 1, 2012"

• Other ROA content

– ROAs contain cryptographic material that allows valida(on of the ROAs content

ROAs (iii)

• Contents of a ROA

– An end-en;ty cer;ficate with resources – A list of "route origin a9esta;ons"

ROA End En;ty Cer;ficate

200/8 172.17/16 200.40.0.0/20-24 -> AS 100 172.17.0.0/16-19 -> AS 100

ROAs (iii) - Valida;on

• In order to validate a ROA three steps have to be

performed

– Crypto valida;on of the public keys and signatures included in the EE cer;ficates inside each ROA – CIDR inclusion checking of resources listed in the EE cer;ficate – CIDR inclusion checking of resources in the route origin a9esta;ons. These resources have to be included in the resources listed in the EE cer;ficate

RPKI in Ac;on

UPDATE Routers assign a "validity status" to the route included in an UPDATE Cache periodically updates the router with a list of validated prefixes

RPKI in Ac;on (ii)

• The valida;on process is split in two parts

– Crypto and CIDR valida;on of ROAs and cer;ficates

• Performed by the valida;n cache

– Valida;on of routes in BGP UPDATEs

• Performed by the BGP speakers in the network
• A special protocol called RTR is being worked on by

the IETF for Router - Cache communica;on

RPKI in Ac;on (iii)

• Cache

– Repository content is downloaded via RSYNC – Cer;ficates and ROAs are validated

• Cryptographically (signature chain)
• Correct CIDR resource inclusion
• In the routers

– A database of prefix <-> origin-as rela;onships is built

BGP interac;on

• Routers build a database with the informa;on they

receive from the caches

• This table contains

– Prefix – Min length – Max length – Origin-AS

• By applying a set of rules a validity status is assigned

to each UPDATE prefix

BGP interac;on (ii)

IP prefix/[min_len – max_len] Origin AS 172.16.0.0 / [16-20] 10 200.0.0.0/[8-21] 20

• If the "UPDATE pfx" is not covered by any entry in

the DB -> "not found"

• If the "UPDATE pfx" is covered by at least one entry

in the DB, and the origin-AS matches the ASNs in the DB -> "valid"

• If the origin-AS does NOT match -> "invalid"

UPDATE 200.0.0.0/9 ORIGIN-AS 20

VALID

twi9er.com/LACNIC facebook.com/ LACNIC youtube.com/user/lacnicstaff gplusme.at/LACNIC

CASA DE INTERNET DE LATINOAMÉRICA Y EL CARIBE

Thank you!