Subject: [Idr] Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-prefix-sid-25: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 19 Jun 2018 17:15:42 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-idr-bgp-prefix-sid-25: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please expand NLRI on first use.

The "MUST be present" (in BGP Prefix-SID) in Section 3.1 seems to
potentially be in conflict with the "are only used when SR is
applied to the MPLS dataplane" in Section 3, but it's quite possible
that I'm just missing the piece that ties things together.

Section 7

It's a little weird to mark the value 2 as "deprecated" with
reference "this document" but not have the previous usage described at
all in the final version.

Section 9

It might be nice to note the consequences of the BGP Prefix-SID
attribute's non-protection by BGPsec signatures, though thank you
for calling out the lack of coverage.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 20 Jun 2018 01:27:31 +0000

Hi Ben, 

> On Jun 19, 2018, at 8:15 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

Sure 

> that I'm just missing the piece that ties things together.

This is with respect to the a TLV in the BGP Prefix-SID attribute. If you are using that attribute with IPv4/IPv6 Unicast Labeled prefixes you are applying SR to the MPLS data plane. 

> all in the final version.

I think this is better than the alternative of describing a TLV that is deprecated. 

What is the technical value of adding?

     “The value 2 previously corresponded to the IPv6 SID TLV. It was included in previous versions of this document but has been removed.” 

This begs the question of explaining why it was removed and adding more information that is ancillary to the IANA considerations. 

> for calling out the lack of coverage.

To be honest, I added this at someone’s request. Possibly yours? I don’t really expect BGPSec to be deployed within an SR domain since this implies global administration of the SRGB space. 

Thanks,
Acee

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 21 Jun 2018 13:49:39 -0500

Hi Acee,

> This is with respect to the a TLV in the BGP Prefix-SID attribute. If you are using that attribute with IPv4/IPv6 Unicast Labeled prefixes you are applying SR to the MPLS data plane. 

Okay, thanks for the cluebat.

> What is the technical value of adding?

Not much.  Which is why it's just "a little weird" -- it may well still be
the right thing to do.

> To be honest, I added this at someone’s request. Possibly yours? I don’t really expect BGPSec to be deployed within an SR domain since this implies global administration of the SRGB space. 

(Probably not mine; I don't think I reviewed a previous version of this
draft.)

I'm not trying to press for any change to this text, but I do want to make
sure I understand your comment -- are you saying that BGPsec would only be
deployable within an SR domain if the corresponding SRGB space is globally
administered and the global administration is unlikely to happen, or that
there is no value in adding BGPsec to a globally administered SRGB space
since the global administration would just distribute the SRGB information
along with the rest of the configuration?

Thanks,

Benjamin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 21 Jun 2018 19:10:09 +0000

Hi Benjamin, 

See inline. 

> On Jun 21, 2018, at 2:49 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi Acee,
> 

Actually I got a second request to add an explanation from Martin and it is in the -26 version that I published earlier today. 

> along with the rest of the configuration?

I realize this is a bit subjective. My thinking is that an SR domain implies a single administrative domain. Within a single administrative domain, I think it is unlikely that BGPsec would be deployed. Rather, the focus would be on securing the network and the transport. I’m sure there would be those that disagree. 

I guess the consequence of the BGP Prefix-SID attribute not being protected is that it could be modified without detection by a man-in-the-middle attack??? 

Note that this is much less dire than some other BGP attributes since the RFC 8277 labeled path is used for routing. 

Thanks,
Acee  

Thanks,
Acee

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 21 Jun 2018 15:57:57 -0500

> Actually I got a second request to add an explanation from Martin and it is in the -26 version that I published earlier today. 

Ah, I see it now; thanks.

> I realize this is a bit subjective. My thinking is that an SR domain implies a single administrative domain. Within a single administrative domain, I think it is unlikely that BGPsec would be deplo…

I am also sure there would be those that disagree :)

> I guess the consequence of the BGP Prefix-SID attribute not being protected is that it could be modified without detection by a man-in-the-middle attack??? 

That seems likely; what's less clear to me is what the consequences would
be if such an attacker supplied "bad data" ... but maybe there is not
anything more interesting to say than "some traffic would go to an
unintended destination, which both increases load on the new recipient and
is a denial of service", which is in some sense uninteresting in the scope
of BGP security considerations.

-Benjamin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 21 Jun 2018 21:30:50 +0000

Hi Ben, 

On 6/21/18, 4:58 PM, "Benjamin Kaduk" <[email-masked]> wrote:

    

    

With bad data, the worse that could happen is that the SR path isn't established and the wrong labels are used from point of attack downstream. This due to this fact from section 2:

      The outgoing label for the prefix is found in the Network Layer
      Reachability Information (NLRI) of the Multiprotocol BGP IPv4/IPv6
      Labeled Unicast prefix advertisement as defined in [RFC8277].  The
      label index L_I is only used as a hint to derive the local/
      incoming label.

There are second level implications of the SR path being disrupted in controller deployments but I really don't want to try and get into those. 

Thanks,
Acee 

    -Benjamin