Subject: [Sidrops] ROV with ATOMIC_AGGREGATE

From: Ben Maddison <[email-masked]>
Date: Thu, 12 Mar 2020 09:04:08 +0000

Hi all,

I'm currently working with one of our vendors on getting their initial
ROV implementation ready to ship.

In their current code they are setting validation state of a route to
Invalid if:
1. The route has the ATOMIC_AGGREGATE attribute set; and
2. The route is covered by any valid ROA.

Note that they are also, correctly, setting state=Invalid if the final
segment of AS_PATH is an AS_SET (and the route is covered by a ROA).
This is independent of the above behavior.

There appears to me to be clearly wrong. I can find nothing in any
relevant RFC that requires the validating BGP speaker to consider the
ATOMIC_AGGREGATE attribute one way or another.

I'd like to ask the WG to correct me in case I have missed something,
before I tell the vendor to go fix this, please?

Cheers,

Ben

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 12 Mar 2020 07:07:34 -0400

I am massively behind in my IETF mail, but the subject line caught my eye.

> On Mar 12, 2020, at 5:04 AM, Ben Maddison <benm=[email-masked]> wrote:
> 
> Hi all,
> 

ATOMIC_AGGREGATE is the remaining fig leaf of proper aggregation.  Many implementations didn't check the resultant AS_PATH to see if it was truncated or not as part of aggregation, and simply sets the flag.  And, since this is showing up in some cases as part of private-as aggregation steps as well you might not have a good belief that it is improperly being set depending on the point it's injected into the Internet tables.

If the origin AS, sans sets, is correct - the implementation should believe it.

If you want path validation, we need bgpsec.

-- Jeff

---

From: Ben Maddison <[email-masked]>
Date: Thu, 12 Mar 2020 12:54:51 +0000

Thanks Jeff,

You can be kinda hard to parse sometimes!

> If the origin AS, sans sets, is correct - the implementation should
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?

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.

Cheers,

Ben

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 12 Mar 2020 10:56:51 -0400

Ben,

> On Mar 12, 2020, at 8:54 AM, Ben Maddison <benm=[email-masked]> wrote:
> 
> Thanks Jeff,
> 

Sorry, this was pre-coffee.

> Applies, as is, irrespective of the possible presence of

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.

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

---

From: Ben Maddison <[email-masked]>
Date: Thu, 12 Mar 2020 15:57:02 +0000

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=[email-masked]> wrote:
> > 
> > Thanks Jeff,
> > 
:-)

> > > If the origin AS, sans sets, is correct - the implementation
> > > should
> > > believe it.
> > > 
> > 
> > You're saying that:
> > 
> > ```
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.
> 
> - 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.
> 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.

> 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

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 12 Mar 2020 12:10:30 -0400

Ben,

> On Mar 12, 2020, at 11:57 AM, Ben Maddison <benm=[email-masked]> wrote:

The original "deprecation" text involved trying to remove the code points for sets and all of the implications that has.

We've largely evolved past that in the current proposal.

-- Jeff