Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 02/17/2023 (Feb 17 2023)
Claudio Jeker <cjeker@diehard.n-r-g.com> Fri, 27 January 2023 10:42 UTC
Return-Path: <cjeker@diehard.n-r-g.com>
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 A06B1C151549 for <sidrops@ietfa.amsl.com>; Fri, 27 Jan 2023 02:42:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.192
X-Spam-Level:
X-Spam-Status: No, score=-4.192 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 z5Ps5k4wmK7P for <sidrops@ietfa.amsl.com>; Fri, 27 Jan 2023 02:42:31 -0800 (PST)
Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA512) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D30C151534 for <sidrops@ietf.org>; Fri, 27 Jan 2023 02:42:30 -0800 (PST)
Received: (qmail 26731 invoked by uid 1000); 27 Jan 2023 10:42:28 -0000
Date: Fri, 27 Jan 2023 11:42:28 +0100
From: Claudio Jeker <cjeker@diehard.n-r-g.com>
To: sidrops@ietf.org
Message-ID: <Y9OqlOLoAz/Oye/2@diehard.n-r-g.com>
References: <CAL9jLaY4hraMLPVC1zJP3Cuss1XVHFHY08Adg_s+_rejgb9RtA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAL9jLaY4hraMLPVC1zJP3Cuss1XVHFHY08Adg_s+_rejgb9RtA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/w1_rRbKGAKjFR2NFjX7DQPUWsgk>
Subject: Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 02/17/2023 (Feb 17 2023)
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: Fri, 27 Jan 2023 10:42:32 -0000
On Thu, Jan 26, 2023 at 01:43:42PM -0500, Christopher Morrow wrote: > Howdy People Of the Internet: > The authors of the draft/document: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ > > have asked for a working-group last-call event to happen. > Please take a few moments to read the ~15 pages, provide > assent, comments, criticism (in the form of replacement text) in the > next 2 or so weeks. > > This last-call should expire 17/feb 2023 I sent a mail on Nov 2nd with a large amount of feedback to this draft. None of it has been incorporated so a last-call for this draft is very premature. There are additional concerns I have with this draft after working on the only BGP implementation over the last weeks. I will send a follow up regarding my findings. I included my feedback from Nov 2nd below. Regards -- :wq Claudio Date: Wed, 2 Nov 2022 18:23:06 +0100 From: Claudio Jeker <cjeker@diehard.n-r-g.com> To: sidrops@ietf.org Subject: [Sidrops] Feedback for draft-ietf-sidrops-aspa-verification-11 Hi Sidrops and draft authors, Here some feedback to draft-ietf-sidrops-aspa-verification-11 now that I started to implement this for OpenBGPD. Section 1 & 2 There is a big bit missing in the introduction which gives an overview what ASPA does. This section would also explain some of the technical bits and jargon used in this draft. Especially explain how downstream/upstream checks work. I found the presentation in [sriram1] important to understand the concept of ASPA verification. Without that presentation I think I would not correctly understand many things in this draft. Section 4 A relying party (RP) must have access to a local cache of the complete set of cryptographically valid ASPAs when performing the customer-provider verification procedure. and The following algorithm describes the customer-provider verification procedure for a selected AFI: 1. Retrieve all cryptographically valid ASPAs with the selected AFI that have a customer value of AS1. The union of SPAS from these ASPAs forms the set of authorized providers. What has an RP to do with the code running on a BGP router. Also the Customer-Provider Verification Procedure is the core lookup function. There should be no step 1. instead there should be a concept similar to VRPs. IMO the above texts should be in section 3. Maybe mention that either static config or RTR can be used to distribute verified ASPA sets and that all sets are merged together. Also I think using the terms "Unknown", "Valid", "Invalid" is inappropriate when it comes to customer-provider lookups. Mainly because "Invalid" is misleading. "Valid" should be "Provider" and "Invalid" should be "Not-Provider". I also accept other terms but mixing Valid/Invalid here with the use in Section 5 (and the final outcome of the ASPA lookup is confusing). The C-P lookup does not define if a path is valid or not. It just tells if there is a C-P relation or not (or it is unknown). Section 5 Is the enforce neighbor-as a proper MUST or is this just la la la nice to have? From my understanding it is an important bit of not allowing empty or wrong paths in. In OpenBGPD enforce neighbor-as is on by default but it can be turned off. So should this be enforced for customer, provider, rs and peer sessions? Also on rs-client session enforce-as becomes more complex (see below). Section 5.1 Please just take all of this behind the barn and start over. The text is a mess, it is not how the code should be implemented. It is confusing and needs a lot of mental gymnastics to follow the text. This part is crucial to properly implement ASPA. Using the same I everywhere is confusing (also I is a very bad letter in text) and then this monstrosity "AS(1),AS(2),..., AS(I-1), AS(I), AS(I+1),..., AS(N)" does not help either. It has no real value (especially the repetition). Also I really dislike that it is the wrong way around. The path is actually AS(N) ... AS(1) since AS(1) is the origin AS. More about this further below. The calculation of the reverse indexes is only required for provider sessions (local role customer). Also it would be nice to not depend on reversing the AS path but instead explain that one can start from AS(N) and backtrack selecting the maximum instead of minimum and then use N - 'found index' as the result. Also note that Section 5.1.1 adds injury to insult by just confusing even more about what the heck is going on. The text should just mention that for Non-Transparent RS sessions the RS ASN should be skipped in the ASPATH and only the reminder checked as defined in Section 5.1. Also detecting this case will be fun: will it be enough to depend on 'role rs-client' and 'enforce neighbor-as yes'? An alternative is to have 'role rs-client non-transparent' as config. I have doubts that this non-transparent IXP check works in real life. While it does work for the immediate rs-client it requires that the non-transparent IXP is listed as provider in all its rs-clients ASPA objects. I guess this should be listed in Section 5.4. At least currently there is nothing like that mentioned in the draft. Section 5.3 Second paragraph (the left and right are confusing especially since it is the reverse of what you normally get (ASPA reversed the ASPATH and so everything is the wrong way). The left-most 'AS(1)' is the origin AS (which is normally the right-most AS) and right-most 'AS(N)' is the neighbor-as (which is normally the left-most AS). If there is an upstream ramp but no downstream ramp or vice versa, then clearly the UPDATE is valid (i.e., not a route leak). However, if both ramps exist, then the UPDATE is Valid if and only if either one or zero AS hops exist between the apexes of the two ramps, i.e., there is no AS between the apexes (see [sriram1] for formal proof). If there are one or more ASes between the apexes of the upstream and downstream ramps, then the UPDATE is a route leak (Invalid) or the presence of a leak cannot be known using available ASPAs (Unknown) [sriram1]. I find 'only if either one or zero AS hops exist ... i.e., there is no AS between the apexes' confusing. If zero AS hops exist then the upstream and downstream ramp touch (both end on the same node). Now they can also overlap but the text totally ignores this here. If there is one AS hop then the two apexes are neighbors (AS(up apex + 1) = AS(down apex). Without context from looking at sriram1 most of this is too hard to understand. Section 5.4 This section is in the wrong spot. It feels more like something that belongs under 7. In general the text in Section 5 is too complex and I fear there will be off by one errors. Without the presentation from [sriram1] I would have a hard time to implement this with confidence of doing it right. There is too much mental gymnastic required to visualize the text correctly to implement this. If one step is missed then the outcome could be wrong. Regards -- :wq Claudio
- [Sidrops] WGLC = draft-ietf-sidrops-aspa-verifica… Christopher Morrow
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Claudio Jeker
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Job Snijders
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Christopher Morrow
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Christopher Morrow
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Christopher Morrow
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Chris Morrow
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Christopher Morrow
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Yangyang Wang
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Yangyang Wang
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… gengnan
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Claudio Jeker
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Amir Herzberg
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Ben Maddison
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Amir Herzberg
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Borchert, Oliver (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Claudio Jeker
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Zhuangshunwan
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Amreesh Phokeer
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Job Snijders
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Claudio Jeker
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Martin Hoffmann
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Claudio Jeker
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Martin Hoffmann
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Randy Bush
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Aftab Siddiqui
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Lubashev, Igor
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Tim Bruijnzeels
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Tim Bruijnzeels
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Di Ma
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… gengnan
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Lubashev, Igor
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Job Snijders
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Yangyang Wang
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Tim Bruijnzeels
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Claudio Jeker
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Claudio Jeker
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Randy Bush
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Claudio Jeker
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Martin Hoffmann
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Ben Maddison
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Ben Maddison
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Claudio Jeker
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Lubashev, Igor
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Lubashev, Igor
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Lubashev, Igor
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Claudio Jeker
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Yangyang Wang
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… 戴志滨
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Russ Housley
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Martin Hoffmann
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Randy Bush
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Job Snijders
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Martin Hoffmann
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Martin Hoffmann
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Job Snijders
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Martin Hoffmann
- [Sidrops] Fw: WGLC = draft-ietf-sidrops-aspa-veri… Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-veri… Christopher Morrow
- [Sidrops] Making ASPA AFI-Agnostic - coordination… Job Snijders
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Martin Hoffmann
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Tim Bruijnzeels
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Di Ma
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Matthias Waehlisch
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Claudio Jeker
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Martin Hoffmann
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Ties de Kock
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Alexander Azimov
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Borchert, Oliver (Fed)
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Russ Housley
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Borchert, Oliver (Fed)
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Job Snijders
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Russ Housley
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Martin Hoffmann
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Job Snijders
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Russ Housley
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Martin Hoffmann
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Job Snijders
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Alexander Azimov
- Re: [Sidrops] Making ASPA AFI-Agnostic - coordina… Alexander Azimov