Subject: [core] comments on CORECONF drafts in WGLC

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Mar 2020 12:22:23 -0400

Hi, I have read:

— draft-ietf-core-yang-cbor-12
— draft-ietf-core-sid-11

I have implementation experience, and I've used these in other protocols, and
I strongly agree that they are ready for publication!

I read the COMI document some time ago, and I thought the approach was
fine.  I do not have any implementation experience, so I have no attempted to
understand the document at that level of detail.
I would have liked to use COMI directly as part of ietf-6tisch-minimal-security's
CoJP, but we would up creating a bespoke CBOR encoding, which is unfortunate.

I suggest that the COMI document include the word "CORECONF" in it's title.
  -> "CoAP Management Interface (CORECONF)"
as I think that it is the starting document that leadds to the other three
documents.  This will make it easier to find in rfc-index.txt.

The security considerations, and authorization for this system is
underspecified.  This was ultimately was killed SNMPv2, and led to a
multi-decade long failure of SNMPv3.
I suspect that this part will have a difficult time with security ADs.

I think that a stronger link to ACE, is in order, and an introspective
interface (using COMI!) into the authorization mechanism would help.
This could be new work, and I suspect that there are many in t2trg and out in
industry groups like OCF and CHIP that would like to have such a thing, but
it is a non-trivial amount of work.

I read draft-ietf-core-yang-library-01 when it was adopted.
I have *no* expertise on the YANG in this document, and I have no expertise
building network management systems that would need to this level of introspection.

As I understand it, this module provides a constrained version of
ietf-yang-library, the purpose of both is to describe which modules a device
supports.

I have no experience with introspection of devices like this, even doing
SNMPv2 going back decades: it either worked or it didn't, usually it didn't,
and one just guessed what the device supported, or read the manual.

I understand the goals here, but I'm not certain, particularly in a
constrained *network* that there is value in doing this.  I think that I'd
rather get this information from a URL provided in an RFC8520 (MUD).
I don't object to it though.

I wonder if queries against this module could be answered with static
content generated at compile time, and therefore from "ROM"?

I disagree with the Security Considerations, that knowing the list of
modules helps the attacker to the extent that it is important to provide
specific read controls on it.  Attackers already have a copy of the ROM ;-)
I would say that the entire COMI interface needs authorized read access, and
this module no more than any other module.

I think that there might be future opportunities to link some of this work to
the SUIT work, to the CoSWID work, and maybe to the RATS work.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-