[secdir] Secdir last call review of draft-wu-l3sm-rfc8049bis-05

Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Wed, 27 September 2017 13:28 UTC

Return-Path: <rifaat.ietf@gmail.com>
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 807BE1331F6; Wed, 27 Sep 2017 06:28:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
To: secdir@ietf.org
Cc: ietf@ietf.org, draft-wu-l3sm-rfc8049bis.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.62.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150651889545.25051.18014743453686617959@ietfa.amsl.com>
Date: Wed, 27 Sep 2017 06:28:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/weEdMjPwF58ptk5yrJYfsGSt0cE>
Subject: [secdir] Secdir last call review of draft-wu-l3sm-rfc8049bis-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 27 Sep 2017 13:28:16 -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.

Summary: Ready with issues


The document defines a YANG data model that defines service configuration
elements that can be used in communication protocols between customers
and network operators. Those elements can also be used as input to
automated control and configuration applications.



Issues
======

* Section 6.9, Security

This section has an Authentication and Encryption sub-sections that apply
to the site.

As per section 6:
   "Authorization of traffic exchange is done through what we call a VPN
    policy or VPN service topology defining routing exchange rules
    between sites."

It might be useful to add an Authorization sub-section to section 6.9 to
capture that security aspect of the model.



* Section 10, Security Considerations

"..., and the server MUST authenticate client access to any protected resource."

There is a need to differentiate between authentication and authorization.
How about the following:
    "..., and the server MUST authenticate the client and authorize access
    to any protected resource."



* Section 10, Security Considerations

"The data nodes defined in the "ietf-l3vpn-svc" YANG module MUST be
carefully created, read, updated, or deleted as appropriate."

I think the above statement is too general, and need to be more specific.
I am assuming that the above statement is trying to say that the identity
of the requestor must be authenticated, and the operations on the model
must be controlled based on authorization associated with the
authenticated entity.

If that is the case, then this should be clearly spelled out.



Nits
====

* Section 6.9.2. Encryption

"A hitless key-change mechanism may be added through augmentation."
Replace "key-change" with "key-exchange"

Regards,
 Rifaat