Skip to main content

Early Review of draft-ietf-idr-bgp-ct-srv6-06
review-ietf-idr-bgp-ct-srv6-06-secdir-early-nystrom-2024-12-23-00

Request Review of draft-ietf-idr-bgp-ct-srv6
Requested revision No specific revision (document currently at 06)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2024-12-21
Requested 2024-04-26
Requested by Susan Hares
Authors Kaliraj Vairavakkalai , Natrajan Venkataraman
I-D last updated 2024-12-23
Completed reviews Opsdir Early review of -05 by Nagendra Kumar Nainar (diff)
Rtgdir Early review of -05 by Matthew Bocci (diff)
Secdir Early review of -06 by Magnus Nyström
Rtgdir Early review of -03 by Jonathan Hardwick (diff)
Opsdir Early review of -03 by Nagendra Kumar Nainar (diff)
Tsvart Early review of -03 by Dr. Joseph D. Touch (diff)
Comments
We did not get the 3/28/2024 review. 

draft-ietf-idr-bgp-ct-srv6 depends on draft-ietf-idr-bgp-ct.  It may be helpful to look at the draft-ietf-idr-bgp-ct and the security review.
Assignment Reviewer Magnus Nyström
State Completed
Request Early review on draft-ietf-idr-bgp-ct-srv6 by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/j7FV9NVRkVruDAZSlre_sRWfwyM
Reviewed revision 06
Result Not ready
Completed 2024-12-23
review-ietf-idr-bgp-ct-srv6-06-secdir-early-nystrom-2024-12-23-00
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 marked this document as "Not ready" due to, what I perceive as, lack of
clarity related to security properties. For example:

Section 5.1: "Are similar" - are they the same or not? If not, please describe
the differences.

Section 5.2.1: "Repurposing IPv6 Unicast family to carry Transport routes also
may impact the operational complexity and security aspects in the network."
Impact the security aspects how? When or under what circumstances? How to
protect against regressions?

Section 8:

- "This document does not change the underlying security issues inherent in the
existing BGP protocol"
  a) Stating that there are "inherent security issues" in BGP reads strange to
  me. b) A document cannot really change security issues, but the protocol or
  the constructs defined in the document may.

  Therefore, suggest changing to something like: "The constructs defined herein
  do not change the security properties of the BGP protocol."

- "This document follows the security considerations" - not sure what "follow"
security considerations mean. Does it mean that all of the Security
Considerations of BGP - CT apply.? In particular, is the Walled Garden approach
*recommended* to prevent the risk of unintended route escapes, does it have to
be adopted, or what? "Followed" is again unclear.

- "This SAFI routes ..." - I cannot parse this, but suspect it was meant to say
that the SAFI routes described open up a new avenue of attack?

- "In order to mitigate the risk of the diversion of traffic from its intended
destination, BGPsec solutions ([RFC8205] and Origin Validation [RFC8210]) may
be extended in [sic] future" - this text seems to say that there currently is
no mitigation against the aforementioned diversion attacks. Is this correct? If
so, text should state so. If correct, I would also not consider such a gap
acceptable for a standards-track document, but since this is Experimental I
guess it may be acceptable.

- That said, the last paragraph of Section 8 indicates there are mechanisms to
completely mitigate diversion attacks, which leaves me confused. Perhaps the
difference is between SAFIs other than 1 and SAFI 1? If so, I would suggest
switching the order of the last two paragraphs, and change the non-Internet
SAFI to: "For non-Internet SAFIs (SAFIs other than 1), BGPsec solutions
([RFC8205] and Origin Validation [RFC8210]) may be extended to mitigate the
risk of the diversion of traffic from its intended destination" - though the
"may" still feels unsatisfactory.

/M