netdev - ULA and privacy addressing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJU8_nU2Yb1yR7j8zMEnF63Lszbu8MVbePWsuwG2_mimU9iwOg@mail.gmail.com>
Date:   Thu, 18 Aug 2022 12:29:33 -0400
From:   Kyle Rose <krose@...se.org>
To:     netdev@...r.kernel.org
Subject: ULA and privacy addressing

My site advertises two IPv6 prefixes to clients: one ULA (static) and
one GUA (in provider-owned space). I would like to by-default enable
privacy addresses for GUA prefixes, but not for ULA prefixes. The main
reason is that long-lived connections (think: SSH) within the LAN
should not stop working when a temporary address has expired. Since
privacy concerns are generally moot for ULA-sourced connections, it
seems like there's no downside.

RFC 4941 predicted the need for this kind of usage pattern:

q( Additionally, sites might wish to selectively enable or disable the
   use of temporary addresses for some prefixes.  For example, a site
   might wish to disable temporary address generation for "Unique local"
   [ULA] prefixes while still generating temporary addresses for all
   other global prefixes.  Another site might wish to enable temporary
   address generation only for the prefixes 2001::/16 and 2002::/16,
   while disabling it for all other prefixes.  To support this behavior,
   implementations SHOULD provide a way to enable and disable generation
   of temporary addresses for specific prefix subranges.  This per-
   prefix setting SHOULD override the global settings on the node with
   respect to the specified prefix subranges.  Note that the pre-prefix
   setting can be applied at any granularity, and not necessarily on a
   per-subnet basis. )

Unfortunately, since router advertisement-derived addresses are always
added with IFA_F_MANAGETEMPADDR, there appears to be no way to achieve
this short of configuring ULA addresses manually on clients, rather
than via radv.

Does anyone have any opinions on the right way to implement a
configuration knob for this (i.e., one that has a chance of being
merged)? While allowing something as expressive as a list of prefixes
for which to not configure IFA_F_MANAGETEMPADDR by default would offer
the most flexibility, it might also be considered too complex for a
niche use case. A boolean knob that allows the administrator to
disable this flag for any radv-configured address in ULA space would
probably cover the overwhelming majority of real-world use cases.

(What I'd *really* like is some way for a router to recommend clients
not use privacy addressing on a particular prefix, but I am skeptical
such a thing would get through the IETF.)

Kyle