Re: Disabling temporary addresses by default?

[Fernando Gont <[e-mail]>]

On 29/1/20 19:56, Tom Herbert wrote:
> On Wed, Jan 29, 2020 at 3:49 AM <[e-mail]> wrote:
>>
>>>> Enterprises use web proxies and SSL intercepting gateways anyway, don't they (sigh).
>>>
>>> Some do. I've worked places that did for non-SSL. Keep in mind the operator of that network tends to only allow devices managed by them so they are not user devices. A user generally has no right to privacy on equipment they do not own.
>>>
>>> (This is a controversial position to state in the IETF but is still valid).
>>
>> And just to be clear. I am not against a document specifying temporary addresses.
>> The IETF published RFC3041 back in 2001, as a response to information leakage caused by EUI-64 based IIDs.
>> Quite a lot has changed since then. I am trying to get some answers to the following questions:
>>
>>   - what are the operational consequences of temporary addresses
>>   - how effective are temporary addresses in making correlation harder?
>>   - are applications clever enough to not re-use tainted addresses for example?
>>   - do protocols like ICE, MPTCP, QUIC bundle together stable and temporary addresses?
>>   - implementations that allow for the use of many addresses might get into trouble with the network,
>>     can they deal with those failure cases in an acceptable way?
>>
>> 4941bis is being demoted to proposed standard. Which means we might live with these questions being unanswered, but I think we need to have some of the discussion around these in the deployment considerations.
>> And the issues with temporary addresses might still warrant that we keep the general recommendation of off by default. TBD.
> 
> Ole,
> 
> I agree these are important questions, I would also add that there
> should be more discussion and analysis as to the real effect that
> temporary addresses has had on privacy in addressing-- specifically,
> whether temporary addresses as defined in RFC4941 has sufficiently
> addressed the problem posed in the Problem Statement (section 1.2 of
> that RFC).

We devoted the whole RFC7721 to that.

-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492