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 On Wed, Nov 21, 2018 at 1:32 PM Juliusz Chroboczek <j...@irif.fr> wrote: > 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 > > _______________________________________________ > 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