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

神明達哉 <jinmei@wide.ad.jp> Tue, 28 March 2017 04:16 UTC

Return-Path: <jinmei.tatuya@gmail.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 DF6901275C5 for <dhcwg@ietfa.amsl.com>; Mon, 27 Mar 2017 21:16:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.702
X-Spam-Level:
X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Mo8K03-V_vB3 for <dhcwg@ietfa.amsl.com>; Mon, 27 Mar 2017 21:16:31 -0700 (PDT)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 76A64126DED for <dhcwg@ietf.org>; Mon, 27 Mar 2017 21:16:31 -0700 (PDT)
Received: by mail-qt0-x230.google.com with SMTP id n21so54806795qta.1 for <dhcwg@ietf.org>; Mon, 27 Mar 2017 21:16:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=MHMyDPNY2afAGE5EIWEWgOZ5heEFwsQ+A1FMHo0qIko=; b=ooV8uX/3vkmXXAHCikVCcNvVi8AWqFyjIgOj9CUC3PYUxcS8SQJbP2NT+IBFnaQJh4 s+bdEhHdZaDaTfRJ46641IWk+Xy3ZW4Ff9tvvGjN81uF2lR+/4iGOcoeUILZPIb6KaH0 qSQBi4SZnmIQgB0KkkP47weJTI0Mi+RVikqTWhY8ZBObVBZ5dhERUTyeqhQ57jCU+Uu/ UoQnWnmWjlqTQBrJZpQWEjvKI6n4lQEJLVg9HzdJZCjpV6NkaM5e/sZXJoOfas/apClM a/V9CZrY3IyufvoVVssnWkPwQccxx08i8zbUupVCQwAZIU1h3HT+tsQSyBR+9k8LJai+ JCDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=MHMyDPNY2afAGE5EIWEWgOZ5heEFwsQ+A1FMHo0qIko=; b=Og4rKaa7M0eBAPoNPU+BQAgZj7Yw3fWNmXhYGeYyIMFz0T6tBjcfg7wU4taheDq0P9 8uvMwXJyX26Bevr8PTU0qdUhYZDrHRx/3S/EE4F69/Tpkhl9GitOQnTOE2zRW9UNaLMF afhCK/kd1wumK1A9OCWHihrcgrq2GGlYTq03Xn8/+CFCXsqvh0rQUzHdKbEeY+TgkppR 1gbK5zFuF6Pi5t/31O7uqw4H5B6LfMWxnTpfPwNEjQz2Ouwk8SFe3M/TuUvv3e4U2x41 +ga8KwSMmvBVT0sL9QE0Nq1lJULJuUKRZ3fcrJv+eHmTiUMcaxJC+xsb8KVWUq91ahyz n1SA==
X-Gm-Message-State: AFeK/H2tH2JhPo4dQl80N4tvIhClBgv8rf29ysfhibFCzOH8gzLlcPfSYVqQtrLkXLKT8bz2l4VbPIuKmwXMiw==
X-Received: by 10.200.56.48 with SMTP id q45mr24632974qtb.220.1490674590583; Mon, 27 Mar 2017 21:16:30 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.61.204 with HTTP; Mon, 27 Mar 2017 21:16:30 -0700 (PDT)
In-Reply-To: <3566F64B-D709-4DF3-9A5F-7648DA8FC45E@cisco.com>
References: <CAJE_bqetH-MvY1RRGXvyy3t8WDa9AUDcvXM6jW0aGP=uJC60hg@mail.gmail.com> <3566F64B-D709-4DF3-9A5F-7648DA8FC45E@cisco.com>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Mon, 27 Mar 2017 21:16:30 -0700
X-Google-Sender-Auth: JRM_GETPBkRB9gNOAecJAZmUik0
Message-ID: <CAJE_bqf1QijOkv4L=YumwH+gxSh5QRxkukAN-b+cgE7zabTmOA@mail.gmail.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/H4g3KWQaTkioRk56itGl0IIF9zs>
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 04:16:33 -0000

At Sun, 26 Mar 2017 14:44:49 +0000,
"Bernie Volz (volz)" <volz@cisco.com> wrote:

> Good point ... I was thinking that encrypted Confirm (or Rebind)
> would be fine - if still on same link (or at least server) it would
> work just fine. Otherwise, client times out and is left to use other
> mechanisms (RS/RA)?

I think that's find in the case of Rebind: if the current server dies
but there are other available servers, and if the admin chooses to
deploy sedhcpv6 in that network, other servers hopefully share the
same server key pair and can decrypt the encrypted Rebind.  (But even
if so, it may be a good idea to discuss this point explicitly).

But, in the case of Confirm and when the client has actually moved,
this approach will involve some longer time until the client falls
back to other mechanisms including a restart of DHCPv6.  This is worse
than the current Confirm without sedhcpv6, and I think it's generally
better to eliminate such regression.

--
JINMEI, Tatuya