Re: [secdir] Secdir last call review of draft-ietf-opsawg-l3sm-l3nm-10 Fri, 03 September 2021 08:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A9C83A1176; Fri, 3 Sep 2021 01:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B_2EzlQUyiN9; Fri, 3 Sep 2021 01:17:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 227533A1173; Fri, 3 Sep 2021 01:17:05 -0700 (PDT)
Received: from (unknown [xx.xx.xx.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by (ESMTP service) with ESMTPS id 4H19ct69s1zyr1; Fri, 3 Sep 2021 10:17:02 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1630657022; bh=Ys12//K/MsX8/dVeaaU3ZpAduJTJ3+6hX+UOG5ozGvE=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=GSb4SnDkcr2WzUffIYYGM9aSoRMBprBDewiW16aex+SBwKUwcugKpiIxU+OmcafY4 8qd8eqFLZ3pawL4ibw/kAk3Fr/PdRloLbfBiQGjWEpU0qTZc35UyuDHGg/cP0WylUe oTxl52Lfg6QjU72DqVVCt+rMaXzIklA8TWvPYa5hpGEGOzAypKCbCW19L3FvcIoT/P qJyiXzatJJIz50vuSmBULBohvuwu9LJvHfmh37CUeHqElMEWOaD4ydXIeNcLhBBtrx B2Oari/CYb4/i+qJi9SmXWO+7XBTekRjtQWclPsQYXzH/y5+UaqVK00HFHB1a+2uN4 sGCsR5Y2pw8oQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (ESMTP service) with ESMTPS id 4H19ct57KwzyQ5; Fri, 3 Sep 2021 10:17:02 +0200 (CEST)
From: <>
To: Rifaat Shekh-Yusef <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Secdir last call review of draft-ietf-opsawg-l3sm-l3nm-10
Thread-Index: AQHXgZdSwzNfaHSiC0m9Ry8G0T+4M6uSMV/Q
Date: Fri, 3 Sep 2021 08:17:01 +0000
Message-ID: <13601_1630657022_6131D9FE_13601_86_23_787AE7BB302AE849A7480A190F8B9330353E84CA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [secdir] Secdir last call review of draft-ietf-opsawg-l3sm-l3nm-10
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: Fri, 03 Sep 2021 08:17:11 -0000

Hi Rifaat, 

Thank you for the review. 

Please see inline. 


> -----Message d'origine-----
> De : Rifaat Shekh-Yusef via Datatracker []
> Envoyé : dimanche 25 juillet 2021 22:55
> À :
> Cc :;;
> Objet : Secdir last call review of draft-ietf-opsawg-l3sm-l3nm-10
> Reviewer: Rifaat Shekh-Yusef
> Review result: Has Issues
> 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.
> This document defines an L3VPN Network YANG Model (L3NM) that can be
> used for the provisioning of Layer 3 Virtual Private Network (VPN)
> services within a service provider network.  The model provides a
> network-centric view of L3VPN services.
> Issues:
> 1. The following is a quote from Security Consideration section:
>     "Several data nodes defined in the L3NM rely upon [RFC8177] for
>      authentication purposes."
> I think it would be helpful to elaborate on which nodes need the
> mechanism defined in RFC8177 and why?

[Med] 8177 is used here to ease the mapping with underlying device modules, particularly routing protocols.

Updated the text to cite the nodes. NEW:

"Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'bfd') rely upon ..."

> 2. The summary bullets:
>    o  Malicious clients attempting to delete or modify VPN services.
> Why 'create' and 'read' are not part of the risks in this case?

[Med] because 'create' is covered in the next bullet: 

   o  Unauthorized clients attempting to create/modify/delete a VPN

And 'read' in the third one: 

   o  Unauthorized clients attempting to read VPN service related

After re-reading the text to check your comment, I figured out that we don't actually need this list as it is redundant with the risks cited for both write and read nodes. The bullet list will be removed.

Your review will be ACKed in the next iteration of the document. Thank you. 



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.