Re: [Pce] RtgDir review: draft-ietf-pce-pceps-12

Dhruv Dhody <dhruv.ietf@gmail.com> Sat, 20 May 2017 15:17 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 EE7D5126BF3; Sat, 20 May 2017 08:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 LVWE4WpZSjCb; Sat, 20 May 2017 08:17:18 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 8572B1277BB; Sat, 20 May 2017 08:17:18 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id k74so80585054qke.1; Sat, 20 May 2017 08:17:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dfxGH1LB26TMQACgqmSRqjj5M+J76JsheqUD6SHLePM=; b=QTKLBH+OeoS73/L4L6YJ/Eeis7YzX7BwR3aPPDVXwbUTRGOcv/N9ZM7YCzQq/1phep lagGp2Qeym/q8a6s97+bBWuECGW0fLpKPaIhoSrMxKyguMvzZq+HPtd0K/ZwZyZi8k0T fs7QTGj6mF6rlBdNlF7O7HuGv5Py++RkAT6fee0whxXyMd9J9m2wYgaOoCc8hkMZpavH isEHf1jQzgox24bETuInR5LyBryCCnaS0YXWtvjXsR4StBe/ErMW5+czcuRbZzueR/jO 72DWJVc1Zlv5O8T2hCC3qCfJwDPDsvhZKTe9jqEVIRjWo3FvG6GaGotsKWvLdW+Gst4Z puUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dfxGH1LB26TMQACgqmSRqjj5M+J76JsheqUD6SHLePM=; b=DFzbkf4n5JSn4mX8PWeCQB6rrUze5cMcFddqUix3CAceMdqJTUEN6B9L/Cr7IhZ4y6 ni9ksevzU8JB+4dBBFJZdN8vKA7suDDkvPbTx2Ra4wcTk2LXGNVaS4cEHjh5FSIXAcQy DU3YvJ5CG+Nv9KuqXJDRT1Chol+O758L+zPWXXU9YiE17jpz89i9F0aNvvcoeV7qDrAO neLsqhE9W9s7znO2Kb61bwb60qUDL6szSXzDVS22kvlgKE/NEgM9iK4l/iq4o8shyVXj YolF3tr0tgNqRjR67x+rV7D1Tgq+4vgNOU5IfoBi3g9CplZSoc3jjuNZbkZGpDSrE3lT 3s1A==
X-Gm-Message-State: AODbwcCz4hU6BT/Jmi74W8xyI2ixZTHGXWDOSJNOpQhWXIbrrFdzsCLz zuKvvdW6XgrnAy969HeT2Abk//oOiQ==
X-Received: by 10.55.43.144 with SMTP id r16mr14774458qkr.213.1495293437730; Sat, 20 May 2017 08:17:17 -0700 (PDT)
MIME-Version: 1.0
Sender: dhruvdhody@gmail.com
X-Google-Sender-Delegation: dhruvdhody@gmail.com
Received: by 10.200.55.212 with HTTP; Sat, 20 May 2017 08:17:17 -0700 (PDT)
In-Reply-To: <23CE718903A838468A8B325B80962F9B8CAD810B@blreml501-mbb>
References: <1494509464.34491.973270680.4CBC76C2@webmail.messagingengine.com> <23CE718903A838468A8B325B80962F9B8CAD810B@blreml501-mbb>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Sat, 20 May 2017 20:47:17 +0530
X-Google-Sender-Auth: Rm3yI1sf2KI74msHUTuV1aqLRIQ
Message-ID: <CAB75xn7vPytXevshRXdWXJ3Nr_1aGm9AAxWerSW3mt4uH8pkvw@mail.gmail.com>
To: Dan Frost <frost@mm.st>
Cc: "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "draft-ietf-pce-pceps.all@ietf.org" <draft-ietf-pce-pceps.all@ietf.org>, "pce@ietf.org" <pce@ietf.org>, Dhruv Dhody <dhruv.dhody@huawei.com>
Content-Type: multipart/alternative; boundary="001a1147164830e5f0054ff62278"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/O7Wfg9QxyYmVedziSKVyAQw-QYw>
Subject: Re: [Pce] RtgDir review: draft-ietf-pce-pceps-12
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 20 May 2017 15:17:22 -0000

Hi All,

A new version handling the RTGDIR comments is posted.
https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/

See diff at - https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pceps-13

Thanks Dan for the comments.

Regards,
Dhruv


On Thu, May 11, 2017 at 10:07 PM, Dhruv Dhody <dhruv.dhody@huawei.com>
wrote:

> Hi Dan,
>
> Thanks for your review. Please see inline...
>
> > -----Original Message-----
> > From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dan Frost
> > Sent: 11 May 2017 19:01
> > To: rtg-ads@ietf.org
> > Cc: rtg-dir@ietf.org; draft-ietf-pce-pceps.all@ietf.org; pce@ietf.org
> > Subject: [Pce] RtgDir review: draft-ietf-pce-pceps-12
> >
> >
> > Hello,
> >
> > I have been selected as the Routing Directorate reviewer for this draft.
> > The Routing Directorate seeks to review all routing or routing-related
> drafts as
> > they pass through IETF last call and IESG review, and sometimes on
> special
> > request. The purpose of the review is to provide assistance to the
> Routing ADs.
> > For more information about the Routing Directorate, please see
> > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> >
> > Although these comments are primarily for the use of the Routing ADs, it
> would
> > be helpful if you could consider them along with any other IETF Last Call
> > comments that you receive, and strive to resolve them through discussion
> or by
> > updating the draft.
> >
> > Document: draft-ietf-pce-pceps-12
> > Reviewer: Dan Frost
> > Review Date: 2017-05-11
> > IETF LC End Date:
> > Intended Status: Standards Track
> >
> > Summary:
> >
> > I have significant concerns about this document and recommend that the
> > Routing ADs discuss these issues further with the authors.
> >
> > Comments:
> >
> > This document proposes to add a STARTTLS mechanism to the PCE protocol.
> > If this basic approach is accepted, then the document is in good shape.
> > It's clear, complete, and straightforward. The question is whether
> mandating
> > STARTTLS is actually a good idea.
> >
> [Dhruv] Yes, this has been discussed in the WG.
> The individual draft in fact asked for another port no, and during the WG
> adoption process, it was discussed in the WG as well as with security
> experts, and concluded that we should use STARTTLS.
> As far as I am aware, use of different port for secured version of a
> protocol has not been followed by IETF for some time now.
>
> > Major Issues:
> >
> > My main concern with this document is that it takes as given that
> STARTTLS is
> > the right way to secure PCEP with TLS. Perhaps this argument was already
> had at
> > some point and this draft is the result, but if so then at a bare
> minimum it needs
> > rationale explaining why STARTTLS was chosen over alternatives, and text
> that
> > addresses weaknesses and mitigations associated with STARTTLS
> processing, in
> > particular the possibility and relative ease of downgrade attacks.
> >
> [Dhruv] I see the benefit of adding text, something in line of -
>
> "As per the recommendation from [RFC7525], PCEP peers that support PCEPS,
> SHOULD prefer strict TLS configuration i.e. do not allow non-TLS PCEP
> sessions to be established."
>
> I will discuss further with my co-authors/chairs/AD, if we also need to
> spell out the full rationale here.
>
> > The obvious alternative would be to not use STARTTLS and simply allocate
> > another TCP port for PCEP-over-TLS. This avoids complicating the PCE
> protocol
> > and introducing the potential for downgrade attacks based on STARTTLS.
> PCE is
> > used to convey critical path-determination information in carrier
> networks,
> > among other things. That it's not fully authenticated and encrypted in
> all cases
> > already is an unfortunate legacy of a bygone era. Ideally operators
> should move
> > as quickly as possible to secure PCEP and aim to entirely remove the
> unsecure
> > form.
> > STARTTLS serves a weaker goal of "opportunistic" security, which, while
> it has its
> > uses, makes little sense for PCE compared to simply deprecating the
> unsecured
> > version.
> >
> > Minor Issues:
> >
> > * Section 3.3: "A RECOMMENDED value for StartTLSWait timer is 60
> seconds."
> > This seems like a very long time to wait for an initial reply on an
> already-
> > established TCP connection.
> >
> [Dhruv] We saw a benefit in keeping this same as the OpenWait time in the
> PCEP session establishment.
>
> > * Section 3.2, fifth paragraph (beginning with "A PCEP speaker
> > receiving..."):
> >
> > This paragraph states: "A PCEP speaker receiving any other message apart
> from
> > StartTLS, open, or PCErr MUST treat it as an unexpected message..."
> >
> > As written this is confusing and seems to imply that no other PCEP
> messages can
> > ever be sent. It looks like this is meant to be scoped to the context of
> the first
> > message sent/received on session initiation?
> >
> [Dhruv] Yes. I will add clarification that this is for the first message.
>
> > * Section 8.6
> >
> > The subsection titles of Section 8 have been taken from Section 8 of RFC
> 5440,
> > but Section 8.6 here is called "Impact on Network Operations"
> > while in RFC 5440 it's called "Impact on Network Operation". Funnily
> enough,
> > that final "s" makes a difference. Without it, the section refers to an
> impact on
> > the functioning of the network itself. With it, it would usually be
> taken to refer
> > to impact on human operations and management procedures.
> >
> > It looks correct to say that the mechanism of this draft should not
> significantly
> > impact the functioning of the network. On the other hand, it certainly
> does
> > impact operations and management procedures, as staff have to develop
> > policies around security requirements for PCEP within the organization,
> methods
> > for verifying whether device security parameters are configured
> correctly,
> > checking for unexpected downgrades to insecure sessions, etc. It would
> be an
> > improvement for the document to address the impact of PCEPS on
> operational
> > processes.
> >
> [Dhruv] Agreed. I will work on text in this section, along these lines.
>
> > Nits:
> [Dhruv] Ack for all.
>
> Thanks for your review.
>
> Regards,
> Dhruv
>
> >
> > Sec 3.1, first paragraph:
> > OLD
> >     The steps involved in the PCEPS establishment consists of following
> >     successive steps:
> > NEW
> >     The steps involved in establishing a PCEPS session are as follows:
> > END
> >
> > Sec 3.4, Step 3:
> > s/Any attempt of initiate a TLS/Any attempt to initiate a TLS/
> >
> >
> > Cheers,
> > -d
> >
> > _______________________________________________
> > Pce mailing list
> > Pce@ietf.org
> > https://www.ietf.org/mailman/listinfo/pce
>