[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