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

[Eliot Lear <[e-mail]>]

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.

Eliot