Re: [homenet] homenet: what now? ... next?

Juliusz Chroboczek <> Fri, 08 March 2019 12:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 086BD1279A9 for <>; Fri, 8 Mar 2019 04:49:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d2RGzD5_gTOM for <>; Fri, 8 Mar 2019 04:49:02 -0800 (PST)
Received: from ( [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9EDA51279A1 for <>; Fri, 8 Mar 2019 04:49:01 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4/relay1/82085) with ESMTP id x28Cmp81031905; Fri, 8 Mar 2019 13:48:51 +0100
Received: from (localhost []) by (Postfix) with ESMTP id C83373EF1C; Fri, 8 Mar 2019 13:49:00 +0100 (CET)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by ( []) (amavisd-new, port 10023) with ESMTP id w-ojLnsHIf21; Fri, 8 Mar 2019 13:48:58 +0100 (CET)
Received: from (unknown []) (Authenticated sender: jch) by (Postfix) with ESMTPSA id 121C23EF17; Fri, 8 Mar 2019 13:48:55 +0100 (CET)
Date: Fri, 08 Mar 2019 13:48:50 +0100
Message-ID: <>
From: Juliusz Chroboczek <>
To: Stephen Farrell <>
Cc: "" <>
In-Reply-To: <>
References: <>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 ( []); Fri, 08 Mar 2019 13:48:51 +0100 (CET)
X-Miltered: at korolev with ID 5C8264B3.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5C8264B3.000 from<>
X-j-chkmail-Score: MSGID : 5C8264B3.000 on : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <>
Subject: Re: [homenet] homenet: what now? ... next?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Mar 2019 12:49:05 -0000

Hi Stephen,

Sorry if I'm repeating myself -- I've already expressed the opinions
below, both at the mike and on the list.

> (a) work on simple naming

I think that this work should be stalled until we have an implementation
to play with and make some in vivo experiments.  (Experience shows that
the best way to break a protocol is to give an implementation to Dave.)

> (b) the drafts on handling names with help from your ISP.

I fear that these drafts are a bad case of complexity for the sake of
complexity (or perhaps a case of involving the ISP for the sake of
involving the ISP).  I still haven't seen a compelling argument that they
do solve a problem that a trivial end-to-end protocol wouldn't solve.
Back in July 2018, I wrote the following:

    This is a question that I've been asking since July 2014, and I still
    haven't received an answer I could understand.

Please see the thread starting on 18 July 2018:

> (We also have a chartered work item [4] on security that has seen no
> progress but you can comment on that as item (c) if you like;-)

Some pointers for the rare people who don't spend most of their leisure
time reading Internet-Drafts:

  - HNCP is based on DNCP, which includes a security mechanism designed to
    provide authenticity, integrity and confidentiality of the HNCP data:

        RFC 7525 Section 8

    I believe that this is implemented in hnetd.  (Yeah, Markus and
    Stephen did some remarkable work.)

  - Babel has two security mechanisms:

    There appear to be no standards-track key distribution and rotation
    protocols for either of OSPF, IS-IS, BGP or BFD (static keying seems
    to be the norm), so a natural question is whether HNCP could serve
    this purpose, or whether it would be better to use a dedicated key
    distribution and rotation mechanism.

  - RFC 3971 Section 6 says the following:

       To protect Router Discovery, SEND requires that routers be
       authorized to act as routers.  This authorization is provisioned in
       both routers and hosts.

    Since hosts don't participate in HNCP, it is not clear if HNCP can be
    used as a SEND trust anchor.  I believe there's the same issue with
    securing access the DNS stub resolver (DNSCrypt, DNS over TLS, etc.).

-- Juliusz