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

[Job Snijders <[e-mail]>]

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.

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