Re: [homenet] naming drafts

[Ray Hunter (v6ops)]

Stephen Farrell wrote on 07/06/2021 21:32:


Hi Michael,

On 05/06/2021 19:46, Michael Richardson wrote:

Well, I'd be happy to discuss with this them again, but they'd have to
actually tell us what "DDNS" really is for them.


Just to clarify: I don't think/claim DDNS is "better" than
the proposal here, rather I don't find the arguments as to
why this is "better" convincing, and so, given that DDNS is
deployed, and has some similarity, I'm wondering if this
spec really has much of a chance at gaining traction.

As a result, I don't really think there's that much value
in attempting a point-scoring exercise comparing the two,
the question for me is really whether or not this spec is
so much better than DDNS that it could displace DDNS, and
I'm not convinced as of now. (But I'm often wrong of course.)

Cheers,
S.


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


Just trying to understand this hurdle/ line of reasoning.

So in addition to achieving "rough consensus", the IETF standardization 
process must also produce drafts that are very likely to gain traction 
to displace non-IETF non-standardised products that are already widely 
commercially deployed?


If that is the case, then perhaps the WG should have steered the draft 
to have been "DDNS, but standardised" or "a TR-069 compatible interface 
for DNS zone delegation".


--
regards,
RayH

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

Re: [homenet] [dhcwg] WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12

[Ray Hunter (v6ops)]

Hi Ted, thanks for the comment.

I agree.

Plus one more point.

The ISP hosts the reverse zone.
The ISP also controls any reverse zone to customer assignments, and is 
in control of any renumbering.
The ISP may therefore choose to simply wipe any reverse zone content 
after renumbering occurs.

That would mitigate any re-use or privacy concerns.

Otherwise the HNA may no longer have authority over the content after a 
flash renumbering (e.g. if the ISP is simply authenticating customers 
based on source address of the updates)


regards,

Ted Lemon wrote on 05/05/2021 18:42:
On May 5, 2021, at 11:44 AM, Michael Richardson > wrote:

The end user might suffer slightly by having locally served
reverse names that are no longer connected: they should obsolete that 
zone

when they realize that their PD hasn't been renewed, until such time,
(if it was a flash renumber), they would be right to think that they
legitimately control them.


In practice I don’t think this is an issue. The reverse lookup is 
usually triggered by receipt of a message from an IP address, so as 
long as the IP address is still in use internally, the presence of the 
reverse zone is wanted. When the address changes, the old zone becomes 
obsolete whether it continues to be served or not. The likelihood of 
the zone being re-allocated to some other network for which the 
original network will then do a reverse lookup is very small, so I 
don’t think there’s any reason to be concerned about this.




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


--
regards,
RayH

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

Re: [homenet] draft-ietf-homenet-naming-architecture-dhc-options-08

[Ray Hunter (v6ops)]

Hi Daniel,

I have a question both for this draft and our "own" Homenet draft

Up until now we've been passing the specification of the DM * Reverse DM 
connections via separate configuration parameters: address/name, port 
number, and transport protocol.


Should we instead be using a DNS URI from 
https://tools.ietf.org/html/rfc4501?


That reduces the DM spec to a single parameter that is also extensible 
for the future.


regards,

Daniel Migault wrote on 01/04/2021 18:18:

Hi Bernie,

I apology for missing that email. Your comments addressed an old 
version, however most of them applies to the new version.  I think all 
comments have been addressed on my working local copy and I provide 
more details on how we addressed them.


I do have one remaining question regarding the IANA section on whether 
the specific values associated to a field of the DHCP option are part 
of the IANA section with the creation of a new registry or not.


Please see inline my response for more details.


Thanks for the review!

Yours,
Daniel

*From:* Bernie Volz (volz) 
*Sent:* Tuesday, March 9, 2021 11:54 AM
*To:* draft-ietf-homenet-naming-architecture-dhc-opti...@ietf.org 


*Subject:* draft-ietf-homenet-naming-architecture-dhc-options-08

Hi:

Took a quick look at the document … just a few nits to point out:

 1. You use “Homnet” in 2 places; I think that should be Homenet?


fixed thanks.


 2. For the FQDN option data, please make sure you refer to encoding
used is specified in https://tools.ietf.org/html/rfc8415#section-10

< mglt>
thanks, the encoding has been specified for all FQDN data, i.e., the 
Registered Domain, the Distribusion Master and Reverse Distribution 
Master.



 3. In 4.1, the diagram shows “Public Key Data” yet the definition
below it has “Client Public Key Data”; fix them to match.


This has been fixed in the previous version by removing these options.


 4. Sometimes you indicate the “length” of the data in the options,
sometimes you don’t; and “(varaiable)” is used in one place which
is misspelled.


Variable has been fixed. I suppose the these comments has been fixed 
from the latest version. As far as i can see, the current version has 
(variable) indicated for all variable fields. and option-len field in 
each description.




 5. You still reference RFC3315 when current DHCPv6 standard is RFC8415.


I have updated the reference. Thanks.


 6. The IANA considerations needs some work. You might see

https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/15/?include_text=1
as an example of a recent very good IANA considerations section.


I have updated the IANA section. I do have one remaining question.
One option specifies the the values of a field in a DHCP option. I am 
wondering if a specific registry needs to be created or not. For now I 
have assumed yes. The IANA section looks like:


IANA is requested to assign the following new DHCPv6 Option Codes in 
the registry maintained in: 
https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2. 



~~~
Value Description                   Client ORO     Singleton Option
TBD1  OPTION_REGISTERED_DOMAIN      Yes            Yes
TBD2  OPTION_DIST_MASTER            Yes            Yes
TBD3  OPTION_REVERSE_DIST_MASTER    Yes            Yes
~~~

The document also requests a Supported Transport Registry:

~~~
Bit | Transport Protocol | Reference
++---
 0  | DNS over TLS       |
 1  | DNS over HTTPS     |
2-7 | unallocated        |
~~~



  * Bernie



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


--
regards,
RayH

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

Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-08.txt

[Ray Hunter (v6ops)]

Hi Daniel,

Thanks for publishing this draft.

I have a three comments/concerns.

Firstly: "this option is also defined in [I-D.ietf-dhc-sedhcpv6]."

I just want to clarify that you are going to provide a new option code, 
but with the identical semantics.


I do think you need a separate code to avoid parsing ambiguity.

But also going forward if the specification is amended, then this would 
also be amended for this usage.


i.e. s/DNSKEY RDATA format as defined in [RFC4034]/DNSKEY RDATA format 
as defined in [RFC4034] or as amended/ ?


Second: I was planning on using certificates to secure the control 
channel. The certificate would be linked to the individual HNA.


Is there any provision for either downloading the relevant certificate 
given the key data, or for containing the certificate directly in the 
DHCP option?


Thirdly: I know some operators have concerns about "individualising" 
DHCP responses per user, rather than a static "get you configuration 
here" type bootstrap for all users.


Has this concern been discussed with any ISP's and is there an 
alternative method of individualizing the bootstrap process?


regards,

Daniel Migault wrote on 22/10/2020 15:10:

Hi,

Please find here an update for the DHCP options aiming at configuring 
the Home Naming Authority (HNA). The document has been updated to 
better reflect the changes made on the front-end draft. As the 
front-end draft enables the Distributed Master (DM) and the HNA to 
agree on some configuration parameters, these parameters no longer 
need to be provided via DHCP. As a result, this resulted in 
simplifying the DHCP options which is reflected by the current version.


As always, comments are welcome!

Yours,
Daniel




-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Thu, Oct 22, 2020 at 9:04 AM
Subject: [homenet] I-D Action: 
draft-ietf-homenet-naming-architecture-dhc-options-08.txt

To: mailto:i-d-annou...@ietf.org>>
Cc: mailto:homenet@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 WG of the IETF.

        Title           : DHCPv6 Options for Home Network Naming Authority
        Authors         : Daniel Migault
                          Ralf Weber
                          Tomek Mrugalski
                          Chris Griffiths
                          Wouter Cloetens
        Filename        : 
draft-ietf-homenet-naming-architecture-dhc-options-08.txt

        Pages           : 14
        Date            : 2020-10-22

Abstract:
   This document defines DHCPv6 options so any agnostic Homnet Naming
   Authority (HNA) can automatically proceed to the appropriate
   configuration and outsource the authoritative naming service for the
   home network.  In most cases, the outsourcing mechanism is
   transparent for the end user.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options-08
https://datatracker.ietf.org/doc/html/draft-ietf-homenet-naming-architecture-dhc-options-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-naming-architecture-dhc-options-08


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


--
Daniel Migault
Ericsson


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


--
regards,
RayH

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

Re: [homenet] biggest L2 domain

[Ray Hunter (v6ops)]

Gert Doering wrote on 13/12/2019 18:26:

Hi,

On Fri, Dec 13, 2019 at 09:54:08AM -0500, Michael Richardson wrote:

I thought that we wrote somewhere in RFC7368 that the Homenet router should
collect as many ports as possible together into a single L2 zone.
I can't find that text right now. Did it go away?

In testing, we have found a device that does not put it's 5-"LAN" ports into
a bridge.  That's probably a missing configuration, but in the meantime, we
have an interesting HNCP and naming setup!

My understanding of "homenet" and "HNCP" devices has always been "every
single hole in the box is a routed port".  Now that's my understanding and
not necessarily written down somewhere.

Magically grouping ports into a common L2 network and then un-grouping
them in case one of them turns out to have another HNCP device connected
sounds like an interesting challenge, to say the least :-)

Gert Doering
 -- NetMaster


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

Hi,

I agree that learning L2 topology is not trivial and is not covered in 
the current Homenet daemon.


Learning at boot time or port status change would require stopping 
forwarding to avoid loops, which is undesirable in networks where 
devices are plugged and unplugged (think wired laptop moving around 
interrupting media streaming on another device)


I was thinking of something like bringing up all ports in L3 at boot 
time, on a dedicated VLAN, see what's there, and then "annealing" the 
network later.


So if two (or more) ports are detected as only having hosts, they could 
later be merged to be one L2 domain after some period of stable operations.


One name and prefix would be primary, whilst the others would be 
configured initially but gradually removed (as leases die), which would 
be the equivalent of a phased

renumbering event with a flag day.

But other alternative of treating all ports as L3 ports forever would 
seem to require hierarchy in the naming solutions (which doesn't exist 
today).


--
regards,
RayH

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

Re: [homenet] outsourcing architecture [meeting notes]

[Ray Hunter (v6ops)]

Hi Daniel,

Here's my input where there wasn't time to provide at the mic in the 
meeting.


Daniel Migault wrote on 19/11/2019 10:36:

Hi,

So my notes/comments regarding the feedbacks received are:
* mentioning the work on axfr over tls

No problem with referencing this and it's helpful feedback.

I currently only protect the HNA based on a simple IP ACL in knot (allow 
DM for AXFR), which is effective, and doesn't eat resources on the HNA.


IMHO We almost certainly already have the required credentials in place 
for mutual authentication of the synchronisation channel (from the 
control channel) and I presume there's no issue with re-using these 
credentials in the reverse direction for the TLS session from DM -> HNA.


In my implementation, the HNA could authenticate itself to the DM by 
using the same certificate signing request signed by a private 
certificate from the DM that was already provided out of band, based on 
a trust anchor at the DM using it's own self-signed root certificate. 
There's no need for any additional public certificate.


The DM could authenticate itself to the HNA using a public Let's Encrypt 
certificate with subject common name matching the DM, with a trust 
anchor of the standard baked in root certs. The name of the DM is 
already provided out of band for initiating the control channel.



* cds needs to be placed in the homenet zone by the HNA
We already foresaw using CDS for ongoing maintenance of the DS key 
[RFC7344 + RFC8078].


See Section 5.2 of our draft.

/Though the HNA may also later directly update the values of the DS via 
the Control Channel, it is RECOMMENDED to use other mechanisms such as 
CDS and CDNSKEY [RFC7344] are used for key roll overs./


So I have no problem with the DM updating the DS key based on CDS 
(Section 4) during normal operations.


However, this can't be the ONLY method of maintaining the DS (which I 
believe was the question asked at the mic).


Because we're bootstrapping the trust between the HNA and the DM, and 
there's little or no previous knowledge of the other party, we need 
additional checks and balances. The KSK may also be lost.


That's why in my implementation we can always create, update, and delete 
the DS directly via the control channel.


The TLS transport on the control channel provides the authenticated 
channel referred to in Section 3.1. of 8078.


The control channel includes mutual authentication using certificates in 
my implementation (we know who we're talking to = authenticated).


I also check if this particular HNA is authourised to update this 
particular DS RR.


/When an UPDATE is received by the DM on the control channel, the 
message SHOULD be checked for authenticity (e.g. the source zone in the 
update message corresponds to the common name of the certificate used by 
the HNA), and then the DM SHOULD use the received information to 
configure the synchronization channel./


That was covered in some text I submitted on the github, but it isn't 
included in the published version 9. I missed that. We should go through 
and make sure those additional checks on the control channel, and why 
they're needed, are correctly documented.


The other options suggested in RFC8078 are inadequate or technically 
difficult IMHO.


RFC8078 Section 3.2 Extra check is technically hard IMHO

What would we check?

RFC8078 Section 3.3. Accepting after delay is inadequate.

We're talking public internet here. Otherwise there could be a resource 
exhaustion attack on the DM by an attacker inserting random DS RR's, or 
denial of service attacks by timing updates on unsuspecting HNA's that 
haven't renewed their DS for a while, or cant defend it quickly enough 
if they're offline.


RFC8078 Section 3.4 Accepting with Challenge

Possible, but then we'd have to define a (new) challenge response protocol.

ACME only works once DNS delegation is established, so you have a 
chicken-egg problem.


RFC8078 Section 3.5 Accepting from Inception
See comments on RFC8078 Section 3.3

* considering factory reset and removal of the provisioned keys ? - we 
need to think of this scenario.

Already covered in my implementation.

The KSK keys for the zone are generated on the HNA itself, and are never 
ever transmitted or stored outside the HNA, so if they're lost (either 
by factory reset or hardware replacement) there needs to be a recovery 
mechanism that does not depend on any state stored on the DM or HNA.


As long as an HNA still has a copy of the certificate signed by the DM, 
or they can grab a new certificate from the DM supplier (out of band), 
they can either update, delete, or replace the existing DS RR without 
knowing the old/lost KSK.


That was one reason for using Section 3.1 of 8078 for authenticating the 
creation, update, and deletion of DS RR's via the control channel.


* securing the synchronization between primary/secondary with TLS ? 
Feed backs are still unclear to me whether 1) we need to secure this 
channel. 

Re: [homenet] https://tools.ietf.org/id/draft-ietf-mboned-ieee802-mcast-problems-09.txt

[Ray Hunter (v6ops)]

Dave Taht wrote on 23/10/2019 08:56:

has anyone here had much chance to review this?


Thanks for the prompt.

From a pure Homenet perspective, it reinforces that L3 routing is the 
correct solution for segmenting networks where end nodes have different 
characteristics. e.g. battery powered or different underlying LAN 
technology. And maybe we need a firewall in front of those segments to 
prevent inbound scanning traffic overloading the link.


Other than that I'm not sure it says much more than "Multicast is great 
for efficiency, until it isn't".


Section 3.2.4:
> On a wired network, there is not a huge difference between unicast, 
multicast and broadcast traffic.


I'd dispute this statement as being overly generic. Anyway, it doesn't 
add much to the discussion (about wireless).


The majority of modern wired Ethernets are actually effectively point to 
point networks, with multicast and broadcast being emulated in silicon 
or software.


Although maybe having a less visible impact than on wireless, multicast 
and broadcast can also have some similar operational impact on wired 
networks (waking nodes unnecessarily, switching via a slow (software) 
path in the main processor,  https://tools.ietf.org/html/rfc6583 etc.).


--
regards,
RayH

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

Re: [homenet] DNCP/HNCP Revisited

[Ray Hunter (v6ops)]

Juliusz Chroboczek wrote on 20/09/2019 14:23:

1) DNCP allows an option of whether a network state TLV contains optional
nested payload (HNCP) TLV's or not.

I'm pretty sure that's not the case.  RFC 7787 Section 7.2.2.

A OK so you're saying this is already covered in (Section 4.4 of) 7787

[...]


   state hash.  The Node State TLVs SHOULD NOT contain the optional
   node data part to avoid redundant transmission of node data,
   unless explicitly specified in the DNCP profile.
So what I was suggesting was merely additional clarification of that.

Careful here.  There is no optional part in the *network*-state TLV - this
TLV's payload is just the network state hash.  The optional payload is for
the *node*-state TLVs.

I see now.

The network state TLV's and node state TLV's are completely separate 
TLV's (not nested in any way) that can be both generated as the result 
of one inbound request (request network state TLV), and they may be sent 
in separate UDP packets.

The replying node MUST reply to all node state queries.  However, it is up
to the replying node whether these replies are sent in a single packet or
split into multiple packets.

So requesting multiple node status TLV's in one packet could lead to an
oversized UDP reply packet.

Yes, this was discussed back in July 2015.  Here's what I said back then:

 It should also say that a node MUST NOT send a datagram with a larger
 payload, and that it MUST silently drop any larger datagrams (optionally
 log to system management, etc.).  If this is not done, persistent state
 desynchronisation may occur.

This is what Markus replied:

 I am not sure I want to cripple use in non-crippled networks, just provide
 guaranteed base value which works everywhere and *RED ALERT* light should
 light up on crippledbox if it encounters this

Since nobody supported my position at the time, I had to agree to the
following:

   - Section 3 of RFC 778 says that "Each node MUST be able to receive (and
 potentially reassemble) UDP datagrams with a payload of at least
 4000 bytes."

   - there is no limit on the size of the packets that a node may send.


So if I understand you correctly, you're saying this is the problem of the
sender of the response to ensure UDP fragmentation doesn't break,

I'm not sure what you mean.  We certainly assume that the network obeys
RFCs 2460 and 4443.


and that multiple long UDP replies can be generated from a single query
packet (potential amplification).

Let's please discuss security at some other time, I'd like the current
discussion to come to a conclusion first.


If there's multiple UDP replies required for a single query, would you expect
sending of these individual packets to also be rate limited by trickle?

Let's please discuss congestion control at some other time, I'd like the
current discussion to come to a conclusion first.


What behavior would we expect from the requester during this time?

The requester parses each top-level TLV in turn, and acts upon it.

This is very illuminating for me, and removes a false assumption on my part.

Wait for all outstanding replies to arrive?

No.  The requester parses each top-level TLV and acts upon it as soon as
it arrives.


Re-transmit a node TLV request for missing / dropped replies?

How would the receiving node detect missing replies?

If some node-state TLVs are missing, then the receiving node's state might
not get updated correctly, which will cause the network hash to mismatch,
which will be detected when it receives a new network-state TLV
(trickle-driven, worst-case 17s).

-- Juliusz

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


Thanks very much for your patience and replies to my questions that have 
certainly filled gaps in my understanding of the protocol that I had 
from reading the standards and the code alone.


AFAICS there's certainly enough room for me to experiment with patches to
i) reduce MTU to avoid problems arising from L2 MTU mismatches and
ii) to reduce the amount of fragments (at the expense of more UDP packets)
without any tweaking of the standards.

My reason for investigating ii) is to potentially reduce the impact of 
the loss of an individual frame on a lossy link (we would lose 1 node 
status TLV from 1 device rather than multiple TLV's related to multiple 
devices).


--
regards,
RayH

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

Re: [homenet] DNCP/HNCP Revisited

[Ray Hunter (v6ops)]

Thanks for your response.

Juliusz Chroboczek wrote on 20/09/2019 12:40:

1) DNCP allows an option of whether a network state TLV contains optional
nested payload (HNCP) TLV's or not.

I'm pretty sure that's not the case.  RFC 7787 Section 7.2.2.

The Network-State TLV only contains the network state hash, short
Node-State TLVs are separate top-level TLVs.  An implementation may choose
to send them in the same packet, but they're independent TLVs and can be
sent in different packets.

A OK so you're saying this is already covered in (Section 4.4 of) 7787

  Upon receipt of:

   o  Request Network State TLV (Section 7.1.1 
): The receiver MUST reply
  with a Network State TLV (Section 7.2.2 
) and a Node State TLV
  (Section 7.2.3 ) for 
each node data used to calculate the network
  state hash.  The Node State TLVs SHOULD NOT contain the optional
  node data part to avoid redundant transmission of node data,
  unless explicitly specified in the DNCP profile.

So what I was suggesting was merely additional clarification of that.




2) The node requesting a node status TLV doesn't know in advance how big a
reply packet will be generated.
DNCP states that nodes MUST reply to all node status TLV queries.

The replying node MUST reply to all node state queries.  However, it is up
to the replying node whether these replies are sent in a single packet or
split into multiple packets.

In other words, the only constraint is that every single node state TLV
must be sent in its entirety within a single packet.  As described in
a previous mail, this does bound the amount of data that a single node can
publish, but no bounds on the total size of the network.


So requesting multiple node status TLV's in one packet could lead to an
oversized UDP reply packet.

The replying node's behaviour has nothing to do with whether the requests
are aggregated in a single packet or not.  The replying node processes
each request independently, whether it finds them in a single packet or in
multiple packets.

-- Juliusz

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


So if I understand you correctly, you're saying this is the problem of 
the sender of the response to ensure UDP fragmentation doesn't break, 
and that multiple long UDP replies can be generated from a single query 
packet (potential amplification).


If there's multiple UDP replies required for a single query, would you 
expect sending of these individual packets to also be rate limited by 
trickle?


What behavior would we expect from the requester during this time?
Wait for all outstanding replies to arrive?
Re-transmit a node TLV request for missing / dropped replies?

Thanks!

--
regards,
RayH

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

Re: [homenet] DNCP/HNCP Revisited

[Ray Hunter (v6ops)]

Juliusz Chroboczek wrote on 19/09/2019 01:02:

The problem is, how’d the packet get so big that it was fragmented?

HNCP relies on network-layer fragmentation: it uses UDP and has no
application-layer mechanism for fragmenting large TLVs.  See Section 4.2
and Appendix B.2 of RFC 7787.

Agreed. I'm aware it was a design decision.


(I seem to recall that an earlier version of DNCP included provisions for
application-layer fragmentation of TLVs, but that was removed at some
point.  I don't remember why.)
Yes. I've read earlier versions of the draft and it was an open point 
whether to do L7 fragmentation as part of HNCP or not.


I can't recall the exact discussion on list but it changed between 
version 4 and 5

https://tools.ietf.org/html/draft-ietf-homenet-hncp-04 (Appendix A)
https://tools.ietf.org/html/draft-ietf-homenet-hncp-05 (rely on UDP 
fragmentation)



Let's please come back to my question.  RFC 4443 paragraph 3.2 says

A Packet Too Big MUST be sent by a router in response to a packet
that it cannot forward because the packet is larger than the MTU of
the outgoing link.

If your tunnelling software violates this, how is it not buggy?

-- Juliusz

Yes, this is a very poor network set up that could be avoided.

Question is: is it worth addressing?

I'm still working on the basis of a simple workaround to address the L2 MTU 
mismatch (limit IPv6 UDP fragment size to 1280 octets).


The separate problem is that if the amount of HNCP state increases (e.g. due to 
electing a central name server or mud server or whatever), the apparent limit 
of having to transmit the entire superset of all node TLV states in a single 
UDP packet may become problematic.

I notice in the current Openwrt code that the max UDP packet size is set at 
9000 octets with the comment:

/* Very arbitrary. On some implementations, I have seen some issues
 * with 10+kb frames so we use this for now. It MUST be significantly
 * more than 4k, due to how code is written at the moment. */
#define HNCP_MAXIMUM_UNICAST_SIZE 9000

With current code (without expanding the TLV data set), and my sample test 
routers, that sets a current maximum network size of approx. 12 nodes.

--
regards,
RayH

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

Re: [homenet] DNCP/HNCP Revisited

[Ray Hunter (v6ops)]

Mark Andrews wrote on 18/09/2019 12:00:



Question: As a simple mitigation, is there any way of manually signalling to 
the kernel that ALL UDP packets on port 8231 should assume an PMTU of 1280 
octets?

setsockopt(IPV6_USE_MIN_MTU=1); from RFC 3542 works provided the OS has 
implemented it.  It’s a really pity that POSIX hasn’t picked up RFC 3542 in the 
16 years since it was published like they picked up RFC 3493.  This is a epic 
fail of SDOs.


Thanks for the tip.

Unfortunately checking  in the current openwrt build tree.
..
#if 0   /* not yet */
#define IPV6_USE_MIN_MTU    63
#endif

:( not yet implemented

--
regards,
RayH

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

[homenet] DNCP/HNCP Revisited

[Ray Hunter (v6ops)]

Hi,

I've been experimenting with Homenet before looking at enhancing HNCP 
for extended naming functionality (the current implementation only 
covers resolver configuration and not name server configuration).


During my testing I managed to break HNCP, so that it got stuck in a 
state where it didn't converge.


Looking at the specification in detail this shouldn't have been a 
surprise to me or anyone else due to the design choices that were made.




First observation: Running HNCP over L2TPv3 breaks HCNP because L2TPv3 
breaks UDP fragmentation (works as designed).


The L2TPv3 tunnel has a lower MTU than the local LAN, and does not 
report ICMP PTB, so HNCP packets in one direction get through, but 
replies get dropped.


Early drafts of HNCP stated that UDP fragmentation would not be broken 
in the Homenet for the foreseeable future. Well I managed to break that ;)


So this is a known situation.

Changing the MTU on the LAN interfaces of my routers to 1280 brought 
everything back to normal, as expected.


Question: If Homenets are moving to flat L2 meshes over foo, as some 
have said, will this impact HNCP?


The Linux kernel (in Openwrt) can/could easily support PMTUD.

But since the L2 tunnels don't report drops, it makes PMTUD potentially 
challenging for a simple protocol like HNCP.


Question: As a simple mitigation, is there any way of manually 
signalling to the kernel that ALL UDP packets on port 8231 should assume 
an PMTU of 1280 octets?


That wouldn't require any specification change and would allow HNCP to 
work reliably in the presence of tunnels and varying MTU's that don't 
match the local interface MTU.





Second Observation: HNCP packets grow quickly in size, which may become 
a concern for scaling.


Again, by design, DNCP is limited to TLV content of 64K (RFC7787 intro).

AFAICS that is 64K per DNCP system, not per node.

Question: Is that correct?

For my 4 node Homenet, HNCP reached 3140 octets, without any 
modifications or additions or long names.


Question: Does the amount of state scale linearly with the number of 
routers?


Question: Is this starting to become a concern?

The limitation for 64K seems to come from the following:

RFC7788
Request Network State TLV (Section 7.1.1): The receiver MUST reply
  with a Network State TLV (Section 7.2.2) and a Node State TLV
  (Section 7.2.3) for each node data used to calculate the network
  state hash.


In the Openwrt implementation, I observe that the requester is 
requesting the node state for all 4 devices in one packet.


I also observe that the reply from the peer contains the entire state of 
the entire Homenet in a single UDP packet (network TLV and node state 
TLV for all 4 routers + optional payload data).


Question: Is that as designed/intended? Is this where the 64K data limit 
comes from in RFC7787?


If this was a design goal to reduce chatiness, and improve convergence 
time, is it possible to implement this differently to reduce packet size 
and/or increase overall TLV data capacity?


Could the requester in step1 request the network status TLV, and the 
peer reply with just the network status TLV and the node TLV's, but 
without the underlying optional HNCP payload data TLV's.


Maybe include a new "more-HNCP-data-to-come" TLV to distinguish this 
from blank node data?


That would give enough information for both nodes to know exactly which 
payload data needed synchronising.


Then as step 2, the requester could individually request the Node TLV 
for each node one per packet, and the peer would reply with the Node TLV 
but this time including the optional data TLV's.


The receiver and peer would both know that HNCP hadn't converged whilst 
waiting for the additional data, and could mark it internally as being 
stale whilst waiting for the additional detailed update.


Question: What would break?

Question: What would need to be amended in the standard RFC? The 
more-HNCP-data-to-come TLV in RFC7788?


Question: Would this tweak increase the ±64K limit of TLV data from 
being per network to being 64K per node? [max UDP packet size for a 
single node TLV + associated payload data]


Question: Is this raw fragmentation by separating DNCP essentials from 
HNCP payload something that the WG would support?


regards,

--
regards,
RayH

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

Re: [homenet] IPv6 & firewall config in a home net

[Ray Hunter (v6ops)]

Mikael Abrahamsson wrote on 06/09/2019 08:59:

On Thu, 5 Sep 2019, Ray Hunter (v6ops) wrote:

IMHO Expected behavior. Many European data protection people consider 
an IP(v6) address to be privacy-sensitive personal data. That will 
likely mean regular renumbering of IA PD by ISP's as the norm rather 
than the exception.


This is the first time I've seen anyone make this claim (I guess 
related to GDPR). I've gone through GDPR review and talked to others 
who have done the same, and I from a GDPR point of view there is no 
reason to renumber on a regular basis. From what I can tell, 
renumbering at some frequency makes no difference from a GDPR point of 
view. The addresses are privacy sensitive regardless if you change 
them frequently or not.

This last sentence is key.

FYI The opinion I read was as follows:

"The same also applies to IP addresses. If the controller has the legal 
option to oblige the provider to hand over additional information which 
enable him to identify the user behind the IP address, this is also 
personal data."


So if the provider intentionally destroys any method of linking an IP 
address to a user behind an address (by regularly renumbering using 
pseudo-random prefixes) then by the opposite argument the IP address 
shouldn't be considered personal data any more.


This is a method that I've also seen used to pseudo-anonymize MAC 
addresses logged via wifi in a building management system. The MAC 
addresses were hashed with a pseudo random key that rotated every day, 
and the key was not stored anywhere. So the location data could be 
tracked accurately for an individual device over a period of 24 hours, 
but the privacy people considered this good enough that the result 
wasn't considered as personal data, because there was no practical way 
to work backwards from the hashed addressed to the movements of an 
individual device carried by an individual person.


I ain't a lawyer.


My experience is that the frequent renumbering is a local market 
practice that people in that market got used to. As a swedish user, I 
hadn't heard of this practice until I started talking about these 
things with people that ran/experienced ISPs in other nations. The 
defaults are also different.


Some markets have frequent renumbering (some even reset the PPPoE 
session once per day, which is a flash renumbering eevent), some never 
renumber unless there is a big network change (I've had the same IPv6 
prefix now for a year).


The conclusion is that we need to create solutions that handle both 
these cases.


I agree with your conclusion, so the rest is pretty much a moot point 
for Homenet.




--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] IPv6 & firewall config in a home net

[Ray Hunter (v6ops)]

Ted Lemon wrote on 05/09/2019 18:31:

On Sep 2, 2019, at 1:47 PM, Michael Richardson  wrote:

Assuming that the prefix change is make-before-break (which we do not clearly
know how to do on the WAN side, I think), then the web server should
configure with the same rfc7212 IID, but a new prefix.

I don’t think there’s any need for the IID to be persistent.   
Make-before-break is accomplished by deprecating the old prefix when the new 
prefix is added.   This is trivial to do; whether it is in fact done is a 
different matter.   I think that at present the client would have to notice 
that it’s happened.


Agreed.

Using RFC7217 will anyway almost certainly guarantee that the IID will 
also change if the prefix changes.


The prefix is included in the function that generates candidate IID's.

  RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)


That was done to prevent tracking when people move between wifi hotspots.

--
regards,
RayH

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

Re: [homenet] IPv6 & firewall config in a home net

[Ray Hunter (v6ops)]

mal.hub...@bt.com wrote on 02/09/2019 17:55:


Hey,

Mal here. IETF attendee since 2012 ;)

I have a home networking question with respect to IPv6 standards, I’m 
hoping to use you as a sounding board first before I take it to v6ops.


The scenario here is a home / soho network situation where the user 
wants to host a service, lets say its a webserver, but really could be 
any hosted application, importantly using IPv6. The router is setup to 
use SLAAC only.


The ISP offers IPv6 GUA addressing in a non-stable manor, its "sticky" 
but at some point in the future it might change (BNG reboot for example),


IMHO Expected behavior. Many European data protection people consider an 
IP(v6) address to be privacy-sensitive personal data.
That will likely mean regular renumbering of IA PD by ISP's as the norm 
rather than the exception.


so the user will use DynDNS provider to provide a stable name for 
their service, this sounds OK so far.


External users should also be using a name rather than a (time variant) 
IPv6 address.


Please be so kind as to review our draft 
https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-08


[Hopefully a new version will be forthcoming soon]

This is precisely one of our use-cases.

The user has to allow the webserver port, 443 in their router GUI 
firewall to allow the traffic in, sounds simple enough. Importantly it 
should be to that webserver device only.


Now the tricky part….

Since in this scenario the webserver device is using privacy 
extensions, it has a bunch of IPv6 GUA addresses and no EUI-64 and


- It has Temporary addressing (which will regularly change)

- It has a "Permanent" address (which is the one the webserver will 
want to use)



The webserver should not be using privacy extensions for inbound sessions.

It really should be using https://tools.ietf.org/html/rfc7217


Does this sound reasonable and make sense so far ? Cool.

In the router GUI the user is presented with a list of "devices" for 
which the router can open up TCP 443 in the firewall.


It is reasonable to assume the user does not want to type in the 
Permanent IPv6 address of the device, as it is poor CX and anyway it 
will change in the future (possibly due to a network change / BNG 
restart etc as mentioned)



Correct.


Current routers on the market I have come across have either:

 1. Open the port to the current temporary address only which means
that inbound connections on the port usually fails right away (if
the webserver is not listening on that address) – or fail after
the temporary address changes.
 2. Opens the port to the correct address (by chance)
 1. - But then fails at some point in the future when the network
prefix changes (as router drops the rule when the prefix changes).
 3. Opens the port to some or ALL addresses currently (& sometimes
historically) associated with the mac address of the device  (not
great for security – spoofing? )
 1. But even that sometimes excludes the permanent address
 4. Opens the port to all addresses on LAN (not great for security at all)

  * Basically the routers firewall config gui doesn’t know reliably
which device address is the permanent one. 


  * Should there exist a mechanism to signal to the router or the
router can accurately learn which of the devices addresses should
be used for configuration in the firewall ?


Yes. via PCP RFC6887 et al.


 *


Is this a problem – have I missed something – Is it worth fixing ?

Yes. - RFC8520? although there's still a gap for policy IMHO (does a 
user want to accept what the manufacturer suggested) - Yes.


Thoughts:

This is probably a strange thing for the user to do (but I have had 
users trying to do it). Its usually fixed for a customer by switching 
off privacy extensions / using EUI-64 so basically giving the device a 
single address for the router gui to identify the device by.


I personally hope this becomes more common, to avoid the need for NAT, 
rendezvous points, dependence on central certificate instances etc.


Mal



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


--
regards,
RayH

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

Re: [homenet] [EXT] securing zone transfer

[Ray Hunter (v6ops)]

Hi,

Ted made a valid point about "running code" in this thread.

So I've been experimenting with various configurations.

My conclusions:

1) We definitely need to properly secure communication between the HNA 
and the DM for control traffic.


This needs to be an explicit part of the draft.

2) Authentication based on the physical connection, plus source IP 
address, plus correlation of the source address against the contents of 
the RR *might* be sufficient for transactions between the HNA and the DM 
for reverse zones - all communication is guaranteed to be contained 
within a single AS.


Current best practice of using IP ACL's + BCP 38 for filtering 
communication could work in this case. The DM would then check whether 
the contents of the PTR updates arrived from a source address associated 
with the HNA.


We'd need to add some text saying the HNA should select source addresses 
for reverse zone updates appropriately (to make sure the updates came 
from an address issued via IA-PD from this ISP).


3) for communication between the HNA and a DM for forward zones, we 
definitely need to specify something stronger, because the DM 
potentially has to serve HNA's scattered over the entire Internet.


4) TSIG isn't going to scale operationally IMHO.

Too many keys to manage. Keys have to be stored on line within the DM. 
Losing keys means compromising the whole service, and it is difficult to 
recover from.


5) SIG(0) has similar problems.

Bootstrapping the trust might mean the expiration time would have to be 
so large that replay attacks will come into play.

And recovery is difficult.

6) DNS over an existing standard FOO secure transport looks promising.

The amount of traffic arriving at a DM should not be so large or time 
critical as the traffic to the resolvers, and capacity can be scaled by 
increasing the numbers of DM's.


There is also existing front-end hardware acceleration available. So the 
secure transport could theoretically be terminated on an dedicated 
acceleration box, and the DM only then needs to speak native DNS.


7) DNS over TLS can almost certainly be made to work without any new 
standards, but it will require extensive coding as support seems pretty 
limited off the shelf.


It also has the added benefit that client authentication can be built 
into the transport.


So I've been playing around with the DM being authenticated by public 
certificates to the HNA (HNA would incorporate root certificates burned 
in at the factory), and the HNA being authenticated to the DM by a 
client-specific certificate that is signed using a self-signed 
intermediate CA certificate from the DM. The DM then trusts the 
certificates it has issued to the client HNA's simply by installing the 
root CA cert on the DM: there's no client specific configuration required.


Since the HNA anyway has to be configured to use the DM, and some trust 
has to be  established, I don't see this as an onerous burden in the 
sign up process.


8) DNS over HTTPS doesn't bring us anything extra in this case IMHO.

It actually presents additional challenges with coding alternate 
transports and parsing (POST or GET HTTP1.1 HTTP2) etc.

Others may disagree, so the draft could use a "recommend DNS over TLS"

9) IMHO we should also standardize the trust-booting process into a JSON 
file, that can either be fetched via HTTPS or pasted into the HNA.


This for the same reasoning for inter-operability that DNS standardized 
the file representation of the zone file in RFC1035 Section 5.


For a start, I came up with the following, although I'm sure we can 
improve as we get more experience in what parameters are needed for each 
implementation.


I came up with 4 parameters:

dm_axfr    fqdn of the DM for axfr (so the HNA can apply IP filters on 
inbound requests)


dm_ctrl    fqdn of the DM for ctrl (so the HNA can send updates to the 
DM control channel e.g. if the HNA renumbers it would send an NS record 
and  record update)


zone    the zone that is being delegated

hna_certificate    client certificate encoded as a single line with 
literal '\n' replacing cr and lf characters (common practice in existing 
equipment when pasting certificates)


This would also work for a reverse zone, although obviously it's a 
different DM etc.


Sample:

{"dm_axfr":"dm.homenetdns.com","dm_ctrl":"dm.homenetdns.com","zone":"sub.homenetdns.com","hna_certificate":"-BEGIN 

Re: [homenet] securing zone transfer

[Ray Hunter (v6ops)]

Michael Richardson wrote on 13/06/2019 03:25:

Juliusz Chroboczek  wrote:
 > Are you assuming here there's a central Homenet controller that presents
 > a web interface where the "house owner" can choose which names get
 > published?

No, we are assuming that there are one or more homenet routers that either
come with a delegated domain from the manufacturer (probably a very ugly
one), or which that CPE's ISP will delegate via DHCPv6. (or both)

Whether we should or have to do some negotiation over HNCP if there are
multiple CPEs is a problem we can deal with later.

We have, however, been thinking about the problem of having partial
connectivity for the home, and how do published names get resolved.

 > I'm probably missing something, Michael, so please explain if you agree
 > with the analysis above, whether you're assuming a central controller,
 > and, if so, where is the central controller located in a network that has
 > multiple edge routers.

If an end user wants a non-ugly domain, and they buy it, then they need to
introduce one or more of their CPEs to the upstream provider of the
domain.  It could be it is at this point that it makes sense to do some HNCP,
but in essence, this is an internal problem, and the front-end-naming
document is not about internal issues.

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



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


Indeed this draft should say as little as possible about what should 
happen internally (whether there's one elected central Homenet 
controller for all ISP uplinks, or there's something running on all 
Homenet routers that updates an edge HNA per ISP uplink, or the HNA 
service runs on a host, or something else).


Probably the text isn't in that state yet.

The facts of life with using DNS are that:
- a zone delegation is built on a hierarchical name space with a single 
root;

- a delegated zone is a proper subset of a parent zone,
- zone signing occurs with one single active zone signing key signing 
the complete set of RR's in a zone (not a key or signature per RR), and 
where
- zone transfer updates are performed with a master/slave arrangement 
with a limited number of known peers per zone.


If you want individual hosts to interact directly with an outsourced 
name service based on DNS (instead of via an HNA), you either have to 
delegate the zone signing to the outsourced name service (which 
introduces a different trust model), or you assign a dedicated zone per 
host (possible?), or you introduce a massive key sharing and signing 
problem.





Another use case could be small companies who want to run something like 
Active Directory on premises (AD integrated DNS).


Then they could potentially build AD forest trust relationships between 
companies.


AD of course runs on a domain controller (DC). The DC function could 
then potentially take on the role of HNA, whether that is running a 
separate server or on a CPE.


--
regards,
RayH

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

Re: [homenet] securing zone transfer

[Ray Hunter (v6ops)]

Inline. Long post.

Juliusz Chroboczek wrote on 12/06/2019 04:03:

Actually, it's fatal, because you can't get a certificate for "boombox.local"
so you can't secure it that way.  So you always have to use the FQDN.

That sucks, of course, but the problem is completely unrelated to being
published in the global DNS -- the very same problem applies to names that
only appear in local MDNS.

No. They are directly related. See below.

I think that's our main disagreement.
For some reason, you guys seem to be assuming that the average user will
want to publish hundreds of names in the global DNS.

Hundreds?  How about two.
My son wants to publish his desktop's name so that his friend can reach his
system directly for minecraft.  I want the same.

Your son clicks "publish name" in the Minecraft server's UI, at which
point he faces the following dialog box:

   Domain: dyndns.minecraft.example.com
   Hostname: minecraft-7ac8
   Password:

The young man considers that default values are for noobz, and edits as
follows:

   Domain: richardson-family.vanity-dyndns.example.com
   Hostname: better-server-than-dads
   Password:

After the name is published (which takes half a second), the Minecraft UI
displays a "share" icon, so that your son can publish the server's name
over UUCP, or whatever it is that them youngsters use nowadays for chatting.

Your turn now.  Could you please describe the UI that you envision?

-- Juliusz


It would seem your objection can be summarized as "we don't need this". 
Correct me if I'm wrong.


To me is like saying we don't need a new routing protocol like BABEL, 
because we have loads of routing protocols already.
[for the record I strongly supported incorporating BABEL into Homenet, 
because to me it was the best choice]


Funnily enough my next door neighbor (who knows nothing about 
networking) could appreciate the use case.


He can currently control his central heating system from his smartphone. 
But he needs to pay for the rendezvous service, or has a tie in to a 
particular heating-system maintenance provider.


The use case would then be that an IoT device or local gateway device 
could use one common protocol (out of scope) to talk to the Homenet 
router, then the homenet router could publish and resolve names to 
backbone DNS infra, whilst the app developer wouldn't need the 
rendezvous service or NAT traversal. The rendezvous service is also a 
single point of attack for large scale DDOS, and also might raise 
privacy concerns because the manufacturer can monitor detailed use of 
all the devices they've sold. Mobile devices could use one single name 
to connect to the gateway device in a secure manner from anywhere.


So rather than being forced to use the manufacturer's thermostat, or 
sign a service contract from a particular maintenance provider tied to 
the manufacturer, he can use OpenTherm, and he can control OpenTherm 
from anywhere.


Yes, there are HTTP REST interfaces to accomplish this, but they ain't 
standard, and they ain't always easy to use.
[check out comments from people who've tried to automate this for 
multiple alternative REST-based providers]


Yes, each individual device could also manage names directly with 
multiple DNS outsourcing providers, but then you potentially create an 
explosion of keying and signing material if you want DNS-SEC to work in 
any meaningful way.


Especially as DNS is becoming more of a trust anchor for other services.

How much easier is it to trust devices using TLS over a self-signed 
certificate anchored via TLSA records to DANE on your own DNS zone?


accept TLS from any devices with certificates with CN 
*..homenet.com
accept TLS from any devices with certificates with CN 
*..homenet.com

deny all

Then the minecraft connection with your friend can be properly secured 
without resorting to chat protocols and shared secrets or IP filters.


You don't need to pay a CA for any magic beans because DANE will work 
with self-signed certificates, even in a chain (mode 2 trust anchor). 
And you can be sure no-one has messed with the certificate, because 
you've created the certificate yourself, and you've signed the DNS zone 
yourself with your own private keys that haven't been shared with anyone 
else. Sure, you still have to bootstrap all of this.


To me it seems obvious that people should be able to distribute services 
(if they want to) to their own network.
If they want to rely on the handful of technology giants for their 
security, then fair enough. But they should have a choice.


regards,
RayH



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


--
regards,
RayH

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

Re: [homenet] [EXT] securing zone transfer

[Ray Hunter (v6ops)]

Thanks for the feedback.

> first, the gateway does not know for sure which external NS are use 
by the secondary DNS service,


Agreed. The draft needs to address how the service is boot-strapped and 
auto-configred.


> second the IPs of the WAN port might not be the internet facing IPs 
and this could break inbound connectivity


I hope that we're going to be able to move past IP filtering as the 
primary security mechanism for this draft.


Especially in the presence of renumbering.

regards,

Jacques Latour wrote on 11/06/2019 20:59:


Daniel,

In trying to setup our secure home gateway project to have the 
external zone & primary DNS server setup and managed on the gateway 
itself and to XFR back to secondary name servers somewhere turned out 
not be functional or practical, first, the gateway does not know for 
sure which external NS are use by the secondary DNS service, second, 
the IPs of the WAN port might not be the internet facing IPs and this 
could break inbound connectivity.  We’re looking at using dynamic DNS 
updates for things that need internet connectivity, and have the 
primary DNS server on the main land.   TSIG & DNS over TLS look like a 
good option to look at.


Jacques

*From:*homenet  *On Behalf Of *Daniel Migault
*Sent:* June 7, 2019 4:03 PM
*To:* homenet 
*Subject:* [EXT] [homenet] securing zone transfer

Hi,

The front end naming architecture uses a primary and a secondary dns 
server to synchronize a zone. The expected exchanges are (SOA, NOTIFY, 
IXFR, AXFR. We would like to get feed backs from the working group on 
what are the most appropriated way to secure this channel.


Options we have considered are TSIG, IPsec, TLS, DTLS. TSIG does not 
provide confidentiality, and we would rather go for user space 
security.  Are there any recommendation for using TLS or DTLS in that 
case ?


Any thoughts would be helpful.

Yours,

Daniel



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


--
regards,
RayH

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

Re: [homenet] primary / secondary configuration

[Ray Hunter (v6ops)]

Daniel Migault wrote on 07/06/2019 22:27:

Hi,

We are looking for a simple way to configure the primary / secondary 
DNS setting between the homenet and the outsourcing infrastructure. 
The exchange of these information is done over a secure channel - let 
say TLS. While we coudl re-define a configuration template / mechanism 
we believe that re-using widely deployed libraries would ease the 
deployment.


The HNA is responsible for building / signing the zone and 
synchronising the zone with the outsourcing infrastructure. To build 
the zone some elements of the infrastructure are needed such as the NS 
and IP for example. One way to enable the transmission of information 
from the the outsourcing infrastructure to the homenet is to use an 
well known fqdn hna.example.com  with an AXFR 
request. Does it sound reasonable ?




Stating the obvious: if an HNA is going to sign a zone, it has to own a 
globally unique delegated zone.


I see 3 ways of delegating a piece of namespace and gathering the input 
for the SOA:


1) HNA is pre-configured with one or more DNS outsourcing providers in 
the admin GUI e.g. .


User picks one via LuCI.

HNA creates a proposed zone name e.g. . or asks for 
a proposal from the user.


DNS Outsourcing Infra confirms that . is unique via 
the parent zone 


2) HNA is pre-configured with one or more DNS outsourcing providers in 
the GUI e.g. .


User picks one via LuCI.

HNA contacts .

HNA receives the zone name  . from the DNS 
Outsourcing Infra.


3) HNA owner purchases a nice name from a registrar e.g. 
. Domain Registrar and the DNS Outsourcing Infra 
example.com, don't share a common parent zone.



IMHO for (1) and (2) we already have working outbound DNS resolution in 
place, and the HNA can gather SOA variables using either a simple SOA 
lookup of the parent zone, or via a SOA + and AXFR to fetch a template.


(1) dig -t soa example.com +dnssec -> NS1 NS2 +  RR + timers of the 
parent -> copied 1:1 to the child zone .example.com.

Obvious disadvantage: everyone is tied to the same infra, timers, and NS RR.
Advantage: cheap and cheerful.

(2) dig -t soa example.com +dnssec|perl extract_MNAME_from_SOA.pl; dig 
@$MNAME -t axfr .example.com +dnssec|perl extract_SOA_variables.pl;


The MNAME in example.com SOA would contain the name of the DM config 
server/template server.


The DM config server/template server would either have to generate the 
template on the fly, or have one pre-configured during sign up.


(3) would have to be out of band or require something much more complex.


On the other hand, the outsourcing infrastructure needs to know the 
fqdn of the hna. One way to provide that information could be to 
re-use DNS update updating the SOA of hna.example.com 
. The fqdn of the hna would be indicated 
using the MNAME field. Does it sounds reasonable as well ?


Yours,
Daniel




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


--
regards,
RayH

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

Re: [homenet] securing zone transfer

[Ray Hunter (v6ops)]

Ted Lemon wrote on 08/06/2019 05:50:
On Jun 7, 2019, at 11:36 PM, Michael Richardson > wrote:
Can we use TLS for authorization, assuming that we have trusted 
certificates

at both ends?  Perhaps this is more of a: did anyone implement this?


How is trust established?   Sure, doing TSIG over TLS is no problem.


Bootstrapping trust is always going to be an issue no matter what we do.

There can be multiple ways to bootstrap this, and multiple possible 
providers pre-configured in the GUI.


Possible alternatives for further investigation:

1) something burned in at manufacturing time + trust between the 
manufacturer and the DNS Outsourcing Infra provider.


An initial query from the HNA to the infra could include a proposed 
domain name e.g. an AXFR or SOA query for .example.com sent to 
the DM together with SIG(0) signing of this name.


The signing could be done by a private key held at the manufacturer.

SIG(0) doesn't protect the wrapper, only the query data, so the query 
can be signed in advance off-line before anything like the homenet IP 
address is known.


The DNS outsourcing infra can check this signature either using an 
associated public key that is hosted on the manufacturer's DNS in a 
pre-agreed location. e.g. homenet-keys.manufacturer.com. Or the 
manufacturer could pre-share this public key with the DNS outsourcing 
provider out of band.


2) Out of band sign up using a public/private key held at the DNS 
outsourcing service provider at service sign up time (https + credit 
card + CGI script on the service provider's web site -> delegated domain 
name + SIG(0) signed delegated domain name query on the HNA for the 
initial query to the DM). The DM only needs to know the current valid 
public keys used for the SIG(0), and the private key and credit card 
details can be held elsewhere and regularly rotated.


3) Trust based on the TLS + certificate chain, rather than anything at 
the DNS application level. Currently very much hand waving on my part up 
until now. I've seen DANE being able to validate TLS connections based 
on a certificate chain (e.g. RFC 6698 DANE-TA(2) Trust anchor assertion, 
with a common trust anchor like let's encrypt X3 root) and was thinking 
we could leverage that somehow for mutual authentication, along with 
perhaps DNS over HTTPS (RFC8484). On the DM end that could use standard 
TLSA records published in the parent zone to validate the DM to the HNA. 
In the other direction we'd have to somehow to process a certificate 
from the HNA to identify the manufacturer or end user to the DM. But 
that's a well-known problem in web server land.


Thoughts?

--
regards,
RayH

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

Re: [homenet] About Ted's naming architecture presentation and document

[Ray Hunter (v6ops)]

james woodyatt wrote:
On Nov 16, 2016, at 17:31, Michael Richardson > wrote:


But, do you agree that publishing your home lighting controller to 
the DNS is

how you manage to control your lights from your phone when you are out of
wifi distance, as you roam to 3G. (I switch to 3G when I get to the 
front of

my rather modest driveway, as the AP is in the back of the basement)?


If anybody is currently shipping, or has announced plans to ship, any 
kind of home automation device that does this, please speak up on the 
mailing list. I’d like to calibrate my perhaps mistaken apprehension 
that nobody would seriously consider doing this. Everyone I know in 
this field plans to do this by providing a single public rendezvous 
point with high availability servers that communicate in turn to home 
automation controllers acting as private clients.



--james woodyatt >



RFC3724.

>  End user choice and empowerment, integrity of service, support for 
trust, and "good network citizen behavior" are all properties that have 
developed as a consequence of the end-to-end principle.


Rendezvous points are themselves an attack vector/ anti-privacy snooping 
vector/ commercial lock-in/ convenience, depending on your point of view.


So please let's empower the end user to either "opt in" or "opt out".

--
regards,
RayH

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

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

[Ray Hunter (v6ops)]

Ted Lemon <mailto:mel...@fugue.com>
14 May 2016 15:18
The only problem with that is that in the homenet ideally we'd like to 
have local names signed and validatable via DNSSEC, and that requires 
that the local namespace be global in scope, even if the names 
published in that namespace are not.



Not necessarily.

You only need global scope namespace if trust also needs to extend 
beyond Homenet.


If we're assuming that ULA will be used for on-Homenet communication 
streams (in the event of non-availability of GUA/ ISP uplink), then 
tying local names into the upstream global namespace is not strictly 
necessary.


So IMHO it would be just as acceptable to sign RRs for local names 
related to ULA address space with a locally-generated trust anchor 
(independent of the trust anchors installed on the Internet root servers).


Nodes and new routers would have to learn their local trust-anchor when 
connecting to the Homenet for the first time.


In other words, the local DNSSEC trust anchor identifies a Homenet. Not 
the ULA. Not an arbitrary label.


Otherwise we're going to need a globally-unique time-invariant label to 
identify this Homenet, that is also not based on the actual chosen ULA 
in use, which is not easy to generate.




Ray Hunter (v6ops) <mailto:v6...@globis.net>
14 May 2016 14:51


Ted Lemon wrote:


If devices publish keys, then you can use those keys to make sure you 
are still talking to them. And the dnssec validation of local names 
would also work. Graceful renumbering should indeed result in DNS 
updates. Bear in mind that this is graceful, so the old and new ULAs 
coexist for a while.




Sounds good.

So can we assume

1) a single ULA namespace for resolving all active ULAs, that will 
eventually converge to only containing RRs from a single ULA?


2) And that ULA namespace is disjoint from/completely independent of 
any GUA namespace?





--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

[Ray Hunter (v6ops)]

Ted Lemon wrote:


If devices publish keys, then you can use those keys to make sure you 
are still talking to them. And the dnssec validation of local names 
would also work. Graceful renumbering should indeed result in DNS 
updates. Bear in mind that this is graceful, so the old and new ULAs 
coexist for a while.




Sounds good.

So can we assume

1) a single ULA namespace for resolving all active ULAs, that will 
eventually converge to only containing RRs from a single ULA?


2) And that ULA namespace is disjoint from/completely independent of any 
GUA namespace?



On May 13, 2016 06:45, "Ray Hunter (v6ops)" <v6...@globis.net 
<mailto:v6...@globis.net>> wrote:




Ted Lemon <mailto:mel...@fugue.com>
12 May 2016 15:48
As long as the renumbering process is clean, there is no downside
to renumbering, and no reason to be careful about which ULA you
ultimately wind up with.


So are you suggesting the Homenet (internal) namespace should be
independent of ULA address space?

In which case

1) how do we avoid the ".local" security problem where mobile
devices are unable to distinguish whether they've actually moved
to a different Homenet, or whether they've stayed still and their
own Homenet has just renumbered.

Or else

2) Does the renumbering mechanism also trigger an automatic
renaming too?

-- 
regards,

RayH

<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>



--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

[Ray Hunter (v6ops)]

Ted Lemon 
12 May 2016 15:48
As long as the renumbering process is clean, there is no downside to 
renumbering, and no reason to be careful about which ULA you 
ultimately wind up with.


So are you suggesting the Homenet (internal) namespace should be 
independent of ULA address space?


In which case

1) how do we avoid the ".local" security problem where mobile devices 
are unable to distinguish whether they've actually moved to a different 
Homenet, or whether they've stayed still and their own Homenet has just 
renumbered.


Or else

2) Does the renumbering mechanism also trigger an automatic renaming too?

--
regards,
RayH

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

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

[Ray Hunter (v6ops)]

Juliusz Chroboczek 
12 May 2016 15:10
If I'm reading you correctly, Ray, you're promoting unstable naming.

Not promoting. Looking at the consequences.

   If
I have two routers called trurl and pirx in my network, then my printer
will becalled diablo630.pirx.home whe pirx is up, diablo630.trurl.home
when trurl is up, and either I reconfigure all of my hosts every time
I swap a router, or rely on the DNS search list being correct?


We have multiple independent address spaces (ULA per router + GUA per
provider),

actually I was thinking more along the lines of the printer being called

diablo630.default_zone.ula1.home (ULA1)

and

diablo630.default_zone.ula2.home (ULA2 if it exists)

and

diablo630.my_isp1.com (GUA1)

and

diablo630.my_isp2.net (GUA2)


simultaneously.

The DNSSL would indeed be updated automatically when the homenet 
autoconfigures, and advertised by RA.


The name registration and resolution for the various namespaces could 
run independently.

No, we have a GUA per provider, and *optionally* a single ULA for the
whole Homenet:

   An HNCP router SHOULD create a ULA prefix if there is no other IPv6
   prefix with a preferred time greater than 0 in the network.  It MAY
   also do so if there are other delegated IPv6 prefixes, but none of
   which is locally generated [...]  In case multiple locally generated
   ULA prefixes are present, only the one published by the node with
   the greatest node identifier is kept

Thanks for that explanation.

If a new router is added, a new ULA is added,


No, that's not the case.
What happens if that new router has been booted stand-alone (so it 
creates its own ULA), and then joins the Homenet by being plugged in, 
and has a higher node identifier?


Shouldn't this be a voting mechanism to retain the "most popular" 
existing ULA?

If a router is removed or dies, the ULA prefix expires


Nope.  If a router dies, any ULA should remain stable, even if it's the
router who originally generated the ULA that dies:

When a new ULA prefix is created, the prefix is selected [...] using
the last non-deprecated ULA prefix

That's the whole point of using a ULA.
Well even then you have the corner case of a split, stable operation, 
remerge, where one of the two ULA prefixes will disappear.


If the namespace relies in any way on the ULA, it'll change if the ULA 
changes.


If the namespace doesn't rely on the ULA, we'll likely get hit by the 
same (security) problems as mobile devices moving between disjoint 
.local networks.


Or else we have to manually configure a "Homenet root name"/ "Homenet 
identifier"?


Thoughts?

--
regards,
RayH

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

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

[Ray Hunter (v6ops)]

Ted Lemon 
11 May 2016 20:03
DNS update is pretty simple.   Any problem with using that?

Not with the update mechanism itself


I think you may be slightly conclusing "authoritative" and "primary." 
  There is no need to elect authoritative servers--just make them 
secondary to the elected primary.   You can't have two primaries with 
stock DNS--that's probably the biggest fly in the ointment.



Exactly.

The challenge is the Homenet requirement to support network segmentation 
and remerging.


We have multiple independent address spaces (ULA per router + GUA per 
provider), so why not multiple namespaces?


If a new router is added, a new ULA is added, together with associated 
namespace, and infra.
If a router is removed or dies, the ULA prefix expires, together with 
associated namespace and infra.


If a new ISP uplink is added, a new GUA is added, together with 
associated (upstream) (globally resolvable) namespace and infra.
If an ISP is removed or dies, the GUA expires, together with associated 
namespace and infra.


Then the namespace infra/ update server could be tightly bound to the 
device that delegates/creates it (either the homenet router, homenet 
border router, or the ISP infra)


I know people don't like DNS search lists, but they do work, and are 
widely supported. Or else a recursive resolver running on the local 
homenet router could handle the search work for the end hosts.


I also realize this creates a new challenge of how to update all of 
these various namespaces.


The reason to have a hybrid proxy is because we have to support 
existing devices.   Clearly it's not the right long-term solution, but 
we can't force vendors to implement something new if they don't want to.





--
regards,
RayH

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

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

[Ray Hunter (v6ops)]

Juliusz Chroboczek 
11 May 2016 18:29

Bonjour is (roughly) based on Appletalk AFAIK. I've got nothing against
Appletalk Phase II, so if Bonjour was extended to provide an equivalent
function to Appletalk Phase II Zone Information Protocol = ZIP then I'd be
happier. That would cover concerns on non-overlapping name spaces. And
Appletalk NBP/ZIP resolution also prevents loops in routed networks.


« The AppleTalk Zone Information Protocol (ZIP) manages the relationship
   between network numbers and zone names. »

While I could in principle go and pick a copy of Inside Appletalk at the
library, I'd be grateful if you could explain what you have in mind.
I do happen to have a (yellowed) copy of "Inside Appletalk" on my 
bookshelf ;)


It would be new functionality to Bonjour, so strictly speaking it's out 
of scope for Homenet.


AFAIK (and I'm sure someone will keep me honest here) Appletalk strongly 
binds network numbers/cable ranges (prefixes in IPv6) to zones (logical 
groupings). Zone associations to network numbers/links are controlled by 
the Appletalk routers (not the hosts directly) and are associated with 
either a logical or physical link. The routing of name resolution 
requests to (extended) networks is based on zones. There can be multiple 
zones per network number, but the first zone is the "default zone" that 
hosts should use if they have no other preference. Host interfaces can 
only have a single network address and be a member of a single zone 
(although I've never actually seen that defined anywhere).


I leave it as a discussion point of whether that's a good model for 
Homenet, especially since IPv6 explicitly supports multiple prefixes per 
link and multiple addresses per interface per host.


Allowing a tight binding of IPv6 prefix <-> Homenet namespace zone could 
possibly work and simplify any solution for e.g. reverse resolution.


The key characteristics (that currently seem to be missing) would be:

1) a mechanism to route name resolution requests in an L3 network

2) a mechanism to prevent/ mitigate the effect of any (transient) loops 
in the name resolution infra (could be sub-function of 1)


3) a mechanism to advertise "zones" between Homenet routers.

4) a mechanism to advertise zones to hosts.

5) a field to indicate "zone membership" of a particular name/label to 
be used by hosts when advertising/resolving names.



I don't like the hybrid proxy model either.  It promises the union of
the problems and intersection of the functionality.  Proxying flies in
the face of the trend of smart devices and dumb networks.


Very well put.

-- Juliusz


--
regards,
RayH

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

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

[Ray Hunter (v6ops)]

Ted Lemon 
11 May 2016 18:37

> I don't like the hybrid proxy model either.  It promises the union of
> the problems and intersection of the functionality.  Proxying
flies in
> the face of the trend of smart devices and dumb networks.

Very well put.


Be that as it may, Homenet in general flies in the face of that trend. 
  And if you think about it, that trend isn't really a very smart 
trend, because the burden it places on devices is extreme, and not all 
devices have infinite resources to spend mapping the network and 
figuring out how to publish their services on it.


But if we were to build a smart network from scratch, I also wouldn't 
start with proxies, nor maintain a distributed database in the hosts.


I'd start with letting the routers build a naming infra, together with 
defining a (simple) name registration protocol between host and on-link 
router(s) (together with conflict resolution to communicate "sorry, that 
names already taken")


And the starting point would then probably be HNCP + DNS to elect a max 
of 'n' authoritative name servers per homenet, where 'n' NS and  
records can fit it a single UDP packet.


So whether you prefer a "smart host" or "smart network" model, hybrid 
proxies seem a poor compromise.


--
regards,
RayH

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

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

[Ray Hunter (v6ops)]

On 11 May 2016, at 15:01, Ray Hunter (v6ops) <v6...@globis.net 
<mailto:v6...@globis.net>> wrote:


Tim Chown wrote:
On 25 Apr 2016, at 03:39, Ted Lemon <mel...@fugue.com 
<mailto:mel...@fugue.com>> wrote:


On Sun, Apr 24, 2016 at 12:29 PM, Juliusz Chroboczek 
<j...@pps.univ-paris-diderot.fr 
<mailto:j...@pps.univ-paris-diderot.fr>> wrote:


> Juliusz, the problem is that existing home network devices that do
> DNS-based service discovery do not support DNS update. They
could, but
> they don't, because we didn't define an easy way for them to
do it.

I'd be grateful if you could expand on that.  Why can't we
define a way
for clients to do DDNS?


We can and should.   The problem is that we won't see that code 
ship in new devices anytime soon, so we still have to make mDNS work.


And this is why the dnssd WG is focused on making mDNS work on 
multi-subnet networks.

That to me seems to be putting pragmatism before requirements.


To an extent it is. The Bonjour protocols are much more widely 
implemented and deployed than DNS Update.


Yes. I've seen a lot of printers shipping with it, and it works great at 
that scale.


I've also seen enterprises working with fully integrated DNS, together 
with managed Windows Domain Controllers, at monster scale.


Homenet is somewhere in the middle: we have more complexity, but no 
"computer certificates" to fall back on.


I'm not entirely convinced by the dnssd work, and have said so on the 
relevant WG.


Do you mean the need for it based on Bonjour, or the solution given 
we’re building on that?

Both.

Bonjour is a great protocol for a flat L2 network.

Bonjour is not designed for L3 networks (no inherent hop count, nor loop 
protection), nor support for multiple/overlapping name spaces.


The Homenet architecture calls for administrative zones.

I may have a guest LAN.
I may have a printer LAN (that is shared with guests)
I may have a media server (which is not shared with guests)

The Homenet architecture calls for multiple upstream providers.

I may have an electricity provider who allows me some special log on via 
the power network to control home automation, or feed back from my solar 
panels. They may publish (private) names for use by contracted customers 
that are not available over the Internet. Yes, that could also be done 
over Internet, but a specialised "walled garden" could be so much more 
secure and less vulnerable to external disruption.


Bonjour is (roughly) based on Appletalk AFAIK. I've got nothing against 
Appletalk Phase II, so if Bonjour was extended to provide an equivalent 
function to Appletalk Phase II Zone Information Protocol = ZIP then I'd 
be happier. That would cover concerns on non-overlapping name spaces. 
And Appletalk NBP/ZIP resolution also prevents loops in routed networks.


Otherwise I struggle to map the Homenet requirements onto the solution.

[BTW for the record, I don't consider DNS "as-is today" a great 
contender either. So I'm not just bashing Bonjour by any means]




Note that one requirement was that other SD protocols could be 
integrated into the hybrid proxy model. That’s still possible, but no 
one has expressed any interest as yet.



I don't like the hybrid proxy model either.

It promises the union of the problems and intersection of the functionality.

Proxying flies in the face of the trend of smart devices and dumb networks.

If you get any device that bypasses, or misunderstands, the proxy 
topology, we could get very nasty name resolution loops [no inherent 
loop protection in Bonjour].


But Ted has raised the question of DNS Update there, and we agreed 
in BA that we’d accept a draft on issues around coexistence of mDNS 
and DNS Update.
If "it" (multi-subnet mDNS) is going to cause more issues down the 
line, is it sensible to pull this into Homenet now?


I think this is why Ted is doing what he is doing.  Homenet is a 
different environment - smaller and unmanaged, generally.



Is that the intended question to be answered by that draft?


The question is what happens in environments where both might mix. 
 Well, that’s one question.  Ted offered to draft a -00 on that topic, 
in one of his spare moments ;)



That seems like a worthwhile draft.


> Just 2136 isn't enfough, because there's no authentication
scheme,

I don't understand this argument.  How is non-secured DDNS any
less secure
than mDNS?  What am I missing?


This is an implementation issue, not a security issue--sorry for 
not making that clear.   In order to preserve the same security 
characteristics that mDNS has, we have to ensure that the update 
actually originated on the local link, which requires a different 
sort of listener than is present in a typical DNS server.   And 
existing DNS servers typically don't have any way to support 
unauthenticated updates on a first-come, first

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

[Ray Hunter (v6ops)]

Tim Chown wrote:
On 25 Apr 2016, at 03:39, Ted Lemon > wrote:


On Sun, Apr 24, 2016 at 12:29 PM, Juliusz Chroboczek 
> wrote:


> Juliusz, the problem is that existing home network devices that do
> DNS-based service discovery do not support DNS update. They
could, but
> they don't, because we didn't define an easy way for them to do it.

I'd be grateful if you could expand on that.  Why can't we define
a way
for clients to do DDNS?


We can and should.   The problem is that we won't see that code ship 
in new devices anytime soon, so we still have to make mDNS work.


And this is why the dnssd WG is focused on making mDNS work on 
multi-subnet networks.

That to me seems to be putting pragmatism before requirements.

I'm not entirely convinced by the dnssd work, and have said so on the 
relevant WG.


But Ted has raised the question of DNS Update there, and we agreed in 
BA that we’d accept a draft on issues around coexistence of mDNS and 
DNS Update.
If "it" (multi-subnet mDNS) is going to cause more issues down the line, 
is it sensible to pull this into Homenet now?


Is that the intended question to be answered by that draft?



> Just 2136 isn't enfough, because there's no authentication scheme,

I don't understand this argument.  How is non-secured DDNS any
less secure
than mDNS?  What am I missing?


This is an implementation issue, not a security issue--sorry for not 
making that clear.   In order to preserve the same security 
characteristics that mDNS has, we have to ensure that the update 
actually originated on the local link, which requires a different 
sort of listener than is present in a typical DNS server.   And 
existing DNS servers typically don't have any way to support 
unauthenticated updates on a first-come, first-served basis, so if 
you allow unauthenticated updates, you don't have any way to avoid 
collisions.   Otherwise you are correct.   The answer is to write a 
document that describes how to do that, and if you read the homenet 
naming arch document, you can see that I actually sketched out a 
solution there, which I expect to go in a different document, likely 
in a different working group.


There are many worms in that can :)
I understand that this is potentially a huge can of worms, but if no one 
opens it, it'll never get solved.


So my preference would be to write down what we want in Homenet (in the 
naming architecture document, in a technology-agnostic way), analyse the 
gaps against competing current technologies, and then see what people 
propose to close those gaps.


If multi-subnet mDNS comes out a clear winner, then I'll shut up.

But I'm not even convinced that the gaps are understood/ documented at 
this time.





Oh, sure, we Poles are not quite as pessimistic as the Finns.  I'm
actually of a divided mind here -- I rather like distributed
solutions
(hence prefer mDNS to DDNS) but dislike proxying.  Part of me
just wishes
we'd mandate site-local multicast and do mDNS over that


The problem with site-local multicast for mDNS is that multicast 
isn't a great solution even on the local wire when that wire is 
wireless.And, you have to do modify the client anyway.


Indeed; this was discussed early on in the dnssd WG, and not 
considered for those reasons.


Furthermore, if you consider the mdns hybrid proxy stateless, then 
you can have a DNS server that is roughly that stateless too.   I 
think it provides better service continuity if you are willing to 
retain some state, but everything will still work even if you don't, 
just as the hybrid proxy does.


Agreed.

Tim



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




--
regards,
RayH

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

Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt

[Ray Hunter (v6ops)]

Mikael Abrahamsson <mailto:swm...@swm.pp.se>
30 Nov 2015 08:33
On Fri, 27 Nov 2015, Ray Hunter (v6ops) wrote:


How would you "move a /64 around"?


Well, the same way you would move a /128 around I guess.


Not sure that's correct.

When moving a /64 per host you have to presume a /64 has been allocated 
to a host already.


So every time a new host joined wifi you'd have to re-run the entire 
HNCP prefix allocation algorithm AFAICS, and check whether there's a 
conflict of this /64 still being active elsewhere. Unless of course you 
pre-allocate a pool in advance assuming there'll be a certain number of 
hosts on wifi.


On the other hand, for moving individual hosts, I've used a CIDR trick 
in the past when moving data centres that 2 or more LANs are configured 
with an identical IPv4 prefix, and then I've added host routes + proxy 
ARP to trick hosts into thinking they're actually directly connected. 
Should also work for IPv6 as long as CIDR is truly 128 bits (RFC7608).


So it seems to me the missing pieces of the puzzle for moving IPv6 /128 
could be:


1. Identifying cooperating router interfaces across the Homenet and 
assigning a common /64 to them in prefix allocation
2. Maintaining a list of /128 wifi hosts bound to the cooperating 
routers interfaces [including MAC address].
3. detecting "side changes" (in bridge speak) where a host has changed 
connection point and packets are arriving on a new cooperating 
interface. Could potentially be detected when receiving a DAD for a /128 
from the list of wifi hosts with identical MAC address to one previously 
observed.
4. injecting and removing /128 routes as hosts move between cooperating 
interfaces, and updating with list of /128 wifi hosts.
5. Proxy ND equivalent to proxy ARP to answer ND requests on cooperating 
router "local" interfaces for hosts connected to "remote" interfaces.


Proxy ND would include DAD [defending a request for a /128 on a 
cooperating interface with a MAC address not included in the list of 
/128 wifi hosts], but also answering standard ND queries AFAICS so that 
wi-fi connected hosts could inter-communicate. Answers to standard 
queries could be triggered by the presence of a /128 route in a similar 
way to IPv4 proxy-arp.


I'm presume cooperating routers would have to maintain a translation 
table of MAC address to /64 prefix per host wireless interface.


What's the practical difference with moving a /64 (which still 
requires routing changes AFAICS) compared to moving a /128 host route?


None, apart from that a host seldom has a single /128 but instead 
several /128:s. The biggest upside is that you don't need to do DAD 
handling between participating wifi routers (since the host is alone 
in the /64, there is no need to do inter-router DAD).


--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt

[Ray Hunter (v6ops)]

Mikael Abrahamsson <mailto:swm...@swm.pp.se>
30 Nov 2015 08:33
On Fri, 27 Nov 2015, Ray Hunter (v6ops) wrote:


How would you "move a /64 around"?


Well, the same way you would move a /128 around I guess.


Not sure that's correct.

When moving a /64 per host you have to presume a /64 has been allocated 
to a host already.


So every time a new host joined wifi you'd have to re-run the entire 
HNCP prefix allocation algorithm AFAICS, and check whether there's a 
conflict of this /64 still being active elsewhere. Unless of course you 
pre-allocate a pool in advance assuming there'll be a certain number of 
hosts on wifi.


On the other hand, for moving individual hosts, I've used a CIDR trick 
in the past when moving data centres that 2 or more LANs are configured 
with an identical IPv4 prefix, and then I've added host routes + proxy 
ARP to trick hosts into thinking they're actually directly connected. 
Should also work for IPv6 as long as CIDR is truly 128 bits (RFC7608).


So it seems to me the missing pieces of the puzzle could be:

1. Identifying cooperating router interfaces across the Homenet and 
assigning a common /64 to them in prefix allocation
2. Maintaining a list of /128 wifi hosts bound to the cooperating 
routers interfaces [including MAC address].
3. detecting "side changes" (in bridge speak) where a host has changed 
connection point and packets are arriving on a new cooperating 
interface. Could potentially be detected when receiving a DAD for a /128 
from the list of wifi hosts with identical MAC address to one previously 
observed.
4. injecting and removing /128 routes as hosts move between cooperating 
interfaces, and updating with list of /128 wifi hosts.
5. Proxy ND equivalent to proxy ARP to answer ND requests on cooperating 
router "local" interfaces for hosts connected to "remote" interfaces.


Proxy ND would include DAD [defending a request for a /128 on a 
cooperating interface with a MAC address not included in the list of 
/128 wifi hosts], but also answering standard ND queries AFAICS so that 
wi-fi connected hosts could inter-communicate. Answers to standard 
queries could be triggered by the presence of a /128 route in a similar 
way to IPv4 proxy-arp.


I'm presume cooperating routers would have to maintain a translation 
table of MAC address to /64 prefix per host wireless interface.


What's the practical difference with moving a /64 (which still 
requires routing changes AFAICS) compared to moving a /128 host route?


None, apart from that a host seldom has a single /128 but instead 
several /128:s. The biggest upside is that you don't need to do DAD 
handling between participating wifi routers (since the host is alone 
in the /64, there is no need to do inter-router DAD).


--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt

[Ray Hunter (v6ops)]

Mikael Abrahamsson <mailto:swm...@swm.pp.se>
26 Nov 2015 16:15
On Thu, 26 Nov 2015, Ray Hunter (v6ops) wrote:


I have read this draft and find it interesting.

The use of host routes would seem appealing to avoid
1) any need for stateful "home agent" and multiple forwarding
2) renumbering of the end nodes when roaming
3) relatively small number of hosts compared to the complexity of the 
topology


Use of RFC7217 addresses would seem appropriate, but that assumes 
that DAD really is reliable at the time a node attaches to the 
homenet for the first time.


Wouldn't it be better to adopt 
https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-02 
and just give every device its own /64 and move that around?


Having a full /64 would seem attractive (for maintaining outbound 
sessions on temporary addresses etc.)


How would you "move a /64 around"?

I'm presume cooperating routers would have to maintain a translation 
table of MAC address to /64 prefix per host wireless interface.


What's the practical difference with moving a /64 (which still requires 
routing changes AFAICS) compared to moving a /128 host route?


What's the practical difference in the trigger for executing the move 
(ND neighbor table update, as opposed to a MAC being detected as having 
changed attachment point)?
My worry about the whole L3 approach is how long does it take to 
re-establish packet flows after the L2 wifi handover between APs 
compared to an L2 only solution?


What's the benefit/downside of this approach compared to having 
roaming nodes actively take part in the HNCP acting as "multi-homed 
routers" with an internal (invariant) /64 VLAN used to bind to 
applications?


I'd say this approach adds one more layer that needs to come up before 
packets can start flowing again, especially since it would require 
routing protocol participation as well, I'd imagine.


If 802.11 can assure L2 handover in 1 second (I don't know how long 
the handover time is, just guessing), how much are we willing to add 
in time because of L3 mechanisms added on top of this, before packet 
flows are up and running again?


--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt

[Ray Hunter (v6ops)]

Alexandre Petrescu wrote:

Hi,

Using host-based routes in a homenet to support mobility (rather than 
Mobile IP) may make sense because the domain is relatively small.


The draft could benefit from illustrating at least a simple topology, 
to understand what the author really means, because there are very 
many possible topologies to talk about.


Alex

Le 16/10/2015 13:36, Steven Barth a écrit :

Hi everyone,

here is some attempt to formalize a simple WiFi roaming approach
using host routes and a stateless proxy for DAD NDP messages.

It's a bit theoretical right now but may be useful as a start for a
discussion. We could do a talk on it in Yokohama as well.



Cheers,

Steven


On 16.10.2015 13:32, internet-dra...@ietf.org wrote:

A new version of I-D, draft-barth-homenet-wifi-roaming-00.txt
has been successfully submitted by Steven Barth and posted to the
IETF repository.

Name:draft-barth-homenet-wifi-roaming
Revision:00
Title:Home Network WiFi Roaming
Document date:2015-10-16
Group:Individual Submission
Pages:7
URL:
https://www.ietf.org/internet-drafts/draft-barth-homenet-wifi-roaming-00.txt 

Status: 
https://datatracker.ietf.org/doc/draft-barth-homenet-wifi-roaming/
Htmlized:   
https://tools.ietf.org/html/draft-barth-homenet-wifi-roaming-00



Abstract:
This document describes a mechanism to manage host routes and
statelessly proxy IPv6 Duplicate Address Detection messages between
multiple WiFi links to allow client roaming.




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.

The IETF Secretariat


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






I have read this draft and find it interesting.

The use of host routes would seem appealing to avoid
1) any need for stateful "home agent" and multiple forwarding
2) renumbering of the end nodes when roaming
3) relatively small number of hosts compared to the complexity of the 
topology


Use of RFC7217 addresses would seem appropriate, but that assumes that 
DAD really is reliable at the time a node attaches to the homenet for 
the first time.


What happens if a homenet becomes temporarily "split-brain" and then 
remerges?

Isn't there a danger of two nodes acquiring the same address.
What happens then? (as DAD has already completed on both client nodes)

What's the mechanism/timing of ND expiry compared to WIFI roaming and 
distribution of route updates?

Isn't this going to be "too slow"?
Should the routers be performing an active "keep alive" on locally 
attached nodes?

[not good for battery life on wireless]

What about using an explicit registration, with each homenet router 
acting as a 6LBR?
e.g. RFC6775 ND Optimization for 6LoWPANs, as the registration 
mechanism, which is then used to inject the host route.


What's the benefit/downside of this approach compared to having roaming 
nodes actively take part in the HNCP acting as "multi-homed routers" 
with an internal (invariant) /64 VLAN used to bind to applications?


--
regards,
RayH

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

Re: [homenet] WiFi handover [was: question: equal-cost multipath?]

[Ray Hunter (v6ops)]

Alexandru Petrescu 
2 Sep 2015 11:31


Le 01/09/2015 18:06, Ray Hunter a écrit :

inline

Alexandru Petrescu wrote:



Le 12/08/2015 14:20, Eric Vyncke (evyncke) a écrit :




While I pay for it, I never use the millions of WiFi access points I
can
use here in the Netherlands. I tried it once, walking in a small
city. At
the time the handover was completed, the connectivity was gone.


This is a question of use-cases.  In a city yes there are many
hotspots but also yes they're sparsely distributed - you must handover
to something else in between.  In a home network they'd be densely
distributed, could hand-over directly, or not at all.

Actually they're pretty densely distributed around me.

There's one AP per household (via the cable TV provider) which has an
SSID for dedicated use.

These also support the guest/roaming access using a common SSID
identical on all APs.


YEs.


There are 5 apartments within wifi range of my desktop (I can see that
via the dedicated SSID).
And I find 12 on my mobile if I walk to the balcony.


I can agree.   I guess while the beacons are seen strong, once 
connected the strength becomes lower for some reason.


Also, automatic handing-over to such apparently dense hotspots is 
hampered on-purpose by administrative will: security keys, captive 
portals, acceptance conditions, and more.


It's a problem in home networks and also while travelling: airport, 
hotel, restaurant networks.


I am not sure how to relate this precisely to homenet WG...

Alex

Homenet has created multiple L3 routed wifi networks.

I think we'll probably have to wait for DMM to nail down thier potnetial 
solutions before drawing firm conclusions. There's not a lot of specific 
information in the DMM WG documents I read so far, as it's early days.


But I think it's fair to conclude that there'll be some interaction with 
/extension of HNCP required (for selecting and configuring IP anchors 
and SSIDs).






You could be moving a lot and never handing over, as much as you could
sit and do many hand-overs per second.

Such use-cases and reqs are described in DMM WG documents.


ACK


Alex

 It might

have to do with IEEE and IETF mismatch. Same SSID shall have same IP
subnet (IEEE) versus each link has its own subnet (some of IETF, no
formal statement...).


Of course, if every SSID has its own 192.168.0.0/24, oups, this is
legacy
IP, so, not a Homenet topic :-O

Sorry could not resist

-éric

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










--
regards,
RayH

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

Re: [homenet] Host naming in Homenet

[Ray Hunter (v6ops)]

Michael Thomas wrote:



On 08/31/2015 04:42 AM, Ray Hunter (v6ops) wrote:


Juliusz (and others) have objected to 
https://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options 
because it appears to be tied to the ISP. Yet for reverse resolution, 
the ISP is an essential party, because they have been delegated the 
DNS zone for their entire allocated address space. And Homenet uses 
delegated prefixes from within this overall allocation.


What that tells me, on the other hand, is that these are two separate 
problems that
just need to get solved. And, in fact, the forward and reverse maps 
may not same auth/authz

requirements for their respective CRUD operations.

Mike

I think you may be right, assuming we want to do DNS for Homenet properly.

i.e. we should be talking about updating multiple ISPs for reserve 
resolution (per delegated IPv6 prefix), and potentially multiple ISPs or 
independent DNS providers for forward resolution (per delegated name space).


And when we're talking about "updating" we also have at least two 
alternatives:
1) maintaining the RRs in the ISPs' or 3rd party DNS providers' DNS 
servers, or
2) ensuring proper delegation and glue records exist, pointing at 
Homenet's own DNS servers (whether they are located on or off Homenet).


Automating zone delegation and glue record insertion with zeroconf seems 
quite a hole in current standards.

and that is also not covered in DNS-SD AFAICS.


--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Ray Hunter (v6ops)]

STARK, BARBARA H 
1 Sep 2015 12:23
and that is also not covered in DNS-SD AFAICS.


As a potential end user of homenet (i.e., within my personal home 
network), I very much do *not* want any of my IoT devices, printers, 
or scanners to be publicly discoverable via DNS. If and when I want 
anything discoverable via public DNS, I want to be very explicit about 
what that is. So any "automating zone delegation" solution needs to 
have as a requirement that it must not automatically cause anything to 
be externally discoverable that the end user does not explicitly identify.


The tremendous lack of security being built into printers, scanners, 
IoT devices, and other devices on the home network suggest that 
automatically exposing them to external discovery would likely have 
Very Bad Consequences for the majority of end users (who will be 
completely unaware that such automatic exposure was occurring).

Barbara


I hear you.

But I think the discussion on automatic delegation of a DNS name space 
is separate from which content Homenet publishes in which zone.


I'm thinking of a delegation mechanism similar to how RFC3633 delegates 
address prefixes, that would allow a DNS service provider to delegate 
one or more subsets of their name space to a Homenet to use as it's 
parent name space.


The transport for this delegation mechanism might be DHCPv6, for the 
case where a DNS operator (the ISP) wants to delegate a reverse zone for 
PTR records for reverse resolution, but it might also be an API over 
HTTP for where there's a DNS provider who has no business relationship 
with the upstream ISP(s). Or both


The name space delegation would support the use case where the DNS 
service provider supplies information for the Homenet on how to update 
the RR hosted on the DNS provider's DNS servers, as well as the use case 
where the Homenet itself provides the DNS servers, and the DNS service 
provider has to enter NS records and glue records in their own DNS servers.


Once those name space delegations are in place, it would be a separate 
discussion on how content is generated and updated e.g. printers using 
ULA addresses should not be pushed to a zone visible on the public Internet.


If we don't have a set of unique parents for the Homenet name space 
(either delegated or self-generated), we'll also run into security 
issues, as .home or .local themselves are not unique for devices that 
roam between multiple (disjoint) Homenets. In exactly the same way that 
ULA addresses also have to be (reasonably) unique across the set of 
Homenets.


So myprintservice..home. would be fine for me for the ULA 
space. The  portion of the name space would obviously not 
generally be displayed to end users.


And for GUA space it could be myservice..myisp.com 
or myservice..mydnsservice.org



--
regards,
RayH

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

Re: [homenet] Host naming in Homenet

[Ray Hunter (v6ops)]

Erik Kline wrote:

On 26 August 2015 at 15:41, Juliusz Chroboczek
  wrote:

Can we just go with whichever recommendations come out of dnssd?

 https://datatracker.ietf.org/wg/dnssd/charter/
 https://datatracker.ietf.org/wg/dnssd/documents/

Could you perhaps point me at a specific paragraph of a specific draft and
tell me "Do implement this, we're betting the company on this protocol"?


No, I cannot...not at this time.  But solving the homenet case is a
requirement, and documented in https://tools.ietf.org/html/rfc7558
(section 3, use case "C", I believe).


I am familiar with Appletalk Phase 2, so the concepts in DNS-SD come as 
no surprise.


However, AFAICS after reading the DNS_SD documents including 
https://tools.ietf.org/html/rfc7558, I think I detect one hole for Homenet.


Although there's a requirement for topology independent zones and 
autoconfig, it's a bit opaque to me:


1) if overlapping zones/namespaces are allowed (multiple ISPs with 
potentially multiple parent delegated name spaces).
That was not allowed in Appletalk Phase 2, and the zones were configured 
manually by an administrator.


2) How the parent namespace(s) are delegated (using zeroconf).

We already have https://tools.ietf.org/html/rfc3633 for explicitly 
delegating address prefixes.


But there doesn't seem yet to be any appetite for a standard mechanism 
for delegating namespaces (e.g. via DHCPv6).


Juliusz (and others) have objected to 
https://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options 
because it appears to be tied to the ISP. Yet for reverse resolution, 
the ISP is an essential party, because they have been delegated the DNS 
zone for their entire allocated address space. And Homenet uses 
delegated prefixes from within this overall allocation.


Also DND SD (RFC 6763) states "Address-based Domain Enumeration queries 
are performed using names under the IPv6 reverse-mapping tree" which is 
under the direct control of the individual upstream ISPs.


So, what are people expecting to happen here?
ISP's to cooperate with independent name services when sending a DHCPv6 
delegation of a namespace e.g. a party like DYNDNS? So the Homenet 
learns everything via one neatly packaged DHCPv6 exchange with each 
upstream provider?

Multiple upstream DNS services that need to be updated?
Overlapping namespaces?
Multiple namespace delegation via multiple mechanisms? e.g. Homenet 
learns the reverse tree from the upstream ISP (via DHCPv6), and forward 
delegation (glue records) are entered via the domain registrar via http 
or something else?


In IPv4 I have my own private company domain bootstrapped by my own 
(manually added  glue records) from my own Domain Registrar (100% 
independent of my ISP). And the ISP adds dummy static reverse records 
and A records, so triple resolution works.


Is this what we want for IPv6, or do we have to deal with seeding 
information into multiple upstream DNS's?


Permitting inbound services and restoring the end to end architecture of 
the Internet is a big part of Homenet IMVHO


--
regards,
RayH

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