Re: Consensus call on adopting: <draft-gont-6man-stable-privacy-addresses-01>

Fernando Gont <fgont@si6networks.com> Sat, 21 April 2012 15:43 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 61AE721F8611 for <ipv6@ietfa.amsl.com>; Sat, 21 Apr 2012 08:43:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 usa3owcaDR78 for <ipv6@ietfa.amsl.com>; Sat, 21 Apr 2012 08:43:23 -0700 (PDT)
Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 45FC521F860D for <ipv6@ietf.org>; Sat, 21 Apr 2012 08:43:19 -0700 (PDT)
Received: from [2001:5c0:1000:a::703] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <fgont@si6networks.com>) id 1SLcSr-0001T9-71; Sat, 21 Apr 2012 17:43:09 +0200
Message-ID: <4F92BDF0.4080604@si6networks.com>
Date: Sat, 21 Apr 2012 11:02:24 -0300
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: Mohacsi Janos <mohacsi@niif.hu>
Subject: Re: Consensus call on adopting: <draft-gont-6man-stable-privacy-addresses-01>
References: <E7607B61-9889-43A9-B86B-133BD4238BA2@gmail.com> <4F87DF53.7030009@cisco.com> <4F881C9A.3050908@si6networks.com> <4F8E8B75.4030605@cisco.com> <4F8EE130.8070903@si6networks.com> <4F901471.3070802@cisco.com> <4F9072E5.7060906@si6networks.com> <CAAVMDnXLoKFsHYvav+Yd8puo9ePEcPvKSZYsyv9=GzRcODHopw@mail.gmail.com> <alpine.BSF.2.00.1204201400580.40024@mignon.ki.iif.hu> <4F91ACB3.2030901@si6networks.com> <alpine.BSF.2.00.1204211015460.40024@mignon.ki.iif.hu>
In-Reply-To: <alpine.BSF.2.00.1204211015460.40024@mignon.ki.iif.hu>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, IPv6 WG Mailing List <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, Eliot Lear <lear@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: Sat, 21 Apr 2012 15:43:28 -0000

On 04/21/2012 06:10 AM, Mohacsi Janos wrote:
>>> The client application
>>> based on the policy should pick pivate or EUI-64 addresses.
>>
>> Just curious: Is there a specific use case for IEEE-derived addresses
>> that cannot be satisfied with draft-gont-6man-stable-privacy-addresses?
> 
> The existing implementations. The most important factor of introduction
> of new standards to interoperate the existing ones. I think this should
> be documented in your  draft. 

Could you please clarify what you're referring to, specifically? --
i.e., this address generation mechanism is backwards-compatible.



> Furthermore there are several firewalls
> and monitoring tools which is generating warning in case of IEEE-derived
> address and MAC mismatch. This has to be investigated and documented in
> the draft.

You mean that updated implementations would automatically generate
addresses differently?

In this case, my take is that *updates* should probably not enable this
mechanism by default, or at the very least have a system toggle to turn
this feature off.

For new devices (i.e., off-the-box rather than software-updated), this
should probably be enabled by default.



>>> I think the proper implementation of RFC 3041 or/and 4941 can solve your
>>> problem
>>
>> I don't follow. RFC 4941 generates addresses in addition to the stable
>> ones, so.. how could they possibly fix the scanning problem?
> 
> I think the stablity/network supervisor ability to track devices is
> enough justification for stable privacy addresses. 

Agreed. But someone might argue that you can achieve this with IPv6
addresses that embed IEEE-identifiers or
randomized-but-stable-across-networks IIDs... but these fail to address
other problems.


> Scanning is not so
> important. I know there are several new techniques - I am warning about
> the possible methods for several years in my presentations.
> http://www2.garr.it/conf_05_slides/j_mohacsi-IPv6_sec.pdf

Will check your slides -- thanks for the pointer!

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