[Idr] Re: WG LC for draft-ietf-idr-deprecate-as-set-confed-set-14 (7/8 to 7/ - call continues from 7/8 to 7/26/2024 - 2nd extensions to 8/6
Alvaro Retana <aretana.ietf@gmail.com> Tue, 20 August 2024 12:37 UTC
Return-Path: <aretana.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24484C14F6EA; Tue, 20 Aug 2024 05:37:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 BljlieoXNuxK; Tue, 20 Aug 2024 05:37:50 -0700 (PDT)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFE2FC14F5F8; Tue, 20 Aug 2024 05:37:50 -0700 (PDT)
Received: by mail-pl1-x62e.google.com with SMTP id d9443c01a7336-20208830de8so31386925ad.1; Tue, 20 Aug 2024 05:37:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724157470; x=1724762270; darn=ietf.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=2Kq+ZGQMbjTgRAepu5SKvaRXVjg8qbGSJACW9HmkuXM=; b=SNWKiR4grpOdC/Swuu/xLrTVJvu3rRNll2fcIOoExcOWcyfU3d07ZxE0s82onfrS1X /D5wYhLRKL/X8F8Hc+x9SBjVBR7DgVoLG5IDoqB0LgG8pDga2ANI09ZVMY4q4TekYE+e wTIz7ESe5/HCftKu9YWcAkijh0evNrY2JoNTFW1MKcQDAEtXS+FDR2ecK2xHBxBqUSy/ tgCjHhC5bWIRGyWDD7vtZM0VI3fpNjYWUUtQCmV4MEP092Dw/9G5xgOmk/mHI6zwUyM0 9Inx/u2B+WJpfVZe/wR2hv8T+XQ0K8ijVOtbbOsQWwcuSFj1bSG95p0+yewDXIAZB08h GH2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724157470; x=1724762270; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2Kq+ZGQMbjTgRAepu5SKvaRXVjg8qbGSJACW9HmkuXM=; b=UkA737M7W5oQhtqsTBesOGQnCLtXAvfzkYbdPFX4S5IGUFa3YH5M/bRMaTmmAmBFac 8Wgh8g32UtOc19/8zDbMR+8wvz0heeaWG5WnaLwkRsB7dN8b6D3tDlKUFihedxjuGgKt Ce5V+gGtrXT32zjS3w//mn+KsFKbjisPDSUl8xpgD38JVp+gRGaeR1G+7w8yKs8VlrKj +cvzr5k+s8uM8DixHh008YeeINpBm14nuFNrU4VcfE+UaX6N+l6GWxwHNtJdQC2yuHiQ Rmwfi46JzuGUtPrxnJpBOStj8sGCN4GnOCnf+FhzNjAC6/peC5UK4goxB6XugLWV4BVy l1Nw==
X-Forwarded-Encrypted: i=1; AJvYcCXkK6g9oWnwyp2uITPX3z4yXVUecHZOGFd0+RTqDejfKRbZmzoYq9cDleaQ0aCBKxH+Y41sgbjWfx7uWAg=
X-Gm-Message-State: AOJu0YzA3TyoWrEo5ma9gOqEBvQqi3S2gW4CPEEg2AeMMqaGHs2+23Xl pSqMU7mDzQwzTz7D/LXtmnyzJ9DBEQ/8GFwKTaX9scDGhVjZhvvuvhidhssp96VEagsn66X/wHU qNJwwjgOIBXiBfmH/0ypO16BxvLn+tDAK
X-Google-Smtp-Source: AGHT+IFwpsgvx8TLG/Ns/bjRVCOAYCXS6G3tE4l8li989YuP+N62pI+WcH2Ll/T1d7RiX3YCvHv/qdcXOvcy1dX99WA=
X-Received: by 2002:a17:902:db10:b0:1fb:4a57:7cba with SMTP id d9443c01a7336-2031512dbbbmr19989905ad.34.1724157469994; Tue, 20 Aug 2024 05:37:49 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 20 Aug 2024 05:37:48 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <SA1PR09MB8142A0CA3BD0DAEA418B4CD4848D2@SA1PR09MB8142.namprd09.prod.outlook.com>
References: <SA1PR09MB8142A0CA3BD0DAEA418B4CD4848D2@SA1PR09MB8142.namprd09.prod.outlook.com>
MIME-Version: 1.0
Date: Tue, 20 Aug 2024 05:37:48 -0700
Message-ID: <CAMMESsxn5oW+UEVXJBRZ32Vf_RccxR+LWLr=W=bYwp6vr=pQ-w@mail.gmail.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
Content-Type: multipart/alternative; boundary="00000000000089369b06201cb17b"
Message-ID-Hash: HE2ZKRA4QLA5DWKJ55ZJIC3YIPFIE7Z4
X-Message-ID-Hash: HE2ZKRA4QLA5DWKJ55ZJIC3YIPFIE7Z4
X-MailFrom: aretana.ietf@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Idr] Re: WG LC for draft-ietf-idr-deprecate-as-set-confed-set-14 (7/8 to 7/ - call continues from 7/8 to 7/26/2024 - 2nd extensions to 8/6
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/xu544rkrhK3gttrTemWkh6Zmdpo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>
Thanks Sriram! The changes look good to me. Alvaro. On August 20, 2024 at 12:27:56 AM, Sriram, Kotikalapudi (Fed) ( kotikalapudi.sriram@nist.gov) wrote: Hi Alvaro, Thank you for your review and comments (July 17th). Jeff responded to some of your comments earlier. We waited for other comments from WG members. Now the draft has been updated and version-15 has been published. All your comments have been carefully considered and changes incorporated. New version (v-15): https://datatracker.ietf.org/doc/html/draft-ietf-idr-deprecate-as-set-confed-set-15 Diff: https://author-tools.ietf.org/iddiff?url1=draft-ietf-idr-deprecate-as-set-confed-set-14&url2=draft-ietf-idr-deprecate-as-set-confed-set-15&difftype=--html Looking at the Diff file may readily make it evident for you, but still I share my responses inline below marked with [KS:]. >From Alvaro Retana <aretana.ietf@gmail.com> Wed, 17 July 2024 > I support this document moving forward. It is time to > proscribe/deprecate/prohibit the use of AS_SETs and AS_CONFED_SETs. Their > use is low and the advantage of this action facilitates the deployment of > BGP security mechanisms. > > However, the intent to proscribe/deprecate/prohibit does not match the > text. From §3: > > 153 BGP speakers conforming to this document (i.e., conformant BGP > 154 speakers) SHOULD NOT locally generate BGP UPDATE messages containing > 155 AS_SETs or AS_CONFED_SETs. Conformant BGP speakers SHOULD NOT send > 156 BGP UPDATE messages containing AS_SETs or AS_CONFED_SETs. Upon > 157 receipt of such messages, conformant BGP speakers SHOULD use the > 158 "treat-as-withdraw" error handling behavior as per [RFC7606]. > > 160 The document uses normative language such as "SHOULD NOT send" rather > 161 than "MUST NOT send" with the intention of allowing some transition > 162 time for existing implementations and avoiding abrupt disruptions for > 163 the operators currently using AS_SETs or AS_CONFED_SETs. However, it > 164 is strongly urged that operators stop sending UPDATEs with AS_SETs or > 165 AS_CONFED_SETs as quickly as possible to avoid having UPDATEs dropped > 166 by BGP security mechanisms such as RPKI-ROV and BGPsec. > > Regardless of the text in an RFC, the transition won't be immediate. I > don't agree with the use of "SHOULD NOT" with the explicit intent "of > allowing some transition time". Using this language provides a hole that > allows conformant implementations to continue to use AS_SETs or > AS_CONFED_SET indefinitely. > > Also, the Introduction mentions that "aggregation that involves AS_SETs is > very seldom used", so the impact would be minimum. > > I haven't been following the discussions about this document in detail, so > my point may have already been addressed on the list. If that is the case, > I will stand in the rough. [KS:] I think you will like the updated Section 3. We now say, "MUST NOT advertise" instead of "SHOULD NOT send". Also, we use "MUST" while specifying treat-as-withdraw on receipt of UPDATE with AS_SET or AS_CONFED_SET. [KS:] Also, we have moved the AS4_PATH related section into Sec. 3 as subsection 3.1 to try to keep all related specifications together in one place. This was also based on your suggestion (below). > > I included other comments below. > > Thanks! > > Alvaro. > > > [Line numbers from idnits.] > > ... > 151 3. Recommendations > ... > 168 If a network operator wishes to consider BGP UPDATE messages with > 169 AS_SETs or AS_CONFED_SETs received from an external BGP peers, they > 170 MAY have a feature (knob) in their implementation to do so on a per- > 171 peer basis. The operator should understand the full implications of > 172 choosing this option. > > "network operator...MAY have a feature" > > The action is not for the network operators, but for the implementation. > > Suggestion> > > An implementation MAY include the ability to consider BGP UPDATE > messages with AS_SETs or AS_CONFED_SETs received from external BGP > peers on a per-peer basis. Network operators should understand > the full implications of choosing this option. > [KS:] I think, by looking at the Diff, you will find that this is all worded succinctly and more aptly in the spirit of "deprecate/prohibit" in Section 3 now. > > 174 Network operators SHOULD NOT locally generate any new announcements > 175 containing AS_SETs or AS_CONFED_SETs. > > This text is a duplicate of the text in the first paragraph of this section. [KS:] Yes, agree. We have tried to eliminate all duplications the document (in v-15). > > 177 BGP security technologies (such as those that take advantage of X.509 > 178 extensions for IP addresses and AS identifiers ([RFC3779], [RFC6480], > 179 [RFC6811], [RFC8205]) might not support routes with AS_SETs or > 180 AS_CONFED_SETs in them. Routes with AS_SETs have no possibility of > 181 ever being considered RPKI-ROV valid [RFC6811] [RFC6907]. > > BGPSec also doesn't support the AS_SET (not "might not"). > [KS:] Yes. Now Section 4 (Treatment of Routes with AS_SET in RPKI-based BGP Security) addresses BGPsec and more (ROV, ASPA, etc.) with precise wording. > > 183 4. Updates to Existing RFCs > > Except for these first 3 paragraphs, none of the subsections (4.*) contain > any Updates to Existing RFCs. > > 185 This document deprecates the origination of BGP routes with AS_SET > 186 (type 1) (see [RFC4271], Section 4.3). > > 188 This document also deprecates the origination of BGP routes with > 189 AS_CONFED_SET (type 4) AS_PATH segments (see [RFC5065], Section 3). > > 191 BGP speakers conforming to this document - i.e., conformant BGP > 192 speakers - SHOULD NOT originate BGP UPDATE messages containing > 193 AS_SETs or AS_CONFED_SETs. Upon receipt of BGP routes containing > 194 AS_SETs, conformant BGP speakers SHOULD use the "treat-as-withdraw" > 195 error handling behavior as per [RFC7606]. > > This is the same text that is in §3. Keep the specification in one place: > it is easy for maintenance of the document, it avoids potential conflict, > getting out of sync, etc. > [KS:] What RFCs are updated is concisely stated now in updated Section 3 in one brief paragraph as follows: Per above specifications, this document updates RFC 4271 and RFC 5065 by deprecating AS_SET (see [RFC4271], Section 4.3) and AS_CONFED_SET (see [RFC5065], Section 3), respectively. [KS:] All duplication that existed earlier has been eliminated. The "Brief aggregation" material is now a separate section (Sec. 5) by itself. > ... > 232 4.2. Issues with "Brief" AS_PATH Aggregation and RPKI-ROV > ... > 245 * In the presence of such varying origin ASes, it would be necessary > 246 for the resource holder to register Route Origin Authorizations > 247 (ROAs) [RFC6482] for each potential origin AS that may result from > 248 the expected aggregated AS_PATHs. > > RFC6482 is Obsolete; use RFC9582 instead. [KS:] Yes, replaced. > > 250 4.3. Recommendations to Mitigate Unpredictable AS_PATH Origins for > 251 RPKI-ROV Purposes > > 253 In order to ensure a consistent BGP origin AS is announced for > 254 aggregate BGP routes for implementations of "brief" BGP aggregation, > 255 the implementation should be configured to truncate the AS_PATH after > 256 the right-most instance of the desired origin AS for the aggregate. > 257 The desired origin AS could be the aggregating AS itself. > > Should there be Normative language in this paragraph? > > The obvious place seems to be s/implementation should be configured to > truncate/implementation SHOULD be configured to truncate But, should that > be a "MUST" instead? If the aggregation is to be "consistent", then the > operation should be REQUIRED and not just RECOMMENDED. > [KS:] We use "MUST" now; see Sec. 5.2 in the updated version. > ... > 268 4.4. Interactions with Four-octet AS Numbers > > 270 [RFC4893] created support for four-octet AS numbers in BGP. A BGP > 271 speaker not supporting four-octet AS numbers, termed an "OLD speaker" > 272 in that document, might have routes that carry the AS4_PATH Path > 273 Attribute. This attribute is used to carry four-octet AS paths > 274 across OLD speakers and may contain AS_PATH segments of type AS_SET. > > RFC4893 is Obsolete; use RFC6793 instead. [KS:] Yes, done. > > 276 BGP speakers conforming to this specification MUST NOT use the > 277 information contained in the AS4_PATH for treat-as-withdraw purposes. > 278 Instead, only the AS_PATH should be used. > > I'm assuming that this reference to "treat-as-withdraw purposes" refers to > the specification in §3. > > If so, it might be helpful to add to the specification in §3 the fact that > the receive part only applies to the AS_PATH. Suggestion> s/Upon receipt > of such messages.../Upon receipt of such messages in the AS_PATH... > [KS:] Your suggestion is incorporated in the revised Sec. 3 & Sec. 3.1. Previous Sec. 4.4 is condensed and moved into Sec. 3.1. > ... > 370 9.2. Informative References > ... > 413 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. > 414 Patel, "Revised Error Handling for BGP UPDATE Messages", > 415 RFC 7606, DOI 10.17487/RFC7606, August 2015, > 416 <https://www.rfc-editor.org/info/rfc7606>. > > This reference should be Normative: it is used to specify an action in §3. [KS:] Yes, done. > > 418 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC > 419 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, > 420 May 2017, <https://www.rfc-editor.org/info/rfc8174>. > > This reference should be Normative. [KS:] Yes, done. > > [EoR-14] Thanks! Sriram
- [Idr] Re: AS_SET deprecation draft in WG last cal… Sriram, Kotikalapudi (Fed)
- [Idr] Re: WG LC for draft-ietf-idr-deprecate-as-s… Sriram, Kotikalapudi (Fed)
- [Idr] Re: WG LC for draft-ietf-idr-deprecate-as-s… Susan Hares
- [Idr] Re: WG LC for draft-ietf-idr-deprecate-as-s… Sriram, Kotikalapudi (Fed)
- [Idr] Re: WG LC for draft-ietf-idr-deprecate-as-s… Sriram, Kotikalapudi (Fed)
- [Idr] Re: WG LC for draft-ietf-idr-deprecate-as-s… Alvaro Retana
- [Idr] Re: AS_SET deprecation draft in WG last cal… Jeffrey Haas