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

Fernando Gont <fgont@si6networks.com> Wed, 18 April 2012 15:44 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 D259721F85B5 for <ipv6@ietfa.amsl.com>; Wed, 18 Apr 2012 08:44:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[AWL=1.199, 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 K65qUxQXsXl4 for <ipv6@ietfa.amsl.com>; Wed, 18 Apr 2012 08:44:01 -0700 (PDT)
Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 98EF521F8589 for <ipv6@ietf.org>; Wed, 18 Apr 2012 08:44:00 -0700 (PDT)
Received: from [2001:5c0:1000:a::195] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <fgont@si6networks.com>) id 1SKX2t-0000ds-Bs; Wed, 18 Apr 2012 17:43:51 +0200
Message-ID: <4F8EE130.8070903@si6networks.com>
Date: Wed, 18 Apr 2012 12:43:44 -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: Eliot Lear <lear@cisco.com>
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>
In-Reply-To: <4F8E8B75.4030605@cisco.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=UTF-8
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>
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: Wed, 18 Apr 2012 15:44:01 -0000

Hi, Eliot,

On 04/18/2012 06:37 AM, Eliot Lear wrote:
>> On 04/13/2012 10:09 AM, Eliot Lear wrote:
>>> At one point you write that the intent is to replace EUI-64-based
>>> addresses (Section 5).  
>> Exactly.

[Correcting myself]

The intent is to have draft-gont-6man-stable-privacy-addresses used
instead of the IIDs that embed IEEE identifiers.



> Yes, I'm looking at the quoted paragraphs (I'm not quite sure from where
> you're quoting):
>>      As noted in [RFC4941], "anytime a fixed identifier is used in
>>       multiple contexts, it becomes possible to correlate seemingly
>>       unrelated activity using this identifier".  Therefore, since
>>       "privacy addresses" [RFC4941] do not eliminate the use of fixed
>>       identifiers for server-like functions, they only *partially*
>>       mitigate the correlation of host activities (see Section 7 for
>>       some example attacks that are still possible with privacy
>>       addresses).  Therefore, it is vital that the privacy
> 
> And so on.  In essence you set up an argument against 4941 but that
> isn't really your argument for the draft and so I don't really know what
> it's doing there.  

It's not an argument against RFc4941, but rather an argument that even
with RFC4941, you still need to do something about the IEEE-based IIDs.
At the Paris IETF, some folks argued that if you have RFC 4941 in place,
you don't need draft-gont-6man-stable-privacy-addresses. Section 7 of
draft-gont-6man-stable-privacy-addresses (which should be an Appendix,
rather than a section in the main body of the document) illustrates that
that's not the case: even if you're employing RFC4941, you're still
subject to host-scanning attacks and host tracking.

It is *not* an argument *against* RFC 4941, since it *is* valuable to
have addresses that change over time for outging communications.



>But perhaps that's not as important as this:
> 
>>> I am concerned that adopting this
>>> mechanism will make matters worse if this mechanism is being used as an
>>> alternative to CGAs, as opposed to EUI-64s..
>> I don't follow. Could you clarify your concern?
> 
> You argue that this is an alternative to EUI-64s.  

Let me correct myself: this is an alternative to IIDs that embed IEEE
identifiers: The modified EUI-64 format is a general format, and it does
not need to embed IEEE identifiers (for instance, RFC4941 produce
Mod-EUI-64 format identifiers, bu clearly do not embed IEEE identifiers).


> But in practice I am
> concerned that people will not use this as an alternative to EUI-64s,
> but instead as an alternative to CGAs, 

Why?

I don't really follow the relationship of
draft-gont-6man-stable-privacy-addresses with CGAs. CGAs are used for
SEND, and are not even mentioned in this I-D.

How do you arrive to the conclusion that people might want to use this
instead of CGAs??

As noted in the I-D tihs mechanism is meant to be a replacement for IIDs
based on IEEE identifiers. This is orthogonal to RFC4941 and orthogonal
to CGAs.

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