Re: Feedback on draft-gont-6man-stable-privacy-addresses-01

Tina TSOU <Tina.Tsou.Zouting@huawei.com> Sun, 15 April 2012 20:56 UTC

Return-Path: <Tina.Tsou.Zouting@huawei.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC8621F8876 for <ipv6@ietfa.amsl.com>; Sun, 15 Apr 2012 13:56:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.425
X-Spam-Level:
X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=-1.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_OFF=2.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjTdzhdgC1Xn for <ipv6@ietfa.amsl.com>; Sun, 15 Apr 2012 13:56:36 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A029321F8867 for <ipv6@ietf.org>; Sun, 15 Apr 2012 13:56:36 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEX99042; Sun, 15 Apr 2012 16:56:36 -0400 (EDT)
Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 15 Apr 2012 13:55:54 -0700
Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 15 Apr 2012 13:55:54 -0700
Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.22]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Mon, 16 Apr 2012 04:55:50 +0800
From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
To: Fernando Gont <fgont@si6networks.com>
Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01
Thread-Topic: Feedback on draft-gont-6man-stable-privacy-addresses-01
Thread-Index: AQHNGn3Vi4WOiPBDMkmREF4aZJE5EpaabyKAgAACpwCAADCgAIAAGYWAgACxIgCAAPI6lw==
Date: Sun, 15 Apr 2012 20:55:49 +0000
Message-ID: <92C76338-38FC-40FE-9CDB-6C4365B67A2F@huawei.com>
References: <E7607B61-9889-43A9-B86B-133BD4238BA2@gmail.com> <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <CAAuHL_BCv2q=hDjTLmiviLoRRTbbyU+aSSQ0ETbDDQk==YfmLQ@mail.gmail.com> <C5B723A8-8A24-46BD-94E5-0BA2D8CCB460@cisco.com> <4F89DEE7.1080205@si6networks.com> <C91E67751B1EFF41B857DE2FE1F68ABA03CFD484@TK5EX14MBXC274.redmond.corp.microsoft.com> <8C04B19A-6E88-4544-8827-13BB4D672CFE@cisco.com> <4F8A3124.4090005@si6networks.com> <1BEEB247-8C36-4139-BF44-79E4993033E1@cisco.com>, <4F8ADB24.1050606@si6networks.com>
In-Reply-To: <4F8ADB24.1050606@si6networks.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_92C7633838FC40FE9CDB6C4365B67A2Fhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Christian Huitema <huitema@microsoft.com>, "ipv6@ietf.org 6man" <ipv6@ietf.org>, Fred Baker <fred@cisco.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Apr 2012 20:56:37 -0000

This function results in addresses that:

1. R stable within the same subnet
2. Have different Interface-IDs when moving across networks

Sent from my iPad

On Apr 15, 2012, at 7:30 AM, "Fernando Gont" <fgont@si6networks.com<mailto:fgont@si6networks.com>> wrote:

Hi, Fred,

On 04/15/2012 05:54 AM, Fred Baker wrote:
That said, a more general question would be: should we include the
(numeric) interface index rather than e.g. a hardware-specific
I-D?

Hmmm. I would tend to think that's a small positive integer, which
isn't all that unique.

Exactly.


Are you thinking of something different than I am?

I don't think so.

If you concern is security, bear in mind that the security of the
mechanism relies on the cryptographic strength of F(), and the
secret_key (and not on the "data" that is hashed. -- That said, the
current I-D recommends to include the machine's serial number in the
hash (as recommended by Steve Bellovin) as part of the data to be hashed
(and this value is expected to be unknown at least to a remote attacker).

If your concern is that two hosts might end up computing the same IID,
then note that the recommendation is for the secret_key to be set to a
random value, *and* as noted in the previous paragraph, we also
recommend to include the machine's serial number as part of the data to
be hashed (and this number is expected to vary from one node to another).

This approach would lead to addresses that do not vary if you change the
NIC (as we'd not be using the MAC address), and one might argue that is
even more 2general" since, as you correctly noted, not all interfaced
have IEEE addresses.

IN any case, this is just an idea. I personally think that would be
really cool. But I'd like you and others to comment.

Thanks!

Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<mailto:fgont@si6networks.com>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------