From nobody Thu Dec 22 05:41:52 2022 Return-Path: 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 2744FC151708 for ; Thu, 22 Dec 2022 05:41:52 -0800 (PST) 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 UllmZT4ShjSd for ; Thu, 22 Dec 2022 05:41:47 -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 11E11C1516FC for ; Thu, 22 Dec 2022 05:41:45 -0800 (PST) Received: (qmail 79391 invoked by uid 1000); 22 Dec 2022 13:41:43 -0000 Date: Thu, 22 Dec 2022 14:41:42 +0100 From: Claudio Jeker To: "Sriram, Kotikalapudi \(Fed\)" Cc: "sidrops@ietf.org" , "draft-ietf-sidrops-aspa-verification@ietf.org" , "draft-ietf-sidrops-aspa-profile@ietf.org" , Job Snijders Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Sidrops] Transparent & Non-transparent IX Route Server ASes (Was: ASPA objects in the public RPKI) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2022 13:41:52 -0000 On Thu, Dec 22, 2022 at 05:05:07AM +0000, Sriram, Kotikalapudi (Fed) wrote: > Hi Claudio, > > You raise some good points. I have prepared a set of slides that should > be useful to discuss various points related to IXP RS and ASPA > verification. A pdf of the slides is attached here and can be also > viewed at: > https://github.com/ksriram25/IETF/blob/main/ASPA-RS-AS-discussion.pdf > > Perhaps it would be best if the two of us have a sidebar discussion > using the slides and bring our combined understanding back to this list. > We can email or do a video call at your convenience. Thanks. Sure. Happy to have a discussion about this. Best time for me would be after the Holiday season is over (start of 2023). I noticed there are other inconsistencies with the drafts and e.g. the special handling of non-transparent IXP RS. I came to the conclusion that Section 5.1.1 of draft-ietf-sidrops-aspa-verification-11 can be removed iff the requirement to include non-transparent RS in the SPAS of its customers remains. I will remove all this extra compexity introduced by Section 5.1.1. from my code base. I really prefer the requirement in Section 3. of draft-ietf-sidrops-aspa-profile-11. In the end simpler code is better. -- :wq Claudio > -----Original Message----- > From: Claudio Jeker > Sent: Monday, December 19, 2022 5:18 AM > To: Sriram, Kotikalapudi (Fed) > Cc: sidrops@ietf.org; Job Snijders ; draft-ietf-sidrops-aspa-verification@ietf.org; draft-ietf-sidrops-aspa-profile@ietf.org > Subject: Re: [Sidrops] Transparent & Non-transparent IX Route Server ASes (Was: ASPA objects in the public RPKI) > > On Sat, Dec 17, 2022 at 10:02:04PM +0000, Sriram, Kotikalapudi (Fed) wrote: > > Hi Claudio, Job: > > > > >From: Claudio Jeker Thu, 15 December 2022 > > >14:48 UTC > > > > > >As mentioned in another mail. The ASPA validation happens only the > > >AS_PATH attribute. So a transparent IXP RS will not show up in there > > >and therefor it does not influence the result. Because of this there > > >is no need to add it to the ASPA object. > > > > That is not quite accurate. The ASPA verification draft algorithm > > requires an RS-client AS to have an ASPA even in the transparent RS > > case. Otherwise, route leak detection will not work correctly. Example: > > > > AS1 (RS-client) ---C2P---> AS2 (transp. RS) ---P2C---> AS3 (RS-client) > > ---p2p---> AS4 > > > > (p2p = lateral peers) > > > > AS4 receives an update with AS_PATH {AS3 AS1} and it can correctly > > detect it as a route leak only if AS1 (RS-client) has an ASPA. > > AS4 detects the route leak because AS3 does not include AS1 as provider in its SPAS. The transp. RS (AS2) does not matter at all here. > There is no need to put AS2 into the SPAS it just increases the SPAS for no reason. The AS_PATH will never include AS2 and therefor only the AS1 - AS3 relation matters. > > > The verification draft says, "An AS number resource holder in its role > > as Customer, MUST register each of its transit provider ASes in its > > ASPA record." There is an implicit assumption that RS-client is > > basically a customer, and the RS is a provider. The draft should make > > this explicit and clear. > > I argue that your interpretation of RS-client = customer and RS = provider is wrong. RS-client with transparent RS relations ships are lateral peer relation ships. There is no need to make this a customer - provider relation ship. The RS does not provide transit for any RS-client. > > I think adding AS2 as SPAS in AS1 will result in a route leak with the AS_PATH { AS3 AS4 } in the above example. > > AS1 receives { AS3 AS4 } from AS2. Since AS2 is a provider the system will use 5.3 Algorithm for Downstream Paths and since there are just 2 hops the path will be valid (any path with less than 3 hops is valid). > > If AS2 is a RS (not a provider) then 5.2 Algorithm for Upstream Paths is used and the path will be unknown (if AS4 has no ASPA record) or invalid if AS4 has an ASPA record (without AS3 in SPAS since it is a lateral peer). > > > The profile draft says: "Thus, a CAS MUST add both upstream providers > > and any connected non-transparent RS AS to its SPAS." > > This is correct. Non-transparent RS MUST show up in the SPAS of RS-clients and the non-transparent RS MUST use [ 0 ] as SPAS. Transparent RS are not covered by this. > > > But that is not adequate. A statement about the ASPA object > > requirement for transparent RS is also called for. As seen in the > > example above, even a transparent RS must have an ASPA. > > All RS should use a [ 0 ] ASPA SPAS record. They are transit free (if they announce their services lan via the RS ASnum then those transits should be in the SPAS). > > > One question is... does the transparent IXP RS AS have a need to > > announce some prefixes of its own in eBGP? RFC 7454 says that is so > > (see Section 6.1.5). Also, the IXP may have servers using some of its > > own prefixes for customer account services, etc. and may announce > > those prefixes in eBGP. Then certainly, the RS-clients of the > > transparent RS will be required to register ASPAs including the > > transparent RS AS as a provider. Otherwise, the ASPA-based route leak > > detection will not work for any routes that the transparent RS AS originates. > > >From my understanding current BCP is to not announce the IXP LAN and > >that > services offered to the public by the IXP are announced using an extra prefix often using a 2nd ASnumber. For this prefix the IXP acts like any other ISP and receives transit from some providers. These providers need to be added as SPAS. Again I think your suggestion would result in possible route leaks of the transparent RS AS since RS-clients would put them into a provider state which is incorrect. This may result in route leaks to pass through via the RS AS. > > Last but not least it is very unfortunate that ASPA registration recommendations (or requirements) are split over the two drafts. I think this should be fixed and all bits about ASPA registration moved to one place. At least then the two drafts will not conflict like they kind of do now. > > -- > :wq Claudio