Re: Disabling temporary addresses by default?

Gyan Mishra <hayabusagsm@gmail.com> Sat, 01 February 2020 21:24 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCB31200FE for <ipv6@ietfa.amsl.com>; Sat, 1 Feb 2020 13:24:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lhAO2no4-dg for <ipv6@ietfa.amsl.com>; Sat, 1 Feb 2020 13:24:21 -0800 (PST)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B47212008F for <ipv6@ietf.org>; Sat, 1 Feb 2020 13:24:21 -0800 (PST)
Received: by mail-io1-xd36.google.com with SMTP id z193so12374046iof.1 for <ipv6@ietf.org>; Sat, 01 Feb 2020 13:24:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I4U1KRTx19zKlaQLnDj3WCu2jwYtWH71EhJER55ptkM=; b=T29sfVseJXfaQqOEeKiwkv2GY5rgrC5+gwicE9dwFZWOTTYjly033p81fzojXdctLP FrYeD/kl5sTsZFxXl+S3dYHJ/j/dWBd6xANooyHbEXEWHgbFDceeWnZNKMLAt4mY3Tjh Syjue2d3hIcyyYQ9EaAidsYoZOt63oW189QcZKO3sUWIt2L/VfcaSPx2atod+TnjwYG2 Rx1iFKYlsI0SXUqJy2xv+TBMZh4/v6G+Z6ngBjODqAuHDWxbK0v/00Ucjbn+2CRgG0e4 yp4gbvltGIsZhh18MesjHl1Yvt7phsX8Zd0ODkgzWKPoQg4WnQoG5dqCfp2izJIfyvxR x6sQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I4U1KRTx19zKlaQLnDj3WCu2jwYtWH71EhJER55ptkM=; b=IyQSV5cuV38ZwzV7PvJuQOwe3k49nPzZseW//Ijif6eoW3EEiWQlv6GBuCnJquh90j pmjGj2ibp4aG47Ae4EpVY6ynxObSLuaO8rrGV0SGzXyGgNISNfUceQSI/JEPD0r0mchm xiXfU+mCnLlLUd1nDVrxXlziwWGCjQ3+Lo3y2NTpfEVFiCNTvqbvVwWGRBYvXVser1XI JBI3VzrcKokDF+VvOfcov2cV0bDGHBF6xsy3gr2pQL1tL6vCfjDD1eLFgxrCSrM86P9C dqoexXYP+ZRcX0bJ1JlP1DBt8z1iDYPtOXsV1mm9TziOR63+Q62RN416lPJKuOdA0CpG DKpQ==
X-Gm-Message-State: APjAAAXukj3cxCdzCj5JcWPcCYJBaHsB39m5nXfY1Uwr7MX3HRIIqohd KmKiAF4YANmhdq1vgvXRthBJuhDy8fRNRu6MGKI=
X-Google-Smtp-Source: APXvYqwn8l7UHeFJ3mh59p2bGJA1VIvL3fpDiedXoj/zTTzLvbKtx0ZLQEEntHFZBdcLMizW0T5x/M6ktySVToa4YGc=
X-Received: by 2002:a6b:4e13:: with SMTP id c19mr12907371iob.58.1580592260810; Sat, 01 Feb 2020 13:24:20 -0800 (PST)
MIME-Version: 1.0
References: <CAKD1Yr11_SSUkCBuQ3-h+eRg0LPZQdhe+h7f0YZy9TiyRWj6mw@mail.gmail.com> <751D59E0-F60B-4FE1-840F-3FEAB82F618F@huitema.net> <c058863d-9e29-3ddb-a020-0ebadef26ad4@si6networks.com> <CABNhwV0KsKN7LQY2D-BJkCtvB40oZCT65EmOCr0oE56c9g7-aQ@mail.gmail.com> <CAKD1Yr05GqFr1r018qHZev8SB6Gd=zm_45TtuShQH_5PVkXpKw@mail.gmail.com>
In-Reply-To: <CAKD1Yr05GqFr1r018qHZev8SB6Gd=zm_45TtuShQH_5PVkXpKw@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sat, 01 Feb 2020 16:24:09 -0500
Message-ID: <CABNhwV2=TPU+CQ1zBu58DmRD7i3=tBsdZvuOxuaS_jQLZ-ebBw@mail.gmail.com>
Subject: Re: Disabling temporary addresses by default?
To: Lorenzo Colitti <lorenzo@google.com>
Cc: 6man WG <ipv6@ietf.org>, Christian Huitema <huitema@huitema.net>, Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary="0000000000003d8fde059d8a502b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/TTcBWlQNOUQ-nISAds6mn4cPUaQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Feb 2020 21:24:24 -0000

On Wed, Jan 29, 2020 at 6:13 AM Lorenzo Colitti <lorenzo@google.com> wrote:

> On Wed, Jan 29, 2020 at 2:46 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>>    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.  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 there is a permanent address as well, then an application that is not
> able to deal with session resets (like SSH) can use
> the IPV6_PREFER_SRC_PUBLIC socket options to use the permanent address
> instead.
>

    See section 5.  A lot more needs to be done as far as API development -
https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations-04#section-5



>
>> 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.
>>
>
> But don't enterprises care about not leaking the habits of their
> employees? If I was on an enterprise security team, I would be pretty
> concerned about the levels of leakage and cross-site tracking that are
> enabled by never changing the IPv6 addresses of a host. This doesn't happen
> in IPv4 because we use NAT, but it will definitely happen in IPv6.
>

   From an enterprise IT perspective network access is all monitored at the
application layer with content filtering blocking URI access.  So the
anonymity or privacy concerns for an individual at home connected to the
internet at home is an IETF objective to maintain per RFC 7258 pervasive
monitoring.  That same objective does not exist for enterprise IT hosts.
In most if not all cases, the endpoint host is owned by the company and has
monitoring software loaded to maintain IT security, and ensue security
patches levels are up to date on endpoints, as well as web content
filtering and restricted access to install or remove software.  For BAU
IPv4 connections on a corporate intranet the IPv4 address is stable and not
changing.  With IPv4 Nat is only used for “hide Nat” to hide internal space
and use of web proxy.  For internal communications within a corporate
intranet Nat is used when address overlap exists. Even with IPv6 6to6 Nat
and is employed within the DMZ for “hide Nat” to eliminate attack vector
from any external entity extranet or internet.  As well as 6to6 web proxy
for internet web access.  From an IT operations perspective, as far as
IPv6, limiting the number of addresses on the endpoint for MTTR ( mean time
to recovery) for availability is the primary objective for an enterprise.
Stable random IPv6 address works best to meet the objective of an
enterprise.

> --

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com