Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023)
Claudio Jeker <cjeker@diehard.n-r-g.com> Mon, 27 March 2023 13:38 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 CB5C5C151B3E for <sidrops@ietfa.amsl.com>; Mon, 27 Mar 2023 06:38:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level:
X-Spam-Status: No, score=-4.195 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] autolearn=unavailable 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 fQnvndXYkRQq for <sidrops@ietfa.amsl.com>; Mon, 27 Mar 2023 06:38:43 -0700 (PDT)
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 A8A92C151B16 for <sidrops@ietf.org>; Mon, 27 Mar 2023 06:38:42 -0700 (PDT)
Received: (qmail 86578 invoked by uid 1000); 27 Mar 2023 13:38:40 -0000
Date: Mon, 27 Mar 2023 15:38:40 +0200
From: Claudio Jeker <cjeker@diehard.n-r-g.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
Cc: Martin Hoffmann <martin@nlnetlabs.nl>, "sidrops@ietf.org" <sidrops@ietf.org>, "sidrops-chairs@ietf.org" <sidrops-chairs@ietf.org>, "draft-ietf-sidrops-aspa-verification@ietf.org" <draft-ietf-sidrops-aspa-verification@ietf.org>, "draft-ietf-sidrops-aspa-profile@ietf.org" <draft-ietf-sidrops-aspa-profile@ietf.org>
Message-ID: <ZCGcYHJ9PyrjgR+V@diehard.n-r-g.com>
References: <SA1PR09MB814241245D01E81BADE3ED0884CF9@SA1PR09MB8142.namprd09.prod.outlook.com> <31FDE1E9-3E87-4011-B65B-C6B3A264303F@vigilsec.com> <SA1PR09MB81427B4A1B126A5D1C1E289C84CF9@SA1PR09MB8142.namprd09.prod.outlook.com> <SA1PR09MB8142E41F2D6B537BCAA758F384CC9@SA1PR09MB8142.namprd09.prod.outlook.com> <CAL9jLaYz3OhcwBBcVMqnUseBR9J1ZyktcJo5YLeefQHMoYJu+A@mail.gmail.com> <CAL9jLaZ7eDc+zbhapS8dTYQKnTfgLd=MOPYw97-qcJ4eP6S6Mg@mail.gmail.com> <CAL9jLaYJ4ODfumG9Yk3-yv=_TaTSUeD++U4sGy7S-0xWcGBQPw@mail.gmail.com> <ZBGqSVL9sSqnAiJc@diehard.n-r-g.com> <SA1PR09MB8142E9F71F250B83062C724884869@SA1PR09MB8142.namprd09.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <SA1PR09MB8142E9F71F250B83062C724884869@SA1PR09MB8142.namprd09.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/5KUfcLr2QjTMZZV4-RzExk-qleg>
Subject: Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 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: Mon, 27 Mar 2023 13:38:43 -0000
On Wed, Mar 22, 2023 at 10:47:20PM +0000, Sriram, Kotikalapudi (Fed) wrote: > Hi Claudio, > > > > Discussing one your earlier points (March 15) for now as below and this might address Martin's question also: > > > > >Section 5: > > > > > >More AFI nightmares in figure 1: > > > "no Attestation" if AS(i) > > > does not have ASPA (i.e., VAP) > > > for mentioned AFI > > > > >Again there is no conept of an ASPA for mentioned AFI. So what does that mean? I already asked this question and did not get a reponse. So let me ask again: > > > > I think SPAS can distinguished as ASPA-SPAS (before X.509 validation) and VAP-SPAS (after X.509 validation). What we are interested in the above are the VAP-SPAS. The VAP-SPAS can be separated per {CAS, AFI} into: > > > > CAS, VAP-SPAS(AFI=1) > > CAS, VAP-SPAS(AFI=2) > > > > VAP-SPAS(AFI=1) and VAP-SPAS(AFI=2) are two sets created per CAS post X.509 validation of the ASPA(s). > > > > Now we can edit the above (what you quoted from Section 5) to read: > > > > "no Attestation" if AS(i) has an empty VAP-SPAS(AFI) set > > > > >Consider the following ASPA entry: > > > customerASID: 42 > > > ProviderASSet: [ { providerASID: 4242, afiLimit: 0001 } ] an ASPA entry for AS42 with a single provider AS4242 that is limited to IPv4. > > > > > >What is the result of hop(42, 4242, 2) and what about hop(42, 123, 2)? > > > > > >The specification is ambiguous in this case because both "Not Provider" > > >and "no Attestation" could be considered a valid outcome. Now my view is that the result MUST be > > >"Not Provider" since 42 has an ASPA record but this really needs to be clarified before this draft can pass WGLC. > > > > We can eliminate the above problem with this addition in Section 4: > > > > ASPA registration is REQUIRED for a compliant AS. The ASPA-SPAS for a > CAS MUST list at least one providerASID for each allowed value of the > AFI (1 and 2), either implicitly (by not specifying the afiLimit) or > explicitly. This includes the possibility of providerASID = 0 for one or > both AFIs. For example, if a CAS X registers only the ASPA: > [customerASID = X, {providerASID = Y, afiLimit = 1}], that is not > permitted because it leaves out AFI =2. Instead, if the CAS X registers > ASPA: [customerASID = X, {providerASID = Y}], or ASPA: [customerASID = > X, {providerASID = Y, afiLimit = 1}, {providerASID = 0, afiLimit = > 2}], or ASPA: [customerASID = X, {providerASID = Y, afiLimit = 1}, > {providerASID = Z, afiLimit = 2}], any of those is permitted. > > > > With the above updated recommendation, maybe the objection about the > ASPA RTR PDU per draft-ietf-sidrops-8210bis (Martin's question) also > goes away... since if the separation of VAP-SPAS per {CAS, AFI} is > performed at the RPKI cache, the router can benefit (avoid having to do > the processing on the router). > > > > Your thoughts? > Right now both BGP-SRx nor OpenBGPD implement a single aspa table. At least for OpenBGPD this was done to have a single, cache efficent and extremly fast lookup function. Performance of ASPA is a big concern since it must be applied to every path received. The lookup table consists of many sources (static config and each RTR session) data is merged and compiled into one lookup table. Adding more work in that compile step has little impact on BGP performance which is fine as long as the basic lookup still works. The operational impact of AFI dependent ASPA objects was little discussed. ASPA is already complex enough and unlike ROA validation the outcome depends not only on a single resource. Also every AS may get different outcomes because the view is different (downstream path). So having to figure out why one path is accepted and another fails is already complicated without doubling the pain with AFI=1 and AFI=2. Having a disconnect between an ASPA object in RPKI and the resulting lookup object in BGP makes this not easier. Now your requirement that ASPA objects MUST cover both supported AFI is an option but all RP software MUST follow that rule and discard badly encoded ASPA objects (which they should anyway but people still like to argue about this a lot). Also BGP router need to follow that rule and make sure that RTR ASPA PDUs always come in couples. So this needs to be explicitly mentioned in all three specifications. Not sure in which document you want to alter Section 4. Right now I think that in draft-ietf-sidrops-aspa-profile-12 section 4 needs to be extended, in draft-ietf-sidrops-aspa-verification-12 section 3, 4 and 5 need some adjustements and in draft-ietf-sidrops-8210bis-10 it would be good to extend 5.12 a little bit. Now if I understand you correctly a Valid ASPA Payload would always cover both AFIs (since an object MUST list some value for both AFI). So your suggestion above: > "no Attestation" if AS(i) has an empty VAP-SPAS(AFI) set can be replaced with > "no Attestation" only if AS(i) has no CAS entry since if one VAP-SPAS(AFI) set exists the other set MUST exist as well. -- :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