Re: Address privacy

[Fernando Gont <[e-mail]>]

On 28/1/20 05:20, Gyan Mishra wrote:
[...]
> 
>      I understand the draft discussed various methods of generating 
> IID.  From an operations perspective of existing deployments of RFC 4941 
> privacy algorithm stating the vulnerabilities that exist with the 
> algorithm addition at the top of section 3.2.  Maybe even state to not 
> use privacy algorithm.

THat's implied by the fact we are obsoleting RFC4941.




> In Section 8 - Significant changes - maybe we should explicitly mention 
> also to not use the original privacy algorithm and to use the 
> alternatives algorithms mentioned. I noticed one of the changes in 
> section 8 mentioned-  is to make the temporary address - enabled - by 
> default.  That will have major operational impacts when an address 
> changes occurs for  active sessions.

Temporary addresses are enabled by default in a number of popular 
operating systems. So, in a way, rfc4941bis is following deployed 
practice. Besides, disabling them by default in a post-Snowden era would 
be a hard case to make.



>   I think if we can figure out a 
> way to improve the robustness of the temporary address so that it does 
> not impact existing sessions.

THat can be addressed by what's currently in the "Future Work" section.

That said, the "Valid lifetime" is one week. For long-lived connections, 
I'd argue you should be opting out of temporary addresses.



>  I maybe wrong but I thought the way it 
> worked is the temporary address during regeneration once the address 
> becomes deprecated, existing sessions continue to use deprecated address 
>   for outgoing connections and the newly regenerated preferred address 
> is for new connections.  If that is true then their should not be any 
> impact during regeneration.

That's flagged in "future work", but not mandated.




> 6. Temporary addresses are *not* disabled by default.  ** I really think 
> we should keep the temporary address disabled by default**
> 
> 
> This is an excerpt from RFC 4941 Deployment considerations section.
> 
>   In addition, some applications may not behave
>     robustly if temporary addresses are used and an address expires
>     before the application has terminated, or if it opens multiple
>     sessions, but expects them to all use the same addresses.

The expectation for all sessions to use the same addresses would seem 
obsolete these days. Whether because the network employs multiple 
prefixes, and/or because with Happy Eyeballs it's hard to predict what 
you will end up using.



>     Consequently, the use of temporary addresses SHOULD be disabled by
>     default in order to minimize potential disruptions.  Individual
>     applications, which have specific knowledge about the normal duration
>     of connections, MAY override this as appropriate.
> 
> 
>   I think RFC 4941 does have room for improvement from an operations 
> perspective with the privacy extension many addresses in use per slaac 
> address.  In updating the spec with this draft it would be good to come 
> up with ways to provide privacy without sacrificing operations with many 
> addresses and changing addresses in use simultaneously.

Temporary addresses leads to about a dozen addresses per host. That's 
the least one could expect in the context of RFC7934. And in ant case, 
it's a deployed reality.

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