[Community-Discuss] Blog Published this week

[Nishal Goburdhan]

On 16 Apr 2021, at 1:46, Ronald F. Guilmette wrote:


> In message <7913C33A-CA19-45C0-8CC2-1D0A9167D4CF at controlfreak.co.za>,

> "Nishal Goburdhan" <nishal at controlfreak.co.za> wrote:

>

>>> https://bgp.he.net/AS398968

>>

>> that is not a real-time view;  even the good people at he.net will 

>> tell

>> you so.

>

> Facinating.  Can you explain the following route data for AS398968,

> which comes from RIPEStat and which I just fetched fresh 1 minute ago?


loosely speaking, “implementing rpki” has two parts;  #1 signing 
your prefixes, and #2, validating others’ prefixes.
the output of the validation process process one of three answers:  not 
found, valid, or invalid.
what many global operators that live in the DFZ (ie. the telias and 
cogents of the world) have done, is to drop prefixes that fail 
validation (colloquially rpki “invalids”)

if you are contending that cogent/telia/anyone else should be dropping 
these prefixes (because the network in question claims to do rpki 
validation), then, they would do so only if the prefixes returned 
“invalid” as the output of the validation process.  a quick test  
tells me that none of these are “invalids”, and in fact, there are 
some validly signed prefixes here.

there are many ways to see the “rpki status”;  here’s one:
https://validator.inx.net.za/#/398968/23.252.161.0%2F24  [1]

the output here, clearly states “No VRP Covers the Route Prefix”  
ie.  rpki state = not found.
“not found” is *not* the same as “invalid”, so there is no 
reason for any network to drop these prefixes.

hth,
-n.

[1]  note: this is not routing data;  this is validation data.