1 / 19

RPKI implementation experiences in the LAC Region

Learn about RPKI (Resource Public Key Infrastructure) implementation experiences in the LAC Region, including architecture, origin validation, management systems, cache repositories, and tools. Gain insights into RPKI evolution, challenges faced, and solutions for creating quality ROAs.

heason
Download Presentation

RPKI implementation experiences in the LAC Region

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RPKI implementation experiences in the LAC Region Carlos M. Martínez – Arturo Servín LACSEC 2012 – LACNIC XVIII

  2. 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

  3. 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

  4. RPKI Architecture and Origin Validation RPKI Management System Cache Repository

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. RPKI Evolution Prefixes Signed IPv4 Space Covered by ROAs (in % of total)

  14. 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

  15. How we figured it out? • http://www.labs.lacnic.net/rpkitools/looking_glass/

  16. 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

  17. 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

  18. 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

  19. Thank you ! carlos @ lacnic.net aservin @ lacnic.net

More Related