[Idr] draft-ietf-idr-link-bandwidth-18 ietf last call Secdir review

Ivaylo Petrov via Datatracker <noreply@ietf.org> Tue, 07 October 2025 20:09 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@mail2.ietf.org
Received: from [10.244.8.182] (unknown [4.156.85.76]) by mail2.ietf.org (Postfix) with ESMTP id 56CFC6EE4621; Tue, 7 Oct 2025 13:09:29 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ivaylo Petrov via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <175986776923.4101714.6026848623320578815@dt-datatracker-6c6cdf7f94-h6rnn>
Date: Tue, 07 Oct 2025 13:09:29 -0700
Message-ID-Hash: YV65UMXU7REHA2QLXMZ67UX37E5WHRWP
X-Message-ID-Hash: YV65UMXU7REHA2QLXMZ67UX37E5WHRWP
X-MailFrom: noreply@ietf.org
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: draft-ietf-idr-link-bandwidth.all@ietf.org, idr@ietf.org, last-call@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: Ivaylo Petrov <ivaylopetrov@google.com>
Subject: [Idr] draft-ietf-idr-link-bandwidth-18 ietf last call Secdir review
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/LXYyjTsCAQEEjUy1K-fjgiwmymI>
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>

Document: draft-ietf-idr-link-bandwidth
Title: BGP Link Bandwidth Extended Community
Reviewer: Ivaylo Petrov
Review result: Has Nits

Reviewer: Ivaylo Petrov
Review result: has nits

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

Comments:
1. The security considerations section seems generally good to me. The most
important new risk is of leakage of sensitive network topology and capacity
information and that seems important indeed. I could not understand how that
interacts with transitivity. 2. The draft states that a bandwidth value of zero
is valid. While the draft specifies that the behavior in this case is
determined by local policy, this could lead to unexpected forwarding behavior
if not handled consistently across a network. I wonder if this could be a
potential vector for a denial of service attack. 3. Ambiguity in Section 3.3.1:
In the section on re-advertisement with a next-hop change, it says the
implementation "MAY remove the Link Bandwidth Extended Community or MAY
re-advertise it unchanged or regenerate it as its default behavior". This feels
like a lot of options, and it could lead to inconsistent behavior between
implementations. It would be better to recommend a single default behavior and
allow for configuration to override it.

Nits:
1. Authors email addresses are work related, which is not recommended.
2. s/IEEE floating point format/IEEE 754 floating point format/