Re: [secdir] [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
>    2.  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.

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

>
>
> *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"?

Thanks

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