Re: Disabling temporary addresses by default?

[Fernando Gont <[e-mail]>]

On 29/1/20 08:48, [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

I proposed a paragraph about this one.


>   - how effective are temporary addresses in making correlation harder?

They limit the lifetime of the address, and in doing so the limit the 
amount of time that network activity correlation can be performed.



>   - are applications clever enough to not re-use tainted addresses for example?

This is out of scope for rfc4941bis. We raised this here 
https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations 
. I presented in 6man, and the suggestion was that this belonged 
elsewhere. Maybe it's time to work on it?




>   - do protocols like ICE, MPTCP, QUIC bundle together stable and temporary addresses?

At the very least, temporary addresses came way before MPTCP and QUIC. 
So I think this is out of scope for this document. -- it *might* be in 
scope for draft-gont-6man-address-usage-recommendations


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

Maybe this was in scope for RFC7934? -- That's the RFC that says host 
should be free to employ addresses as they wish. If anything, RFC4941 is 
below the umbrella of RFC7934.



> 4941bis is being demoted to proposed standard. 

As a non-native English speaker, I had to look up what "demoted" means. 
The dictionary says "move (someone) to a lower position or rank, usually 
as a punishment".

You can argue that in terms of rank, it has been lowered (does anybody 
care?). However, it worries me the idea that addressing flaws in a 
protocol is a kind of punishment.



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

I think discussion does not belong here (other than the note about 
possible effects of many addresses). The topic is a much larger topic, 
and involves many other aspects. Please see: 
draft-gont-6man-address-usage-recommendations

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