Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
Juliusz Chroboczek writes: >> Why? What is wrong with the owner of the network selecting which devices >> / services he/she wants globally reachable > > I don't think this is about global reachability (which is hopefully > managed by PCP), it's about exporting names into the global DNS. We > ought to distinguish the two -- you can be remotely reachable without > publishing your name in the DNS. Fair enough. >> without each device/service having to implement (and be configured for) >> an external naming provider? > > Roughly 100% of Homenet devices don't need a name in the global DNS -- > neither SIP, nor Skype, nor BitTorrent, nor syncthing, nor anything > else that normal people run in their home relies on the DNS for > locating remote peers. Well, those all work because they use a "giant MITM in the cloud" rendezvous point. If publishing things into global DNS worked reliably and automatically, and we had IPv6 everywhere, such designs would not be needed... > In the rare case where a device needs to be in the global DNS (and the > only case I can see is that of a web server), I'd much rather > configure that on the device itself than on the buggy web interface of > my ISP-provided CPE (or, even worse, "in the cloud"). Right, I can certainly see where you're coming from with this :) -Toke ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
Hi, On Mon, Jul 23, 2018 at 08:50:50PM +0200, Toke Høiland-Jørgensen wrote: > Juliusz Chroboczek writes: > > > Exporting names from the Homenet into the global namespace, on the > > other hand, should be done by the hosts, with no involvement of any > > third party (neither the ISP nor the Homenet itself). This is where I > > argue for some form of end-to-end, secured, dynamic DNS update. > > Why? What is wrong with the owner of the network selecting which devices > / services he/she wants globally reachable without each device/service > having to implement (and be configured for) an external naming provider? This is homenet. There is nobody here who manages the network. Which seems to be the main difference in views here - "I have a middlebox where I can do configuration" vs. "the network is not managed, if I want something to happen, I do it on the host". Looking at my parents' setup, things like "teamviewer" work because they do not need configuration on their router. It has its own namespace, registers the host, and it can be found (due to IPv4 NAT, it needs to also use a rendezvous server, but that might hopefully go away one day). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> Why? What is wrong with the owner of the network selecting which devices > / services he/she wants globally reachable I don't think this is about global reachability (which is hopefully managed by PCP), it's about exporting names into the global DNS. We ought to distinguish the two -- you can be remotely reachable without publishing your name in the DNS. > without each device/service having to implement (and be configured for) > an external naming provider? Roughly 100% of Homenet devices don't need a name in the global DNS -- neither SIP, nor Skype, nor BitTorrent, nor syncthing, nor anything else that normal people run in their home relies on the DNS for locating remote peers. In the rare case where a device needs to be in the global DNS (and the only case I can see is that of a web server), I'd much rather configure that on the device itself than on the buggy web interface of my ISP-provided CPE (or, even worse, "in the cloud"). -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> Apparently my comment was clear as mud. I meant this: > https://tools.ietf.org/html/draft-ietf-opsawg-mud-25 Quote, "YANG-based JSON that describes a Thing", unquote. 61 pages. Revision 25, and still a draft. I wish you a lot of fun implementing that. > Having a public/private zone pair where the public zone is an image of > the private zone that is constructed following rules, the default rule > being "don't copy," seems very straightforward to me. It's not clear to > me in what sense it's brittle. It's brittle because you have state in the network. (You know, end-to-end argument and so on.) More concretely: - what happens when the current hidden master loses an election? Is the state magically transferred? - what happens when the current hidden master crashes/is unplugged/is retired? let alone the issue of electing the hidden master in the first place, which I believe Daniel hasn't addressed at all. > To me, the difference between what you are proposing, Juliusz, and what > Daniel is proposing, is where the control point is. For you, the control > point is the device. That's right. > For Daniel, the control point is the resolver. Which resolver? (I could be wrong, but I don't think that the Homenet architecture has a central resolver.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
Juliusz Chroboczek writes: > Exporting names from the Homenet into the global namespace, on the > other hand, should be done by the hosts, with no involvement of any > third party (neither the ISP nor the Homenet itself). This is where I > argue for some form of end-to-end, secured, dynamic DNS update. Why? What is wrong with the owner of the network selecting which devices / services he/she wants globally reachable without each device/service having to implement (and be configured for) an external naming provider? -Toke ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> By using DynDns are you proposing to remove the requirement of having > a naming resolution mechanism internally in the homenet ? No. Naming *internal* to the Homenet needs another mechanism, perhaps what Ted is designing (and implementing), perhaps something else. Exporting names from the Homenet into the global namespace, on the other hand, should be done by the hosts, with no involvement of any third party (neither the ISP nor the Homenet itself). This is where I argue for some form of end-to-end, secured, dynamic DNS update. > But considering that we need an internal dns to serve internal requests > (regardless of an ISP connection) and that we also need an outsourced > one for external resolution, isn't it simpler to make them synchronize > in a primary / secondary fashion ? Wouldn't it be an extra work to > manage (update/add/delete) multiple records through dyndns ? I claim it isn't. Synchronising with the external DNS provider is no more work than synchronising with the hidden master, and it avoids the hairy issue of electing the hidden master. > From my understanding dyndns would solve just a small part of the whole > problem being tackled here which is: providing internal/external name > resolution and manage the synchronization of an entire zone, rather than > updating a single record continuously. It solves the issue of exporting names into the public namespace. This has nothing to do with name resolution internal to the Homenet. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
Hi Juliusz, I'm just catching up in the mailing list here and I'd like to clarify if my understanding is correct. By using DynDns are you proposing to remove the requirement of having a naming resolution mechanism internally in the homenet ? DynDns does work nicely to update a single record whenever it changes. But considering that we need an internal dns to serve internal requests (regardless of an ISP connection) and that we also need an outsourced one for external resolution, isn't it simpler to make them synchronize in a primary / secondary fashion ? Wouldn't it be an extra work to manage (update/add/delete) multiple records through dyndns ? >From my understanding dyndns would solve just a small part of the whole >problem being tackled here which is: providing internal/external name >resolution and manage the synchronization of an entire zone, rather than >updating a single record continuously. Cheers Elson -Original Message- From: homenet On Behalf Of Juliusz Chroboczek Sent: Thursday, July 19, 2018 4:38 PM To: Ted Lemon Cc: Homenet Subject: Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS > One way to automate this would be using mud. A bright light shines from the heavens, bathing you in its warm glow. An enormous, white temple stands to the north, taking most of your view. In order to enter the Temple of Homenet Naming, you must travel up the large staircase that stands in front of you. Exits: North, West, East, South. (Perhaps you had something else in mind when you said MUD?) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
Apparently my comment was clear as mud. I meant this: https://tools.ietf.org/html/draft-ietf-opsawg-mud-25 Having a public/private zone pair where the public zone is an image of the private zone that is constructed following rules, the default rule being "don't copy," seems very straightforward to me. It's not clear to me in what sense it's brittle. Requiring each device to be configurable with a way to update a name server Out There, and managing the set of devices that are publishing their names, seems not merely brittle but also difficult to operate. To me, the difference between what you are proposing, Juliusz, and what Daniel is proposing, is where the control point is. For you, the control point is the device. For Daniel, the control point is the resolver. Each of these has different properties in terms of manageability. Depending on how each is used, your model may be easier or harder. What I have set up in my home assumes the mud model, although that's not actually implemented yet, and even the topology is a work in progress because I haven't gone back and fixed everything yet. The model is that all of my IoT devices are on their own network, which is firewalled from the rest of my network and has no external connectivity by default. If a device needs external access, it gets access to what mud says it needs access to (e.g., it can download its firmware updates, but not log in to facebook). If it wants to be externally reachable, its mud description would say so, and would say what would be allowed to reach in and touch it. This model would work with non-IoT devices as well—if they don't have mud descriptions, then by default they can reach out to touch anything, but nothing is allowed to reach in to touch them, and their names are not published. What's good about this model is that things can happen completely automatically. The end user is not asked to understand security models, and need take no action other than enrolling devices on the network, which I think is unavoidable. The only problem with this is that there's no way to automatically corral IoT devices to the IoT network. That said, what I've described here is out of scope for the current discussion, other than with respect to naming. On Thu, Jul 19, 2018 at 4:38 PM, Juliusz Chroboczek wrote: > > One way to automate this would be using mud. > > A bright light shines from the heavens, bathing you in its warm glow. An > enormous, white temple stands to the north, taking most of your view. > > In order to enter the Temple of Homenet Naming, you must travel up the > large staircase that stands in front of you. > > Exits: North, West, East, South. > > (Perhaps you had something else in mind when you said MUD?) > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> One way to automate this would be using mud. A bright light shines from the heavens, bathing you in its warm glow. An enormous, white temple stands to the north, taking most of your view. In order to enter the Temple of Homenet Naming, you must travel up the large staircase that stands in front of you. Exits: North, West, East, South. (Perhaps you had something else in mind when you said MUD?) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
The provisioning process for front end naming delegation we’re thinking of includes the provisioning of the domain name itself at the registry, and the setup on the home gateway itself and registration with an external secondary anycast for global name resolution. The gateway would have an internal and external view, where the external view would sync with the outsourced DNS service, could be using standard IXFR/AXFR methods. We would sign both internal/external views with DNSSEC and publish a CDS that the registry can take to bootstrap the delegation. We need to add a Dyn like process to sync external dynamic addresses to the external zone file. We’re not planning to use home.arpa because it will not have a secure chain of trust and if we have a domain name for external reachability (example.ca) then might as well use it internally. As a side note, I don’t think we should even think of building a solution to make home.arpa a secure delegation, it’s a good domain name for internal use and avoid name collisions, not good for DNSSEC. From: homenet On Behalf Of Ted Lemon Sent: Thursday, July 19, 2018 9:31 AM To: Stephen Farrell Cc: Homenet ; Daniel Migault ; Juliusz Chroboczek Subject: Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS One way to automate this would be using mud. On Thu, Jul 19, 2018 at 9:28 AM, Stephen Farrell mailto:stephen.farr...@cs.tcd.ie>> wrote: (with no hats...) On 19/07/18 10:42, Juliusz Chroboczek wrote: >> Also, think of the privacy implications if all of the services on the >> homenet had to be discovered from a shared zone like >> dyndns.org<http://dyndns.org>. > Quite the opposite. In the trivial update protocol, the update is > end-to-end, encrypted, and only the host and the DNS provider see the > data. Every Homenet, every host, heck, even every application can use > a different DNS provider, and each DNS provider only sees the data that > was explicitly sent to it. I'm also a bit puzzled by how the subset of records to be globally published relates to the set of records that are to be internally visible. I guess this is not something that we'd fully standardise, but there are privacy issues here if too much gets published globally, so there may be some protocol (change/tweak) required to make it possible for implementers to distinguish which information ought be globally visible, and which not. Cheers, S. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> On the other hand same thing using nsupdate (using TSIG and dynamic > dns) is one command line + input file for nsupdate: Cool. Whichever end-to-end (host to DNS provider with no intermediate proxying) encrypted and authentified protocol you pick, I'm with you. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
Juliusz Chroboczek writes: > And it's literally four lines of shell: > > while true; do > wget --post-data 'name=gameserver.myhome.net=topsecret' \ > https://dyndns.example.com > sleep $((24 * 3600)) > done How does that get both IPv4 and IPv6 addresses published? Perhaps bit more parameters are needed? The reason people use those dyndns services is because they only use IPv4, and they have NATs, and they want to publish the outer address of the NAT. I would hope we are getting proper non-natted IPv6 networks with globally routable address at home too, so you do not need to use such hacks. On the other hand same thing using nsupdate (using TSIG and dynamic dns) is one command line + input file for nsupdate: -- nsupdate -k $KEYFILE << EOF server ns.example.com. zone myhome.net. update add gameserver.myhome.net. 3600 A $IP4 update add gameserver.myhhome.net. 3600 $IP6 send EOF -- No need to sleep and do operations periodically, you only need to run this when the IP-addresses change... -- kivi...@iki.fi ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
>> And it's literally four lines of shell: > vs > while true; do > (omitted for brevity) You're doing end-to-end dynamic update over DNS, which is fine with me. The exact transport we end up using doesn't matter that much. You're not doing the proxying through a hidden master mandated by Daniel's draft, which is what I find complex and fragile. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> On 19 Jul 2018, at 11:58 pm, Mark Andrews wrote: > > > >> On 19 Jul 2018, at 11:30 pm, Juliusz Chroboczek wrote: >> >>> I am not speaking about discovery within the Homenet. I am speaking about >>> exporting names into the global DNS, which is what Daniel's draft is >>> about. >> >>> Yes, but the problem is that you are treating this as if these are two >>> separate problems, but they are not. >> >> These are two completely different problems, with different default >> behaviours and different failure modes. >> >> The default behaviour for the local zone is that devices should be >> discoverable. The default behaviour for the public DNS is that a device >> should not be published unless it takes explicit action. >> >> It makes a lot of sense to have two different protocols, rather than >> essentially leaking a local zone into the ISP's DNS servers. >> >>> I'm not following your reasoning here -- why does the zone being tied to >>> the ISP imply that we must use a more complex protocol? >> >>> Doing this transaction over HTTP means another service that the ISP has >>> to operate, >> >> Not the ISP, a third-party DNS provider. That's the whole point. >> >>> and another service that the HNR has to connect to. >> >> Not the HNR, the end host. That's the whole point. >> >> And it's literally four lines of shell: >> >> while true; do >> wget --post-data 'name=gameserver.myhome.net=topsecret' \ >>https://dyndns.example.com >> sleep $((24 * 3600)) >> done > > vs > > while true; do > ( > # delete all the existing records > update delete host.example.com IN > # add in all the GUA records > ifconfig -a inet6 | > sed -n -e '/%/d' -e '/ ::1 /d' -e '/ > fd[0-9a-f][[0-9a-f]:/d’ \ > -e 's/inet6/update add host.example.com 3600 IN /‘ \ > -e 's/ prefixlen.*//p’ > # tell nsupdate to send the update request. Nsupdate will work > out zone and > # DNS servers to send the update request too. > echo send > ) | nsupdate -y Khost.example.net.+001+56524 > sleep $((24 * 3600)) > done And I forgot to mention that this supports multiple records. > >>> Quite the opposite. In the trivial update protocol, the update is >>> end-to-end, encrypted, and only the host and the DNS provider see the >>> data. >> >>> You've published a record in a public zone. It doesn't matter that the >>> protocol you used to publish it is privacy-protecting, because the >>> publication of the name immediately negated that. >> >> With delegation through an ISP-controlled hidden master, the ISP gets >> a database of all the names published by all of its users. >> >> With an encrypted connection to a DNS provider, the ISP needs to troll all >> of the DNS providers in order to build such a database. >> >>> I actually share your concern that what he's got written down right now >>> is more complicated than it needs to be, and this is partly because it >>> was originally motivated by his work at an ISP. >> >> Uh-huh. >> >> -- Juliusz >> >> ___ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> On 19 Jul 2018, at 11:30 pm, Juliusz Chroboczek wrote: > >>I am not speaking about discovery within the Homenet. I am speaking about >>exporting names into the global DNS, which is what Daniel's draft is >>about. > >> Yes, but the problem is that you are treating this as if these are two >> separate problems, but they are not. > > These are two completely different problems, with different default > behaviours and different failure modes. > > The default behaviour for the local zone is that devices should be > discoverable. The default behaviour for the public DNS is that a device > should not be published unless it takes explicit action. > > It makes a lot of sense to have two different protocols, rather than > essentially leaking a local zone into the ISP's DNS servers. > >>I'm not following your reasoning here -- why does the zone being tied to >>the ISP imply that we must use a more complex protocol? > >> Doing this transaction over HTTP means another service that the ISP has >> to operate, > > Not the ISP, a third-party DNS provider. That's the whole point. > >> and another service that the HNR has to connect to. > > Not the HNR, the end host. That's the whole point. > > And it's literally four lines of shell: > >while true; do >wget --post-data 'name=gameserver.myhome.net=topsecret' \ > https://dyndns.example.com >sleep $((24 * 3600)) >done vs while true; do ( # delete all the existing records update delete host.example.com IN # add in all the GUA records ifconfig -a inet6 | sed -n -e '/%/d' -e '/ ::1 /d' -e '/ fd[0-9a-f][[0-9a-f]:/d’ \ -e 's/inet6/update add host.example.com 3600 IN /‘ \ -e 's/ prefixlen.*//p’ # tell nsupdate to send the update request. Nsupdate will work out zone and # DNS servers to send the update request too. echo send ) | nsupdate -y Khost.example.net.+001+56524 sleep $((24 * 3600)) done >>Quite the opposite. In the trivial update protocol, the update is >>end-to-end, encrypted, and only the host and the DNS provider see the >>data. > >> You've published a record in a public zone. It doesn't matter that the >> protocol you used to publish it is privacy-protecting, because the >> publication of the name immediately negated that. > > With delegation through an ISP-controlled hidden master, the ISP gets > a database of all the names published by all of its users. > > With an encrypted connection to a DNS provider, the ISP needs to troll all > of the DNS providers in order to build such a database. > >> I actually share your concern that what he's got written down right now >> is more complicated than it needs to be, and this is partly because it >> was originally motivated by his work at an ISP. > > Uh-huh. > > -- Juliusz > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
One way to automate this would be using mud. On Thu, Jul 19, 2018 at 9:28 AM, Stephen Farrell wrote: > > (with no hats...) > > On 19/07/18 10:42, Juliusz Chroboczek wrote: > > >> Also, think of the privacy implications if all of the services on the > >> homenet had to be discovered from a shared zone like dyndns.org. > > > Quite the opposite. In the trivial update protocol, the update is > > end-to-end, encrypted, and only the host and the DNS provider see the > > data. Every Homenet, every host, heck, even every application can use > > a different DNS provider, and each DNS provider only sees the data that > > was explicitly sent to it. > > I'm also a bit puzzled by how the subset of records to be > globally published relates to the set of records that are > to be internally visible. I guess this is not something > that we'd fully standardise, but there are privacy issues > here if too much gets published globally, so there may be > some protocol (change/tweak) required to make it possible > for implementers to distinguish which information ought be > globally visible, and which not. > > Cheers, > S. > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> I am not speaking about discovery within the Homenet. I am speaking about > exporting names into the global DNS, which is what Daniel's draft is > about. > Yes, but the problem is that you are treating this as if these are two > separate problems, but they are not. These are two completely different problems, with different default behaviours and different failure modes. The default behaviour for the local zone is that devices should be discoverable. The default behaviour for the public DNS is that a device should not be published unless it takes explicit action. It makes a lot of sense to have two different protocols, rather than essentially leaking a local zone into the ISP's DNS servers. > I'm not following your reasoning here -- why does the zone being tied to > the ISP imply that we must use a more complex protocol? > Doing this transaction over HTTP means another service that the ISP has > to operate, Not the ISP, a third-party DNS provider. That's the whole point. > and another service that the HNR has to connect to. Not the HNR, the end host. That's the whole point. And it's literally four lines of shell: while true; do wget --post-data 'name=gameserver.myhome.net=topsecret' \ https://dyndns.example.com sleep $((24 * 3600)) done > Quite the opposite. In the trivial update protocol, the update is > end-to-end, encrypted, and only the host and the DNS provider see the > data. > You've published a record in a public zone. It doesn't matter that the > protocol you used to publish it is privacy-protecting, because the > publication of the name immediately negated that. With delegation through an ISP-controlled hidden master, the ISP gets a database of all the names published by all of its users. With an encrypted connection to a DNS provider, the ISP needs to troll all of the DNS providers in order to build such a database. > I actually share your concern that what he's got written down right now > is more complicated than it needs to be, and this is partly because it > was originally motivated by his work at an ISP. Uh-huh. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
(with no hats...) On 19/07/18 10:42, Juliusz Chroboczek wrote: >> Also, think of the privacy implications if all of the services on the >> homenet had to be discovered from a shared zone like dyndns.org. > Quite the opposite. In the trivial update protocol, the update is > end-to-end, encrypted, and only the host and the DNS provider see the > data. Every Homenet, every host, heck, even every application can use > a different DNS provider, and each DNS provider only sees the data that > was explicitly sent to it. I'm also a bit puzzled by how the subset of records to be globally published relates to the set of records that are to be internally visible. I guess this is not something that we'd fully standardise, but there are privacy issues here if too much gets published globally, so there may be some protocol (change/tweak) required to make it possible for implementers to distinguish which information ought be globally visible, and which not. Cheers, S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
On Thu, Jul 19, 2018 at 5:42 AM, Juliusz Chroboczek wrote: > > In order for services to be discoverable on the homenet, they have to > > publish their contact info on the homenet. The protocol that everyone > > uses for this is DNSSD. This is how you find your printer when you want > > to print to it. Nobody uses the ad-hoc DynDNS protocol for this. > > I am not speaking about discovery within the Homenet. I am speaking about > exporting names into the global DNS, which is what Daniel's draft is about. > Yes, but the problem is that you are treating this as if these are two separate problems, but they are not. If we need devices to know how to do one thing, that's enough. We shouldn't demand that they know how to do two things that accomplish the same thing. So if we need service registration, we shouldn't also have a second method of publishing names, because that's additional work for the device manufacturer. > > The reverse mapping zone has to be delegated by the ISP, so we might as > > well do it in a prefix delegation transaction. > > I'm not following your reasoning here -- why does the zone being tied to > the ISP imply that we must use a more complex protocol? > Again, we are already doing DHCP PD to get the prefix from the ISP. The transaction is already happening. Sending our ZSK to the root along with the IP address of our public or hidden primary for the reverse zone isn't a lot of additional work. Doing this transaction over HTTP means another service that the ISP has to operate, and another service that the HNR has to connect to. So it's not a simplication—it's a complexification, even though the protocol itself is simple. > > Also, think of the privacy implications if all of the services on the > > homenet had to be discovered from a shared zone like dyndns.org. > > Quite the opposite. In the trivial update protocol, the update is > end-to-end, encrypted, and only the host and the DNS provider see the > data. Every Homenet, every host, heck, even every application can use > a different DNS provider, and each DNS provider only sees the data that > was explicitly sent to it. > You've published a record in a public zone. It doesn't matter that the protocol you used to publish it is privacy-protecting, because the publication of the name immediately negated that. In Daniel's protocol, the data goes from host to hidden primary to DNS > provider. The hidden primary is probably controlled by the ISP, which is > convenient if you happen to be a privacy-violating ISP. The hidden primary would be on an HNR, so unless the HNR is controlled by the ISP, the hidden primary isn't either. In principle, at least, the hidden primary should only be exposing names to the ISP that are intended to be exposed. The reason I was hassling Daniel about implementations at the mic is that I actually share your concern that what he's got written down right now is more complicated than it needs to be, and this is partly because it was originally motivated by his work at an ISP. Now that he isn't doing that, we have an opportunity to do a rethink about what is good and bad about the proposal, and I think we should take advantage of this opportunity. That said, DNS delegation and IXFR are well-understood technologies that are well-suited to the purpose we have here, so I think we should be careful when trying to simplify this to make sure that what is being proposed actually has that effect! ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> In order for services to be discoverable on the homenet, they have to > publish their contact info on the homenet. The protocol that everyone > uses for this is DNSSD. This is how you find your printer when you want > to print to it. Nobody uses the ad-hoc DynDNS protocol for this. I am not speaking about discovery within the Homenet. I am speaking about exporting names into the global DNS, which is what Daniel's draft is about. > It's certainly true that we could use an HTTPS-based protocol for setting up > delegations for the forward mapping zone. This makes a great deal of sense, Good. > The reverse mapping zone has to be delegated by the ISP, so we might as > well do it in a prefix delegation transaction. I'm not following your reasoning here -- why does the zone being tied to the ISP imply that we must use a more complex protocol? > So if you are advocating this second thing, that makes sense, and we should > definitely talk about whether it makes sense to do it this way. Let's. > Also, think of the privacy implications if all of the services on the > homenet had to be discovered from a shared zone like dyndns.org. Quite the opposite. In the trivial update protocol, the update is end-to-end, encrypted, and only the host and the DNS provider see the data. Every Homenet, every host, heck, even every application can use a different DNS provider, and each DNS provider only sees the data that was explicitly sent to it. In Daniel's protocol, the data goes from host to hidden primary to DNS provider. The hidden primary is probably controlled by the ISP, which is convenient if you happen to be a privacy-violating ISP. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
The trivial update protocol isn't a standard protocol, and doesn't do what we need it to do. In order for services to be discoverable on the homenet, they have to publish their contact info on the homenet. The protocol that everyone uses for this is DNSSD. This is how you find your printer when you want to print to it. Nobody uses the ad-hoc DynDNS protocol for this. What the DynDNS protocol does is to allow you to track the IP address of your home gateway using a single A record in someone else's zone (e.g., dyndns.org). It doesn't let you populate your own zone, and you can't do service discovery on the resultant DNS entry, because service discovery is a bit more complicated than that. It's certainly true that we could use an HTTPS-based protocol for setting up delegations for the forward mapping zone. This makes a great deal of sense, since the forward mapping zone shouldn't have to be tied to the ISP. The reverse mapping zone has to be delegated by the ISP, so we might as well do it in a prefix delegation transaction. So if you are advocating this second thing, that makes sense, and we should definitely talk about whether it makes sense to do it this way. If you are talking about the first thing, then maintaining a zone in the homenet is definitely a requirement. Also, think of the privacy implications if all of the services on the homenet had to be discovered from a shared zone like dyndns.org. On Wed, Jul 18, 2018 at 9:35 PM, Juliusz Chroboczek wrote: > > All of this can be done in the DNS without resorting to any other > protocol. > > Excellent. > > So what technical reasons are there to prefer the complexity of > draft...front-end-naming-delegation over a trivial update protocol, > whether encapsulated in HTTPS or DNS? > > -- Juliusz > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> All of this can be done in the DNS without resorting to any other protocol. Excellent. So what technical reasons are there to prefer the complexity of draft...front-end-naming-delegation over a trivial update protocol, whether encapsulated in HTTPS or DNS? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
All of this can be done in the DNS without resorting to any other protocol.
_dns-update._udp SRV is registered with IANA for finding where to send
UPDATE request to if the SOA MNAME or the NS’s are not reasonable.
UPDATEs can be secured with TSIG (shared secret) or SIG(0) (public key
cryptography). The later has the advantage that there isn’t a scaling
issue as the KEY record is stored in the zone.
If you want to experiment with this named has an update policy rule that
allows just such secured updates.
update-policy {
grant example.com name * KEY;
grant * self . [type list];
};
where example.com is a TSIG or KEY record used by the administrator
to install the KEY record for the node initially.
Garbage collection (GC) had never been defined by a DNS protocol but a simple
one would be to request a TYPE that can live a long side CNAME (like KEY
does) which has the type code to be removed and GC time. Server policy
could be to add this or the client could include the record in the UPDATE
request. Doing GC with a record like this would be trivial for a DNS server.
DNSSEC servers already do wall clock time based regeneration of RRSIGs using
the type covered and expiry fields of the RRSIG records. GC would use a
similar mechanism.
> On 19 Jul 2018, at 7:21 am, Juliusz Chroboczek wrote:
>
> Dear all,
>
> Since the 1990s, people have been putting their dynamically allocated IPv4
> addresses into global DNS by using a family of gratuitiously incompatible
> trivial protocols. The technique doesn't have an official name (let alone
> a specification), and is usually referred to as DDNS, DynDNS or Dynamic DNS.
>
> The basic idea is as follows:
>
> - the client is configured with its DynDNS provider;
> - whenever its public IP changes, the client makes an HTTP request to
>register the name directly with the provider.
>
> Usually, but not always, there's some form of garbage collection -- if the
> client fails to refresh its name within some timeframe, the entry is
> deleted. Security can be achieved either by using HTTPS with a plaintext
> password, or by using clear HTTP and a cryptographic challenge mechanism.
>
> This kind of protocol has a number of desirable features:
>
> - the client side can be implemented in roughly 4 lines of Python;
> - it's end-to-end, so no privacy issues (if using HTTPS);
> - it's end-to-end, so it doesn't depend on any local infrastructure;
> - it's end-to-end, so it can be used in a foreign network (e.g. you can
>use it to advertise the address of the game server you run on your
>laptop during IETF meetings).
>
> DynDNS has been widely deployed for 20 years or so, and would appear to
> solve the problem of name outsourcing quite nicely. What technical
> problem is draft-ietf-homenet-front-end-naming-delegation solving that is
> not adequately solved by a DynDNS-style solution?
>
> This is a question that I've been asking since July 2014:
>
> https://mailarchive.ietf.org/arch/msg/homenet/7JmkTCBSSMs5nnH3VWPj6JAL0cA
>
> and I still haven't received an answer I could understand.
>
> -- Juliusz
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
[homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
Dear all, Since the 1990s, people have been putting their dynamically allocated IPv4 addresses into global DNS by using a family of gratuitiously incompatible trivial protocols. The technique doesn't have an official name (let alone a specification), and is usually referred to as DDNS, DynDNS or Dynamic DNS. The basic idea is as follows: - the client is configured with its DynDNS provider; - whenever its public IP changes, the client makes an HTTP request to register the name directly with the provider. Usually, but not always, there's some form of garbage collection -- if the client fails to refresh its name within some timeframe, the entry is deleted. Security can be achieved either by using HTTPS with a plaintext password, or by using clear HTTP and a cryptographic challenge mechanism. This kind of protocol has a number of desirable features: - the client side can be implemented in roughly 4 lines of Python; - it's end-to-end, so no privacy issues (if using HTTPS); - it's end-to-end, so it doesn't depend on any local infrastructure; - it's end-to-end, so it can be used in a foreign network (e.g. you can use it to advertise the address of the game server you run on your laptop during IETF meetings). DynDNS has been widely deployed for 20 years or so, and would appear to solve the problem of name outsourcing quite nicely. What technical problem is draft-ietf-homenet-front-end-naming-delegation solving that is not adequately solved by a DynDNS-style solution? This is a question that I've been asking since July 2014: https://mailarchive.ietf.org/arch/msg/homenet/7JmkTCBSSMs5nnH3VWPj6JAL0cA and I still haven't received an answer I could understand. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
