Re: Disabling temporary addresses by default?

[Gyan Mishra <[e-mail]>]

On Wed, Jan 29, 2020 at 6:26 AM Nick Hilliard <[e-mail]> wrote:

> Lorenzo Colitti wrote on 29/01/2020 11:13:
> > But don't enterprises care about not leaking the habits of their
> employees?
>
> This is only a problem in SLAAC environments where privacy addresses are
> turned off.  In DHCP environments, the network operator can change
> endpoint addresses by policy if this is what they want to do.
>

   Gyan> Enterprises fall into a totally different camp altogether as far
as “employee” privacy as that is non existent as all traffic is monitored
to be business related traffic to the extent of web content blocking which
most all companies implement.   The use of temporary addresses does not
make sense for enterprises to employ as operations stability and 99.99999%
available and MTTR( mean time to recovery) is of utmost importance.  By
disabling the temporary address - simplified the enterprise network
troubleshooting tremendously as only a single “stable” random address
exists at all times.  As far as temporary address and “long lived”
connections for enterprise business critical applications that can all be
solved by disabling the temporary address.

RFC 4941bis should have verbiage to that extent something like this below:

Enterprise networks have different requirements for privacy as far as cross
site address tracking correlation, or IID leaking concerns that exist when
connected to the internet.  For enterprises availability and operational
stability and MTTR(mean time to recovery) is of utmost importance.  The
temporary address due to the complexity added with the N= Preferred / Valid
addresses that get generated complicates operations ability to resolve
network issue with the number of active addresses.  It is recommended that
enterprises disable the temporary address as privacy from and end user
privacy standpoint, address correlation is a requirement for IT security.

By adding this text we can exclude “enterprise” from the equation ; thus
the finalized options N=Preferred/ Valid option that Fernando put together
need only address end user privacy when connected directly to the
internet.  Since end user at home broadband or connected to the internet at
a hotspot don’t have to worry as much about business critical applications
that are revenue generating and millions of $$ lost as a result of an
outage.  So the “long lived” connections discussion although it can exist
in a home network, the impact is not the same as with an enterprise.   So
from my standpoint, VPN, ssh or your TV STB disconnecting with “long lived”
connections is not as big a deal as “ip address identity theft”.

I will reply to Fernando’s options separately as if everyone agrees  that
enterprise can be pulled out of the equation it does make it easier to come
up a solution that is truly geared towards “end user” privacy and address
correlation and “ip address identity theft” to commit crimes by address
spoofing your public IP.  This does allow us to play more with the N=
numbers and maybe tweak the default to maximum for end user privacy.

>
> Nick
>
> --------------------------------------------------------------------
> 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]