Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt

[Daniel Migault <[e-mail]>]

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 <
[e-mail]> 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
[phone]


On Thu, Jul 3, 2014 at 2:14 PM, Juliusz Chroboczek <
[e-mail]> 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
[phone]