Subject: [homenet] Last Call Comments on draft-ietf-homenet-dncp-07

From: Margaret Cullen <[email-masked]>
Date: Mon, 20 Jul 2015 04:21:26 +0200

I support the publication of draft-ietf-homenet-dncp-07.  However, I think there are a few issues with the document that need to be fixed before it is published as an RFC, including:

(1) The document needs a reference for Merkel Trees that is sufficiently clear and well-specified to allow implementation.

(2)  RFC 6234 (US Secure Hash Algorithms) should be a normative reference in this document, not an informative one, as the SHA-256 algorithm is needed to implement the Trust-Verdict TLV described in section 8.3.3.  To reference RFC 6234 normatively, a routine down-ref will be required.

(3) Section 6.3 on Node Data Fragmentation is a bit confusing.  It states that a reason for needing fragmentation might be that a Node-Data TLV might be too large to fit in a single TLV or packet, however it then goes on to say, "Note that the maximum size of fragment also constrains the maximum size of a single TLV published by a node."  I think I understand what this section is trying to say -- that a Node-Data TLV can be broken across multiple fragments, but that none of the TLVs _within_ a fragmented Node-Data TLV will be broken across fragments.  The current text doesn't quite manage to say that, though.

(4) In section 10 (Security Considerations), the document states that "A DNCP node should therefore rate-limit its reactions to multicast packets."  I believe the "should" in this sentence should be replaced with "MUST", because if a node does not rate-limit its reactions to multicast packets, an attacker can repeatedly send a single packet that will be multiplied by the DNCP node.

Thanks for your consideration of these issues.

Margaret

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 22 Jul 2015 07:30:50 +0200

Thank you for the review.

> On 20.7.2015, at 4.21, Margaret Cullen <[email-masked]> wrote:

The term was inexact and addressed in dncp-08; it is actually a hash tree, and formally defined (in the original Merkle papers) the Merkle tree is a binary hash tree. Therefore we simply renamed it (arbitrary width) hash tree, and as there is a stand-alone section in dncp-08 already describing it's characteristics and use, and some notes on it's usage also elsewhere in e.g. overview, we hope it is sufficient without external reference as the data structure itself appears in typical compsci textbooks I believe.

(Merkle tree and hash tree are used loosely synonymously even in some of the literature though, so sigh..)

> (2)  RFC 6234 (US Secure Hash Algorithms) should be a normative reference in this document, not an informative one, as the SHA-256 algorithm is needed to implement the Trust-Verdict TLV described i…

Added in dncp-08 and to be discussed in WG today if anyone has objections.

> (3) Section 6.3 on Node Data Fragmentation is a bit confusing.  It states that a reason for needing fragmentation might be that a Node-Data TLV might be too large to fit in a single TLV or packet,…

Based on some other reviews we already removed the section altogether.

Later extensions to DNCP could define similar scheme as the one currently defined, without even breaking backwards compatibility for most part, if it seems useful. As currently there are no concrete DNCP using protocols that need it, and no implementations, just removal seemed the sane choice for now.

> (4) In section 10 (Security Considerations), the document states that "A DNCP node should therefore rate-limit its reactions to multicast packets."  I believe the "should" in this sentence should b…

Good catch, fixed in dncp-08.

Cheers,

-Markus