Re: [Sidrops] Comments on draft-ietf-sidrops-validating-bgp-speaker

[Job Snijders <[e-mail]>]

On Thu, Feb 15, 2018 at 02:39:31PM +0100, Job Snijders wrote:
> On Wed, Feb 14, 2018 at 11:22:48PM +0100, Aris Lambrianidis wrote:
> > Let me also point out that in theory, forwarding "invalid" prefixes is
> > bad. However, our own operational experience so far has shown that
> > most ROA invalid prefixes are due to misconfiguration rather than
> > malicious intent.
> 
> A major consideration is that all IXP route servers only offer a
> _partial_ view on the global routing table, nobody ever single-homes
> behind an IXP route server. So, if the IXP route server does _not_
> propagate invalid prefixes to its participants, operationally speaking
> the 'worst' thing that can happen is that alternative paths are used via
> either bilateral peering or other arrangements. If anything, if people
> depend on keeping their traffic on the IX with the help of the RS, there
> is an actual monetary incentive to repair the misconfigured ROAs. If
> anything, IXPs should take a leading role in deploying RPKI Origin
> Validation - this draft proposes the opposite: a watering down that
> justifies propagation of bad announcements.
> 
> By merely tagging the invalid prefixes with a community, the sender of
> those BGP announcements has significantly visiblity into problem, since
> the sender of such announcements won't see the 'invalid community'
> themselves.

Oops, some words were missing from the above paragraph:

    By merely tagging the invalid prefixes with a community, the sender
    of those BGP announcements has significantly less visiblity into the
    problem, since the sender of such announcements won't see the
    'invalid community' themselves.

> I think in context of IXP Route Servers it is very detrimental to the
> Internet community's overall effort to improve routing security if
> invalid malicious announcements are distributed alongside these
> 'misconfigurations', and the propagation of misconfigurations is deemed
> more important than blocking of incorrect announcements.
> 
> Given the prevalence of routing incidents and the critical effects they
> have on business continuity, I'm concerned that time is wasted on
> actively lowering the bar ('rpki-light' aka 'draft-ietf-sidrops-validating-bgp-speaker')
> rather than spending time on setting higher standards.
> 
> ESPECIALLY given the position of route servers in the routing ecosystem.
> If we consider a misconfigured RPKI ROA an 'error', favoring strict
> error handling (dropping) over attempting error recovery is an effective
> technique for ensuring that faults receive attention. 
> 
> Kind regards,
> 
> Job