Re: rfc4941bis: Invalid addresses used by ongoing sessions

Mark Smith <markzzzsmith@gmail.com> Tue, 11 February 2020 09:55 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 1E3CF120220 for <ipv6@ietfa.amsl.com>; Tue, 11 Feb 2020 01:55:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.501
X-Spam-Level:
X-Spam-Status: No, score=0.501 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, FREEMAIL_REPLY=1, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, 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 SoawNtm-BUsO for <ipv6@ietfa.amsl.com>; Tue, 11 Feb 2020 01:55:45 -0800 (PST)
Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 48B9E1201E0 for <6man@ietf.org>; Tue, 11 Feb 2020 01:55:45 -0800 (PST)
Received: by mail-oi1-x233.google.com with SMTP id c16so12246441oic.3 for <6man@ietf.org>; Tue, 11 Feb 2020 01:55:45 -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=+F0+Vz97A7A8dWlKM1quQNmMtI4IVdxmGr6jEMhv960=; b=ljWwyBgyGPjRbkoeq7iV+iJ4QmjSLc6+Ndi9f/yovDuYMZx3aQBUd5snW9luPTkrye gUV2NTMj7jMj2vY+VGH5PkfVabis1jnDDKxExRsF039BdWaM9oW2/eO4EZAvco/cthp0 30xFnTxl3vKak9JLchz5QMMJBHVai+9NA4ao6RrhDOcKkJxw+8og3jNKuGq9fSEVwlcp 8NGyOgZ1OsaR8CoZInPXCnxahZTziyxdQWqV6SA+S47/zggeBNhzKHljeO3cfZ2vLfbc sglwVuUhGH6Wg1utyEM+jJAnu1TlM5FYr+58uMijw3hoVv5yHo8fnuVKDKVmcIeUGG9e E5pA==
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=+F0+Vz97A7A8dWlKM1quQNmMtI4IVdxmGr6jEMhv960=; b=AYvCBlqFtVqNymOxU9I3zV2YFekItlxXXCAW9okDwu4ddzCyhfTrT2Fm+vs7mbHT5J ezclZh1+nGxw1DwBK7aq0gtgXepO5azwx8HSx432HjEw/Csqdu8n3rz94Q9c1EYZlJ4v qKszKWGX2I1hYJEcKigGi8/W2Zujsv0HdRLz7V4uYHqUy/hqdrUXiKdM8BTLt+miQGu8 sYRxQirLrovmssHUXTDhlY3cEU00AzvJutwsqFrzHmK/Uci+xksL4IeX4PA6S0Zkxo5f kceKfDfdz3CSKCIQ9B8WpMYw72iH0gxqnpdhd1EewonPsmrrogZ8CMq1UT2vREWhFFAt Qibg==
X-Gm-Message-State: APjAAAXAJoCdscWUVuua7FxLXbIGieT1qcT0mKuWNzaf/wW8xOhVmjWv 3sbyARKjcqiXzrQTR743yXNHo+65i//eytsasZQ=
X-Google-Smtp-Source: APXvYqwvh1x6pgi9EieaD8jyLuszP7Cd8lXKBIJhthQeeBBUivvYaVNx+bgzLaISELbbBoKhR2S/ESUXau5LxJtbh7o=
X-Received: by 2002:a05:6808:99c:: with SMTP id a28mr2228745oic.164.1581414944506; Tue, 11 Feb 2020 01:55:44 -0800 (PST)
MIME-Version: 1.0
References: <c6ba9a00-cb44-2022-5009-34211966518c@si6networks.com> <CABNhwV0mb8dL_4Ef5UxAbcRbP18nH9Ztvx8XHJ0Z0GM-NaCwgw@mail.gmail.com> <CAO42Z2zB6gpKwZ=DfRVEbURNyKPJWAOqLqrFvW8T_uc59=9tiw@mail.gmail.com> <675eba6f-942e-82d9-e28d-de960d36d3b2@si6networks.com>
In-Reply-To: <675eba6f-942e-82d9-e28d-de960d36d3b2@si6networks.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Tue, 11 Feb 2020 20:55:17 +1100
Message-ID: <CAO42Z2wrSZEoSKuSeo0iTLpc6ybSheQN=ba9G02OY2XvZscEOw@mail.gmail.com>
Subject: Re: rfc4941bis: Invalid addresses used by ongoing sessions
To: Fernando Gont <fgont@si6networks.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, 6MAN <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/U5y62g1fUvCFbFjbkO-dGqTtBVo>
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, 11 Feb 2020 09:55:47 -0000

On Tue, 11 Feb 2020 at 16:16, Fernando Gont <fgont@si6networks.com> wrote:
>
> On 10/2/20 23:25, Mark Smith wrote:
> >
> >
> > On Tue, 11 Feb 2020, 13:13 Gyan Mishra, <hayabusagsm@gmail.com
> > <mailto:hayabusagsm@gmail.com>> wrote:
> >
> >
> >
> >
> >     On Mon, Feb 10, 2020 at 11:12 AM Fernando Gont
> >     <fgont@si6networks.com <mailto:fgont@si6networks.com>> wrote:
> >
> >         Folks,
> >
> >         As currently specified, temporary addresses are removed when
> >         they become
> >         invalid (i.e., the Valid Lifetime expires).
> >
> >         Section 6 ("6.  Future Work") of the draft
> >         (https://tools.ietf.org/id/draft-ietf-6man-rfc4941bis-06.txt) still
> >         keeps the following text from RFC4941.
> >
> >         6.  Future Work
> >
> >             An implementation might want to keep track of which
> >         addresses are
> >             being used by upper layers so as to be able to remove a
> >         deprecated
> >             temporary address from internal data structures once no
> >         upper layer
> >             protocols are using it (but not before).  This is in contrast to
> >             current approaches where addresses are removed from an
> >         interface when
> >             they become invalid [RFC4862], independent of whether or not
> >         upper
> >             layer protocols are still using them.  For TCP connections, such
> >             information is available in control blocks.  For UDP-based
> >             applications, it may be the case that only the applications have
> >             knowledge about what addresses are actually in use.
> >         Consequently, an
> >             implementation generally will need to use heuristics in
> >         deciding when
> >             an address is no longer in use.
> >
> >
> >         I wonder if this text should be:
> >
> >         1) moved more into the body of the document and made a "MAY"
> >         (which for
> >         TCP is very straightforward),
> >
> >         2) Be left "as is", or,
> >
> >         3) Removed from the document
> >
> >
> >         The implications of #1 above is that it can't prevent long-lived
> >         connections that employ temporary addresses from being torn
> >         down, at the
> >         expense of possibly increasing the number of concurrent IPv6
> >         addresses.
> >
> >
> >        Gyan> So for TCP apps it maybe easier to track via active TCB
> >     blocks so those long lived connections could be tracked.  So those
> >     long lived TCP connections would not be impacted and torn down.
> >     Other apps using UDP may not be as easily tracked and so maybe using
> >     the deprecated address, however due to difficulty of tracking maybe
> >     torn down as a side effect of option #1.
> >
> >
> >
> > Long lived connections using temporary addresses should not be a
> > consideration, because long lived connections should not be using
> > temporary addresses.
> >
> > "Temporary" and "long lived" (persistent, stable) are opposites that can
> > never be resolved.
>
> In that case, would you go for #2 above?

Probably #2, although mainly because that text is in RFC 3041 and it
hasn't caused issues since. I'm wondering if all the possible
scenarios and consequences have been thought through though.

> And, what's your position
> regarding reducing the preferred and valid lifetimes?
>

I'm generally okay with the existing defaults, and would probably only
change them if there is a specific reason to.

If I was choosing the values today, I think I would have chosen 6
hours for the preferred lifetime, and 24 hours for the valid lifetime.

I would consider an application's connection that persists longer than
24 hours to be "long lived", and I don't think the sort of devices
where temporary addresses provide the most privacy value (e.g.
end-user PCs, smartphones etc) are likely to have application
connections that are going to persist for more than or even close to
24 hours. It's unlikely that these devices maintain a connection to
the same network for more than 24 hours e.g. they go to sleep
disconnecting from the network, or get taken somewhere else etc.

Humans have to sleep once every 24 hours, so having a "new identity"
i.e. IID within a prefix each day would sound to me to be a reasonable
default.

The current values are probably quite conservative because of the
context  - these original RFC3041 defaults was IIDs that persisted as
long as the network card's hardware address existed - probably 3 to 5
years typically, although possibly much longer (there's a 20 year old
100Mbps NIC in this 11 year old PC for example!). Reducing the
persistence of a node's interface IID value from many years down to 1
week was a very significant privacy improvement.

TL;DR, leave as they are just because there doesn't seem to be a
strong reason to change them.


Regards,
Mark.














> Thanks!
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>