Hi Alvaro, On Fri, Oct 4, 2019 at 4:49 PM Alvaro Retana <[email protected]> wrote: > > On September 30, 2019 at 7:29:19 AM, Dhruv Dhody ([email protected]) wrote: > > Dhruv: > > Hi! > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I have a substantive comment and then some nits/editorial notes. > > > > (1) It seems to me that any PCE can request control of an LSP. Even if the > > sessions are authenticated and encrypted, how does the PCC determine if > > it's ok > > for the requesting PCE to ask for control? §8.1 says that an "implementation > > SHOULD allow the operator to configure the policy based on which it honors > > the > > request to control the LSPs". If the implementation doesn't allow the > > configuration of policy, then it is possible for a rogue PCE to ask for > > control > > of an LSP, and for the PCC to grant it. Why is the ability to configure this > > policy not REQUIRED? I believe this case should be explicitly called out as > > a > > vulnerability. > > > > Thanks for pointing this out. Since RFC 8231 uses SHOULD wrt policy, I > would consider not changing that. We can highlight that the PCC is the > ultimate arbiter on if the delegation should be made and to which PCE. > Even after delegation, the PCC can take back control anytime. But at > the same time blindly accepting control request could be a problem! > > I propose this text in Security section - > > A PCC is the ultimate arbiter of delegation. As per [RFC8231], a > local policy at PCC is used to influence the delegation. A PCC can > also revoke the delegation at any time. A PCC MUST NOT blindly trust > the control requests and SHOULD take local policy and other factors > into consideration before honoring the request. > > > Two points: > > (1) How is “MUST NOT blindly trust” normatively enforceable? Even if it was, > the mechanism to take off the blindfolds is the policy… >
You are right, better to avoid normative language here. > (2) Even if policy is configured, a rogue PCE can still take control of the > LSP; for example, the policy was misconfigured, or simply because the PCE has > been compromised. > > In all these cases the problem is not so much that a PCE took control, but > the actions that it can take with the LSP: change its characteristics, > reroute it, shut it down, etc… > I made the same point to Ben in my reply. The actions that the PCE can take on a delegated LSP is covered by RFC 8231: a PCC could reject the parameters set by the PCC and it could also revoke delegation. Policy related text in RFC 8231 uses SHOULD. Does the ability of a PCE to 'request' control over an LSP in itself raise the bar? IMHO it falls well within the existing protocol policy parameters of RFC 8231 (and also RFC 8281: PCE-initiated LSP). For the sake of consistency I feel SHOULD is the way to go. Thanks! Dhruv > Thanks! > > Alvaro. _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
