Sriram, It's no more broken that the other brief-mode aggregation issues that OV has. See our discussions on the sloppiness of origin-AS in those circumstances - I think they're applicable here.
-- Jeff > On Jul 21, 2022, at 12:46 PM, Sriram, Kotikalapudi (Fed) > <kotikalapudi.sri...@nist.gov> wrote: > > 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 <jh...@pfrc.org> > Sent: Thursday, July 21, 2022 6:22 PM > To: Nick Hilliard > Cc: Sriram, Kotikalapudi (Fed); sidr...@ietf.org; GROW WG; > draft-ietf-sidrops-aspa-verificat...@ietf.org > Subject: Re: [GROW] Any credence to AS_SET in the *middle* between > AS_SEQUENCEs? > >> On Jul 21, 2022, at 4:36 AM, Nick Hilliard <n...@foobar.org> 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 > _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
