Re: [dhcwg] Fw:New Version Notification for draft-cui-dhc-dhcpv6-encryption-00.txt

神明達哉 <jinmei@wide.ad.jp> Fri, 10 July 2015 18:08 UTC

MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
In-Reply-To: <639aa3c9.1158f.14dbe76fb5e.Coremail.lilishan48@126.com>
References: <639aa3c9.1158f.14dbe76fb5e.Coremail.lilishan48@126.com>
Date: Fri, 10 Jul 2015 11:08:23 -0700
Message-ID: <CAJE_bqc+dqM3TgdHvHgB3ZocMGGnMkMpapKm7k9fW=mUTzgn3A@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: Lishan Li <lilishan48@126.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/-LKarUgnCXXVdERQHEnnFFSh3-s>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] Fw:New Version Notification for draft-cui-dhc-dhcpv6-encryption-00.txt
Precedence: list

On Thu, Jun 4, 2015 at 5:06 AM, Lishan Li <lilishan48@126.com> wrote:

> We have submitted a new draft about DHCPv6 Authentication and Encryption
> mechanism.
> This document discusses two possible solutions to achieve the authentication
> and encryption between DHCPv6 server and client. One solution needs to be
> selected to solve the DHCPv6 privacy problem. We are not sure which one the
> WG would prefer.
> Could you please review the draft and any comments are welcome.

I don't have a strong opinion either way, but since "Solution B" would
require a substantial change to the original protocol anyway (as
described in Section 4.4), "Solution A" seems a bit better.

Some other random thoughts:

- Especially if we use "Solution A", wouldn't it be better to use a
  symmetric key after authentication, rather than keep using
  public/private keys?  For a client that may not matter much, but for
  a busy server the performance overhead difference might be
  substantial.
- And, to this end, would it be feasible to use a separate encryption
  mechanism such as DTLS rather than introducing a built-in mechanism
  for DHCP(v6)?  (In case of DTLS we should at least consider how to
  handle multicast traffic, though).
- If (one of) the main purpose for encryption is to hide clients'
  identity, we'll probably also need to consider the identify
  disclosure via the certificate or public key.
- The draft seems to (implicitly?) assume this encryption will be used
  for stateful DHCPv6 sessions starting with a SOLICIT message.  Would
  it also be expected to be used for stateless sessions beginning with
  INFORMATION-REQUEST?

--
JINMEI, Tatuya

[dhcwg] Fw:New Version Notification for draft-cui… Lishan Li
Re: [dhcwg] Fw:New Version Notification for draft… 神明達哉
Re: [dhcwg] Fw:New Version Notification for draft… 神明達哉