Re: [6lo] Generation of IPv6 IIDs

Fernando Gont <fgont@si6networks.com> Thu, 24 July 2014 00:57 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71F41A0381 for <6lo@ietfa.amsl.com>; Wed, 23 Jul 2014 17:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 7j4osGqzKaba for <6lo@ietfa.amsl.com>; Wed, 23 Jul 2014 17:57:22 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5461A037F for <6lo@ietf.org>; Wed, 23 Jul 2014 17:57:22 -0700 (PDT)
Received: from [2001:5c0:1000:a::991] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <fgont@si6networks.com>) id 1XA7LQ-0006ep-DF; Thu, 24 Jul 2014 02:57:16 +0200
Message-ID: <53D059E8.6030709@si6networks.com>
Date: Wed, 23 Jul 2014 20:57:12 -0400
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Samita Chakrabarti <samita.chakrabarti@ericsson.com>, "6lo@ietf.org" <6lo@ietf.org>
References: <5361A67D.4010508@si6networks.com> <ECA43DA70480A3498E43C3471FB2E1F01C1FBD12@eusaamb103.ericsson.se>
In-Reply-To: <ECA43DA70480A3498E43C3471FB2E1F01C1FBD12@eusaamb103.ericsson.se>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/6lo/yAocSEyDtehqSlyWPiRXhjhFGko
Cc: "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, "6man Chairs (6man-chairs@tools.ietf.org)" <6man-chairs@tools.ietf.org>, Erik Nordmark <nordmark@cisco.com>, "draft-ietf-6man-default-iids@tools.ietf.org" <draft-ietf-6man-default-iids@tools.ietf.org>, Dave Thaler <dthaler@microsoft.com>
Subject: Re: [6lo] Generation of IPv6 IIDs
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jul 2014 00:57:24 -0000

Hi, Samita,

[Erik Nordmark added t te CC list]

Thanks so much for your effort and help in summarizing the discussion!
Please find my comments in-line....


On 07/22/2014 12:41 PM, Samita Chakrabarti wrote:
> 
> Based on the discussions at the 6lo list regarding the impact of
> default-iid draft on 6lo/6lowpan documents and future ipv6-over-foo
> 6lo documents, Ulrich, Ralph and myself had a discussion and our
> recommendation to default-iid co-authors are to either list 6lo
> specific RFCs or make a general statement about 6lo/6lowpan documents
> for exceptions from default-iid  mandate. The future documents in 6lo
> WG  would consider the default-iid recommendations when applicable.
> But note that 6lo deals with  constrained nodes and
> RFC6282/RFC4944/RFC6755 do require using IID bits for efficiency over
> privacy in a constrained network environment that can be isolated
> from the rest of the Internet.

The question here maybe is whether we want to flag these documents as
"exceptions", or whether we want to flag them as "these documents rely
on MAC-address-based IIDs. They may continue to employ such IIDs while a
solution that does not rely on such IIDs is generated".

(i.e., "it's okay to leave as is" vs. "there's work to be done here"...)

The "there's work to be done" option seems to be the one suggested by
Erik, and I tend to like it better than the "leave it 'as is'"



> Carsten Bormann <cabo@tzi.org> ========================== Privacy
> leaks for link-local cases requires privacy fixing at the lower
> layers: https://www.w3.org/2014/strint/papers/35.pdf
> 
> Owen Kirby <osk@exegin.com> =========================== Re-assigning
> link-layer IID is another way to solve privacy in 6lo

My take is that these two are orthogonal. So I don't think one should
consider "randomizing the MAC address" as an alternative to employing
privacy-enhanced IIDs.

Thanks!

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