Re: [Sidrops] [GROW] Any credence to AS_SET in the *middle* between AS_SEQUENCEs?

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

Jeff,

Thanks for the detailed insights. 

I gather that at least Nick and Job are clearly in favor of marking an UPDATE Invalid (i.e., a route leak in the present context) for having an AS_SET anywhere in the AS_PATH. (I.e., forget about having the Unverifiable flavor.) It appears Randy is also in the same camp.

Are you also OK going along with it?

In Section 5.3 (Mitigation), it is also stated:
   If the output of the AS_PATH verification procedure is "Invalid" the
   route MUST be rejected.

Sriram

________________________________________
From: Jeffrey Haas <[e-mail]>
Sent: Thursday, July 21, 2022 6:22 PM
To: Nick Hilliard
Cc: Sriram, Kotikalapudi (Fed); [e-mail]; GROW WG; [e-mail]
Subject: Re: [GROW] Any credence to AS_SET in the *middle* between AS_SEQUENCEs?

> On Jul 21, 2022, at 4:36 AM, Nick Hilliard <[e-mail]> wrote:
>
> Sriram, Kotikalapudi (Fed) wrote on 19/07/2022 22:24:
>> Question: Operationally, is an AS_SET ever used in the*middle*
>> between AS_SEQUENCEs? Or, should one simply give zero credence to
>> it?
>
> tl;dr: epsilon levels of credence.
>
> in the context of EBGP connectivity, on the internet, having an AS_SET in the middle of a sequence means that whoever is responsible for leaking that is exposing far more about their internal sausage factory than I ever want to know.  There could possibly be valid reasons, but it's far more likely that this is the outcome of temporary or simply poor quality routing policies.

In principle, "complex aggregation" permitted you to avoid shortening the as-path lengths excessively.

Simple example:

A: 100 5 4 3 2 1
B: 200 5 4 3 2 1

Complex Aggregated path: [ 100 200 ] 5 4 3 2 1; length 6
Simple aggregated path: [ 1 2 3 4 5 100 200 ]; length 1

In practice, the majority of aggregation happens near leaf ASes from provider space delegated to multi-homed customers.  So, "throw it all into the set" works fine for the desired properties.  In the set of ASes with aggregated prefixes, they are expected to have all of the more specifics.

Where brief aggregation gets tricky is where the cut point is for the aggregating AS that will now be the "origin".  Those procedures don't interact nicely with RPKI OV, and are the main detail I've been owing a write-up on for the deprecate as-set document.

One thing very much worth mentioning is that anything clever some provider might want to do with complex aggregation is likely to be undone by anyone else doing aggregation and using the simple mode.

> ASPA somewhat assumes a naive/simplistic routing policy.  Having AS_SET support of this style means that it's entertaining a far greater level of complexity than ASPA's target network might operate. There are echoes of the DNS camel here.

I suspect that for simple aggregation the procedures for ASPA could be clear.  I don't know that I'd try to support complex aggregation.

And that said, ASPA will have the same concerns with brief mode aggregation that OV does.

-- Jeff