iamjeffvader's studymotron and rantatorium

Here is a quick look at static RPKI on the Nokia 7×50.

Resource Public Key Infrastructure is a security measure which attempts to solve, or minimise, the impact of prefixes being disseminated from invalid source ASNs.  This is where an AS will hijack and originate a prefix when it does not own it.  Sure this can be because of a legitimate mistake but it can also be used for being naughty.

You can use dynamic or static mappings to confirm the legitimacy of the prefix origination.  Here I will use static only.

To demonstrate this we will originate prefix 192.0.2.1/32 from ASN 64497 (legitimate owner) and ASN 64496 (naughty people).  ASN 64498 will use static mappings to decide which is the source of truth. For reference sros1 is running release 14, sros3 is release 13 and sros8 is the all new release 15 router.

First we configure the loopback addresses and BGP sessions.

All we have done here is configure a loopback on sros1 of 192.0.2.1/32, set our ASN to 64496 and configured our BGP parameters for our session to sros8.  We configure the equivalent BGP config on sros8

We then confirm sros8 is receiving and installing 192.0.2.1/32 as the best path.

Before we look at competing ASNs let’s enable prefix validation on sros8.

We can configure our dynamic relationship with a server under the rpki-session config context or we can configure statically.  As I don’t have the option of using RPKI server mappings right now I choose static.  Here we configure an entry that covers anything within 192.0.2.0/24 up to a prefix length of /32.  This covers off the 192.0.2.1/32 prefix I am receiving from sros1.  We then specify the ASN of the source and either tag it as valid or invalid.  Here we are going invalid as we know AS64496 should not be originating this particular prefix.

If we look at our local database on sros8 we can see a flag of Static-I set.  This means it is statically configured as invalid.

Now will BGP reject the prefix?  

No because we haven’t told the BGP process to do anything with the origin validation information yet.  We need to enable origin validation within the BGP group context.

So now we have enabled origin validation with the BGP group config we still have one step to carry out.  As shown above we need to tell the BGP process that anything marked as origin-invalid should be considered unusable.  Once we make that change the path will no longer be considered in the best path selection process.

Now what if AS64497 starts legitimately advertising 192.0.2.1/32, will we allow this?  One would hope so!

We now have our peering up to both sros1 and sros3, both of which are sending us 192.0.2.1/32.

On the prefix received from sros3 we have an origin validation state of NotFound, basically not explicitly valid or invalid.  sros1 reports the state as invalid and, as we saw, it cannot be considered for best path determination.