[Outages-discussion] RPKI invalid 209.58.46.0/24 widely accepted (was: [outages] [23E-270B4044-0002] TATA issues in Los Angeles)

[Lukas Tribus]

Hello Job,


On Mon, 5 Oct 2020 at 21:46, Job Snijders <job at ntt.net> wrote:
>
> On Mon, Oct 05, 2020 at 09:21:57PM +0200, Lukas Tribus wrote:
> > On Mon, 5 Oct 2020 at 21:01, Job Snijders <job at ntt.net> wrote:
> > >
> > > Q: Why does AS 2914 still propagate some RPKI Invalid routes?
> > >
> > > A: On March 25th, 2020, the Global IP Network division of NTT Ltd. has
> > > completed a very important milestone in the deployment of RPKI
> > > throughout its network to date. Through this effort, AS 2914 no longer
> > > propagates a majority of RPKI invalid BGP routes that can potentially be
> > > received through the global Internet routing system.
> > >
> > > Currently, a number of technical caveats affects our ability for a 100%
> > > deployment. A limited number of RPKI invalid route announcements are
> > > still propagated to EBGP peers, at the moment of writing this the number
> > > is approximately 650 routes. We are developing technical workarounds and
> > > engaging vendors in order to enable us to gradually decrease this number
> > > in the coming months.
> >
> > I was aware of this FAQ item; it just did not occur to me that this
> > also included peers (I was thinking about internal stuff and big
> > customers).
>
> NTT has enabled RPKI ROV on ~ 96% of all EBGP sessions. The remaining 4%
> lands on devices which cannot support RPKI. In NTT's RPKI deployment the
> availbility of RPKI Origin Validation capability is not dependent on the
> customer / peer type, but on what device the EBGP session terminates.
> Replacing the non-RPKI devices is on the roadmap, however due to the
> COVID-19 crisis many migration plans incurred delays.
>
> As more and more customers and peering partners deploy RPKI ROV that 4%
> will effectively decrease - ideally both sides do RPKI ROV, but benefits
> exist as long as at least one side is doing RPKI ROV.
>
> > > We've reached out to tata, they are aware and working on it.
> >
> > Thanks, looks like the prefix is gone now.
>
> In the case of NTT's Tata peering in Sydney NTT relies on Tata
> performing RPKI ROV 'invalid == reject' in the egress direction (RFC
> 8893). They'll investigate what transpired.

Thanks for all that information, I didn't realize this kind of
configuration already is a thing.

Unsurprisingly reality is a bit more complex than one would imagine.


We don't have a RCA yet, but I guess monitoring validators, RTR
endpoints and the freshness of the data the RTR endpoint provides
really is important.


I wonder for how long 209.58.46.0/24 was announced there.


Lukas