Re: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS)

Fernando Gont <fgont@si6networks.com> Wed, 22 January 2014 20:49 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E01E1A0214; Wed, 22 Jan 2014 12:49:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 sqPijgsYoKx4; Wed, 22 Jan 2014 12:49:48 -0800 (PST)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id E2A261A0158; Wed, 22 Jan 2014 12:49:47 -0800 (PST)
Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from <fgont@si6networks.com>) id 1W64k5-0000rP-3F; Wed, 22 Jan 2014 21:49:45 +0100
Message-ID: <52E02EAD.1050009@si6networks.com>
Date: Wed, 22 Jan 2014 17:48:45 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Brian Haberman <brian@innovationslab.net>, The IESG <iesg@ietf.org>
Subject: Re: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS)
References: <20140122202434.30069.4084.idtracker@ietfa.amsl.com>
In-Reply-To: <20140122202434.30069.4084.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, draft-ietf-6man-stable-privacy-addresses@tools.ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 22 Jan 2014 20:49:49 -0000

On 01/22/2014 05:24 PM, Brian Haberman wrote:
> 
> I am taking the somewhat curious route of raising a DISCUSS on a document
> that I am shepherding.  I will return to a Yes when these issues are
> resolved.  Thomas Narten raised a good point that this document does not
> mention the work published in RFCs 4436 and 6059 (from the concluded DNA
> WG).  Two of the points he raised are worth addressing in this document
> prior to publication.
> 
> 1. If you have stable storage (and many devices do), it makes sense to
> just cache the addresses instead of
> regenerating them.

1) Recording the addresses a node has visited during its lifetime would
somehow be ironic for a document aiming at privacy. Just get the
document compromised, and you get a list of where the node has been
since it was first installed.

2) Recording the addresses seems like a waste of resources. How many
networks you connect to only once in your lifetime?



> DNA does this. Seems like that option should be
> allowed. (the current document suggests saving the number of DAD
> iterations in stable storage... why do that if you can just save the
> address itself?)

The current document allows that to happen for cases where you find a
colission -- which would be close to nil, given that subnets are /64 and
the IIDs are essentially random.

That said, as an author, I don't expect implementations to record the
dad counter ever, even in the presence of collisions.  I'd argue that
that paragraph is there with this rationale "if you're picky and you're
going to argue that this spec doesn't guarantee a stable IID, you can do
this if you want".



> 2. DNA also has recommendations for detecting when you (re)connect to a
> network you visited before. That is pretty much the same thing this spec
> needs to do in order to generate the same addresses when connecting to a
> previously visited network (i.e., the Network_ID paramater). For the
> wired case (i.e, no SSID), DNA suggests using the linklayer/linklocal
> address pair of routers to identify a link. This document might suggest
> doing the same thing.

IMHO, using the linklayer/linklocal address of the router is not a good
idea. Thing about a replaced NIC,  or a backup router that kicks in in
the event of failuer of the main one.

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