Subject: [homenet] Queries on draft-ietf-homenet-hncp-02

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Nov 2014 16:14:38 +1300

Hi,

I'm doing my homework (pun intended) by trying to thoroughly
understand HNCP. At the moment I have a few naive questions:

> 3.  Data model
...
>       A unique node identifier.  It may be a public key, unique hardware
>       ID, or some other unique blob of binary data which HNCP can run a
>       hash upon to obtain a node identifier that is very likely unique
>       among the set of routers in the homenet.

This definition eats its own tail. "It [is] binary data which HNCP can...
hash to obtain a node identifier..."

If you are trying to distinguish a unique node identifier from a hashed
node identifier, I think you need to be very specific with terminology.
Actually I could not understand what this meant until I read this text:

> 4.3.  HNCP Protocol Message Processing
...
>    If this happens more than 3 times in 60 seconds and the local node
>    identifier is not globally unique, there may be more than one router
>    with the same node identifier on the network.  If there is no global
>    guarantee of unique node identifier, a new node identifier SHOULD be
>    generated and node data republished accordingly.

I *assume* that at this point, 'node identifier' means 'hashed node
identifier' and that 'unique node identifier' means 'unique hashed
node identifier.' But it's not clear to me how the node in question
knows that 'the local node identifier is not globally unique.'

Of course I have anima eyes, and I think of node IDs as being
cryptographically bound to a key pair and registered with the
trust anchor. In that case, a node ID clash would be a very big
deal, and generating a new node ID would break all dependent
trust relationships.

It would probably be better if this aspect of HNCP was well
separated. At least, make the automatic regeneration of a
node ID a configurable option, since in a network with a trust
anchor and cryptographic IDs, this will be different.

'Link Identifier' is mentioned several times before it's defined.
Once, it is spelt 'Link-Identifier' which is a bit confusing when
searching.

Then it is defined:

>       Link Identifier is the local HNCP identifier of the link the
>       prefix is assigned to.

This sentence occurs twice, but it doesn't help me because the
phrase "HNCP identifier" isn't defined. All that has been defined
is 'node identifier' and that doesn't identify an interface, let
alone a link. (I raised a related question on draft-ietf-homenet-
prefix-assignment, and I'm still unclear how HNCP determines
that multiple interfaces of a node are connected to the same
link, which would presumably have the same Link Identifier
on different interfaces.)

Assuming I know what a Link Identifier is, the phrases Neighbor
Link Identifier and Local Link Identifier are also used
without definition. It isn't obvious to me where they come from.

That's it for now. I plan to read the draft again when I've
understood these points better.

Regards
   Brian

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 26 Nov 2014 09:39:51 +0200

> understand HNCP. At the moment I have a few naive questions:

Thanks for it ;) Oddly enough, within last month, I have received similar comments from 3 sources (and nothing in the preceding year). I guess you are more careful reader (or make less assumptions) than others.

> Actually I could not understand what this meant until I read this text:

The document badly needs some sort of terminology section somewhere early on, I think. 

Node identifier = unique node identifier. It is not really used really in and of itself anywhere currently (+- public-key TLV, but currently not really implemented anywhere and going to be phased out probably in favor of leaving the asymmetric crypto details out of the protocol itself).

> knows that ‘the local node identifier is not globally unique.'

Correct.

Non-uniqueness is detected by receiving node state+data for local (hashed) node identifier that the node itself did not originate.

> deal, and generating a new node ID would break all dependent

True.

> anchor and cryptographic IDs, this will be different.

Agreed. I have had similar input from elsewhere too.

>>      Link Identifier is the local HNCP identifier of the link the

I suspect this has been victim of search-and-replace or something as it does not make even sense to me anymore.

Correct description of the link identifier would be simply locally unique, node-specific identifier for that interface on that particular node.

(Neighbor link id is just link id posted by remote node)

> on different interfaces.)

Node identifier (hash) is same on the sent packets. Therefore, it can detect it sent them itself (and potentially stop using one of the interfaces, for example, although our implementation does not do that at the moment).

> without definition. It isn’t obvious to me where they come from.

I guess local link identifier is probably an error, it could be just link identifier (as defined above).

> understood these points better.

Thanks for the review! It seems it still has some work to be done before it is readable ;)

Cheers,

-Markus

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Nov 2014 09:59:30 +0000

On 26/11/14 07:39, Markus Stenberg wrote:
> public-key TLV, but currently not really implemented anywhere and
> going to be phased out probably in favor of leaving the asymmetric
> crypto details out of the protocol itself

oooh - there's a way to get my attention:-) Is that saying that
HNCP used have some asymmetric crypto that wasn't implemented and
that's going to be cut from the spec?

If so, can you explain what/why? (To someone who's yet to read
the spec sorry, if your answer is "go read the spec" that's a
fine answer.)

Ta,
S.

---

From: Steven Barth <[email-masked]>
Date: Wed, 26 Nov 2014 11:11:47 +0100

> that's going to be cut from the spec?
It had stubs for TLVs for that matter but never a concrete 
specification. We eventually decided to drop it since (re)inventing 
assymetric crypto in-protocol would have been a nightmare to specifiy, 
implement and maintain correctly and would have easily gotten more 
complex than the state-synchronization protocol itself.

Cheers,

Steven