[Sidrops] 'tagging' in draft-ietf-sidrops-validating-bgp-speaker

[Job Snijders <[e-mail]>]

Hi all,

Today there was yet another incident related to a BGP hijack of an IXP
Peering LAN Prefix: an ASN originated 80.249.208.0/24, which is part
of 80.249.208.0/21. This /24 route was an RPKI invalid announcement.

This misconfiguration negatively affected the AMS-IX platform, and some
of the authors are associated with this organisation. It is my hope that
a real world example of what I at the IETF 104 SIDROPS meeting
predicted, will help the authors better understand the negative security
implications of the current draft.

To better understand the severity of an event like this, one can
consider the publicly published statistics, here is a screenshot:
http://instituut.net/~job/amsix-rpki-disruption.png You can see an arrow
pointing to a low point in the graph, the graph should've been a
smoother sine-like shape.

The issue is that some BGP implementations will send the BGP packets
destined for 80.249.208.0/24 via the hijacked route rather than via the
directly connected interface with the less-specific route. For a period
of time a few hunderd gigabit/sec was dropped on the floor; this is of
course problematic.

Now, imagine this 80.249.208.0/24 route announcement passed through a
BGP speaker that adheres to the 'tagging' option in
draft-ietf-sidrops-validating-bgp-speaker, and instead of rejecting the
route announcement only a BGP Large Community is added to this RPKI
invalid announcement. I can assure everyone that the presence or absense
of that BGP Large Community will do *nothing* to reduce the negative
consequences of the existence of such a invalid more-specific /24.

It is my hope that the authors now recognize that knowingly propagating
RPKI Invalid announcements, even with a specific BGP community attached;
makes no sense from a routing security perspective. 

I propose the "tagging" option is removed from the draft document
entirely, or that the "invalid" community is removed and only the
'valid' and 'not-found' communities are specified. A BGP validating
speaker should not propagate RPKI invalid announcements, instead such
invalid announcements should be rejected; this document can state that.

Kind regards,

Job