Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6

Francis Dupont <Francis.Dupont@fdupont.fr> Wed, 07 June 2017 23:37 UTC

Return-Path: <Francis.Dupont@fdupont.fr>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47F51293E3 for <dhcwg@ietfa.amsl.com>; Wed, 7 Jun 2017 16:37:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 6P8pSS5NXZov for <dhcwg@ietfa.amsl.com>; Wed, 7 Jun 2017 16:37:31 -0700 (PDT)
Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E4E1128CD5 for <dhcwg@ietf.org>; Wed, 7 Jun 2017 16:37:31 -0700 (PDT)
Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v57NMdgh078025; Thu, 8 Jun 2017 01:22:39 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201706072322.v57NMdgh078025@givry.fdupont.fr>
From: Francis Dupont <Francis.Dupont@fdupont.fr>
To: Ted Lemon <mellon@fugue.com>
cc: =?utf-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>, dhcwg <dhcwg@ietf.org>
In-reply-to: Your message of Wed, 07 Jun 2017 18:26:30 -0400. <32EF9515-3518-4D50-B718-B2B3A8839346@fugue.com>
Date: Thu, 08 Jun 2017 01:22:39 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/mqfMMZFY1tZYFjR-ILFESQ-KTW8>
Subject: Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Jun 2017 23:37:33 -0000

 In your previous mail you wrote:

>  Right.  That's what I mean.   The encrypted payload is going to the host =
>  where the relay agent is running, which doesn't have the key to decrypt =
>  the payload.   And so the packet is never delivered to the relay agent, =
>  and hence never forwarded to the DHCP server.

=> I don't understand your argument: if you send an encrypted packet
to a box without the proper security association of course it does not
work. This has nothing to do with IPsec and will happen with DTLS too
or anything secure protocol which carries DHCP messages.

As I said we are squeezed between the address bootstrap mess (this problem)
and the security bootstrap mess (the problem that current secure DHCPv6
tries and IMHO fails to solve).
So I strongly suggest to write what we want and to reduce problems to
things we know to do reusing as most as possible already existing protocols.
On the paper hop-by-hop IPsec works and for the privacy only we have
the opportunistic IPsec idea so it seems a good point to start
(and as it is transparent for DHCP is clearly out of the scope of
both the DHCP WG and this list, argh! :-).

Thanks

Francis.Dupont@fdupont.fr