[secdir] Secdir last call review of draft-ietf-i2nsf-capability-data-model-16

Paul Wouters via Datatracker <noreply@ietf.org> Tue, 18 May 2021 20:16 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 2451D3A0889; Tue, 18 May 2021 13:16:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Paul Wouters via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-i2nsf-capability-data-model.all@ietf.org, i2nsf@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.29.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <162136896309.19274.13384213577960243417@ietfa.amsl.com>
Reply-To: Paul Wouters <paul@nohats.ca>
Date: Tue, 18 May 2021 13:16:03 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/0M2g4ku0c5cmOqQo9O3EFryzDG8>
Subject: [secdir] Secdir last call review of draft-ietf-i2nsf-capability-data-model-16
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: Tue, 18 May 2021 20:16:03 -0000

Reviewer: Paul Wouters
Review result: Has Nits

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.

The summary of the review Has Nits

The issues that  Michael Scharf raised regarding TOS have been addressed. Thank
you. I have no items that are serious issues, just some comments that you may
take into consideration for a minor update.

Nits:

The privacy section talks about a trade-off between privacy and security. But I
do not understand what trade-off is meant. The document does not seem to make
any trade-off. It just defines capabilities that can be used, some of which
might process private material. But the trade-offs of that are really at the
protocol level (like they did use TLS or IPsec or why not). I dont think
describing technical capabilities is a trade-off of security vs privacy.
Perhaps the section could talk about the discovery and/or usage of capabilities
and that those capabilities handling private information should attempt to
report their usage/findings/events underst conditions that preserve the privacy
(eg require TLS or IPsec between SG and NSF ?)

The Security section talks about layers that "can use" SSH or TLS for security.
I'm not sure why it does not say SHOULD or MUST ? I would rewrite "need to be
tightly secured and monitored" to "MUST be tightly secured, monitored and
audited".

Section 3.1 states:

    These capabilities MAY have their access control restricted by a policy;

In light of the other recommendations in the Security Section, I think this MAY
should really be a SHOULD or even MUST. Alternatively, perhaps say "Some of
these capabilities SHOULD" ?