Re: [dhcwg] IETF-93 Follow Up - draft-ietf-dhc-stable-privacy-addresses (Respond by Aug 11, 2015)

Linhui Sun <lh.sunlinh@gmail.com> Tue, 11 August 2015 11:45 UTC

Return-Path: <lh.sunlinh@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAB91A8836 for <dhcwg@ietfa.amsl.com>; Tue, 11 Aug 2015 04:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Level:
X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=no
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 bW6EJxcD0yG9 for <dhcwg@ietfa.amsl.com>; Tue, 11 Aug 2015 04:45:58 -0700 (PDT)
Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::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 100691A8830 for <dhcwg@ietf.org>; Tue, 11 Aug 2015 04:45:58 -0700 (PDT)
Received: by pdrh1 with SMTP id h1so64872805pdr.0 for <dhcwg@ietf.org>; Tue, 11 Aug 2015 04:45:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:to:cc:references:subject:mime-version :content-type:content-transfer-encoding:content-disposition; bh=ErGihFq4WjVZkh89Ea+lF0lnD5BeFZAovYGujslkSmI=; b=HVvApk4nMJ+WHWPyPyyUwnQfng/zmYB37BwQQUCfRa1ByBLD+zSPTVRV7/039/zLPI a8bOkWy/YRRrK+QZg92/VOTpjFFanAafg+Y4QHVRt22L5xAOVbQEUIrlGpqoglUFiq/S ZTR+opH31TQulHtuTGxslVWRgBf9tsviaJPd5Zi2lh049+XmThWY17lmYII9qVZ/98E0 lxWDLj5AT4D3Qka5YM3aYNRxGXjUhQG/otDaeiD0gMJfAW9b+osAoB15LrZ26gBgCRyx lv3yxScvySo4aHINjmBF9eqd0bCugi1jktpr4OAXU0uPGAZIrt0k5tqL6298y4h0nqGI HIEQ==
X-Received: by 10.70.92.138 with SMTP id cm10mr56184085pdb.63.1439293557779; Tue, 11 Aug 2015 04:45:57 -0700 (PDT)
Received: from [127.0.0.1] ([119.28.3.169]) by smtp.gmail.com with ESMTPSA id is3sm2369226pbc.53.2015.08.11.04.45.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2015 04:45:56 -0700 (PDT)
Message-ID: <55c9e074.43c5440a.e673f.5c8d@mx.google.com>
X-Google-Original-Message-ID: <emc_8d74c07fd1e94e07a4d7d05700e0ddbb>
Date: Tue, 11 Aug 2015 19:45:53 +0800
From: Linhui Sun <lh.sunlinh@gmail.com>
To: 神明達哉 <jinmei@wide.ad.jp>
References: <CAJE_bqeCgTvy=PMdfGAx-r3m=54HAnnUDjYFNjboJdwyWQD+AQ@mail.gmail.com> <489D13FBFA9B3E41812EA89F188F018E1CB90384@xmb-rcd-x04.cisco.com> <55c85da1.8520460a.54bd4.18c0@mx.google.com>
X-Mailer: YoMail.Win
X-YoMail-GUID: emc_8d74c07fd1e94e07a4d7d05700e0ddbb
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
Content-Disposition: inline
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/D3v_nlTSS3fVfC-1jXoSAIAqFFI>
Cc: dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] IETF-93 Follow Up - draft-ietf-dhc-stable-privacy-addresses (Respond by Aug 11, 2015)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Aug 2015 11:45:59 -0000

Hi Jinmei,

Thanks for your reply and please see comments inline.

Best regards,
Linhui

< 神明達哉> 2015-08-11 00:54:00 wrote:
At Mon, 10 Aug 2015 16:15:25 +0800,
Linhui Sun <lh.sunlinh@gmail.com> wrote:


> Have a brief look at this document, it defines an algorithm to solve
> the safety problem brought by IPv6 SLAAC, where the MAC address is
> encapsulated in the IPv6 address.


I don't get it...draft-ietf-dhc-stable-privacy-addresses has nothing
to do with SLAAC. Besides, "solutions" to the problem you mentioned
about SLAAC have already been published, first in RFC 3041 back in
2001, then in RFC 4941, and now in RFC 7217.

[LH]: Sorry for the error and thanks for pointing out that. It seems that I was a little bit confused with the previous work (as you mentioned RFC7217). Have another look on this document, it does have nothing to do with SLAAC. It defines an algorithm to randomly generate interface id that is hard to be predicted to mitigate the privacy issue. Please correct me if I'm wrong again : )

If you tried to say that dhc-stable-privacy does not embed a MAC
address as the pure SLAAC does, the bare DHCPv6 already has that
property (an awkward server implementation might still embed a MAC
address, but that's not a protocol issue and would be quite unlikely
to be the case in practice anyway).

[LH]: Agree, since DHCPv6 and SLAAC are different things, it makes no sense to say this does not embed a MAC address.

--
JINMEI, Tatuya