Re: rfc4941bis: Change to Valid Lifetime of temporary addresses

[Gyan Mishra <[e-mail]>]

On Thu, Jan 30, 2020 at 5:27 PM Fernando Gont <[e-mail]> wrote:

> Folks,
>
> It has been suggested by Lorenzo Colitti, David Farmer, and others, to
> change the default Valid Lifetime of temporary addresses.
>
> Namely, to change it from the current (RFC4941) "one week", to "two
> days". This indirectly limits the maximum number of temporary addresses
> employed by hosts. (2, compared to the current 11 (as per RFC4941)).
>
> This requires these changes:
>
> * Section 3.5:
>
> OLD:
>     Because the precise frequency at which it is appropriate to generate
>     new addresses varies from one environment to another, implementations
>     SHOULD provide end users with the ability to change the frequency at
>     which addresses are regenerated.  The default value is given in
>     TEMP_PREFERRED_LIFETIME and is one day.  In addition, the exact time
>     at which to invalidate a temporary address depends on how
>     applications are used by end users.  Thus, the suggested default
>     value of one week (TEMP_VALID_LIFETIME) may not be appropriate in all
>     environments.  Implementations SHOULD provide end users with the
>     ability to override both of these default values.
>
> NEW:
>     Because the precise frequency at which it is appropriate to generate
>     new addresses varies from one environment to another, implementations
>     SHOULD provide end users with the ability to change the frequency at
>     which addresses are regenerated.  The default value is given in
>     TEMP_PREFERRED_LIFETIME and is one day.  In addition, the exact time
>     at which to invalidate a temporary address depends on how
>     applications are used by end users.  Thus, the suggested default
>     value of two days (TEMP_VALID_LIFETIME) may not be appropriate in all
>     environments.  Implementations SHOULD provide end users with the
>     ability to override both of these default values.
>
>
> * Section 5:
>
> OLD:
>     TEMP_VALID_LIFETIME -- Default value: 1 week.  Users should be able
>     to override the default value.
>
> NEW:
>     TEMP_VALID_LIFETIME -- Default value: two days.  Users should be able
>     to override the default value.
>
>
> Comments? Objections?


   Since we are proposing change of valid lifetime from 2 to 1 why not make
the valid lifetime 1 day as well - same as the preferred.  The historical
deprecated value would not exist and now there would be 1 less address on
the host to troubleshoot.

When you increase the valid lifetime the user can see his previous stare of
the address.  Most users would not be able to understand what is meant by
preferred or deprecated address.  I am not sure what is gained from an end
user standpoint whom most likely will not be network savvy.


Also from a network standpoint the operator for enterprises as well as
service providers save the ND cache for troubleshooting to fire devices
historical data so even if the address changes every day the operator can
determine all the address the host as used during the tracking cycle before
the database rolls over which varies.  Operators have direct access to the
network elements so the ND cache monitoring is at their fingertips.  The
main thing post Snowden era that privacy advocates are concerned about is
address correlation and monitoring done by LFA.   In order for enterprise
or service provider operators to manage the network monitoring is a must as
all links or aggregation points  are tapped so all flows can be monitored.
This is built into the OPEX cost to run a network.  A side effect to that
monitoring is now LFA can obtain FISA warrant for monitoring.  The data is
already present as operators require to save the data for troubleshooting
to provide customer SLA’s.

I think for troubleshooting and MTTR that enterprises require and use a
stable random address for troubleshooting by disabling the temporary
address for the “long lived” flows where the endpoint permanently always
remains in the office connected to the corporate intranet.  So with the new
draft we will still allow disabling the temporary address if desired to
have a stable address.

For enterprise mobile and personal direct internet connection privacy
concerns of address correlation, the temporary address would be enabled by
default and kept enabled as the recommendation. So this use case would use
the temporary privacy address privacy with valid and preferred lifetime
equal set to 1 day.  There would not be any deprecated addresses.


What do you think?

Any downside to doing so?

>
>
> Thanks!
>
> Cheers,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]