Re: Disabling temporary addresses by default?

Mark Smith <markzzzsmith@gmail.com> Tue, 28 January 2020 18:24 UTC

Return-Path: <markzzzsmith@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 664A1120143 for <ipv6@ietfa.amsl.com>; Tue, 28 Jan 2020 10:24:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Level:
X-Spam-Status: No, score=-0.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 D9u0RWeflFvr for <ipv6@ietfa.amsl.com>; Tue, 28 Jan 2020 10:24:11 -0800 (PST)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 7B877120142 for <ipv6@ietf.org>; Tue, 28 Jan 2020 10:24:11 -0800 (PST)
Received: by mail-ot1-x335.google.com with SMTP id r16so12979586otd.2 for <ipv6@ietf.org>; Tue, 28 Jan 2020 10:24:11 -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=MwfxDR3lULqZjkno345FRH/i8u5dcieP1J3T6u7le2M=; b=grrZbvOw9cofNRSrccVz3Xl0en463XIqzClWWpdDm7B3XkbsQvdfpPczSjWl9091bF aHx2ToykgW0Y/mfewG0rRnc6mviATdhqNAGhDJLL4EsWjc7n4VXsj77JHg8xlkgoeSB8 prk4YrJPViHyzlq3HyhTdXk+8boBYAQoZPAuVHWKAvHhU1APZf3vxaRwCxrUN026eVcI T43sxhGuJR7AeZY4gAndx+TSRYYFo2g9wTDl/iXy99BoextC43YYBYd4A1ILhlHldnyZ YXgFfWLUv0fZ8fq8XzR4nKAuqjZ3bpBsSFnKR8nacpIgY5PZx/hRnf8D6kfQoSd+x7yK vxcg==
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=MwfxDR3lULqZjkno345FRH/i8u5dcieP1J3T6u7le2M=; b=AXSbG6TBonPKz5kb37OPZqB9lDaFKdHGexaLOfGZiJFgz3syxxWrpTitKj0KSeVOyy 0cdXVvKGb8O2UmkV8y4UEiNwckyaBt4fOUXWBRLQxoVvtMlLpmw0WrDnc6BH1XYyzxS4 PcF8LwpafEE9hmZUzg8qi7YwT4W+ilh01mhqguF8MmZiTowZjbjZzgKeVnA7Tfk0C5lc I0f2DLqhPAO94CfDcFpW2rm7c9fSRfodcRqVqk8/iM0f/qdGErtACvPOyz8ZcQe1KjJQ ry++14JXiXM/79s/zIpHCCxS4u3HIdDhtZY/16HRlkHTcjI3kfew0pwZygUvN3ifVpPJ Xgyw==
X-Gm-Message-State: APjAAAX/bbdWCOFfDaRVfIGmOu8ZzUia12MczVyfHl2A2MvnyNnlxPrW erP5KycEgcnuzmltsIus0ClXCdknUYtXxtkC42s=
X-Google-Smtp-Source: APXvYqzgp0tGsIQIH+TAmSmxJsVS38Ge/CIAHW5IkMLPvGt6h9vksM6z1UTn84fc8JvvmgWoMA9l7DBnQDEnTnOIcEc=
X-Received: by 2002:a9d:798e:: with SMTP id h14mr16795750otm.257.1580235850538; Tue, 28 Jan 2020 10:24:10 -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>
In-Reply-To: <CABNhwV0KsKN7LQY2D-BJkCtvB40oZCT65EmOCr0oE56c9g7-aQ@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 29 Jan 2020 07:23:58 +1300
Message-ID: <CAO42Z2zzmBGwrEthNP=S0yF+uiUP=88OKRhtXN8L+mtbdGO8rw@mail.gmail.com>
Subject: Re: Disabling temporary addresses by default?
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Fernando Gont <fgont@si6networks.com>, Christian Huitema <huitema@huitema.net>, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000088633f059d3754fa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/MlQChVj4pW_FUnKn8xITVF6POE4>
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: Tue, 28 Jan 2020 18:24:14 -0000

On Wed, 29 Jan 2020, 06:47 Gyan Mishra, <hayabusagsm@gmail.com> wrote:

>
>
> On Tue, Jan 28, 2020 at 12:11 PM Fernando Gont <fgont@si6networks.com>
> wrote:
>
>> On 28/1/20 13:27, Christian Huitema wrote:
>> >
>> > On Jan 28, 2020, at 6:59 AM, Lorenzo Colitti <lorenzo=
>> 40google.com@dmarc.ietf.org> wrote:
>> >>
>> >> Instead of disabling, why not change the default of the number of
>> addresses maintained? For example, instead of maintaining 1 permanent + 1
>> valid + 7 deprecated, why not just default to maintaining 1 permanent + 1
>> valid + 1 deprecated. That means that applications would have to
>> re-establish their connections once a day instead of once every 7 days. But
>> if they use privacy addresses, they already need to re-establish
>> connections after 7 days. And they can always use not to use privacy
>> addresses via the appropriate socket option.
>> >
>> > 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.
>>
>> 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.
>

Devices and their end-users that desire address privacy are unlikely to
have long lived connections.

Can you provide an example of a common long lived connection that would
occur with a laptop or smartphone? I can't think of one.

Even back in the early 1990s, when fixed location desktops were the main
personal computing device, long lived client connections were rare. If you
wanted a reliable long lived connection for something, you didn't use your
desktop, you used the hosts/servers that were in computer rooms protected
by UPS.






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.  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.  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.   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.  This will help from an operations
> perspective that all flows in/out now all use the same privacy address.  We
> can limit the number of temporary addresses to 2 which would only occur
> during transition to the new preferred address.  In a normal state when the
> address has not hit the lifetime expire timer, only a single GUI address
> exists on the host plus the link local.
>
>>
>>
>> --
>> 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
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>