Skip to main content

Early Review of draft-ietf-grow-bgpopsecupd-08
review-ietf-grow-bgpopsecupd-08-rtgdir-early-dunbar-2025-09-30-00

Request Review of draft-ietf-grow-bgpopsecupd
Requested revision No specific revision (document currently at 12)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2025-09-30
Requested 2025-08-18
Requested by Job Snijders
Authors Tobias Fiebig , Nick Hilliard
I-D last updated 2025-11-12 (Latest revision 2025-11-12)
Completed reviews Intdir Early review of -09 by Florian Obser (diff)
Intdir Early review of -11 by Daniel Migault (diff)
Rtgdir Early review of -08 by Linda Dunbar (diff)
Comments
It has proven difficult so far to get substantive feedback on this document. At IETF123 (in the GROW session) it was suggested to solicit additional review via the directorates on the document in order to ascertain quality and readiness.
Assignment Reviewer Linda Dunbar
State Completed
Request Early review on draft-ietf-grow-bgpopsecupd by Routing Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/dvz32WzX8yVogktDYv8d8J2Mfjo
Reviewed revision 08 (document currently at 12)
Result Not ready
Completed 2025-09-30
review-ietf-grow-bgpopsecupd-08-rtgdir-early-dunbar-2025-09-30-00
I have been selected as the Routing Directorate reviewer for this draft. For
background, see the RtgDir wiki.

Summary: This draft updates BCP guidance for secure, reliable BGP
operations—replacing RFC 7454—by outlining goals and practices for session
protection, route filtering, and attribute handling in the Internet’s
Default-Free Zone.

Major:
- Section 4.1: the second bullet is not great for a standards doc:
      "All ASes left of the originating AS in the AS_PATH MUST be authorized to
      advertise the NLRI to the AS directly to their left,.."

Suggest the following:
 "Let AS_PATH = {AS1, AS2, …, ASn}, where AS1 is the neighbor that sent the
 UPDATE and ASn is the origin. For each k in 1..n−1, AS(k+1) MUST/SHOULD be
 authorized to export the NLRI to ASk according to their bilateral routing
 policy (e.g., provider–customer, peer, or lateral-peer)."

Minor:
- Section 3.1 lists desired properties (prevent off-path injection,
interruption, etc.) but gives no references (e.g., GTSM/TTL-security, TCP-AO,
BGP-MD5, CoPP/CP-policing, max-prefix). It would be helpful to readers to have
the informative references or a short “Examples include …”

NITS:
Section 2 Scope:
- suggest expand DFZ: “...routers in the Default-Free Zone (DFZ)"

Section 3.2:
- “External activity towards the management interface do not interfere …” ->
“does not interfere …”.

Ack: Acknowledgements list has Martin Pels twice;

Warm Regards,
Linda Dunbar