Adding Sec-DIR issues (-18 and -19) - For check in -27

[suehares]

SEC-DIR Early Review: (on -18)
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-18-secdir-early-nystrom-2023-12-23/
SEC-DIR Early Review: (on -19)
https://mailarchive.ietf.org/arch/msg/secdir/kFzE5B7LSCmtHH1kyoxuC8dF178/

Points recorded in Shepherd's report
1) Why does the definition of "new AFI/SAFI to pass routes" not change any underlying security characteristics?
This should be explained better.

2) Where is it stated in the document - "Mechanisms described in this document follow a "Walled Garden" approach?
This should be explained better.

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 that:
"In order to mitigate the risk of the diversion of traffic from its
intended destination, [the] existing BGPsec solution could be extended, and
supported for this SAFI."
What does "could" mean 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
endpoints?

[suehares]

Link to -30 review
https://mailarchive.ietf.org/arch/msg/idr/fYulGchhf6oWPWhVWHxqx6WNupI/

Comment from Magnus:
Comparing with my original review (-18) the authors have addressed my concerns.

There is one remaining, probably smaller, issue: The Security Considerations
section states:

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.

• was this meant to say "existing BGPsec solutions"
  or "the existing BGP solution"?

Also, it isn't clear how BGPsec should be extended - and if it would provide any substantial benefit over the mechanisms described herein
(the remainder of this paragraph states:

"The restriction of the aplicability of this SAFI to its intended well-defined >scope limits the likelihood of traffic diversions. Furthermore, as long as the >filtering and appropriate configuration mechanisms discussed previously are >applied diligently, risk of the diversion of the traffic is significantly mitigated.".

response from Kaliraj:
https://mailarchive.ietf.org/arch/msg/idr/JLJ7jywuP-ROlyk6kwt8M52I6Mg/

was this meant to say "existing BGPsec solutions" or "the existing BGP solution"?

I think we should change it to ‘existing BGP solutions’. Agree.

Response to Magnus from Shepherd (Susan Hares)
https://mailarchive.ietf.org/arch/msg/idr/ngF3LVLGaMLsBaO2RTTJyeTStfY/

[suehares]

Kaliraj investigation

Hi Sue, Magnus,

It seems there is more to it.

Reading the text in sec 6.2.1 of rfc8374, it actually doesn’t answer why
SAFI was not included in Capability.

It seems to assume that current support is only for SAFI 1:

“It was decided that during capability negotiation, the address family
for which the BGPsec speaker is advertising support for BGPsec will
be shared using the Address Family Identifier (AFI). Initially, two
address families would be included, namely, IPv4 and IPv6. BGPsec
for use with other address families may be specified in the future.”

The text in 2.2.1 rfc8374 (which discusses Figure 8 in rfc8205), explains why address-family
information (this text uses only AFI to indicate an address-family) was included in the
“things to be hashed”. rfc8205 Figure 8 actually included both AFI and SAFI. Which is good.

It is possible that when AFI,SAFI were added to the “things to be hashed” in Sec 4.2 Figure 8,
in draft-ietf-sidr-bgpsec-protocol-13.txt they missed adding SAFI to the Capability.

Looking at the meta comment in 6.2.1 about non-Internet SAFIs, and my limited understanding, I feel more careful considerations [are] required to extend BGPsec for other SAFIs. We cannot assume that today, it supports all SAFIs for AFI-1 and 2. Stating so in the CT draft would contradict the above rfc8374 text.
It may mislead readers to think that the support is complete.

Same with RPKI-RTR spec. It seems to assume Internet families only today. There is no AFI/SAFI information carried in the PDUs (rfc8210, rfc6810).

I also consulted internally with Santosh (copied) who works on RPKI/ROV, and is familiar with BGPsec. Our general feeling is that the BGPsec and ROV protocol mechanisms may need more thought and work if/when applying to non-Internet SAFIs. So we are not very comfortable with specifying it as a “should”.

Given the above reasons, I am inclined to put the following text wrt BGPsec in the CT drafts:

“In order to mitigate the risk of the diversion of traffic from its
intended destination, BGPsec solutions (RFC8505 and Origin Validation RFC8210) may be extended in future to work for non-Internet SAFIs (SAFIs other than 1).

The restriction of the applicability of this SAFI to its intended
well-defined scope limits the likelihood of traffic diversions.
Furthermore, as long as the filtering and appropriate configuration
mechanisms discussed previously are applied diligently, risk of the
diversion of the traffic is eliminated.”

Please let me know if I am missing anythihg. And if we should sync up on a zoom call to discuss this.

Thanks
Kaliraj

[suehares]

Magnus response to Kaliraj information on BGPsec

Hi Kaliraj,
It seems like it is currently not determined if BGPSec as it is would suffice or if enhancements are needed (I can't tell). Perhaps in that situation, it is better to just remove the sentence " In order to mitigate the risk of the diversion of traffic from its intended destination, existing BGPsec solution could/may be extended and supported for this SAFI." ?

[suehares]

Sue's comment in response to Magnus

Sue (on 4/25/2024)
Magnus:

I am uncomfortable changing the text in draft-ietf-idr-bgp-ct-32. I hope you are OK with this resolution.

Based on the research from Kaliraj, I think BGPsec could be extended to include AFI and SAFI in the hash. This change would require new BGPsec code, a revision to BGPsec specification, and a new BGPsec capability. Existing implementations would need a knob to specify the new revision for BGPsec.

[suehares]

Magnus's response to my Shepherd's statement

Sue, my comments are just that, suggestions. Personally I feel that for new functionality, it should be made clear to implementers if existing (and possibly simultaneously introduced) security measures are sufficient to accomplish a secure implementation of the new functionality. A "could" does not, to me, provide that guidance and that's why I, again, personally don't findl the current writing satisfactory, but ultimately Iit is your call.

[suehares]

Shepherd's note: I've asked the ADs to look at security issues first.