Re: Disabling temporary addresses by default?

[Fernando Gont <[e-mail]>]

On 28/1/20 14:46, Gyan Mishra wrote:
> 
> 
> On Tue, Jan 28, 2020 at 12:11 PM Fernando Gont <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     On 28/1/20 13:27, Christian Huitema wrote:
[....]
>      > That seems plausible, but how about going one step further and
>     for clients just have one temporary and one deprecated address,
>     without any stable address? If the client is not running any server,
>     that makes address management much simpler.
> 
>     rfc4041 bis already allows for that.

FWIW, this was a typo (I meant "RFC4941").


> 
>     The only thing is that if the Preferred Lifetime is 1 day, and Valid
>     Lifetime is 2*Preferred Lifetime, and you only do temporary addresses,
>     then your sessions (e.g. SSH) cannot span past one day, *unless* we
>     recommend that invalid addresses are still okay for established
>     connections.
> 
>     The main reason this topic comes has up is due to possible impact of 
> usage of the temporary address when it gets deprecated with long lived 
> session. 

BUt the problem is not in RFC4941, but in the lack of an API for apps to 
specify the properties they expect from the underlying addresses.


>  That’s the crux of why this topic is critical and has severe 
> operational impact. When the address changes for long lived connections 
> from the deprecated temporary address to the new preferred address, the 
> session would terminate and have to re-establish, which is impacts the 
> user. 

If anything, the session would break when the address becomes invalid 
(the Valid Lifetime" expires) -- not when another address becomes 
"preferred".

That said, one can always recommend or give the option to maintain 
established sessions that employ invalid addresses.



> Maybe a change to the behavior as how this works is that the long 
> lived flow remains active on the deprecated temporary address 
> indefinitely until the flow is terminated via graceful TCP close.

You don't need to care about TCP state. Just check if there's a PCB 
associated with the address (whatever the upper protocol is).


>  This 
> would allow us to maintain privacy extension temporary address enabled 
> by default change to benefit privacy advocates and also eliminate impact 
> for enterprise users where availability and stability is utmost 
> importance.  The second issue is maintaining of a multiple addresses on 
> the end host from an operations perspective if that can be limited.  One 
> idea to accomplish this is that if the privacy temporary address is 
> enabled by default, that is if we are able to resolve the operational 
> impact of long lived sessions when the temporary address changes - how 
> can we minimize the number of active addresses per RA slaac address.  
> Allow the interface stable random address to be active only if the 
> temporary privacy address is disabled - non default scenario. 

That's not correct: the stable address is there for a reason: e.g. 
receiving incoming connections.


>  Once the 
> temporary address is enabled default scenario- and preferred, it is now 
> used for both incoming and outgoing connections and the interface 
> “stable” random address is now disabled.

Quite the contrary: if possible, you would *prevent* incoming 
connections on temporary addresses. -- e.g. there's no reason to allow 
port-scans on your temporary addresses just because you happened to 
communicate with a rogue web site.

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