Re: [secdir] SECDIR review of draft-ietf-pce-stateful-path-protection

Dhruv Dhody <> Tue, 03 September 2019 07:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2845E12021D; Tue, 3 Sep 2019 00:00:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y3Y6CjEPBcB4; Tue, 3 Sep 2019 00:00:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A53C1201E4; Tue, 3 Sep 2019 00:00:25 -0700 (PDT)
Received: by with SMTP id x4so33415670iog.13; Tue, 03 Sep 2019 00:00:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1xf+v81TeaD+Gg+FFVOjhg/jc2Y9NaL1OCMxJJPcNEU=; b=WM/XLBX6X6wS+c+ZkS+to3Ms/nJgw9fp1Q9xYxG0Xt/uGrmoc/QJd7yGilLXJOfq8t R7Zh+BaNk7tLbj9eQ+dqzZNHZ51PB5XWR+kO3X12VMMN7hSHWM+uf+cB9CKWlA+T8/Tl nPbyr/BuIdpVItdNHLNBfGPgj+CKz/5neT/9iOlnqib/3E1C9C6xvSv6djkZw061R4w+ q1JDmX22jOyF+gDWxC2u1ub0ZX1XSfv3k3BHFXznyj16QcdI+yt35dFZ+sJmEBkPJkKB yFuoOnYczI03TRHzGlnl4685pt7XCunjOPT53CHjdbQnPk0TyOt2ycBDIBRzv8A8TUQR pq8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1xf+v81TeaD+Gg+FFVOjhg/jc2Y9NaL1OCMxJJPcNEU=; b=MYL3L9VJD97tmTUs7x3CeI05jZDUH7d527wxiooyUCFATtCNJVeEbSaub4GoRJ4Mpf r7Q7175T8wm42dLTnbgnlB2Go/D65Ov25hHt7v+n9/RivmCLKLD9zy8Ux3RKYpCLCWkm 5oGluhcc4IU2dczZmI3bDj+n3M+z45/3MH2Hon1ZTZ+3XaHHfzBkSNmyd8aUW2J5As1s WgnvOS17DaFieyJj9ovpzAYEVso+tKPfknAr/gHxJnm/T2uKXK2D4Ozv22kTm1sthwLU Qhcwqh2mJXHBFnsyLDngFSG4og1tpTwT4bC+QoLgoIB7gcI29sPMj/MJevcNW4B3qxtl mPwg==
X-Gm-Message-State: APjAAAUDBy0MSC5aEP/4j4WIbBMpIwTZVlEnIKaZ4Abvp4JJq2OuAqxt xvbGhXcq+VVzn3YSHtpu6RvbfLwsMwXfQ8X5spw=
X-Google-Smtp-Source: APXvYqysMBsdei7s5RQyY2/2aTSFS8DO8OVAlYakAStEjFB5NFfzycuJtjEvLLGGlx8w+VCEXsdXmlje4ovItoICqF4=
X-Received: by 2002:a6b:c38f:: with SMTP id t137mr3920168iof.137.1567494024497; Tue, 03 Sep 2019 00:00:24 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Dhruv Dhody <>
Date: Tue, 3 Sep 2019 12:29:48 +0530
Message-ID: <>
To: Donald Eastlake <>
Cc: "" <>,, secdir <>,, Mahend Negi <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [secdir] SECDIR review of draft-ietf-pce-stateful-path-protection
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Sep 2019 07:00:27 -0000

Hi Donald,

Thanks for your review.

On Thu, Aug 29, 2019 at 8:21 PM Donald Eastlake <> wrote:
> I have reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG.  Document editors and WG chairs should treat these comments just like any other last call comments.
> The summary of the review is Almost Ready.
> This document specifies an extension to the stateful Path Computation Element Communication Protocol to associate two or more Label Switched Paths for the purpose of setting up path protection.
> This is not at all my area of expertise. The Security Considerations section primarily refers to the Security Considerations in existing RFCs and one draft, draft-ietf-pce-association-group (which is already in the RFC Editor queue). I think these references are pretty thorough and provide good security coverage and advice with one possible exception. Given that this document specifies a new facility, it seems likely that a few narrow sentences would be in order about the damage an adversary could cause by specifically monkeying with that new facility.

I see that authors have posted a new revision (-10) that has this sentence -

   Adding a spurious protection LSP
   to the Path Protection Association group could give false sense of
   network reliability, which leads to issues when the working LSP is
   down and the protection LSP fails as well.

Does this work for you?


> Tiny nits:
> In abstract and other places when referring to what this standards track draft does: "describes" -> "specifies" or "defines"
> Draft references draft-ietf-pce-association-diversity-08 when latest version is -09
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  1424 Pro Shop Court, Davenport, FL 33896 USA