Re: [Pce] AD review of draft-ietf-pce-binding-label-sid-10

[Dhruv Dhody <[e-mail]>]

Hi John,

<snip>


> > ***************
> > *** 507,513 ****
> > --- 558,573 ----
> >
> >
> >      In some cases, a stateful PCE can request the PCC to allocate any
> > +                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >      binding value.  It instructs the PCC by sending a PCUpd message
> > +    ^^^^^^^^^^^^^
> > +    I don't understand what that means. My *guess* is that you mean
> > +    the PCE is just saying "hey PCC, please allocate a binding value
> > +    and tell me what it is".  Is that right?  If so I think this
> > +    could be worded even more clearly, perhaps "a stateful PCE may
> > +    want to request that the PCE allocate a binding value of the PCE's
> > +    own choosing"?
> > +
> >
> > [Dhruv]: It should be PCC's own choosing.
>
> Were you just correcting my comment (to say I should have written “PCC”
> the latter two times, I agree, my mistake), or was your point also to say
> that yes, my guess is correct? If the latter, then as I mentioned, I’d
> appreciate having the wording improved.
>
>
[Dhruv]: I was correcting your suggested text (sorry for not being clear).
I agree that clarifying text is a good idea.



> > <snip>
> > ***************
> > *** 655,660 ****
> > --- 742,758 ----
> >         *  Send a PCErr message with Error-Type=19 (Invalid Operation)
> and
> >            Error-Value=16 (Attempted PCECC operations when PCECC
> >            capability was not advertised)
> > +
> > + You need to update your reference to point to RFC 9050. You should
> > + then either reference §5.4 and NOT copy-and-paste the relevant text,
> > + or you should (less desirably, IMO) update your copy-and-paste to
> > + the text published with RFC 9050.  Notably, RFC 9050 covers the case
> > + of a legacy PCEP speaker, whereas the text in this spec doesn't.
> > +
> > + IMO since RFC 9050 already specifies what to do when the capability
> > + isn't exchanged, there is no need to say anything at all in this
> > + document, so unless you have a compelling reason (what?) to keep it,
> > + please remove this bullet and its two sub-bullets.
> >
> >         *  Terminate the PCEP session
> >
> >
> >
> > [Dhruv]: The only reason to include this text is for "P=1 in the LSP
> object" i.e. the presence of the LSP object with P flag set is to be
> considered as a PCECC operation, which would not be the case in RFC9050.
>
> I see, thanks. In that case, then I guess the copy-paste needs to be
> updated to follow the text in 9050, or if that doesn’t work for some reason
> I’ve overlooked, in any case the text needs to be updated to cover the case
> of a legacy speaker.
>
>
[Dhruv]: Agree.



> > ***************
> > *** 745,754 ****
> >      [RFC8281] and [RFC8664] are applicable to this specification.  No
> >      additional security measure is required.
> >
> > !    As described [RFC8664], SR allows a network controller to
> instantiate
> >      and control paths in the network.  A rogue PCE can manipulate
> binding
> >      SID allocations to move traffic around for some other LSP that uses
> >      BSID in its SR-ERO.
> >
> >      Thus, as per [RFC8231], it is RECOMMENDED that these PCEP extensions
> >      only be activated on authenticated and encrypted sessions across
> PCEs
> > --- 843,857 ----
> >      [RFC8281] and [RFC8664] are applicable to this specification.  No
> >      additional security measure is required.
> >
> > !    As described in [RFC8664], SR allows a network controller to
> instantiate
> >      and control paths in the network.  A rogue PCE can manipulate
> binding
> >      SID allocations to move traffic around for some other LSP that uses
> >      BSID in its SR-ERO.
> > +
> > + Try as I might, I'm not able to figure out what, specifically, the
> above
> > + sentence (that begins "a rogue PCE") means.  I mean, I get it, a rogue
> > + PCE can misdirect traffic.  Beyond that, can you help me understand
> what
> > + you meant to convey here?
> >
> > [Dhruv]: IMHO it highlights how this new capability of "allocating
> binding SID" can be exploited by a rogue PCE to misdirect traffic. Path
> {A, B, BSID_1}  can be misdirected just by assigning the BSID_1 value to a
> different LSP making it a lot easier (and harder to detect).
>
> I think it would be helpful to add something concrete like that.
>
>
[Dhruv]: I agree.



> >      Thus, as per [RFC8231], it is RECOMMENDED that these PCEP extensions
> >      only be activated on authenticated and encrypted sessions across
> PCEs
> > ***************
> > *** 773,778 ****
> > --- 876,889 ----
> >
> >      The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to
> >      include policy configuration for binding label/SID allocation.
> > +
> > + It looks like pcep-yang expired a couple months ago, but I think
> > + that's just an oversight and doesn't reflect the WG abandoning
> > + the work.  Is there any intention on the part of the WG, to
> > + extend it as described?  My understanding is that yes, the WG does
> > + intend to do this -- in that case I think this section would be
> > + stronger if you indicated that, something like "The PCEP YANG module
> > + will be extended..." instead of "could be".
> >
> >
> >
> > [Dhruv]: This one is my fault. It is on my to-do list to update.
>
> OK, thanks. If the WG has consensus that the YANG module will be extended
> as described, I think making the suggested change might help avoid
> questions during IESG review.
>
>
[Dhruv]: Sure!

<snip>

Cheng is holding the pen for this I-D. It's a holiday week in China, so
let's give him some time to respond.

Thanks!
Dhruv