Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-lsp-control-request-09: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 03 October 2019 19:45 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8AB12020A; Thu, 3 Oct 2019 12:45:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlWTV5Q_pxFr; Thu, 3 Oct 2019 12:45:16 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8439120098; Thu, 3 Oct 2019 12:45:15 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x93Jj96q007273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 3 Oct 2019 15:45:11 -0400
Date: Thu, 3 Oct 2019 12:45:08 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Dhruv Dhody <dhruv.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-pce-lsp-control-request@ietf.org, Hariharan Ananthakrishnan <hari@netflix.com>, pce-chairs <pce-chairs@ietf.org>, pce@ietf.org
Message-ID: <20191003194508.GY6424@kduck.mit.edu>
References: <156986574432.578.10826380036165341647.idtracker@ietfa.amsl.com> <CAB75xn5Lj4pGCwKgf3_PQtGFVfTM_FvvKXPFmjDSnmGGn5u1nw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAB75xn5Lj4pGCwKgf3_PQtGFVfTM_FvvKXPFmjDSnmGGn5u1nw@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/1Rzgr7cToC6tqS8QrIn7c0aNR98>
Subject: Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-lsp-control-request-09: (with DISCUSS and COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Oct 2019 19:45:19 -0000

On Tue, Oct 01, 2019 at 01:44:54PM +0530, Dhruv Dhody wrote:
> Hi Ben,
> 
> Thanks for your review. A few thoughts on your DISCUSS...
> 
> On Mon, Sep 30, 2019 at 11:19 PM Benjamin Kaduk via Datatracker
> <noreply@ietf.org>; wrote:
> >
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-pce-lsp-control-request-09: Discuss
> >
> > 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-pce-lsp-control-request/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > This may just be a philosophical discussion, but if RFC 8231 marks the
> > PLSP-ID value of 0 as "reserved" and we are making use of the extension
> > point, do we need to have an Updates: relationship with 8231?  This
> > seems particularly poigniant given that we have to explicitly override
> > the RFC 8231 error handling, with some text in the second paragraph of
> > Section 4.
> >
> 
> There are various cases when PLSP-ID can be zero already. RFC 8231 has
> end-of-synchronisation marker. RFC 8281 uses it to indicate removal of
> all LSPs. So IMHO this extension defines a new use of PLSP-ID=0 to be
> used, that too, only when the C flag is set!
> 
> As Deborah puts it - this does not require an update to existing RFC
> 8231 implementation. Only those implementing this 'optional' feature
> needs to consider this.

I think we should leave this to the other ongoing thread.

> 
> > What kind of feature negotiation is available to check support prior to
> > using this flag?  After all, if the peer does not implement this
> > document it will not implement the override of 8231 error handling and
> > will respond with errors when the D flag is set (or the PLSP-ID of 0
> > used).  If we have to just "try it and fall back to not using it if we
> > get errors", that has some associated security considerations as well.
> >
> 
> In this case Capability negotiation might be an overkill. We are just
> adding a new flag; there is a clear error case to work with legacy
> implementation.
> 
> Anyways, We can update the security considerations to include this
> fact. Something like -
> 
>    Note that, a PCE may not be sure if a PCC supports this feature.  A
>    PCE would try sending a control request to a 'legacy' PCC, which
>    would in turn respond with an error as described in Section 4.  So a
>    PCE would learn this fact only when it wants to take control over an
>    LSP.
> 
> Do you see anything else worth highlighting?

If TLS is not used, a MITM could inject an error and cause the PCE to not
use the feature when it otherwise could be used.  But the consequences of
that are, I think, not terribly severe, so we don't need to do more than
note the risk of downgrade.  (I still don't have a sense for how widely
deployed RFC 8253 is, as came up in Stephen's secdir review of a different
document.)

> > What can we say about authorization policy on the PCC?  Alvaro touched
> > on this in his Comment, but I think it's important enough to be
> > Discuss-level.  Since this policy is the key factor to the security
> > posture of this extension, not only does it seem like there MUST be the
> > ability to configure the policy, but it also seems like we should be
> > able to give some guidance on typical use cases (where the authors
> > believe the security properties to be reasonable).  Other use cases
> > might require an additional level of analysis by those proposing to
> > deploy the solution.
> >
> >
> 
> Delegation is just about giving temporary control to PCE, the real
> impact on LSP would happen when a PCE updates the LSP parameters. This

Yes and no -- applying policy here could be seen as an "additional layer of
protection" in that if a PCC has a LSP that is particularly sensitive, it
will never be subject to PCUpd requests.  But the same policy could be done
within the bounds of RFC 8231 by "denying the request"ed updates from the
PCUpd messages, it is true.  The difference becomes more a matter of ease
of implementation and risk of errors; from a perspective of designing
systems to be safe in the face of error/accident, the extra policy layer
may make a lot of sense.

> impact fall under RFC 8231 where PCC decides to either accept the
> update or not. Moreover RFC 8281 grants PCE the capability to initiate
> LSPs as well.
> 
> So IMHO this request control falls within the existing perimeter of
> the protocols.
> 
> I wrote this to Alvaro -
> 
> > 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.
> 
> So the key question is that does this 'control request' raises to the
> level that we make policy a MUST, when RFC 8231/8281 did not...

I think I can accept the SHOULD-level requirement; thanks for the above
text.

> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Section 1
> >
> >                It includes mechanisms to effect LSP state
> >    synchronization between Path Computation Clients (PCCs) and PCEs,
> >    delegation of control of LSPs to PCE, and PCE control of timing and
> >    sequence of path computations within and across PCEP sessions.  [...]
> >
> > nit: assuming this is grouped as "it includes mechanisms to: (1) effect
> > LSP state synchronization [...], (2) delegation of control [...], and
> > (3) PCE control of timing and sequence [...]", the verb tenses need to
> > be changed so that they match up.
> >
> >    For Redundant Stateful PCEs (section 5.7.4. of [RFC8231]), during a
> >    PCE failure, one of the redundant PCE could request to take control
> >    over an LSP.  The redundant PCEs may use a local policy or a
> >
> > Just to check: this request is only possible with the mechanism defined
> > in this document, and is not possible with just the previous
> > technologies?  I might suggest to s/could/might want to/ to make it more
> > clear that this is motivating the rest of the document.
> >
> >    In case of virtualized PCEs (vPCE) running as virtual network
> >    function (VNF), as the computation load in the network increases, a
> >
> > nit: singular/plural mismatch "PCEs"/VNF
> >
> >    can be used in conjunction to [RFC8231].  Ultimately, it is the PCC
> >    that decides which PCE to delegate the orphaned LSP.
> >
> > nit: either "to which to delegate the orphaned LSP" or "to delegate the
> > orphaned LSP to".
> >
> > Section 3
> >
> >    A new flag, the "LSP-Control Request Flag" (C), is introduced in the
> >    SRP object.  On a PCUpd message, a PCE sets the C Flag to 1 to
> >    indicate that it wishes to gain control of LSPs.  The LSPs are
> >    identified by the LSP object.  A PLSP-ID of value other than 0 and
> >    0xFFFFF is used to identify the LSP for which the PCE requests
> >    control.  The PLSP-ID value of 0 indicates that the PCE is requesting
> >    control of all LSPs originating from the PCC that it wishes to
> >    delegate.  [...]
> >
> > nit: I suggest s/identified by the LSP object/identified by the PLSP-ID
> > in the LSP object following the SRP object/.
> >
> >    delegate.  The C Flag has no meaning in other PCEP messages that
> >    carry SRP object and the flag MUST be set to 0 on transmission and
> >    MUST be ignored on receipt.
> >
> > nit: I suggest s/object/objects/ and s/and the/and for which the/
> >
> > Section 4
> >
> >    If a PCE wishes to gain control over an LSP, it sends a PCUpd message
> >    with C Flag set to 1 in SRP object.  The LSP for which the PCE
> >    requests control is identified by the PLSP-ID.  The PLSP-ID of 0
> >
> > nit: as above, I suggest s/identified by the PLSP-ID/identified by the
> > PLSP-ID in the associated LSP object/
> >
> >    timer.  A PCE ignores the C Flag on the PCRpt message.  Note that, if
> >
> > nit: I think this is now redundant with the text added in respone to
> > the genart review ("The C Flag has no meaning in other PCEP messages
> > that carry SRP object and the flag MUST be set to 0 on transmission and
> > MUST be ignored on receipt").
> >
> >    It should be noted that a legacy implementation of PCC, that does not
> >    support this extension would trigger the error condition as specified
> >    in [RFC8231] (a PCErr with Error-type=19 (Invalid Operation) and
> >    error-value 1 (Attempted LSP Update Request for a non-delegated LSP))
> > I don't understand this sentence -- what does "as the D Flag would be
> > unset" mean?  Does it just mean that the PCC treats it as unset because
> > it has no code to handle the D flag at all?
> >
> 
> Suggestion to make this clearer with -
> 
>    It should be noted that a legacy implementation of PCC that does not
>    support this extension would trigger the error condition as specified
>    in [RFC8231] (a PCErr with Error-type=19 (Invalid Operation) and
>    error-value 1 (Attempted LSP Update Request for a non-delegated
>    LSP)), as any control request would have the D Flag (delegate) unset
>    and it would be considered as attempt to update a non-delegated LSP.

That's an improvement, but only a slight one (or perhaps I'm still
confused).  The question seems to be not whether the D flag is set (which
is controlled solely by the PCE), but whether the PCC recognizes that the
D flag is set (i.e., whether it recognizes the D flag at all).  So perhaps
"as the D Flag would not be processed, and it would be considered as an
attempt to update a non-delegated LSP"?

Thanks,

Ben

> > Section 6
> >
> > Please cite RFC 7525 as BCP 195.
> >
> >
> 
> Thanks!
> Dhruv