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

Ted Lemon <> Mon, 23 July 2018 13:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C61B130E84 for <>; Mon, 23 Jul 2018 06:02:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x3bdlcgYjqmq for <>; Mon, 23 Jul 2018 06:02:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9EBDE130E6E for <>; Mon, 23 Jul 2018 06:02:00 -0700 (PDT)
Received: by with SMTP id z19-v6so447681ioh.4 for <>; Mon, 23 Jul 2018 06:02:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s/RtybE9rb5dlHQGWXZ6qfFqQi6K3DbYXU/PUtCAL90=; b=ofRazbax/BaS9vYF9aCLO90+hrZxOYJAhsYuMz3BhhOdzMk+IXxSWzFNYku0O70zW8 p98KEroQZ+tNW4rx4Pm/82QIr/HNI2HwDvxNLvlOqnx6JLjqfN5NUYxQ55yiHF2ZEooc POR+uOhEm7OXQRwRVuAUAD59OIznuF2bgJwgkmNtia8OivhxBrjee2ZQtBR+7N/dmDTS 8f0EIpjPBN0NwGJVxAp4ubUTnksOYoIpJJODIjFQsllRsHYQqCdUHSseq9aikhBlf8pS V1v6h9VXzk8odCDTQ5QzvEcqfz+K8VL1pl3UYfLycM7pdYbYSWrDo3pY1sYnp35G65EU on1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s/RtybE9rb5dlHQGWXZ6qfFqQi6K3DbYXU/PUtCAL90=; b=OlJ3A2z1CR22dC4rkwB9v6lg/P+sK66J7iLMiyNmO0K+EoFM1vy/5GrbSHR3rM0VD6 riNh49uzKKfS3gHYaIn0bYQ8GhG0uTlg4dp763KnFShyNbDiS8b3lV/SGk1Jvy1x0C7s n7DPQgrRgVEBj/XEkpB3VVW5sid/nzc3iKPSL5o0YKZpdeHuEb8wTe9Z4qBthXEEAaqo 3tpFomMeWD6do4A73O7wzNu2aKPgxNX745lYklRwlDSBx5+Rdk71fK6f8AF+avPuyF3H Irp5IqU+BG1l6MaO499vgp0Nj9cBSVOXBeTk0Bc0heyi77lUe2zfFv9lAvwMwEEh1Tq8 eSaw==
X-Gm-Message-State: AOUpUlFQgTiYJmgnhxJjKqimB5zTXt0JEZqHo3U+/iyww1zdNX4CrV07 AMfTgr2Si8UVBVlMWdagyMYYXDNZAqDZa2YWc+Zl/CSovTI=
X-Google-Smtp-Source: AAOMgpfYjPalLfaCdJZLqHh9jni1FzrPK/8SWhOcxWvfscCcHIU//6D2IsCgG0XAfyLLweBglYmw+PO+IXcrP2qdJ5k=
X-Received: by 2002:a6b:4c5:: with SMTP id 188-v6mr10403136ioe.32.1532350919760; Mon, 23 Jul 2018 06:01:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:b442:0:0:0:0:0 with HTTP; Mon, 23 Jul 2018 06:01:19 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Ted Lemon <>
Date: Mon, 23 Jul 2018 09:01:19 -0400
Message-ID: <>
To: Juliusz Chroboczek <>
Cc: Homenet <>
Content-Type: multipart/alternative; boundary="0000000000003e7a900571aa40ae"
Archived-At: <>
Subject: Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Jul 2018 13:02:09 -0000

Apparently my comment was clear as mud.   I meant this:

Having a public/private zone pair where the public zone is an image of the
private zone that is constructed following rules, the default rule being
"don't copy," seems very straightforward to me.   It's not clear to me in
what sense it's brittle.   Requiring each device to be configurable with a
way to update a name server Out There, and managing the set of devices that
are publishing their names, seems not merely brittle but also difficult to
operate.   To me, the difference between what you are proposing, Juliusz,
and what Daniel is proposing, is where the control point is.   For you, the
control point is the device.   For Daniel, the control point is the
resolver.   Each of these has different properties in terms of
manageability.   Depending on how each is used, your model may be easier or

What I have set up in my home assumes the mud model, although that's not
actually implemented yet, and even the topology is a work in progress
because I haven't gone back and fixed everything yet.   The model is that
all of my IoT devices are on their own network, which is firewalled from
the rest of my network and has no external connectivity by default.   If a
device needs external access, it gets access to what mud says it needs
access to (e.g., it can download its firmware updates, but not log in to
facebook).   If it wants to be externally reachable, its mud description
would say so, and would say what would be allowed to reach in and touch it.

This model would work with non-IoT devices as well—if they don't have mud
descriptions, then by default they can reach out to touch anything, but
nothing is allowed to reach in to touch them, and their names are not

What's good about this model is that things can happen completely
automatically.   The end user is not asked to understand security models,
and need take no action other than enrolling devices on the network, which
I think is unavoidable.   The only problem with this is that there's no way
to automatically corral IoT devices to the IoT network.

That said, what I've described here is out of scope for the current
discussion, other than with respect to naming.

On Thu, Jul 19, 2018 at 4:38 PM, Juliusz Chroboczek <> wrote:

> > One way to automate this would be using mud.
> A bright light shines from the heavens, bathing you in its warm glow.  An
> enormous, white temple stands to the north, taking most of your view.
> In order to enter the Temple of Homenet Naming, you must travel up the
> large staircase that stands in front of you.
> Exits: North, West, East, South.
> (Perhaps you had something else in mind when you said MUD?)