Re: [homenet] I-D Action: draft-ietf-homenet-hncp-bis-00.txt

[Terry Manderson]

On 9/07/2016, 9:04 AM, "homenet on behalf of Ted Lemon"
 wrote:
>
>
>ADs do not get to say what is in documents.   They can refuse to publish,
>and they can publish individual submissions if they get IETF consensus,
>and they can threaten to close working groups, but any other changes are
>the purview of the working group.
>

Correct.

:)

Terry


smime.p7s
Description: S/MIME cryptographic signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-bis-00.txt

[Terry Manderson]

On 9/07/2016, 2:30 AM, "Ray Bellis"  wrote:
>
>The instruction to the authors were to incorporate the original .home
>errata verbatim, and also to fix the error with options 37/38 being the
>wrong way around in two diagrams.
>
>If there is to be further wordsmithing on that we'd need to take that up
>with our AD.

So let me clarify a point, the direction from me was to use the errata
wording verbatim in the initial BIS as that forms the start point of the
discussion.

Beyond that, if the WG comes to a consensus to either use that text or
other text after fuller discussion, that will be a WG decision and not
explicitly my decision. The solution must be a WG solution yet respect
IETF processes.

Cheers
Terry


smime.p7s
Description: S/MIME cryptographic signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-bis-00.txt

[Ted Lemon]

A small reminder: while there was clearly a mistake made in including
".home" in this document, from a process perspective an updated document
being worked on by the working group is a working group document, and the
working group can make changes to it.   The document doesn't get published
as a working group document if there isn't consensus to publish it.

So the chairs do not need to "check with the AD" about other changes that
are proposed.   The AD may have specified an accelerated timeline for the
work, so the chairs may say "look, we don't have time for that," but if we
do have time for that, and there is consensus to do it, why on earth would
we not?   If there is a time limit, just say that the change doesn't go in
if there's no consensus to make it before the time limit.

ADs do not get to say what is in documents.   They can refuse to publish,
and they can publish individual submissions if they get IETF consensus, and
they can threaten to close working groups, but any other changes are the
purview of the working group.


On Fri, Jul 8, 2016 at 3:45 PM, Ralph Droms <rdroms.i...@gmail.com> wrote:

>
> On Jul 8, 2016, at 12:30 PM 7/8/16, Ray Bellis <r...@bellis.me.uk> wrote:
>
>
>
> On 08/07/2016 17:25, Ralph Droms wrote:
>
> I took a quick look at draft-ietf-homenet-hncp-bis-00, including a
> diff; seems the only change is to solve the .home problem.  I don't
> think I quite understand the new text and here's a suggested
> clarification:
>
> OLD:
>
> A default value for this TLV MUST be set, although the default value
> of the Domain-Name TLV (Section 10.6) is out of scope of this
> document, and an administrator MAY configure the announcement of a
> Domain-Name TLV for the network.
>
> NEW:
>
> The administrator MUST configure the announcement of a network-wide
> zone suffix through the Domain-Name TLV.
>
> As far as I can tell, draft-ietf-homenet-hncp-bis-00 does not address
> errata 4718.  While this errata has not yet been verified, in my
> opinion *something* has to be done to correct the text around
> "Multicast DNS Proxy".  If "Multicast DNS Proxy" is intended to refer
> to "Hybrid Proxy" in draft-ietf-dnssd-hybrid-03, the appropriate
> normative reference will constitute a downref in
> draft-ietf-homenet-hncp-bis-00.
>
>
> The instruction to the authors were to incorporate the original .home
> errata verbatim, and also to fix the error with options 37/38 being the
> wrong way around in two diagrams.
>
>
> I honestly can't understand the new text.  Why a friendly suggestion for a
> simplification need AD intervention?
>
>
> If there is to be further wordsmithing on that we'd need to take that up
> with our AD.
>
> As for errata 4718, I fully expect that it will be incorporated in a
> further revision just as soon as it has been verified (and subject to a
> resolution of any resulting downref issue).
>
>
> OK. As an aside, *something* will have to be done with the text regarding
> "Multicast DNS Proxy" regardless of whether or not the errata is verified.
> I see a couple of ways to read the existing text and the citations of RFC
> 6762.
>
> One way to read RFC 7788 is to assume "Multicast DNS Proxy" refers to the
> "Multicast DNS Proxy Servers" defined in RFC 6762, in which case RFC 7788
> is specifying that an HNCP device should participate in whatever election
> protocol "Multicast DNS Proxy Servers" use to elect the proxy server for a
> link.  That election protocol needs a reference
>
> Another way to read RFC 7788 is that there is no citation for a definition
> of "Multicast DNS Proxy" at all (assuming the citations of RFC 6762 apply
> just to mDNS and not "proxy"), in which case RFC 7788 needs to be amended
> to include that definition of "Multicast DNS Proxy".
>
> Seems like the WG might want to go ahead and figure out which way it wants
> to fix this issue as doing nothing isn't an option.
>
> - Ralph
>
>
> kind regards,
>
> Ray
>
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-bis-00.txt

[Ralph Droms]

On Jul 8, 2016, at 12:30 PM 7/8/16, Ray Bellis <r...@bellis.me.uk> wrote:On 08/07/2016 17:25, Ralph Droms wrote:I took a quick look at draft-ietf-homenet-hncp-bis-00, including adiff; seems the only change is to solve the .home problem.  I don'tthink I quite understand the new text and here's a suggestedclarification:OLD:A default value for this TLV MUST be set, although the default valueof the Domain-Name TLV (Section 10.6) is out of scope of thisdocument, and an administrator MAY configure the announcement of aDomain-Name TLV for the network.NEW:The administrator MUST configure the announcement of a network-widezone suffix through the Domain-Name TLV.As far as I can tell, draft-ietf-homenet-hncp-bis-00 does not addresserrata 4718.  While this errata has not yet been verified, in myopinion *something* has to be done to correct the text around"Multicast DNS Proxy".  If "Multicast DNS Proxy" is intended to referto "Hybrid Proxy" in draft-ietf-dnssd-hybrid-03, the appropriatenormative reference will constitute a downref indraft-ietf-homenet-hncp-bis-00.The instruction to the authors were to incorporate the original .homeerrata verbatim, and also to fix the error with options 37/38 being thewrong way around in two diagrams.I honestly can't understand the new text.  Why a friendly suggestion for a simplification need AD intervention?If there is to be further wordsmithing on that we'd need to take that upwith our AD.As for errata 4718, I fully expect that it will be incorporated in afurther revision just as soon as it has been verified (and subject to aresolution of any resulting downref issue).OK. As an aside, *something* will have to be done with the text regarding "Multicast DNS Proxy" regardless of whether or not the errata is verified.  I see a couple of ways to read the existing text and the citations of RFC 6762.One way to read RFC 7788 is to assume "Multicast DNS Proxy" refers to the "Multicast DNS Proxy Servers" defined in RFC 6762, in which case RFC 7788 is specifying that an HNCP device should participate in whatever election protocol "Multicast DNS Proxy Servers" use to elect the proxy server for a link.  That election protocol needs a reference Another way to read RFC 7788 is that there is no citation for a definition of "Multicast DNS Proxy" at all (assuming the citations of RFC 6762 apply just to mDNS and not "proxy"), in which case RFC 7788 needs to be amended to include that definition of "Multicast DNS Proxy".Seems like the WG might want to go ahead and figure out which way it wants to fix this issue as doing nothing isn't an option.- Ralphkind regards,Ray
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-bis-00.txt

[Ralph Droms]

> On Jul 8, 2016, at 12:30 PM 7/8/16, Ray Bellis <r...@bellis.me.uk> wrote:
> 
> 
> 
> On 08/07/2016 17:25, Ralph Droms wrote:
>> I took a quick look at draft-ietf-homenet-hncp-bis-00, including a
>> diff; seems the only change is to solve the .home problem.  I don't
>> think I quite understand the new text and here's a suggested
>> clarification:
>> 
>> OLD:
>> 
>> A default value for this TLV MUST be set, although the default value
>> of the Domain-Name TLV (Section 10.6) is out of scope of this
>> document, and an administrator MAY configure the announcement of a
>> Domain-Name TLV for the network.
>> 
>> NEW:
>> 
>> The administrator MUST configure the announcement of a network-wide
>> zone suffix through the Domain-Name TLV.
>> 
>> As far as I can tell, draft-ietf-homenet-hncp-bis-00 does not address
>> errata 4718.  While this errata has not yet been verified, in my
>> opinion *something* has to be done to correct the text around
>> "Multicast DNS Proxy".  If "Multicast DNS Proxy" is intended to refer
>> to "Hybrid Proxy" in draft-ietf-dnssd-hybrid-03, the appropriate
>> normative reference will constitute a downref in
>> draft-ietf-homenet-hncp-bis-00.
> 
> The instruction to the authors were to incorporate the original .home
> errata verbatim, and also to fix the error with options 37/38 being the
> wrong way around in two diagrams.

I honestly can't understand the new text.  Why a friendly suggestion for a 
simplification need AD intervention?

> 
> If there is to be further wordsmithing on that we'd need to take that up
> with our AD.
> 
> As for errata 4718, I fully expect that it will be incorporated in a
> further revision just as soon as it has been verified (and subject to a
> resolution of any resulting downref issue).

OK. As an aside, *something* will have to be done with the text regarding 
"Multicast DNS Proxy" regardless of whether or not the errata is verified.  I 
see a couple of ways to read the existing text and the citations of RFC 6762.

One way to read RFC 7788 is to assume "Multicast DNS Proxy" refers to the 
"Multicast DNS Proxy Servers" defined in RFC 6762, in which case RFC 7788 is 
specifying that an HNCP device should participate in whatever election protocol 
"Multicast DNS Proxy Servers" use to elect the proxy server for a link.  That 
election protocol needs a reference

Another way to read RFC 7788 is that there is no citation for a definition of 
"Multicast DNS Proxy" at all (assuming the citations of RFC 6762 apply just to 
mDNS and not "proxy"), in which case RFC 7788 needs to be amended to include 
that definition of "Multicast DNS Proxy".

Seems like the WG might want to go ahead and figure out which way it wants to 
fix this issue as doing nothing isn't an option.

- Ralph

> 
> kind regards,
> 
> Ray
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-bis-00.txt

[Ralph Droms]

> On Jul 8, 2016, at 12:30 PM 7/8/16, Ray Bellis <r...@bellis.me.uk> wrote:
> 
> 
> 
> On 08/07/2016 17:25, Ralph Droms wrote:
>> I took a quick look at draft-ietf-homenet-hncp-bis-00, including a
>> diff; seems the only change is to solve the .home problem.  I don't
>> think I quite understand the new text and here's a suggested
>> clarification:
>> 
>> OLD:
>> 
>> A default value for this TLV MUST be set, although the default value
>> of the Domain-Name TLV (Section 10.6) is out of scope of this
>> document, and an administrator MAY configure the announcement of a
>> Domain-Name TLV for the network.
>> 
>> NEW:
>> 
>> The administrator MUST configure the announcement of a network-wide
>> zone suffix through the Domain-Name TLV.
>> 
>> As far as I can tell, draft-ietf-homenet-hncp-bis-00 does not address
>> errata 4718.  While this errata has not yet been verified, in my
>> opinion *something* has to be done to correct the text around
>> "Multicast DNS Proxy".  If "Multicast DNS Proxy" is intended to refer
>> to "Hybrid Proxy" in draft-ietf-dnssd-hybrid-03, the appropriate
>> normative reference will constitute a downref in
>> draft-ietf-homenet-hncp-bis-00.
> 
> The instruction to the authors were to incorporate the original .home
> errata verbatim, and also to fix the error with options 37/38 being the
> wrong way around in two diagrams.

I honestly can't understand the new text.  Why a friendly suggestion for a 
simplification need AD intervention?

> 
> If there is to be further wordsmithing on that we'd need to take that up
> with our AD.
> 
> As for errata 4718, I fully expect that it will be incorporated in a
> further revision just as soon as it has been verified (and subject to a
> resolution of any resulting downref issue).

OK. As an aside, *something* will have to be done with the text regarding 
"Multicast DNS Proxy" regardless of whether or not the errata is verified.  I 
see a couple of ways to read the existing text and the citations of RFC 6762.

One way to read RFC 7788 is to assume "Multicast DNS Proxy" refers to the 
"Multicast DNS Proxy Servers" defined in RFC 6762, in which case RFC 7788 is 
specifying that an HNCP device should participate in whatever election protocol 
"Multicast DNS Proxy Servers" use to elect the proxy server for a link.  That 
election protocol would need a normative reference.

Another way to read RFC 7788 is that there is no citation for a definition of 
"Multicast DNS Proxy" at all (assuming the citations of RFC 6762 apply just to 
mDNS and not "proxy"), in which case RFC 7788 needs to be amended to include 
that definition of "Multicast DNS Proxy".

Seems like the WG might want to go ahead and figure out which way it wants to 
fix this issue as doing nothing isn't an option.

- Ralph

> 
> kind regards,
> 
> Ray
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-bis-00.txt

[Ray Bellis]

On 08/07/2016 17:25, Ralph Droms wrote:
> I took a quick look at draft-ietf-homenet-hncp-bis-00, including a
> diff; seems the only change is to solve the .home problem.  I don't
> think I quite understand the new text and here's a suggested
> clarification:
> 
> OLD:
> 
> A default value for this TLV MUST be set, although the default value
> of the Domain-Name TLV (Section 10.6) is out of scope of this
> document, and an administrator MAY configure the announcement of a
> Domain-Name TLV for the network.
> 
> NEW:
> 
> The administrator MUST configure the announcement of a network-wide 
> zone suffix through the Domain-Name TLV.
> 
> As far as I can tell, draft-ietf-homenet-hncp-bis-00 does not address
> errata 4718.  While this errata has not yet been verified, in my
> opinion *something* has to be done to correct the text around
> "Multicast DNS Proxy".  If "Multicast DNS Proxy" is intended to refer
> to "Hybrid Proxy" in draft-ietf-dnssd-hybrid-03, the appropriate
> normative reference will constitute a downref in
> draft-ietf-homenet-hncp-bis-00.

The instruction to the authors were to incorporate the original .home
errata verbatim, and also to fix the error with options 37/38 being the
wrong way around in two diagrams.

If there is to be further wordsmithing on that we'd need to take that up
with our AD.

As for errata 4718, I fully expect that it will be incorporated in a
further revision just as soon as it has been verified (and subject to a
resolution of any resulting downref issue).

kind regards,

Ray

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

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-bis-00.txt

[Ralph Droms]

I took a quick look at draft-ietf-homenet-hncp-bis-00, including a diff; seems 
the only change is to solve the .home problem.  I don't think I quite 
understand the new text and here's a suggested clarification:

OLD:

  A default value for this TLV MUST be set, although
  the default value of the Domain-Name TLV (Section 10.6) is out of
  scope of this document, and an administrator MAY configure the
  announcement of a Domain-Name TLV for the network.

NEW:

  The administrator MUST configure the announcement of a network-wide
  zone suffix through the Domain-Name TLV.

As far as I can tell, draft-ietf-homenet-hncp-bis-00 does not address errata 
4718.  While this errata has not yet been verified, in my opinion *something* 
has to be done to correct the text around "Multicast DNS Proxy".  If "Multicast 
DNS Proxy" is intended to refer to "Hybrid Proxy" in 
draft-ietf-dnssd-hybrid-03, the appropriate normative reference will constitute 
a downref in draft-ietf-homenet-hncp-bis-00.

- Ralph

> On Jul 8, 2016, at 10:20 AM 7/8/16, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Home Networking of the IETF.
> 
>Title   : Home Networking Control Protocol
>Authors : Markus Stenberg
>  Steven Barth
>          Pierre Pfister
>   Filename: draft-ietf-homenet-hncp-bis-00.txt
>   Pages   : 38
>   Date: 2016-07-08
> 
> Abstract:
>   This document describes the Home Networking Control Protocol (HNCP),
>   an extensible configuration protocol, and a set of requirements for
>   home network devices.  HNCP is described as a profile of and
>   extension to the Distributed Node Consensus Protocol (DNCP).  HNCP
>   enables discovery of network borders, automated configuration of
>   addresses, name resolution, service discovery, and the use of any
>   routing protocol that supports routing based on both the source and
>   destination address.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp-bis/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-homenet-hncp-bis-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] I-D Action: draft-ietf-homenet-hncp-bis-00.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Home Networking of the IETF.

Title   : Home Networking Control Protocol
Authors : Markus Stenberg
  Steven Barth
  Pierre Pfister
Filename: draft-ietf-homenet-hncp-bis-00.txt
Pages   : 38
Date: 2016-07-08

Abstract:
   This document describes the Home Networking Control Protocol (HNCP),
   an extensible configuration protocol, and a set of requirements for
   home network devices.  HNCP is described as a profile of and
   extension to the Distributed Node Consensus Protocol (DNCP).  HNCP
   enables discovery of network borders, automated configuration of
   addresses, name resolution, service discovery, and the use of any
   routing protocol that supports routing based on both the source and
   destination address.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp-bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-homenet-hncp-bis-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [homenet] HNCP in tcpdump and wireshark?

[Markus Stenberg]

On 9.6.2016, at 19.38, Juliusz Chroboczek  
wrote:
>>> Do you know if anyone is working on HNCP support for tcpdump and
>>> wireshark?  I'm considering giving it out as a student project this
>>> summer, but of course it doesn't make a lot of sense if somebody beats us
>>> to it.
>>> 
>>> (I already know about the lua script for Wireshark.)
>> Plenty of Wireshark built-in decoders are in lua also, so I guess you
>> can if you must, but probably just upstreaming the Lua version would be
>> the thing to do..?
> Do we have your blessing for completing and upstreaming your lua code?

Certainly. Currently hnetd (where it resides) is Apache licensed, and AFAIK 
that is fine, and if not, earlier version (with very minor changes) was GPL 
just like the Wireshark. Only change from GPL->Apache version was the update to 
match RFC7788 #s.

Cheers,

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

Re: [homenet] HNCP in tcpdump and wireshark?

[Juliusz Chroboczek]

>> Do you know if anyone is working on HNCP support for tcpdump and
>> wireshark?  I'm considering giving it out as a student project this
>> summer, but of course it doesn't make a lot of sense if somebody beats us
>> to it.
>> 
>> (I already know about the lua script for Wireshark.)

> Plenty of Wireshark built-in decoders are in lua also, so I guess you
> can if you must, but probably just upstreaming the Lua version would be
> the thing to do..?

Do we have your blessing for completing and upstreaming your lua code?

-- Juliusz


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

Re: [homenet] HNCP in tcpdump and wireshark?

[Markus Stenberg]

> On 9.6.2016, at 18.38, Juliusz Chroboczek  
> wrote:
> 
> Dear Markus, dear all,
> 
> Do you know if anyone is working on HNCP support for tcpdump and
> wireshark?  I'm considering giving it out as a student project this
> summer, but of course it doesn't make a lot of sense if somebody beats us
> to it.
> 
> (I already know about the lua script for Wireshark.)

Plenty of Wireshark built-in decoders are in lua also, so I guess you can if 
you must, but probably just upstreaming the Lua version would be the thing to 
do..?

Cheers,

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

[homenet] HNCP in tcpdump and wireshark?

[Juliusz Chroboczek]

Dear Markus, dear all,

Do you know if anyone is working on HNCP support for tcpdump and
wireshark?  I'm considering giving it out as a student project this
summer, but of course it doesn't make a lot of sense if somebody beats us
to it.

(I already know about the lua script for Wireshark.)

-- Juliusz

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

Re: [homenet] HNCP question: multiple delegations for same prefix

[Pierre Pfister]

Hello Juliusz,

I think your understanding is correct. 
Nothing in HNCP prevents routers from advertising identical delegated prefixes.
And nothing prevents routers from advertising overlapping delegated prefixes.

But it is stated that the set of delegated prefixes to be used by the prefix 
assignment algorithm contains: 
 "The set of prefixes encoded in
  Delegated-Prefix TLVs that are not strictly included in prefixes
  encoded in other Delegated-Prefix TLVs."

Which means indeed that in such a situation, only one prefix from the 
overlapping delegated prefixes will be assigned to each link.

Cheers,

- Pierre


> Le 19 avr. 2016 à 17:50, Juliusz Chroboczek  
> a écrit :
> 
> Hi,
> 
> Is it legal for multiple HNCP routers to announce the same delegated
> (IPv6) prefix?
> 
> I assume it is legal, and that nodes should assign a single prefix per
> delegated prefix to attached links (the spec says "set of delegated
> prefixes", not "multiset"), but I'd like to be sure I'm not overlooking
> something.
> 
> -- Juliusz
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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

[homenet] HNCP question: multiple delegations for same prefix

[Juliusz Chroboczek]

Hi,

Is it legal for multiple HNCP routers to announce the same delegated
(IPv6) prefix?

I assume it is legal, and that nodes should assign a single prefix per
delegated prefix to attached links (the spec says "set of delegated
prefixes", not "multiset"), but I'd like to be sure I'm not overlooking
something.

-- Juliusz

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

Re: [homenet] HNCP: interaction with routing protocol?

[Henning Rogge]

On Wed, Dec 16, 2015 at 6:31 PM, Juliusz Chroboczek
 wrote:
>> hnetd does address configuration on interfaces, the routing protocol picks
>> this up because that's how it's configured...? Hnetd doesn't communicate
>> directly with the routing protocol at all, right? It just sets up the
>> landscape so the routing protocol can come and survey it and communicate
>> the contents.
>
> That's exactly right (and very well put).  That's what I tried to express
> in my talk at Prague -- it turns out that HNCP is a very clean design.
> (Except where it isn't, of course.)
>
> Hnetd and shncpd do that somewhat differently.  Hnetd assume that the
> routing protocol redistributes everything.  Shncpd has closer binding to
> the routing protocol, it marks its routes as "proto 43" and expects the
> routing protocol to redistribute just that; shncpd also occasionally
> inserts dummy "proto 43" routes into the kernel, just so that they get
> redistributed into the routing protocol.  The result is that shncpd
> produces somewhat cleaner (more aggregated) routing tables, at the cost of
> requiring special configuration of the routing protocol.

Just redistributing protocol 43 will also make you miss the default
route you get by DHCP from an uplink.

Henning Rogge

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

Re: [homenet] HNCP: interaction with routing protocol?

[Juliusz Chroboczek]

> If you're announcing an external connection into the HNCP domain, shncpd
> will install a proto 43 source-specific default route.  See route_externals
> in prefix.c.

In case that wasn't clear -- shncpd doesn't act as a DHCPv6-PD or DHCPv4
client, it expects you (the human operator or the startup scripts) to set
up what HNCP calls an "external connection" using the "-E" and "-N" flags.
So the design is the opposite of hnetd: hnetd controls the DHCP clients,
while shncpd is controlled by the DHCP client.

Depending on whether you already have suitable DHCP clients in your
system, you'll prefer one approach or the other.

-- Juliusz

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

Re: [homenet] HNCP: interaction with routing protocol?

[Juliusz Chroboczek]

>> Shncpd has closer binding to the routing protocol, it marks its routes
>> as "proto 43" and expects the routing protocol to redistribute just
>> that; shncpd also occasionally inserts dummy "proto 43" routes into the
>> kernel, just so that they get redistributed into the routing protocol.

> Just redistributing protocol 43 will also make you miss the default
> route you get by DHCP from an uplink.

If you're announcing an external connection into the HNCP domain, shncpd
will install a proto 43 source-specific default route.  See route_externals
in prefix.c.

If you're not announcing an external connection, then indeed you need to
manually arrange redistribution of the default route.  Shncpd doesn't do
that for you, since it doesn't know whether forwarding is set up for the
route and whether there's the need to set up a source prefix for BCP38.

(This is where hnetd and shncd differ.  Hnetd is optimistic, it assumes
that forwarding is set up and that the default route has a suitable source
prefix attached.  Shncpd is pessimistic, and fears that redistributing
random default routes into the routing protocol will create blackholes.
Somebody once wrote that optimists and pessimists die the same way, they
just live differently.)

-- Juliusz

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

Re: [homenet] HNCP: interaction with routing protocol?

[Juliusz Chroboczek]

> hnetd does address configuration on interfaces, the routing protocol picks
> this up because that's how it's configured...? Hnetd doesn't communicate
> directly with the routing protocol at all, right? It just sets up the
> landscape so the routing protocol can come and survey it and communicate
> the contents.

That's exactly right (and very well put).  That's what I tried to express
in my talk at Prague -- it turns out that HNCP is a very clean design.
(Except where it isn't, of course.)

Hnetd and shncpd do that somewhat differently.  Hnetd assume that the
routing protocol redistributes everything.  Shncpd has closer binding to
the routing protocol, it marks its routes as "proto 43" and expects the
routing protocol to redistribute just that; shncpd also occasionally
inserts dummy "proto 43" routes into the kernel, just so that they get
redistributed into the routing protocol.  The result is that shncpd
produces somewhat cleaner (more aggregated) routing tables, at the cost of
requiring special configuration of the routing protocol.

(Why 43?  Because babeld uses 42, of course.)

-- Juliusz

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

Re: [homenet] HNCP: interaction with routing protocol?

[Markus Stenberg]

> On 14.12.2015, at 8.15, Mikael Abrahamsson  wrote:
> 
> On Sun, 13 Dec 2015, Juliusz Chroboczek wrote:
> 
>> The OpenWRT hnetd configuration redistributes everything, indeed.  The
>> recommended shncpd configuration redistributes just hncpd routes:
>> 
>>   redistribute local deny
>>   redistribute proto 43 allow
> 
> Just to be clear here, when you say "hnetd configuration" you are referring 
> to babeld.conf that gets installed when you install hnetd-full? So it's 
> really the babel configuraton that you get when installing hnetd?

The routing support script that enables routing on an interface (based on 
border discovery result) has hard-coded configuration for Babel which 
redistributes all routes.

> Because as far as I understand, hnetd doesn't do any redistribution into the 
> routing protocol, this is done by configuring the routing protocol to look at 
> interface addresses/prefix and communicating this to other participants in 
> the routing protocol?
> 
> hnetd does address configuration on interfaces, the routing protocol picks 
> this up because that's how it's configured...? Hnetd doesn't communicate 
> directly with the routing protocol at all, right? It just sets up the 
> landscape so the routing protocol can come and survey it and communicate the 
> contents.

See above. Given fixed interface categories, static routing protocol 
configuration could work, but as is, the script provides list of interfaces 
that routing protocol _can_ run on given the current state of detected borders.

Cheers,

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

Re: [homenet] HNCP: interaction with routing protocol?

[Juliusz Chroboczek]

>> I'm probably missing something -- but where in the HNCP document does it
>> say that applied prefixes must be announced over the routing protocol?
>> I don't see it in Section 6.3.3.

> I'd say the role of HNCP and the routing protocol and what does what, is
> not really specified anywhere.

HNCP does specify when the router MUST speak RA and DHCPv4, and SHOULD
speak DHCPv6-PD, so I'd expect it to have similar requirements for
routing.  It doesn't make a lot of sense to send RAs or perform prefix
delegation if you're not going to announce the prefix over the routing
protocol.

Markus, Stephen -- it's too late to change that, right?  If so, no big
deal, we'll put it in the Homenet profile for Babel.

> Otoh, it's very natural for me that a routing protocol would do
> "redistribute connected" or at least do this for interfaces marked as
> "HNCP". From my testing before on the actual OpenWRT implementations as
> they are configured out of the box as I tested them, it seemed babel was
> doing "redistribute connected" for all interfaces,

The OpenWRT hnetd configuration redistributes everything, indeed.  The
recommended shncpd configuration redistributes just hncpd routes:

redistribute local deny
redistribute proto 43 allow

("redistribute proto 43" is shncpd, "redistribute local" is locally
assigned addresses.)

(I'll go out on a limb, and argue that it's not HNCP's business to say
what the routing protocol does with non-Homenet routes -- it's hopefully
legal for a Homenet router to redistribute, say, RIPng into Babel --, so
both implementations are correct.)

-- Juliusz

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

Re: [homenet] HNCP: interaction with routing protocol?

[Mikael Abrahamsson]

On Sun, 13 Dec 2015, Juliusz Chroboczek wrote:


The OpenWRT hnetd configuration redistributes everything, indeed.  The
recommended shncpd configuration redistributes just hncpd routes:

   redistribute local deny
   redistribute proto 43 allow


Just to be clear here, when you say "hnetd configuration" you are 
referring to babeld.conf that gets installed when you install hnetd-full? 
So it's really the babel configuraton that you get when installing hnetd?


Because as far as I understand, hnetd doesn't do any redistribution into 
the routing protocol, this is done by configuring the routing protocol to 
look at interface addresses/prefix and communicating this to other 
participants in the routing protocol?


hnetd does address configuration on interfaces, the routing protocol 
picks this up because that's how it's configured...? Hnetd doesn't 
communicate directly with the routing protocol at all, right? It just sets 
up the landscape so the routing protocol can come and survey it and 
communicate the contents.


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

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

Re: [homenet] Protocol Action: 'Home Networking Control Protocol' to Proposed Standard (draft-ietf-homenet-hncp-10.txt)

[Juliusz Chroboczek]

> The IESG has approved the following document:
> - 'Home Networking Control Protocol'
> (draft-ietf-homenet-hncp-10.txt) as Proposed Standard

Yay!

(Congratulations to Markus, Stephen and Pierre, and also to Mark and
everyone else who sweated water and bl

-- Juliusz

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

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

[Stephen Farrell]

I had a peek at the diff and it's all good from my POV.

Isn't it amazing how you can look at a document for ages
and ages and not just see stuff like the hkdf thing? I do
it all the time;-(

S.


On 04/12/15 21:53, Markus Stenberg wrote:
>> On 4.12.2015, at 18.51, Stephen Farrell  wrote:
>> Thanks for addressing my discuss about the options for 
>> using DTLS. Sorry for being slow with this ballot update.
>>
>> The comments below are old, I didn't check if you've
>> made related changes. Happy to chat about that if you
>> want, (or not if you prefer not:-)
>>
>> - I agree with Kathleen's discuss that the implementation
>> requirements for DTLS need to be clarified, hopefully (from my
>> POV) to make that MTI but I'll leave that discussion to the
>> other thread.
> 
> We did some text clarification on this I believe in -10.
> 
>> -Section 9: You should refer to HKDF and not HMAC-SHA256 though
>> the reference to RFC 6234 is still right. HMAC-SHA256 itself
>> is not a key derivation function, which is what you want here.
> 
> Fixed in -10 (really sad failure on my part :-p)
> 
>> - Please take a look at the secdir review [1] and respond to
>> that as it raises one issue not (I think) otherwise mentioned.
>> What is the effect (on a home) of one compromised hncp router?
>> Perhaps you'll say that's obvious, or perhaps not, but I'm 
>> interested in what you do say, in case it's not obvious:-)
> 
> There's text about that in the security considerations, I believe. (Pointer 
> in the -09 DISCUSS thread IIRC).
> 
> Cheers,
> 
> -Markus
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 

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

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

[Markus Stenberg]

> On 4.12.2015, at 18.51, Stephen Farrell  wrote:
> Thanks for addressing my discuss about the options for 
> using DTLS. Sorry for being slow with this ballot update.
> 
> The comments below are old, I didn't check if you've
> made related changes. Happy to chat about that if you
> want, (or not if you prefer not:-)
> 
> - I agree with Kathleen's discuss that the implementation
> requirements for DTLS need to be clarified, hopefully (from my
> POV) to make that MTI but I'll leave that discussion to the
> other thread.

We did some text clarification on this I believe in -10.

> -Section 9: You should refer to HKDF and not HMAC-SHA256 though
> the reference to RFC 6234 is still right. HMAC-SHA256 itself
> is not a key derivation function, which is what you want here.

Fixed in -10 (really sad failure on my part :-p)

> - Please take a look at the secdir review [1] and respond to
> that as it raises one issue not (I think) otherwise mentioned.
> What is the effect (on a home) of one compromised hncp router?
> Perhaps you'll say that's obvious, or perhaps not, but I'm 
> interested in what you do say, in case it's not obvious:-)

There's text about that in the security considerations, I believe. (Pointer in 
the -09 DISCUSS thread IIRC).

Cheers,

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

Re: [homenet] Stephen Farrell's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Juliusz Chroboczek]

>>> Hmm. I've also setup many small PKIs and don't agree. I do think someone
>>> could easily make all that quite usable within the home.

>> Have you ever walked a non-specialist through the process?

> I have not.

I see.

-- Juliusz

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

[homenet] Barry Leiba's No Objection on draft-ietf-homenet-hncp-10: (with COMMENT)

[Barry Leiba]

Barry Leiba has entered the following ballot position for
draft-ietf-homenet-hncp-10: 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-hncp/



--
COMMENT:
--

Version -10 addresses all my comments.  Thanks very much for considering
them!


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

Re: [homenet] Stephen Farrell's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Michael Thomas]

On 11/26/2015 08:49 AM, Juliusz Chroboczek wrote:

Hmm. I've also setup many small PKIs and don't agree. I do think someone
could easily make all that quite usable within the home.

Have you ever walked a non-specialist through the process?




I'm not Stephen, and I don't play Stephen on teevee, but anything you 
can do with pre-shared keys, you
can do with with an asymmetric keying approach too. Pre-shared keys are 
pretty high touch form of enrollment,
after all. If you can get away with leap-of-faith kinds of enrollment, 
it is even easier IMO because you don't have

to remember messy and/or lousy keys/passphrases:

New Thingy: "I'm blah and want to enroll! my public key is blah-blah-blah"
Enroller: "Sure!" or "Nah, you look sketchy"

Mike

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

Re: [homenet] Stephen Farrell's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Henning Rogge]

On Thu, Nov 26, 2015 at 5:49 PM, Juliusz Chroboczek
 wrote:
>> Hmm. I've also setup many small PKIs and don't agree. I do think someone
>> could easily make all that quite usable within the home.
>
> Have you ever walked a non-specialist through the process?

I wonder why this could not be fully automatic?

Setup a "press button for first login" system similar to WPS for Wifi
that deploys the certificate.

No need for the user to do something complicated.

Henning

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

Re: [homenet] Stephen Farrell's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Stephen Farrell]

On 26/11/15 16:49, Juliusz Chroboczek wrote:
>> Hmm. I've also setup many small PKIs and don't agree. I do think someone
>> could easily make all that quite usable within the home.
> 
> Have you ever walked a non-specialist through the process?

I have not. But as others said, the key idea would be to make
it as invisible as possible, which is quite doable. And the
tools are there these days (much moreso than even 5-6 years
ago) in pretty much all platforms/languages.

S.

> 
> -- Juliusz
> 

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

Re: [homenet] Alia Atlas' No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)

[Markus Stenberg]

Heya,

thanks for the review :)

> --
> COMMENT:
> --
> 
> I support Brian's Discuss.
> 
> 1)  In Sec 1.1, it states "...in homenet environments where multiple IPv6
> 
>   source-prefixes can be present, routing based on source and
> destination 
>   address is necessary [RFC7368]."
> 
>   Looking at RFC7368, I don't see anything that matches the strength of
> this
>   assertion which says in Sec 3.2.4 merely  "Another avenue is to
> introduce support
>   throughout the homenet for routing that is based on the source as
>   well as the destination address of each packet."
> 
>   While src-dest routing is certainly a solution - and an interesting
> one - it doesn't
>   seem at all appropriate for an HNCP spec to assert that it is
> necessary.

True. However, we were asked to describe the applicability, and I consider e.g. 
tunneling solution inferior so I would rather not propose that here. (And you 
either need tunneling or src-dst routing for this to work, and defining new 
tunneling scheme just for this to work is much harder than saying src-dst). 
Without one of them, the solution will break BCP-38 and not work.

What would be the other realistic option to change here? The whole 
applicability mess showed up somewhere in the review process, and I would 
rather not have it, but dropping it is not an option either.

> 2) For the DNCP profile,  draft-ietf-homenet-dncp-12 says  "Anything
> received over multicast, except Node Endpoint TLV (Section 7.2.1) and
> Network State TLV (Section 7.2.2)." and this draft says "HNCP nodes MUST
> ignore all Node State TLVs received via multicast
> on a link which has DNCP security enabled in order to prevent spoofing
> of node state changes."
> Could you please align and clarify the desired behavior for HNCP?

The part you are quoting from DNCP profile notes only what _can_ be defined to 
be ignored by profiles. HNCP as written is correct.

I welcome deltas which make it more correct, but you did not quote the 
preceding paragraph which says this in DNCP:

   o  When receiving TLVs, what sort of TLVs are ignored in addition -
  as specified in Section 4.4 - e.g., for security reasons.  While
  the security of the node data published within the Node State TLVs
  is already ensured by the base specification (if secure unicast
  transport is enabled, Node State TLVs are sent only via unicast as
  multicast ones are ignored on receipt), if a profile adds TLVs
  that are sent outside the node data, a profile should indicate
  whether or not those TLVs should be ignored if they are received
  via multicast or non-secured unicast.  A DNCP profile may define
  the following DNCP TLVs to be safely ignored:

Cheers,

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

Re: [homenet] Alia Atlas' No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)

[Juliusz Chroboczek]

>> While src-dest routing is certainly a solution - and an interesting
>> one - it doesn't seem at all appropriate for an HNCP spec to assert
>> that it is necessary.

> True. However, we were asked to describe the applicability, and
> I consider e.g. tunneling solution inferior so I would rather not
> propose that here.

I was under the impression that there was consensus that tunnelling is
a bad idea, and that source-specific routing is superior.  I may be
mis-reading Alia, but perhaps she means that some deployments might not
require the added complexity of source-specific routing, and might be able
to get away with ordinary next-hop routing.  (Alia, apologies if
I misunderstood.)

Recall that our main concern is to ensure that Homenet routers from
different vendors interoperate.  Source-specific routing, when done right,
interoperates with ordinary next-hop routing under the following
conditions: (1) all edge routers are source-specific, (2) there is
a connected backbone of source-specific routers, and (3) at least one of
the routers in the backbone announces a non-specific default route.  (1)
and (3) are easy enough, but (2) is problematic: it is a global condition,
one that can only be verified with global knowledge of the topology.

So I agree with Markus -- while it might be possible to get away with
a weaker requirement, it is way simpler to make source-specific routing
a MUST.  If there is market demand, we might want to write a different
document that describes a weaker set of requirements for interior-only
(non-gateway-capable) Homenet nodes.

(A more desirable alternative, of course, would be to split the
requirements in HNCP into HNCP requirements and Homenet requirements, but
I gather that there's consensus that it's somewhat late to embark on such
an ambitious project.  I rather agree with that assessment -- we need to
get Homenet out of the door quickly, lest people start deploying IPv6 NAT.)

-- Juliusz

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

Re: [homenet] Barry Leiba's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Juliusz Chroboczek]

> It MUST be set to 0 if the router is not capable of doing FOO,
> otherwise it SHOULD be set to 4 but MAY be set to any value from 1 to
> 7 to indicate a non-default priority. The values 8-15 are reserved
> for future use.

Steven, shouldn't it say explicitly what a node does when it receives
a capability in the 8 to 15 range ?  Should it let the router announcing
the out-of-range capability win the election, or should such announcements
be ignored?  (Shncpd does the former, which I guess is the intent.)

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

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

[Markus Stenberg]

On 18.11.2015, at 16.56, Ted Lemon  wrote:
> Wednesday, Nov 18, 2015 8:24 AM Juliusz Chroboczek wrote:
>> HNCP is an amazingly flexible protocol, and one that will hopefully be
>> used well beyond it's original area of application.  Many of the possible
>> applications of HNCP don't require DTLS, either because the network is
>> secured at a lower layer, or because they use a different application
>> layer mechanism.
> Which possible applications of HNCP don't require security?   The problem we 
> have with HNCP is that we have no basis for establishing trust, not that we 
> don’t need security.

Most home networks in my honest opinion. Let us enumerate the threats:

- If the devices communicate using the wires in the home, if you have a breach 
there, someone can e.g. do nasty things to devices themselves anyway (for 
example, likelihood of someone doing on-wire tapping of my home ethernet 
infrastructure is less than someone actually stealing the Mac Pro, servers and 
other hardware the ethernet is attached to if they get the access) => physical 
security wins.

- If the devices communicate using wireless in the home, if you have a breach 
there, someone can e.g. do nasty things to other devices anyway => no wins in 
securing HNCP.

Securing HNCP will only make the attacks local, not global (in terms of the 
network). Someone can still spoof e.g. sending RAs on the local link, or do 
ARP/DHCPv4 in IPv4 land, and after that pretend to be router etc. Only if we 
have just point-to-point links (e.g. star topologies), with router as first hop 
for every node, then securing HNCP actually mitigates some threats. In practise 
I suspect typical homes will have relatively large number of devices in one or 
few wireless SSIDs and perhaps something on wires, but that does not imply star 
topology.

If we contrast that to the current full L2 bridges in homes, the situation is 
simply same; attacks can be mounted on any insecure link in home and it affects 
the whole home.

While improving the state of the art here would be nice, I do not really see it 
as a reason to say MUST to an unproven solution (in terms of deployment and 
adoption).

> The argument against DTLS that I think makes some sense is "we don't know how 
> to key it, and therefore don't know if it will work if/when we figure out 
> security," not "we don't need it."   I actually have a great deal of sympathy 
> for Kathleen’s view here; if we make DTLS MTI, then at least we’ll have an 
> encryption/authentication mechanism when we figure out how we want to do that.

But we will have no implementations that actually do that. I consider that just 
harmful code bloat until some distant day in the future in which we have 
feasible bootstrapping scheme AND implementations in place to use it. 

> I think there's a pretty strong case to be made that the security mechanism 
> will require public key cryptography.   If that's the case, then DTLS will 
> work as an encryption/authentication layer.   The fact that the current draft 
> refers to DTLS and makes it mandatory to use when transmitting pre-shared 
> keys means that we’ve already got consensus that DTLS is a necessary option 
> for encryption/authentication.

Possibly. The jury is still out on what is actually deployable. I am very leery 
of mandating anything without actual deployment experience.

For example, the current open source DTLS implementations that do non-PSK are 
woefully small in number, and mostly derive from same, huge, and not so good 
codebase (naming no names to be polite).

There’s another (much more lightweight) scheme on how to (less well, psk-only) 
secure DNCP stuff that I actually I use in my home; no draft, as I did not want 
to muddle the waters, but it is essentially few lines of Python[1] as opposed 
to half million lines of C that certain unnamed SSL/TLS/DTLS implementation. 
Obviously it cannot be bootstrapped but neither can be the most common type of 
DTLS - PSK-based.

As the routing protocol choice was left up in the air for homenet, I consider 
this to be much more thorny issue, and just saying ‘DTLS+$FOO’ seems dangerous. 
Especially as none of the current solutions seem that appealing (PSK = 
practically no go in terms of real deployment, consensus = unproven new stuff, 
perhaps we want in-home CA?).

> That being the case, I actually don't see any argument against making DTLS 
> mandatory to implement.   You didn't give a reason for your opinion that we 
> should not.   If you do have a reason for thinking that DTLS shouldn't be 
> MTI, please state it plainly--your opinion may well be correct, but if we 
> don't know why you have that opinion, we have no way to evaluate it other 
> than to trust you or not, and that's not a good way to do standards work.   
> If the concern is whether there's a good DTLS implementation that can be 
> used, I don't know how good it is but tinydtls looks like it might work.   It 
> uses a license that is 

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

[Kathleen Moriarty]

Hi Markus,

Thanks for your quick response, inline,

On Fri, Nov 20, 2015 at 10:07 AM, Markus Stenberg
 wrote:
> On 20.11.2015, at 16.47, Kathleen Moriarty  
> wrote:
>>> It is question of threats <-> risks  <-> mitigation analysis. Only thing 
>>> HNCP security really brings is _in case of insecure L2_ _some_ security for 
>>> routing/psk state. If we assume every other protocol is secured (e.g. SEND, 
>>> DHCPv6 ’secure mode’) it may be actually worthwhile, but as long as e.g. 
>>> DHCPv4 is not secure (and it will never be I suspect), the amount of 
>>> threats you actually take out of the picture by forcing ’securing’ HNCP 
>>> alone is not really significant.
>>>
>>> To sum it up: I recommend still SHOULD MTI, MUST MTU _if and only if_ L2, 
>>> but at least _my_ home does not _have_ any insecure L2, or at least 
>>> insecure in a sense that HNCP running there would be my greatest worry.
>> If MTI is not a MUST, how can you MUST the MTU?
>
> The MUST MTU here is only for (relatively small) subset of U cases. 
> Therefore, if a product (or a network) does not see those cases happening, 
> broad MTI/MTU causes extra bloat without any benefit (like my home network 
> case I mentioned).

Can you propose text that clearly describes this for developers and
implementors to replace the current text and we'll see where we are
at?  If it makes enough sense, I may be okay with that.  Stephen also
supported my discuss, so both of us may need to review and possibly
tweak it.  The current text isn't clear enough to convey what's been
described int his thread.


>
> For example, given Markus’ Home Network product does not support insecure 
> (L2-wise) network, having MTI DTLS/TLS causes bloat and solves nothing and 
> makes product harder to ship.
>
>> I think my question on what is "secure mode" and request for a
>> reference is still outstanding.
>
> Ah, sorry, simply too much mail backlog. ’secure mode’ in that context should 
> be probably just secure _transport_ enabled on that particular link/for a 
> particular remote endpoint, that is,  the {TLS,DTLS} based one described in 
> the rest of the text.

OK, then for the text where this shows up in this draft, please do
replace it with what is meant exactly.

>
> I wonder if we should edit dncp too, I don’t think that term appears anywhere 
> elsewhere in the document.

Yes, please.  Since it isn't defined anywhere, just stating what was
intended would be much better.

Thank you,
Kathleen

>
> Cheers,
>
> -Markus
>



-- 

Best regards,
Kathleen

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

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

[Markus Stenberg]

On 20.11.2015, at 16.47, Kathleen Moriarty  
wrote:
>> It is question of threats <-> risks  <-> mitigation analysis. Only thing 
>> HNCP security really brings is _in case of insecure L2_ _some_ security for 
>> routing/psk state. If we assume every other protocol is secured (e.g. SEND, 
>> DHCPv6 ’secure mode’) it may be actually worthwhile, but as long as e.g. 
>> DHCPv4 is not secure (and it will never be I suspect), the amount of threats 
>> you actually take out of the picture by forcing ’securing’ HNCP alone is not 
>> really significant.
>> 
>> To sum it up: I recommend still SHOULD MTI, MUST MTU _if and only if_ L2, 
>> but at least _my_ home does not _have_ any insecure L2, or at least insecure 
>> in a sense that HNCP running there would be my greatest worry.
> If MTI is not a MUST, how can you MUST the MTU?

The MUST MTU here is only for (relatively small) subset of U cases. Therefore, 
if a product (or a network) does not see those cases happening, broad MTI/MTU 
causes extra bloat without any benefit (like my home network case I mentioned).

For example, given Markus’ Home Network product does not support insecure 
(L2-wise) network, having MTI DTLS/TLS causes bloat and solves nothing and 
makes product harder to ship.

> I think my question on what is "secure mode" and request for a
> reference is still outstanding.

Ah, sorry, simply too much mail backlog. ’secure mode’ in that context should 
be probably just secure _transport_ enabled on that particular link/for a 
particular remote endpoint, that is,  the {TLS,DTLS} based one described in the 
rest of the text.

I wonder if we should edit dncp too, I don’t think that term appears anywhere 
elsewhere in the document.

Cheers,

-Markus

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

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

[Kathleen Moriarty]

On Fri, Nov 20, 2015 at 9:21 AM, Markus Stenberg  wrote:
> On 18.11.2015, at 16.56, Ted Lemon  wrote:
>> Wednesday, Nov 18, 2015 8:24 AM Juliusz Chroboczek wrote:
>>> HNCP is an amazingly flexible protocol, and one that will hopefully be
>>> used well beyond it's original area of application.  Many of the possible
>>> applications of HNCP don't require DTLS, either because the network is
>>> secured at a lower layer, or because they use a different application
>>> layer mechanism.
>> Which possible applications of HNCP don't require security?   The problem we 
>> have with HNCP is that we have no basis for establishing trust, not that we 
>> don’t need security.
>
> Most home networks in my honest opinion. Let us enumerate the threats:
>
> - If the devices communicate using the wires in the home, if you have a 
> breach there, someone can e.g. do nasty things to devices themselves anyway 
> (for example, likelihood of someone doing on-wire tapping of my home ethernet 
> infrastructure is less than someone actually stealing the Mac Pro, servers 
> and other hardware the ethernet is attached to if they get the access) => 
> physical security wins.
>
> - If the devices communicate using wireless in the home, if you have a breach 
> there, someone can e.g. do nasty things to other devices anyway => no wins in 
> securing HNCP.
>
> Securing HNCP will only make the attacks local, not global (in terms of the 
> network). Someone can still spoof e.g. sending RAs on the local link, or do 
> ARP/DHCPv4 in IPv4 land, and after that pretend to be router etc. Only if we 
> have just point-to-point links (e.g. star topologies), with router as first 
> hop for every node, then securing HNCP actually mitigates some threats. In 
> practise I suspect typical homes will have relatively large number of devices 
> in one or few wireless SSIDs and perhaps something on wires, but that does 
> not imply star topology.
>
> If we contrast that to the current full L2 bridges in homes, the situation is 
> simply same; attacks can be mounted on any insecure link in home and it 
> affects the whole home.
>
> While improving the state of the art here would be nice, I do not really see 
> it as a reason to say MUST to an unproven solution (in terms of deployment 
> and adoption).
>
>> The argument against DTLS that I think makes some sense is "we don't know 
>> how to key it, and therefore don't know if it will work if/when we figure 
>> out security," not "we don't need it."   I actually have a great deal of 
>> sympathy for Kathleen’s view here; if we make DTLS MTI, then at least we’ll 
>> have an encryption/authentication mechanism when we figure out how we want 
>> to do that.
>
> But we will have no implementations that actually do that. I consider that 
> just harmful code bloat until some distant day in the future in which we have 
> feasible bootstrapping scheme AND implementations in place to use it.
>
>> I think there's a pretty strong case to be made that the security mechanism 
>> will require public key cryptography.   If that's the case, then DTLS will 
>> work as an encryption/authentication layer.   The fact that the current 
>> draft refers to DTLS and makes it mandatory to use when transmitting 
>> pre-shared keys means that we’ve already got consensus that DTLS is a 
>> necessary option for encryption/authentication.
>
> Possibly. The jury is still out on what is actually deployable. I am very 
> leery of mandating anything without actual deployment experience.
>
> For example, the current open source DTLS implementations that do non-PSK are 
> woefully small in number, and mostly derive from same, huge, and not so good 
> codebase (naming no names to be polite).
>
> There’s another (much more lightweight) scheme on how to (less well, 
> psk-only) secure DNCP stuff that I actually I use in my home; no draft, as I 
> did not want to muddle the waters, but it is essentially few lines of 
> Python[1] as opposed to half million lines of C that certain unnamed 
> SSL/TLS/DTLS implementation. Obviously it cannot be bootstrapped but neither 
> can be the most common type of DTLS - PSK-based.
>
> As the routing protocol choice was left up in the air for homenet, I consider 
> this to be much more thorny issue, and just saying ‘DTLS+$FOO’ seems 
> dangerous. Especially as none of the current solutions seem that appealing 
> (PSK = practically no go in terms of real deployment, consensus = unproven 
> new stuff, perhaps we want in-home CA?).
>
>> That being the case, I actually don't see any argument against making DTLS 
>> mandatory to implement.   You didn't give a reason for your opinion that we 
>> should not.   If you do have a reason for thinking that DTLS shouldn't be 
>> MTI, please state it plainly--your opinion may well be correct, but if we 
>> don't know why you have that opinion, we have no way to evaluate it other 
>> than to trust you or not, and that's not a good way to 

Re: [homenet] Stephen Farrell's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Markus Stenberg]

> On 19.11.2015, at 16.21, Stephen Farrell  wrote:
> (Sorry for the N-th discuss, I quite like this protocol and
> I'm sure we'll get 'em all cleared soon, but... ;-)
> 
> I'd like to chat about whether or not the DTLS recommendations
> are correct here. To me, the consensus stuff (from section 8.3
> of dncp) is not clearly baked (as I noted in iesg review of
> dncp). The PKI stuff is well known, even if it it is a PITA from
> many points of view. I don't think a SHOULD for the former and
> a MAY for the latter is appropriate now. If the consensus based
> stuff gets deployed and works, then it might be time to say
> what you're now saying, but I don't think we're there yet. (I'd
> be happy to look @ evidence that we are, and to change my
> opinion accordingly.)

Given bootstrapping PKI seems nigh impossible (home CA anyone?), I am not sure 
I agree with you.  I have done that few of times and do not recommend it to 
anyone. Of course, I guess at some point some products may make it painless but 
I am not sure I will live long enough to see that. (Especially so that the 
control stays still within home, and does not stray to some American ‘cloud 
server’, cough cough.)

> Please note that I think I like the consensus based scheme, I'm
> just concerned it may not be ready for prime time. I'm also not
> really convinced that all you need to do to get interop for
> that is mention it and refer to dncp. But again, I could be
> wrong and would appreciate being corrected if so.
> 
> In summary, I think you should say "when using DTLS with
> asymmetric keying, then you SHOULD support the PKI-based method
> and MAY support the consensus based method, which is still
> somewhat experimental.”

SHOULD/MAY neither provide really interoperability anyway, so I am mostly 
interested about MUSTs. Current PSK MUST I find rather sad, as that is clearly 
_not_ elegantly bootstrappable.

Trust consensus or even given some leap of faith about home CA <> cloudy CA the 
PKI-based method seem better in that regard. But I have not seen that much in 
the wild yet (see the ‘unproven’ argument in the other DISCUSS thread).

So given the context (ideally zeroconf, at least littleconf) home network, what 
would you pick for the PSK / PKI / trust consensus? Apparently SHOULD/MAY for 
the two later, but is PSK really the MUST here or is it the PKI?

> -Section 9: You should refer to HKDF and not HMAC-SHA256 though
> the reference to RFC 6234 is still right. HMAC-SHA256 itself
> is not a key derivation function, which is what you want here.

Good catch, thanks, staged for -10[1]. Essentially instead of HMAC-SHA256 
recommending HMAC-SHA256 based HKDF with the ‘info’ field the protocol being 
keyed.

> - Please take a look at the secdir review [1] and respond to
> that as it raises one issue not (I think) otherwise mentioned.
> What is the effect (on a home) of one compromised hncp router?
> Perhaps you'll say that's obvious, or perhaps not, but I'm 
> interested in what you do say, in case it's not obvious:-)
> 
>   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06098.html

It essentially broadens a number of on-link attacks to network-wide ones. 
Notably you can redirect arbitrary traffic wherever you want (without HNCP, you 
do RA/DHCPv4 faster than router on the link -> MITM), and DoS of the network 
instead of on-link nodes. Additionally of course it also provides view of the 
topology and the services that use TLVs encoded in HNCP node data so that can 
be used for various nefarious things as well. 

Cheers,

-Markus

[1] 
https://github.com/fingon/ietf-drafts/commit/7a140efa2693d9b0138654f5ec71e5888caa6777
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Barry Leiba's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Markus Stenberg]

On 20.11.2015, at 12.07, Steven Barth  wrote:
>> -- Section 13 --
>> I have two concerns with how the HNCP TLV Types registry is specified:
>> 
>> 1. Because the DNCP TLV Types registry specifically allocates 32-511 for
>> profiles, it'd be better to simply limit the range of values in this
>> registry to those values, rather than making it broader and duplicating
>> the other values from the other registry.
>> 
>> 2. I think it's a bad idea for HNCP to re-define DNCP's Private Use range
>> in its registry.  I would rather see this be text in the document (here
>> in the IANA Considerations is a fine place for it) that says that HNCP
>> uses the Private Use range for per-implementation experimentation, and
>> not have that be in the HNCP registry.
>> 
>> In other words, I'd make it more like this (and add a reference to RFC
>> 5226):
>> 
>> NEW
>>   IANA should set up a registry for the (decimal values within range
>>   32-511, as allocated to profiles by DNCP) "HNCP TLV Types" under
>>   "Distributed Node Consensus Protocol (DNCP)", with the following
>>   initial contents:
>> 
>>  32: HNCP-Version
>>  33: External-Connection
>>  34: Delegated-Prefix
>>  35: Assigned-Prefix
>>  36: Node-Address
>>  37: DHCPv4-Data
>>  38: DHCPv6-Data
>>  39: DNS-Delegated-Zone
>>  40: Domain-Name
>>  41: Node-Name
>>  42: Managed-PSK
>>  43: Prefix-Policy
>>  44-511: Unassigned
>> 
>>   The policy "RFC Required" [RFC5226] should be used for future
>>   assignments.
>> 
>>   The range reserved by DNCP for Private Use (768-1023) is used by
>>   HNCP for per-implementation experimentation.  How collisions are
>>   avoided is out of scope of this document.
>> END
>> 
>> Does that make sense?
> 
> Yes, I will talk to Markus about it, but from my point of view your
> suggestion looks good.

I am not so sure about it personally, mostly because this what lives on that 
port; if e.g. future DNCPv2 winds up redefining DNCP registry, or changes the 
behavior of the protocol in some drastic way _that is not desirable for HNCP_, 
I rather have HNCP stay the same. Therefore freezing the contents of the whole 
TLV space in one registry seems useful to me (for action that happens using 
same transport on same port(s) at any rate), but I do not care much the either 
way.

Whole DNCP registry in and of itself is bit questionable to me because it is 
not deployable in and of itself.

(e.g. Thomas C. argued that sticking in TLV definitions in DNCP was wrong move, 
and I agree with him but it was bit late in the game to change.)

Cheers,

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

Re: [homenet] Ben Campbell's No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)

[Ben Campbell]

On 20 Nov 2015, at 1:30, Markus Stenberg wrote:


On 18.11.2015, at 17.02, Steven Barth  wrote:
-6.4, first paragraph: "Each HNCP node SHOULD announce an IPv6 
address

and - if it supports IPv4 - MUST announce an IPv4 address,"
I don't suppose there's any way we can make IPv6 a MUST?
I guess we could unify both and make them both SHOULD or MUST. Right 
now

I can't really remember the argument for or against either but I will
discuss it with Markus.


This current MUST + SHOULD is actually result of developments during 
summer (not sure if it was this summer, but I suspect so). Note that 
it does NOT say that you MUST assign IPv4 and SHOULD assign IPv6; it 
talkes entirely about announcing the said assignment. The assignment 
is also used for conflict resolution, but (at the time) the people who 
discussed these noted that RFC7217 is unlikely to conflict, and 
therefore announcing the assignments is nice to have, but not 
mandatory (and you could also use e.g. DAD if you really wanted to as 
this is simply local state on a link). In case of IPv4, where we 
essentially pick out of /26, 1 in 64 chance of collision (1 in ~8 due 
to birthday paradox) was not considered as good odds and therefore it 
was made a MUST; there is no IPv4 DAD as fallback either.


I am not fine with SHOULD for IPv4 as it will essentially break it; I 
can live with MUST for IPv6 but consider it unneccessary. Let me know 
how you feel about it (or if we should add the justification text to 
the document).


Your answer makes perfect sense. My wishful thinking was just wishful.

Ben.

[...]

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

Re: [homenet] Ben Campbell's No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)

[Juliusz Chroboczek]

> I am not fine with SHOULD for IPv4 as it will essentially break it;

Agreed, but I don't feel strongly about it.

> I can live with MUST for IPv6 but consider it unneccessary.

Agreed, announcing your IPv6 address, if it's chosen randomly, just wastes
24 bytes * prefixes * nodes * interfaces.  That's 2.4kB of uselessly
flooded data in a mere 10 node network with two prefixes.  (Recall that
HNCP doesn't have link-local signalling or delayed flooding -- anything
that's announced must be flooded throughout the network in a timely manner.)

-- Juliusz

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

Re: [homenet] Barry Leiba's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Steven Barth]

Hello Barry,

thanks for your review.

On 19.11.2015 06:42, Barry Leiba wrote:
> --
> DISCUSS:
> --
> 
> I have two points that I'd like to discuss, both of which should be very
> easy to resolve:
> 
> -- Section 10.1 --
> For all the capability values you say something like this:
> 
>   It MUST be set to some value between 1 and 7
>   included (4 is the default) if the router is capable of proxying
>   MDNS and 0 otherwise.
> 
> First, the word you want is "inclusive", not "included".
> 
> Second, "4 is the default" really means that you can set it to 0, and
> that's the same as setting it to 4.  But it seems that 0 means that the
> router does not have the specified capability.  Those seem to be in
> conflict.  I strongly suggest you do NOT have a default, and allow the
> use of 0 *only* to designate lack of that capability.
> 
> Please discuss this with me to make sure I'm not misunderstanding you
> here.

I have changed them all to:

  It MUST be set to 0 if the router is not capable of doing FOO,
  otherwise it SHOULD be set to 4 but MAY be set to any value from 1 to
  7 to indicate a non-default priority. The values 8-15 are reserved
  for future use.

I hope this clears it up.


> -- Section 13 --
> I have two concerns with how the HNCP TLV Types registry is specified:
> 
> 1. Because the DNCP TLV Types registry specifically allocates 32-511 for
> profiles, it'd be better to simply limit the range of values in this
> registry to those values, rather than making it broader and duplicating
> the other values from the other registry.
> 
> 2. I think it's a bad idea for HNCP to re-define DNCP's Private Use range
> in its registry.  I would rather see this be text in the document (here
> in the IANA Considerations is a fine place for it) that says that HNCP
> uses the Private Use range for per-implementation experimentation, and
> not have that be in the HNCP registry.
> 
> In other words, I'd make it more like this (and add a reference to RFC
> 5226):
> 
> NEW
>IANA should set up a registry for the (decimal values within range
>32-511, as allocated to profiles by DNCP) "HNCP TLV Types" under
>"Distributed Node Consensus Protocol (DNCP)", with the following
>initial contents:
> 
>   32: HNCP-Version
>   33: External-Connection
>   34: Delegated-Prefix
>   35: Assigned-Prefix
>   36: Node-Address
>   37: DHCPv4-Data
>   38: DHCPv6-Data
>   39: DNS-Delegated-Zone
>   40: Domain-Name
>   41: Node-Name
>   42: Managed-PSK
>   43: Prefix-Policy
>   44-511: Unassigned
>   
>The policy "RFC Required" [RFC5226] should be used for future
>assignments.
> 
>The range reserved by DNCP for Private Use (768-1023) is used by
>HNCP for per-implementation experimentation.  How collisions are
>avoided is out of scope of this document.
> END
> 
> Does that make sense?

Yes, I will talk to Markus about it, but from my point of view your
suggestion looks good.



> --
> COMMENT:
> --
> 
> -- Section 1.1 --
> 
>As HNCP uses DNCP as the actual state synchronization protocol, the
>applicability statement of DNCP can be used here as well; HNCP should
>not be used for any data that changes rapidly and constantly, and
>locators to find such services should be published using it instead.
> 
> I don't follow the second half of that (after the semicolon): I don't get
> the antecedents to "such services" (there are no services mentioned) and
> "it" (maybe understanding "such" will help sort this part out).  Can you
> re-word this to make it clearer?

Changed to:

  As HNCP uses DNCP as the actual state synchronization protocol,
  the applicability statement of DNCP applies here as well; HNCP
  should not be used for any data that changes rapidly and constantly.
  If such data needs to be published in an HNCP network, a more
  applicable protocol should be used for those portions and locators
  to a server of said protocol can be announced using HNCP instead.
  An example for this is naming and service
  discovery for which HNCP only transports DNS server
  addresses, and no actual per-name or per-service data of hosts.


> 
> -- Section 3 --
> 
>3.  DNCP Profile
>The DNCP profile of HNCP is defined as follows:
> 
> That seems backwards to me; I'd say this is "the HNCP profile of DNCP",
> no?

changed to "DNCP profile *for* HNCP"

> 
>o  HNCP operates on multicast-capable interfaces only.  HNCP nodes
>   MUST assign a locally unique non-zero 32-bit endpoint identifier
>   to each interface for which HNCP is enabled.  The value zero it is
>   not used in DNCP TLVs, but it has a special meaning in HNCP TLVs
>   (see Section 

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

[Brian Haberman]

Hi Steven,
 Your response look good except for...

On 11/20/15 4:07 AM, Steven Barth wrote:
> 
>> * The definition of Leaf in 5.1 is unclear.  It says "Such an interface
>> uses the Internal category with the exception that HNCP traffic MUST NOT
>> be sent on the interface, and all such traffic received on the interface
>> MUST be ignored." The "all such traffic" is ambiguous. Based on the
>> definition of the Guest category, I think "all such traffic" is really
>> "all HNCP traffic".
> 
> I have changed it to
> 
>   Such an interface uses the Internal category with the exception that
>   it MUST NOT operate as a DNCP endpoint.
> 
> to be in line with the changed definitions for the internal and external
> categories (to address one of Ben's comments).
> 

Two things on this.  First, is a Leaf interface on the router facing
devices that don't support HNCP or on the hosts facing an HNCP router? I
would think you would want this to be a category on the router.  Second,
I don't quite understand "DNCP endpoint". There is no definition of that
in either this spec or the DNCP spec. So, I am not sure what that would
entail for an implementer.

Regards,
Brian



signature.asc
Description: OpenPGP digital signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Barry Leiba's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Barry Leiba]

>>> -- Section 13 --
>>> I have two concerns with how the HNCP TLV Types registry is specified:
>>>
>>> 1. Because the DNCP TLV Types registry specifically allocates 32-511 for
>>> profiles, it'd be better to simply limit the range of values in this
>>> registry to those values, rather than making it broader and duplicating
>>> the other values from the other registry.
>>>
>>> 2. I think it's a bad idea for HNCP to re-define DNCP's Private Use range
>>> in its registry.  I would rather see this be text in the document (here
>>> in the IANA Considerations is a fine place for it) that says that HNCP
>>> uses the Private Use range for per-implementation experimentation, and
>>> not have that be in the HNCP registry.
>>>
>>> In other words, I'd make it more like this (and add a reference to RFC
>>> 5226):
>>>
>>> NEW
>>>   IANA should set up a registry for the (decimal values within range
>>>   32-511, as allocated to profiles by DNCP) "HNCP TLV Types" under
>>>   "Distributed Node Consensus Protocol (DNCP)", with the following
>>>   initial contents:
>>>
>>>  32: HNCP-Version
>>>  33: External-Connection
>>>  34: Delegated-Prefix
>>>  35: Assigned-Prefix
>>>  36: Node-Address
>>>  37: DHCPv4-Data
>>>  38: DHCPv6-Data
>>>  39: DNS-Delegated-Zone
>>>  40: Domain-Name
>>>  41: Node-Name
>>>  42: Managed-PSK
>>>  43: Prefix-Policy
>>>  44-511: Unassigned
>>>
>>>   The policy "RFC Required" [RFC5226] should be used for future
>>>   assignments.
>>>
>>>   The range reserved by DNCP for Private Use (768-1023) is used by
>>>   HNCP for per-implementation experimentation.  How collisions are
>>>   avoided is out of scope of this document.
>>> END
>>>
>>> Does that make sense?
>>
>> Yes, I will talk to Markus about it, but from my point of view your
>> suggestion looks good.
>
> I am not so sure about it personally, mostly because this what lives
> on that port; if e.g. future DNCPv2 winds up redefining DNCP registry,
> or changes the behavior of the protocol in some drastic way _that is
> not desirable for HNCP_, I rather have HNCP stay the same. Therefore
> freezing the contents of the whole TLV space in one registry seems
> useful to me (for action that happens using same transport on same
> port(s) at any rate), but I do not care much the either way.
>
> Whole DNCP registry in and of itself is bit questionable to me because
> it is not deployable in and of itself.

I can still be convinced that this is the way to go, but I haven't
been yet, so let's please talk about it a bit more.

I see your point about the possibility that future DNCP updates could
change the registry, though that's always a problem, and that issue
should be caught during IANA and IESG review in the future: changes
that conflict with how HNCP uses the registry should be noticed and
questioned.

It seems to me (not having participated in the discussion of DNCP)
that DNCP registered some common TLV types to be used by all profiles,
and then set aside overlapping space for each profile to define its
own TLV types.  So...

1. there's common space left in which profiles can register common TLV
types that can be used by other profiles and...

2. there's profile-specific space in which profiles can register their
own TLV types that other profiles won't use (and where other profiles
will, in fact, use the same type numbers for their own purposes).

That all seems sensible.  And, given that, what makes the most sense
to me is for this profile to *only* specify allocation for the range
that was allocated for profile-specific stuff (and to use the base
DNCP registry for any other ranges).  Repeating information from one
registry into another is a bad recipe, more prone to future conflicts,
I think, than what you're concerned about.

How about this?:
Add something like this to my suggested change above:

NEW+
In the DNCP TLV Types registry, IANA is asked to change the
descriptions of two value ranges, as follows:

32-511, new description "Reserved for per-DNCP profile use; this range
is in active use by DNCP profiles and must remain reserved."

768-1023, new description "Reserved for Private Use; this range is in
active private use and must remain reserved."
END

Markus, would that address your concern about possible future changes?

Barry

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

Re: [homenet] Alissa Cooper's No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)

[Markus Stenberg]

Thanks for the comments ;)

On 18.11.2015, at 21.42, Alissa Cooper  wrote:
> -- How does a node end up in the leaf or guest category? Is it only if a
> fixed category is configured? If so, who decides that that configuration
> should happen? I think this info belongs in the draft.

Steven added some text on this related to some other DISCUSS:

>Note that all fixed categories
>except internal and external cannot be auto-detected and can only
>be selected using manual configuration.

> -- Section 5.1 says:
> 
> "Guest category:  This declares an interface used by untrusted client
>  devices only.  In addition to the restrictions of the Leaf
>  category, HNCP routers MUST filter traffic from and to the
>  interface such that connected devices are unable to reach other
>  devices inside the HNCP network or query services advertised by
>  them unless explicitly allowed."
> 
> What is the mechanism for explicitly allowing selective access for guest
> nodes? Is this left for firewall policy configuration? I think this
> warrants some explanation.

I think this is implementation choice for now; doing it interoperably is not 
within scope of this document at least, although someone could provide some 
HNCP TLVs for distributed firewall configuration in the future. (I am not sure 
if such exist in the IETF wild currently.)

> -- In Sec 6.4, I'm unclear on whether the address selection process
> specified in the bulleted list would ever be used to obtain a IPv6
> address. If not, then this comment is not relevant. But if it might be
> used in some case where the node is using v6 but for some reason cannot
> use the mechanism specified in RFC7217, I think additional guidance is
> needed here about self-assignment, in line with the ongoing work on
> draft-ietf-6man-default-iids. Nodes might be tempted to embed a
> link-layer address in the IID as a means of ensuring that their
> self-assigned addresses do not collide with others, but they should be
> discouraged from doing so. So I think some text to the effect that nodes
> SHOULD assign themselves semantically opaque addresses even if they
> cannot use the RFC7217 mechanism and SHOULD NOT embed the underlying
> link-layer address in the IID is warranted here.

I think it is essentially just fallback that I would rather not elaborate on - 
few reasons:

- RFC7217 is the SHOULD; not doing SHOULD requires good idea on why not to 
anyway
- the self-assignment preferences are likely to evolve over time (note: ongoing 
work)
- we are mostly talking about routers (=few connections outside the home) not 
hosts => I am not that worried about the IID hiding

However, if you can come up with a concise futureproof text that addresses the 
concern, I do not mind incorporating it. I personally am not sure how to phrase 
that. 

Cheers,

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

Re: [homenet] Barry Leiba's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Markus Stenberg]

On 20.11.2015, at 17.50, Barry Leiba  wrote:
> I can still be convinced that this is the way to go, but I haven't
> been yet, so let's please talk about it a bit more.
> 
> I see your point about the possibility that future DNCP updates could
> change the registry, though that's always a problem, and that issue
> should be caught during IANA and IESG review in the future: changes
> that conflict with how HNCP uses the registry should be noticed and
> questioned.

Yes, but not automatically rejected.

> It seems to me (not having participated in the discussion of DNCP)
> that DNCP registered some common TLV types to be used by all profiles,
> and then set aside overlapping space for each profile to define its
> own TLV types.  So…

Yeah, and I find that design more undesirable the more I think about it.

> 1. there's common space left in which profiles can register common TLV
> types that can be used by other profiles and...
> 
> 2. there's profile-specific space in which profiles can register their
> own TLV types that other profiles won't use (and where other profiles
> will, in fact, use the same type numbers for their own purposes).
> 
> That all seems sensible.  And, given that, what makes the most sense
> to me is for this profile to *only* specify allocation for the range
> that was allocated for profile-specific stuff (and to use the base
> DNCP registry for any other ranges).  Repeating information from one
> registry into another is a bad recipe, more prone to future conflicts,
> I think, than what you're concerned about.
> 
> How about this?:
> Add something like this to my suggested change above:
> 
> NEW+
> In the DNCP TLV Types registry, IANA is asked to change the
> descriptions of two value ranges, as follows:
> 
> 32-511, new description "Reserved for per-DNCP profile use; this range
> is in active use by DNCP profiles and must remain reserved."
> 
> 768-1023, new description "Reserved for Private Use; this range is in
> active private use and must remain reserved."
> END
> 
> Markus, would that address your concern about possible future changes?

Hmm. I am not quite sure about how this whole DNCP <> DNCP extensions <> DNCP#2 
maps to the two registries in my head, so not quite sure how it _should_ be 
addressed. However, as Steven already staged the changes limiting the registry 
range to 32-511, I guess I can live with that :)

To expand on my concern, while HNCP refers to a particular DNCP version, what 
about DNCP extensions and/or DNCPv2 relation to HNCP (and the related registry 
content changes if any). It is not clear that an arbitrary DNCP extension needs 
to be supported by a HNCP implementation (unless HNCP 1.1 spec refers to it), 
but just looking at the main DNCP registry will not really work well to see 
what is ’the current state’ HNCP implementor needs to follow.

Anyway, I can live with even what’s currently staged, just general unease about 
the ‘future’ with dual registry model. Having _just_ HNCP registry would have 
made this much more understandable for an implementor, and less likely to break 
in the future too.

Cheers,

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

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

[Steven Barth]

> Two things on this.  First, is a Leaf interface on the router facing
> devices that don't support HNCP or on the hosts facing an HNCP router? I
> would think you would want this to be a category on the router.  Second,
> I don't quite understand "DNCP endpoint". There is no definition of that
> in either this spec or the DNCP spec. So, I am not sure what that would
> entail for an implementer.
The leaf category can be used for interfaces of HNCP devices on which
it doesn't which to speak HNCP, e.g. where only non-HNCP devices
are expected to be, e.g. a WiFi AP for clients. The point is to not speak
 HNCP if you don't have to which can increase security (see 12.2).

"Endpoint" is used and defined in DNCP, I called it "DNCP Endpoint"
to indicate it comes from that draft, however i can remove the "DNCP"
if that would make it more clear.



Cheers,

Steven

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

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

[Markus Stenberg]

> On 20.11.2015, at 17.17, Kathleen Moriarty  
> wrote:
> 
> Hi Markus,
> 
> Thanks for your quick response, inline,
> 
> On Fri, Nov 20, 2015 at 10:07 AM, Markus Stenberg
>  wrote:
>> On 20.11.2015, at 16.47, Kathleen Moriarty 
>>  wrote:
 It is question of threats <-> risks  <-> mitigation analysis. Only thing 
 HNCP security really brings is _in case of insecure L2_ _some_ security 
 for routing/psk state. If we assume every other protocol is secured (e.g. 
 SEND, DHCPv6 ’secure mode’) it may be actually worthwhile, but as long as 
 e.g. DHCPv4 is not secure (and it will never be I suspect), the amount of 
 threats you actually take out of the picture by forcing ’securing’ HNCP 
 alone is not really significant.
 
 To sum it up: I recommend still SHOULD MTI, MUST MTU _if and only if_ L2, 
 but at least _my_ home does not _have_ any insecure L2, or at least 
 insecure in a sense that HNCP running there would be my greatest worry.
>>> If MTI is not a MUST, how can you MUST the MTU?
>> 
>> The MUST MTU here is only for (relatively small) subset of U cases. 
>> Therefore, if a product (or a network) does not see those cases happening, 
>> broad MTI/MTU causes extra bloat without any benefit (like my home network 
>> case I mentioned).
> Can you propose text that clearly describes this for developers and
> implementors to replace the current text and we'll see where we are
> at?  If it makes enough sense, I may be okay with that.  Stephen also
> supported my discuss, so both of us may need to review and possibly
> tweak it.  The current text isn't clear enough to convey what's been
> described int his thread.

I am not really a wordsmith, and as I am completely happy with the ’security of 
unicast traffic’ (given the delta in [1]), I am not really sure what is to be 
done about that. Perhaps Steven can come up with something.

The text currently looks as follows:

12.2.  Security of Unicast Traffic

   Once the homenet border has been established there are several ways
   to secure HNCP against internal threats like manipulation or
   eavesdropping by compromised devices on a link which is enabled for
   HNCP traffic.  If left unsecured, attackers may perform arbitrary
   traffic redirection, eavesdropping, spoofing or denial of service
   attacks on HNCP services such as address assignment or service
   discovery, and the protocols secured using HNCP-derived keys such as
   routing protocols.

   Detailed interface categories like "leaf" or "guest" can be used to
   integrate not fully trusted devices to various degrees into the
   homenet by not exposing them to HNCP traffic or by using firewall
   rules to prevent them from reaching homenet-internal resources.

   On links where this is not practical and lower layers do not provide
   adequate protection from attackers, DTLS-based secure unicast
   transport MUST be used to secure traffic.

Can you and Stephen come up with requirements on what exactly you want in this 
subsection?

>> Ah, sorry, simply too much mail backlog. ’secure mode’ in that context 
>> should be probably just secure _transport_ enabled on that particular 
>> link/for a particular remote endpoint, that is,  the {TLS,DTLS} based one 
>> described in the rest of the text.
> OK, then for the text where this shows up in this draft, please do
> replace it with what is meant exactly.
>> I wonder if we should edit dncp too, I don’t think that term appears 
>> anywhere elsewhere in the document.
> Yes, please.  Since it isn't defined anywhere, just stating what was
> intended would be much better.

Staged [1] for both dncp(-13) and hncp(-10) that removes ‘secure mode’ 
references. I suspect it is remainder of some much older text where we used the 
term more :) Good catch, thanks.

Cheers,

-Markus

[1] 
https://github.com/fingon/ietf-drafts/commit/363bd9b02108b4f05c03eaa68181a0f972de8c6c

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

Re: [homenet] Stephen Farrell's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Stephen Farrell]

On 20/11/15 15:35, Markus Stenberg wrote:
> 
> [1] 
> https://github.com/fingon/ietf-drafts/commit/f8275e165802a9c310f0bbde98e42087ecc891b1

Great, that's fine to sort my discuss point. I'll clear whenever
that's posted

Thanks,
S.

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

[homenet] Alia Atlas' No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)

[Alia Atlas]

Alia Atlas has entered the following ballot position for
draft-ietf-homenet-hncp-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-hncp/



--
COMMENT:
--

I support Brian's Discuss.

1)  In Sec 1.1, it states "...in homenet environments where multiple IPv6

   source-prefixes can be present, routing based on source and
destination 
   address is necessary [RFC7368]."
  
   Looking at RFC7368, I don't see anything that matches the strength of
this
   assertion which says in Sec 3.2.4 merely  "Another avenue is to
introduce support
   throughout the homenet for routing that is based on the source as
   well as the destination address of each packet."

   While src-dest routing is certainly a solution - and an interesting
one - it doesn't
   seem at all appropriate for an HNCP spec to assert that it is
necessary.

2) For the DNCP profile,  draft-ietf-homenet-dncp-12 says  "Anything
received over multicast, except Node Endpoint TLV (Section 7.2.1) and
Network State TLV (Section 7.2.2)." and this draft says "HNCP nodes MUST
ignore all Node State TLVs received via multicast
 on a link which has DNCP security enabled in order to prevent spoofing
of node state changes."
Could you please align and clarify the desired behavior for HNCP?


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

Re: [homenet] Stephen Farrell's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Michael Richardson]

Markus Stenberg  wrote:
>> I'd like to chat about whether or not the DTLS recommendations
>> are correct here. To me, the consensus stuff (from section 8.3
>> of dncp) is not clearly baked (as I noted in iesg review of
>> dncp). The PKI stuff is well known, even if it it is a PITA from
>> many points of view. I don't think a SHOULD for the former and
>> a MAY for the latter is appropriate now. If the consensus based
>> stuff gets deployed and works, then it might be time to say
>> what you're now saying, but I don't think we're there yet. (I'd
>> be happy to look @ evidence that we are, and to change my
>> opinion accordingly.)

> Given bootstrapping PKI seems nigh impossible (home CA anyone?), I am
> not sure I agree with you.  I have done that few of times and do not
> recommend it to anyone. Of course, I guess at some point some products
> may make it painless but I am not sure I will live long enough to see
> that. (Especially so that the control stays still within home, and does
> not stray to some American ‘cloud server’, cough cough.)

The IETF has chartered a group, ANIMA, which might produce something useable.
I don't think that homenet needs to invent something on it's own.

As long as HNCP *CAN* accomodate a one-level deep (no chains of trust) PKI,
then it should be good.  So the security has to be MTI, but MAY configure.

I do agree with Markus' here at present.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Steven Barth]

Hello Brian,

thanks for the comments.

On 19.11.2015 14:59, Brian Haberman wrote:
> --
> DISCUSS:
> --
> 
> * I see where HNCP describes how interfaces are classified as internal or
> external, but how does an interface get classified as leaf, guest, or
> ad-hoc?  Is this some manual configuration step that needs to be
> described somewhere?

These can only be manually selected. I have added a sentence:

  Note that all fixed categories
  except internal and external cannot be auto-detected and can only
  be selected using manual configuration.

to the second-last paragraph of the border discovery algorithm section.


> * The definition of Leaf in 5.1 is unclear.  It says "Such an interface
> uses the Internal category with the exception that HNCP traffic MUST NOT
> be sent on the interface, and all such traffic received on the interface
> MUST be ignored." The "all such traffic" is ambiguous. Based on the
> definition of the Guest category, I think "all such traffic" is really
> "all HNCP traffic".

I have changed it to

  Such an interface uses the Internal category with the exception that
  it MUST NOT operate as a DNCP endpoint.

to be in line with the changed definitions for the internal and external
categories (to address one of Ben's comments).


> * The text in section 5.3 seems incomplete. It gives a 4-step algorithm
> for border discovery, but says "if the node does not implement
> auto-detection, only the first step is required." If auto detection is
> not supported and a fixed category is not configured, what happens? Does
> this mean that if auto detection is not supported manual configuration of
> the border is required?

I changed it to "first and last" so the default is in line with the
default for the auto border discovery.


> * Section 7 describes how to handle non-HNCP capable routers. However, I
> don't see any operational issues described that could arise from having a
> non-HNCP capable router connecting two clouds of HNCP within the same
> home network. It seems like that could cause problems with a bunch of the
> services provided by HNCP.

I have added this as a paragraph to the applicability section:

  While HNCP routers can provide configuration to and receive
  configuration from non-HNCP routers, they are not able to traverse
  such devices based solely on the protocol as defined in this document,
  i.e., HNCP routers that are connected only by different interfaces
  of a non-HNCP router will not be part of the same HNCP network.


> --
> COMMENT:
> --
> 
> * Section 3 has several ambiguous/confusing statements:
> 
> 1. Does "locally unique" mean unique to the node or unique to the
> link/network?

Clarified.

> 
> 2. On a node ID collision, which node re-computes? The one detecting, I
> assume.

Correct.

> 
> 3. "7 doublings" is an odd phrase.  Why not say "Imin * 2^7"?
> 

That phrase actually comes from the Trickle RFC
"The maximum interval size, Imax, is described as a number of
  doublings of the minimum interval size (the base-2 log(max/min))."



Cheers,

Steven

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

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

[Mark Andrews]

In message <1447953139625-fadd659d-49861c14-8098f...@fugue.com>, Ted Lemon writ
es:
>
> Thursday, Nov 19, 2015 1:49 AM Brian E Carpenter wrote:
> >> Just to clarify, mandatory to implement doesn't mean you have to write
> >> the code.   It means the functionality has to be present in the deployed
> >> implementation so that two communicating partners can be configured to
> >> use it.
> >
> > Um, where is that defined? Is there a BCP that says that?
>
> It's not codified into law, but what else could it mean?   Why would we
> specify something as mandatory to implement if an expression of that
> implementation in running code did not actually contain the
> implementation?
>
> > I don't think a protocol spec can say that feature X cannot be ifdeffed.
> > It can say that a protocol must be capable of X and that implementations
> > must therefore be capable of X. But if you tell implementors that they
> > can't
> > ifdef unused stuff when building images for highly constrained nodes, I
> > don't think they will take you seriously.
>
> The protocol spec would just say MUST implement.   If the implementor
> wants to conditionalize the compilation of the code, we can't stop them
> from doing that, but then they don't have an implementation of the
> specification, and they shouldn't say "supports RFC XXX".   "supports RFC
> XXX" means that anything that is specified in the RFC is asserted to be
> functional in the implementation.
>
> They can perfectly well say "supports a subset of RFC XXX," and I can't
> imagine that anybody would object to that.

Unless they say what the subset they support / don't support, then
I object.  "partial support" is meaningless unless it is qualified.

> --
> Sent from Whiteout Mail - https://whiteout.io
> 
> My PGP key: https://keys.whiteout.io/mellon@fugue.=
> com
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

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

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

[Spencer Dawkins at IETF]

For what it's worth ...

On Thu, Nov 19, 2015 at 7:59 AM, Brian Haberman <br...@innovationslab.net>
wrote:

> Brian Haberman has entered the following ballot position for
> draft-ietf-homenet-hncp-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-hncp/
>
>
>
> --
> DISCUSS:
> --
>
> * I see where HNCP describes how interfaces are classified as internal or
> external, but how does an interface get classified as leaf, guest, or
> ad-hoc?  Is this some manual configuration step that needs to be
> described somewhere?
>
> * The definition of Leaf in 5.1 is unclear.  It says "Such an interface
> uses the Internal category with the exception that HNCP traffic MUST NOT
> be sent on the interface, and all such traffic received on the interface
> MUST be ignored." The "all such traffic" is ambiguous. Based on the
> definition of the Guest category, I think "all such traffic" is really
> "all HNCP traffic".
>
> * The text in section 5.3 seems incomplete. It gives a 4-step algorithm
> for border discovery, but says "if the node does not implement
> auto-detection, only the first step is required." If auto detection is
> not supported and a fixed category is not configured, what happens? Does
> this mean that if auto detection is not supported manual configuration of
> the border is required?
>
> * Section 7 describes how to handle non-HNCP capable routers. However, I
> don't see any operational issues described that could arise from having a
> non-HNCP capable router connecting two clouds of HNCP within the same
> home network. It seems like that could cause problems with a bunch of the
> services provided by HNCP.
>
>
> --
> COMMENT:
> --
>
> * Section 3 has several ambiguous/confusing statements:
>
> 1. Does "locally unique" mean unique to the node or unique to the
> link/network?
>
> 2. On a node ID collision, which node re-computes? The one detecting, I
> assume.
>
> 3. "7 doublings" is an odd phrase.  Why not say "Imin * 2^7"?


I don't think I"m reading this the same way Brian is, which does make a
case that it really is odd ...

Spencer


> * I support the other DISCUSS positions raised.
>
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ted Lemon]

Thursday, Nov 19, 2015 1:46 AM Mark Townsley wrote:
>> Just to clarify, mandatory to implement doesn't mean you have to write the 
>> code.
> 
> s/write/run ?

No, that's not the point I was making (apparently I'm not very good at 
clarifying).   What I mean is that MTI means that an implementation of what is 
specified will be able to use the thing that's MTI when it's called for.   So 
it can't be #ifdef'd out and still be an implementation of the specification.   
The mere fact that the code is there and could be compiled in does not mean the 
implementation conforms to the specification.   It has to actually be compiled 
in and operable.

As a general practice, ifdeffing out code that you've written tends not to be 
the right thing, because then it doesn't get tested and maintained.   c.f. 
"technical debt."


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mel...@fugue.com

pgpw2yewMXlrx.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ted Lemon]

Thursday, Nov 19, 2015 1:49 AM Brian E Carpenter wrote:
>> Just to clarify, mandatory to implement doesn't mean you have to write the 
>> code.   It means the functionality has to be present in the deployed 
>> implementation so that two communicating partners can be configured to use 
>> it.   
> 
> Um, where is that defined? Is there a BCP that says that?

It's not codified into law, but what else could it mean?   Why would we specify 
something as mandatory to implement if an expression of that implementation in 
running code did not actually contain the implementation?

> I don't think a protocol spec can say that feature X cannot be ifdeffed.
> It can say that a protocol must be capable of X and that implementations
> must therefore be capable of X. But if you tell implementors that they can't
> ifdef unused stuff when building images for highly constrained nodes, I
> don't think they will take you seriously.

The protocol spec would just say MUST implement.   If the implementor wants to 
conditionalize the compilation of the code, we can't stop them from doing that, 
but then they don't have an implementation of the specification, and they 
shouldn't say "supports RFC XXX".   "supports RFC XXX" means that anything that 
is specified in the RFC is asserted to be functional in the implementation.

They can perfectly well say "supports a subset of RFC XXX," and I can't imagine 
that anybody would object to that.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mel...@fugue.com

pgpAN9O3NxVoR.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Brian Haberman]

Brian Haberman has entered the following ballot position for
draft-ietf-homenet-hncp-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-hncp/



--
DISCUSS:
--

* I see where HNCP describes how interfaces are classified as internal or
external, but how does an interface get classified as leaf, guest, or
ad-hoc?  Is this some manual configuration step that needs to be
described somewhere?

* The definition of Leaf in 5.1 is unclear.  It says "Such an interface
uses the Internal category with the exception that HNCP traffic MUST NOT
be sent on the interface, and all such traffic received on the interface
MUST be ignored." The "all such traffic" is ambiguous. Based on the
definition of the Guest category, I think "all such traffic" is really
"all HNCP traffic".

* The text in section 5.3 seems incomplete. It gives a 4-step algorithm
for border discovery, but says "if the node does not implement
auto-detection, only the first step is required." If auto detection is
not supported and a fixed category is not configured, what happens? Does
this mean that if auto detection is not supported manual configuration of
the border is required?

* Section 7 describes how to handle non-HNCP capable routers. However, I
don't see any operational issues described that could arise from having a
non-HNCP capable router connecting two clouds of HNCP within the same
home network. It seems like that could cause problems with a bunch of the
services provided by HNCP.


--
COMMENT:
--

* Section 3 has several ambiguous/confusing statements:

1. Does "locally unique" mean unique to the node or unique to the
link/network?

2. On a node ID collision, which node re-computes? The one detecting, I
assume.

3. "7 doublings" is an odd phrase.  Why not say "Imin * 2^7"?

* I support the other DISCUSS positions raised.


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

[homenet] Stephen Farrell's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Stephen Farrell]

Stephen Farrell has entered the following ballot position for
draft-ietf-homenet-hncp-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-hncp/



--
DISCUSS:
--


(Sorry for the N-th discuss, I quite like this protocol and
I'm sure we'll get 'em all cleared soon, but... ;-)
 
I'd like to chat about whether or not the DTLS recommendations
are correct here. To me, the consensus stuff (from section 8.3
of dncp) is not clearly baked (as I noted in iesg review of
dncp). The PKI stuff is well known, even if it it is a PITA from
many points of view. I don't think a SHOULD for the former and
a MAY for the latter is appropriate now. If the consensus based
stuff gets deployed and works, then it might be time to say
what you're now saying, but I don't think we're there yet. (I'd
be happy to look @ evidence that we are, and to change my
opinion accordingly.)

Please note that I think I like the consensus based scheme, I'm
just concerned it may not be ready for prime time. I'm also not
really convinced that all you need to do to get interop for
that is mention it and refer to dncp. But again, I could be
wrong and would appreciate being corrected if so.

In summary, I think you should say "when using DTLS with
asymmetric keying, then you SHOULD support the PKI-based method
and MAY support the consensus based method, which is still
somewhat experimental."


--
COMMENT:
--

- I agree with Kathleen's discuss that the implementation
requirements for DTLS need to be clarified, hopefully (from my
POV) to make that MTI but I'll leave that discussion to the
other thread.

-Section 9: You should refer to HKDF and not HMAC-SHA256 though
the reference to RFC 6234 is still right. HMAC-SHA256 itself
is not a key derivation function, which is what you want here.

- Please take a look at the secdir review [1] and respond to
that as it raises one issue not (I think) otherwise mentioned.
What is the effect (on a home) of one compromised hncp router?
Perhaps you'll say that's obvious, or perhaps not, but I'm 
interested in what you do say, in case it's not obvious:-)

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06098.html


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

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

[Ted Lemon]

Wednesday, Nov 18, 2015 10:57 AM Juliusz Chroboczek wrote:
>> If you do have a reason for thinking that DTLS shouldn't be MTI, please
>> state it plainly
> 
> The mesh community has been using a wide range of techniques for
> configuring routers, static configuration, configuration protocols built
> into routing protocols, AHCP, etc.  I am currently working on promoting
> the use of a subset of HNCP instead.
> 
> This work is made difficult by the way the HNCP draft is written -- it is
> not immediately obvious that HNCP is a small and elegant protocol, and
> that most of the messy baggage is optional.  The general perception is "we
> don't need the complexity of HNCP, let's do something ad hoc".  See for
> example
> 
>   http://mid.gmane.org/87fv09u7uq.wl-...@pps.univ-paris-diderot.fr
> 
> Adding MTI DTLS to HNCP will only make this situation worse: either HNCP
> will be ignored by the communities, or the DTLS requirement will be
> ignored.  The latter will enforce the (widely held) belief that the IETF
> is a fossilised bureaucracy more interested in following its bureaucratic
> rules than producing useful documents.  Neither is a desirable outcome.

There is a reason why IETF standards are harder than ad hoc protocols: we 
specify what's needed to solve the problem generally and interoperably, and try 
to think about the problem from a systems perspective, not from the perspective 
of the immediate problem we have.Ad hoc protocols do not suffer from that 
constraint.

If someone's argument for why not to adopt HNCP is "it's too hard," then they 
are discounting the technical debt that they accumulate when they do a one-off 
ad hoc protocol.   Do you have any idea, for example, how much technical debt 
was accumulated with the simple decision many years ago to adopt dbus as the 
notification protocol for Linux?   That decision was made in precisely the way 
you describe, and the damage has been incalculable.   It barely works now, a 
decade later, and the idea of a "linux" desktop is a laughingstock due to this 
decision, among several other similar decisions made the same way.

There is a reason why the IETF seems slow.  It is because we think hard about 
problems, together, through a consensus process.   This definitely takes more 
time than just deciding to do something to solve the immediate problem.   The 
way the IETF competes with people who think that way is by producing protocols 
that actually work and are extensible, not by sinking to their level.   There 
are problems with the consensus process.   We sometimes get stuck in annoying 
ways, as with the routing discussion.  That was actually a process failure from 
which I hope all involved have learned (I certainly have).   The slower process 
is the price we pay for doing things the way we do, but please don't make the 
mistake of thinking that we get nothing for that price.

The bottom line is that I think the reason you have given for not making DTLS 
MTI is a really bad one.   There is a perfectly good DTLS implementation out 
there, which is quite easy to use as far as I can tell, and if people really 
think that they don't need to be thinking about security of network protocols 
in this day and age, then it's best that they fail quickly at minimal cost, and 
don't drag the network down with them.  I am really tired of crappy embedded 
network devices with no security, no upgrade path and no thought to system 
design.   We should not support the proliferation of such devices.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mel...@fugue.com

pgpMt5Bmriixp.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ted Lemon]

Wednesday, Nov 18, 2015 11:04 AM Henning Rogge wrote:
> I don't think DTLS with PSK is much better than WPA2 with PSK...

True.   And that does rule out tinydtls but there are quite a few other DTLS 
implementations available.   Is your point that we need to say more than just 
that DTLS is MTI?   Certainly the text requiring DTLS to protect symmetric key 
TLVs would need to be updated to address this point!


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mel...@fugue.com

pgpH2trkQegRS.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Brian E Carpenter]

Ted,

> The bottom line is that I think the reason you have given for not making DTLS 
> MTI is a really bad one.   There is a perfectly good DTLS implementation out 
> there, which is quite easy to use as far as I can tell,

So I am puzzled. If that is the case, it is not the HNCP implementer who has to
write any DTLS code (in my book, the word "implement" in a protocol spec means
"write code"). At most there would need to be a few extra instructions to wrap
a socket in DTLS, and that code would likely be ifdeffed because it would
only be used when needed. Which sounds exactly like a SHOULD to me.
Or maybe "mandatory to be able to switch on." In any case, not part of the
HNCP protocol itself.

Regards
   Brian

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

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

[Ted Lemon]

Wednesday, Nov 18, 2015 9:20 AM Steven Barth wrote:
> The basic idea behind the SHOULD is that there may be cases where either
> physical security of links (e.g. cables) can be ensured or link-layer
> security such as WPA for WiFi is present. In these cases (e.g. some sort
> homenet wifi repeater) the DTLS would be redundant.

WPA2, at least in PSK mode, does not provide confidentiality from attackers who 
have the PSK.   WPA isn't even as good as WPA2.   I think relying on this level 
of security makes sense if we have no alternative, but in no other case.

>   On links where this is not practical and lower layers do not provide
>   adequate protection from attackers, DNCP secure mode MUST be used to
>   secure traffic.
> 
> which should ensure that devices MUST use HNCP security over both
> physically and link-layer-wise unsecured links. I guess this could be
> reflected in the DNCP profile section as well if that makes it more clear.

So doesn't that make DTLS MTI already?   If so, maybe we should just say so 
explicitly.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mel...@fugue.com

pgphF76pcEmvv.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Henning Rogge]

On Wed, Nov 18, 2015 at 4:46 PM, Ted Lemon  wrote:
> Wednesday, Nov 18, 2015 9:20 AM Steven Barth wrote:
>> The basic idea behind the SHOULD is that there may be cases where either
>> physical security of links (e.g. cables) can be ensured or link-layer
>> security such as WPA for WiFi is present. In these cases (e.g. some sort
>> homenet wifi repeater) the DTLS would be redundant.
>
> WPA2, at least in PSK mode, does not provide confidentiality from attackers 
> who have the PSK.   WPA isn't even as good as WPA2.   I think relying on this 
> level of security makes sense if we have no alternative, but in no other case.

I don't think DTLS with PSK is much better than WPA2 with PSK...

Henning Rogge

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

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

[Juliusz Chroboczek]

>> HNCP is an amazingly flexible protocol, and one that will hopefully be
>> used well beyond it's original area of application.  Many of the possible
>> applications of HNCP don't require DTLS, either because the network is
>> secured at a lower layer, or because they use a different application
>> layer mechanism.

> Which possible applications of HNCP don't require security?

It's not about not requiring security -- it's about mandating this
particular security mechanism.

> If you do have a reason for thinking that DTLS shouldn't be MTI, please
> state it plainly

The mesh community has been using a wide range of techniques for
configuring routers, static configuration, configuration protocols built
into routing protocols, AHCP, etc.  I am currently working on promoting
the use of a subset of HNCP instead.

This work is made difficult by the way the HNCP draft is written -- it is
not immediately obvious that HNCP is a small and elegant protocol, and
that most of the messy baggage is optional.  The general perception is "we
don't need the complexity of HNCP, let's do something ad hoc".  See for
example

  http://mid.gmane.org/87fv09u7uq.wl-...@pps.univ-paris-diderot.fr

Adding MTI DTLS to HNCP will only make this situation worse: either HNCP
will be ignored by the communities, or the DTLS requirement will be
ignored.  The latter will enforce the (widely held) belief that the IETF
is a fossilised bureaucracy more interested in following its bureaucratic
rules than producing useful documents.  Neither is a desirable outcome.

-- Juliusz

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

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

[Juliusz Chroboczek]

> There is a reason why IETF standards are harder than ad hoc protocols: we
> specify what's needed to solve the problem generally and interoperably,

A lot of the MUST in HNCP are not about interoperability, they are about
mandating the features that we want Homenet routers that we have.  In
other words, HNCP does not distinguish between "MUST or else you won't
interoperate" and "MUST because we are Homenet and we tell you so".

> If someone's argument for why not to adopt HNCP is "it's too hard," then
> they are discounting the technical debt that they accumulate when they do
> a one-off ad hoc protocol.

That's very well put, and exactly what I'm trying to explain to the
community.  Please help me do that rather than adding to the perception
that HNCP contains dozens of random, arbitrary requirements.

> There is a reason why the IETF seems slow.

You're changing the subject, Ted.  Nobody mentioned timeliness.

I'm arguing against making strong requirements that will be ignored by any
sensible implementer.  "Hey, you don't need to deploy that, but you still
MUST carry the dead code in your implementation".

How much more silly can one get?

-- Juliusz

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

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

[Kathleen Moriarty]

Sent from my iPhone

> On Nov 18, 2015, at 12:23 PM, Brian E Carpenter  
> wrote:
> 
> Ted,
> 
>> The bottom line is that I think the reason you have given for not making 
>> DTLS MTI is a really bad one.   There is a perfectly good DTLS 
>> implementation out there, which is quite easy to use as far as I can tell,
> 
> So I am puzzled. If that is the case, it is not the HNCP implementer who has 
> to
> write any DTLS code (in my book, the word "implement" in a protocol spec means
> "write code"). At most there would need to be a few extra instructions to wrap
> a socket in DTLS, and that code would likely be ifdeffed because it would
> only be used when needed. Which sounds exactly like a SHOULD to me.
> Or maybe "mandatory to be able to switch on." In any case, not part of the
> HNCP protocol itself.

Hmm, I'm reading it the same way as Ted.  Right now, you have a SHOULD use and 
while I'm okay with that, a MUST implement enables the option for the SHOULD 
use, but that they are separate.

If there is a strong enough argument against MTI, I'll be okay with that.  I 
haven't seen it yet.  The SHOULD use can stay to meet some of the arguments 
stated, but can a MUST implement be added?

Thanks,
Kathleen 

> 
> Regards
>   Brian
> 

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

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

[Kathleen Moriarty]

Hi Steven,

Thanks for your response and text suggestions.  Inline.

Sent from my iPhone

> On Nov 18, 2015, at 9:20 AM, Steven Barth  wrote:
> 
> Hello Kathleen,
> 
> thanks for the review.
> 
>> 1. I'm not clear on one of the bullets in section 3, 
>>  o  HNCP nodes MUST use the leading 64 bits of MD5 [RFC1321] as DNCP
>>  non-cryptographic hash function H(x).
>> 
>> Is this meant to use a message digest (RFC1321) or a cryptographic hash
>> for authentication (RFC2104)?  If it's the former, can you make this more
>> clear in the bullet?  If it's the latter, can you update the reference
>> and the number of bits to use for truncation is 80 for the minimum.  You
>> do explicitly mention HMACs later on for PSKs using SHA256, so maybe the
>> reference is correct and the wording should just be a bit more clear?
> 
> I have staged this text now:
> 
>  HNCP nodes MUST use the leading 64 bits of the   target="RFC1321">MD5 message digest as the DNCP hash function
>  H(x) used in building the DNCP hash tree.
> 
> I hope that makes it more clear, that the hash is only used for
> comparison and to detect changes, not as a form of signature or
> authentication.
> 

This does help, thank you!
> 
>> 2. Can you explain why DTLS is a SHOULD and not a MUST?  The bullet in
>> section 3 reads as if this is for use, not implementation.  Is there a
>> MUST for implementation (I didn't see one, but maybe I missed that)?
> 
> The basic idea behind the SHOULD is that there may be cases where either
> physical security of links (e.g. cables) can be ensured or link-layer
> security such as WPA for WiFi is present. In these cases (e.g. some sort
> homenet wifi repeater) the DTLS would be redundant.
> 
> In the Security Considerations sections we currently have a requirement:
> 
>  On links where this is not practical and lower layers do not provide
>  adequate protection from attackers, DNCP secure mode MUST be used to
>  secure traffic.

This may be okay.  I will have to look at the draft again to see the references 
for DNCP security and will get back yo you as soon as I can do that.  I've had 
some day job responsibilities this morning.
> 
> which should ensure that devices MUST use HNCP security over both
> physically and link-layer-wise unsecured links. I guess this could be
> reflected in the DNCP profile section as well if that makes it more clear.
> 
> Would that work better or do you have something different in mind?
> 

More later.  Thanks again!
Kathleen 
> 
>> 
>> Could you add a reference to RFC7525 to help with configuration and
>> cipher suite recommendations?  This could be in section 12, security
>> considerations.
> 
> Staged for next revision.
> 
> 
> 
> Cheers,
> 
> Steven

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

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

[Ted Lemon]

Wednesday, Nov 18, 2015 8:24 AM Juliusz Chroboczek wrote:
> HNCP is an amazingly flexible protocol, and one that will hopefully be
> used well beyond it's original area of application.  Many of the possible
> applications of HNCP don't require DTLS, either because the network is
> secured at a lower layer, or because they use a different application
> layer mechanism.

Which possible applications of HNCP don't require security?   The problem we 
have with HNCP is that we have no basis for establishing trust, not that we 
don't need security.

The argument against DTLS that I think makes some sense is "we don't know how 
to key it, and therefore don't know if it will work if/when we figure out 
security," not "we don't need it."   I actually have a great deal of sympathy 
for Kathleen's view here; if we make DTLS MTI, then at least we'll have an 
encryption/authentication mechanism when we figure out how we want to do that.

I think there's a pretty strong case to be made that the security mechanism 
will require public key cryptography.   If that's the case, then DTLS will work 
as an encryption/authentication layer.   The fact that the current draft refers 
to DTLS and makes it mandatory to use when transmitting pre-shared keys means 
that we've already got consensus that DTLS is a necessary option for 
encryption/authentication.

That being the case, I actually don't see any argument against making DTLS 
mandatory to implement.   You didn't give a reason for your opinion that we 
should not.   If you do have a reason for thinking that DTLS shouldn't be MTI, 
please state it plainly--your opinion may well be correct, but if we don't know 
why you have that opinion, we have no way to evaluate it other than to trust 
you or not, and that's not a good way to do standards work.   If the concern is 
whether there's a good DTLS implementation that can be used, I don't know how 
good it is but tinydtls looks like it might work.   It uses a license that is 
GPL-compatible.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mel...@fugue.com

pgpebceVopOW5.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Juliusz Chroboczek]

Dear Kathleen,

> 2. Can you explain why DTLS is a SHOULD and not a MUST?  The bullet in
> section 3 reads as if this is for use, not implementation.  Is there a
> MUST for implementation (I didn't see one, but maybe I missed that)? 

I am not one of the authors of the draft, but I'm the author of the
independent reimplementation of HNCP (shncpd), so I have a fair
understanding of what the protocol does.

HNCP is an amazingly flexible protocol, and one that will hopefully be
used well beyond it's original area of application.  Many of the possible
applications of HNCP don't require DTLS, either because the network is
secured at a lower layer, or because they use a different application
layer mechanism.

To many people, a "Should Deploy, Must Implement" requirement in HNCP will
just seem like an arbitrary and useless hoop, and will needlessly reduce
the prestige and authority of the IETF.  If a MUST related to DTLS in
Homenet is required (and this is open to discussion), it belongs in
a different document, not in the HNCP protocol specification.

Regards,

-- Juliusz

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

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

[Steven Barth]

Hello Benoit,


thanks for the review.


On 18.11.2015 15:20, Benoit Claise wrote:
> One issue to be discussed: the link with the future BCP
> draft-ietf-v6ops-reducing-ra-energy-consumption-03, on the same telechat.
> 
> draft-ietf-v6ops-reducing-ra-energy-consumption-03 mentions:
>"On links with a large number of battery-powered devices, sending
>solicited Router Advertisements multicast can severely impact host
>power consumption."
> 
>>From this document: I see "HNCP operates on multicast-capable interfaces
> only"
> Do we expect battery-powered devices in homenet? I guess so: my phone for
> example.
> I discussed this topic with Mark Townsley, who is on it already.

DNCP (and thus HNCP) uses multicast only for unsolicited messages, e.g.
messages triggered by Trickle. Every solicited message (= reply to a
multicast or unicast packet) MUST always be sent using unicast. This is
mandated in the DNCP draft. So I think there should not be an inherent
conflict with this draft here.



> 
> 
> --
> COMMENT:
> --
> 
>As HNCP uses DNCP as the actual state synchronization protocol, the
>applicability statement of DNCP can be used here as well; HNCP should
>not be used for any data that changes rapidly and constantly, and
>locators to find such services should be published using it instead.
>This is why the naming and service discovery (Section 8) TLVs contain
>only DNS server addresses, and no actual per-name or per-service data
>of hosts.
> 
> What is it in in "using it"? If DNCP, then it contradicts
> https://tools.ietf.org/html/draft-ietf-homenet-dncp-12#section-1.1:
> 
> However, there are certain cases where the protocol as defined in
> this document is a less suitable choice. ...  frequently changing
> data:  DNCP with its use of Trickle is
> optimized for the steady state and less efficient otherwise.
> 
> Chatting with Mark Townsley, he proposed some clarifying text:
> HNCP should not be used directly for data that changes rapidly and
> constantly, though
> stable locators to find such data by other means may be advertised
> within HNCP.

Okay we will discuss this one in the coming days and try to come up with
something more clear.


> - Each HNCP router MAY obtain external connection information such as
>address prefixes, DNS server addresses and DNS search paths from one
>or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241] or
>static configuration. 
> 
> If you know pf the YANG model already, you should mention it.
We don't yet, but it would probably be something defining network
interface related. I will try to investigate if there is a relevant RFC
already that we could reference.


> Below is Sheng's OPS-DIR review.
Sorry, that somehow slipped through my radar until today, I just sent a
direct reply to that mail-thread.



Cheers,

Steven

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

Re: [homenet] Ben Campbell's No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)

[Steven Barth]

Hello Ben,

thanks for the review.


> --
> COMMENT:
> --
> 
> Minor Issues:
> ===
> 
> -4, 1st paragraph, last sentence:
> I confused by the fact this sentence says nodes MUST include
> HNCP-Version, then goes on to talk about nodes _not_ including it.

I added a note that the presence of the TLV indicates the support for
the currently defined HNCP version. The idea is that in case there are
other DNCP nodes that speak a different HNCP version their information
is still spread in the DNCP sense, but not interpreted.


> -6.4, first paragraph: "Each HNCP node SHOULD announce an IPv6 address
> and - if it supports IPv4 - MUST announce an IPv4 address,"
> I don't suppose there's any way we can make IPv6 a MUST?

I guess we could unify both and make them both SHOULD or MUST. Right now
I can't really remember the argument for or against either but I will
discuss it with Markus.


> -7.4, 2nd paragraph:
> The MUST seems to conflict with the SHOULD in the third paragraph of
> section 8.

That conflict is ruled out by the MUST in 10.1
 It MUST be set to some value between 1 and 7
 included (4 is the default) if the router is capable of proxying
 MDNS and 0 otherwise.

and the election mechanism. If it doesn't support an MDNS proxy
(disobeying the SHOULD) it MUST announce its mdns-capability as 0 and
thus will never be elected and never be subject to the MUST in 7.4. 2nd
paragraph.


> 
> -14.2:
> It looks like some, maybe most, of the informative references  need to be
> normative. They are cited with 2119 language,  cited in other protocol
> definition, or are otherwise required to fully understand this draft:
> 3004, 2131, 3315, 3633, 4291, 1321, 6762, 6763, 2132, 4193, 7084, 7217,
> 4861, and 6092.

Ok we will reevaluate the references in the coming days and see which of
those should be promoted.

> 
> 
> Editorial Comments:
> =
> 
> -4, 2nd paragraph: "Any node announcing the value 0 is considered to not
> advertise the respective capability and thus does not take part in the
> respective election."
> 
> Am I correct to assume this means "any node announcing the value 0 for a
> particular capability..."?
Yes, clarified.

> 
> - 5.1:"Internal category":"HNCP traffic MUST be sent and received."
> What must send and receive it? (Similar comments for External Category).
Changed to "The interface MUST (NOT) operate as a DNCP endpoint"


> 
> -6.5:
> Please expand "ULA" on first mention.
Done.

> 
> - 9, 1st paragraph: "The scheme SHOULD be used only in conjunction"
> "SHOULD ... only" is a subtle way of saying SHOULD NOT. I suggest the
> following:
> OLD:
> The scheme SHOULD be used only in conjunction...
> NEW:
> The scheme SHOULD NOT be used unless in conjunction...
Staged for next revision.


> 
> - 14.3:
> Looks like neither URL will be cited once the RFC editor removes the
> appendices marked for deletion.

Okay, will try to see if we can convince xml2rfc to mark this section
for removal somehow. Otherwise we probably need to manually modify the
.txt



Cheers,

Steven

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

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

[Steven Barth]

Hello Kathleen,

thanks for the review.

> 1. I'm not clear on one of the bullets in section 3, 
>   o  HNCP nodes MUST use the leading 64 bits of MD5 [RFC1321] as DNCP
>   non-cryptographic hash function H(x).
> 
> Is this meant to use a message digest (RFC1321) or a cryptographic hash
> for authentication (RFC2104)?  If it's the former, can you make this more
> clear in the bullet?  If it's the latter, can you update the reference
> and the number of bits to use for truncation is 80 for the minimum.  You
> do explicitly mention HMACs later on for PSKs using SHA256, so maybe the
> reference is correct and the wording should just be a bit more clear?

I have staged this text now:

  HNCP nodes MUST use the leading 64 bits of the MD5 message digest as the DNCP hash function
  H(x) used in building the DNCP hash tree.

I hope that makes it more clear, that the hash is only used for
comparison and to detect changes, not as a form of signature or
authentication.


> 2. Can you explain why DTLS is a SHOULD and not a MUST?  The bullet in
> section 3 reads as if this is for use, not implementation.  Is there a
> MUST for implementation (I didn't see one, but maybe I missed that)? 

The basic idea behind the SHOULD is that there may be cases where either
physical security of links (e.g. cables) can be ensured or link-layer
security such as WPA for WiFi is present. In these cases (e.g. some sort
homenet wifi repeater) the DTLS would be redundant.

In the Security Considerations sections we currently have a requirement:

  On links where this is not practical and lower layers do not provide
  adequate protection from attackers, DNCP secure mode MUST be used to
  secure traffic.

which should ensure that devices MUST use HNCP security over both
physically and link-layer-wise unsecured links. I guess this could be
reflected in the DNCP profile section as well if that makes it more clear.

Would that work better or do you have something different in mind?


> 
> Could you add a reference to RFC7525 to help with configuration and
> cipher suite recommendations?  This could be in section 12, security
> considerations.

Staged for next revision.



Cheers,

Steven

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

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

[Benoit Claise]

Benoit Claise has entered the following ballot position for
draft-ietf-homenet-hncp-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-hncp/



--
DISCUSS:
--

One issue to be discussed: the link with the future BCP
draft-ietf-v6ops-reducing-ra-energy-consumption-03, on the same telechat.

draft-ietf-v6ops-reducing-ra-energy-consumption-03 mentions:
   "On links with a large number of battery-powered devices, sending
   solicited Router Advertisements multicast can severely impact host
   power consumption."

>From this document: I see "HNCP operates on multicast-capable interfaces
only"
Do we expect battery-powered devices in homenet? I guess so: my phone for
example.
I discussed this topic with Mark Townsley, who is on it already.


--
COMMENT:
--

   As HNCP uses DNCP as the actual state synchronization protocol, the
   applicability statement of DNCP can be used here as well; HNCP should
   not be used for any data that changes rapidly and constantly, and
   locators to find such services should be published using it instead.
   This is why the naming and service discovery (Section 8) TLVs contain
   only DNS server addresses, and no actual per-name or per-service data
   of hosts.

What is it in in "using it"? If DNCP, then it contradicts
https://tools.ietf.org/html/draft-ietf-homenet-dncp-12#section-1.1:

However, there are certain cases where the protocol as defined in
this document is a less suitable choice. ...  frequently changing
data:  DNCP with its use of Trickle is
optimized for the steady state and less efficient otherwise.

Chatting with Mark Townsley, he proposed some clarifying text:
HNCP should not be used directly for data that changes rapidly and
constantly, though
stable locators to find such data by other means may be advertised
within HNCP.



- Each HNCP router MAY obtain external connection information such as
   address prefixes, DNS server addresses and DNS search paths from one
   or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241] or
   static configuration. 

If you know pf the YANG model already, you should mention it.


Below is Sheng's OPS-DIR review.

1. HNCP describes Prefix and Naming configuration. But it is not very
clear how they are matched in the DNCP architecture. It would be help to
understand if some description using DNCP architecture, like node state
and network state, etc., could be added.

2. It would be very useful to add a bootstrap and configuration procedure
of HNCP. So far, this is not clear.

3. Section 6.5 "only the one published by the node with the highest node
identifier". It is not very clear how to compare the value against node
identifier.


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

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

[Kathleen Moriarty]

On Wed, Nov 18, 2015 at 1:39 PM, Kathleen Moriarty
 wrote:
> Hi Steven,
>
> Thanks for your response and text suggestions.  Inline.
>
> Sent from my iPhone
>
>> On Nov 18, 2015, at 9:20 AM, Steven Barth  wrote:
>>
>> Hello Kathleen,
>>
>> thanks for the review.
>>
>>> 1. I'm not clear on one of the bullets in section 3,
>>>  o  HNCP nodes MUST use the leading 64 bits of MD5 [RFC1321] as DNCP
>>>  non-cryptographic hash function H(x).
>>>
>>> Is this meant to use a message digest (RFC1321) or a cryptographic hash
>>> for authentication (RFC2104)?  If it's the former, can you make this more
>>> clear in the bullet?  If it's the latter, can you update the reference
>>> and the number of bits to use for truncation is 80 for the minimum.  You
>>> do explicitly mention HMACs later on for PSKs using SHA256, so maybe the
>>> reference is correct and the wording should just be a bit more clear?
>>
>> I have staged this text now:
>>
>>  HNCP nodes MUST use the leading 64 bits of the >  target="RFC1321">MD5 message digest as the DNCP hash function
>>  H(x) used in building the DNCP hash tree.
>>
>> I hope that makes it more clear, that the hash is only used for
>> comparison and to detect changes, not as a form of signature or
>> authentication.
>>
>
> This does help, thank you!
>>
>>> 2. Can you explain why DTLS is a SHOULD and not a MUST?  The bullet in
>>> section 3 reads as if this is for use, not implementation.  Is there a
>>> MUST for implementation (I didn't see one, but maybe I missed that)?
>>
>> The basic idea behind the SHOULD is that there may be cases where either
>> physical security of links (e.g. cables) can be ensured or link-layer
>> security such as WPA for WiFi is present. In these cases (e.g. some sort
>> homenet wifi repeater) the DTLS would be redundant.
>>
>> In the Security Considerations sections we currently have a requirement:
>>
>>  On links where this is not practical and lower layers do not provide
>>  adequate protection from attackers, DNCP secure mode MUST be used to
>>  secure traffic.
>
> This may be okay.  I will have to look at the draft again to see the 
> references for DNCP security and will get back yo you as soon as I can do 
> that.  I've had some day job responsibilities this morning.

I don't see any references for "DNCP secure mode" in this draft.  I
see the term used in
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/?include_text=1

but that is also without reference.  Can you point me to the
definition for "DNCP secure mode"?  This may help, I'm not sure until
I can see the definition and can understand if it addresses the points
or not.

Thank you!
Kathleen

>>
>> which should ensure that devices MUST use HNCP security over both
>> physically and link-layer-wise unsecured links. I guess this could be
>> reflected in the DNCP profile section as well if that makes it more clear.
>>
>> Would that work better or do you have something different in mind?
>>
>
> More later.  Thanks again!
> Kathleen
>>
>>>
>>> Could you add a reference to RFC7525 to help with configuration and
>>> cipher suite recommendations?  This could be in section 12, security
>>> considerations.
>>
>> Staged for next revision.
>>
>>
>>
>> Cheers,
>>
>> Steven



-- 

Best regards,
Kathleen

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

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

[Ted Lemon]

Wednesday, Nov 18, 2015 12:23 PM Brian E Carpenter wrote:
>> The bottom line is that I think the reason you have given for not making 
>> DTLS MTI is a really bad one.   There is a perfectly good DTLS 
>> implementation out there, which is quite easy to use as far as I can tell,
> 
> So I am puzzled. If that is the case, it is not the HNCP implementer who has 
> to
> write any DTLS code (in my book, the word "implement" in a protocol spec means
> "write code"). At most there would need to be a few extra instructions to wrap
> a socket in DTLS, and that code would likely be ifdeffed because it would
> only be used when needed. Which sounds exactly like a SHOULD to me.
> Or maybe "mandatory to be able to switch on." In any case, not part of the
> HNCP protocol itself.

That's why I said MTI, not MTU!   But MTI means not #ifdef.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mel...@fugue.com

pgp1m0Tk51mCt.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Ben Campbell's No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)

[Ben Campbell]

Thanks! A couple of remaining comments below. I removed sections that 
don't seem to need further discussion.


Ben.

On 18 Nov 2015, at 9:02, Steven Barth wrote:


[...]



-6.4, first paragraph: "Each HNCP node SHOULD announce an IPv6 
address

and - if it supports IPv4 - MUST announce an IPv4 address,"
I don't suppose there's any way we can make IPv6 a MUST?


I guess we could unify both and make them both SHOULD or MUST. Right 
now

I can't really remember the argument for or against either but I will
discuss it with Markus.


This was really wishful thinking on my part. I don't expect a change. I 
was mainly reacting to IPv4 being a MUST and IPv6 not.  OTOH, I'd be 
equally happy if neither were MUSTSs.






-7.4, 2nd paragraph:
The MUST seems to conflict with the SHOULD in the third paragraph of
section 8.


That conflict is ruled out by the MUST in 10.1
It MUST be set to some value between 1 and 7
included (4 is the default) if the router is capable of proxying
MDNS and 0 otherwise.

and the election mechanism. If it doesn't support an MDNS proxy
(disobeying the SHOULD) it MUST announce its mdns-capability as 0 and
thus will never be elected and never be subject to the MUST in 7.4. 
2nd

paragraph.


IIUC, a router that doesn't support MDNS will never be elected. So is 
the statement in 7.4 that an elected router MUST support MDNS 
constraining in any way?


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

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

[Ted Lemon]

Wednesday, Nov 18, 2015 11:28 AM Juliusz Chroboczek wrote:
>> If someone's argument for why not to adopt HNCP is "it's too hard," then
>> they are discounting the technical debt that they accumulate when they do
>> a one-off ad hoc protocol.
> 
> That's very well put, and exactly what I'm trying to explain to the
> community.  Please help me do that rather than adding to the perception
> that HNCP contains dozens of random, arbitrary requirements.

That's what I thought I was doing by writing that message!   I am not sure it's 
helpful for me to pop up on the olsr mailing list and start talking about this, 
and I also don't really have time, but I will see what I can do.

>> There is a reason why the IETF seems slow.
> 
> You're changing the subject, Ted.  Nobody mentioned timeliness.

That's how I read what you said.   I don't think it matters--whether it's 
timeliness or complexity, there are definitely costs to writing standards for 
everybody to follow.

> I'm arguing against making strong requirements that will be ignored by any
> sensible implementer.  "Hey, you don't need to deploy that, but you still
> MUST carry the dead code in your implementation".

Right, but I am disputing your claim that they don't need to deploy that.   
Deploying it may be a regrettably manual process at the moment, but I think it 
is very much needed.
 
> How much more silly can one get?

I suspect that collectively we can get very silly indeed, should we choose to 
seriously put this question to the test, but perhaps that's more of a thing for 
a bar bof than a working group... ;)


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mel...@fugue.com

pgpPofihiBuuk.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Barry Leiba's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Barry Leiba]

Barry Leiba has entered the following ballot position for
draft-ietf-homenet-hncp-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-hncp/



--
DISCUSS:
--

I have two points that I'd like to discuss, both of which should be very
easy to resolve:

-- Section 10.1 --
For all the capability values you say something like this:

  It MUST be set to some value between 1 and 7
  included (4 is the default) if the router is capable of proxying
  MDNS and 0 otherwise.

First, the word you want is "inclusive", not "included".

Second, "4 is the default" really means that you can set it to 0, and
that's the same as setting it to 4.  But it seems that 0 means that the
router does not have the specified capability.  Those seem to be in
conflict.  I strongly suggest you do NOT have a default, and allow the
use of 0 *only* to designate lack of that capability.

Please discuss this with me to make sure I'm not misunderstanding you
here.

-- Section 13 --
I have two concerns with how the HNCP TLV Types registry is specified:

1. Because the DNCP TLV Types registry specifically allocates 32-511 for
profiles, it'd be better to simply limit the range of values in this
registry to those values, rather than making it broader and duplicating
the other values from the other registry.

2. I think it's a bad idea for HNCP to re-define DNCP's Private Use range
in its registry.  I would rather see this be text in the document (here
in the IANA Considerations is a fine place for it) that says that HNCP
uses the Private Use range for per-implementation experimentation, and
not have that be in the HNCP registry.

In other words, I'd make it more like this (and add a reference to RFC
5226):

NEW
   IANA should set up a registry for the (decimal values within range
   32-511, as allocated to profiles by DNCP) "HNCP TLV Types" under
   "Distributed Node Consensus Protocol (DNCP)", with the following
   initial contents:

  32: HNCP-Version
  33: External-Connection
  34: Delegated-Prefix
  35: Assigned-Prefix
  36: Node-Address
  37: DHCPv4-Data
  38: DHCPv6-Data
  39: DNS-Delegated-Zone
  40: Domain-Name
  41: Node-Name
  42: Managed-PSK
  43: Prefix-Policy
  44-511: Unassigned
  
   The policy "RFC Required" [RFC5226] should be used for future
   assignments.

   The range reserved by DNCP for Private Use (768-1023) is used by
   HNCP for per-implementation experimentation.  How collisions are
   avoided is out of scope of this document.
END

Does that make sense?


--
COMMENT:
--

-- Section 1.1 --

   As HNCP uses DNCP as the actual state synchronization protocol, the
   applicability statement of DNCP can be used here as well; HNCP should
   not be used for any data that changes rapidly and constantly, and
   locators to find such services should be published using it instead.

I don't follow the second half of that (after the semicolon): I don't get
the antecedents to "such services" (there are no services mentioned) and
"it" (maybe understanding "such" will help sort this part out).  Can you
re-word this to make it clearer?

-- Section 3 --

   3.  DNCP Profile
   The DNCP profile of HNCP is defined as follows:

That seems backwards to me; I'd say this is "the HNCP profile of DNCP",
no?

   o  HNCP operates on multicast-capable interfaces only.  HNCP nodes
  MUST assign a locally unique non-zero 32-bit endpoint identifier
  to each interface for which HNCP is enabled.  The value zero it is
  not used in DNCP TLVs, but it has a special meaning in HNCP TLVs
  (see Section 10.3 and Section 6.4).  Implementations MAY use a
  value equivalent to the IPv6 link-local scope identifier for the
  given interface.

I want to probe that "MAY" for a moment.  Of course, implementations can
use anything they want to, right?  So what's the point of calling out the
scope identifier specifically?  Is it because that's a particularly
convenient ur useful value?  Is it something you're recommending (but not
at the "RECOMMEND" level)?  If so, it might be better to say that, rather
than saying "MAY"; the "MAY" seems rather useless here.

  *  Imax 

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

[Juliusz Chroboczek]

>> That's very well put, and exactly what I'm trying to explain to the
>> community.  Please help me do that rather than adding to the perception
>> that HNCP contains dozens of random, arbitrary requirements.

> That's what I thought I was doing by writing that message!  I am not
> sure it's helpful for me to pop up on the olsr mailing list

You already know that, Ted, but I'd like to clarify for the list.

It's not a simple matter of sending a few mailing list messages -- it's
a long-term effort that consists of writing portable, open source,
lightweight implementations (hnetd, shncpd), of deploying HNCP ourselves
(Paris network, Henning's network somewhere in Germany), of getting HNCP
implementations into Linux and Unix distributions (OpenWRT by Steven,
Debian/Ubuntu soon, I'm not telling), of speaking to people at community
meetings (Battlemesh, IETF, CCC, FOSDEM), in short, making HNCP familiar
and easily available.

(And as we're trying to communicate our message in a clear and accurate
manner, how helpful it is to be able to say that a feature is "mandatory
to implement, optional to use, but you're not allowed to #ifdef it away".)

-- Juliusz

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

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

[Ted Lemon]

Wednesday, Nov 18, 2015 6:49 PM Juliusz Chroboczek wrote:
> It's not a simple matter of sending a few mailing list messages -- it's
> a long-term effort that consists of writing portable, open source,
> lightweight implementations (hnetd, shncpd), of deploying HNCP ourselves
> (Paris network, Henning's network somewhere in Germany), of getting HNCP
> implementations into Linux and Unix distributions (OpenWRT by Steven,
> Debian/Ubuntu soon, I'm not telling), of speaking to people at community
> meetings (Battlemesh, IETF, CCC, FOSDEM), in short, making HNCP familiar
> and easily available.

Sure, that's fair enough.

> (And as we're trying to communicate our message in a clear and accurate
> manner, how helpful it is to be able to say that a feature is "mandatory
> to implement, optional to use, but you're not allowed to #ifdef it away".)

Just to clarify, mandatory to implement doesn't mean you have to write the 
code.   It means the functionality has to be present in the deployed 
implementation so that two communicating partners can be configured to use it.  
 Mandatory to use means that the functionality has to be used at all times.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mel...@fugue.com

pgpfoxsWeI4Te.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Brian E Carpenter]

On 19/11/2015 17:14, Ted Lemon wrote:
> Wednesday, Nov 18, 2015 6:49 PM Juliusz Chroboczek wrote:
>> It's not a simple matter of sending a few mailing list messages -- it's
>> a long-term effort that consists of writing portable, open source,
>> lightweight implementations (hnetd, shncpd), of deploying HNCP ourselves
>> (Paris network, Henning's network somewhere in Germany), of getting HNCP
>> implementations into Linux and Unix distributions (OpenWRT by Steven,
>> Debian/Ubuntu soon, I'm not telling), of speaking to people at community
>> meetings (Battlemesh, IETF, CCC, FOSDEM), in short, making HNCP familiar
>> and easily available.
> 
> Sure, that's fair enough.
> 
>> (And as we're trying to communicate our message in a clear and accurate
>> manner, how helpful it is to be able to say that a feature is "mandatory
>> to implement, optional to use, but you're not allowed to #ifdef it away".)
> 
> Just to clarify, mandatory to implement doesn't mean you have to write the 
> code.   It means the functionality has to be present in the deployed 
> implementation so that two communicating partners can be configured to use 
> it.   

Um, where is that defined? Is there a BCP that says that?

I don't think a protocol spec can say that feature X cannot be ifdeffed.
It can say that a protocol must be capable of X and that implementations
must therefore be capable of X. But if you tell implementors that they can't
ifdef unused stuff when building images for highly constrained nodes, I
don't think they will take you seriously.

   Brian


Mandatory to use means that the functionality has to be used at all times.
> 
> 
> --
> Sent from Whiteout Mail - https://whiteout.io
> 
> My PGP key: https://keys.whiteout.io/mel...@fugue.com
> 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 

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

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

[Carsten Bormann]

Brian E Carpenter wrote:
>> Just to clarify, mandatory to implement doesn't mean you have to write the 
>> code.   It means the functionality has to be present in the deployed 
>> implementation so that two communicating partners can be configured to use 
>> it.   
> 
> Um, where is that defined? Is there a BCP that says that?
> 
> I don't think a protocol spec can say that feature X cannot be ifdeffed.
> It can say that a protocol must be capable of X and that implementations
> must therefore be capable of X. But if you tell implementors that they can't
> ifdef unused stuff when building images for highly constrained nodes, I
> don't think they will take you seriously.

Maybe slightly off-topic for homenet, but +1000 for constrained node
networks.

Grüße, Carsten

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

[homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)

[Kathleen Moriarty]

Kathleen Moriarty has entered the following ballot position for
draft-ietf-homenet-hncp-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-hncp/



--
DISCUSS:
--

I have a couple of pints to discuss that should be pretty easy to resolve
as I wasn't clear on the first because of wording (should be very simple)
and would like to chat about the second.  Thanks.

1. I'm not clear on one of the bullets in section 3, 
  o  HNCP nodes MUST use the leading 64 bits of MD5 [RFC1321] as DNCP
  non-cryptographic hash function H(x).

Is this meant to use a message digest (RFC1321) or a cryptographic hash
for authentication (RFC2104)?  If it's the former, can you make this more
clear in the bullet?  If it's the latter, can you update the reference
and the number of bits to use for truncation is 80 for the minimum.  You
do explicitly mention HMACs later on for PSKs using SHA256, so maybe the
reference is correct and the wording should just be a bit more clear?

2. Can you explain why DTLS is a SHOULD and not a MUST?  The bullet in
section 3 reads as if this is for use, not implementation.  Is there a
MUST for implementation (I didn't see one, but maybe I missed that)? 

Could you add a reference to RFC7525 to help with configuration and
cipher suite recommendations?  This could be in section 12, security
considerations.




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

[homenet] Ben Campbell's No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)

[Ben Campbell]

Ben Campbell has entered the following ballot position for
draft-ietf-homenet-hncp-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-hncp/



--
COMMENT:
--

Minor Issues:
===

-4, 1st paragraph, last sentence:
I confused by the fact this sentence says nodes MUST include
HNCP-Version, then goes on to talk about nodes _not_ including it.

-6.4, first paragraph: "Each HNCP node SHOULD announce an IPv6 address
and - if it supports IPv4 - MUST announce an IPv4 address,"
I don't suppose there's any way we can make IPv6 a MUST?

-7.4, 2nd paragraph:
The MUST seems to conflict with the SHOULD in the third paragraph of
section 8.

-14.2:
It looks like some, maybe most, of the informative references  need to be
normative. They are cited with 2119 language,  cited in other protocol
definition, or are otherwise required to fully understand this draft:
3004, 2131, 3315, 3633, 4291, 1321, 6762, 6763, 2132, 4193, 7084, 7217,
4861, and 6092.


Editorial Comments:
=

-4, 2nd paragraph: "Any node announcing the value 0 is considered to not
advertise the respective capability and thus does not take part in the
respective election."

Am I correct to assume this means "any node announcing the value 0 for a
particular capability..."?

- 5.1:"Internal category":"HNCP traffic MUST be sent and received."
What must send and receive it? (Similar comments for External Category).

-6.5:
Please expand "ULA" on first mention.

- 9, 1st paragraph: "The scheme SHOULD be used only in conjunction"
"SHOULD ... only" is a subtle way of saying SHOULD NOT. I suggest the
following:
OLD:
The scheme SHOULD be used only in conjunction...
NEW:
The scheme SHOULD NOT be used unless in conjunction...

- 14.3:
Looks like neither URL will be cited once the RFC editor removes the
appendices marked for deletion.


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

[homenet] I-D Action: draft-ietf-homenet-hncp-09.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Home Networking Working Group of the IETF.

Title   : Home Networking Control Protocol
Authors : Markus Stenberg
  Steven Barth
  Pierre Pfister
Filename: draft-ietf-homenet-hncp-09.txt
Pages   : 39
Date: 2015-08-31

Abstract:
   This document describes the Home Networking Control Protocol (HNCP),
   an extensible configuration protocol and a set of requirements for
   home network devices.  HNCP is described as a profile of and
   extension to the Distributed Node Consensus Protocol (DNCP).  HNCP
   enables discovery of network borders, automated configuration of
   addresses, name resolution, service discovery, and the use of any
   routing protocol which supports routing based on both source and
   destination address.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-homenet-hncp-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-hncp-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-09.txt

[Steven Barth]

Hi everyone,

this is HNCP revision 9. This version addresses the issues raised in the second
WGLC. Changes include final adaptions to the latest DNCP version (updated TLV
definitions, improved version handling), as well as clarifications to client
configuration and naming.


Cheers,

Steven




Am 31.08.2015 um 20:09 schrieb internet-dra...@ietf.org:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>  This draft is a work item of the Home Networking Working Group of the IETF.
> 
> Title   : Home Networking Control Protocol
> Authors : Markus Stenberg
>   Steven Barth
>   Pierre Pfister
>   Filename    : draft-ietf-homenet-hncp-09.txt
>   Pages   : 39
>   Date: 2015-08-31
> 
> Abstract:
>This document describes the Home Networking Control Protocol (HNCP),
>an extensible configuration protocol and a set of requirements for
>home network devices.  HNCP is described as a profile of and
>extension to the Distributed Node Consensus Protocol (DNCP).  HNCP
>enables discovery of network borders, automated configuration of
>addresses, name resolution, service discovery, and the use of any
>routing protocol which supports routing based on both source and
>destination address.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-homenet-hncp-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-hncp-09
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 

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

Re: [homenet] HNCP WGLC

[Steven Barth]

Hi Douglas,

it is a bit hard for me to decipher your mail or
extract what is relevant wrt. to the HNCP I-D.


 Sorry for the delay.  We were attempting to complete a
 security related draft on the topic.
Are you preparing a generic draft on homenet security or is
this specific to HNCP or DNS-SD? Do you have an ETA or can you share
the relevant pieces for HNCP (can be in private to Markus, Pierre and me)
upfront so we can address them in the next HNCP revision? We'd rather like
to go ahead asap, that is probably release a new revision early next week,
fixing all the things that came up during LC. Most of that is already
staged in our git.


 A few issues may be a concern.  The required support of UDP
 4000 byte packets in Section 3 DNCP Profile suggests there
 may be a concern. Section 2.1.4. Amplification Issues of
 https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threats-00
 describes considerations not covered in RFC6762, RFC6763 or
 RFC7368 when aggregate sizes of RRsets are overlooked,
 especially in such environments.
I do not think amplification attacks wrt. HNCP are particularly relevant
given you can mitigate them by using (DNCP) security. I also don't get the
RRset thing? Are you referring to SD and Naming TLVs in HNCP or was this not
intended to be relevant for HNCP?


 This section, as well as the Security Considerations
 section, does not ensure local resources are not externally
 exposed.
Which section? RFC 6092 is supposed to be followed by edge routers as HNCP
references 7084 and applies it to HNCP interfaces, however it might be a good
idea to explicitly reference RFC 6092 in our own Security Considerations in 
12.1.
where we merely state A firewall perimeter is set up for the external 
interfaces
without any further references. We might as well just do that.



Cheers,

Steven

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

Re: [homenet] HNCP WGLC

[Markus Stenberg]

On 27.8.2015, at 9.26, Steven Barth cy...@openwrt.org wrote:
 A few issues may be a concern.  The required support of UDP
 4000 byte packets in Section 3 DNCP Profile suggests there
 may be a concern. Section 2.1.4. Amplification Issues of
 https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threats-00
 describes considerations not covered in RFC6762, RFC6763 or
 RFC7368 when aggregate sizes of RRsets are overlooked,
 especially in such environments.
 I do not think amplification attacks wrt. HNCP are particularly relevant
 given you can mitigate them by using (DNCP) security. I also don't get the
 RRset thing? Are you referring to SD and Naming TLVs in HNCP or was this not
 intended to be relevant for HNCP?

HNCP has nothing to do with RRsets, and HNCP only runs _within_ home. In-home 
amplification attacks sound far-fetched, especially as HNCP itself (given DTLS 
at least) is relatively hard to attack in such a way.

If there are concerns about the definition of home and not-home being unclear, 
diffs are welcome. However, at worst case, given no firewalls and wrong 
interface category, ISP may attack the home router _from the next hop_ only, 
due to link-local addresses being only ones specified (also in the Section 3). 
I consider this somewhat unlikely to be a real threat.

Cheers,

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

[homenet] HNCP WGLC

[Ray Bellis]

Homenet WG,

This is just a quick reminder that the WGLC on
draft-ietf-homenet-hncp-08 is due to finish this Friday, 28th August.

If you have any further comments please get them in ASAP.

thanks,

Ray and Mark.

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

Re: [homenet] HNCP WGLC

[Douglas Otis]

On 8/26/15 6:21 AM, Ray Bellis wrote:
 Homenet WG,
 
 This is just a quick reminder that the WGLC on
 draft-ietf-homenet-hncp-08 is due to finish this Friday, 28th August.
 
 If you have any further comments please get them in ASAP.

Dear Ray,

Sorry for the delay.  We were attempting to complete a
security related draft on the topic.

A few issues may be a concern.  The required support of UDP
4000 byte packets in Section 3 DNCP Profile suggests there
may be a concern.  Section 2.1.4. Amplification Issues of
https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threats-00
describes considerations not covered in RFC6762, RFC6763 or
RFC7368 when aggregate sizes of RRsets are overlooked,
especially in such environments.

This section, as well as the Security Considerations
section, does not ensure local resources are not externally
exposed.

Regards,
Douglas Otis


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

Re: [homenet] HNCP and connected interfaces

[Juliusz Chroboczek]

A node MUST be able to detect whether two of its local internal
interfaces are connected, e.g., by detecting an identical remote
interface being part of the Common Links of both local interfaces.
 
 What should the node do if it detects that two interfaces are on the same
 link?

Ok, I've looked at the spec, I've looked at my code, and it's still not
entirely clear what needs to be done in that case.  Steven, is the
following correct:

  - the algorithm that causes DNCP to avoid id collisions needs to be
modified so that a node doesn't attempt to negociate with itself;
  - the definition of precedence in PA needs to be changed so that one of
the interfaces takes precedence over the other one.

Is that correct, and is that all I need to do?

-- Juliusz

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

Re: [homenet] HNCP and connected interfaces

[james woodyatt]

On Aug 18, 2015, at 10:45, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr 
wrote:
 
 Section 6.1 says:
 
  A node MUST be able to detect whether two of its local internal
  interfaces are connected, e.g., by detecting an identical remote
  interface being part of the Common Links of both local interfaces.
 
 Seems like this could be improved by rephrasing it to the effect that
 a node with multiple interfaces on the same common link MUST NOT
 advertise inconsistent information among them.
 
 That's too weak -- it also needs to take care to perform prefix assignment
 only once (although it will probably want to perform address assignment on
 both interfaces, especially if they're in ad-hoc mode), to run only one
 instance of RA and DHCPv4, etc.
 
 I'd really like to see it spelled out.

Doesn’t section 6.3.1 already spell that out?

 Set of Shared Links: […] When multiple interfaces are
   detected as belonging to the same Common Link, prefix assignment
   is disabled on all of these interfaces except one.


—james

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

Re: [homenet] HNCP and connected interfaces

[Juliusz Chroboczek]

 Section 6.1 says:
 
   A node MUST be able to detect whether two of its local internal
   interfaces are connected, e.g., by detecting an identical remote
   interface being part of the Common Links of both local interfaces.

 Seems like this could be improved by rephrasing it to the effect that
 a node with multiple interfaces on the same common link MUST NOT
 advertise inconsistent information among them.

That's too weak -- it also needs to take care to perform prefix assignment
only once (although it will probably want to perform address assignment on
both interfaces, especially if they're in ad-hoc mode), to run only one
instance of RA and DHCPv4, etc.

I'd really like to see it spelled out.

-- Juliusz

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

Re: [homenet] HNCP and connected interfaces

[james woodyatt]

On Aug 18, 2015, at 06:38, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr 
wrote:
 
 Section 6.1 says:
 
   A node MUST be able to detect whether two of its local internal
   interfaces are connected, e.g., by detecting an identical remote
   interface being part of the Common Links of both local interfaces.
 
 What should the node do if it detects that two interfaces are on the same
 link?  (Disable HNCP on one interface?  Speak HNCP on both interfaces but
 disable prefix assignment?  Something even more exciting?)

Seems like this could be improved by rephrasing it to the effect that a node 
with multiple interfaces on the same common link MUST NOT advertise 
inconsistent information among them.


—james

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

Re: [homenet] HNCP and connected interfaces

[Steven Barth]

Am 18.08.2015 um 19:45 schrieb Juliusz Chroboczek:
 That's too weak -- it also needs to take care to perform prefix assignment
 only once (although it will probably want to perform address assignment on
 both interfaces, especially if they're in ad-hoc mode), to run only one
 instance of RA and DHCPv4, etc.
 
 I'd really like to see it spelled out.

How about adding In this case the respective interfaces MUST be treated as
belonging to a single shared Common Link.?

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

Re: [homenet] HNCP and connected interfaces

[Juliusz Chroboczek]

James:

 Doesn’t section 6.3.1 already spell that out?
 
 Set of Shared Links: […] When multiple interfaces are
   detected as belonging to the same Common Link, prefix assignment
   is disabled on all of these interfaces except one.

Steven:

 How about adding In this case the respective interfaces MUST be treated as
 belonging to a single shared Common Link.?

Ah, I missed that.  Steven, yes, this deserves a pointer.

Is that really all there is to it?  I run two instances of PA (but
treating them as a single common link), two instances of RA, two instances
of DHCPv4?

-- Juliusz

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

[homenet] HNCP and connected interfaces

[Juliusz Chroboczek]

Section 6.1 says:

   A node MUST be able to detect whether two of its local internal
   interfaces are connected, e.g., by detecting an identical remote
   interface being part of the Common Links of both local interfaces.

What should the node do if it detects that two interfaces are on the same
link?  (Disable HNCP on one interface?  Speak HNCP on both interfaces but
disable prefix assignment?  Something even more exciting?)

-- Juliusz

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

Re: [homenet] HNCP: avoiding renumbering

[Gert Doering]

Hi,

On Sun, Aug 16, 2015 at 11:57:07PM -0700, Toerless Eckert wrote:
 I don't know why Juliusz called stable storage bad. 

I'd assume it has to do with flash write cycles on $30 routers...

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279

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

Re: [homenet] HNCP nits re DHCPv4

[Juliusz Chroboczek]

 I might experiment with working around some of these issues by using RFC
 3203 and RFC 6704 (forcerenew with nonce authentication, which is
 reportedly implemented by dhcpcd).  If you have experience with this
 subprotocol, please drop me a note.

 The problem is we can't rely on it since it is not widely supported by
 clients.

Chicken and egg.  If you put it in hnetd, the clients will come.

 4. Section 7.3 says DHCPv4 lease times SHOULD be short (i.e., not longer
than 5 minutes) in order to provide reasonable response times to
changes.  I'm not sure that's necessary -- wouldn't a longer lease
time but with a low rebind timer (T2 in RFC 2131) be more robust?

 That was the intended meaning, it has been a while since I dealt with DHCPv4,
 but IIRC there is no lease time besides T1 and T2, anyway clarified.

Yes there is, option 51; it's the time at which you unconditionally
discard a lease even if you didn't manage to rebind it.  I think there
are some tradeoffs between decreasing T2 and decreasing the lease time,
and I'm not sure I fully understand what they are.

The requirement L-9 is modified, in that the M flag MUST be set
if and only if a router connected to the respective Common Link
is advertising a non-zero H-capability.  The O flag SHOULD
always be set.

If I'm reading this correctly, you're saying that a Homenet router SHOULD
implement stateless DHCPv6.  That seems like a somewhat arbitrary
requirement -- could you please explain the rationale?

-- Juliusz

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

Re: [homenet] HNCP: avoiding renumbering

[Juliusz Chroboczek]

 I don't know why Juliusz called stable storage bad.

Ideology.

Soft state good, hard state bad.  A network protocol should be able to
recover all the data it needs just by consulting its neighbours.  If it
needs stable storage to function, then it's a failed design.

Yeah, I know, I'm a fanatic.

 Where would i be without stable storage for my routers software, policy
 configuration, passwords, logs and the like.

That's okay, static configuration data is not protocol state.

-- Juliusz

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