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

Fernando Gont <fgont@si6networks.com> Sat, 14 April 2012 12:05 UTC

Return-Path: <fgont@si6networks.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 D7CF421F8625 for <ipv6@ietfa.amsl.com>; Sat, 14 Apr 2012 05:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 77PzBYDhg3My for <ipv6@ietfa.amsl.com>; Sat, 14 Apr 2012 05:05:30 -0700 (PDT)
Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id D20F821F8618 for <ipv6@ietf.org>; Sat, 14 Apr 2012 05:05:26 -0700 (PDT)
Received: from [83.167.52.94] (helo=[10.255.171.106]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <fgont@si6networks.com>) id 1SJ1j8-0006Wj-La; Sat, 14 Apr 2012 14:05:14 +0200
Message-ID: <4F8967F3.50707@si6networks.com>
Date: Sat, 14 Apr 2012 14:05:07 +0200
From: Fernando Gont <fgont@si6networks.com>
Organization: SI6 Networks
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: Karl Auer <kauer@biplane.com.au>
Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01
References: <E7607B61-9889-43A9-B86B-133BD4238BA2@gmail.com> <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl>
In-Reply-To: <1334363774.3945.541.camel@karl>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: ipv6@ietf.org
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: Sat, 14 Apr 2012 12:05:31 -0000

On 04/14/2012 02:36 AM, Karl Auer wrote:
> On Fri, 2012-04-13 at 15:29 +0200, Fernando Gont wrote:
>> "IPv6 implementations conforming to this specification MUST generate
>> interface identifiers using the algorithm specified in this section in
>> replacement of Modified EUI-64 format identifiers."
>> ?
> 
> While that is good, it would be clearer if it was expanded out to make
> the desired points separately:
> 
>    It is intended that the use of Modified-IEEE interface identifiers
>    be replaced wherever possible by the use of interface identifiers
>    generated as described in this specification.

Shouldn't it be specified with RFC 2119 language?



>    When generating interface identifiers, IPv6 implementations
>    conforming to this specification MUST use the algorithm specified
>    in this section.
> 
>    [I'm not sure this is necessary - it seems to be saying that
>    "conforming implementations have to conform"]

>From my pov, it means that all the algorithm is mandatory (nothing to
add or take out).



>    IPv6 implementations conforming to this specification MUST NOT use
>    Modified-IEEE format interface identifiers [see 4291 Appendix A] for
>    any purpose EXCEPT THAT link local addresses MAY be generated using
>    Modified-IEEE format interface identifiers.
> 
>    [remove everything from EXCEPT THAT onwards if that isn't what you
>    intended]

Yep. I think it would be better to have all IIDs generated with the
algorithm.



>    If for any reason the generation of an interface identifier
>    according to this specification fails, IPv6 implementations
>    conforming to this specification MUST NOT fall back to
>    using Modified-IEEE format interface identifiers.
> 
>    Interface identifiers other than Modified-IEEE interface identifiers
>    MAY be used in addition to interface identifiers generated according
>    to this specification.

Ok, I will add this.


>> It shouldn't be possible. The idea is that the secret key is set to a
>> random number (by default).
> 
> I still think you need a special value for "invalid secret key", so that
> any systems do not have any way to obtain random numbers can refuse to
> autoconfigure if the key is not set.

I'd like other to weigh in on this one. -- I don't think there's a need
for a "invalid secret key". The secret key is supposed to be
generated/selected at installation time. If for some reason such
secret_key cannot be randomly generated, the the OS can prompt the user
for one.


>>> 5: Duplicate address detection is not mentioned explicitly, but probably
>>> should be - what happens if a host does DAD and determines that its
>>> stable address is already in use?
>>
>> Address configuration fails.
> 
> That should be in the spec.

As noted, IIRC this is not clearly defined for traditional SLAAC,
either. So, should we be different in this respect?



>> That said, if deemed appropriate, one could include one additional byte,
>> "DAD" in the hash function, which is initialized to 0, and that is
>> incremented by 1 if the host wants to try a different address if/when
>> DAD fails.
>>
>> If we do that, the implementations should probably cache the resulting
>> address, such that it is stable. (otherwise the resulting address might
>> change if the same node was brought up while the node with the
>> conflicting address is off).
> 
> This may not be possible on systems with no onboard storage, and makes
> things much more complicated. I suggest that if DAD fails, then
> autoconfiguration should just fail (at least as regards stable
> addresses).

This is kind of the way DAD works with traditional SLAAC. However, I'm
not sure whether this is the right approach (to have address
configuration fail as a result of that), or whether it would be better
to have some "backup plan" (even if the address is not stored in on
non-volatile storage). For instance, the IIDs that you generate with
this scheme are not globally unique, and then, probabilistically
speaking, there could be collisions.


>> Actually, this algorithm could still be used with longer prefixes (i.e.,
>> fewer bits for the IID). So I'm not sure whether we should include this
>> requirement. e.g., if we were to eventually allow non-/64 autoconfigured
>> addresses, this algorithm could be use without any changes (while the
>> traditional MAC-based identifiers couldn't).
> 
> I like the 64-bit limitation. Either way it should be made explicit.

Is this made explicit in any RFC for traditional SLAAC addresses?



>> (Note that this is a different issue from item #1 above: Item #1 above
>> is about what you should do if you implement this spec, while the point
>> that I'm making in the previous paragraph is that you SHOULD implement
>> this spec).
> 
> I don't think a spec can mandate it's own use unless it obsoletes or
> updates a spec that mandates something. Your spec would have to update
> 4291, for example, replacing the whole modified-IEEE thing with your
> mechanism. That's a BIG step.

Well, that shouldn't be a big deal, and it would be a big advance. If we
were to pursue that path, it should be a "SHOULD", such that in specific
scenarios or circumstances nodes can still used the MAC-based addresses.



>> Additionally, I'd argue that in order to have such thing, then
>> 1) You'd need to manually configure your address each time you move from
>> one network to another (as with manual configuration requires you to set
>> the whole address, rather than just the IID bits), or,
> 
> No - you could just have a flag that says "the key is the interface
> identifier I want to use - verbatim". 

Sorry, what you put in the key would be used for setting the IID??


> Then that IID gets appended to
> whatever prefix happens along. Obviously this does NOT have the same
> anti-tracking qualities etc, but I can see it being useful. 

What's the use case you have in mind?

Thanks!

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