Re: Address privacy

Gyan Mishra <hayabusagsm@gmail.com> Tue, 28 January 2020 16:26 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 8F392120251 for <ipv6@ietfa.amsl.com>; Tue, 28 Jan 2020 08:26:48 -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 bxhPVQDvlggA for <ipv6@ietfa.amsl.com>; Tue, 28 Jan 2020 08:26:46 -0800 (PST)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 CFBFC12018D for <ipv6@ietf.org>; Tue, 28 Jan 2020 08:26:45 -0800 (PST)
Received: by mail-il1-x12a.google.com with SMTP id f10so11147454ils.8 for <ipv6@ietf.org>; Tue, 28 Jan 2020 08:26: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=pdoOS9PXUt38YEPfyJ1J8I+ennLWhPQWMIz0mUSmVj8=; b=ofzioPKzlvg2Rw4TLrzRuklpYhoqDXtDVOX5SbTQ+03JdMPS4D59q2UQCErLfb11hn EU/PfQlz7hLvzHq/8+tlZ34IPyiNUS51FmPA9gUsPoF1g7/k6le42CtTGHq1uRAxrDdC r4ZsRp9Fs9BqIiIhWYbs3uQQTwztEuP/GHYUdgY95sQCuKzvtTDPpcpSqOx5VaafMQJR /SAvgielvySylIdUpvWuTivzDFBq588FpRsIlS7OCNh/Gv02umgRFxoOXnOslPZ5gUak 5HlFJ4XgeDq0Z7OAuu624YzzfvDGeGL7J9GpDy6+AslEwVjCPNAwCoWmXuBzlB2R1TDd jlSg==
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=pdoOS9PXUt38YEPfyJ1J8I+ennLWhPQWMIz0mUSmVj8=; b=Jgf2bmz7jjD/qp30J7wBSOWFWRYqOPmDR3PXcBFjrgbqe68MWd1wPWkUZDm/4O43QH RHD83U4Fyt4OA5dNMTY0QTEfWjNNdKcn5VWM+7OT8GM/O99hbu9QsdxSpCC8RExd7zmJ MsM7zPvFvoiHSx+71tGYVrxaeJagu/QQZtlh7yws9f46WNqaNZIdhVhBdGU6O9MJEpTD Z4G6MnKti8Otb1Yyj2RUGoWjTtbNV7N1+1GAukPAKCB+TsV9mkqygWjmuwbhcXhzBQkL A/2NZxRVVxkGx8KvHHE/hevTHeD1fWAe5YGS9Z5KMm97HE1fgqwsxp88t/ugSzIAPOni Lsgg==
X-Gm-Message-State: APjAAAWgQthi4+BZ1dEfzegzDonA0krmYRPWxRGSpTAU6MMfYejlu1Ks Vn83uC6AfnEolSp58shgzO4+xrPvQ5InrQCesp/WFIVv
X-Google-Smtp-Source: APXvYqyCIL1psR03rL7AlQeNrqttFJsaJopym2jANcF7XtAxfv67xqgilBiCLX4Bc1Q1FVN/K1PhcF2CG8pGZXBCQx4=
X-Received: by 2002:a92:350d:: with SMTP id c13mr21329917ila.205.1580228804670; Tue, 28 Jan 2020 08:26:44 -0800 (PST)
MIME-Version: 1.0
References: <DB9D43C2-BE65-4DC0-AE25-E62E27569E90@gmail.com> <F5799B90-FE98-4746-9FE7-4F3985997A13@employees.org> <CABNhwV2oCAW7w6oWA7hbTU3SpFcPSVf+naViUxRbiaqy6bZxjg@mail.gmail.com> <9690CBEF-CB61-46BE-ADEC-F9EB2AF97042@employees.org>
In-Reply-To: <9690CBEF-CB61-46BE-ADEC-F9EB2AF97042@employees.org>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tue, 28 Jan 2020 11:26:34 -0500
Message-ID: <CABNhwV2QYHzF8+TKL6OR-zTHog7D-hGeitwZz0UMYCkJ6mAktw@mail.gmail.com>
Subject: Re: Address privacy
To: otroan@employees.org
Cc: 6man WG <ipv6@ietf.org>, Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary="00000000000090f973059d35b053"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8yeolxdqELIjVxGwvtxPgfuBnZM>
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 16:26:49 -0000

Will do.

Kind regards

Gyan

On Tue, Jan 28, 2020 at 3:40 AM <otroan@employees.org> wrote:

> Hi Gyan,
>
> Can you please propose text?
> Either as a pull request against https://github.com/ietf-6man/4941bis
> or as OLD: / NEW: in email.
>
> Best regards,
> Ole
>
> > On 28 Jan 2020, at 09:20, Gyan Mishra <hayabusagsm@gmail.com> wrote:
> >
> >
> >
> > On Tue, Jan 28, 2020 at 2:41 AM Ole Troan <otroan@employees.org> wrote:
> > Gyan,
> >
> > > On 28 Jan 2020, at 08:31, Gyan Mishra <hayabusagsm@gmail.com> wrote:
> > >
> > > Do you think we should start this algorithm vulnerability in RFC
> 4941bis draft?
> >
> > Could you expand a bit more on what you mean?
> > Rfc4941bis already uses different example algorithms for generation of
> random iids than 4941.
> >
> >
> >     I understand the draft discussed various methods of generating IID.
> From an operations perspective of existing deployments of RFC 4941 privacy
> algorithm stating the vulnerabilities that exist with the algorithm
> addition at the top of section 3.2.  Maybe even state to not use privacy
> algorithm.
> > That would be a good segway   into listing alternative algorithm
> examples that can be employed by OS vendors.
> >
> > In Section 8 - Significant changes - maybe we should explicitly mention
> also to not use the original privacy algorithm and to use the alternatives
> algorithms mentioned. I noticed one of the changes in section 8 mentioned-
> is to make the temporary address - enabled - by default.  That will have
> major operational impacts when an address changes occurs for  active
> sessions.   I think if we can figure out a way to improve the robustness of
> the temporary address so that it does not impact existing sessions.  I
> maybe wrong but I thought the way it worked is the temporary address during
> regeneration once the address becomes deprecated, existing sessions
> continue to use deprecated address  for outgoing connections and the newly
> regenerated preferred address is for new connections.  If that is true then
> their should not be any impact during regeneration.
> >
> > 6. Temporary addresses are *not* disabled by default.  ** I really think
> we should keep the temporary address disabled by default**
> >
> > This is an excerpt from RFC 4941 Deployment considerations section.
> >
> >  In addition, some applications may not behave
> >    robustly if temporary addresses are used and an address expires
> >    before the application has terminated, or if it opens multiple
> >    sessions, but expects them to all use the same addresses.
> >    Consequently, the use of temporary addresses SHOULD be disabled by
> >    default in order to minimize potential disruptions.  Individual
> >    applications, which have specific knowledge about the normal duration
> >    of connections, MAY override this as appropriate.
> >
> >
> >  I think RFC 4941 does have room for improvement from an operations
> perspective with the privacy extension many addresses in use per slaac
> address.  In updating the spec with this draft it would be good to come up
> with ways to provide privacy without sacrificing operations with many
> addresses and changing addresses in use simultaneously.
> >
> > Best regards,
> > Ole
> > --
> > 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