[dhcwg] whether/how to support Confirm with sedhcpv6

神明達哉 <jinmei@wide.ad.jp> Sun, 26 March 2017 14:32 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 0163D12441E for <dhcwg@ietfa.amsl.com>; Sun, 26 Mar 2017 07:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.402
X-Spam-Level:
X-Spam-Status: No, score=-2.402 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 QrshtVCvNUSW for <dhcwg@ietfa.amsl.com>; Sun, 26 Mar 2017 07:32:09 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 243B812940C for <dhcwg@ietf.org>; Sun, 26 Mar 2017 07:32:09 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id p22so21325962qka.3 for <dhcwg@ietf.org>; Sun, 26 Mar 2017 07:32:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=k+w98ndnRx1jsJ4EXcHsXlWAWn/d++DenQGmAVk2vN0=; b=NSEx48BRgr6BDWnnX5FDpOkRs/NoUwWXaTGcL2u7Ss0xpO8JQYlk58vcnRVeujcc5+ 2tMGsb80YRrOocOsYlV3FTgDZgx8h/Ab0LnuvxLOfAxru50upl7PBjaUuffv/FlLSbH+ 8Zzhb9bPAWARhS2auOwUnvbWfmlj3auzNQnZaikvOe9zILaXZqCqNCDVcnQUAy/134He OVWSFWxaVJqQhqwVlY2Jjbb4JjYay3DLeaUIW+y6WyVvYnOonq1PPk/GBTYTeonLlBoU 7+7KbNcFZ2VA+c4FR95/msumPtf9KuDp4UDnGQAgXKphEI+FBQl+HO+M1Jion/0AqkUY 3OAw==
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:from:date:message-id:subject :to; bh=k+w98ndnRx1jsJ4EXcHsXlWAWn/d++DenQGmAVk2vN0=; b=Pwo+65JBMqPPXQ04R751C/8wZglS7z00rkkWjpApaIGlZMTfG6r3X9tYkOrkSBJWZW yzpWka4MC2+wNhPMkeljk190/tRf/h8o2tgHXyQ12r+60MLpy4qG++qoFi/3VhwNCL9I 569ysk9Ra9GTFwjWMIdWSf1Ef47cmXLRiYqlTUXrVWe4wV5Rd4+0mPgjzBjmgyIQ6zfL 3GgQACb9XNy3xBhqSIqwcwZB/dxsinXnV0XT8FF3kwYsKb+wIUUMngkCIoILcrSg11CL BE80pvJoeZQWHQWLV7uIpkDMi2SWEf31byqiQLA1Hquea5PG6WYXn0C3NJRiC18ZD5/1 uLJw==
X-Gm-Message-State: AFeK/H1+REWAAtNjYPZg7c4voJk2Mabpq9wbM7ImeJlAK7vz89fWcgHjJj6MaXgXs59Q6QBiHCvLihTjIN/+0g==
X-Received: by 10.55.146.135 with SMTP id u129mr15734389qkd.219.1490538727916; Sun, 26 Mar 2017 07:32:07 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.61.204 with HTTP; Sun, 26 Mar 2017 07:32:07 -0700 (PDT)
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Sun, 26 Mar 2017 07:32:07 -0700
X-Google-Sender-Auth: vShJIR7Bhlxmd7CEkk-7UWSvYB8
Message-ID: <CAJE_bqetH-MvY1RRGXvyy3t8WDa9AUDcvXM6jW0aGP=uJC60hg@mail.gmail.com>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/1JT0UGx3jnguU04F_qkBPbVMbfQ>
Subject: [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: Sun, 26 Mar 2017 14:32:11 -0000

While reviewing ietf-dhc-sedhcpv6-21, I've realized one thing that
probably requires a discussion: whether/how to use sedhcpv6 for
Confirm.  To avoid distraction I'm raising it separately from the full
review I'm planning to submit later.

When a client might want to send a Confirm, it should be reasonably
possible that the client has moved and would be talking to a different
server.  In that case it doesn't make sense to encrypt the Confirm
message and encapsulate it in an Encryption-query message; the actual
server would silently discard it, and the client can't tell whether
it's because it has moved or the message is simply lost.  So I think
we need some special case handling here.  A couple of choices I can
think of are:
- say sedhcpv6 can't support Confirm (I don't like this option)
- have the client perform a separate information-request/reply
  exchange to see if the currently recognized server and its public
  key are still usable (if not, the client should basically not send
  the Confirm, following the sense of RFC7844).

(There may be other options.)

--
JINMEI, Tatuya