Large communities indicating RPKI VALID status

[Ondrej Zajicek]

On Sun, Apr 28, 2024 at 01:00:40PM +0200, Job Snijders wrote:
> On Sat, Apr 27, 2024 at 03:00:45PM +0200, Ondrej Zajicek via Bird-users wrote:
> > On Sat, Apr 27, 2024 at 08:18:18AM +0200, Daniel Suchy via Bird-users wrote:
> > > There's internet draft describing in detail, why it's not a good idea to
> > > store RPKI validation state inside community variables at all..
> > > 
> > > https://www.ietf.org/archive/id/draft-ietf-sidrops-avoid-rpki-state-in-bgp-00.html
> > 
> > Well, note that this draft is primarily about not announcing validation
> > state in transitive attributes to the whole internet.
> 
> Yes
> 
> > But there are good reasons for having validation state in
> > non-transitive BGP attributes (or communities properly filtered out on
> > AS egress). Validating RPKI and marking routes at AS ingress ensures
> > that all routers within AS have consistent routing state and thus
> > avoiding routing loops.
> 
> Perhaps I am missing something, but how does marking in itself help
> avoid routing loops?
> 
> I am under the impression that a requirement for intra-AS transitive
> marking follows from non-standard modifying of non-transitive local
> attributes (for example, 'weight' or 'preference') based on the
> validation state - which is not what I'd recommend to begin with.

Well, you are right. there are three ways how to define policy based on
RPKI status:

1) Validate RPKI for all routes and apply policy based on the validation
state on all routers.

2) Validate RPKI only for EBGP routes on border routers, mark result with
communities, then apply policy based on marks on all routers.

3) Validate RPKI only for EBGP routes on border routers, apply policy
based on validation state there and use (non-transitive) BGP attributes
for policy (like bgp_local_pref) to propagate it through AS.


The first approach is bad and can easily lead to inconsistent routing,
the second is better as marking ensures that different routers have
consistent view of validation states of routes, but the third approach is
even better and does not require explicit marking of validation states
(although one could argue that the validation state is implicitly encoded
in the policy-carrying BGP attributes).


> Merely rejecting RPKI-invalid routes at the AS ingress and *not*
> manipulating any other local or transitive path attributes will also
> ensure a consistent routing state.

Obviously.


> > Unfortunately large communities do not have transitive flag like
> > extended ones
> > so perhaps it would make sense to use extended community for this
> > purpose. Or perhaps there should be well-known extended community for
> > that ...
> 
> https://www.rfc-editor.org/rfc/rfc8097.html ?

Thanks, i was not aware of this.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
"To err is human -- to blame it on a computer is even more so."