Re: [Sidrops] ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved

[John Curran <[e-mail]>]

Hi Randy!

On 15 Aug 2020, at 5:19 PM, Randy Bush <[e-mail]> wrote:
> 
> thanks for the preliminary post mortem

No problem…  (fairly obligatory after precipitating production infrastructure services) 

>> 3) Additional stringency to specs for the more common validators would
>>   help in some cases
> 
> fwiw, one dragon lab instance sra is running is so old it is rsync only,
> and so did not see the problem.
> 
> the assorted dragon labs instances i watch did not report anything.
> they quietly fell back from rrdp to rsync per spec.  this is both good
> news, things worked as expected, and bad news, they knew something went
> wrong and did not report it.
> 
> in general, the rpki infrastructure lacks alerts and lacks reporting
> channels other than ghostbuster records.

Something that we all should probably spend some time thinking about – 
particularly as the dependency on this infrastructure increases. 

> this week our (john kristoff doing the heavy lifting) short paper was
> accepted at imc.  will shout when there is camera ready.  from the
> abstract
> 
>    In this short paper, we introduce a framework to observe RPKI
>    relying parties (i.e., those that fetch RPKI data from the
>    distributed repository) and present insights into this ecosystem
>    for the first time. Our longitudinal study of data gathered from
>    three RPKI certification authorities (AFRINIC, APNIC, and our own
>    CA) identifies different deployment models of relying parties and
>    (surprisingly) larger inconsistent fetching behavior, which might
>    affect robustness in Internet routing. Our results reveal that some
>    relying parties are not able to connect to specific publication
>    points at all.


Thanks for the info – definitely some interesting work!
/John

John Curran
President and CEO
American Registry for Internet Numbers