Re: [Pce] Roman Danyliw's Discuss on draft-ietf-pce-stateful-hpce-13: (with DISCUSS and COMMENT)

Dhruv Dhody <dhruv.ietf@gmail.com> Tue, 24 September 2019 14:06 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 3F50B120854; Tue, 24 Sep 2019 07:06:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, 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 jCPkzSkP2pJu; Tue, 24 Sep 2019 07:06:28 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 E6682120845; Tue, 24 Sep 2019 07:06:27 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id j4so4675854iog.11; Tue, 24 Sep 2019 07:06:27 -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:content-transfer-encoding; bh=FPPWmV2FnXlpVVeDBR7vHj2wGvjoWsJn3Dk2adfN4Vs=; b=K5k/Js8z5/Pz5FP+/LNkMAmmaRP/Pe8f5z0isU6v7nZ/YJXDI7qQjBmkj0+wdjwysx vLiiIm3x36BBNeIOoTVwLr7UbAhYvJLVmBXaYcg6VG02OhxwmWuUT+nSBNCMgKyaCq4n ciRCCwROtLXYrpJmGEwRTKFs90Sv9MNCDzTevHwGzQQDF2qD7iF9LXIHQH6fk5eYC8Ir 2Iw68R23C5iMSChOj7ZRFxnkEKLtTPSmGWUHEtyZATgd5EGY+hMwTtuc2ybFLjfGf1wH Y36srP0njBnKwnuVzFEoBC/6dRQMtHpyhHqF3u9UNOq1AG12nhTdDaw6FMupZeT98C0H aehQ==
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:content-transfer-encoding; bh=FPPWmV2FnXlpVVeDBR7vHj2wGvjoWsJn3Dk2adfN4Vs=; b=T+vAmma8jauuIab2qJ7Snv+8JLuvpsPPBhwHrGZCfN3TINV7p88Afn8phZ4bBJyQ40 o+6KJsmETQ9nbQkZDZazQLDCzsq7tSxPgH3i3V1vToDiPWXMmOJ8JCgco9vgoklJJcAo Y25u9ykvf//IhiMwl6Gu3yO892KsOq1m/2J4IG+RQ93H2+I2oyolkeYSJY27+37/rW+7 N87xFf6auuXF2/vUOWPZwlyLJPMtd3+2LC/NO7Vtyjn4qk+2zXBCdDyEqPa7ULn6USXC tNJNTipE4YIKM09TCg8fsf6/jSwlC3rCHqqcg8QwFgXxRtWqq504K1U7DRaPhcaNqBG2 EBcA==
X-Gm-Message-State: APjAAAWtDFozGXeDTegHYCo4sYQ3N0rEScIg+ZNhHm1MiGkDcGyrN4IN Nvwdj28P2czd5Vk7HbQSXYEw0rZqLLmDOCx5yQU=
X-Google-Smtp-Source: APXvYqzfg5Sm7M+FLg0uK2zfc04/LIzI205F65zsZtuz1AT1yEFOeW4ZiN8+avUT9OAIG5Vr0zgnIMAyjVZuNZuG2kk=
X-Received: by 2002:a5d:9457:: with SMTP id x23mr3649555ior.14.1569333986942; Tue, 24 Sep 2019 07:06:26 -0700 (PDT)
MIME-Version: 1.0
References: <156881612137.4479.15191325652251719065.idtracker@ietfa.amsl.com>
In-Reply-To: <156881612137.4479.15191325652251719065.idtracker@ietfa.amsl.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Tue, 24 Sep 2019 19:35:49 +0530
Message-ID: <CAB75xn7ffQRzKdiHf3U5asnFuOenBQoeHT-ER1Bdd=zeieiXtQ@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-pce-stateful-hpce@ietf.org, Adrian Farrel <adrian@olddog.co.uk>, pce-chairs <pce-chairs@ietf.org>, pce@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/zuNvwEEsu1CUtxqrvr0OryMTvt0>
Subject: Re: [Pce] Roman Danyliw's Discuss on draft-ietf-pce-stateful-hpce-13: (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: Tue, 24 Sep 2019 14:06:33 -0000

Hi Roman,

Thanks for your review.

On Wed, Sep 18, 2019 at 7:45 PM Roman Danyliw via Datatracker
<noreply@ietf.org> wrote:
>
> Roman Danyliw has entered the following ballot position for
> draft-ietf-pce-stateful-hpce-13: 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-stateful-hpce/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> ** Section 4.  Per “The security considerations listed in [RFC8231], [RFC6805]
> and [RFC5440] apply to this document as well. As per [RFC6805], it is expected
> that the parent PCE will require all child PCEs to use full security when
> communicating with the parent.”, the references make sense, thanks for making
> them.  My concern is in the definition of “use full security”.  I can see those
> words come from RFC6805, however, I can't find where that set of practices is
> defined.  Can this please be clarified.
>

How about we update to "..full security (i.e. the highest security
mechanism available for PCEP)"?

>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> ** Section 4.  Per the recommendation to use TLS _or_ TCP-AO.
> -- I take the point from the SECDIR (thanks Stephen Farrell) about the (lack
> of) deployment of AO.  My caution would be that TLS and TCP-AO provide
> different security mechanism and therefore imbue different security properties
> and this should be noted. (i.e., this isn’t a choice between like options)
>

How about I make at "..and/or.."? RFC8253 encourages the use of TCP-AO
alongside TLS. This could do the trick of removing the sense of choice
without adding more text.

> -- As an editorial nit, it would be worth saying that guidance for implementing
> using TLS with PCEP can be found in RFC8232.
>

You mean RFC 8253 right? Updated text -

   Thus it is RECOMMENDED to secure the PCEP session (between the P-PCE
   and the C-PCE) using Transport Layer Security (TLS) [RFC8446] (per
   the recommendations and best current practices in [RFC7525]) and/or
   TCP Authentication Option (TCP-AO) [RFC5925]. The guidance for
   implementing PCEP with TLS can be found in [RFC8253].

> ** Editorial Nits:
> Title.  Is the period at the end of the title necessary?
>
>

Removed.

Thanks!
Dhruv