RPKI implementation experiences in the

LAC Region

Carlos M. Martínez – Arturo Servín

LACSEC 2012 – LACNIC XVIII

What is RPKI?

RPKI (Resource Public Key Infrastructure) allows the validation of an organization right to use of a certain resource (IPv4, IPv6, ASN)

RPKI combines the hierarchy of the Internet resource assignment model through RIRs with the use of digital certificates based on standard X.509

RPKI is standardized in the IETF through the SIDR WG. It has produced RFCs 6480 – 6492

Application of RPKI

One of the threats to the routing system is the forging of the origin autonomous system in BGP.

To reduce monkey-in-the-middle attacks and misconfiguration errors in BGP we use RPKI to validate the autonomous system that originates a prefix

RPKI Architecture and Origin Validation

Cache

RPKI Management System

Repository

Types of users

Prefix holder You want to certify your prefixes and create

ROAs Router operator

You want to validate prefixes using RPKI and origin-validation

You are both

Prefix Holder

You need to create and publish your resource certificate and your ROAs One way is to use RIRs systems already

deployed Run your own CA and repository

Router Operator

You need an origin-validation capable router, an RPKI cache and at least one trust anchor

Cisco, Juniper and Quagga (srx-module) are capable routers

RIPE NCC and others have cache implementations

Each RIR is the trust anchor of the resources (IPv6 and IPv4) that they have allocated

Router Operator (2)

Configure your cache to pull the TALs from RIRs

Configure your router and cache to speak RTR

Configure policies in your router Check your BGP routes

Validation Cache

RIPE NCC Java, runs almost anywhere, supports (RPKI

routing protocol Download:

http://labs.ripe.net/Members/agowland/ripencc-rpki-validator.zip/view

Rcynic Runs in unix like systems Download: http://rpki.net

BBN Written in C++, tested in linux but it may run in

other unix like systems

Routers

Cisco Production software for ASR1000, 7600, ASR903

and ASR901 – releases 15.2(1)S or XE 3.5 Juniper

Beta versions in JunOS Production version sometime in 2012

Quagga Quagga SRX, developed by NIST US 3rd-party patch, merge into mainline Quagga

planned for later in 2012

RPKI in the LAC Region

• This segment of the talk is biased– It covers operational experience from our service

region only (LACNIC)– I assume people should know what their network

is actually doing– So take all this with a grain of salt

• It is not meant to be hard on early adopters– Early adopters always get burnt, but they gather

and provide extremely valuable experience

RPKI in the LACNIC Service Region

• Where are we? – Slowly getting there– There is a lot of interest in the community– A bit of disappointment due to lack of router

software • This should change later this year

• Noticeable increments in usage after our conferences

• ~200** prefixes, 6% of announced IPv4 covered by ROAs

• 2nd place among all regions behind RIPE-NCC by some measurements

RPKI Evolution

Prefixes Signed IPv4 Space Covered by ROAs (in % of total)

Nice, right? Or...

• … perhaps not• Statistics show that the quality of the ROAs

created tends to be not-very-good• Quality in this context means 'first do no

harm'– Your ROAs should not create 'artificial' invalids,

otherwise trust in the system will be quickly undermined once BGP speakers start validating

• Our region was creating almost ~1500 invalids

How we figured it out?

http://www.labs.lacnic.net/rpkitools/looking_glass/

Why ? What is Going On ?

• Network-related issues– Lack of awareness on how a 'complex' network is

actually, well, 'networking' with its peers• 'Complex' as in 'I use more than one AS'• Failure to properly identify correct originating AS– Flabbergasting levels of de-aggregation• Sometimes for TE needs, sometimes hard-to-explain • Make creation of proper ROAs impractical with currently

available tools• System-related

Why ? What is Going On ? (ii)

• System-related– Lack of 'previewing' or 'prototyping' tools• Leading to 'blind' ROA creation and lots of trial & error– Lack of awareness of tools like RIS

What Now? What Should We Do?

• Act now:– We contacted our worst offenders and reduced our

count of invalids by 75% while keeping them using the system

• Plan for the future:– Provide better tools• Ways of 'previewing' the effect of a ROA

– RIS data invaluable for this purpose• Batch-creation of ROAs• Up/Down– Integrate them with the hosted system

• BGP Training• Remember the BGP BoF later today

Thank you !

carlos @ lacnic.netaservin @ lacnic.net