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

Jeffrey Haas <jhaas@pfrc.org> Thu, 21 July 2022 17:07 UTC

Return-Path: <jhaas@pfrc.org>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF47C131959; Thu, 21 Jul 2022 10:07:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W09ho2ByW9z3; Thu, 21 Jul 2022 10:07:40 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1A3C13C511; Thu, 21 Jul 2022 10:07:39 -0700 (PDT)
Received: from smtpclient.apple (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id C91BE1E345; Thu, 21 Jul 2022 13:07:38 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <SA1PR09MB81421D152AC2DA200EDE1D9784919@SA1PR09MB8142.namprd09.prod.outlook.com>
Date: Thu, 21 Jul 2022 13:07:38 -0400
Cc: Nick Hilliard <nick@foobar.org>, "sidrops@ietf.org" <sidrops@ietf.org>, GROW WG <grow@ietf.org>, "draft-ietf-sidrops-aspa-verification@ietf.org" <draft-ietf-sidrops-aspa-verification@ietf.org>, "a.e.azimov@gmail.com" <a.e.azimov@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E19A89F1-B892-4D41-99A3-5C551C7FB640@pfrc.org>
References: <SA1PR09MB8142D357A98BFAAF206C387C848F9@SA1PR09MB8142.namprd09.prod.outlook.com> <66814cfa-8425-8063-9193-272bc8b28291@foobar.org> <1F8421AA-8514-41FB-A047-EEDAF975B934@pfrc.org> <SA1PR09MB81421D152AC2DA200EDE1D9784919@SA1PR09MB8142.namprd09.prod.outlook.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/U25xXLOto1E60fkTYl3fc0703i0>
Subject: Re: [Sidrops] [GROW] Any credence to AS_SET in the *middle* between AS_SEQUENCEs?
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jul 2022 17:07:42 -0000

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.sriram@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 <jhaas@pfrc.org>
> Sent: Thursday, July 21, 2022 6:22 PM
> To: Nick Hilliard
> Cc: Sriram, Kotikalapudi (Fed); sidrops@ietf.org; GROW WG; draft-ietf-sidrops-aspa-verification@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 <nick@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
>