Re: [Last-Call] Secdir last call review of draft-ietf-pce-lsp-extended-flags-05

Dhruv Dhody <dd@dhruvdhody.com> Tue, 11 October 2022 04:49 UTC

Return-Path: <dd@dhruvdhody.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022E0C14CF05 for <last-call@ietfa.amsl.com>; Mon, 10 Oct 2022 21:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dhruvdhody-com.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAdfLEBGPeJz for <last-call@ietfa.amsl.com>; Mon, 10 Oct 2022 21:49:27 -0700 (PDT)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CF2C1527AB for <last-call@ietf.org>; Mon, 10 Oct 2022 21:49:27 -0700 (PDT)
Received: by mail-vs1-xe2a.google.com with SMTP id v68so12265223vsb.1 for <last-call@ietf.org>; Mon, 10 Oct 2022 21:49:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0bTq71YqG6WmlW9HTmTvg37b6w8+ZR3HjgH4EKmisoM=; b=x6WjrkQxzhGA4On78jfEugeW8pk87F7E6wzV2S3/NgruCX32r9f+2ufWujoywtvp5l 8jiciM8wzv7pitOlGq0HRKDtGJjm1rytdeqHIlFXkvu1sKmDMDDgfugsxtOzsv6Ru0BI 1hi8uJuDnNqh4h8pQLDGl3AyuWvF2Ak/N0vDmtUFrOa+tKggYZUi054H9gQ+uFSTO2SY SA/OKuFpc69Z5VKDwbE2kwJrcBjNJs0hk5+dzV8nrhVWpQ/hzm5gre+47WpaQ+Evtz9+ qYhm7hbOrS0ZSAX7HIQT8Nw1KnwNG2dCj+6+fYhXDK8dsGiwUVWFAPNstjrzLQ/Sk7Q2 C4jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0bTq71YqG6WmlW9HTmTvg37b6w8+ZR3HjgH4EKmisoM=; b=gK7xX2BX+dqtsjsJHW3fzdEuM6aHVCT/YxLTYjo/A2IO7RLK4zVl/l7EEkATdvP2NC tEbA7bxAw66QqAgKl6hn59Hw4INNL8aym3lCZ/5ljWPojvxHh13YbYekMM+xd7cD4rwu cpzBUfsT/lOkSV1r6LRKllLNrfSdvXMn+eN4KMcNfVzNhgm/fqtNRx/ZlJTQ+wbFveH3 mut0xwc9QgoBVBohYI/1ZNqLeKfLqYp8jh+uY/inV7OCkg/UfT6NXXzTLzDkWZA9ZwFt ysMjny7jxZTkzHJvzyi5OHyXv8sALbo7uAEHzGip6p+1/jSPi69hkxo9h5wEyiZfzWPp kq8A==
X-Gm-Message-State: ACrzQf07/QwGrirX7rVmpBUh+/B8huWlEtos807gKPkgb9vRABGeKa5S i9DqfsvTeod5Q4ZydhdLxrtRuo0NQrkaizpVmS5DVA==
X-Google-Smtp-Source: AMsMyM76o7N1/buBHbVadYvL59s1a94ktpCV14CxHPgmQXlVOINyO83MJaTcVojx/RP5BoniFU7X1sHI/9GR19yZMDM=
X-Received: by 2002:a67:d701:0:b0:3a7:180c:5154 with SMTP id p1-20020a67d701000000b003a7180c5154mr10727215vsj.9.1665463766119; Mon, 10 Oct 2022 21:49:26 -0700 (PDT)
MIME-Version: 1.0
References: <166544104074.23839.1857148456549380843@ietfa.amsl.com>
In-Reply-To: <166544104074.23839.1857148456549380843@ietfa.amsl.com>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Tue, 11 Oct 2022 10:18:50 +0530
Message-ID: <CAP7zK5bYjjMx4oYM36nUb_HQy8_wYFwDxgjjAOtdSsMy9vNxcg@mail.gmail.com>
To: Shivan Sahib <shivankaulsahib@gmail.com>
Cc: secdir@ietf.org, draft-ietf-pce-lsp-extended-flags.all@ietf.org, last-call@ietf.org, pce@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002a8bc205eabb00bc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/5Srw9JslE2mOGj6Xznyy09Y-wmg>
Subject: Re: [Last-Call] Secdir last call review of draft-ietf-pce-lsp-extended-flags-05
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Oct 2022 04:49:32 -0000

Hi Shivan,

Thanks for your review! Document Shepherd here...

On Tue, Oct 11, 2022 at 4:00 AM Shivan Sahib via Datatracker <
noreply@ietf.org> wrote:

> Reviewer: Shivan Sahib
> Review result: Has Nits
>
> I have reviewed this document as part of the security directorate's
> ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the  security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
>
> The summary of the review is Ready with nits.
>
> ---
>
> 1. Section 4 (Advice for Specification of New Flags) seems sparse. There
> are a
> number of security considerations that apply to LCP extensions (for e.g.
> https://www.rfc-editor.org/rfc/rfc8231.html#section-10). It would be
> helpful
> for this document to mention that there are security considerations
> related to
> adding new flags that might interact with existing extensions. It would
> also be
> especially helpful for this document's Security Considerations to
> summarize the
> security-critical aspects of existing flags so as to help future flag
> developers make secure choices.
>
>
I proposed a sentence in the security consideration (see below)

I am not sure what you have in mind related to security consideration
interaction between new and existing flags.

A sentence like this can be added but I am not sure how helpful that is -

"They are also expected to discuss any security implications of the
additional flags (if any) and their interactions with existing flags."



> 2. The Security Considerations section of RFC 8231 says:
>
> As a general precaution, it is RECOMMENDED that these PCEP extensions
>    only be activated on authenticated and encrypted sessions across PCEs
>    and PCCs belonging to the same administrative authority, using
>    Transport Layer Security (TLS) [PCEPS], as per the recommendations
>    and best current practices in [RFC7525].
>
> Is there any reason we can't provide similar guidance for new LSP extended
> flags
>

How about this ->

9.  Security Considerations

   [RFC8231] sets out security considerations for PCEP when used for
   communication with a stateful PCE.  This document does not change
   those considerations.  For LSP Object processing, see [RFC8231].

   The flags for the LSP object and their associated security
   considerations are specified in [RFC8231], [RFC8281], [RFC8623],
   and [I-D.ietf-pce-binding-label-sid].

   This document provides for future addition of flags in the LSP Object.
   No additional security issues are raised in this document beyond those
   that exist in the referenced documents. Note that the [RFC8231]
   recommends that the stateful PCEP extension are authenticated and
   encrypted using Transport Layer Security (TLS) [RFC8253], as per the
   recommendations and best current practices in [RFC7525].

Thoughts?

Thanks!
Dhruv