[homenet] Benoit Claise's Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)

[Benoit Claise]

Benoit Claise has entered the following ballot position for
draft-ietf-homenet-dncp-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/



--
DISCUSS:
--

Other ADs focused on the protocol specific points. So let me focus on
something else.
The applicability section doesn't answer my questions: when to (re-)use
this protocol?
Note that the write-up mentioned ANIMA.

I see the protocol description:

   DNCP is designed to provide a way for each participating node to
   publish a set of TLV (Type-Length-Value) tuples, and to provide a
   shared and common view about the data published by every currently or
   recently bidirectionally reachable DNCP node in a network.

I see, under the applicability section, under which conditions to use
it.
Basically, suitable to exchange any TLV tuples, infrequently. 

However, this applicability section doesn't tell me when to re-use DNCP
(or define a profile for it).
What about the environment: home network versus LAN versus WAN? How big
can the network be?
Does the technology matter? 
Regarding transport, it's basically any transport, unicast or multicast,
right? (DNCP can be used in networks where only unicast transport is
available.  While DNCP uses the least amount of bandwidth when multicast
is utilized)
All devices in a DNCP network must be DNCP node?
I have a DNCP network with profile 1, can I use the same DNCP network
with profile 2?
IANA and enterprise specific TLVs?
UDP is fine as a transport?
What if I know my topology already (I see later: "may use multicast for
Trickle-based shared state dissemination and topology discovery") 
etc.  

Just reading the intro and the applicability, I scratched my head: it's
so generic, should I even consider it for ANIMA?

A few paragraphs, somewhere in the document, would solve my DISCUSS:
- this protocol should be used to exchange the following type of data
...
- it's envisioned that this generic state synchronization protocol will
be used in the following environments ...
- potential DNCP-based protocols include ...


--
COMMENT:
--

- I would agree with Alvaro, when he wrote: "In general, I found the text
not straight forward or easy to understand." Potentially due to the
structure.

- I hope that a document about manageability considerations (see
https://tools.ietf.org/html/rfc5706#appendix-A) will follow.

- As reported by Victor, part of his OPS DIR review:
Found In Nits:

(https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-homenet-dncp-09.txt)

- Use of lower case not with SHOULD statement (see Paragraph 2,
Section 4.5)

- Flagged spacing items (Lines 197, 252, 256 and 260)


Section 3: Overview 
   
paragraph 2: their addresses may be manually configured or they may

   be found by some other means defined in a later specification

** This text is not quite clear.  Is it the author’s intention that
the reader assume the other means will be part of a specific DNCP
profile specification, a revision of the DNCP document or a
different type of document.? ***


Section 4.2: Data Transport 

Paragraph 4 / Part “Multicast+Unicast”

  It is used to send Network State TLVs every now and

  then, as specified in Section 4.3

 It is used to send Network State TLVs
periodically, as specified in Section 4.3

  Avoids using an idiom to express sending frequency
in text.

 
Section 8.1 Pre-Shared Kay Trust Method

** Would it be within the DNCP document to discuss how PSKs are
stored (as to not be externally accessed) or would it be to the
profile to defined that level? ***


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Benoit Claise's Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)

[Markus Stenberg]

On 17.9.2015, at 12.11, Benoit Claise  wrote:
> --
> DISCUSS:
> --
> 
> Other ADs focused on the protocol specific points. So let me focus on
> something else.
> The applicability section doesn't answer my questions: when to (re-)use
> this protocol?
> Note that the write-up mentioned ANIMA.
> 
> I see the protocol description:
> 
>   DNCP is designed to provide a way for each participating node to
>   publish a set of TLV (Type-Length-Value) tuples, and to provide a
>   shared and common view about the data published by every currently or
>   recently bidirectionally reachable DNCP node in a network.
> 
> I see, under the applicability section, under which conditions to use
> it.
> Basically, suitable to exchange any TLV tuples, infrequently. 

This is the gist of it. Even more frequently is ok, but then you have extra 
complexity without gaining from it.

_That_ is what you have to determine if you want to use it; do you want to 
synchronize a small set of TLV tuples, communicating efficiently, across a set 
of nodes.

> However, this applicability section doesn't tell me when to re-use DNCP
> (or define a profile for it).
> What about the environment: home network versus LAN versus WAN? How big
> can the network be?
> Does the technology matter? 
> Regarding transport, it's basically any transport, unicast or multicast,
> right? (DNCP can be used in networks where only unicast transport is
> available.  While DNCP uses the least amount of bandwidth when multicast
> is utilized)

Guesses are correct, but given it is more of an algorithm than concrete 
protocol, your questions are hard to respond in a generic way.

> All devices in a DNCP network must be DNCP node?

It is actually definition of DNCP network ; a set of DNCP nodes.

> I have a DNCP network with profile 1, can I use the same DNCP network
> with profile 2?

If the profiles’ transport details match and use a shared IANA TLV space, then 
yes.

> IANA and enterprise specific TLVs?

I am not sure what you mean by this; ultimately actually used TLVs are matter 
of (DNCP profile specific) IANA sub-registry, which should reserve the space. 
While DNCP itself reserves some space for DNCP-specific extensions (so far 
considered fragmentation, delta synchronization, authentication/confidentiality 
of multicast traffic using PSKs, and few other things), and leaves most of 
space open (for e.g. to be used as bits later on), the rest is up to profile.

> UDP is fine as a transport?

There is another DISCUSS on this, I will reply to it there.

> What if I know my topology already (I see later: "may use multicast for
> Trickle-based shared state dissemination and topology discovery") 
> etc.  

You can define a protocol that is solely TCP unicast based, for example, and 
make it’s definition of peer liveliness depend only on the TCP connections +- 
knowledge of topology graph changing.

(This assuming you know which nodes need to communicate with each other.)

> Just reading the intro and the applicability, I scratched my head: it's
> so generic, should I even consider it for ANIMA?

Funny, I get the opposite impression reading ANIMA mailing list, as I wonder if 
it is too generic for DNCP.

E.g. what if someone wants to share a DVD image to upgrade their routers using 
the protocol? DNCP is _not_ the way. URL + hash of content, or magnet link, 
perhaps, but not the image.

> A few paragraphs, somewhere in the document, would solve my DISCUSS:
> - this protocol should be used to exchange the following type of data
> ...

See edit of first sentence of introduction in [1]. Still work in progress, but 
emphasizing that a) set of TLVs published by a node is small, and b) it has 
hard cap of 64kb.

> - it's envisioned that this generic state synchronization protocol will
> be used in the following environments …
> - potential DNCP-based protocols include …

I do not really see where to stick these or what the exact content would be;

‘anywhere you can use _a_ transport protocol’, ’to synchronize stuff (home 
automation? configuration? cache synchronization? routing? you name it, this 
can do it, although not necessarily well, and all have _already been done_ 
although not necessarily documented in the IETF)’

> --
> COMMENT:
> --
> 
> - I would agree with Alvaro, when he wrote: "In general, I found the text
> not straight forward or easy to understand." Potentially due to the
> structure.

Structure has been rewritten more than once due to various reviews too. 

> - I hope that a document about manageability considerations (see
> https://tools.ietf.org/html/rfc5706#appendix-A) will follow.

Hm, I see value of having one for particular DNCP-based protocols but not 
really DNCP 

[homenet] Stephen Farrell's No Objection on draft-ietf-homenet-dncp-09: (with COMMENT)

[Stephen Farrell]

Stephen Farrell has entered the following ballot position for
draft-ietf-homenet-dncp-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/



--
COMMENT:
--


- 8.3 generally: I think this could be the basis for something
quite good but that'll only become clear really (to me) when I
go over it in a real protocol and not in the abstract. I'd
also speculate that you might end up changing this if it gets
more security review, but again that's hard to get in the
abstract.  Basically: be prepared for changes as this is made
concrete and if that would be a problem please yell now.  If
you do yell, I'm fine with making this a DISCUSS so we're sure
to resolve it. (I nearly did make this a DISCUSS, as I'm not
sure this is all fully worked out, but I'm ok that we can fix
that later. And you have enough DISCUSS ballots;-)

- The write up notes various drafts were input to what became
this one. I assume that none of those had associated IPR that
hasn't trickled through to being noted as applying to this
one? If not, as I expect, that's fine, no response is needed,
I'm just noting this since I didn't see any "replaced by"
entries in the history and it's those that cause IPR to be
transitively visible.

- section 2 - it's not clear to me why all node identifiers
need to be the same length - some protocols using DNCP could I
guess have variable length identifiers. IPv4 and IPv6 and
Ethernet for example all have different lengths.

- 4.2: seems to contradict itself. 1st para says that MC is
not used for anything sensitive, but 2nd-last para of section
says that network state TLVs can be sent "now and then."
(Reason to ask is that (D)TLS won't work if sensitive data is
sent via MC.)

- 4.4, 2nd para: what is a "valid" address? 

- 8.1: do you mean one PSK per network or per pair of nodes?
Better to say. I assume it's the former.

- 8.3: This is an example of (a fairly complex) use of
opportunistic security (RFC7435). Be good to note that.

- 8.3: Calling this "certificate based" is I think a misnomer.
I suspect all the same things could be done with raw public
keys (RFC 7250).

- 8.3: please do note that a concrete protocol might need
changes to this distributed algorithm and that this section is
guidance and not to be considered entirely fixed (when
coding).


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Spencer Dawkins' Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS)

[Markus Stenberg]

On 16.9.2015, at 23.09, Spencer Dawkins at IETF  
wrote:
> Do you think we should insert some sort of disclaimer there about the default 
> value to avoid potential misdesign?
> 
> I haven't seen people tripping over using TCP keep-alives and assuming they'd 
> be more responsive than they are lately, but I have seen that happen a bunch 
> of times in my life ...
> 
> If you think making a text change would be helpful, I'd suggest simply 
> removing the reference to "or TCP keep-alive". If any other way of detecting 
> liveness is available, it’s probably faster than two hours, so TCP 
> keep-alives would likely be a last-ditch defense in any case.

I (slightly) prefer including the second example especially as it is the 
traffic/implementation minimizing option (given TCP transport). So I think I 
will leave it there.

Only case where it really hits the TCP k-a interval anyway is if _nothing_ in 
the DNCP network changes during the k-a interval, otherwise the connection 
would hit the (potentially tuned) RFC1122’s R2 anyway. That would guarantee 
dropping of connections that seem not to propagate fresh state change 
correctly. In my experience, I have yet to encounter a DNCP use case (and I 
have seen so far 4 distinct ones) where that 2 hour limit would be really 
encountered anyway => ’something else’ would take care of it faster than the 
TCP k-a if the network is really functioning, and if not, k-a would sort it out 
‘eventually’ for e.g. a lone node that gets network partitioned away from other 
nodes.

Cheers,

-Markus

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Stephen Farrell's No Objection on draft-ietf-homenet-dncp-09: (with COMMENT)

[Stephen Farrell]

Hiya,

On 17/09/15 16:00, Steven Barth wrote:
> Hello Stephen,
> 
> thanks for your review.
> Please find some comments below.
> 
> 
> Cheers,
> 
> Steven
> 
> 
>> --
>> COMMENT:
>> --
>> - 8.3 generally: I think this could be the basis for something
>> quite good but that'll only become clear really (to me) when I
>> go over it in a real protocol and not in the abstract. I'd
>> also speculate that you might end up changing this if it gets
>> more security review, but again that's hard to get in the
>> abstract.  Basically: be prepared for changes as this is made
>> concrete
> 
> Understood, the intention is to potentially have something better
> suited than PSKs or PKIs for cases like bootstrapping a (mostly)
> unmanaged home network. We are aware that this is probably a
> first slab at such an approach and might benefit from a few more
> eyes and practical experience.
> 
> In any case, it is not substantial to the document and we would
> rather remove it if it would become a blocker.

As long as we're flexible with it, it's not a blocker. And
as I said I think it's good, but it may need tweaks as we
finish the concrete protocol that uses it.

All the rest below is fine but sorry I don't have a catchy
better name for 8.3 to hand. (And I don't care about the
name so much as e.g. considering RFC7250 which may fit
better here, as one wouldn't need a CA.)

S

> 
> 
>> - The write up notes various drafts were input to what became
>> this one. I assume that none of those had associated IPR that
>> hasn't trickled through to being noted as applying to this
>> one? If not, as I expect, that's fine, no response is needed,
>> I'm just noting this since I didn't see any "replaced by"
>> entries in the history and it's those that cause IPR to be
>> transitively visible.
> We are not aware of any IPR associated with those drafts, at
> least to my knowledge none was declared in the IETF IPR search.
> 
> 
>> - section 2 - it's not clear to me why all node identifiers
>> need to be the same length - some protocols using DNCP could I
>> guess have variable length identifiers. IPv4 and IPv6 and
>> Ethernet for example all have different lengths.
> Well, theoretically this is probably not a hard requirement,
> however the way we currently define our TLVs a variable length
> identifier here would require changing the TLVs to include a
> length field for it in some cases. I do not really see the big
> benefit of allowing this here so we will probably rather leave
> it as is.
> 
> 
>> - 4.2: seems to contradict itself. 1st para says that MC is
>> not used for anything sensitive, but 2nd-last para of section
>> says that network state TLVs can be sent "now and then."
>> (Reason to ask is that (D)TLS won't work if sensitive data is
>> sent via MC.)
> We do not consider the Network State TLV to be sensitive,
> since it is a merely a single hash-value over other hashes and
> a bit of metadata (see "Hash Tree"). The only reaction to the
> reception of a Network State TLV is triggering a unicast
> request to the originator (which whould then be authenticated
> and encrypted) using (D)TLS. We noted this in the Security
> Considerations already in the first paragraph and mandate
> rate-limitation of thereby triggered requests.
> 
> 
>> - 4.4, 2nd para: what is a "valid" address?
> A profile might e.g. restrict the transport to link-local scoped
> addresses or make other similar assumptions. I guess we will
> add a an example in -10.
> 
> 
>> - 8.1: do you mean one PSK per network or per pair of nodes?
>> Better to say. I assume it's the former.
> Well technically it could be either but in practice I'd think we'd
> assume it to be the former since latter is a bit impractical.
> 
> 
>> - 8.3: This is an example of (a fairly complex) use of
>> opportunistic security (RFC7435). Be good to note that.
> Staged for -10.
> 
>>
>> - 8.3: Calling this "certificate based" is I think a misnomer.
>> I suspect all the same things could be done with raw public
>> keys (RFC 7250).
> 
> Well most of it can, however there is one bit that somehow utilizes
> certificates:
> 
>A node MUST be
>trusted for participating in the DNCP network if and only if the
>current effective trust verdict for its own certificate or any one in
>its certificate hierarchy is (Cached or Configured) Trust and none of
>the certificates in its hierarchy have an effective trust verdict of
>(Cached or Configured) Distrust
> 
> In any case it could get a different name, do you have a fitting idea?
> 
> 
>> - 8.3: please do note that a concrete protocol might need
>> changes to this distributed algorithm and that this section is
>> guidance and not to be considered entirely fixed (when
>> coding).
> 
> Staged for -10.
> 

___
homenet mailing list
homenet@ietf.org

Re: [homenet] Brian Haberman's Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)

[Markus Stenberg]

On 16.9.2015, at 18.39, Brian Haberman  wrote:
 A_NC_I calculation does not depend on how you synchronize things 
 (full state dump <> delta). It is mostly about value <> cost of 
 having Trickle, as opposed to fixed timers.
 
 What would you propose then?
>>> My proposal is based on the observation that the design decisions
>>> made appear to be really grounded in simplicity of implementation.
>>> And, to me, that is perfectly fine.  I think the discussion of
>>> justification in the Applicability section should simply focus on
>>> that simplicity and not theoretical arguments about relationships
>>> between various variables.  If this were a full-blown protocol
>>> specification (e.g., an actual profile spec), I would expect more
>>> focused justification.
>> Hmm. T. Clausen review told us that we should essentially describe
>> what this is good for; that calculation explains where it is
>> applicable. We got push-back from some other reviewers where we used
>> less exact terms like ’small to medium sized networks of nodes with
>> low amount of change’ in some iteration of the document (’small’?
>> ‘medium’? ‘low’?). We even got asked for explicitly writing out
>> intervals to the introduction of an abstract protocol earlier..
> So, this may turn into more of an IESG-based discussion.  Given the
> generalities introduced by this "abstract protocol specification", I
> think it will be useful for the IESG to work this out.

Ok, looking forward to what you guys tell us to do about it :)

>> ’simple to implement’ (or ’not complex to implement’) could be added
>> there to the delta part though.
> IMO, it wouldn’t hurt.

Added in [1] (and simplified the text bit, I think saying that there is no 
delta transmission scheme makes it obvious that you have to send the whole 
thing).

> I am not sure how that helps in this case.  What you want, I think, is
> to explicitly state that profiles of DNCP could specify exchanges that
> carry sensitive information and confidentiality is needed.  Section 4.2
> is focused more on the underlying transport protocol (TCP vs. UDP) and
> the nebulous "security" term.  The driver here should be whether
> authentication, integrity protection, confidentiality, or authorization
> is needed.  Perhaps that would make sense in Section 9.

As currently specified, there isn’t really half-way choice in the spec (e.g. no 
confidentiality); if you go for ‘insecure’, you get none, and if not, you are 
essentially forced to integrity protection+confidentiality  and your choice of 
authentication+authorization (section 8). 

Everything within node data is already covered by default (adding explicit 
statement to that effect in [1]) given adherence of the secure <> not-secure 
specification (notably, reception ignores Node State TLVs received via 
multicast), but it is true that if a DNCP profile specifies TLVs that are sent 
outside node data a security policy must be stated for them as well.

>>> * When responding to a multicast request over a
>>> multi-access medium, why is the randomization of the
>>> transmit time only a SHOULD?  I would think that needs to
>>> be a MUST.
>> I think this more or less depends on the type of link and
>> its characteristics and the current state, so I'm not sure if
>> a MUST is necessary in all cases.
> Multicast-based implosion is a problem.  If implementations
> ignore the SHOULD, you run a very real risk of overloading the
> request sender with unicast responses.  If the WG is not
> willing to make this a MUST, the spec should clearly spell out
> the potential of amplification attacks using this protocol.
 
 I am not sure what you mean by this, as I cannot really see it;
 in _some applications_ on _some links_ perhaps, with bad
 implementations _without rate limiting_ (that is stated that is
 acceptable for about anything in the message processing flow).
 
 As specified, the _only_ multicast TLV that MUST be responded is
 the Network State TLV, and those replies MUST be rate limited
 already.
>>> 
>>> I don't think that is true based on this statement in the draft:
>>> 
>>> However, an implementation MUST eventually reply to similar
>>> repeated requests, as otherwise state synchronization breaks.
>>> 
>>> Does that not apply to any TLV sent via multicast?
>> 
>> Depends on profile (see section 9).
>> 
>> I wonder how this should be rephrased to make it more clear; as what
>> DNCP spec _says_ essentially that only mandatory to send/receive
>> multicast TLV is the Network State TLV (+ associated Node Endpoint
>> TLV), and everything else comes from the unicast reply sequences
>> stemming from there.
> I think that the MUST clause I quoted above from 4.4 needs to be put in
> context with what is stated in section 9.

Hm, true. Updated in [1] (also changed the ‘eventually’ to the meaning I meant, 
that is, non-zero probability but 

Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)

[Kathleen Moriarty]

Thanks, Markus.  inline.

On Thu, Sep 17, 2015 at 11:53 AM, Markus Stenberg
 wrote:
> On 16.9.2015, at 22.46, Kathleen Moriarty  
> wrote:
>> I just have one thing I'd like to discuss that should be easy enough to
>> resolve.
>>
>> Section 8 mentions that DTLS or TLS MAY be used and that it is up to the
>> DNCP profile.  I'd be interested to see the security considerations that
>> would lead to a recommendation of using session transport for the DNCP
>> profiles.  If it is in another RFC, could you add a pointer?  If it is
>> not, could this be added to the security considerations section since it
>> could be an important consideration?
>
> Thanks for the comment.
>
> I am actually planning to write one more appendix to the text for -10; it 
> will contain datagram(=e.g. UDP) <> stream(=e.g. TCP) pros and cons as I have 
> been thinking about it every now and then, and I think it would make life of 
> someone else defining a DNCP-based protocol bit easier.
>
> From the security standpoint, there isn’t much of a difference, as the 
> TLS/DTLS state is more or less same for both cases. You will anyway need 
> either up to date sessions (TLS(+DTLS)) and-or long lived session caching 
> (DTLS(+TLS)), as you cannot afford too many new sessions that actually 
> involve the authz step per given time interval. So essentially even DTLS is 
> session-based transport in this case from my point of view.
>
> The rest, I will write it tomorrow and you (and Brian H. who also raised 
> interest on the different transport options) can check it once we publish -10 
> if it matches the requirements; we plan to publish -10 either tomorrow or on 
> Monday.

Great, if you could put a couple of lines in the security
considerations section as general guidance, I think that would be very
helpful.  I'm taking tomorrow off (and the rest of today), so Monday
is fine for me.

Thanks,
Kathleen

>
>> --
>> COMMENT:
>> --
>>
>> Thanks for your detailed work on this draft to provide all of the
>> security related options in section 8.
>
> Thanks ;) Section 8.3 is actually somewhat novel I think, the others 
> (8.1/8.2) are relatively .. mundane.
>
> Cheers,
>
> -Markus



-- 

Best regards,
Kathleen

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Benoit Claise's Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)

[Benoit Claise]

Markus,

Instead of focusing on the specific questions/answers, the key message is.
The applicability section doesn't answer my questions: when to (re-)use 
this protocol?


Regards, Benoit

On 17.9.2015, at 12.11, Benoit Claise  wrote:

--
DISCUSS:
--

Other ADs focused on the protocol specific points. So let me focus on
something else.
The applicability section doesn't answer my questions: when to (re-)use
this protocol?
Note that the write-up mentioned ANIMA.

I see the protocol description:

   DNCP is designed to provide a way for each participating node to
   publish a set of TLV (Type-Length-Value) tuples, and to provide a
   shared and common view about the data published by every currently or
   recently bidirectionally reachable DNCP node in a network.

I see, under the applicability section, under which conditions to use
it.
Basically, suitable to exchange any TLV tuples, infrequently.

This is the gist of it. Even more frequently is ok, but then you have extra 
complexity without gaining from it.

_That_ is what you have to determine if you want to use it; do you want to 
synchronize a small set of TLV tuples, communicating efficiently, across a set 
of nodes.


However, this applicability section doesn't tell me when to re-use DNCP
(or define a profile for it).
What about the environment: home network versus LAN versus WAN? How big
can the network be?
Does the technology matter?
Regarding transport, it's basically any transport, unicast or multicast,
right? (DNCP can be used in networks where only unicast transport is
available.  While DNCP uses the least amount of bandwidth when multicast
is utilized)

Guesses are correct, but given it is more of an algorithm than concrete 
protocol, your questions are hard to respond in a generic way.


All devices in a DNCP network must be DNCP node?

It is actually definition of DNCP network ; a set of DNCP nodes.


I have a DNCP network with profile 1, can I use the same DNCP network
with profile 2?

If the profiles’ transport details match and use a shared IANA TLV space, then 
yes.


IANA and enterprise specific TLVs?

I am not sure what you mean by this; ultimately actually used TLVs are matter 
of (DNCP profile specific) IANA sub-registry, which should reserve the space. 
While DNCP itself reserves some space for DNCP-specific extensions (so far 
considered fragmentation, delta synchronization, authentication/confidentiality 
of multicast traffic using PSKs, and few other things), and leaves most of 
space open (for e.g. to be used as bits later on), the rest is up to profile.


UDP is fine as a transport?

There is another DISCUSS on this, I will reply to it there.


What if I know my topology already (I see later: "may use multicast for
Trickle-based shared state dissemination and topology discovery")
etc.

You can define a protocol that is solely TCP unicast based, for example, and 
make it’s definition of peer liveliness depend only on the TCP connections +- 
knowledge of topology graph changing.

(This assuming you know which nodes need to communicate with each other.)


Just reading the intro and the applicability, I scratched my head: it's
so generic, should I even consider it for ANIMA?

Funny, I get the opposite impression reading ANIMA mailing list, as I wonder if 
it is too generic for DNCP.

E.g. what if someone wants to share a DVD image to upgrade their routers using 
the protocol? DNCP is _not_ the way. URL + hash of content, or magnet link, 
perhaps, but not the image.


A few paragraphs, somewhere in the document, would solve my DISCUSS:
- this protocol should be used to exchange the following type of data
...

See edit of first sentence of introduction in [1]. Still work in progress, but 
emphasizing that a) set of TLVs published by a node is small, and b) it has 
hard cap of 64kb.


- it's envisioned that this generic state synchronization protocol will
be used in the following environments …
- potential DNCP-based protocols include …

I do not really see where to stick these or what the exact content would be;

‘anywhere you can use _a_ transport protocol’, ’to synchronize stuff (home 
automation? configuration? cache synchronization? routing? you name it, this 
can do it, although not necessarily well, and all have _already been done_ 
although not necessarily documented in the IETF)’


--
COMMENT:
--

- I would agree with Alvaro, when he wrote: "In general, I found the text
not straight forward or easy to understand." Potentially due to the
structure.

Structure has been rewritten more than once due to various reviews too.


- I hope that a document about manageability considerations (see
https://tools.ietf.org/html/rfc5706#appendix-A) will 

[homenet] Spencer Dawkins' No Objection on draft-ietf-homenet-dncp-09: (with COMMENT)

[Spencer Dawkins]

Spencer Dawkins has entered the following ballot position for
draft-ietf-homenet-dncp-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/



--
COMMENT:
--

Thanks for talking through my Discuss, which was 

This should be an easy Discuss to ... discuss ...

I'm looking at this text:

   If keep-alives specified in Section 6.1 are NOT sent by the peer
   (either the DNCP profile does not specify the use of keep-alives or
   the particular peer chooses not to send keep-alives), some other
   existing local transport-specific means (such as Ethernet carrier-
   detection or TCP keep-alive) MUST be used to ensure its presence.
   
and wondering if using TCP keep-alive for liveness detection is realistic
in the use cases this specification is expecting to address. 

Unless I missed something, the default TCP keep-alive interval is still
two hours (that's been true since RFC 1122, and also true in the
relatively recent version of Linux I'm using). If that's OK, I'll clear.

If you're assuming a keep-alive interval that's shorter, lots of
implementations allow you to tune this, but it seems like the
specification should say something about that.

Given that the other example of "transport-specific means" is Ethernet
carrier-detection, which would be orders of magnitude faster, I thought I
should ask.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Alia Atlas' Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)

[Steven Barth]

Hello Alia,


please find replies inline.


Cheers,

Steven & Markus


> --
> DISCUSS:
> --
>
> First,  I have a number of specific comments.   Some of these are hazards
> to technical interoperability; I've tried
> to include those in my discuss - but the general point is that it is very
> hard to tell a number of details because the
> structure is assumed.   Having read this document, I do not think that I
> could properly implement DNCP from scratch.

Please note that an independent DNCP (or more specifically an HNCP)
implementation has been successfully developed based on
an earlier version of this draft and has been shown to be
interoperable with the reference implementation of the draft authors.
We used the implementer’s feedback afterwards to further refine the draft
to avoid possible ambiguities.


> a) What is a topology graph?  When is it created, modified, or destroyed?
>  Is it a conceptual artifact constructed
> from the various TLVs?  I think a quick paragraph describing it would
> help.

The term “topology graph” is defined in the Terminology Section and based
on bidirectional peer reachability which is defined right afterwards. In the
latter definition it is mentioned that the process is solely based on published
TLVs so the topology graph is to my understanding already unambiguously
defined. It is solely up to the implementer if this is implemented as an actual
graph or not, as long as the outcome is consistent with what is described.

If you still think it is ambiguous please provide some ideas on how this
could be worded better.


> b) How are peer relationships discovered and established and destroyed?
> I really can't tell from the draft and even a quick scan of
> RFC 6206 doesn't give any hints.

This is explained in section “4.5 Adding and Removing Peers”. As for
methods for discovery, this is actually mentioned multiple times across
the document, e.g. in the second paragraph of the Overview or in the
terminology.

Could you please be more specific on what exactly is unclear here in your
opinion?


> c) It looks like the TLVs are sent one after another in a datagram or
> stream across a socket.  The closest I see to any detail
> is "TLVs are sent across the transport as is".

Section “4.2 Data Transport” says
   TLVs are sent across the transport as is, and they SHOULD be sent
   together where, e.g., MTU considerations do not recommend sending
   them in multiple batches.  TLVs in general are handled individually
   and statelessly, with one exception …

Could you please be more specific on what is unclear?

The section states that TLV handling is stateless except for the one exception
which is explained, so otherwise  it does not really matter in what order
they are sent or how you split them up onto datagrams (if that is your
transport).


> d) As far as I can tell, Trickle is used to decide basically how often to
> send information - but the details of this and the interactions
> aren't clear to me.

This is explained in detail in section “4.3.  Trickle-Driven Status Updates”.

   The Trickle state for all Trickle instances is considered
   inconsistent and reset if and only if the locally calculated network
   state hash changes.  This occurs either due to a change in the local
   node's own node data, or due to receipt of more recent data from
   another node.  A node MUST NOT reset its Trickle state merely based
   on receiving a Network State TLV (Section 7.2.2) with a network state
   hash which is different from its locally calculated one.

   Every time a particular Trickle instance indicates that an update
   should be sent, the node MUST send a Network State TLV…

Could you please be more specific on what is missing here?


> I suspect that there are dependencies on the HNCP draft that would make
> this a lot easier to understand but since we want it to progress
> separately, the document does need to stand alone.

No, there are no dependencies. This was noted already in response to
reviews from Thomas Claussen and Les Ginsberg.

Please refer to section “9.  DNCP Profile-Specific Definitions“ for the
comprehensive list of things we have intentionally left out in DNCP.


> 8) In Sec 4.6 "   o  The origination time (in milliseconds) of R's node
> data is greater
>   than current time in - 2^32 + 2^15."  Since origination time hasn't
> yet been introduced, I'm going
> on an assumption that it means when R's node data was originated from R.
> So - this requirement is
> saying that R's node data must have been generated in the future (but
> already known by the local node)???

The term “origination time” is actually explained in Section “5. Data Model”,
-10 will have a forward-reference here. About the time itself,
the text says greater than “current time - 2^32+2^15”; that threshold is always
in the past.


> 9) In Sec 4.6 "They MAY be 

Re: [homenet] Stephen Farrell's No Objection on draft-ietf-homenet-dncp-09: (with COMMENT)

[Steven Barth]

Hello Stephen,

thanks for your review.
Please find some comments below.


Cheers,

Steven


> --
> COMMENT:
> --
> - 8.3 generally: I think this could be the basis for something
> quite good but that'll only become clear really (to me) when I
> go over it in a real protocol and not in the abstract. I'd
> also speculate that you might end up changing this if it gets
> more security review, but again that's hard to get in the
> abstract.  Basically: be prepared for changes as this is made
> concrete

Understood, the intention is to potentially have something better
suited than PSKs or PKIs for cases like bootstrapping a (mostly)
unmanaged home network. We are aware that this is probably a
first slab at such an approach and might benefit from a few more
eyes and practical experience.

In any case, it is not substantial to the document and we would
rather remove it if it would become a blocker.


> - The write up notes various drafts were input to what became
> this one. I assume that none of those had associated IPR that
> hasn't trickled through to being noted as applying to this
> one? If not, as I expect, that's fine, no response is needed,
> I'm just noting this since I didn't see any "replaced by"
> entries in the history and it's those that cause IPR to be
> transitively visible.
We are not aware of any IPR associated with those drafts, at
least to my knowledge none was declared in the IETF IPR search.


> - section 2 - it's not clear to me why all node identifiers
> need to be the same length - some protocols using DNCP could I
> guess have variable length identifiers. IPv4 and IPv6 and
> Ethernet for example all have different lengths.
Well, theoretically this is probably not a hard requirement,
however the way we currently define our TLVs a variable length
identifier here would require changing the TLVs to include a
length field for it in some cases. I do not really see the big
benefit of allowing this here so we will probably rather leave
it as is.


> - 4.2: seems to contradict itself. 1st para says that MC is
> not used for anything sensitive, but 2nd-last para of section
> says that network state TLVs can be sent "now and then."
> (Reason to ask is that (D)TLS won't work if sensitive data is
> sent via MC.)
We do not consider the Network State TLV to be sensitive,
since it is a merely a single hash-value over other hashes and
a bit of metadata (see "Hash Tree"). The only reaction to the
reception of a Network State TLV is triggering a unicast
request to the originator (which whould then be authenticated
and encrypted) using (D)TLS. We noted this in the Security
Considerations already in the first paragraph and mandate
rate-limitation of thereby triggered requests.


> - 4.4, 2nd para: what is a "valid" address?
A profile might e.g. restrict the transport to link-local scoped
addresses or make other similar assumptions. I guess we will
add a an example in -10.


> - 8.1: do you mean one PSK per network or per pair of nodes?
> Better to say. I assume it's the former.
Well technically it could be either but in practice I'd think we'd
assume it to be the former since latter is a bit impractical.


> - 8.3: This is an example of (a fairly complex) use of
> opportunistic security (RFC7435). Be good to note that.
Staged for -10.

> 
> - 8.3: Calling this "certificate based" is I think a misnomer.
> I suspect all the same things could be done with raw public
> keys (RFC 7250).

Well most of it can, however there is one bit that somehow utilizes
certificates:

   A node MUST be
   trusted for participating in the DNCP network if and only if the
   current effective trust verdict for its own certificate or any one in
   its certificate hierarchy is (Cached or Configured) Trust and none of
   the certificates in its hierarchy have an effective trust verdict of
   (Cached or Configured) Distrust

In any case it could get a different name, do you have a fitting idea?


> - 8.3: please do note that a concrete protocol might need
> changes to this distributed algorithm and that this section is
> guidance and not to be considered entirely fixed (when
> coding).

Staged for -10.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Benoit Claise's Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)

[Markus Stenberg]

> On 17.9.2015, at 19.22, Benoit Claise  wrote:
> Instead of focusing on the specific questions/answers, the key message is.
> The applicability section doesn’t answer my questions: when to (re-)use this 
> protocol?

I still rephrase my previous answer - the one sentence that summarizes (what 
intro + applicability statement detain more detail) is: do you want to 
synchronize a small set of TLV tuples that changes relatively infrequently 
across a set of nodes, or not.

To expand it somewhat, most ‘application’ protocols can be more or less modeled 
as client-server (potentially hierarchical - hello DHCP), or distributed state 
sharing (e.g. link-state routing protocols, Pierre’s recent prefix assignment 
RFC). DNCP-profile defined TLV _transport_ can be used for either (it would be 
trivial to e.g. encapsulate DHCPv6 if you felt like it, not like it were a good 
idea). DNCP _state synchronization_ is just for the latter, and optimized for 
the case noted above.

I still do not know what to do about the text though.

Cheers,

-Markus
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] IS-IS metric mechanism and implementation (was Re: Info about IS-IS demo from Bits N Bites Prague)

[Mikael Abrahamsson]

Hi,

I just want to change the subject of this so that people who are 
interested in this topic doesn't miss it.


On Thu, 17 Sep 2015, Christian Franke wrote:


Hello all,

since there have been some inquiries about different aspects of the demo
that NetDEF showed at the bits N bites in Prague, I decided to provide a
more detailed description here on the list.

We showed a home network running HNCP and two different implementations
of IS-IS interoperating with each other, at the high level the demo showed:

- IS-IS for Homenet (IPv6 & IPv4)
- Transport: both L2 & IPv6 (Link-Local)
- Point-to-Multi-Point or Broadcast over L2 or IPv6
- Dynamic IS-IS Route Metric updating based on WiFi QualityInfo about
IS-IS demo from Bits N Bites Prague
- HNCP IPv6 Prefix Delegation
- SRC / DEST Routing
- IS-IS Auto-Configuration

Both code bases implemented the following extensions on top of standard
IS-IS:

- draft-franke-isis-over-ipv6
- draft-baker-ipv6-isis-dst-src-routing
- draft-lamparter-isis-p2mp
- draft-franke-isis-over-ipv6
- dynamic metric support (see below)

For more information for the first four bullet points, please refer to
the drafts.

There is currently no draft on the dynamic metric support, since this
feature does not change the IS-IS protocol. Therefore, a short
description is following.

For the dynamic metrics support, we implemented a small daemon called
etxrd which provides metric information from the 802.11 layer. The
information is gathered using OpenWRT's libiwinfo, on our platform using
nl80211. We have a patch for libiwinfo that allows us to query the
estimated tx rate from the wifi stack, this value is suitable as a
metric for routing purposes. However that patch has not been in a
release yet, so to support running our code on the current standard
OpenWRT system, we rely on SNR as a metric for now. This provides some
information, but is suboptimal.

The daemon currently only provides metrics for the wifi side. We use a
fixed (better) metric for wired connections.

Just to clarify, that daemon is not specific to IS-IS, and it does not
need IS-IS to run. It just provides metric information about known
802.11 neighbors that can be consumed by any interested party, e.g.
other routing protocols, without requiring any modification on the
daemon side.

In our use case, IS-IS subscribes to the provided information and uses
it to adjust metrics for the neighbors. These are standard IS-IS wide
metrics, although it makes use of the per neighbor metrics available
with draft-lamparter-isis-p2mp.

Since 802.11 clients/stations only communicate with other stations via
the access point, they do only have metric information about the access
point, while the access point has information about all clients. To
address this, links without metric information (i.e. direct links
between clients) will not be considered for SPF. Since 802.11 frames
from clients to clients are relayed by the AP, this actually can reflect
the metrics better.

---

The code that was use for the demo is available at the NetDEF git. There
is a package feed for OpenWRT that allows to build images containing our
IS-IS version available here:

https://git.netdef.org/projects/OSR/repos/openwrt-isis-hnet/

Instructions for using that feed can be found in the README file.

-Christian

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet



--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet