Re: [Sidrops] ROV with ATOMIC_AGGREGATE

[Jeffrey Haas <[e-mail]>]

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.

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.

> 
> 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.

-- Jeff

[1] The ATOMIC_AGGREGATE feature in BGP is an interesting anatomical vestige from the BGP-3 to BGP-4 transition that never got deployed properly.  The originally desired behavior for it was incorrect from the start and unimplementable.  It also made my nascent life in IETF work unnecessarily interesting.