Hi Juliusz, If I understand correctly your point your point is not about the DHCP Options, but about the architecture we defined for outsourcing the DNS Homenet Zone. I have just submitted an update of the description of the architecture in draft-mglt-homenet-front-end-naming-delegation-04.txt [1].
The main idea is that the CPE builds the zone for the whole home network. Then it outsources the zone on a server that handles the authoritative naming service on the Internet. The reason for outsourcing is that CPE have not been designed to host the authoritative service on the Internet and thus may be exposed to resource exhaustion. I am rephrasing your use case to make sure we have the same in mind. Please clarify if we do not agree on the use case. You consider is a web server in the home network, that you want to be reachable from the Internet. In order to do that you buy a specific domain name www.homenet.com. The domain is hosted on a Public Authoritative Server, you edit the zone, add the IP address of your server. Then, you can do that manually every time your IP changed or use a specific software that your registrar recommend you. To me, the drawbacks of this architecture are: 1) It is not scalable in term of configuration: if you have a single server, you can edit the zone. If you have 100 devices (which is not much) you will not be able to do it especially if you IP prefix changes every day. 2) It is not scalable in term of software installation: every registrar have its own API for configuring the zone. If you want to be able to do so, devices need to ba familiar with all APIs. Furthermore, if you suppose all registrar agree to have a unique way to do so, -- suppose nsupdate -- all devices will have to implement this protocol. For most devices this may be not a problem, however, for all devices like sensors having to perform nsupdate every day, may impact their battery life time for nothing. 3) It is not automatic and flexible: A new device that is in your network cannot have a name, as an admin needs to register its name in the zone myhomenet.com, or provide the credential for it to all new devices. 4) It is not scalable in term of zone management and bandwidth: Suppose you have n devices in the home network and a renumbering occurs. All these n devices will contact the Public Authoritative Server that may be miles away from your home network. The Authoritative Server will have to deal with n nsupdate transaction instead of one. 5) it exposes your homenet to IP disruption. Suppose your ISP has a connectivity issue, even a node in your home network will not be able to contact your web server as the DNS(SEC) resolution is not possible. In contrast, the architecture we describe in [1] : 1) is scalable in term of configuration: The only device that you may need to configure is your CPE. In the worst case it is done once for all. 2) is scalable in term of software installation: Only the CPE needs to be compliant with the registrar API, other devices do not need any kind of credentials, or other APIs. 3) It is automatic and flexible: as a new node is attached, it advertise its name in a DHCP query and the CPE takes in charge the binding. 4) it is scalable in term of zone management and bandwidth: registration is performed by the CPE, that is one of the first hops. Then the CPE updates once the zone to the Public Authoritative Server. This can be done with nsupdate, but we recommend master / slave synchronization. 5) It preserves the home network from IP disruption. If you d not have any connectivity on the Internet, as the authoritative naming service is provided by the CPE for the home network, nodes within the home network can still communicate. BR, Daniel [1] http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-04.txt On Thu, Jul 3, 2014 at 2:14 PM, Juliusz Chroboczek < j...@pps.univ-paris-diderot.fr> wrote: > Thanks for your answer, Daniel. > > > If I understand it properly, the use case you consider: 1) you set up > > a web server in your homenet, 2) you want it to be accessed from the > > outside so you register your domain name and register the IP address to > > the zone. Note that In this case, the Authoritative Naming service is > > outsourced to a third party which is what we want to achieve to. > > No, I think that I'm speaking of the same use case as your draft. (I'm > not sure, since your draft takes the use case for granted -- I'm probably > missing some background here, sorry for not being more attentive > previously.) > > I've got a device that wants to be advertised in the global DNS (a web > server is the obvious example, but it doesn't matter). Your draft > suggests (I think) that the device should speak to the CPE which will take > care of the interaction with the public DNS (arrow 6 in Figure 1 is > missing, by the way). I'd like to understand why the device needs to go > through the middleman rather than speaking directly to the authoritative > DNS server. > > My family was poor but honest, Daniel, and NATed addresses were all we > could afford. Notwithstanding our difficult conditions, my parents took > a lot of care to bring me up to believe that end-to-end is always better > than proxying. Since you're advocating proxying, I'd like to understand > why you think it is necessary. What is more, I'd like to understand why > you require that the proxy be co-located with the CPE. (It could > certainly be implemented on the CPE, but I don't understand why the > protocol requires that.) > > You give some good reasons below, and I think they should be included in > the draft: > > > - Ease the naming of device of various nature. > > Please explain. > > > - CPE remains in the homenet and may be easier to be authenticated > > than all different devices. > > Good point. > > > - CPE presents a centralized point for end user interactions > > I'm not convinced about that, the authoritative DNS master seems like the > natural place for end-user interactions. (Note that this does not prevent > the CPE's web interface from implementing some sort of proxy to the DNS > master's interface.) > > > - CPE are "powerful enough" to handle complex policies... > > Everything is powerful enough nowadays. My abacus has a four-core chip. > > > - CPE can integrate multiple protocols to publish a zone. Suppose > mDNS is > > used by a node, than registration of its IP address and name cannot be > > perfomed on a public authoritative server cannot be performed using mDNS. > > I strongly disagree. I don't want mDNS->DNS proxying. Registering in the > global DNS is something that should be under user control, while mDNS > is something that happens automatically (for better or worse). > > -- Juliusz > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 On Thu, Jul 3, 2014 at 2:14 PM, Juliusz Chroboczek < j...@pps.univ-paris-diderot.fr> wrote: > Thanks for your answer, Daniel. > > > If I understand it properly, the use case you consider: 1) you set up > > a web server in your homenet, 2) you want it to be accessed from the > > outside so you register your domain name and register the IP address to > > the zone. Note that In this case, the Authoritative Naming service is > > outsourced to a third party which is what we want to achieve to. > > No, I think that I'm speaking of the same use case as your draft. (I'm > not sure, since your draft takes the use case for granted -- I'm probably > missing some background here, sorry for not being more attentive > previously.) > > I've got a device that wants to be advertised in the global DNS (a web > server is the obvious example, but it doesn't matter). Your draft > suggests (I think) that the device should speak to the CPE which will take > care of the interaction with the public DNS (arrow 6 in Figure 1 is > missing, by the way). I'd like to understand why the device needs to go > through the middleman rather than speaking directly to the authoritative > DNS server. > > My family was poor but honest, Daniel, and NATed addresses were all we > could afford. Notwithstanding our difficult conditions, my parents took > a lot of care to bring me up to believe that end-to-end is always better > than proxying. Since you're advocating proxying, I'd like to understand > why you think it is necessary. What is more, I'd like to understand why > you require that the proxy be co-located with the CPE. (It could > certainly be implemented on the CPE, but I don't understand why the > protocol requires that.) > > You give some good reasons below, and I think they should be included in > the draft: > > > - Ease the naming of device of various nature. > > Please explain. > > > - CPE remains in the homenet and may be easier to be authenticated > > than all different devices. > > Good point. > > > - CPE presents a centralized point for end user interactions > > I'm not convinced about that, the authoritative DNS master seems like the > natural place for end-user interactions. (Note that this does not prevent > the CPE's web interface from implementing some sort of proxy to the DNS > master's interface.) > > > - CPE are "powerful enough" to handle complex policies... > > Everything is powerful enough nowadays. My abacus has a four-core chip. > > > - CPE can integrate multiple protocols to publish a zone. Suppose > mDNS is > > used by a node, than registration of its IP address and name cannot be > > perfomed on a public authoritative server cannot be performed using mDNS. > > I strongly disagree. I don't want mDNS->DNS proxying. Registering in the > global DNS is something that should be under user control, while mDNS > is something that happens automatically (for better or worse). > > -- Juliusz > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet