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

From: Philip Homburg <[email-masked]>
Date: Mon, 14 Dec 2020 12:04:00 +0100

>So we're back to each host deciding on the security policy for the network - n
>ot a network admin (as a proxy for the owners of the site/network).
>
>I make a point of disabling upnp as one of the first steps when setting up a n
>etwork. Who wants ${random device which may or may not be "friendly"} to be ab
>le to determine what traffic is allowed into the network - it's not like there
> is anyone out there in the wild west of the internet who'd have any hostile i
>ntent :-/

There are a numbering of things that could be done:
- Use DHCPv6 IA_NA instead of SLAAC
- Have a provisioning system that provides each host with a static address.
- Bring back EUI-64. For systems with static addresses, EUI-64 works just
  fine.
- Define yet another pseudo-random IID. This time one where the IID remains
  constant over the lifetime of the system.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 14 Dec 2020 10:49:16 -0300

> - Use DHCPv6 IA_NA instead of SLAAC

Could work, but obviously not for Android.

> - 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)

> - Bring back EUI-64. For systems with static addresses, EUI-64 works just

*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.

>    constant over the lifetime of the system.

FWIW, this is what Windows does.

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?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Philip Homburg <[email-masked]>
Date: Mon, 14 Dec 2020 15:41:38 +0100

> Could work, but obviously not for Android.

I assumed he had a server.

> 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.

> address based on a token (this is what windows does). This way the
> IID is stable, but you still mitigate address scans.
> 

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

> 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.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Dec 2020 16:17:28 +1100

Or just use PCP and authenticate the request.

> On 14 Dec 2020, at 22:04, Philip Homburg <[email-masked]> wrote:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]