Re: [dhcwg] whether/how to support Confirm with sedhcpv6

Ted Lemon <> Tue, 28 March 2017 18:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08098129445 for <>; Tue, 28 Mar 2017 11:48:47 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y1qx2b-dUVkI for <>; Tue, 28 Mar 2017 11:48:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3BAC1129A02 for <>; Tue, 28 Mar 2017 11:48:41 -0700 (PDT)
Received: by with SMTP id 81so66235309pgh.2 for <>; Tue, 28 Mar 2017 11:48:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S7p1KNsSLDS6SewJ5qkAJbgme0R5dojc6QRZtYDH9b4=; b=pvkIxuaXWjQUxB8JwWrf91KjMYIPhYo/UZyF+2aEPhnVGWKXfc2E4voclwfT/iJZMg AK548vgpr1vRbQQvXuuSab6WlIQTogrWSOYPLoL4Mi5PAMqFuk5lacv8GOM5UFysC/O0 oUWUEBCYW/PO7XHVsB+4EJJSEtfF5zTgE8xV8mPg5qLRBtXC6cJpeDLdEiCrSoTMOD3I iFxF3WsAO9LfIJ2BbO2+NReONvsFnPwZ5lrxFiAxe4Z+M32+N2C+4ebAmOJYzFjsMc4L /rCkKqvFcO0/7imQIhZu2cQ2LCe6QZKML6/TWr38SSsIzfYEfgM4w0xcJTQKrQ6pq2+E iH3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S7p1KNsSLDS6SewJ5qkAJbgme0R5dojc6QRZtYDH9b4=; b=BUcbSV4cBxM9wPzZ3+k+eEDsSWX/ZWhlZaYOlSCfJ7tNiUY2sKzKGtZBMpAldI3Rzm 6Hae291CtKqMkBRlfKuHLgz/82a9kEvys1E8hh3bUrW41eca2cR4lJve6TXoK2/i78+O WGCPdlbA8MS9hPjhxmiNrypG1iq7ZKn54E82BYqx26C/yMcZ8GiU2jLawCLQpxOACFgR XlstfduJte4YBgs/DaixNV5YOHlgbpYWVFbfgrdLB+raWrwCm91JSxBi7U9acXgpWCbs /pMAkODOwZVv8qSZ5ItugnCF6BsuZEulzzeSy65dB7Z5ZGIMsqmT/Oac3Z3wMpGbK9eu DoyA==
X-Gm-Message-State: AFeK/H2cSkaedU6cqEWDgrCzY5iBZ9qDEiUCSNNmLV5QUZa7uVRtCpwPhI/k0AtF5BkjXIBgdnHo7UXrqIlZ3g==
X-Received: by with SMTP id b13mr25612243plk.72.1490726920861; Tue, 28 Mar 2017 11:48:40 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 Mar 2017 11:48:40 -0700 (PDT)
Received: by with HTTP; Tue, 28 Mar 2017 11:48:40 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Ted Lemon <>
Date: Tue, 28 Mar 2017 14:48:40 -0400
Message-ID: <>
To: "Bernie Volz (volz)" <>
Cc: dhcwg <>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Content-Type: multipart/alternative; boundary=94eb2c1a3e26934ff0054bcee810
Archived-At: <>
Subject: Re: [dhcwg] whether/how to support Confirm with 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: Tue, 28 Mar 2017 18:48:47 -0000

I think these are easy problems to solve and do not add significant
complexity.   Encryption of the confirm I think addresses the privacy

On Mar 28, 2017 10:44 AM, "Bernie Volz (volz)" <> wrote:

> Interesting idea …
> But, wouldn’t just sending the initial Information-Request per seDHCPv6
> which “solicits” server’s certificates with the Encrypted-Message Option
> which contained the Confirm (and an Encryption Key Tag Option) be best? Not
> exactly sure what the reference to “wrap relay messages”.
> We might also consider whether this could be useful for the Rebind (prefix
> delegation version of Confirm).
> And, then there’s the question of what the server’s response is … for the
> server that can decrypt, it would send a Reply for the Confirm(/Rebind) and
> not answer the Information-Request?
> BTW: RFC 7844 (DHCP Anonymity Profiles) section 4.2 says not to send
> Confirms. Perhaps for seDHCPv6, starting with the seDHCPv6
> Information-Request is thus OK and if client determines same server exists
> (based on certificate) it could then issue Confirm (or just Renew/Rebind).
> RFC7844 4.2 also suggests that if other information about the link is
> available (such as SSID), the Confirm might be sent directly.
> The main question is how much special mechanism to add? Be nice to not
> make it too complex.
> - Bernie
> On 3/28/17, 11:28 AM, "Ted Lemon" <> wrote:
>     Probably the most expedient way to handle this would be to create a
> confirm, sign and encrypt it, and then wrap it the same way we wrap relay
> messages, including it in an information-request as in the regular
> IR/Solicit/Confirm process for secure DHCP.
>     The server on the local wire either supports the wrapping and can
> decrypt, supports it but cannot decrypt, or doesn't support it and hence
> ignores it.   This allows the client to send a single packet that will
> always elicit a response, either an answer to the question asked in the
> Information request, or else a confirmation that it's okay to continue
> using the address.
>     The hard question is, what do you do if you get an answer to the
> information request, rather than to the Confirm?   But I think that's
> straightforward: you wait a (short) while to see if you get an answer to
> the confirm; if you do, you take that; otherwise you take the answer from
> the Information-Request.