On Tue, Jul 11, 2017 at 11:08:23AM +0100, Stuart Henderson wrote:
> On 2017/07/11 07:45, Florian Obser wrote:
> > The way I want to move forward with this is:
> > 
> > 1) generate a random key at boot if it's not present yet (like we do
> > for ssh host keys and ipsec)
> > 2) if /etc/netstart brings up an interface set the key there by
> > enabling the feature per default like we do with privacy addresses.
> > NOTE that this does NOT enable v6.
> > If you do not want this you have to put -soiikey into the hostname.if
> > file (like -autoconfprivacy)
> 
> It's slightly different to autoconfprivacy as that is enabled by
> default in the kernel for new interfaces, whereas with this it depends
> on the key being configured. So there are implications for dynamically
> created interfaces (USB, vlan etc) which may not always be handled by
> netstart.
> 
> I'm wondering if we should have a "system soiikey" (e.g. in a sysctl)
> that is automatically applied to newly created interfaces? (Does the
> key even need to be configurable per-interface or would a per-system
> one be enough by itself?)

I was also considering this. A per system key is probably enough.  I
went with the per-interface key because that made it easier to disable
the feature on an interface. If we go with per-system we need a
interface flag to disable the feature (like -autoconfprivacy).

The rfc seems to assume a per system secret.

hmm... are there sysctls that are only readable as root?

> 
> > 3) if v6 is enabled in hostname.if you get a random but stable link
> > local address according to RFC 7217.
> > 4) if autoconf6 is enabled on the interface slaacd will generate a
> > random but stable global address according to RFC 7217
> > 
> > Also note that RFC 8064 is a thing and we are kinda supposed to do this.
> > Also I think it's a good idea[tm].
> > 
> > Comments, OKs?
> 
> A couple of other comments:
> 
> - system administrators should know in advance of updating that their
> IP address may change in case they need to prepare for it (adjust
> firewalls/nat-pt/proxies).

sure, /me glances at current.html

> 
> - ramdisk upgrades may need to load the key from the installed system
> (e.g. in presence of restrictive firewall policies).
> 

good point

> - a half-related idea came up while pondering this,
> "block in inet6 to autoconfprivacy" (similar UI to urpf-failed)
> (I'm meant to be doing something else and likely to forget so I'd
> like to at least plant the idea :)

heh, interesting

-- 
I'm not entirely sure you are real.

Reply via email to