Re: rfc4941bis: Change to Valid Lifetime of temporary addresses

Gyan Mishra <hayabusagsm@gmail.com> Mon, 10 February 2020 04:44 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 CC423120096 for <ipv6@ietfa.amsl.com>; Sun, 9 Feb 2020 20:44:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 My5GOqVnXZoI for <ipv6@ietfa.amsl.com>; Sun, 9 Feb 2020 20:44:18 -0800 (PST)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 4D0B9120099 for <6man@ietf.org>; Sun, 9 Feb 2020 20:44:18 -0800 (PST)
Received: by mail-il1-x12b.google.com with SMTP id p8so4591872iln.12 for <6man@ietf.org>; Sun, 09 Feb 2020 20:44:18 -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=EAtoxrVjLaRQIlH94wB3K2zpe2IZvM1ehnMP16mo3mc=; b=uJEiGZZooCuqFJqf8PklTtOB0lfj8098Rl/rm4bpF+1E5okNaAv5FdHYAgsBGt2Bz6 YlNU1th3xSCel1aCpWmLLE55m/ttVzmnjeg3fGt8lUZhgJnJj2y3erSj103xIR6tAixT Odnckgy9Xryp3Z/8IN1u3lCk4koPhcIo1deyQFp1GeBzTgapGnZrMqcAnQcgpazsDfG3 1BUpuIsolzscbVwX4C+kYioNvbCYCe6+gxU79gl9iH+HipfQxSCOgXgfYDAbZHIpSCOE VTn99pSnoPk1w4fdLqfVDN6AeJ1652mR6TIzThiYZ9CC+GW35rOEeUa42SBjdgK8oKqU op4A==
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=EAtoxrVjLaRQIlH94wB3K2zpe2IZvM1ehnMP16mo3mc=; b=CB+NqvP348ECt7kypLfXoq8H1MEcTLAltMKSO8aIuf7bif7kKfs6ppSmCNQm0HpjaV 9Bi6HbwRZDsge+l7OhOvmo8adQW1+TNfYEN7c7z1X8byLrpL5jTfhnmQKTFwrj7xQmui c7vPSOnyfa5JiWTY2RJ76GL1j6UtxbZz+zWnkAVFnap58WZJ/IOoRV6YI7nHvaTSOuwc BPAKIVUIyHPULf9uBw7B6bG1aB6rSOQmllyZbSYGtnYQI/X3jusRotPhOTZvR0FBld0p hMDWq3Exj5UIdkg5/mX4jXqeTFfZ+sOdok0ZY+eX5r9izyXudnMKo8xDsBK0FwHHxWYb zdTg==
X-Gm-Message-State: APjAAAUmtNtCmr/BmBPuhsKnjrIlfIwAxPkaGgqYBN2CfFxtJYUEhub0 3rCjRNSh7lY/X4/UT4EVN3T2+7pRi4E18JFl7l3TVp3H
X-Google-Smtp-Source: APXvYqxEsMlyYiskda6oS6BXKccNX6PkNQlSSZ0rRy7gfnmKz94N/sRkBcm9xykd644xs/z0IS4LW/ZryjkiZZvZE5g=
X-Received: by 2002:a92:af44:: with SMTP id n65mr10252753ili.158.1581309857287; Sun, 09 Feb 2020 20:44:17 -0800 (PST)
MIME-Version: 1.0
References: <9cb65947-f634-e250-bfdc-134cfa2c91e9@si6networks.com>
In-Reply-To: <9cb65947-f634-e250-bfdc-134cfa2c91e9@si6networks.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sun, 9 Feb 2020 23:44:06 -0500
Message-ID: <CABNhwV2CGDCMiKMguk1D-TAk2WDentAY6eo86scgejjkHMOJKQ@mail.gmail.com>
Subject: Re: rfc4941bis: Change to Valid Lifetime of temporary addresses
To: Fernando Gont <fgont@si6networks.com>
Cc: "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000052d4af059e31648f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/WXdaVxgDzRaqu-sG5b1fl3vWF64>
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: Mon, 10 Feb 2020 04:44:23 -0000

On Thu, Jan 30, 2020 at 5:27 PM Fernando Gont <fgont@si6networks.com> 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: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com