Re: rfc4941bis: trying to keep focus

Gyan Mishra <hayabusagsm@gmail.com> Sun, 02 February 2020 01:50 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 298421201C6 for <ipv6@ietfa.amsl.com>; Sat, 1 Feb 2020 17:50:56 -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 wWN1MUmvnHgG for <ipv6@ietfa.amsl.com>; Sat, 1 Feb 2020 17:50:52 -0800 (PST)
Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 C0650120013 for <6man@ietf.org>; Sat, 1 Feb 2020 17:50:52 -0800 (PST)
Received: by mail-il1-x131.google.com with SMTP id o13so9612622ilg.10 for <6man@ietf.org>; Sat, 01 Feb 2020 17:50:52 -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=qTuushiy0kk4ofSmJEmqag1aFSuRnM5AAOhJFPu7J7Y=; b=W8BrJZjnXQ6Daa1D+uDPJolgfxPcXIqyypT6HkMd53esKqBPy3trfwHcoiHqiuTn0B lw+81/UrULJc7vopRzn7gP39EgYFxXZbfp8sUoyZ6aI8JDPC2hnoD83CrXdUFGeZLDBT IQseJhLn5D0nCMRb2lkgp/LFc/LZ4XEW3ALI8i4JiCSAgcMRhZHMI5ZSHP2rK/jVEFz1 A9asawLQeul4hRtYG39f2otLgio4ZwcH8NOpQSSro20h0n2FIBovG3qEqx/9hLZKe9ka hs0ABSFdgrQ9Tfzj2zXNwao/TG7tfd29D01Hv5OaP01G0n87XtGXYbjBk8QCmfHRc9zt lgWw==
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=qTuushiy0kk4ofSmJEmqag1aFSuRnM5AAOhJFPu7J7Y=; b=i1Voiu9Z+d+Qpr5RW7PjxVqDgm5XGzJEwM8Z2/BBOm+7RaobuvaBF9HmZj4MKZ2+41 7xKmz8trE4Em3TTxgybrA+xJhZIE4+sXj27AC104QvZkMobl2//Uco+QnJjjs1J4YWOY w6v/Fb5DXyeHYumHc1PsHsJOJvJLpJXZNGme/OMfG0MeSfJPA1JKc+L+i7MJ0q6/zxUT yf/m1MMrtNtDhjJZ5x3iHMNi/PC9MaIMSRL3TitkyXNLpX5bGAKAkWhFCvrBjVgh2SP+ rf3n4eO0Hb6cH0DXvXRB123x3VIVvPYQZJwAeK6BbnzTIxZfNbl5NZXsZkpf/mHk+KA7 thNQ==
X-Gm-Message-State: APjAAAULKBYfy5XojWbd9ddxuqK/de1nffCGkxaFHr8ob8OnyE2RqrAM teRU/ssfimf85Zq1p4dRTeki/t11749dwabXzE61hrrA
X-Google-Smtp-Source: APXvYqwbyoqqMNOrWsRzMAl9L/+ONckk2XDzkTDaL7daetO4I0E16377/g9aHrRKTrC2f+oZ9aFPvdo8njAkqSM8qW8=
X-Received: by 2002:a92:350d:: with SMTP id c13mr16740692ila.205.1580608251777; Sat, 01 Feb 2020 17:50:51 -0800 (PST)
MIME-Version: 1.0
References: <4085840f-6c30-323a-b2e9-544f1a783103@si6networks.com> <CAKD1Yr1zxX-GM+gg-rsix4fHzfUnpW+SbvFmGmJRSC3jnnAbvQ@mail.gmail.com> <CABNhwV1oyMWw8OGKNnKvE8Fvrao_Rd6LOLMnKUOow3g2nL_6ew@mail.gmail.com>
In-Reply-To: <CABNhwV1oyMWw8OGKNnKvE8Fvrao_Rd6LOLMnKUOow3g2nL_6ew@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sat, 1 Feb 2020 20:31:10 -0500
Message-ID: <CABNhwV07-Htua+=pbP637im1oy1LRf07YgDY_sr=rJCF8JC2EA@mail.gmail.com>
Subject: Re: rfc4941bis: trying to keep focus
To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
Cc: "6man@ietf.org" <6man@ietf.org>, Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary="00000000000060571e059d8e0944"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ozwqaJUxCNTLkNEAZZ969fx_JP4>
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: Sun, 02 Feb 2020 01:50:56 -0000

On Sat, Feb 1, 2020 at 5:20 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
> Fernando
>
> I agree as well with Lorenzo that we should be able to come to consensus
> on moving forward with RFC 4941bis.
>
> I understand that in the post Snowden era that privacy and pervasive
> monitoring is an IETF objective per RFC 7258 that we have to be cognizant
> of across the board.
>
> From a personal privacy perspective use case connected to the internet on
> your home broadband connection or anywhere, you want to limit or eliminate
>  ease of pervasive monitoring ; given that sophisticated pervasive
> monitoring or attacks will require an IPv6 TOR capability or a anonymity
> provider NAT bridge discussed in some of the threads, of course that is out
> of scope for this document but valid concerns.
>
> From an enterprise IT security perspective, with regard to long lived
> connections, we would still have the option to disable the temporary
> address even with RFC 4941bis if you want a “stable” random address.  That
> option could be used if desired,  if the host endpoints are “owned” by the
> corporation and are in fact not mobile and remains permanently in the
> office .  If the employee owned or private mobile endpoint is used at the
> office and taken home or also shared use for “personal” use as well ; the
> recommendation would be to not disable the temporary address.  For all the
> use cases described above, from an operations perspective, limiting the
> valid lifetime down from 7 days to 2 days - drastically reduces the maximum
> number of depreciated addresses from 7 down to 2. That is a huge
> operational gain that will help enterprises as far as troubleshooting and
> availability and MTTR ( mean time to recovery).
>
> Another point as far as “stable” address from an enterprise operations and
> MTTR perspective, even though you could a maximum of 7 temporary addresses
> for outgoing connections, 1 stable for incoming connections, link local for
> ND/RA communications ; total of 9 addresses per RA slaac address-  For
> “client host” only the one (preferred) is used.  There maybe home or
> enterprise use cases where you are sharing your local drive for
> peer-to-peer communications - moreso with home versus enterprise use case.
>
> As a happy medium for the enterprise versus home user connected directly
> to the internet the following:
>
> 1. Temporary address enabled by Default
>
> 2.  Valid lifetime change form 7 to 2
>
> 3.  Allow the ability to disable the temporary address if desired.
>

 I was thinking further about the valid lifetime and other then the user or
network administrator knowing history state values what other use does that
provide.

The preferred life time is the most important from a stable address
perspective as how long an address can be used before it is deprecated.
Also the preferred lifetime provides the privacy temporary address
 expiration time of when the address will change.  So if we make valid and
preferred set to 1 day we would not have any deprecated address and only
one preferred address.

>From an operations standpoint per slaac address we now only have LL +
temporary and stable address a total of 3 at any given time.

What do you think and is that even feasible??


>From a network perspective the ND cache is monitored by the enterprise or
provider perspective in order to meet SLA agreements for 99.99%
availability ; so the operators can correlate your Mac to all your
historical Privacy addresses easily.  For both enterprises and service
providers networks,  all links are monitored and have sniffer active and
passive in line or Y cable sniffer taps which is network engineering
requirement for any network.  This is a requirement for troubleshooting and
being able to isolate rouge ports and partition offenders off the network
by disabling their port.  This is also done by enterprise operators to be
able to monitor employee network activity as the network resources are only
allowed to be used for work related and not personal activity.  Similarly
service provider operators have to monitor all links and ND cache as well
for LFA for criminal activity.  Side effect of that is impacts we have seen
from disclosures from Snowden related to wire tapping and subsequent
publishing of RFC 7258.   So monitoring is always present and has been from
Day 1 and its a requirement that will never go away from a network
engineering and operations perspective.  It’s something we have to be
cognizant off as to reasons why it’s there and not just the “privacy”
aspect that all monitoring is bad and sometimes that should be eliminated
as its an invasion of privacy ; as per reasons given removal of monitoring
will never be possible or an option.

Also no matter how often you change your address lowering the preferred
lifetime, since the ND cache is kept in a database saved ; correlation can
be done to your MAC address easily and all the historical IPV6 addresses
you have ever used.


> Gyan
>
> On Fri, Jan 31, 2020 at 3:44 AM Lorenzo Colitti <lorenzo=
> 40google.com@dmarc.ietf.org> wrote:
>
>> Fernando,
>>
>> I agree with all your points. I don't think it's a good idea to pause or
>> derail this update because of more general concerns that some participants
>> have with temporary addresses in general or with SLAAC in general.
>> Temporary addresses have been extremely widely deployed for many years, and
>> it seems unlikely that we would degrade them to historic, or that
>> implementers would stop implementing them. If there are bugs in RFC 4941
>> that impact user privacy, and we can fix them, then we should absolutely do
>> so, and do so sooner rather than later.
>>
>> Cheers,
>> Lorenzo
>>
>> On Fri, Jan 31, 2020 at 5:51 AM Fernando Gont <fgont@si6networks.com>
>> wrote:
>>
>>> Folks,
>>>
>>> I'm trying to summarize what I've seen as part of the recent discussion
>>> about (or at least triggered by) rfc4941bis.
>>>
>>> First, let me give the (obvious) context:
>>>
>>> rfc4941bis is meant, for the most part, to address flaws in RFC4941 --
>>> RFC4941 is a Standards Track document, already. rfc4941bis is not
>>> proposing or introducing temporary addresses, but simply addressing
>>> flows in the scheme *we already have* (which is widely deployed).
>>>
>>>
>>> Now, let's move to the main topics of this discussion:
>>>
>>>
>>> 1) "temporary addresses results in too many addresses"
>>>
>>> This is not a problem araising from RFC4941, but a problem with SLAAC.
>>> In SLAAC, routers offer network configuration information, and hosts
>>> do... what they virtually please.
>>>
>>> Routers could also advertise many different prefixes on the same link,
>>> leading to many addresses. Hosts could also manually configure lots of
>>> addresses.  An OS might also provide a proprietary interface for
>>> proprietary apps to request "one address per flow".
>>>
>>> Given a sufficient number of prefixes and hosts, this may get to a point
>>> where implementation limits such as the maximum number of NCE may be hit.
>>>
>>> If folks are concerned about the maximum number of addresses that may be
>>> employed in a network (a valid concern), then I guess energy should be
>>> spent on how to address this general issue of SLAAC, *in SLAAC*, as
>>> opposed to simply bother about one of the many possible ways in which a
>>> host may configure addresses.
>>>
>>> I'd note that we have a BCP (RFC7934) about the topic of "number of
>>> addresses". In the typical/default case, RFC4941 will lead to a maximum
>>> of 7 addresses per host. In the context of RFC7934, I guess being able
>>> to handle 7 addresses per host is the least one could expect. I do
>>> understand that some systems can't handle them (given a sufficient
>>> number of hosts). Maybe we need to send a signal to router vendors.
>>> Maybe a few thousand entries in the NC is way too IPv4ish? All these
>>> issues are worth discussing... but they are issues with SLAAC or ipv6
>>> network configuration, and not with RFC4941.
>>>
>>> That said, and given recent feedback, it seems sensible to reduce the
>>> preferred lifetime and valid lifetime of temporary addresses to 1 day
>>> and 2 days, respectively. This would result in one preferred and one
>>> deprecated temporary addresses (as opposed to 1 preferred and 6
>>> deprecated addresses resulting from RFC4941).
>>>
>>>
>>> 2) The value of temporary addresses
>>>
>>> As noted above, one would assume that since RFC4941 has not been
>>> deprecated, there is consensus that RFC4941 provides value in the area
>>> of privacy.
>>>
>>> Everytime you reuse an identifier, it leaks information. Temporary
>>> addresses reduce the address lifetime, and hence limit the amount of
>>> time you reuse an identifier. That's an improvement. And it is a
>>> middleground between not using temporary addresses (and hence resuse the
>>> same identifier forever) or doing "one address per flow" which, while
>>> interesting, would take the number of addresses employed in any network
>>> to another dimension. As such (a middle-ground), it can't be expected to
>>> be perfect.
>>>
>>> Temporary addresses are meant employed for outgoing connections. Maybe
>>> RFC4941 should provide stronger hints or even recommendations that this
>>> use mode is enforced. For connection-oriented transport protocols, the
>>> concept is straightforward. For stateless protocols, not so much.
>>>
>>> But even if this mode is enforced for connection-oriented transport
>>> protocols, this would make temporary addresses reduce host exposure
>>> quite a lot. This is another area where temporary addresses have value.
>>>
>>> That said, I'm not sure to what extent it makes sense to argue about the
>>> value of temporary addresses in the context of *this* document. If we
>>> take the to extreme possible outcomes:
>>>
>>> * we don't publish rfc4941bis, and we keep a flawed RFC4941
>>> * we publish rfc4941bis, and have an improved version of rfc4941
>>>
>>> Only one of these options will improve RFC4941, and none of them will
>>> obsolete rfc4941.
>>>
>>>
>>> 3) Should temporary addresses be enabled by default?
>>>
>>> One would assume that since RFC4941 has not been deprecated, there is
>>> consensus that RFC4941 provides value in the area of privacy.
>>>
>>> In that sense, and in the context of RFC7258, I believe it would be a
>>> hard case to make to have temporary addresses disabled by default.
>>>
>>> I do believe some network might want to disable them. That would require
>>> the network to be able to convey this policy to hosts. This was tried
>>> (draft-gont-6man-managing-slaac-policy) and rejected ten years ago.
>>>
>>> I believe that, at least in the absence of policy, and in the context of
>>> RFC7258, it is sensible for the default to be "on".
>>>
>>> Besides, in a post-Snowden era, I believe we'd nevertheless have a hard
>>> time recommending OS vendors to disable them by default.
>>>
>>> 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
>>> --------------------------------------------------------------------
>>>
>> --------------------------------------------------------------------
>> 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
>
>
>
> --

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com