Re: [homenet] after the meeting comments on draft-ietf-homenet-front-end-naming-delegation-07

Daniel Migault <daniel.migault@ericsson.com> Tue, 24 July 2018 21:14 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 C2856130F3F for <homenet@ietfa.amsl.com>; Tue, 24 Jul 2018 14:14:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 f92_MY5jhF1Q for <homenet@ietfa.amsl.com>; Tue, 24 Jul 2018 14:14:33 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 C62A7130F34 for <homenet@ietf.org>; Tue, 24 Jul 2018 14:14:32 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id n96-v6so3963261lfi.1 for <homenet@ietf.org>; Tue, 24 Jul 2018 14:14:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XPG3sN1T/V1m6lgRTb4DgK7kS0ETSoDYlzRFhuxNZDk=; b=ZggBNLTGsG9T9E9dIG/SGGOyum83++aE9dUvXZ8Utrw2bYkXvQIBAqP4sWzwoXniDl VTo3cXE5V5pMOXr3uxRoUMMG7tT4NcOqG4qjlyDCmLALzvYMmJcYcuQ2dZHgiz1M2omp oa9o6CGjLHsdEPiUAygmYG5hN8J0wbMAQas+GOHIRzYnrYyuLHekjXqh+FPdgb3AyQIH KbZ869f3N6BKkuBPmYfK5Wu9brRftczOARgkD1k/ob08yy0+07/iDSDNxhwOYSqo0wMf HycAarKd9mOWn9lImy10JOaajZ84LnquhoOXv0LhpawPyvUyILmT54N9wi3MvyLxyoa7 mZvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XPG3sN1T/V1m6lgRTb4DgK7kS0ETSoDYlzRFhuxNZDk=; b=R3NitjqWRpwj5Y5N9k42KVw7p5giYWKU+AprY/Ny9o+76m5ecpb6B1OuOdgANTApmf XHOw06VCqo97LeHlN7ik3ZF2VShXfPnLUzequYXdyCHDNYjmKQcFIpafspqji5h3u6E+ RJ1phA9VrBww/uNvRi5mCRSpRc++nUGqHiT5ZNwHVMGUl0+U0r6EiWB/lokETCbstXBr 9IANG5txAoj3Bi1nfz4j3gRu0G8Tkknb2WJJBPd1owh3BAj3sNIhJdWLV5dJfyWsXVpd dw3jPw061xT41Nd1KxYuC2AE2Y86dvLf78ScOyK9jFcmnjeXkDgMSz15HJhbNNoJiB/a a2ew==
X-Gm-Message-State: AOUpUlH1IhokbZdnU0FGcqWI75ZAnWXPPhSdOaWbQT865Hb7iQfsWfIu TFensRZS3aCO8+4Ny2/ijd1diGn7HSUvj2D6vzA=
X-Google-Smtp-Source: AAOMgpfOSt2qPRaxgF/LD6kHS7u8e4fiP3jwaCZemzlUJRN7bmEpR7I3z9FuC4/v//ZJ/b8KdCEj9zqiLVwHPB3zBIE=
X-Received: by 2002:a19:95c9:: with SMTP id x192-v6mr10842831lfd.37.1532466870995; Tue, 24 Jul 2018 14:14:30 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 2002:a2e:320c:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 14:14:30 -0700 (PDT)
In-Reply-To: <CAPt1N1mgJ0xeDqYk7uKtTt6sUGZTi2t78dbD=gR-20vs8oQE=A@mail.gmail.com>
References: <164cd21de61.cf472e3065599.3014191005552687277@ovsienko.info> <CAPt1N1mgJ0xeDqYk7uKtTt6sUGZTi2t78dbD=gR-20vs8oQE=A@mail.gmail.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Tue, 24 Jul 2018 17:14:30 -0400
X-Google-Sender-Auth: 4M8EkOQhU7fi7ZwZR4s4X0SfW0o
Message-ID: <CADZyTkkvqknc4A0GpJTLzMqMokmW=xxqmb+BE_2-R4-4gPmNKg@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: Denis Ovsienko <denis@ovsienko.info>, homenet <homenet@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000079d0880571c53f44"
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/ZOodqyPTlBqkdZMq_oF4GPb7FX4>
Subject: Re: [homenet] after the meeting comments on draft-ietf-homenet-front-end-naming-delegation-07
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 24 Jul 2018 21:14:36 -0000

Hi Denis,

Thanks for the feed back! The big read arrow symbolized the synchronization
between the zone hosted on your HNA and the DNS Public server on the
outsourcing infrastructure. This could be your ISP or any third party. One
of the motivation to outsource was to prevent DDoS attack on the HNA, so as
mention Ted, if your ISP is as reliable as your HNA.... you may use a third
party to host your zone. However, the HNA hosts the Hidden primary and is
expected to host the most up-to date content. When you switch from one ISP
to another, these ISP are hosting secondary servers and your hidden primary
are expected to be able to synchronize with these secondaries. As a result
the zone published on the Internet is expected to remain synchronized. The
problem by switching from one outsourcing infrastructure to the other, is
that information stored in cache resolver (NS) may not be up-to-date for
TTL seconds. As mentioned Ted, we expect that the hosting infrastructure is
able to host relatively safely.

I believe this concern might also be relevant to the dhcp option draft
where we explicitly had the discussion of an ISP providing the service. In
this draft the DNS Zone Template is a template that is expected to be
provisioned by the HNA. In other words, the template is not expected to
contain all elements. The template is mostly useful when the HNA is
booting. As a result, it is likely that there are very little changes over
time and remain the same over the time you switch from one ISP to the
other. If not up-to-date, the HNA may also update the template.

Yours,
Daniel



On Tue, Jul 24, 2018 at 12:35 PM, Ted Lemon <mellon@fugue.com> wrote:

> My personal feeling on this is that the off-site backup zone is a service
> that could be provided by an ISP, could be provided by someone else, or
> could just be something that a sufficiently geeky user sets up for
> themself.   If an ISP connection is as flaky as you describe, I would think
> that they would be a poor candidate for offering this service, although as
> long as it is reachable through ISP B, and is updated accurately, it should
> be fine.   If your point is that the homenet should notice if it can't
> maintain contact with the off-site backup server, I think that's a good
> point.
>
> On Tue, Jul 24, 2018 at 12:31 PM, Denis Ovsienko <denis@ovsienko.info>
> wrote:
>
>> Hello group.
>>
>> What I was trying to say at the WG meeting was the following. Looking at
>> the slide with the red arrow between a DNS server in the home network and a
>> DNS server somewhere on the Internet, the following scenario immediately
>> came to my mind.
>>
>> 1. A home network is connected to the Internet through an ISP A.
>> Everything is synchronous and works.
>> 2. The link to ISP A fails.
>> 3. For the next month the home network remains half time disconnected and
>> half time connected through ISP B. Regardless of the Internet reachability,
>> devices come and go, and the network tries to update its zone.
>> 4. The link to ISP A is restored and works for the next three months.
>> 5. The user occasionally connects to ISP B in parallel, as a matter of
>> habit.
>> 6. Go to 2.
>>
>> Now, given the suggestion that the ISP maintains the zone, it would make
>> sense to think what happens when the ISP's copy is no longer updated and
>> the home network copy has changed. I have briefly looked through the I-D
>> and have not found anything that would explicitly make sure that the zone
>> cannot go split-brain. And if it goes split-brain, will it necessarily
>> synchronize afterwards with no human intervention? Maybe those provisions
>> are there, but I did not see them, in that case please disregard the
>> comment.
>>
>> Feel free to use this input to improve the document, if it gives you any
>> new ideas.
>>
>> --
>>     Denis Ovsienko
>>
>>
>> _______________________________________________
>> 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
>
>