Skip to main content

Early Review of draft-ietf-idr-bgp-ct-18

Request Review of draft-ietf-idr-bgp-ct-18
Requested revision 18 (document currently at 33)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2023-12-18
Requested 2023-12-04
Requested by Susan Hares
Authors Kaliraj Vairavakkalai , Natrajan Venkataraman
I-D last updated 2023-12-23
Completed reviews Rtgdir Early review of -18 by Jonathan Hardwick (diff)
Secdir Early review of -18 by Magnus Nyström (diff)
Opsdir Early review of -19 by Bo Wu (diff)
Secdir Early review of -19 by Magnus Nyström (diff)
Tsvart Early review of -27 by Olivier Bonaventure (diff)
Secdir Early review of -30 by Magnus Nyström (diff)
Rtgdir Early review of -09 by Mohamed Boucadair (diff)
Opsdir Early review of -12 by Bo Wu (diff)
please review the latest version before the End of WG LC (12/19/2023)
Assignment Reviewer Magnus Nyström
State Completed
Request Early review on draft-ietf-idr-bgp-ct by Security Area Directorate Assigned
Posted at
Reviewed revision 18 (document currently at 33)
Result Has issues
Completed 2023-12-19
 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 comments.

This document presents BGP constructs that may be used to implement certain
types of network segmentation.

   1. The Security Considerations section start off by stating:

   This document defines a new BGP SAFI for AFIs 1 and 2 and therefore
      does not change the underlying security issues inherent in the
      existing BGP protocol

   It isn't clear to this reader why the definition and introduction of a
   new element "therefore" doesn't change any underlying security
   characteristics. This should be explained better.
   2. The Security Considerations section also states:

   Mechanisms described in this document follow a "Walled Garden"

   Perhaps this is due to me not being an expert in this area and therefore
   missing it, but where in the document is it expressed that these mechanisms
   only apply to Walled Garden situations?
   3. It is stated that BGP origin validation "could" be used to "increase
   assurance" that information has not been falsified. Firstly, "could" does
   not say much to an implementer. Is this intended to be "SHOULD"? What's the
   risk of not using origin validation? And conversely, what assurance is
   given if BGP origin validation is not used (the "increased assurance" part).
   4. It is stated:

   In order to mitigate the risk of the diversion of traffic from its
      intended destination, existing BGPsec solution could be extended and
      supported for this SAFI

   Again,"could" is not part of RFC 2119, so not sure what is intended here.
   5. It is also stated that "as long as filtering [and other measures] are
   applied diligently, "risk of [traffic diversion] is eliminated" - is this
   really the case? That it is entirely eliminated?
   6. Not being an expert in this area, I just want to call out the
   following items that I ask the authors to ensure that they are covered:
      1. Is there anything in here which increases the risk of dDoS attacks?
      2. Do the mechanisms and constructs in this document introduce any
      new risks related to unintended information disclosure?
      3. Do the mechanisms and constructs in this document introduce any
      new risks due to spoofing of endpoint identities etc.?
      4. Do the mechanisms and constructs in this document introduce any
      new risks due to modification of information exchanged, e.g., between AS

Editorial: Generally the document is in need of language clean-up, it uses
needless commas, etc. Three examples below just from the abstract:

   - The first sentence is very long and hard to follow. I suggest changing

   This document specifies a mechanism referred to as "Intent Driven
   Service Mapping." The mechanism uses BGP to express intent-based association
   of overlay routes with underlay routes that have specific Traffic
   Engineering (TE) characteristics satisfying a certain Service
   Level Agreement (SLA)."

   - .Likewise, I suggest changing the next sentence to (since a document
   in itself doesn't achieve anything):

   This is achieved by ...

   - I also suggest starting the second paragraph

   Additionally, this document specifies ...

-- Magnus