Subject: [homenet] How to compute DNCP/HNCP node data?

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 27 Jun 2015 16:40:00 +0200

Markus,

I haven't gotten any smarter since yesterday, so please be patient.

DNCP uses the value H(node data) in a few places, but unless I'm missing 
something this doesn't seem to be clearly defined anywhre.  I have two 
hypotheses:

1. This value is computed by the originator, and is simply forwarded by 
other nodes in Node State TLVs without interpretation or validation.  
Therefore, the exact means of computing this hash does not need to be 
specified.

2. This value needs to be computed locally by this node, and therefore the 
"node data" has a canonical representation that's described somewhere and 
I'm too stupid to see where.

Could you please clarify?  (I hope it is (1), by the way.)

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Sat, 27 Jun 2015 17:52:57 +0200

Hi Juliusz,

The glossary for node state should iirc say that hash function and size is defined in profile e.g. hncp. Profile recommendations section in dncp recommends sha-256. HNCP itself should also mention something in dncp profile. The hash function is used for both levels of the Merkle tree i.e. also for network state hash. DNCP specifies canonical form of node data as binary sorted so it should be all defined and unambiguous. 

Cheers,

Steven

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 27 Jun 2015 18:44:28 +0200

> Profile recommendations section in dncp recommends sha-256.

Er... -06 recommends the leading 8 octets of MD-5.  Section 3.

But that's not what I'm asking about.  The question is what it is exactly 
that I'm hashing:

1. simply copy the has received from the originator, no questions asked; 
2. hash the raw data received from the originator; 
3. hash data that I've formatted from my internal data structures.

(1) is the simplest to implement, but it doesn't allow validation 
(detecting buggy or malicious peers).  (2) is pretty simple too, but it 
requires that I keep duplicate data -- one raw copy and one in my data 
structures.  (3) is more involved, since it requires defining a canonical 
form for the data (e.g. how to sort the TLVs and what to do with duplicate 
TLVs).

I'm currently doing (2).

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Sat, 27 Jun 2015 19:23:51 +0200

>Er... -06 recommends the leading 8 octets of MD-5.  Section 3.

DNCP recommends sha256 for profiles. HNCP uses what you mentioned.

>3. hash data that I've formatted from my internal data structures.

Since dncp mandates the canonical order this essentially means 2 and 3 are identical.  I personally don't believe in supporting buggy clients as in clients violating MUST statements since at some point it just breaks.

Cheers,

Steven

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 29 Jun 2015 13:34:20 +0300

> Since dncp mandates the canonical order this essentially means 2 and 3 are identical.  I personally don't believe in supporting buggy clients as in clients violating MUST statements since at some p…

Actually, I do not think it does anymore mandate _internal 
implementation_ in dncp-06 (it used to earlier). However, on the wire, 
there is canonical ordering of TLVs etc.

Anyway, [2] is correct, [3] is obviously impossible to interoperate 
with, and [1] a bad idea.

Cheers,

-Markus