Attacks on routing: IP hijacks

Attacks on routing: IP hijacks

How Internet number resources are managed IANA ARIN LACNIC APNIC RIPE NCC AfriNIC ISP NIC.br NIC.MX ISP #1 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 FoundaOonal document: RFC 2050 IP Registry Alloca1on Guidelines Each RIR is the authorita(ve source on the relaoonship between users/holders and resources Each RIR operates a registry database

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

RouOng 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 originaong the route ("origin- as") In this case ASN 20 is the "origin- as" for 10.1/16

Who has the "right" to use resources? When an ISP obtains resources from its RIR (IPv6/IPv4/ ASN): The ISP has to noofy its upstream ASNs which prefixes are going to be announced via BGP This is usually done via e- mail, web forms or by updaong 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 automaoc usage IRR WHOIS Non- signed informaoon, lizle addioonal tools provided for verificaoon of usage rights except for names, phone numbers and email POCs This verificaoon process is someomes not as thorough as it should be

Checking usage rights for a resource Network administrators Local checks in rouong infrastructure Require previous step (registering the route object with an IRR) Router protecoon RouOng protocol integrity Peer authenocaoon Filtering known- invalid routes RFC 1918 prefix filtering Bogon filtering In the end the integrity of the rouong system depends on ad- hoc trust rela(onships between peers

Route Hijacking When an enoty parocipaong in Internet rouong announces a prefix without authorizaoon we face a route hijack It can be either malicious or due to operaoonal 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 hzp://www.youtube.com/watch?v=izlpkuaoe50

Resource PKI Resource Public Key Infraestructure Goal: create a system that allows the ceroficaoon of usage rights for Internet numbering resources High- level overview Use of X.509 v3 ceroficates Apply RFC 3779 extensions to these ceroficates. These extensions allow Internet resources (IPv4/IPv6/ASNs) fields within ceroficates A way to automaocally validate the origin- as of a BGP UPDATE StandardizaOon AcOviOes IETF SIDR working group ImplementaOon AcOviOes RIRs

Resource PKI (ii) Automated origin valida(on for route announcements The enoty with usage rights for a resource signs the origin- as field of a PKI object The following procedures are applied to validate RPKI ceroficates and rouong informaoon objects: The cryptographic validity of the RPKI ceroficate chain (just like any other PKI) The CIDR inclusion properoes of IP addresses In this way it becomes more difficult for a third party to inject invalid data into the rouong system

Resource PKI (iii) RPKI Management System Cache Repository

Resource PKI (iv) All RPKI signed objects are listed in public repositories Aoer verificaoon, these objects can be used to configure filtering in routers ValidaOon Process Signed objects have references to the ceroficate used to sign them Each ceroficate has a pointer to an upper level ceroficate The resources listed in a ceroficate MUST be valid subsets of the resources listed in its parent's ceroficate In this way a trust chain can be traced to a "trust anchor" both cryptographically as well as in CIDR terms

X.509 v3 ceroficates with RFC 3779 extensions X.509 Digital CerOficates Subject, validity period, public key and other fields With extensions: RFC 3779 defines extensions that allow the representaoon of Internet resources as ceroficate fields List of IPv4, IPv6 and ASNs assigned to an organizaoon Implemented in OpenSSL 1.0c onwards It has to be specifically enabled when running "./configure" Version Serial Number Signature Algorithm Issuer Subject Subject Public Key Extensions Subject InformaOon Authority (SIA) Authority InformaOon Access (AIA) Addr: 10.10.10.0 Asid: 65535

CerOficates with RFC 3779 extensions "IP DelegaOon" SecOon Special value: "INHERITED" "AS DelegaOon" SecOon Special value: "INHERITED" ValidaOon Process It involves the validaoon of the resources Version Serial Number Signature Algorithm Issuer Subject Subject Public Key Extensions Subject InformaOon Authority (SIA) Authority InformaOon Access (AIA) Addr: 10.10.10.0 Asid: 65535

RPKI Structure RTA is the self- signed ceroficate in the hierarchy LACNIC RTA LACNIC resources LACNIC ProducOon <<INHERITED>> Signature chain ISP #2 ISP #2 Resources ISP #1 ISP #1 Resources ROA End EnOty cert. ROA End EnOty cert. End User CA #1 (EU #1 Resources) ROA End EnOty cert. ROA End EnOty cert.

RPKI Structure (ii) CAs CerOficate- signing enoty (CA bit = 1) ISPs can use this ceroficate to sign their client's ceroficates CerOficate Repository The repository contains ceroficates, 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 ceroficate for an organizaoon and guards both private and public keys CerOficates are emized when requested by LACNIC member organizaoons Users can manage their RPKI objects using a user- friendly web interface provided by LACNIC "Delegated" mode An organizaoon creates its own resource ceroficate This ceroficate is submized to LACNIC for signing. LACNIC returns the signed ceroficate. "Up- down" protocol

Services provided by the RPKI CA Emisng child resource ceroficates when changes to the registry database occur or when solicited by a resource holder Child ceroficate revocaoon when solicited by a resource holder CRL periodic update Publishing child ceroficates, trust anchor and auxiliary objects in a public repository (rsync)

Resource CerOficate

ROAs ROAs: RouOng Origin AuthorizaOon ROAs contain data on the allowed origin- as for a set of prefixes ROAs are signed using the ceroficates generated by the RPKI Signed ROAs are copied to the repository

ROAs (ii) A simplified ROA contains the following informaoon: 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- enoty ceroficate with resources A list of "route origin azestaoons" ROA End EnOty CerOficate 200/8 172.17/16 200.40.0.0/20-24 - > AS 100 172.17.0.0/16-19 - > AS 100

ROAs (iii) - ValidaOon In order to validate a ROA three steps have to be performed Crypto validaoon of the public keys and signatures included in the EE ceroficates inside each ROA CIDR inclusion checking of resources listed in the EE ceroficate CIDR inclusion checking of resources in the route origin azestaoons. These resources have to be included in the resources listed in the EE ceroficate

RPKI in AcOon 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 AcOon (ii) The validaoon process is split in two parts Crypto and CIDR validaoon of ROAs and ceroficates Performed by the validaon cache ValidaOon 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 communicaoon

RPKI in AcOon (iii) Cache Repository content is downloaded via RSYNC CerOficates and ROAs are validated Cryptographically (signature chain) Correct CIDR resource inclusion In the routers A database of prefix <- > origin- as relaoonships is built

BGP interacoon Routers build a database with the informaoon 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 interacoon (ii) UPDATE 200.0.0.0/9 ORIGIN- AS 20 VALID IP prefix/[min_len max_len] 172.16.0.0 / [16-20] 10 200.0.0.0/[8-21] 20 Origin AS 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"

Herramientas Validadores RIPE hzp://labs.ripe.net/members/agowland/ripe- ncc- validator- for- resource- ceroficaoon/view Rcyinc hzp://subvert- rpki.hactrn.net/rcynic/ Visualización y estadísocas Construidas sobre la salida de los validadores

Validación RIPE Labs

Validación (ii) Example: Validación top- down del repositorio de LACNIC exportando prefijos validados en un CSV Paso 1: bajar el RTA de LACNIC wget --output-document=./trust-anchors/talacnic.cer https://rpki.lacnic.net/rpki/rootcert Paso 2: correr la validación./ripencc-rpki-validator/bin/ certification-validator \ --top-down -o validator/ \ -t./trust-anchors/ta-lacnic.cer \ -r lacnic-roas.csv

Validación (iii) ROAs validados y prefijos (lacnic-roas.csv) URI,ASN,IP Prefix,Max Length,Not Before,Not After rsync://repository.lacnic.net/rpki/hosted/d62c58a7-668d-41a6- a246-af9400104596/utt-n3nq91lgzh0jvwppn- KirQ4.roa",AS28000,200.7.84.0/23,24,2011-01-07 02:00:00,2012-08-05 03:00:00 rsync://repository.lacnic.net/rpki/hosted/d62c58a7-668d-41a6- a246-af9400104596/utt-n3nq91lgzh0jvwppn- KirQ4.roa",AS28000,2001:13c7:7001::/48,48,2011-01-07 02:00:00,2012-08-05 03:00:00 rsync://repository.lacnic.net/rpki/hosted/d62c58a7-668d-41a6- a246-af9400104596/ nfnv84a_ga8zpecmr4jx1qe557o.roa",as28001,200.3.12.0/22,24,2011-01 -07 02:00:00,2012-08-05 03:00:00 rsync://repository.lacnic.net/rpki/hosted/d62c58a7-668d-41a6- a246-af9400104596/ nfnv84a_ga8zpecmr4jx1qe557o.roa",as28001,2001:13c7:7002::/48,48,2 011-01-07 02:00:00,2012-08-05 03:00:00

Fuente: Visualizando RPKI hzp://www.labs.lacnic.net/~rpki/rpki- heatmaps/latest/ Mapas de Hilbert coloreados de acuerdo con el espacio cubierto por ROAs:

The LACNIC RPKI System RPKI in hosted mode is in producoon state since 1/1/2011 To use it you only need: Have your AdministraOve Contact details (username and password) at hand to create ceroficates Have your Technical Contact details (username and password) at hand to create ROAs Where is it? hzp://rpki.lacnic.net/

Comentarios finales Posibles usos de RPKI mientras no todos los routers sean capaces de validar Puentes entre IRRd y RPKI Puentes entre WHOIS y RPKI Procesamiento de tablas BGP de routers offline Existe una variedad de herramientas de uso libre para RPKI Los repositorios de los 5 RIRs pueden bajarse libremente via rsync rsync avz rsync://repository.lacnic.net/rpki/./rpki

Links / References The LACNIC RPKI System hzp://rpki.lacnic.net/ LACNIC s RSYNC Repository rsync://repository.lacnic.net/rpki/ LisOng the repository rsync - - list- only rsync://repository.lacnic.net/rpki/lacnic/ Some RPKI StaOsOcs hzp://www.labs.lacnic.net/~rpki

Thank You!