RE: default-iids ready for WGLC? (Re: I-D Action: draft-ietf-6man-default-iids-10.txt)

Christian Huitema <huitema@microsoft.com> Fri, 25 March 2016 01:10 UTC

Return-Path: <huitema@microsoft.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 5C45912D9CE for <ipv6@ietfa.amsl.com>; Thu, 24 Mar 2016 18:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 KapPIe_oNfwO for <ipv6@ietfa.amsl.com>; Thu, 24 Mar 2016 18:10:36 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:796]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899F312D9C7 for <ipv6@ietf.org>; Thu, 24 Mar 2016 18:10:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=04+UV0oAVidq97DnZXW8jaBW5/RBwZyXQREddReaLGc=; b=RFlrAikswgexTReE8zqPVApMAYcSAw0LFvzdkty7G6FbpeZfjbXPgBYxA3nfH7zS6Q8mnCxNTAcdhlti5mCLkteYSKf3bbi0NjDRaeEGKTCG14ZoKb9r/Q/qvRWU9e8lNib6Nj3j+SMhJZqYemA4xTDZnEcH1P4wKIQjohq40n4=
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) with Microsoft SMTP Server (TLS) id 15.1.434.16; Fri, 25 Mar 2016 01:10:14 +0000
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0434.023; Fri, 25 Mar 2016 01:10:14 +0000
From: Christian Huitema <huitema@microsoft.com>
To: Fernando Gont <fgont@si6networks.com>, Lorenzo Colitti <lorenzo@google.com>, Brian Haberman <brian@innovationslab.net>
Subject: RE: default-iids ready for WGLC? (Re: I-D Action: draft-ietf-6man-default-iids-10.txt)
Thread-Topic: default-iids ready for WGLC? (Re: I-D Action: draft-ietf-6man-default-iids-10.txt)
Thread-Index: AQHRaXPDogG0q1X6D0m1s0AcI1i5hp9dzFGAgAAlA4CAAU8iAIAADQMAgAAB1ICAAA3ogIAACtSAgAADAICAAAkUAIAAG+QAgAC1TwCAA1t5AIAAenMAgACZlYCAAAKOAIAAAW6AgADKNACAAAxmAIACLFmAgAHUKpA=
Date: Fri, 25 Mar 2016 01:10:14 +0000
Message-ID: <DM2PR0301MB0655E824D1D31AB7CC224365A8830@DM2PR0301MB0655.namprd03.prod.outlook.com>
References: <20160217110334.12586.6254.idtracker@ietfa.amsl.com> <56EACDE3.3020708@si6networks.com> <CAKD1Yr0xHUaZtgGr-_kDykP7xSzSOdwpucp60KZkzgnh8OEATw@mail.gmail.com> <56EBF1EE.4080105@si6networks.com> <CAKD1Yr0ffqhbfKt4w465eD7zg5XQu9URgF9FYH-XZcGVM-PjGg@mail.gmail.com> <56EBFF21.3010202@si6networks.com> <CAKD1Yr2VXmDfvzVk9g-PuKXkrNzF2JUrCeov27_U4eH_tUvOAA@mail.gmail.com> <56EC0ABB.4050608@si6networks.com> <CAKD1Yr2xDO+wsRtni-2oTCskxt5UsyY-tnf7nviXvjnqEWCAhQ@mail.gmail.com> <56EC29BE.7020802@si6networks.com> <CAO42Z2w+ezd9-K+xczTjA2pZz-it7v6=4E3LTHMhRfHG5B128A@mail.gmail.com> <CAKD1Yr1VEjQRW5VgpYNQYbK=ZcHvYrmvGuFoaJp=B5fD92dygw@mail.gmail.com> <56EFF988.4040703@si6networks.com> <CAKD1Yr2t8OJLgfPUFnabayku9jus+wc1ZhtEd__5Zj9enJcERw@mail.gmail.com> <56F07C82.2020400@si6networks.com> <CAKD1Yr3akJ1Fa=8Ch+nKzz_FO4+46AUPMfH8n8AbG1106PM79g@mail.gmail.com> <56F12754.4020209@innovationslab.net> <CAKD1Yr2SUNz5Vc0uzvOyXif9tgiyG3P=C1Gt6zxs5nux5Mj48w@mail.gmail.com> <56F3046D.4040700@si6networks.com>
In-Reply-To: <56F3046D.4040700@si6networks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: si6networks.com; dkim=none (message not signed) header.d=none;si6networks.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:5::591]
x-ms-office365-filtering-correlation-id: 505d0ea4-4595-4506-b2f5-08d3544a38d6
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0655; 5:Qb8av1teBMfZNEuZYVr6HQK1XIVFiq3+MCG1qRjoGKikm7E+Oi7uetpz9R0P3trrMW8xyl/lznmkJPQw6IOgcD2ixj6XPiDFvPwaHzoAhwdmKxX/pAoBEaAwlk5X4H9VPO5U9JXOgylu2N02sfQJig==; 24:Uom5obQ0lVI0QVpqh1JBKqWcIArdGLaYtyXswPDePgADbL7ByMHlmw2dJkhGKujdnZ2IzYIEb8hBtGpoGUSf/QovFA0Mp/KY8I6mq3bmPTc=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0655;
x-microsoft-antispam-prvs: <DM2PR0301MB06553E848ED0C3F9B7751A9CA8830@DM2PR0301MB0655.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:DM2PR0301MB0655; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655;
x-forefront-prvs: 0892FA9A88
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(122556002)(10400500002)(8990500004)(5005710100001)(10090500001)(81166005)(106116001)(10290500002)(11100500001)(54356999)(87936001)(50986999)(76176999)(5003600100002)(74316001)(230783001)(92566002)(99286002)(2900100001)(77096005)(2950100001)(33656002)(86362001)(189998001)(5001770100001)(102836003)(76576001)(5004730100002)(93886004)(1220700001)(1096002)(4326007)(3280700002)(6116002)(586003)(3660700001)(5008740100001)(2906002)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0655; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2016 01:10:14.6029 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0655
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/cwe54eAudkNmzzJ5XD0W0HYSCd0>
Cc: IETF IPv6 Mailing List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 25 Mar 2016 01:10:38 -0000

> > What concerns me the most is that platforms that are already
> > implementing MAC address randomization, and that have strong privacy
> > requirements, should not be forced to implement RFC 7217, which from a
> > privacy perspective is inferior to EUI-64 with MAC address randomization.
> 
> That has nothing to do with this document. If that's your concern, then
> you're calling for an update to RFC4941, such that you do both random link-
> layer addresses and temporary addresses with no stable addresses.
> 
> However, I'd say that you can probably get away with what you want, while
> doing RFC7217, even without doing RFC4941: use your randomized MAC
> address as the Net_Iface parameter, and your address will change as often
> as your MAC address. From the point of view of achiving a stable address, I'd
> say you chose the wrong surce of Net_Iface ;-), but it'll get what you want...

I am reading this discussion just now. I think that the issue is with the requirements stated in section, or precisely with what is not stated there. The first requirement stated is about stability, "The resulting Interface Identifiers remain stable for each prefix used with SLAAC within each subnet for the same network interface." That requires that when a mobile node visits a particular subnet, it should obtain exactly the same IID. 

Well, the practice of MAC Address Randomization goes against that. When a user decides to randomize the MAC address used on a particular link, the user expects that during the next visit to the link, after randomization, the interface will obtain a different address. Failing that would allow tracking through IID, and negate the privacy value of the randomization.

As Lorenzo points out, the simple solution is to use the randomized MAC address as the Net_Iface parameter specified for RFC7217. As far as I can tell, at least one stack is doing exactly that today.

Note that this is unrelated to whether IT admins allow randomized addresses, or whether a specific hardware supports it. If randomization is forbidden or unavailable, of course it will not be used and the address will not change. And the users will be easy to track.

-- Christian Huitema