Subject: [homenet] draft-ietf-homenet-front-end-naming-delegation

From: Daniel Migault <[email-masked]>
Date: Wed, 21 Nov 2018 11:32:00 -0500

Hi,

I am planning to update the front end naming delegation draft [1] in the
next weeks. Before revisiting the draft, I am collecting comments that need
to be addressed.

The draft has been waiting the naming architecture draft become more
advanced. I believe this now achieved.

The main comments I received during the sessions is that the document is
too long. The current size results from addressing requests for more
details. I will reduce the document size and place some of the section in
the appendix. It would be helpful for me to indicate what you believe
should be placed in the appendix as opposed as to the main document or any
thoughts you have.

I also believe that the position toward the naming architecture should be
clarified.

If there are any other concerns, please let me know!

Yours,
Daniel

[1]
https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 21 Nov 2018 19:31:47 +0100

Dear Daniel,

> I am planning to update the front end naming delegation draft [1] in the next
> weeks. Before revisiting the draft, I am collecting comments that need to be
> addressed. 

After your talk at IETF-102, I asked what is the purpose of this rather
complex protocol, and why it is preferable to a trivial end-to-end
protocol.  As instructed during the meeting, I carried my question to the
list, in a message dated 18 July 2018.

A number of people participated in the ensuing discussion, however, none
provided a definitive answer to my question.  I may have missed something,
but as far as I know you did not participate in this discussion.

Daniel, please explain why proxying through a hidden master is needed, and
what problem this protocol solves that could not be solved with a trivial
end-to-end protocol.

Thanks for your understanding,

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Nov 2018 13:49:29 -0500

What do you mean by a "trivial end to end protocol," Juliusz?

On Wed, Nov 21, 2018 at 1:32 PM Juliusz Chroboczek <[email-masked]> wrote:

> next
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 21 Nov 2018 15:06:38 -0500

Hi Juliusz,

If I understand correctly the question is why do we have a Homenet Naming
Authority responsible to outsource the Homenet Zone to  the Public
Authoritative Servers ( Front End architecture) instead of having each
device updating their data directly to the  Public Authoritative Servers
(End to end architecture) ?

If I understand correctly the proposed end-to-end architecture here are
some potential elements that might provide some (partial) responses. I
would be interested to see what advantage you see wit the end-to-end
architecture.

* The End to end architecture does not seem to be scalable in term of
management

The architecture where all devices directly update their data to the Public
Authoritative Servers requires these devices being configured appropriately
with authentication credentials, the Public Authoritative Servers, the
Homenet Domain, the policies that defines what IP address needs to be
published, as well as if the device domain name is expected to be published
on the internet. While we can assume that such configuration will not be
provided if the device is not expected to publish its name, it also means
that the network admin needs to update all devices when its publishing
policy changes or when any configuration is changed. This makes the
management of the homenet very hard and unsecure as authentication
credentials are spread across all devices. With such credentials almost
public, Public Servers may be exposed to DDoS.

With the architecture proposed, all this information is centralized to the
HNA and easier to secure.

* End-to-end Architecture does not provide internal and external views.

Devices with local IP addresses are not expected to be published on the
Internet. In addition, some devices are simply not expected to become
accessible from the Internet but are expected to be accessible only from
within the homenet. It seems that the end to end architecture could hardly
provide an internal view and a public view. In addition, it hardly prevents
leaks. A device that used to publish a global IP address that got a local
IP address may publish his local IP address.  As a result the end-to-end
architecture is likely to leak privacy.
In addition its design imply that everything is published to the Internet,
and the naming within the homenet hardly work without connectivity.

The proposed architecture takes the opposite idea. Instead of making
everything public, it makes everything internal and let the admin define
what needs to be outsourced. Outsourcing is firstly intended to address
DDoS attacks but does not needs to be always on.

* End-to-end architecture is hard to get adopted.

DNS update seems the only standard way to update DNS data. Many DNS hoster
uses there own API, and it seems unrealistic that all devices will have all
these different APIs and choose the appropriated one. This however seems
realistic that a central equipment handles this interface.

Currently most homenet architectures have a CPE that assigns ip addresses
to devices. The front end architecture enables to leverage from the
existing deployments while the end-to-end architecture does not seem to
consider the legacy deployment.

Yours,
Daniel

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 21 Nov 2018 23:03:21 +0100

Thanks for your reply, Daniel.

> Authority responsible to outsource the Homenet Zone to the Public Authoritative
> Servers ( Front End architecture) instead of having each device updating their
> data directly to the Public Authoritative Servers (End to end architecture) ?

Yes, that's a good summary.

> * The End to end architecture does not seem to be scalable in term of

I don't think that this argument is relevant to Homenet.

I'd expect most devices in a home network to have no externally visible
name.  The number of externally named devices is 0 for the typical user,
and just 3 for a rather extreme geek (NAS, boom box, and game server).

I'm sure we can agree that the end-to-end architecture scales well beyond
3 devices.

> with authentication credentials,

This is also the case with the proxying architecture: devices are by
default not announced to the global DNS, and per-device configuration is
needed for devices that want to be named globally.

> With the architecture proposed, all this information is centralized to the HNA
> and easier to secure.

The devices that need to have globally visible names are the secure ones
(the NAS, the music collection, the game server).  The insecure devices
are exactly the ones that should not have a global name.

Or are you assuming that I'll want to publish each lightbulb in the global DNS?

> * End-to-end Architecture does not provide internal and external views.

I don't see how.  The end-to-end protocol only publishes names of devices
that have been explicitly configured to do so, just like the proxying
algorithm.

> In addition its design imply that everything is published to the
> Internet, and the naming within the homenet hardly work without
> connectivity.

I don't see how.  Homenet-local naming is not impacted by how we publish
externelly-visible names.

> DNS update seems the only standard way to update DNS data.

There's no reason why DNS updates couldn't happen end-to-end.  I am not
discussing the exact encoding here, what I'm discussing is the need for
a proxy.

> Currently most homenet architectures have a CPE that assigns ip addresses to
> devices.

This statement is in clear contradiction with the Homenet architecture.

-- Juliusz