I would want to implement RPKI in my network. I have gone through some documents by which i cant understand the implementation process.

What are the steps i should follow to implement RPKI in my network, Please help...

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer. – Ron Maupin Dec 15 '19 at 19:14

Your question is very broad, and you're not providing many details (for example which documents you read or what your network topology and equipment used is), but I'll try to give you some pointers.

First, implementing RPKI consists of two parts: 1. signing your prefixes so others can validate them 2. implementing RPKI validation on your network

Signing prefixes

Signing your prefixes usually is the easier and less impacting task. RIRs (like ARIN and RIPE) offer online tools to sign your prefixes by linking a prefix and prefix length to an autonomous system. Be wary of setups where prefixes are sometimes announced with a different prefix length or source ASN. This typically happens with DDoS mitigation, where sometimes more specific routes are advertised, possibly from a different network, to divert IP space under attack to a DDoS scrubbing center.

Once you've signed your prefixes, others are able to validate them if they implemented RPKI validation. Since more and more networks are doing this (for example, Tier1 network Telia started doing so last week), this will prevent your prefixes from being hijacked intentionally or unintentionally by other ASNs. Keep in mind that RPKI only offers a solution for Route Origin Validation (ROV), man-in-the-middle attacks by injecting an ASN in the AS-path are still possible, since RPKI offers no path validation.

Validating prefixes

My guess is that you're mostly interested in this. Since you're not providing any details on your network, it's a bit hard to be specific, but I can give some details on how to do this.

To do RPKI validation, a number of steps need to be taken:

  1. install one or more RPKI route validators. Currently, there are a few choices: RIPE RPKI Validator, NLnetlab's Routinator 3000 and Cloudflare's OctoRPKI. A route validator is a piece of software which retrieves RPKI data from all IRRs and verifies the signatures.
  2. configure validation sessions on your border routers with the route validator. This allows your router to populate a validation database which contains validated prefix, prefixlength and source ASN combinations.
  3. implement BGP filters on your external BGP sessions. On all inbound BGP sessions with peers, transit and BGP customers, you need to add a policy to reject any received prefix which are RPKI invalid. The exact way to do this depends on the equipment you're using, see links below for some websites which have configuration examples for various brands.

That last step is by far the most complex and time consuming step. A few additional remarks on that:

  1. as long as you don't implement RPKI validation on all upstream BGP sessions (peering and transit), RPKI invalid routes will still be available in your network if they're learned from one upstream and propagated via iBGP. You need to implement it everywhere, or be sure that all upstreams do it for you.
  2. the only correct way to deal with RPKI invalids is to reject them. I've seen a few (mostly older) examples mentioning assigning a lower local preference, but that does not help you a bit, since a more specific route with a lower local preference will allways win from a less specific route with a higher local preference. That way, you would still be routing traffic to a network which possibly hijacked the IP space.
  3. there is still a (slowly declining if I'm correct) number of prefixes which are RPKI invalid visible in the DFZ. Mostly, these are misconfigurations by their owners. My (and others') experience is that this is not a problem to start rejecting the prefixes (since others like AT&T, CloudFlare and Telia are doing so as well), but in specific cases it can be problematic. Validators offer options to whitelist or ignore specific prefixes.
  4. make sure you reject RPKI invalid routes on your outbound sessions as well. You don't want to be propagating any invalid routes.
  5. train your support staff and provide them with tooling to check RPKI validation status for IP's. Your support staff needs to understand that complaints about destinations being unreachable can be related to RPKI, they need to know how to identify those and how to deal with that.

There's a number of good resources on RPKI I can recommend:

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.