Subject: [secdir] Secdir telechat review of draft-ietf-lime-yang-connectionless-oam-methods-11

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 25 Oct 2017 09:32:54 -0700

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.

---

From: Qin Wu <[email-masked]>
Date: Thu, 26 Oct 2017 03:56:31 +0000

Thanks Benjamin for valuable review.
This draft is updated based on YANG security guideline:
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
Privacy issue has been considered in security section since "location-type" and other system identifiers are defined within two RPC operations.
Regarding copy editing for language/grammar issue, yes, many other raised similar issue as you said, we will fix those typo and format issue in the update. 
Thanks a lot.

-Qin
-----邮件原件-----
发件人: Benjamin Kaduk [mailto:[email-masked]] 
发送时间: 2017年10月26日 0:33
收件人: [email-masked]
抄送: [email-masked]; [email-masked]; [email-masked]
主题: 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.