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

Dhruv Dhody <dhruv.ietf@gmail.com> Fri, 04 October 2019 06:41 UTC

Return-Path: <dhruv.ietf@gmail.com>
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 7775E12004E; Thu, 3 Oct 2019 23:41:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 DrErwJ1nQe-2; Thu, 3 Oct 2019 23:41:46 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17CB120018; Thu, 3 Oct 2019 23:41:46 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id n197so11165579iod.9; Thu, 03 Oct 2019 23:41:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AY7h5gdOpoTZtHCSh/OASv1wLdJnybcSSE8n2ep7gl4=; b=BeYNQF8b45y2JMrIfXF9YTwvqOU4mftHSq5I6ij2InzKazeuPKqWHZ9y71scmGFaMK LahHUiu/D8/Mi2teHZERFTVqpXKH7Fb7MaUP1PgfFdUzWk5RmCKFVd++uQ/rAEPYMeBp nbuZcoQUg7KrurlQWosUG/xWGETiehTqimqdEPWEwxLxHu0Ef4z67UaeWge5rDA047Ej r9GQf68Q81H2FC3Nm6Et41nkv4PixfjP5kfSjEMzr3cUWuYH3rvbmpCE081wMWLWb2uJ kkUQyXyhH6ANPjmjM0SdNhf+96LfzrFgsne1Tp4grhQd+1f+3qMJxoiot6o8I6kJsNzR JA8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AY7h5gdOpoTZtHCSh/OASv1wLdJnybcSSE8n2ep7gl4=; b=UACm8oD3wsfyYxabjqIRCJOxz3yXjVEZi+C/CP1eGXtD6n938npprEtvyUkWVirywd YRE/1Hsd5JELRl//BSmdJRZ5rlyC79AlSbB+G5Gvsj706D9uZphuDYn4XuR+hBCBhX+e Lhx5i3NS/fxej4OrKDLbGMimU2Vl+EYHLWH+rimw15UjXwJckBliV+4HTx/jiWlIp/Lk 135+8IdeLX2td6TwzdTzYHFSQc4gbuL6VFFplTe5h+Tql3OkYv5bf/rtaLlzawn+EWEu 19oSUqXZHdooaRk/w13JPb8steyPJLrdfLmF5k+RitXWwyRohvPdK1iJAnMForKKIJss ht3g==
X-Gm-Message-State: APjAAAU5MHZAIOTxD3VGPctegFi7GbH0BH8Q8oTUXdKs8jqUfeWUyJer EEw4TFCccH/O393+Ue+S0Ziyt9mI3YksGxEHOnYWCkq7
X-Google-Smtp-Source: APXvYqx9HIFXhxuKzItQjL87FJtkcZhG86083X+EHHM6xGGl7Ni1bUmCFK9WlVGsZ4C+aRgIH67t9E6rL0zwIAimkPE=
X-Received: by 2002:a92:458a:: with SMTP id z10mr14054051ilj.279.1570171305778; Thu, 03 Oct 2019 23:41:45 -0700 (PDT)
MIME-Version: 1.0
References: <156986574432.578.10826380036165341647.idtracker@ietfa.amsl.com> <CAB75xn5Lj4pGCwKgf3_PQtGFVfTM_FvvKXPFmjDSnmGGn5u1nw@mail.gmail.com> <20191003194508.GY6424@kduck.mit.edu>
In-Reply-To: <20191003194508.GY6424@kduck.mit.edu>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Fri, 4 Oct 2019 12:11:09 +0530
Message-ID: <CAB75xn4m=LEOse-+B3L2fcrg5kr_cgszomfUdPJ+hRg6yg1f9g@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
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
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/vWXxZtEPS_-yfECwRVfB38YGRss>
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: Fri, 04 Oct 2019 06:41:49 -0000

Hi Ben,

> >
> > > 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.

That can be added.


> > 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.
>

Thanks!


> > >    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"?
>

I think you mean C flag would not be processed. Just to clarify -

- D flag is defined in RFC 8231 and any PCUpd message would always set
it as per RFC 8231.
- This document defines a new C flag, and ask that D flag must be
unset if the C flag is set.
- A legacy implementation that receives an PCUpd with C=1 and D=0,
would simply ignore the C flag and trigger the error because D flag is
unset.

Let me try again -

   It should be noted that a legacy implementation of PCC that does not
   support this extension would receive an LSP control request: PCUpd
   message with C flag set and D flag (delegate) unset, it would ignore
   the C flag and trigger the error condition for the D flag 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)).

Thanks!
Dhruv