Internet Resource Certification (RPKI) Building a More Secure Internet Sint-Maarten Internet Week Carlos Mar2nez Cagnazzo carlos @ lacnic.net
A9acks on rou;ng: IP hijacks
How Internet number resources are managed IANA ARIN LACNIC APNIC RIPE NCC AfriNIC ISP #1 ISP NIC.br NIC.MX LIRs/ISPs LIRs/ISPs End users ISP mx
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
Rou;ng in the Internet ASN 20 announces 10.1.0.0/16 ASN 2 ASN 3 ASN1 ASN 20 ASN 10 The 10.1.0.016 prefix propagates across ASs (via BGP ASN 10 receives sessions) the prefix A9ributes: 10.1.0.0/16 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 ASN 2 values of the available ASN 3 ASN1 ASN 20 a=ributes ASN 10 • AS_PATH is a list of the autonomous systems a given UPDATE has traversed In this case ASN 20 is – The first entry is the AS the "origin-as" for origina;ng the route ("origin- 10.1/16 as")
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 on 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 6057 announces 200.40/16 AS 15358 AS 8158 gets announces 200.40.0.0/16 200.40/24 AS 8158 gets and 200.40.0.0/16 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
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 origin-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) RPKI Management System Cache 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 of 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 RTA is the self- signed cer;ficate LACNIC RTA in the hierarchy LACNIC resources Signature chain LACNIC Produc;on <<INHERITED>> ISP #2 ISP #1 ISP #2 Resources ISP #1 Resources End User CA ROA ROA #1 End En;ty cert. End En;ty cert. (EU #1 Resources) ROA ROA End En;ty cert. End En;ty cert.
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 organiza;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 200.40.0.0/20-24 -> AS 100 172.17.0.0/16-19 -> AS 100 Cer;ficate 200/8 172.17/16
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) VALID IP prefix/[min_len – max_len] Origin AS UPDATE 200.0.0.0/9 172.16.0.0 / [16-20] 10 ORIGIN-AS 20 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 "
CASA DE INTERNET DE LATINOAMÉRICA Y EL CARIBE twi9er.com/LACNIC facebook.com/ LACNIC youtube.com/user/lacnicstaff gplusme.at/LACNIC
Thank you!
Recommend
More recommend
