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