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

Daniel Migault <daniel.migault@ericsson.com> Wed, 21 November 2018 20:06 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A99126C01 for <homenet@ietfa.amsl.com>; Wed, 21 Nov 2018 12:06:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yblWd63pPD7y for <homenet@ietfa.amsl.com>; Wed, 21 Nov 2018 12:06:53 -0800 (PST)
Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94B91286E3 for <homenet@ietf.org>; Wed, 21 Nov 2018 12:06:52 -0800 (PST)
Received: by mail-lj1-f180.google.com with SMTP id v1-v6so5972629ljd.0 for <homenet@ietf.org>; Wed, 21 Nov 2018 12:06:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hVP0FD10kqFod7cuXnKP3xQ0cLMfRbkFwL0zIpR5fJU=; b=JwTzQoC+P5bjXUUImyvJqDgPTzlh+OzeTc5+tje/tN92mmEADqbjS9mtn+3XrWuyV4 gkrUAbSaLcPq+YZLl4sKCPf5nB7IUE2SDKt6Vlj4p2Ffj8VRfCh+P59LP7NgRx3eNjEJ /fR83gvlLsuZvnSg4GEU9jfQEWr4eVUWOYRg+BlGpCVtxiUGcnfJXh+qvnzCXt0LeweM YeSnF9wMXqdAQPgk8Kij7kgrYUA4S1vLtuEQrgqBE46z7BoOzJZM4WU7JiYoK0BbpY1R stM7VqY/8XiYCuVTpayJjXLUnSW1ttXtm6J7BIUvLmxCeTfDhjkPCPdmFF3GrYG5b+3e Jfzg==
X-Gm-Message-State: AA+aEWbtLEWmqKqJGVBRVo7pz/GvFWsblMBLDQ7P55NP+EfU7DXpVqva X443efXqIxFrs5TROE7mqaEaw/VAAjqoYMHeCXym7Q==
X-Google-Smtp-Source: AFSGD/WlOG4RZwr0Ag2uh+Cniz+aC+ygtG/sNKloJf1KApSrnCMSTuqp0NlGZwwOEVaemsiMAioeMjZQpkx7eDmDVwc=
X-Received: by 2002:a2e:9819:: with SMTP id a25-v6mr5446348ljj.6.1542830810638; Wed, 21 Nov 2018 12:06:50 -0800 (PST)
MIME-Version: 1.0
References: <CADZyTkmZTrPkOHusvVjcAqBxOCr+=0Dk68zmYODZq_cYgGXt1A@mail.gmail.com> <87muq2qo30.wl-jch@irif.fr>
In-Reply-To: <87muq2qo30.wl-jch@irif.fr>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Wed, 21 Nov 2018 15:06:38 -0500
Message-ID: <CADZyTkntEHNbQQ91=gKmaSaGgN88gpaojDnCykMZca29g2ytvw@mail.gmail.com>
To: Juliusz Chroboczek <jch@irif.fr>
Cc: homenet <homenet@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006ab077057b324acc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/NCbU4XHh0tk8HAowH5rcGEB3fOo>
Subject: Re: [homenet] draft-ietf-homenet-front-end-naming-delegation
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Nov 2018 20:06:55 -0000

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 <jch@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
>