Skip to main content

Early Review of draft-ietf-idr-bgp-car-05

Request Review of draft-ietf-idr-bgp-car-05
Requested revision 05 (document currently at 10)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2024-01-04
Requested 2023-12-14
Requested by Susan Hares
Authors Dhananjaya Rao , Swadesh Agrawal , Co-authors
I-D last updated 2023-12-19
Completed reviews Secdir Early review of -05 by Yoav Nir (diff)
Tsvart Early review of -05 by Brian Trammell (diff)
Rtgdir Early review of -05 by Mike McBride (diff)
Opsdir Early review of -08 by Yingzhen Qu (diff)
Opsdir Early review of -02 by Yingzhen Qu (diff)
Rtgdir Early review of -02 by Ben Niven-Jenkins (diff)
This document will start a 2nd WG LC during January (after January 4th).   

The draft is experimental, but there are multiple implementations.  See the implementation report at (
Assignment Reviewer Yoav Nir
State Completed
Request Early review on draft-ietf-idr-bgp-car by Security Area Directorate Assigned
Posted at
Reviewed revision 05 (document currently at 10)
Result Has nits
Completed 2023-12-19
Hi.  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.

I have mixed feelings about this document.  The Security Considerations seems
fine. It calls out that new SAFI can provide new avenues for traffic diversion.
It says that BGPsec can be extended to mitigate those risks, but that extension
is not done in this document. That is fine, especially for an experimental

But I can't honestly say that I understand the draft. I thought it could be
just me not having enough routing clue to figure it out, but even the rtgdir
review suggests more explanation of "color" and "color-aware routing" in the

A comment accompanying the requested review suggested the following:

   Security reviews should consider this draft as being deployed in a "walled
   garden" where the walls are created via configuration by providers.  Some
   questions that might be explored are:

     a) Does the security text provide an adequate description of the formation
     of the "walled garden" via BGP TCP security, address considerations,
     preventing DOS service attacks, and strong BGP security (BGP origin and

     b) does the security text provide an adequate description of how to detect
     if traffic goes outside of the "walled garden"?

I'm afraid I don't understand the protocol enough to answer those questions.