Re: [v6ops] RFC7217 and flash renumbering and IID change

Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com> Mon, 14 December 2020 14:41 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 152BB3A10F5 for <ipv6@ietfa.amsl.com>; Mon, 14 Dec 2020 06:41:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.401
X-Spam-Level:
X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
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 F0hXmVtRXBgc for <ipv6@ietfa.amsl.com>; Mon, 14 Dec 2020 06:41:44 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0E93A10EB for <ipv6@ietf.org>; Mon, 14 Dec 2020 06:41:43 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kop2j-0000E5C; Mon, 14 Dec 2020 15:41:41 +0100
Message-Id: <m1kop2j-0000E5C@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Cc: Fernando Gont <fgont@si6networks.com>
Subject: Re: [v6ops] RFC7217 and flash renumbering and IID change
From: Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <alpine.DEB.2.20.2012111147020.10335@uplift.swm.pp.se> <28ec97ca-355b-e4d8-200d-1c14160b51c0@si6networks.com> <4AC2A13C-9FE6-4D2C-B14C-D1DCC3169700@thehobsons.co.uk> <m1kole5-0000HWC@stereo.hq.phicoh.net> <7b7803bb-cd05-339c-b072-3435a435d8eb@si6networks.com>
In-reply-to: Your message of "Mon, 14 Dec 2020 10:49:16 -0300 ." <7b7803bb-cd05-339c-b072-3435a435d8eb@si6networks.com>
Date: Mon, 14 Dec 2020 15:41:38 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/EzKuVxlOu_g_oCYOcxltn1p2KWg>
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: Mon, 14 Dec 2020 14:41:45 -0000

> > There are a numbering of things that could be done:
> > - Use DHCPv6 IA_NA instead of SLAAC
> 
> Could work, but obviously not for Android.

I assumed he had a server.

> > - Have a provisioning system that provides each host with a static address.
> 
> This assumes that:  * The firewall can filter based on an address/IID
> token -- which need not be the case * You're only setting rules
> for incoming connections (since temporary addresses will lead to
> changing addresses for outgoing connections)

I assume that the provisioning system would both generate the relevant
part of the firewall config and provide hosts with addresses.
There is no need to assume that addresses have a particular form.

> > - Bring back EUI-64. For systems with static addresses, EUI-64 works just
> >    fine.
> 
> *If* you wanted to do this sort of thing, you could configure the
> address based on a token (this is what windows does). This way the
> IID is stable, but you still mitigate address scans.
> 
> That said, I think EUI-64 are a bad idea.

EUI-64 works very well for this purpose. There is only the scare that you can
find out what hardware the devices is using.

> > - Define yet another pseudo-random IID. This time one where the IID remains
> >    constant over the lifetime of the system.
> 
> FWIW, this is what Windows does.

The question is whether this is also described in an RFC.

> Now, if the goal is to set fw rules for incoming connections, then
> it's likely that you'll access the boxes via DNS names. If the
> address changes, the DNS RRs need to be updated. So the hosts could
> update them, and the fw set the rules on a per-domain-name basis?

If the IID is constant then you can automatically generate a new DNS
zone file and the firewall config.

If the IID is not constant you would have to implement DNS update on all hosts.
And then generate the firewall config from that. So you have quite bit of
extra complexity for no good reason. If you automatically update DNS, then
changing the IID doesn't provide much privacy either. In addition, you don't
want your firewall to depend on whether DNS is working or not.