Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6

Francis Dupont <> Wed, 07 June 2017 19:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1FCFD131463 for <>; Wed, 7 Jun 2017 12:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 01Vevg5EsQdT for <>; Wed, 7 Jun 2017 12:23:37 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 3F41912948F for <>; Wed, 7 Jun 2017 12:23:37 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (8.14.7/8.14.7) with ESMTP id v57J8lqg062133; Wed, 7 Jun 2017 21:08:47 +0200 (CEST) (envelope-from
Message-Id: <>
From: Francis Dupont <>
To: Tomek Mrugalski <>
In-reply-to: Your message of Wed, 07 Jun 2017 20:43:05 +0200. <>
Date: Wed, 07 Jun 2017 21:08:47 +0200
Archived-At: <>
Subject: Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Jun 2017 19:23:39 -0000

 In your previous mail you wrote:

>  This work has been in development for almost a decade. This particular
>  approach started in 2013. Let's not restart the work until we exhaust
>  all other possible alternatives.

=> I know it was pretty old (I was its gen-art reviewer and did thsi
review the 20130220 according to my message to gen-art...).
At this time it was not ready ("Summary: Not Ready" cut & paste
from this message) but putting some ideas from SEND which solved
a similar problem with same hard constraints made it something

IMHO the real issue comes from the switch from an authentication
mechanism to unauthenticated encryption. So if the name is the same
in fact it is a very different protocol, and of course to twist it
to fulfill a different goal did not work well...

>  How about the proposal Bernie made here?

=> IMHO anything using RSA encryption is dead.

>  Another possible approach to the problem mentioned in off-line
>  discussion was DTLS 1.2 (RFC6347), but Francis pointed out that it's
>  quite exchange heavy, compared to DHCP, which takes 1 or 2 exchanges.
>  Going to 3 or perhaps 4 exchanges is ok in my opinion, but if the
>  proposal requires more than that, we would see a lot of raised eyebrows.

=> without RSA encryption only solutions using state and multiple
exchanges are available so instead to transform DHCP into something
different I suggest to do the opposite: start from a security protocol
and add some DHCP features into it. In the case of opportunistic
IPsec/IKE it could be more DHCP features or if we are lucky some


PS: References are:
 RFC 4322 "Opportunistic Encryption using the Internet Key Exchange (IKE)"
 RFC 5996 "Internet Key Exchange Protocol Version 2 (IKEv2)"
 RFC 5739 "IPv6 Configuration in Internet Key Exchange Protocol
           Version 2 (IKEv2)"