bgp resource public key infrastructure (rpki) … resource public key infrastructure (rpki) origin...

BGP Resource Public Key Infrastructure (RPKI) Origin Validation Tech Note

April 2017

Tech Note

2 © 2017 Juniper Networks, Inc.

Juniper Networks, Inc. 1133 Innovation Way Sunnyvale, California 94089 USA 408-745-2000 www.juniper.net

Copyright © 2017, Juniper Networks, Inc. All rights reserved.

Tech Note

© 2017 Juniper Networks, Inc. 3

Table of Contents Overview of RPKI .................................................................................................................................................................... 4 Public Key Infrastructure ......................................................................................................................................................... 4 Certificate Distribution ............................................................................................................................................................. 4 RPKI Details ............................................................................................................................................................................ 5 How Routers Process RPKI Data ........................................................................................................................................... 6 RPKI Cache Server ................................................................................................................................................................. 7 RPKI in Practice ...................................................................................................................................................................... 8 Proof of Concept Network ....................................................................................................................................................... 8 Configuring RPKI .................................................................................................................................................................... 9 Configuring the RPKI Validator ............................................................................................................................................. 11 RPKI Validator Verification and Operation ............................................................................................................................ 16 RPKI Junos OS Router Commands ...................................................................................................................................... 19

The Show Validation Command ....................................................................................................................................... 19 The Show Route Validation-State Command ................................................................................................................... 20

Conclusion ............................................................................................................................................................................. 22 Appendix A: Router Details ................................................................................................................................................... 23 Appendix B: Public Test Bed ................................................................................................................................................. 23

Tech Note


Overview of RPKI The Border Gateway Protocol (BGP) used on the Internet core relies on a transitive trust model. A transitive trust is one in which a certain level of trust (or believability) is inherited by an entity through an intermediary, rather than directly from the source. In a data center, a new process might inherit access rights not only from a parent process, but also from the parent process’s parent (a kind of “grandparent”). Transitive trusts are not the only kinds possible. A bank, for example, might trust checks drawn on an account in a different branch, but not on an account from an out-of-state bank. There are also hierarchical trust models where trust in passed along from some top authority down to others. Hierarchical trusts are important in the solution in this paper. On the Internet, the transitive trust nature of typical BGP routing information can lead to outages when someone else incorrectly announces routes they do not own. Because routers choose a more specific route announcement in favor of a less specific route, an incorrect route announcement that has a longer, more specific network mask can result in the “hijacking” of a prefix throughout the Internet. This is a somewhat common event in the Internet and is usually the result of an accidental misconfiguration. However, this accidental origin in no way eases the impact of the problem. In response to this possibility, the Secure Inter-Domain Routing (sidr) IETF Working Group has defined a solution that helps to reduce this inherent vulnerability: the BGP Resource Public Key Infrastructure (RPKI). RPKI is a specialized PKI framework designed to secure the Internet’s routing infrastructure. RPKI provides the ability to validate the originating Autonomous System (AS) number of IPv4 and IPv6 prefixes. RPKI also makes sure that the prefix lengths for these routes are within the limits defined by their owners. RPKI links this route information (a resource) to a trust anchor (a root certificate authority). This allows legitimate holders of these route resources to control the operation of routing protocols, in particular BGP, regarding their route information.

Public Key Infrastructure PKI uses asymmetric keys called public and private keys to encrypt and decrypt information. RPKI uses one key to encrypt (the private key) and the other key is used to decrypt (the public key). A Certificate Authority (CA) validates the holder of these resources. RPKI uses the hierarchical trust model where the trust runs from the End Entity (EE) Certificates back up to the Root CA Certificate. RPKI uses Digital Signatures to validate they are the legitimate holders of the routing resources.

Certificate Distribution The certificate structure mirrors the way IP addresses and AS numbers are distributed. The Internet Assigned Numbers Authority (IANA), which is a department within the Internet Corporation for Assigned Names and Numbers (ICANN), distributes names and addresses to the Regional Internet Registries (RIRs) who in turn distribute them to Local Internet Registries (LIRs), and finally out to customers. Figure 1 shows a map of the RIR areas.

Tech Note


Figure 1. Map of the RIR areas.

RPKI Details Overall RPKI operation is defined by a number of RFCs. RPKI uses X.509 certificates (described in RFC 5280 and RFC 6818), extensions for IP addresses and AS identifiers (RFC 3779), BGP Prefix Origin Validation (RFC 6811), and Resource Public Key Infrastructure (RFC 6810 and RFCs 6480-6493). This allows the LIRs to obtain a resource certificate listing the Internet number (AS and IP addresses) resources they hold; a certificate that validates their proof of holdership (in no sense do the LIRs “own” these resources). The LIRs create cryptographic attestations using this resource certificate. A cryptographic attestation is used to show a valid claim to the route announcements they make with the prefixes they hold. Figure 2 shows the general content of the X.509 certificate.

Figure 2. The X.509 Certificate for RPKI. RPKI calls these attestations Route Origination Authorizations (ROAs). ROAs authorize the AS to originate a given IPv4/IPv6 prefix and, optionally, the maximum prefix length as well. If the AS does not include a maximum length, then the AS is authorized only to advertise the exact prefix: anything more specific is

Tech Note


considered invalid. Using the maximum prefix length is a way to enforce aggregation to a shorter, less specific prefix length as well as to prevent route hijacking through a more specific announcement. RPKI uses a cynical rsync (RCynic) publication protocol to distribute the certificates from the RPKI Engines. This allows operators who wish to use the RPKI data to retrieve and store the data in their cache from all the operators who have entered RPKI data. Routers then retrieve the entire RPKI database from the caches. The RPKI-to-router protocol uses a form of serial number logic to check for changes to the database. This means that routers only need to download the full database once, and then check periodically to see if any ROAs have changed.

Figure 3 shows the process of passing these certificates from IANA through a Security Industry Authority (SIA) to the ROA. Note that the ISP adds the IP address, prefix length, and ASN as appropriate.

Figure 3. From IANA to ROA.

How Routers Process RPKI Data Ultimately, it is up to the router on how to process this information. The border routers of an AS should make these decisions. The router checks each of its BGP routes against the received ROAs and sets each route’s validation state to one of three possible states: VALID—A matching or covering ROA was found with a matching AS number. A covering ROA is one

with a less specific route than another ROA. That is, the ROA 10.0.0.0/16 “covers” 10.0.0.0/22. INVALID—A matching or covering ROA was found, but the AS number did not match or the mask

exceeded the defined maximum length. UNKNOWN (or NOT FOUND)—No matching or covering ROA was found. This could be because the

owner did not enter their prefix, or their certificate has expired, but there are other possible causes. Based on the route’s validation state, each operator makes a decision on how to proceed according to his or her local policy. The Junos OS accomplishes this using a routing policy. A possible use policy would drop any routes with a state of INVALID, but this action is not mandatory. In fact, draft-ietf-sidr-origin-ops-23 (“RPKI-Based Origin Validation Operation”) states:

“…until the community feels comfortable relying on RPKI data, routing on Invalid origin validity, though at a low preference, MAY occur.”

Tech Note


However, the goal of the community is to drop routes with a state of INVALID: “Announcements with Invalid origins SHOULD NOT be used, but MAY be used to meet special operational needs. In such circumstances, the announcement SHOULD have a lower preference than that given to Valid or NotFound.”

Figure 4. From Global RPKI to BGP Router.

Figure 4 shows the overall flow from the global RPKI level through the cache to the individual router.

RPKI Cache Server This origin validation technique requires three components:

• The ROA entries from the RPKI databases • A router to make decisions on these ROAs • The RPKI Cache Server (also called the RPKI Validator) between the RPKI database and router.

The cache server queries all of the distributed RPKI databases to collect all of the ROAs and validates each entry’s signature. The cache server then replies to the router’s query by forwarding all of the ROAs in the validated cache to the router. The router does not have to worry about decrypting the certificates because this is the task of the origin validator.

Tech Note


RPKI in Practice The latest version of RPKI-Based Origin Validation Operation (currently draft-ietf-sidr-origin-ops-23) discusses practical topics that are outside of the scope of this document. Some of these topics include the following: Security between the RPKI validator(s) and the routers—Caches should be located in a safe and

secure place with a secure transport between validator and routers. Redundant caches—Routers support multiple RPKI validator sessions and in this way avoid single

points of failure of device or communications link. Routers also support preference settings for which ROA to use if a conflict occurs between caches.

Local policy decisions—Instructions on how to handle a route with a validation state of INVALID or UNKNOWN (as mentioned above, these states are not the same).

ROA allocations—Ways to avoid defining ROAs that cause unexpected outages. For example, if a network operator owning a large block of prefixes creates a ROA with a maximum prefix length defined, but also has customers who are announcing sub-allocations from this block, then the customers’ smaller prefixes are considered INVALID (due to a longer-than-allowed prefix length) by a router unless the customers also create ROAs for their smaller blocks.

Proof of Concept Network A recent Juniper Networks customer requested RPKI origin validation testing for Proof Of Concept (POC) in the Westford World Wide POC Labs. Figure 5 shows the high-level network diagram for this test The POC Lab used an N2X Router Tester to simulate the two ISP routers connected with eBGP.

Tech Note


Figure 5. High-Level Network Diagram for RPKI Origin Validation Testing. The two MX80 routers, Router1 and Router2, are border routers that control the routes received from upstream ISPs. RPKI is configured on these two routers. A virtual machine (VM) was created (IP address 172.18.158.29) with RIPE NCC’s RPKI Validator (http://www.ripe.net/lir-services/resource-management/certification/tools-and-resources ) installed. This VM downloads the RPKI ROA’s from the internet.

Configuring RPKI RPKI origin validation is supported for BGP starting with Junos OS Release 12.2. This RPKI configuration used Junos OS Release 12.3R1.7. The BGP import policy used is tolerant of INVALID routes and does not reject them. In this case, a VALID state adjusts the local preference value to 110, an UNKNOWN value for routes adjusts the local preference to 100, and INVALID routes adjusts the local preference to 90. This adjustment agrees nicely with the text of the draft. The relevant configuration stanzas for the Router1 MX80 are highlighted in the following router options:

Router1 routing-options { router-id 10.104.0.254;

http://www.ripe.net/lir-services/resource-management/certification/tools-and-resources


Tech Note


autonomous-system 64496; validation { group rpki-validator { session 172.18.158.39 { IP address of the RPKI Cache Server refresh-time 120; hold-time 180; port 8282; local-address 172.18.1.127; } } } } protocols { bgp { group isp1-r1 { type external; import route-validation; Policy which acts on received BGP routes based on their

validation state export export-direct; neighbor 10.104.0.3 { authentication-key "$ABC123"; ## SECRET-DATA peer-as 64510; } neighbor 10.104.3.2 { peer-as 64500; } neighbor 10.104.0.1 { peer-as 64509; } } } } policy-options { policy-statement route-validation { this policy accepts all, including INVALIDs, and adjusts

their preference using Local Preference term valid { from { protocol bgp; validation-database valid; } then { local-preference 110; validation-state valid; accept; } } term invalid { from { protocol bgp; validation-database invalid; } then { local-preference 90; validation-state invalid; accept; } } term unknown { from protocol bgp; then { local-preference 100; validation-state unknown; accept; } } } }

Tech Note


Configuring the RPKI Validator This configuration uses the RPKI validator from RIPE NCC, but other validators are available. It is even possible to set up an “in-house” validation server. The first thing required for a RPKI validator is a Linux operating system with Java 1.6 and rsync support. The validation software comes from RIPE’s website (http://www.ripe.net/lir-services/resource-management/certification/tools-and-resources) and is copied onto the server. Figure 6 shows the RIPE NCC download screen for the RPKI validator software.

Figure 6. The RIPE NNC Validator Download Page. This configuration uses a VM running Centos 5.4. This particular RPKI validator package did not require installation—the package simply unzipped and ran from ./bin/rpki-validator. The package supports a web-based GUI on port 8080 for monitoring and configuring the validator, and listens on port 8282 for RPKI-to-router communications. The configuration process is shown and highlighted below.


Tech Note


[root@LinuxVM1 ~]# cd rpki-validator-app-2.7 [root@LinuxVM1 rpki-validator-app-2.7]# ./bin/rpki-validator 09:57:48,843 INFO Loading trust anchors... 09:57:49,691 INFO RTR server listening on 0.0.0.0/0.0.0.0:8282 09:57:50,205 INFO Welcome to the RIPE NCC RPKI Validator, now available on port 8080. Hit CTRL+C to terminate. 09:57:54,424 INFO Retrieved 14224 entries from http://www.ris.ripe.net/dumps/riswhoisdump.IPv6.gz, last modified at 2013-04-26T06:06:01.000-04:00 09:57:59,897 INFO Retrieved 526553 entries from http://www.ris.ripe.net/dumps/riswhoisdump.IPv4.gz, last modified at 2013-04-26T06:03:31.000-04:00 09:58:15,439 INFO Loaded trust anchor APNIC from LACNIC RPKI Root from location rsync://rpki.apnic.net/repository/apnic-rpki-root-lacnic-origin.cer, starting validation 09:58:15,458 INFO Loaded trust anchor APNIC from ARIN RPKI Root from location rsync://rpki.apnic.net/repository/apnic-rpki-root-arin-origin.cer, starting validation 09:58:15,459 INFO Loaded trust anchor APNIC from RIPE RPKI Root from location rsync://rpki.apnic.net/repository/apnic-rpki-root-ripe-origin.cer, starting validation 09:58:15,459 INFO Loaded trust anchor APNIC from IANA RPKI Root from location rsync://rpki.apnic.net/repository/apnic-rpki-root-iana-origin.cer, starting validation 09:58:15,460 INFO Loaded trust anchor AfriNIC RPKI Root from location rsync://rpki.afrinic.net/repository/AfriNIC.cer, starting validation 09:58:15,461 INFO Loaded trust anchor LACNIC RPKI Root from location rsync://repository.lacnic.net/rpki/lacnic/rta-lacnic-rpki.cer, starting validation 09:58:15,455 INFO Loaded trust anchor RIPE NCC RPKI Root from location rsync://rpki.ripe.net/ta/ripe-ncc-ta.cer, starting validation 09:58:17,815 INFO Prefetching 'rsync://rpki.apnic.net/member_repository/' 09:58:17,939 INFO Prefetching 'rsync://rpki.apnic.net/member_repository/' 09:58:18,228 INFO Prefetching 'rsync://rpki.afrinic.net/member_repository/' 09:58:18,421 INFO Client connected : /172.18.1.127:59378 09:58:18,537 INFO Prefetching 'rsync://rpki.apnic.net/member_repository/' 09:58:18,786 INFO Prefetching 'rsync://rpki.apnic.net/member_repository/' 09:58:19,079 INFO Prefetching 'rsync://rpki.ripe.net/repository/' 09:58:19,325 INFO Prefetching 'rsync://repository.lacnic.net/rpki/' 09:58:24,023 INFO Done prefetching for 'rsync://rpki.afrinic.net/member_repository/' 09:58:24,334 INFO Done prefetching for 'rsync://repository.lacnic.net/rpki/' 09:58:24,954 INFO Loaded trust anchor APNIC from AFRINIC RPKI Root from location rsync://rpki.apnic.net/repository/apnic-rpki-root-afrinic-origin.cer, starting validation 09:58:25,211 INFO Prefetching 'rsync://rpki.apnic.net/member_repository/' 09:58:29,944 INFO Done prefetching for 'rsync://rpki.apnic.net/member_repository/' 09:58:30,281 INFO Done prefetching for 'rsync://rpki.apnic.net/member_repository/' 09:58:33,626 INFO Finished validating AfriNIC RPKI Root, fetched 77 valid Objects 09:58:34,628 INFO Done prefetching for 'rsync://rpki.apnic.net/member_repository/' 09:58:35,161 INFO Done prefetching for 'rsync://rpki.apnic.net/member_repository/' 09:58:35,553 INFO Done prefetching for 'rsync://rpki.apnic.net/member_repository/' 09:58:36,043 INFO Sending Notify with serial 1 to all clients [ERROR] [04/26/2013 09:58:36.84] [default-akka.actor.default-dispatcher-4] [akka://default/user/$a] Futures timed out after [20000] milliseconds java.util.concurrent.TimeoutException: Futures timed out after [20000] milliseconds at akka.dispatch.DefaultPromise.ready(Future.scala:870) at akka.dispatch.DefaultPromise.result(Future.scala:874) at akka.dispatch.Await$.result(Future.scala:74) at akka.actor.ActorSystemImpl.actorOf(ActorSystem.scala:513) at akka.agent.Agent$$anonfun$sendOff$1.apply(Agent.scala:157) at scala.concurrent.stm.ccstm.NonTxn$.transformAndGetImpl(NonTxn.scala:408) at scala.concurrent.stm.ccstm.NonTxn$.transformAndGet(NonTxn.scala:404) at scala.concurrent.stm.ccstm.ViewOps$class.transformAndGet(ViewOps.scala:62) at scala.concurrent.stm.ccstm.CCSTMRefs$BaseRef.transformAndGet(CCSTMRefs.scala:42) at akka.agent.AgentUpdater.update(Agent.scala:294) at akka.agent.AgentUpdater$$anonfun$receive$1.apply(Agent.scala:288) at akka.agent.AgentUpdater$$anonfun$receive$1.apply(Agent.scala:287) at akka.actor.Actor$class.apply(Actor.scala:318) at akka.agent.AgentUpdater.apply(Agent.scala:286) at akka.actor.ActorCell.invoke(ActorCell.scala:626) at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:197) at akka.dispatch.Mailbox.run(Mailbox.scala:179) at akka.dispatch.ForkJoinExecutorConfigurator$MailboxExecutionTask.exec(AbstractDispatcher.scala:516) at akka.jsr166y.ForkJoinTask.doExec(ForkJoinTask.java:259) at akka.jsr166y.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:975) at akka.jsr166y.ForkJoinPool.runWorker(ForkJoinPool.java:1479) at akka.jsr166y.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:104) 09:58:36,223 INFO Finished validating APNIC from RIPE RPKI Root, fetched 23 valid Objects 09:58:38,790 INFO Sending Notify with serial 2 to all clients

Tech Note


09:58:39,156 INFO Started validating 484796 BGP announcements with 28 RTR prefixes. 09:58:40,356 INFO Finished validating APNIC from AFRINIC RPKI Root, fetched 14 valid Objects 09:58:41,718 INFO Finished validating APNIC from LACNIC RPKI Root, fetched 5 valid Objects 09:58:44,656 INFO Sending Notify with serial 3 to all clients 09:58:47,005 INFO Finished validating APNIC from ARIN RPKI Root, fetched 57 valid Objects 09:58:49,820 INFO Sending Notify with serial 4 to all clients 09:58:54,603 INFO Done prefetching for 'rsync://rpki.ripe.net/repository/' 09:58:55,246 INFO Sending Notify with serial 5 to all clients 09:59:44,638 INFO Completed validating 484796 BGP announcements with 28 RTR prefixes. 09:59:44,648 INFO Started validating 484796 BGP announcements with 28 RTR prefixes. 10:00:31,118 INFO Finished validating LACNIC RPKI Root, fetched 687 valid Objects 10:00:31,166 INFO Completed validating 484796 BGP announcements with 28 RTR prefixes. 10:00:31,178 INFO Started validating 484796 BGP announcements with 28 RTR prefixes. 10:00:51,901 INFO Sending Notify with serial 6 to all clients 10:01:14,022 INFO Completed validating 484796 BGP announcements with 28 RTR prefixes. 10:01:14,030 INFO Started validating 484796 BGP announcements with 28 RTR prefixes. 10:01:37,642 INFO Completed validating 484796 BGP announcements with 28 RTR prefixes. 10:01:37,683 INFO Started validating 484796 BGP announcements with 29 RTR prefixes. 10:01:39,416 WARN /whitelist akka.pattern.AskTimeoutException: Timed out at akka.dispatch.DefaultPromise.result(Future.scala:875) at akka.dispatch.Await$.result(Future.scala:74) at akka.agent.Agent.await(Agent.scala:190) at net.ripe.rpki.validator.bgp.preview.BgpAnnouncementValidator.validatedAnnouncements(BgpAnnouncementValidator.scala:68) at net.ripe.rpki.validator.config.Main$$anon$1.validatedAnnouncements(Main.scala:265) at net.ripe.rpki.validator.config.Main$$anon$1.validatedAnnouncements(Main.scala:231) at net.ripe.rpki.validator.controllers.WhitelistController$$anonfun$1.apply(WhitelistController.scala:56) at net.ripe.rpki.validator.controllers.WhitelistController$$anonfun$1.apply(WhitelistController.scala:56) at org.scalatra.ScalatraBase$class.org$scalatra$ScalatraBase$$liftAction(ScalatraBase.scala:160) at org.scalatra.ScalatraBase$$anonfun$invoke$1.apply(ScalatraBase.scala:155) at org.scalatra.ScalatraBase$$anonfun$invoke$1.apply(ScalatraBase.scala:155) at org.scalatra.ScalatraBase$class.withRouteMultiParams(ScalatraBase.scala:223) at net.ripe.rpki.validator.config.WebFilter.withRouteMultiParams(WebFilter.scala:40) at org.scalatra.ScalatraBase$class.invoke(ScalatraBase.scala:154) at net.ripe.rpki.validator.config.WebFilter.invoke(WebFilter.scala:40) at org.scalatra.ScalatraBase$$anonfun$runRoutes$1$$anonfun$apply$2.apply(ScalatraBase.scala:140) at org.scalatra.ScalatraBase$$anonfun$runRoutes$1$$anonfun$apply$2.apply(ScalatraBase.scala:139) at scala.Option.flatMap(Option.scala:146) at org.scalatra.ScalatraBase$$anonfun$runRoutes$1.apply(ScalatraBase.scala:139) at org.scalatra.ScalatraBase$$anonfun$runRoutes$1.apply(ScalatraBase.scala:138) at scala.collection.immutable.Stream.flatMap(Stream.scala:443) at org.scalatra.ScalatraBase$class.runRoutes(ScalatraBase.scala:138) at net.ripe.rpki.validator.config.WebFilter.runRoutes(WebFilter.scala:40) at org.scalatra.ScalatraBase$class.executeRoutes(ScalatraBase.scala:92) at net.ripe.rpki.validator.config.WebFilter.executeRoutes(WebFilter.scala:40) at org.scalatra.ScalatraBase$$anonfun$handle$1.apply$mcV$sp(ScalatraBase.scala:64) at org.scalatra.ScalatraBase$$anonfun$handle$1.apply(ScalatraBase.scala:62) at org.scalatra.ScalatraBase$$anonfun$handle$1.apply(ScalatraBase.scala:62) at scala.util.DynamicVariable.withValue(DynamicVariable.scala:57) at org.scalatra.DynamicScope$class.withResponse(DynamicScope.scala:50) at net.ripe.rpki.validator.config.WebFilter.withResponse(WebFilter.scala:40) at org.scalatra.DynamicScope$$anonfun$withRequestResponse$1.apply(DynamicScope.scala:30) at scala.util.DynamicVariable.withValue(DynamicVariable.scala:57) at org.scalatra.DynamicScope$class.withRequest(DynamicScope.scala:41) at net.ripe.rpki.validator.config.WebFilter.withRequest(WebFilter.scala:40) at org.scalatra.DynamicScope$class.withRequestResponse(DynamicScope.scala:29) at net.ripe.rpki.validator.config.WebFilter.withRequestResponse(WebFilter.scala:40) at org.scalatra.ScalatraBase$class.handle(ScalatraBase.scala:62) at net.ripe.rpki.validator.config.WebFilter.org$scalatra$servlet$ServletBase$$super$handle(WebFilter.scala:40) at org.scalatra.servlet.ServletBase$class.handle(ServletBase.scala:47) at net.ripe.rpki.validator.config.WebFilter.org$scalatra$FlashMapSupport$$super$handle(WebFilter.scala:40) at org.scalatra.FlashMapSupport$$anonfun$handle$1.apply$mcV$sp(flashMap.scala:145) at org.scalatra.FlashMapSupport$$anonfun$handle$1.apply(flashMap.scala:135) at org.scalatra.FlashMapSupport$$anonfun$handle$1.apply(flashMap.scala:135) at scala.util.DynamicVariable.withValue(DynamicVariable.scala:57)

Tech Note


at org.scalatra.DynamicScope$class.withRequest(DynamicScope.scala:41) at net.ripe.rpki.validator.config.WebFilter.withRequest(WebFilter.scala:40) at org.scalatra.FlashMapSupport$class.handle(flashMap.scala:135) at net.ripe.rpki.validator.config.WebFilter.org$scalatra$MethodOverride$$super$handle(WebFilter.scala:40) at org.scalatra.MethodOverride$class.handle(MethodOverride.scala:25) at net.ripe.rpki.validator.config.WebFilter.handle(WebFilter.scala:40) at org.scalatra.ScalatraFilter$$anonfun$doFilter$1.apply$mcV$sp(ScalatraFilter.scala:33) at org.scalatra.ScalatraFilter$$anonfun$doFilter$1.apply(ScalatraFilter.scala:33) at org.scalatra.ScalatraFilter$$anonfun$doFilter$1.apply(ScalatraFilter.scala:33) at scala.util.DynamicVariable.withValue(DynamicVariable.scala:57) at org.scalatra.ScalatraFilter$class.doFilter(ScalatraFilter.scala:32) at net.ripe.rpki.validator.config.WebFilter.doFilter(WebFilter.scala:40) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1338) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) at org.eclipse.jetty.server.Server.handle(Server.java:350) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:630) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:77) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:606) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:46) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:603) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:538) at java.lang.Thread.run(Thread.java:636) Caused by: akka.pattern.AskTimeoutException: Timed out at akka.pattern.PromiseActorRef$$anonfun$1.apply$mcV$sp(AskSupport.scala:274) at akka.actor.DefaultScheduler$$anon$6$$anon$7.run(Scheduler.scala:183) at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:94) at akka.jsr166y.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1381) at akka.jsr166y.ForkJoinTask.doExec(ForkJoinTask.java:259) at akka.jsr166y.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:975) at akka.jsr166y.ForkJoinPool.runWorker(ForkJoinPool.java:1479) at akka.jsr166y.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:104) 10:01:53,060 INFO Completed validating 484796 BGP announcements with 29 RTR prefixes. 10:01:53,067 INFO Started validating 484796 BGP announcements with 291 RTR prefixes. 10:01:56,075 INFO Completed validating 484796 BGP announcements with 291 RTR prefixes. 10:02:08,090 INFO Finished validating APNIC from IANA RPKI Root, fetched 1388 valid Objects 10:02:11,256 INFO Sending Notify with serial 7 to all clients 10:02:11,264 INFO Started validating 484796 BGP announcements with 358 RTR prefixes. 10:02:24,720 INFO Completed validating 484796 BGP announcements with 358 RTR prefixes. 10:03:10,353 INFO Finished validating RIPE NCC RPKI Root, fetched 5298 valid Objects 10:03:14,391 INFO Started validating 484796 BGP announcements with 4653 RTR prefixes. 10:03:14,751 INFO Sending Notify with serial 8 to all clients 10:03:40,561 INFO Completed validating 484796 BGP announcements with 4653 RTR prefixes. 11:57:50,637 INFO BGP entries from http://www.ris.ripe.net/dumps/riswhoisdump.IPv4.gz were not modified since 2013-04-26T06:03:31.000-04:00 11:57:50,637 INFO BGP entries from http://www.ris.ripe.net/dumps/riswhoisdump.IPv6.gz were not modified since 2013-04-26T06:06:01.000-04:00 11:57:53,555 INFO Started validating 484796 BGP announcements with 4653 RTR prefixes. 11:58:18,976 INFO Completed validating 484796 BGP announcements with 4653 RTR prefixes. 13:57:50,689 INFO BGP entries from http://www.ris.ripe.net/dumps/riswhoisdump.IPv4.gz were not modified since 2013-04-26T06:03:31.000-04:00 13:57:50,689 INFO BGP entries from http://www.ris.ripe.net/dumps/riswhoisdump.IPv6.gz were not modified since 2013-04-26T06:06:01.000-04:00 13:57:53,625 INFO Started validating 484796 BGP announcements with 4653 RTR prefixes. 13:58:16,854 INFO Completed validating 484796 BGP announcements with 4653 RTR prefixes. 13:58:39,406 INFO Loaded trust anchor APNIC from RIPE RPKI Root from location rsync://rpki.apnic.net/repository/apnic-rpki-root-ripe-origin.cer, starting validation 13:58:41,840 INFO Prefetching 'rsync://rpki.apnic.net/member_repository/'

Tech Note


13:58:41,894 INFO Loaded trust anchor AfriNIC RPKI Root from location rsync://rpki.afrinic.net/repository/AfriNIC.cer, starting validation 13:58:44,423 INFO Prefetching 'rsync://rpki.afrinic.net/member_repository/' 13:58:47,923 INFO Done prefetching for 'rsync://rpki.afrinic.net/member_repository/' 13:58:49,027 INFO Loaded trust anchor APNIC from AFRINIC RPKI Root from location rsync://rpki.apnic.net/repository/apnic-rpki-root-afrinic-origin.cer, starting validation 13:58:51,264 INFO Prefetching 'rsync://rpki.apnic.net/member_repository/' 13:58:51,269 INFO Loaded trust anchor APNIC from LACNIC RPKI Root from location rsync://rpki.apnic.net/repository/apnic-rpki-root-lacnic-origin.cer, starting validation 13:58:53,537 INFO Prefetching 'rsync://rpki.apnic.net/member_repository/' 13:58:58,008 INFO Done prefetching for 'rsync://rpki.apnic.net/member_repository/' 13:58:58,706 INFO Finished validating AfriNIC RPKI Root, fetched 77 valid Objects 13:59:02,336 INFO Sending Notify with serial 9 to all clients 13:59:02,500 INFO Loaded trust anchor APNIC from ARIN RPKI Root from location rsync://rpki.apnic.net/repository/apnic-rpki-root-arin-origin.cer, starting validation 13:59:02,677 INFO Started validating 484796 BGP announcements with 4653 RTR prefixes. 13:59:02,753 INFO Done prefetching for 'rsync://rpki.apnic.net/member_repository/' 13:59:07,216 INFO Done prefetching for 'rsync://rpki.apnic.net/member_repository/' 13:59:07,755 INFO Prefetching 'rsync://rpki.apnic.net/member_repository/' 13:59:13,216 INFO Finished validating APNIC from RIPE RPKI Root, fetched 23 valid Objects 13:59:13,447 INFO Finished validating APNIC from LACNIC RPKI Root, fetched 5 valid Objects 13:59:16,059 INFO Finished validating APNIC from AFRINIC RPKI Root, fetched 14 valid Objects 13:59:24,724 INFO Done prefetching for 'rsync://rpki.apnic.net/member_repository/' 13:59:32,795 INFO Sending Notify with serial 10 to all clients 14:01:08,517 INFO Loaded trust anchor LACNIC RPKI Root from location rsync://repository.lacnic.net/rpki/lacnic/rta-lacnic-rpki.cer, starting validation 14:04:23,555 INFO Prefetching 'rsync://repository.lacnic.net/rpki/' 14:04:30,602 INFO Loaded trust anchor RIPE NCC RPKI Root from location rsync://rpki.ripe.net/ta/ripe-ncc-ta.cer, starting validation 14:04:55,928 INFO Done prefetching for 'rsync://repository.lacnic.net/rpki/' 14:05:44,490 INFO Prefetching 'rsync://rpki.ripe.net/repository/' 14:05:47,355 INFO Loaded trust anchor APNIC from IANA RPKI Root from location rsync://rpki.apnic.net/repository/apnic-rpki-root-iana-origin.cer, starting validation 14:06:12,273 INFO Done prefetching for 'rsync://rpki.ripe.net/repository/' 14:06:39,687 INFO Prefetching 'rsync://rpki.apnic.net/member_repository/' 14:06:51,333 INFO Done prefetching for 'rsync://rpki.apnic.net/member_repository/' 14:11:34,610 INFO Completed validating 484796 BGP announcements with 4653 RTR prefixes. 14:11:34,619 INFO Started validating 484796 BGP announcements with 4653 RTR prefixes. 14:12:26,842 INFO Completed validating 484796 BGP announcements with 4653 RTR prefixes. 14:13:16,783 INFO Finished validating LACNIC RPKI Root, fetched 687 valid Objects 14:13:27,674 INFO Sending Notify with serial 11 to all clients 14:13:27,680 INFO Started validating 484796 BGP announcements with 4653 RTR prefixes. 14:15:48,525 INFO Completed validating 484796 BGP announcements with 4653 RTR prefixes. 14:15:58,821 INFO Finished validating APNIC from IANA RPKI Root, fetched 1388 valid Objects 14:16:09,790 INFO Sending Notify with serial 12 to all clients 14:16:09,799 INFO Started validating 484796 BGP announcements with 4653 RTR prefixes. 14:17:22,577 INFO Completed validating 484796 BGP announcements with 4653 RTR prefixes. 14:19:23,459 INFO Finished validating RIPE NCC RPKI Root, fetched 5298 valid Objects 14:19:27,953 INFO Sending Notify with serial 13 to all clients 14:19:27,961 INFO Started validating 484796 BGP announcements with 4653 RTR prefixes. 14:19:55,862 INFO Completed validating 484796 BGP announcements with 4653 RTR prefixes. 15:57:51,891 INFO Retrieved 14223 entries from http://www.ris.ripe.net/dumps/riswhoisdump.IPv6.gz, last modified at 2013-04-26T14:06:02.000-04:00 15:58:22,715 INFO Retrieved 526920 entries from http://www.ris.ripe.net/dumps/riswhoisdump.IPv4.gz, last modified at 2013-04-26T14:03:31.000-04:00 15:58:25,475 INFO Started validating 485144 BGP announcements with 4653 RTR prefixes. 15:59:00,481 INFO Completed validating 485144 BGP announcements with 4653 RTR prefixes.

Tech Note


RPKI Validator Verification and Operation Operators use the Web GUI to view the state of the RPKI validator process. Figure 7 shows how to check the state of downloading and validating ROAs from the preconfigured RPKI Engines (Trust Anchors).

Figure 7. Checking the Configured Trust Anchors. Operators can check the state of the connection from the routers to the validator. Figure 8 shows the view from the Router1 MX80, but the view from the Router2rfc MX80 is similar.

Tech Note


Figure 8. Checking the Router Sessions. Operators can check the connection state from the routers to the RPKI roots as well. Figure 9 shows the view of the validated ROAs from the various NICs and the RIPE NCC.

Figure 9. Checking the RPKI ROAs. The RPKI validator has a very useful feature, the Whitelist, which allows operators to create their own ROAs locally. Figure 10 shows three local ROAs (with emphasis).

Tech Note


Figure 10. Locally Created ROAs.

Tech Note


RPKI Junos OS Router Commands The Junos OS has two main CLI commands focused on RPKI:

- show validation - show route validation-state

The following sections detail the operation of these two commands.

The Show Validation Command The show validation command displays the state of the router with regard to the RPKI validators. user@Router1> show validation ? Possible completions: database Show contents of route validation database group Show route validation redundancy groups replication Show route validation replication information session Show route validation session information statistics Show route validation statistics user@Router1> show validation session Session State Flaps Uptime #IPv4/Ipv6 records 172.18.158.39 Up 0 06:33:59 3985/668 user@Router1> show validation database RV database for instance master Prefix Origin-AS Session State Mismatch 10.0.0.0/12-16 64508 172.18.158.39 valid 10.0.0.0/16-16 64508 172.18.158.39 valid 10.0.0.0/22-24 64500 172.18.158.39 valid 10.1.0.0/16-16 64508 172.18.158.39 valid 10.2.0.0/16-16 64508 172.18.158.39 valid 10.3.0.0/16-16 64508 172.18.158.39 valid 10.4.0.0/16-16 64508 172.18.158.39 valid 10.5.0.0/16-16 64508 172.18.158.39 valid 10.6.0.0/16-16 64508 172.18.158.39 valid 10.8.0.0/16-16 64508 172.18.158.39 valid 10.9.0.0/16-16 64508 172.18.158.39 valid 10.10.0.0/16-16 64508 172.18.158.39 valid 10.11.0.0/16-16 64508 172.18.158.39 valid 10.110.0.0/16-16 64508 172.18.158.39 valid 10.13.0.0/16-16 64508 172.18.158.39 valid 10.14.0.0/16-16 64508 172.18.158.39 valid 10.80.0.0/14-14 64507 172.18.158.39 valid 172.16.0.0/16-16 64500 172.18.158.39 valid <…> user@Router1> show validation statistics Total RV records: 4653 Total Replication RV records: 4653 Prefix entries: 4434 Origin-AS entries: 4653 Memory utilization: 907142 bytes Policy origin-validation requests: 700 Valid: 4 Invalid: 232 Unknown: 464 BGP import policy reevaluation notifications: 100 inet.0, 100 inet6.0, 0

Tech Note


The Show Route Validation-State Command The show route validation-state command displays routes having a certain validation state. user@Router1> show route validation-state ? Possible completions: invalid Invalid route validation state unknown Unknown route validation state unverified Unverified route validation state valid Valid route validation state

Following are the routes the N2X (AS 64500) is announcing and the resultant validation states on the MX. There are 30 /24 prefixes, all with their first (origin) AS path set to 64510: 10.0.0/24 thru 10.0.9/24

o The RPKI Validator has a whitelist for 10.0.0/22 and a maximum prefix length of 24. This means all of the routes should have a state of VALID; however, there is also a ROA for 10.0.0.0/12-16 (maximum /16) for origin AS of 64508. This marks 10.0.4/24 thru 10.0.9/24 as INVALID.

172.16.0/24 thru 172.16.9/24 o The RPKI Validator has a whitelist for 172.16.0.0/16 and a maximum prefix length of 16. This

means all of these routes should have a state of INVALID - even though the origin AS is correct, they have exceeded the maximum prefix length of /16.

172.30.0.0/24 thru 172.30.9.0/24 o The RPKI Validator does not have a whitelist for any of these routes, nor is there a ROA entry in

the database for any of them. This means all of these should have a state of UNKNOWN. user@Router1> show route validation-state valid inet.0: 40 destinations, 40 routes (40 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/24 *[BGP/170] 00:36:02, localpref 110 AS path: 64500 ?, validation-state: valid > to 10.104.3.2 via ge-1/0/1.3110 10.0.1.0/24 *[BGP/170] 00:36:02, localpref 110 AS path: 64500 ?, validation-state: valid > to 10.104.3.2 via ge-1/0/1.3110 10.0.2.0/24 *[BGP/170] 00:36:02, localpref 110 AS path: 64500 ?, validation-state: valid > to 10.104.3.2 via ge-1/0/1.3110 10.0.3.0/24 *[BGP/170] 00:36:02, localpref 110 AS path: 64500 ?, validation-state: valid > to 10.104.3.2 via ge-1/0/1.3110 user@Router1> show route validation-state unknown inet.0: 40 destinations, 40 routes (40 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.30.0.0/24 *[BGP/170] 00:36:06, localpref 100 AS path: 64500 ?, validation-state: unknown > to 10.104.3.2 via ge-1/0/1.3110 172.30.1.0/24 *[BGP/170] 00:36:06, localpref 100 AS path: 64500 ?, validation-state: unknown > to 10.104.3.2 via ge-1/0/1.3110 172.30.2.0/24 *[BGP/170] 00:36:06, localpref 100 AS path: 64500 ?, validation-state: unknown > to 10.104.3.2 via ge-1/0/1.3110 172.30.3.0/24 *[BGP/170] 00:36:06, localpref 100 AS path: 64500 ?, validation-state: unknown > to 10.104.3.2 via ge-1/0/1.3110 172.30.4.0/24 *[BGP/170] 00:36:06, localpref 100

Tech Note


AS path: 64500 ?, validation-state: unknown > to 10.104.3.2 via ge-1/0/1.3110 172.30.5.0/24 *[BGP/170] 00:36:06, localpref 100 AS path: 64500 ?, validation-state: unknown > to 10.104.3.2 via ge-1/0/1.3110 172.30.6.0/24 *[BGP/170] 00:36:06, localpref 100 AS path: 64500 ?, validation-state: unknown > to 10.104.3.2 via ge-1/0/1.3110 172.30.7.0/24 *[BGP/170] 00:36:06, localpref 100 AS path: 64500 ?, validation-state: unknown > to 10.104.3.2 via ge-1/0/1.3110 172.30.8.0/24 *[BGP/170] 00:36:06, localpref 100 AS path: 64500 ?, validation-state: unknown > to 10.104.3.2 via ge-1/0/1.3110 172.30.9.0/24 *[BGP/170] 00:36:06, localpref 100 AS path: 64500 ?, validation-state: unknown > to 10.104.3.2 via ge-1/0/1.3110 user@Router1> show route validation-state invalid inet.0: 40 destinations, 40 routes (40 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.4.0/24 *[BGP/170] 00:36:09, localpref 90 AS path: 64500 ?, validation-state: invalid > to 10.104.3.2 via ge-1/0/1.3110 10.0.5.0/24 *[BGP/170] 00:36:09, localpref 90 AS path: 64500 ?, validation-state: invalid > to 10.104.3.2 via ge-1/0/1.3110 10.0.6.0/24 *[BGP/170] 00:36:09, localpref 90 AS path: 64500 ?, validation-state: invalid > to 10.104.3.2 via ge-1/0/1.3110 10.0.7.0/24 *[BGP/170] 00:36:09, localpref 90 AS path: 64500 ?, validation-state: invalid > to 10.104.3.2 via ge-1/0/1.3110 10.0.8.0/24 *[BGP/170] 00:36:09, localpref 90 AS path: 64500 ?, validation-state: invalid > to 10.104.3.2 via ge-1/0/1.3110 10.0.9.0/24 *[BGP/170] 00:36:09, localpref 90 AS path: 64500 ?, validation-state: invalid > to 10.104.3.2 via ge-1/0/1.3110 172.16.0.0/24 *[BGP/170] 00:36:08, localpref 90 AS path: 64500 ?, validation-state: invalid > to 10.104.3.2 via ge-1/0/1.3110 172.16.1.0/24 *[BGP/170] 00:36:08, localpref 90 AS path: 64500 ?, validation-state: invalid > to 10.104.3.2 via ge-1/0/1.3110 172.16.2.0/24 *[BGP/170] 00:36:08, localpref 90 AS path: 64500 ?, validation-state: invalid > to 10.104.3.2 via ge-1/0/1.3110 172.16.3.0/24 *[BGP/170] 00:36:08, localpref 90 AS path: 64500 ?, validation-state: invalid > to 10.104.3.2 via ge-1/0/1.3110 172.16.4.0/24 *[BGP/170] 00:36:08, localpref 90 AS path: 64500 ?, validation-state: invalid > to 10.104.3.2 via ge-1/0/1.3110 172.16.5.0/24 *[BGP/170] 00:36:08, localpref 90 AS path: 64500 ?, validation-state: invalid > to 10.104.3.2 via ge-1/0/1.3110 172.16.6.0/24 *[BGP/170] 00:36:08, localpref 90 AS path: 64500 ?, validation-state: invalid > to 10.104.3.2 via ge-1/0/1.3110 172.16.7.0/24 *[BGP/170] 00:36:08, localpref 90 AS path: 64500 ?, validation-state: invalid > to 10.104.3.2 via ge-1/0/1.3110 172.16.8.0/24 *[BGP/170] 00:36:08, localpref 90 AS path: 64500 ?, validation-state: invalid > to 10.104.3.2 via ge-1/0/1.3110 172.16.9.0/24 *[BGP/170] 00:36:08, localpref 90 AS path: 64500 ?, validation-state: invalid > to 10.104.3.2 via ge-1/0/1.3110

Tech Note


Conclusion The main goal of BGP RPKI Origin Validation is to reduce the negative impact of routes with incorrect origins due to misconfigured routers. Validation does not address the malicious attacker who has redirected the forwarding path to be out of sync from the control path. There are other designs in progress to deal with those types of problems.

BGP RPKI Origin Validation has been in use on the Internet since January of 2011 and continued growth is expected. This paper shows the purpose, setup, and configuration for BGP RPKI Origin Validation. It also shows the basic operation along with showing the Junos OS router CLI commands used to verify its operation. This document forms a starting point for anyone implementing BGP RPKI Origin Validation. When setting up BGP RPKI Origin Validation in a production environment, we recommend first defining the local policy on how to treat each validation state and define the BGP import policy to match. Please refer to Juniper Network’s technical documentation on the Junos OS routing policies for more information.

Tech Note


Appendix A: Router Details user@Router1> show version Hostname: Router1 Model: mx80 JUNOS Base OS boot [12.3R1.7] JUNOS Base OS Software Suite [12.3R1.7] JUNOS Kernel Software Suite [12.3R1.7] JUNOS Crypto Software Suite [12.3R1.7] JUNOS Packet Forwarding Engine Support (MX80) [12.3R1.7] JUNOS Online Documentation [12.3R1.7] JUNOS Routing Software Suite [12.3R1.7]

Appendix B: Public Test Bed Euro Transit (via RIPE) has provided a public test bed running the Junos OS software. Here is the connection information:

Telnet to 193.34.50.26

Username: rpki, password: testbed

bgp resource public key infrastructure (rpki) … resource public key infrastructure (rpki) origin...

Documents