Re: [Sidrops] ROV with ATOMIC_AGGREGATE

[Ben Maddison <[e-mail]>]

Hi Jeff,

On Thu, 2020-03-12 at 10:56 -0400, Jeffrey Haas wrote:
> Ben,
> 
> 
> > On Mar 12, 2020, at 8:54 AM, Ben Maddison <
> > benm=[e-mail]> wrote:
> > 
> > Thanks Jeff,
> > 
> > You can be kinda hard to parse sometimes!
> 
> Sorry, this was pre-coffee.
> 
:-)

> > 
> > On Thu, 2020-03-12 at 07:07 -0400, Jeffrey Haas wrote:
> > > 
> > > If the origin AS, sans sets, is correct - the implementation
> > > should
> > > believe it.
> > > 
> > 
> > You're saying that:
> > 
> > ```
> >   o  Route Origin ASN: The origin AS number derived from a Route as
> >      follows:
> > 
> >      *  the rightmost AS in the final segment of the AS_PATH
> > attribute
> >         in the Route if that segment is of type AS_SEQUENCE, or
> > 
> >      *  the BGP speaker's own AS number if that segment is of type
> >         AS_CONFED_SEQUENCE or AS_CONFED_SET or if the AS_PATH is
> > empty,
> >         or
> > 
> >      *  the distinguished value "NONE" if the final segment of the
> >         AS_PATH attribute is of any other type.
> > ```
> > (https://tools.ietf.org/html/rfc6811#section-2)
> > 
> > Applies, as is, irrespective of the possible presence of
> > ATOMIC_AGGREGATE, right?
> 
> Exactly.
> 
Thanks!

> ATOMIC_AGGREGATE these days[1] means that aggregation has been done
> at some point in the life of the BGP AS_PATH for the NLRI in
> question.
> 
> Once it has been added, subsequent aggregation could have been done,
> and may have set elements added to it.  In such cases, the current
> desired behavior is that the route cannot be used for origin
> validation purposes.
> 
> However, similarly, subsequent aggregation may be done and further
> information lost from the AS_PATH; we don't get more than one
> ATOMIC_AGGREGATE marker and it has no counter.
> 
> My general observations on aggregation with respect to origin
> validation have been:
> - Parties that have the "right" to aggregate (prefix ownership, or
> owner of prefix that more specifics have been delegated from) can
> aggregate and it'd still match RPKI policies.
> - Proxy aggregation by other parties will fail RPKI policies.
> 
> The first case means that ATOMIC_AGGREGATE ("brief") style
> aggregation is fine and fits the intent of RPKI origin
> validation.  The second case doesn't fit the intent and will fail
> regardless fo whether there's a set or not.
> 
> It's this set of properties that has me being an objecting party to
> the movement to completely kill set behaviors in BGP as-paths.  it
> has more than the usual incremental deployment issues to be
> conformant with actual "deprecation" and doesn't help with the
> desired intent.  I'm quite happy to say "don't do that" and let RPKI
> slowly extinguish the feature's use.
> 
I'm in agreement with all of this, except that I'm not sure that I see
how the argument against deprecation follows.
Surely the "Treat-as-withdraw" handling is just a stronger "don't do
that" signal. In fact, in an imaginary strict-ROV-everywhere-world,
they come down to the same thing. Except treat-as-withdraw is probably
easier to troubleshoot.

> > 
> > Cheers,
> > 
> > Ben
> > 
> > > If you want path validation, we need bgpsec.
> > > 
> > 
> > Depending on what you want to validate it *against*, you may need
> > ASPA.
> > But that's a different conversation.
> 
> Indeed.  Relevant to this particular conversation, if you're
> concerned about truncated paths, which is what ATOMIC_AGGREGATE is
> intended to help signal, you may care that the route's origin AS was
> actually originated by that AS.
> 
I'm mostly interested in the ~12k false-Invalids that I'm currently
seeing on the implementation that I'm testing and need to deploy!

If anyone else thinks that I shouldn't tell my vendor that they've
written a bug, please say why, soon?

Cheers,

Ben