Last Call Review of draft-ietf-i2rs-yang-l2-network-topology-13
review-ietf-i2rs-yang-l2-network-topology-13-secdir-lc-huitema-2020-06-24-00

Request Review of draft-ietf-i2rs-yang-l2-network-topology
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-06-25
Requested 2020-06-11
Authors Jie Dong, Xiugang Wei, Qin Wu, Mohamed Boucadair, Anders Liu
Draft last updated 2020-06-24
Completed reviews Rtgdir Early review of -02 by Henning Rogge (diff)
Rtgdir Early review of -04 by Henning Rogge (diff)
Yangdoctors Early review of -04 by Ladislav Lhotka (diff)
Rtgdir Last Call review of -13 by Stig Venaas (diff)
Yangdoctors Last Call review of -13 by Ladislav Lhotka (diff)
Genart Last Call review of -13 by Meral Shirazipour (diff)
Secdir Last Call review of -13 by Christian Huitema (diff)
Secdir Telechat review of -14 by Christian Huitema (diff)
Assignment Reviewer Christian Huitema
State Completed
Review review-ietf-i2rs-yang-l2-network-topology-13-secdir-lc-huitema-2020-06-24
Posted at https://mailarchive.ietf.org/arch/msg/secdir/nKqsL8jSghFG_bdEKasBvE1wNp0
Reviewed rev. 13 (document currently at 15)
Review result Has Issues
Review completed: 2020-06-24

Review
review-ietf-i2rs-yang-l2-network-topology-13-secdir-lc-huitema-2020-06-24

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 with the intent of improving security requirements and
considerations in IETF drafts.  Comments not addressed in last call may be
included in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

This document describes a Yang model for representing Link Layer topologies.
Representing such topologies is obviously useful for managing network.
The security section is focused on securing the usage of this
information for network management, but does not address potential
privacy issues.

The security considerations explain correctly how altering the link layer
information could enable attacks against the network. The proposed
remedy is access control, implemented using either SSH or TLS. This is
fine, although the discussion of TLS authorisation is a bit short. By default,
TLS verifies the identity of the server but not that of the client. RFC8040
section 2.5 specifies that "a RESTCONF server SHOULD require authentication based
on TLS client certificates. I assume that's the intent, but it might be useful
to say so.

On the other hand, the security considerations do not describe privacy
issues, and I find that problematic. The proposed information model lists
a number of sensitive data, such as for example the MAC addresses of devices.
This information can be misused. For example, applications could assess device
location fetching the MAC addresses of local gateways. Third
parties could access link local information to gather identities of devices
accessing a particular network. Such information is often protected
by privacy API in the Operating System, but accessing the Yang module over
the network might allow applications to bypass these controls.

Client authentication alone does not necessarily protect against these
privacy leaks. A classic configuration error would limit write access
to authorized users, but to allow read-only access to most users. This kind of
error would allow privacy leaks. Given the sensitive nature of MAC addresses
and other identifiers, it is useful to warn against such errors.