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

[Jeff Wheeler <[e-mail]>]

A colleague brought the recent draft titled "Signaling Prefix Origin
Validation Results from an RPKI Origin Validating BGP Speaker to BGP
Peers" to my attention.


The authors clearly recognize a hazard of implementing this draft --
trusting the claimed validation state received from an eBGP neighbor.
The draft makes this explicit in both sections 5.2 (..receiving the ..
extended community) and section 7 (security considerations.)

Rather than depend on neighboring networks to configure their devices
appropriately, the draft introduces what I believe is a novel / unique
handling for an extcomm, namely, it is transitive yet only for one
hop, and has to be deleted instead of propagated to any neighbors.

This requirement seems like a significant obstacle to implementation.

It also sets up an incorrect expectation that you should be able to
trust if you receive this extcomm that you got it from the
directly-adjacent BGP neighbor, and not from a distant device.  This
won't be true until the neighbor updates his software, and normally in
BGP, we would expect a Capability to be signaled so implementations
have explicit knowledge of neighbors' relevant BGP features.  The
draft does not call for a Capability.

In light of all this, I think a Well-Known BGP Community makes more
sense than an extcomm.  Operators are already familiar with signaling
and filtering them and this would avoid the need for vendors to write
code for the special propagation scope of the proposed extcomm.


I further believe this draft might be misguided as a whole, but I
imagine the authors, being IXPs, may have their members to answer to;
and are perhaps trying to create transition tools to satisfy everyone.
My colleague reminded me that you must actively mess yourself up to
cause your IP address space to fail RPKI validation.

Perhaps it is unwise for IXP route-servers to propagate invalid routes.

-- 
Jeff S Wheeler <[e-mail]>