Re: OPS-DIR review of draft-6man-stable-privacy-addresses-16
Fernando Gont <fgont@si6networks.com> Mon, 27 January 2014 22:07 UTC
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC611A0093; Mon, 27 Jan 2014 14:07:45 -0800 (PST)
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 Rhavt6hnqiQD; Mon, 27 Jan 2014 14:07:41 -0800 (PST)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id B3BB91A0068; Mon, 27 Jan 2014 14:07:41 -0800 (PST)
Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from <fgont@si6networks.com>) id 1W7uK6-0006R2-GE; Mon, 27 Jan 2014 23:06:30 +0100
Message-ID: <52E6D7E1.4090007@si6networks.com>
Date: Mon, 27 Jan 2014 19:04:17 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Tim Chown <tjc@ecs.soton.ac.uk>
Subject: Re: OPS-DIR review of draft-6man-stable-privacy-addresses-16
References: <C7046F3A-8C15-4863-9402-A5F6DAEB67BC@ecs.soton.ac.uk> <EMEW3|8f37f1d5d449ce20468ee92a0af181faq0M16n03tjc|ecs.soton.ac.uk|C7046F3A-8C15-4863-9402-A5F6DAEB67BC@ecs.soton.ac.uk> <52E0C6A8.3050503@si6networks.com> <A770E304-C965-4829-8F31-E93D0E7A4564@ecs.soton.ac.uk> <EMEW3|12f5e9bae279fcfd68e300eb7c33b88aq0NHE703tjc|ecs.soton.ac.uk|A770E304-C965-4829-8F31-E93D0E7A4564@ecs.soton.ac.uk> <52E65DE6.3010903@si6networks.com> <6FB21B43-0001-46D7-A57E-2359D819BC4A@ecs.soton.ac.uk> <EMEW3|098bca4b1eaa1178fbc2402cb1bb79e2q0QHBi03tjc|ecs.soton.ac.uk|6FB21B43-0001-46D7-A57E-2359D819BC4A@ecs.soton.ac.uk>
In-Reply-To: <EMEW3|098bca4b1eaa1178fbc2402cb1bb79e2q0QHBi03tjc|ecs.soton.ac.uk|6FB21B43-0001-46D7-A57E-2359D819BC4A@ecs.soton.ac.uk>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Cc: 6man-chairs@tools.ietf.org, ops-dir@ietf.org, ipv6@ietf.org, draft-ietf-6man-stable-privacy-addresses.all@tools.ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 27 Jan 2014 22:07:45 -0000
Hi, Tim, On 01/27/2014 02:11 PM, Tim Chown wrote: [....] >> >> "This document specifies a method to generate Interface Identifiers >> that, subject to a stable interface identifier being available (see >> Appendix A), are stable for each network interface within each >> prefix" >> >> (I've just added a reference to Appendix A, and removed the term >> "constant", based on the discussions we have had for the >> ipv6-addressing-privacy I-D). > > So I think the thing here is that the IID can't be guaranteed to be > stable per prefix, because there are factors that may cause it to > change. The only way to be sure it's stable per prefix is to store > the IID used per prefix, or to find some stateless generation method > for which there can be no change. Storing the per-prefix IIDs > essentially puts a permanent list of all addresses the device has > ever used into persistent storage on the device. Well, strictly speaking, you can never guarantee an IID to be stable: since you're required to do DAD, even with the traditional SLAAC you might find a collision. Even if you record the addresses, the same applies. My take is that, one way or another, you can always find some stable-enough Net_Iface parameters that leads to a pragmatically stable IID. >> Rather than enumerating the cases, I'd probably add a "disclaimer" >> in the Intro. How about this improved version of the text: >> >> "Since different implementation are likely to use different values >> for the secret_key parameter, and may also employ different PRNGs >> for F(), and different sources for the Net_Iface parameter, the >> addresses generated by this scheme should not expected to be >> constant across different operating system installations. For >> example, a host that is dual-boot or that is reinstalled may result >> in different IPv6 addresses for each OS and/or installation." > > Well, I'm not making this as a blocking comment, I'm just suggesting > that a (sub)section that itemises the reasons that the "stable" > address per prefix may not be stable would be a useful thing to have > in the table of contents. My take is that such section is doomed to have an errata. :-) Thus why I suggest a clarification of "don't expect the IID to remain constant across OS installations... even if re-installation of the same OS). Having some sort of stable Net_iface is a requirement for this spec. It doesn't matter which one you choose... as long as it is stable. >>>>> 4. The draft talks (in one place in Section 3) about stable >>>>> privacy addresses being allocated by DHCPv6; some further >>>>> discussion of how this might be achieved may be useful given >>>>> the secret key is presumed to be generated on and reside on >>>>> the host, not the DHCPv6 server. Or would this be described >>>>> in a separate future draft? >>>> >>>> Yes, a future draft -- e.g. where the algorithm is computed by >>>> the DHCPv6 server. >>> >>> So one thing to consider here is that unless the 'secret_key' is >>> shared/copied between the host and the DHCPv6 server, a subnet >>> which changes to/from DHCPv6 to/from RAs for address >>> configuration will see the IID change. Maybe this is a third >>> case of the above... >> >> I kind of think of DHCPv6 as a different world and "out of scope". >> But please let me know if you think otherwise... > > The title of the document is clearly stating this is a SLAAC method, > so there's no need to discuss DHCPv6. But I would say that some > networks will run SLAAC, and some DHCPv6, and that choice might > change over time, so there is an issue as to whether the secret_key > is held only on the host, only on the DHCPv6 server, or if there's > some method to share them. So far, there's nothing like that. And while this document mentions DHCPv6, the idea is "this might be ported to DHCPv6 in some future document". > Another thing to consider operationally is the scope of where the > stable privacy address is used. If you really wanted to guarantee a > stable privacy address per subnet within a single enterprise, and you > had administrative/policy control of the hosts, you might want to > have a configuration knob to turn on storage of per-prefix IIDs for > prefixes belonging to that site. Similarly some administrators might > turn off IPv6 Privacy Addresses where they have managed devices > within an enterprise to ensure their devices use stable IPv6 source > addresses. I guess this type of consideration is probably best aimed > at your other usage draft though... Agreed. FWIW, I should say that previous attempts to do that for SLAAC have failed (e.g. <http://tools.ietf.org/id/draft-gont-6man-managing-slaac-policy-00.txt>). Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
- OPS-DIR review of draft-6man-stable-privacy-addre… Tim Chown
- Re: OPS-DIR review of draft-6man-stable-privacy-a… Hannes Frederic Sowa
- Re: OPS-DIR review of draft-6man-stable-privacy-a… Fernando Gont
- Re: OPS-DIR review of draft-6man-stable-privacy-a… Tim Chown
- Re: OPS-DIR review of draft-6man-stable-privacy-a… Fernando Gont
- Re: OPS-DIR review of draft-6man-stable-privacy-a… Tim Chown
- RE: OPS-DIR review of draft-6man-stable-privacy-a… Christian Huitema
- Re: OPS-DIR review of draft-6man-stable-privacy-a… Tim Chown
- Re: OPS-DIR review of draft-6man-stable-privacy-a… Fernando Gont