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

Ted Lemon <mellon@fugue.com> Tue, 28 March 2017 18:48 UTC

Return-Path: <mellon@fugue.com>
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 08098129445 for <dhcwg@ietfa.amsl.com>; Tue, 28 Mar 2017 11:48:47 -0700 (PDT)
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, 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: 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 y1qx2b-dUVkI for <dhcwg@ietfa.amsl.com>; Tue, 28 Mar 2017 11:48:43 -0700 (PDT)
Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 3BAC1129A02 for <dhcwg@ietf.org>; Tue, 28 Mar 2017 11:48:41 -0700 (PDT)
Received: by mail-pg0-x233.google.com with SMTP id 81so66235309pgh.2 for <dhcwg@ietf.org>; Tue, 28 Mar 2017 11:48:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; 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; d=1e100.net; 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 10.84.229.13 with SMTP id b13mr25612243plk.72.1490726920861; Tue, 28 Mar 2017 11:48:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.179.203 with HTTP; Tue, 28 Mar 2017 11:48:40 -0700 (PDT)
Received: by 10.100.179.203 with HTTP; Tue, 28 Mar 2017 11:48:40 -0700 (PDT)
In-Reply-To: <80C62C74-BB9D-4F43-9C2F-A5EC02A63918@cisco.com>
References: <CAJE_bqetH-MvY1RRGXvyy3t8WDa9AUDcvXM6jW0aGP=uJC60hg@mail.gmail.com> <3566F64B-D709-4DF3-9A5F-7648DA8FC45E@cisco.com> <CAJE_bqf1QijOkv4L=YumwH+gxSh5QRxkukAN-b+cgE7zabTmOA@mail.gmail.com> <4512A1F7-A480-4250-BE57-FCE822EAC890@fugue.com> <80C62C74-BB9D-4F43-9C2F-A5EC02A63918@cisco.com>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 28 Mar 2017 14:48:40 -0400
Message-ID: <CAPt1N1=B47QURtMNK=hCX-xByF5F4vjB6=fKR5_pHHdc=yQe1A@mail.gmail.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
Cc: dhcwg <dhcwg@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Content-Type: multipart/alternative; boundary=94eb2c1a3e26934ff0054bcee810
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/aIQaB0IPbJCBaK9CQK07Ruvi7Ig>
Subject: Re: [dhcwg] whether/how to support Confirm with 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: 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
problem.

On Mar 28, 2017 10:44 AM, "Bernie Volz (volz)" <volz@cisco.com> 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" <mellon@fugue.com> 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.
>
>
>
>