Re: [core] comments on CORECONF drafts in WGLC

Hello Michael,

Thank you for the review and the comments! Please find my answers below
prefixed by [IP]. You can find the resulting diffs at the following link
[1].

Best regards,
Ivaylo

[1]:
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-core-comi.txt&url2=https://core-wg.github.io/comi/draft-ietf-core-comi.txt

On Mon, Mar 30, 2020 at 6:22 PM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> 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!
>

[IP]: Thank you for your reviews and helping us get them to that state!

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.
>

[IP]: That sounds indeed a good way to go forward. Unless someone objects,
I am going to apply this change with the next revision.

>
> 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.
>

[IP]: I tried to improve this section to some extent. Please let me know if
you have other ideas. Text contribution is always welcomed as well.

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.
>

[IP]: I added an informational link to ACE, which for me seems as one of
the ways authorization can be handled in COMI. Is this what you have in
mind?

> 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.
>

[IP]: Thank you for your thoughts on that one! I believe Michel Veillette
would best reply to the pros and cons of using URL in a MUD file vs this
document, but it seems to me that they would still address slightly
different use cases and probably there is value in having both supported.

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

[IP]: I would imagine so.

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.
>

[IP]: I believe the idea here is that the attacker doesn't necessarily know
which ROM the device is using. Having an easy way to discover that and from
there all the possible vulnerabilities of that device is what we want to
avoid. Otherwise I agree that the entire CoMI interface needs authorized
read access.

> 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.
>

[IP]: I strongly agree with this, but from all the different IoT security
options, I am currently not sure which ones would be best suited for CoMI
in different situations. Do you have ideas for concrete drafts and use
cases?

--
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>