Re: [Idr] Secdir early review of draft-ietf-idr-bgp-ct

[Kaliraj Vairavakkalai <[e-mail]>]

Copying IDR mailing list too.



Juniper Business Use Only
From: Kaliraj Vairavakkalai <[e-mail]>
Date: Sunday, January 21, 2024 at 10:06 PM
To: Magnus Nyström <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Secdir early review of draft-ietf-idr-bgp-ct
Hi Magnus, please see inline for responses. KV>

I have made some updates accordingly in draft version -20.

https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-20

Thanks
Kaliraj

From: Magnus Nyström <[e-mail]>
Date: Monday, December 18, 2023 at 10:07 PM
To: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Secdir early review of draft-ietf-idr-bgp-ct
[External Email. Be cautious of content]

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:

2.  This document defines a new BGP SAFI for AFIs 1 and 2 and therefore

3.     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.
4.       The Security Considerations section also states:

5.  Mechanisms described in this document follow a "Walled Garden"

   approach
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?
KV> I clarified/reworded tbe text to explain this better: https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-20#section-14
6.       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).
KV> That para about TCP-AO, GTSM, BGP-SEC and Origin-Route-Validation (RV) was added as a general BGP security practice, based on suggestions from the chairs.
KV> RV is used to validate origination of public Internet service prefixes. Though BGP CT families don’t carry service prefixes, RV can be used to detect/validate any origination of internal loopback routes from EBGP Interenet peers. In absence of Origin validation, BGP policy can be used in the network perimeter to reject such routes.
KV> will change the ‘could’ to MAY.
7.       It is stated:

8.  In order to mitigate the risk of the diversion of traffic from its

9.     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.
KV> will change it to MAY.
10.    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?
KV> changed ‘eliminated’ to ‘significantly mitigated’
11.    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?
KV> No.
2.       Do the mechanisms and constructs in this document introduce any new risks related to unintended information disclosure?
KV> No. As the reachability information advertisement has confined scope.
3.       Do the mechanisms and constructs in this document introduce any new risks due to spoofing of endpoint identities etc.?
KV> No.
4.       Do the mechanisms and constructs in this document introduce any new risks due to modification of information exchanged, e.g., between AS endpoints?
KV> No, this document doesn’t introduce new risks. But use of mechanisms like TCP-AO, GTSM, BGPSEC are recommended, as stated in the text.
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 to:

   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 ...



KV> Fixed these. Thanks.


Thanks,
--
-- Magnus