[Lime] Secdir telechat review of draft-ietf-lime-yang-connectionless-oam-methods-11

Benjamin Kaduk <kaduk@mit.edu> Wed, 25 October 2017 16:32 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: secdir@ietf.org
Cc: draft-ietf-lime-yang-connectionless-oam-methods.all@ietf.org, lime@ietf.org, ietf@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150894917478.4886.16418816851585609070@ietfa.amsl.com>
Date: Wed, 25 Oct 2017 09:32:54 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lime/bx4aU_AFjlhZOKkimQjJ7MruPT0>
Subject: [Lime] Secdir telechat review of draft-ietf-lime-yang-connectionless-oam-methods-11

Reviewer: Benjamin Kaduk
Review result: Ready

This draft is basically providing a YANG model as an abstraction over existing
(connectionless OAM) functionality, perhaps with some intention of facilitating
similar functionality in new spaces.  (E.g., ICMP ping/traceroute exist, but
entries are also given for SFC, MPLS, MPLS-TP, TWAMP, BIER, and I do not expect
that all of those currently have such functionality.).

The modeled functionality is intended to be run over management protocols such
as NETCONF or RESTCONF (i.e., ssh or HTTPS), which are at least nominally
secure transports.  Though it is possible to configure either of them in an
insecure fashion, I don't feel a particular need to beat the reader over the
head with notes about actually verifying TLS certificates, etc..  The security
considerations duly mention that access control is appropriate and that some
operations may be considered sensitive or vulnerable in some environments,
which is true, and probably the most that can reasonably be said at this level
of abstraction.

I do see several appearances of an abstract "location-type" field and other
system identifiers ("identityref", "system-id", MAC/IPv4/IPv6 addresses), which
 are sometimes considered sensitive, especially when they can be associated
back to individual users, which leads to privacy considerations about user
tracking and similar.  Since this is OAM work, I don't actually know that there
are real users in scope as opposed to fixed infrastructure, but perhaps a
statement in the security considerations about privacy and this sort of
identifiers would still be useful.

The document could benefit from some general copy editing for
language/grammar/etc., but unfortunately given the short turnaround between
last call end and the telechat, I cannot provide a more detailed patch or
comments at the present time.

[Lime] Secdir telechat review of draft-ietf-lime-… Benjamin Kaduk
Re: [Lime] Secdir telechat review of draft-ietf-l… Qin Wu