Last Call Review of draft-ietf-ccamp-layer1-types-16
review-ietf-ccamp-layer1-types-16-secdir-lc-huitema-2023-11-12-00

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 is 'Ready'.

draft-ietf-ccamp-layer1-types specifies a YANG module for describing the common
data types, groupings and identities for use in YANG [RFC7950] data models of
Layer 1 networks, such as for example Optical Transport Networking.

The security section asserts that potential security issues do not derived from
the particulars of the Yang modules, but from potential unauthorized access to
the data and unauthorized modification of the data. Access is expected to be
protected using either SSH for NETCONF or HTTPS for RESTCONF, as per standard
practice. I would not expect a Yang module to state anything else.

I do not have enough expertise in Optical Transport Networking and other Layer
1 networks to evaluate the details of the specification. I assume that other
reviewers will conduct such specialized review.

And now, a side remark, not related to this specific document but applying to
the general practice of saying "just use NETCONF with SSH or RESTCONF with
TLS", but SSH and HTTPS support a variety of authentication mechanisms. SSH,
for example, can authenticate a client using a public key, a password, a host
identity, or even nothing. HTTPS has a similar range of options. Some of those
options are much more vulnerable than others -- password based authentication,
for example, is vulnerable to phishing attacks and password reuse.

The NETCONF and RESTCONF specifications leave the choice of authentication to
the organization deploying the Yang based management, with statements like "the
identity of the SSH client MUST also be verified and authenticated by the SSH
server according to local policy". I did not find a specification of what the
local policy should be. It would be nice if the safety of network
infrastructure could not be defeated by a password-based attack, or other
simple attacks. It might be useful to do some work here, and provide practical
guidance on the deployment of strong authentication mechanisms.