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

Ted Lemon <mellon@fugue.com> Fri, 08 March 2019 15:10 UTC

Return-Path: <mellon@fugue.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 BD01612787F for <homenet@ietfa.amsl.com>; Fri, 8 Mar 2019 07:10:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 Y-jzfCgcFAUL for <homenet@ietfa.amsl.com>; Fri, 8 Mar 2019 07:09:58 -0800 (PST)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 73BD112423B for <homenet@ietf.org>; Fri, 8 Mar 2019 07:09:58 -0800 (PST)
Received: by mail-qt1-x82d.google.com with SMTP id v10so21518617qtp.8 for <homenet@ietf.org>; Fri, 08 Mar 2019 07:09:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xQojqM0F46k6JHeW7N1bKOLXfSrXNScAJszYmgLXDkY=; b=Tk1tAG529mqrKFieIdzqn3d1OMGVEX/UQqMOv4yHsa4GHcptZXprep6WLR/7ud7hSo /e5SEq2r+bxEeqULZGLHerrdREesrza7/6lDjiGjEX1GWYZvg52BNMaEzijepYSGFI3S oqzMZbQMNsl33zzXVtPO4CdBMf69Txay/J9lt/TbNE+w6Zn1pZqNDQGcOioMfNY3U6Oa uBMSibOHiSumhc9vOb1Kmo2fFJNU9r9HhLaiNbscvW4F0Q/7T801fWEpXuX/IEpbyHoI blFS4EQSpjI7DYuOe8X4ZLVjwqyB84FHCSvHr6YJ5drp5TqhNK3yimzSD1T/eQUn6P1Y zmuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xQojqM0F46k6JHeW7N1bKOLXfSrXNScAJszYmgLXDkY=; b=dZM++Qa2asvmzuab9NVG9mpW3U57uWxzla5NLc+lIMVFrJD3sq546aOl1TVoerGOON bs/V6VR/2H9f5jRqI769A/9kvOeQgtKoMpoFeoGaB627VhUDeZEa8/vo3HVFHdPozNN9 PWif0Z91MsAn/4ckLL9oVNOCLWSyuWEDXwa6h2RCTyi0+XrYfTy1JN1rUaGi6gXHoAf5 yNILRfOWx5XXamnemL40TVP7CQz8GQONherc0luKx2WDmam8Bm9lGbBSa+JGOM0qJ3y9 KQ3KFRibTuJQkwWKofRt3ZVactF5eQlhCeTDqm2OJKNky2LwCz7cd/4LSqiNCN375kz0 ejng==
X-Gm-Message-State: APjAAAXBT/KeJ+hbl+VVU66zc8crgEqptoT/2P08AJrJBrOEpaCtE5wM F5UHIX3tmiiK32EuTt05t98Vbw==
X-Google-Smtp-Source: APXvYqznFHWXPTWXWjIyoXdnWVidWg48SiVaXEyck4LKMz59deqvLgUBtrF7TnUp2aRLtf25teghZA==
X-Received: by 2002:ac8:3439:: with SMTP id u54mr15555681qtb.154.1552057797554; Fri, 08 Mar 2019 07:09:57 -0800 (PST)
Received: from [10.0.100.12] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id p35sm5054375qte.83.2019.03.08.07.09.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Mar 2019 07:09:57 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <6D84125B-40C4-4B9C-914E-0B701E2827CD@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F8B218D4-A281-410A-B9C1-5F47D2DC3968"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\))
Date: Fri, 8 Mar 2019 10:09:56 -0500
In-Reply-To: <871s3hlefh.wl-jch@irif.fr>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "homenet@ietf.org" <homenet@ietf.org>
To: Juliusz Chroboczek <jch@irif.fr>
References: <894b4181-c4ca-5cf1-adba-1c5fcab0d355@cs.tcd.ie> <871s3hlefh.wl-jch@irif.fr>
X-Mailer: Apple Mail (2.3445.104.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/Stk1LIQPpJK3sEOaFwt_pg6bZWo>
Subject: Re: [homenet] homenet: what now? ... next?
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: Fri, 08 Mar 2019 15:10:01 -0000

On Mar 8, 2019, at 7:48 AM, Juliusz Chroboczek <jch@irif.fr <mailto:jch@irif.fr>> wrote:
>> (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.)

We have a working dnssd discovery proxy and client.   What we don’t have is those things connected via hncpd.   That is one of the things I would like to work on at the hackathon, if there is interest.

>> (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.)

I had indeed missed this—thanks for pointing it out.   However, I have no idea how to configure it with existing software.   This is also something I’d like to work on at the hackathon: can we actually use this mechanism?   Can we come up with a way to set it up in OpenWRT that people who are not networking grad students can deploy?

> - Babel has two security mechanisms:
> 
>       https://tools.ietf.org/html/draft-ietf-babel-hmac <https://tools.ietf.org/html/draft-ietf-babel-hmac>
>       https://tools.ietf.org/html/draft-ietf-babel-dtls <https://tools.ietf.org/html/draft-ietf-babel-dtls>
> 
>   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.).

HNCP can’t be used by hosts to establish trust, as currently specified.   We don’t really have an answer to the host enrollment problem at present, unfortunately.