Subject: [Idr] Eric Rescorla's No Objection on draft-ietf-idr-bgp-prefix-sid-13: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Tue, 06 Feb 2018 18:05:27 -0800

Eric Rescorla has entered the following ballot position for
draft-ietf-idr-bgp-prefix-sid-13: 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:
----------------------------------------------------------------------

   BGP Prefix-SID attribute, it MUST program the derived label as the
   local label for the prefix in its MPLS dataplane.  In case of any
   error, a BGP speaker MUST resort to the error handling rules
This seems over-strong, as the next paragraph suggests that you might reject it
due to policy.

   This document defines a new BGP attribute in order to address the use
   case described in [I-D.ietf-spring-segment-routing-msdc].  It i
   assumed that the new attribute (BGP Prefix-SID) advertisement is
Nit: "is assumed", i think?

   inherits the security considerations expressed in: [RFC4271] and
   [RFC3107].
This section seems like it needs to discuss how the security of this mechanism
interacts with BGPSEC, etc. Maybe it's just "the same as everything else" but
perhaps not...

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 7 Feb 2018 02:32:34 +0000

Hi Eric, 

On 2/6/18, 9:05 PM, "Eric Rescorla" <[email-masked]> wrote:

    

I really don't see that MUST is incorrect since normally the attribute would be validated prior to applying policy.

This was fixed based in the -13 version. You must be looking at a previous version. 
    
ment        inherits the security considerations expressed in: [RFC4271] and
       [RFC3107].
    This section seems like it needs to discuss how the security of this mechanism
    interacts with BGPSEC, etc. Maybe it's just "the same as everything else" but
    perhaps not...

The -13 version references RFC 8277 rather than RFC 3107 which has an extensive "Security Considerations" section relative to MPLS label advertisement. Do you want me to add that there are no security considerations unique to [RFC8205]?

Thanks,
Acee

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 6 Feb 2018 18:36:45 -0800

On Tue, Feb 6, 2018 at 6:32 PM, Acee Lindem (acee) <[email-masked]> wrote:

> I really don't see that MUST is incorrect since normally the attribute
> would be validated prior to applying policy.
>

Oops. My bad. It's the first MUST that I am referring to, about programming
in
the label.

> This was fixed based in the -13 version. You must be looking at a previous

Sorry about that.

> The -13 version references RFC 8277 rather than RFC 3107 which has an
> extensive "Security Considerations" section relative to MPLS label
> advertisement. Do you want me to add that there are no security
> considerations unique to [RFC8205]?
>

I think that would be helpful.

-Ekr

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 7 Feb 2018 02:40:40 +0000

Hi Eric,

From: Eric Rescorla <[email-masked]>
Date: Tuesday, February 6, 2018 at 9:37 PM
To: Acee Lindem <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, Susan Hares <[email-masked]>, Alvaro Retana <[email-masked]>, "[email-masked]" <[email-masked]>, IDR List <[email-masked]>
Subject: Re: Eric Rescorla's No Objection on draft-ietf-idr-bgp-prefix-sid-13: (with COMMENT)

On Tue, Feb 6, 2018 at 6:32 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric,

On 2/6/18, 9:05 PM, "Eric Rescorla" <[email-masked]<mailto:[email-masked]>> wrote:

Oops. My bad. It's the first MUST that I am referring to, about programming in
the label.

Ok – I can see your point here.

Sorry about that.

I will add this clarification and reference to RFC8205 in the -14 version.

Thanks,
Acee

-Ekr

Thanks,
Acee

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 7 Feb 2018 10:33:08 +0100

Hey Acee,

Regarding this text I would actually question it more then the policy point
Eric was raising.

The text says:

   When a BGP speaker receives a path from a neighbor with an acceptable
   BGP Prefix-SID attribute, it MUST program the derived label as the
   local label for the prefix in its MPLS dataplane.

IMO it is incorrect as stated as any label programming carried in the
attribute MUST **only** take place if received path is actually selected as
BGP best path for a given prefix.  Otherwise it is completely wrong thing
to do to install anything which is non best path.

Likewise the BGP path which is either withdrawn or is valid but no longer
best path should have labels carried in its attribute removed from data
plane.

Another interesting point also not discussed at all in the draft when
carrying labels in the attribute is how do you handle multi-path ? Is that
disabled when paths for a given net (and different next hops) have
attributes with different labels ? Is this allowed such that label is a
property of a tuple (prefix + next hop) and not just prefix - like current
version of the draft describes in number of places ?

Thx,
Robert.

On Wed, Feb 7, 2018 at 3:40 AM, Acee Lindem (acee) <[email-masked]> wrote:

> Hi Eric,
>
>
>
> *From: *Eric Rescorla <[email-masked]>
> *Date: *Tuesday, February 6, 2018 at 9:37 PM
> *To: *Acee Lindem <[email-masked]>
> *Cc: *The IESG <[email-masked]>, "[email-masked]" <
> [email-masked]>, Susan Hares <[email-masked]>,
> Alvaro Retana <[email-masked]>, "[email-masked]" <
> [email-masked]>, IDR List <[email-masked]>
> *Subject: *Re: Eric Rescorla's No Objection on
> draft-ietf-idr-bgp-prefix-sid-13: (with COMMENT)
>
>
>
>
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 7 Feb 2018 15:24:41 +0000

Hi Robert,
I’ll add “and that path is selected as the best path” as criteria.
Thanks,
Acee

From: <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Wednesday, February 7, 2018 at 4:33 AM
To: Acee Lindem <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, IDR List <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, Susan Hares <[email-masked]>
Subject: Re: [Idr] Eric Rescorla's No Objection on draft-ietf-idr-bgp-prefix-sid-13: (with COMMENT)

Hey Acee,

Regarding this text I would actually question it more then the policy point Eric was raising.

The text says:

IMO it is incorrect as stated as any label programming carried in the attribute MUST *only* take place if received path is actually selected as BGP best path for a given prefix.  Otherwise it is completely wrong thing to do to install anything which is non best path.

Likewise the BGP path which is either withdrawn or is valid but no longer best path should have labels carried in its attribute removed from data plane.

Another interesting point also not discussed at all in the draft when carrying labels in the attribute is how do you handle multi-path ? Is that disabled when paths for a given net (and different next hops) have attributes with different labels ? Is this allowed such that label is a property of a tuple (prefix + next hop) and not just prefix - like current version of the draft describes in number of places ?

Thx,
Robert.

On Wed, Feb 7, 2018 at 3:40 AM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric,

From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 6, 2018 at 9:37 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Susan Hares <[email-masked]<mailto:[email-masked]>>, Alvaro Retana <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, IDR List <[email-masked]<mailto:[email-masked]>>
Subject: Re: Eric Rescorla's No Objection on draft-ietf-idr-bgp-prefix-sid-13: (with COMMENT)

Sorry about that.

Thanks,
Acee

-Ekr

Thanks,
Acee

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 8 Feb 2018 06:20:55 -0800

On February 6, 2018 at 9:37:26 PM, Eric Rescorla ([email-masked]) wrote:

Acee:

Hi!

Mostly a nit….   The text you added is this:

   When advertised using BGPsec as described in [RFC8205], the BGP

   Prefix-SID attribute doesn't impose any unique security

   considerations.
…which is correct.  However, I think that, as long as we’re mentioning
BGPsec, we should point out that the reason it doesn’t change anything is
because this new attribute is not protected by the BGPsec signatures (just
as all other attributes, except the AS_PATH).  Proposal; add something like
this to the end of the text above:

   The BGP Prefix-SID attribute is not protected by the BGPsec signatures.

Thanks!

Alvaro.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 8 Feb 2018 15:29:46 +0100

Alvaro,

When thinking about security let's think about entire network view.

Today you don't put into FIB (maybe with the exception of
encapsulation/tunnel attribute) any forwarding information into data plane
from BGP attributes - hence whatever protection is offered say by BGPSec
the NLRI which actually go into data plane are protected (in some way).

Statement that BGPSec does not protect attributes is actually contrary to
state that the network security does not get any weaker with this proposal.

Of course for SR the right argument may be to state that this is to be used
only under single administrative domain, but stating that this proposal
does not change anything as attributes are not protected is just not
correct.

Best,
R.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 8 Feb 2018 09:38:29 -0800

Robert:

I think I got lost…what are you trying to get to?

Are you saying that we shouldn’t add the extra sentence?  Do you think
something else needs to be said here?  Are you proposing new
security-related work?

Thanks!

Alvaro.

On February 8, 2018 at 9:29:48 AM, Robert Raszuk ([email-masked]) wrote:

Alvaro,

Best,
R.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 8 Feb 2018 17:44:53 +0000

Hi Alvaro,

From: Alvaro Retana <[email-masked]>
Date: Thursday, February 8, 2018 at 9:20 AM
To: Eric Rescorla <[email-masked]>, Acee Lindem <[email-masked]>
Cc: Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, IDR List <[email-masked]>
Subject: Re: Eric Rescorla's No Objection on draft-ietf-idr-bgp-prefix-sid-13: (with COMMENT)

On February 6, 2018 at 9:37:26 PM, Eric Rescorla ([email-masked]<mailto:[email-masked]>) wrote:

Acee:

Hi!

   considerations.
…which is correct.  However, I think that, as long as we’re mentioning BGPsec, we should point out that the reason it doesn’t change anything is because this new attribute is not protected by the BGPsec signatures (just as all other attributes, except the AS_PATH).  Proposal; add something like this to the end of the text above:

SLAP – will be in -15.

Thanks,
Acee

Thanks!

Alvaro.