[c-nsp] RPKI extended-community RFC8097

[Job Snijders]

On Tue, Apr 21, 2020, at 23:34, Radu-Adrian FEURDEAN wrote:
> On Tue, Apr 21, 2020, at 22:42, Nick Hilliard wrote:
> > > BIRD. And RFC8097 doesn't exactly match that scenario either.
> > 
> > RFC8097 is ibgp only.  There are compelling reasons not to do this with ebgp.
> 
> That's why it "doesn't exactly match the scenario". And why IXPs that 
> signal validation state, do it their own way (LINX and France-IX comes 
> to my mind).
> However, did you note that after the "MUST drop the extcomm", the next 
> phrase says: "However, it SHOULD be possible to configure an 
> implementation to send or *accept* the community when warranted" ?

Any operator can attach any BGP Community to signal things like "valid", "not-found", "orange", but the two operators need to agree on it between their ASNs and assume both sides will delete & set such communities in the right places. If you want to signal something, pick a normal or a large community (within your own 'namespace') and tell your peers that's the one you are using for a specific purpose.

However, I don't think you can really signal the validation state across administrative boundaries. The trust is not transitive, especially over most-likely unsecured BGP transport. There is no mechanism in BGP to verify if the peer can be trusted to set the right communities, operational parameters about the peer's validation process are not visible through BGP.

Kind regards,

Job