Skip to main content

IETF Last Call Review of draft-ietf-idr-link-bandwidth-18
review-ietf-idr-link-bandwidth-18-secdir-lc-petrov-2025-10-07-00

Request Review of draft-ietf-idr-link-bandwidth
Requested revision No specific revision (document currently at 24)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2025-10-07
Requested 2025-09-23
Authors Prodosh Mohapatra , Reshma Das , SATYA R MOHANTY , Serge Krier , Rafal Jan Szarecki , Akshay Gattani
I-D last updated 2026-01-08 (Latest revision 2026-01-07)
Completed reviews Opsdir Early review of -16 by Tim Chown (diff)
Rtgdir Early review of -16 by Russ White (diff)
Tsvart IETF Last Call review of -18 by Brian Trammell (diff)
Secdir IETF Last Call review of -18 by Ivaylo Petrov (diff)
Assignment Reviewer Ivaylo Petrov
State Completed
Request IETF Last Call review on draft-ietf-idr-link-bandwidth by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/wsWpdUzggMsJqysBbJpP2uUf6X4
Reviewed revision 18 (document currently at 24)
Result Has nits
Completed 2025-10-07
review-ietf-idr-link-bandwidth-18-secdir-lc-petrov-2025-10-07-00
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/