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

Aligned, thanks!

On Tue, Apr 23, 2024 at 4:18 PM Susan Hares <shares@ndzh.com> wrote:

> Magnus:
>
>
>
> Thank you for your feedback.  See my comments below.
>
>
>
> I will request that the authors change the “*could*” to a “*should*”
> before submitting to the draft-ietf-idr-bgp-ct in the following sentence:
>
> Old text: /  “In order to mitigate the risk of the diversion of traffic
> from its intended destination,  existing BGPsec solutions *could* be
> extended and supported for this SAFI.”/
>
> New text:/ “In order to mitigate the risk of the diversion of traffic from
> its intended destination,  existing BGPsec solutions *should* be extended
> and supported for this SAFI.”/
>
> Cheerily, Sue Hares
>
>
>
> *From:* Magnus Nyström <magnusn@gmail.com>
> *Sent:* Tuesday, April 23, 2024 4:20 PM
> *To:* Susan Hares <shares@ndzh.com>
> *Cc:* Kaliraj Vairavakkalai <kaliraj@juniper.net>; secdir@ietf.org;
> draft-ietf-idr-bgp-ct.all@ietf.org; idr@ietf.org
> *Subject:* Re: [Idr] Secdir early review of draft-ietf-idr-bgp-ct-30
>
>
>
>
>
> Hi Sue and apologies for my tardiness. See below.
>
>
>
> On Tue, Apr 9, 2024 at 4:30 PM Susan Hares <shares@ndzh.com> wrote:
>
> Magnus:
>
>
>
> As shepherd of the draft-ietf-idr-bgp-ct draft,  I need additional
> information about your review.   Would you help me by answering three
> questions?
>
> For these questions, imagine a series of networks cooperating to get
> traffic between either: a) two data centers or b) between data centers and
> user phones.
>
> Thank you, Sue Hares
>
> *Question 1:  What are you assuming is involved in BGPsec solutions? *
>
> The text in draft-ietf-idr-bgp-ct-30 states in the security section:
>
> “To mitigate any risk of manipulating the routing information carried
> within a new SAFI, BGP origin validation [RFC6811] and BGPsec [RFC8205]  MAY
> be used as means to increase assurance that the information  has not been
> falsified.”
>
>  AND
>
>  “In order to mitigate the risk of the diversion of traffic from its
> intended destination,  existing BGPsec solutions could be extended and
> supported for this SAFI.”
>
>  This points to basic protocols plus solutions augmented to support this
> for the BGP Updates with the AFI/SAFIs that include the CT SAFI.
>
> Are you taking “BGPSec solutions” to mean:
>
>    1. implementations are being extended to work with CT AFI/SAFI or
>
> b.      additions IETF protocols for BGPsec that include additional
> features?
>
> My understanding is that “BGPsec solutions” in the CT document is adding
> BGPsec protocol + Origin validation to implementations supporting CT.
>
>
>
> *MN: *Right, I did not expect additions to IETF protocols for BGPsec
> would be required (beyond what possibly is in this memo already), but I was
> wondering if that "could" was intended to be a "should" (or should be a
> "should). I mean, pretty much everything "could" always be enhanced.
>
>
>
> *Sue2: *Many operators utilize the Origin validation along with
> private-links to provide scalable security. Since CT is target at the
> providers space with private-links, this may be the most deployed
> solution.  BGPsec could be extended to support this SAFI.
>
> *Sue2:* I’ll suggest the authors change the following sentence to:
>
>
>
> Old text:/  “In order to mitigate the risk of the diversion of traffic
> from its intended destination,  existing BGPsec solutions could be
> extended and supported for this SAFI.”/
>
> New text:/  “In order to mitigate the risk of the diversion of traffic
> from its intended destination,
>
>        existing BGPsec solutions (e.g. BGPsec or Route Origin Validation)
> should be extended and supported for this SAFI.”/
>
>
>
> *2) Are you familiar with the potential additions to BGPsec and Origin
> Validation? *
>
>
>
> One could secure other attributes that do not change between routers
> within the BGP Update packet.  These attributes could be secured separately
> from the BGP Path attribute.   The benefit of securing such things as the
> “BGP Tunnel Encapsulation Attribute” may aid in securing the distribution
> of tunnel endpoints within a domain containing multiple AS within a
> network.
>
>
>
> One could register locally Origin validation specific to the transport
> addresses used by CAR and CT.
>
>
>
> *MN: *I am not familiar with those additions and not sure how they would
> read on this CT work, I will have to defer to others on this.
>
> *Sue-2: *Thank you for letting me know.
>
>
>
> *3) Are you familiar with the amount of Configuration involved in these
> features?  *
>
> You mention this text in your review:
>
> "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 significantly
> mitigated."
>
> This text was written to indicate (as described in the CT document)
>
>    1. Networks are filtering offered data traffic into different service
>    levels (e.g. gold, silver, bronze service levels),
>
> This filtering includes normal filtering of traffic against DDOS and other
> attack traffic.
>
>    2. Data Traffic is placed on set-up transport pathways created by the
>    BGP protocols.
>
> 3.      Back-up pathways are also set-up by the BGP protocol with input
> from IGP protocols.
>
> All of this setup requires a great deal of configuration on the nodes.
>
>
>
> *MN: *I agree, and this goes back to my question there - are the
> extensions a "could" or a "should". For example, if the configuration will
> be so involved as to be likely to cause incidents because of incorrectness
> from a security perspective, maybe that "could" is a "should"?
>
>
>
> *Sue-2:  *Thank you for your response. Most operators run the
> configuration from automated system where double checks are made before
> deploy.  Origin Validation catches a many of the current set of issues, but
> BGP should continually work toward improving security levels.
>
>
>
> Sue-2: (resolution):  I agree with adding should the previous sentence.
>
>
>
>
>
>
>
>
>
>
>
> *From:* Kaliraj Vairavakkalai <kaliraj@juniper.net>
> *Sent:* Monday, April 8, 2024 10:38 PM
> *To:* Magnus Nyström <magnusn@gmail.com>; secdir@ietf.org
> *Cc:* draft-ietf-idr-bgp-ct.all@ietf.org; idr@ietf.org
> *Subject:* Re: [Idr] Secdir early review of draft-ietf-idr-bgp-ct-30
>
>
>
>
>
> Hi Magnus,
>
>
>
> > was this meant to say "existing BGPsec solutions" or "the existing BGP
> solution"?
>
>
>
> I think we should change it to ‘existing BGP solutions’. Agree.
>
>
>
> Thanks,
>
> Kaliraj
>
>
>
>
>
> Juniper Business Use Only
>
> *From: *Idr <idr-bounces@ietf.org> on behalf of Magnus Nyström via
> Datatracker <noreply@ietf.org>
> *Date: *Sunday, April 7, 2024 at 10:17 PM
> *To: *secdir@ietf.org <secdir@ietf.org>
> *Cc: *draft-ietf-idr-bgp-ct.all@ietf.org <
> draft-ietf-idr-bgp-ct.all@ietf.org>, idr@ietf.org <idr@ietf.org>
> *Subject: *[Idr] Secdir early review of draft-ietf-idr-bgp-ct-30
>
> [External Email. Be cautious of content]
>
>
> Reviewer: Magnus Nyström
> Review result: Has Nits
>
> 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.").
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!B2BvMqPMR2r1KICWj3Vip_HLeDU5abmgtAXxyMwbmZhtzxUlyiprfSYhkYvbMBSGgTiBOIH3LSaGNns$
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!B2BvMqPMR2r1KICWj3Vip_HLeDU5abmgtAXxyMwbmZhtzxUlyiprfSYhkYvbMBSGgTiBOIH3LSaGNns$>
>
>
>
> --
>
> -- Magnus
>

-- 
-- Magnus