[secdir] Secdir last call review of draft-ietf-opsawg-l3sm-l3nm-10

Rifaat Shekh-Yusef via Datatracker <noreply@ietf.org> Sun, 25 July 2021 20:54 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A673A0763; Sun, 25 Jul 2021 13:54:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Rifaat Shekh-Yusef via Datatracker <noreply@ietf.org>
To: <secdir@ietf.org>
Cc: draft-ietf-opsawg-l3sm-l3nm.all@ietf.org, last-call@ietf.org, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.35.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <162724649271.1477.16367299362861096101@ietfa.amsl.com>
Reply-To: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
Date: Sun, 25 Jul 2021 13:54:52 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/gakUeHlyJ2hiwJIwd0xSsrAwpYE>
Subject: [secdir] Secdir last call review of draft-ietf-opsawg-l3sm-l3nm-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Jul 2021 20:54:53 -0000

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?


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?