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

[Daniel Migault <[e-mail]>]

Hi

Please see my comments inline.

>
>
> On Sat, Jul 5, 2014 at 12:12 AM, Juliusz Chroboczek <
> [e-mail]> wrote:
>
>> > The main idea is that the CPE builds the zone for the whole home
>> network.
>>
>> Thanks for the clarification.
>>
>> Daniel, perhaps I'm still misunderstanding something -- but I'm afraid
>> that
>> right now I'm strongly opposed to this protocol.  I hold no opinion yet on
>> whether proxying is necessary (although I hope it isn't), but I am
>> strongly
>> opposed to binding the DNS proxy role with the CPE at the protocol level.
>> (This does not mean that the DNS proxy cannot be colocated with the CPE,
>> only that I find a protocol that mandates this kind of colocation
>> unacceptable.)
>>
>
I do not think our architecture is bound to the CPE. In the architecture
document we mention that the CPE is the most likely to host the DNS zone
for the home network. However, I agree it can be any other node. We do not
either mandate any collocation of functions. If you could point specific
sections, that would help to clarify the next versions.

Similarly, I do not recall using the term proxy in one or the other draft,
and I do not see what could be considered as a proxy. More specifically,
suppose you have a authoritative DNS server in your homenet work. In the
draft we said a CPE will most likely handle this function. This server MAY
NOT want to respond for queries that are coming from outside the home
network. In this case, This server outsources the authoritative server for
queries coming from the Internet to a third party. DNS queries for the
Domain name of the home network will be answered by the "CPE" when the
query comes form the home network and by the "third party" when the query
comes from outside the home network.

>
>
>>  > 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.
>>
>> Oh, nothing that geeky.  I copy my vacation photographs onto my NAS.
>> I click the "share over the Internet" button on the NAS's web interface.
>> The NAS performs DynDNS registration, I get a link that I can copy-paste
>> into an e-mail to my mom: "Mom, the vacation photographs are on
>> http://www.user-fe83-paris-13.dyndns.example.com:8080/photos, the
>> password
>> is 1234."  I've avoided putting my private photographs on Google's
>> servers -- and we're changing the world.
>>
>> I click on the "share over the internet" button on my stereo's web
>> interface.  The stereo performs DynDNS registration, I get a link that
>> I can copy-paste.  "Daniel, the song you found so funny at my place last
>> night night is on
>> http://www.user-fe83-paris-13.dyndns.example.com/funny-music,
>> the password is 1234".  I've avoided sending 20MB of Ukrainian R'n'B over
>> SMTP -- and we're changing the world.
>>
>> I'm at the train station.  There's a strike on.  I'm playing Civilisation
>> on my laptop in an internet cafe.  I click the "Invite over the Internet"
>> button.  Civilisation performs DynDNS registration, I get a link which
>> I can copy-paste.  "Daniel, I'm bored, join me for a game of Civilisation,
>> link is civ://www.user-fe83-paris-13.dyndns.example.com, password is
>> 1234", and now I can wholeheartedly support the cheminot's strike -- we're
>> changing the world again.
>>
>
To me the last use case you provide is not in the scope of home network
unless you are unsing a VPN. The two first examples seems to be related to
WEBDAV. On a DNS point of view, it looks to me that they involve only a DNS
registration. Suppose there is not NAT. Your NAS requests /discovers its IP
address and then registers its IP address to the registrar. This means that
at one time you have configured your NAS with the appropriated credentials
to update your zone in the registrar. In the architecture we propose,
things may be as follows: the NAS only needs a hostname: myserver for
example. You plug the NAS in your home network, it announces its name via
DHCP. The DHCP transmit the information to the entity that manages the DNS
zone, which then outsource the zone to the registrar. You NAS does not need
to be configured to update the zone at the registrar.

>
>
> >     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.
>>
>> Sure.  Just like you, I'm expecting dynamic updates.  But I don't expect
>> dynamic updates to be dependent on my CPE, which is buggy (it was provided
>> by the major competitor of your employer) and isn't available at the
>> internet cafe.
>
>
To me the Internet cafe is not the home network. The issue of buggy CPE is
an important one. The goal of the two drafts is to provide guidance to
avoid such issues... and providing no guidances or leaving things as there
are now won't solve these issues ;-)

>
>
>
>> >     2) It is not scalable in term of software installation: every
>> registrar
>> > have its own API for configuring the zone.
>>
>> Then why not standardise a registration API?
>>
>
I am not sure there is a real interest in doing so, nor that it is
feasible. The important thing is that you have the APIs of your registrar
and that you do not have to set it in all devices. Some devices like sensor
will never be able to embed these APIs anyway.


>
>>
>  > 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.
>>
> If you really believe that proxying is necessary (and I'd like actual
>> figures to support this claim -- how many devices do you have in your home
>> that cannot afford the cost of one registration every few hours?), then
>> there's nothing preventing a DNS proxy from using the standardised
>> registration protocol on behalf of its clients.  Then clients can choose
>> whether to go through the proxy, and users can choose whether use the
>> ISP-provided proxy (co-located with the CPE) or a third-party proxy that
>> happens to work.
>>
>
It is not clear what you have in mind with proxy, so I might misunderstand
your point here. It seems to me that you do not want the architecture to
prevent a host to register on its own. YES this is the case. Suppose your
Registered Domain Name for your home network is myhome.net. With our
architecture, as mentioned above, your NAS may be automatically registered
as myserver.myhome.net. If you want your server to be registered as
myserver.org, nothing prevents you from doing so. You may have two names
for the server, or a single one. In other words the proposed architecture
is compliant with existing deployment.

>
>
>> >     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.
>>
>> That's what we have HNCP for -- for distributing random data to all
>> devices.
>>
>
I am sure I misunderstood your point, but I understand you suggest using
HNCP to distribute credentials (private keys, login password). Am I
correct?


>> >     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.
>>
>> I've got 100 devices.  I renumber.  Each device sends 500 bytes of
>> registration data.  My monthly Internet bill has just increased by 50 kB.
>>
>
That is still more than 0  ;-)

> >     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.
>>
>> But my nodes are still running mDNS/zeroconf, right?  Or are you
>> deprecating
>> that?
>>
>
Interchanging mDNS and DNS for local / global scope is not an easy thing.
These protocols are different protocols and I do not think it is a good
idea to impose all devices to have both, then homenet may have different
subnetworks, mDNS can use UTF-8...  There are a lot of ongoing work in
dnssd.

By the way, I am not deprecating the use of mDNS at all it is simply
orthogonal.

>
>
>
>  -- Juliusz
>>
>
>
>
> --
> Daniel Migault
> Orange Labs -- Security
> [phone]
>



-- 
Daniel Migault
Orange Labs -- Security
[phone]