Skip to main content

Last Call Review of draft-ietf-opsawg-l3sm-l3nm-10
review-ietf-opsawg-l3sm-l3nm-10-secdir-lc-shekh-yusef-2021-07-25-00

Request Review of draft-ietf-opsawg-l3sm-l3nm
Requested revision No specific revision (document currently at 18)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2021-08-06
Requested 2021-07-16
Authors Samier Barguil , Oscar Gonzalez de Dios , Mohamed Boucadair , Luis Angel Munoz , Alejandro Aguado
I-D last updated 2021-07-25
Completed reviews Yangdoctors Early review of -03 by Radek Krejčí (diff)
Intdir Last Call review of -08 by Ron Bonica (diff)
Yangdoctors Last Call review of -07 by Radek Krejčí (diff)
Rtgdir Last Call review of -10 by Andrew G. Malis (diff)
Opsdir Last Call review of -10 by Qin Wu (diff)
Secdir Last Call review of -10 by Rifaat Shekh-Yusef (diff)
Genart Early review of -14 by Pete Resnick (diff)
Assignment Reviewer Rifaat Shekh-Yusef
State Completed
Request Last Call review on draft-ietf-opsawg-l3sm-l3nm by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/gakUeHlyJ2hiwJIwd0xSsrAwpYE
Reviewed revision 10 (document currently at 18)
Result Has issues
Completed 2021-07-25
review-ietf-opsawg-l3sm-l3nm-10-secdir-lc-shekh-yusef-2021-07-25-00
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?