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

Eliot Lear <> Thu, 19 April 2012 13:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08C3421F862A for <>; Thu, 19 Apr 2012 06:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.349
X-Spam-Status: No, score=-110.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BiQjv3dVBlWa for <>; Thu, 19 Apr 2012 06:34:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6A07821F861A for <>; Thu, 19 Apr 2012 06:34:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3468; q=dns/txt; s=iport; t=1334842473; x=1336052073; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=25iARqD+7lB5SeUDEgPJFp2VnJV50LSUEaoCL6uaGwg=; b=GO5ddtVDACFO2e4rQJ0XeAqntjr3Rt2w1OiEc/xhHSPMqRrpYrGxz1Gd /YTVlVdQwtvUl5rGtwz6Y95C7T4EWrk4SHSYOVdpT8Hwo8Y3rqqe5Hw0W 2pHO4YUHeWFIhL8NFljaAUEBqqkwMzqTMK0dhql5pp1hgbkp3TBoyrVPz 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.75,446,1330905600"; d="scan'208";a="71281000"
Received: from ([]) by with ESMTP; 19 Apr 2012 13:34:30 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id q3JDYUsr001963; Thu, 19 Apr 2012 13:34:30 GMT
Message-ID: <>
Date: Thu, 19 Apr 2012 15:34:41 +0200
From: Eliot Lear <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Fernando Gont <>
Subject: Re: Consensus call on adopting: <draft-gont-6man-stable-privacy-addresses-01>
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: 6man Chairs <>, IPv6 WG Mailing List <>, Bob Hinden <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Apr 2012 13:34:38 -0000

On 4/18/12 5:43 PM, Fernando Gont wrote:
> 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.

Well, host scanning at least.  Host tracking depends on the implementation.

> 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.

I know what you mean.  That matters less than how other people make use
of the work.  Believe me I know.  I've got my name on RFC-1918, for
crying out loud.