[ipv6hackers] Pros and Cons of Address Randomization

[Jim Small]

Hi Owen,

> First, I think it is important to define the type of randomization you are
> talking about...

Good point - I'm talking about randomizing Interface Identifiers or the trailing 64 bits of the IPv6 address.

> Then, of course, there is the question of whether you're talking about prefix
> or suffix or both randomization. (Some ISPs in EU are advocating randomizing
> customer prefixes in the name of consumer privacy).

I'm talking about suffixes.  Prefixes would be a separate thread.

> Assuming for the moment that we are taking about suffix randomization by
> the host on the local subnet, common practices today include {1,2,3,4}. Each
> approach has different advantages and drawbacks.
> >
> > Pros/Cons of IPv6 Address Randomization:
> >
> > Let me start be saying that I welcome disagreement and criticism.  May I
> ask though, when you criticize or disagree please share your thinking on what
> I missed or got wrong.  That said:
> >
> > Address Randomization Value
> > Pros:
> > * Makes host scans/enumeration very difficult (assuming of course they
> can't use DNS or some other means to identify the host - see above I-D by
> Fernando/Tim)
> 
> As is commonly stated... Assumption is the mother of all ****ups. This is an
> utterly invalid assumption in virtually every case.
> 
> > * Having more security options/tools is always a good thing.  The RFC and I-
> D provide some excellent points to think through especially if you use global
> multicast.
> 
> Randomization is about privacy, not really security unless you buy into the
> concept of security through obscurity. Please do not continue to conflate the
> two. While it is not uncommon for people to do so, it really causes a lot of
> errors.

Good point.  In this case I am more focused on the security via obscurity than the privacy aspect.  There is some value in a randomized address for a publicly accessible system.  For example, in the IPv4 Internet common services are scanned daily.  Just log access to a publicly accessible ssh service.  So if I have a system that's not in DNS and allows ssh access, there is some value in having a random IPv6 address as it makes the system harder to brute force.  Mind you, I'm not advocating this - just trying to understand where address randomization can add some value.

> > * Definitely makes sense in some cases - e.g. Clients
> 
> Only if clients care about IP address privacy or masking their host identity. I
> would argue that in about 99% of cases, there is virtually no reason or benefit
> to doing so.

Again, I'm not advocating for or against but just trying to understand value.  I believe there is some privacy value for clients to use a randomized (non-M-EUI-64) IPv6 address.  There is also some security through obscurity value.  If someone is scanning the subnet (penetration test or something similar), it is harder to detect a system using a random address.

> > Cons/Doubts:
> > * The biggest issue I have with this is it seems to imply that you must hide
> your address if you connect to the Internet.  I have a hard time with this.
> What about firewalls, access control, and system hardening?  Is this really the
> right place to focus resources?
> 
> I have trouble parsing this statement in a way that makes sense. Address
> randomization is an optional tool in every implementation where I am aware
> of it. Each individual host can choose to use it (unless it is prohibited) or not.
> Using IP address suffix-based controls on firewalls or for access control or
> system hardening when the address is dynamic (which is a prerequisite to
> address randomization) is utter folly to begin with.

I don't think I was clear on this one.  My intent was to state that if you're worried about protecting against scanning from the Internet you should use firewalls, access control, and system hardening.  My belief is that these are more valuable than address randomization as a defense mechanism.
 
> > * My next biggest concern is that if this is recommended best practice it's
> one more barrier to IPv6 adoption.  I can already hear the groans about how
> onerous it will be to implement and operate IPv6 because of the
> burdensome security requirements.
> 
> This doesn't make sense to me. Can you clarify how having the option of a
> random address creates a burdensome security requirement?

Many are saddled in IPv4 thinking.  If I tell someone in this mindset that all addressing should be randomized and done via DNS that will be a tough sell.  As a consultant I can tell you that many organizations like statically addressing all servers and prefer accessing systems via IP.  I'm not advocating this!  But as an observer of this practice I must advocate IPv6 to these organizations in a way that is palatable to them.
 
> > * To some degree this appears like security through obscurity - I read the
> defense in depth part but I'm still having a hard time getting past this
> 
> First, this is primarily because you are making the mistake of considering
> address randomization to be a security tool. It is not. It is a privacy enhancing
> tool. I would argue that it is not an especially effective one, but certainly,
> without it, privacy is compromised.
> 
> > * How many system compromises are from random scans?  Perhaps it
> depends on the type of network being discussed.  In the Enterprise for
> example, my understanding is that most attacks are drive by download
> exploits, social engineering, or simple mistakes.  Perhaps a case could be
> made for publicly accessible systems in a DMZ, but in general?
> 
> Very few these days. However, address randomization can provide a small
> benefit in reducing the spread of a compromise in that it may make it more
> difficult for the compromised node to identify other targets nearby.
> However, due to the way ND works, the scan space is reduced from 64 bits to
> 24 bits because one only needs to scan through the solicited note multicast
> addresses to enumerate the entire network once one has a presence on the
> LAN.

That's an awesome point on scanning via solicited node multicast!

> Scanning 16.7 million hosts at 1,000 pps is less than 16,778 seconds (roughly
> 1/5th of a day or a little less than 5 hours).
> 
> > * Increases operational complexity
> > Rather than systems using a predictable pattern that's easy to remember
> and administer we use totally random addresses that make addresses hard
> to use and remember
> 
> This really doesn't differ from DHCP today. Nobody tends to memorize
> dynamically assigned host addresses in IPv4.

This is true for dynamically assigned addresses.  However, statically assigned addresses is still popular in many places.
 
> > The use of DNS or even full DDI is virtually forced - this is another potential
> cost/barrier to deploy IPv6
> 
> Not really. mDNS and other service discovery mechanisms still apply equally
> to what is available in IPv4. Generally the same rules about using static
> addresses on servers would also apply.

What I'm saying here is that if you use a randomized IPv6 address, you will have to use DNS.  In order to maintain synchronization between DHCP and DNS you may also need a DDI solution.
 
> > In some organizations DNS and Network administration are siloes and
> forcing the Network team to rely on a separate team could create additional
> challenges or a barrier to adoption
> > * Typically if you need the address of a host/system you can just ask
> someone (social engineering)
> >
> 
> I don't see the IPv6 scenario in this regard as being particularly different from
> the current IPv4 situation.

Yes and no.  It's not really different from IPv4.  However, if we advocate for randomized addresses then we are also effectively saying you have to use DNS and probably DDI too.  This is a change from IPv4, or at least from the way many do IPv4 today.
 
> > So there are classes of systems and a value proposition in regards to
> address randomization for each of them:
> 
> Of course. We didn't limit IPv4 to a single address assignment methodology
> for this reason. Why are you assuming that we need to do so in IPv6. In fact,
> what has actually happened in IPv6 is that we have taken the existing
> address assignment strategies in IPv4 and made them a little more formal
> and documented them a little better.
> 
> Think of address randomization (in its various forms) as being like IPv4 DHCP
> where lease renewals are not granted and addresses are changed. The
> difference is that in IPv6, we have the tools to do this in a much more
> graceful manner that has little or no impact on the end-user.

Agreed.
 
> > Good Value:
> > * Clients - For general clients I am a fan of randomized identifiers, especially
> if Fernando's stable privacy address proposal gets adopted.  With clients we
> can also typically use DHCPv6 (Android being the exception) to provide a
> randomized IID.
> >                Recommend using DHCPv6 server which can supply randomized IIDs
> >                Recommend using Fernando Gont's stable privacy addressing for
> non-DHCPv6 nodes
> >                ** Strongly against rotating addresses for the Enterprise - too
> complex and limits accountability
> 
> I don't see the advantage to using DHCPv6 vs. having the client do the
> randomization via SLAAC with privacy enhanced addresses.

Because with DHCPv6 you have an explicit log of the client and have more control.  DHCPv6 lets you keep the same address (where often privacy addresses rotate).  I would argue that DHCPv6 provides better accountability and auditing than SLAAC.  Most enterprises use DHCP for IPv4 and will (IMHO) prefer DHCPv6.
 
> > Value Depends:
> > * Servers - Different schools of thought:
> >  ** Questioning Value:
> > Critical servers which probably need to be static (DNS, DHCP, Directory
> Servers) - for these I would prefer some kind of pattern versus a randomized
> address.  The value of an addressing scheme with a pattern is it makes server
> administration easier.
> > Servers with static addressing - again, a pattern makes life easier.
> 
> A naming pattern here is more valuable than an addressing pattern with the
> possible exception of DNS servers.

I think you could make a similar argument for DHCPv6 and Directory servers.  Not everyone will want to type in randomized DHCPv6 server addresses in their relays.  Also, many systems which use LDAP require an address and don't do DNS.  I'm not saying this is good, but for this reason there is also some potential value in having a simple patterned address for these server types too.

> Permanent addresses make more sense than temporary addresses, but
> those permanent addresses can be random without any meaningful penalty.

In general agreed.  But for the above examples I think there's a case for a simple patterned address assignment.

> >  ** Valuable
> >                Servers accessible to Internet or in a DMZ - here a randomized
> address makes sense
> >                Servers which can use DHCPv6 reservations - as long as a reliable
> Dynamic DNS or DDI solution is in place
> 
> I don't see the value here. Can you explain your thinking in why this would be
> valuable?

If a server is in a DMZ and publicly accessible there is some value in it having a randomized address.  This makes it less susceptible to dumb brute force scans.  Am I saying it's a large difference?  No, but there is some value.

> I see a number of disadvantages:
> 	1.	Complicates server administration
> 	2.	Makes services less reliable and more complex
> 	3.	Reduces service predictability.
> 	4.	Creates additional dependencies in the availability chain

So I think these issues are based on the address changing.  I would keep the address static.  So when the address is chosen (manual or reserved DHCPv6 assignment), pick a randomized one.  However, one the address is chosen it shouldn't change.

> There are probably other disadvantages as well.

Does that address the issues?

> >
> > Bad (IMHO) Value:
> > * Infrastructure Devices (Routers, Switches, Firewalls, Load Balancers,
> etc...) - For these I am questioning the value of address randomization.  I
> would much rather use an address like 2001:db8::1/64 for my router than
> 2001:db8::ea23:f02b:139e:ffe2.  The latter makes operations much harder
> and it's easy to transpose the digits if you're typing them in (CLI access).
> Perhaps you could break these into categories:
> >  ** Questioning Value:
> >                Loopback interfaces, management interfaces, default gateways,
> VIPs (routers/load balancers)
> >  ** Possible Value:
> >                Where devices are transparently bridging and need an address but
> it's not the default gateway or used for management
> >                Where DNS can be used though I'm skeptical of this as it hasn't
> seemed to work very well in IPv4 - perhaps I'm saddled by IPv4 thinking
> here...
> >
> 
> Given that you learn your router as a link-local address obtained via multicast
> anyway, why do you even care what the address of your router is?

Well IMHO you should do it this way.  However, I have seen many examples where the link-local or VIP is manually configured.  Some people/organizations are terrified of anything dynamic because of the publicized issues with NDP attacks (e.g. Windows DoS).  Therefore they do everything statically.  I am not in favor of this, but where it is done I can see doing it with a pattern.

> I don't
> find that having a random address on my router makes any difference vs. a
> static address on the router. I work in environments that contain examples of
> both and I have not noticed any difference in the complexity of operations in
> those environments. I have more than 5 years experience in both
> environments (yes, on IPv6 in large scale networks) at this point, so I think
> you need to make a better case for your claim that it makes operations much
> harder. I simply haven't seen that to be the case in actual real world
> deployments.

So for example - if my router has a loopback of 2001:db8::1 it's easier to ssh to than if it's 2001:db8::fea2:ec02:578a:129f.  You could use DNS and have a naming convention for everything - in fact that's probably the way to go.  However for organizations that prefer to use addresses instead of names I can see using a pattern as a desirable thing.

> When would you ever be typing your router's address in to a CLI in IPv6? In 5
> years of running IPv6, I can probably count the number of times I have done
> so on one hand and still have fingers left over.

So you always rely on DNS?

> > I guess the question is - does the potential security value of address
> randomization outweigh the increased operational complexity incurred?  I
> would like to add though that despite my efforts to reshape my neurons into
> IPv6 mode and shed the legacy IPv4 mentality, perhaps I am being saddled
> by this?  I am interested in your thoughts on the value of address
> randomization.  As I described above I think there are cases where it's
> valuable and cases where I question the value.
> >
> 
> Since there is no security value to address randomization, that's really the
> wrong question to be asking. The question is the privacy value since that is
> what address randomization provides.
> 
> You are correct that much of what you have stated above is still tainted by
> IPv4 style thinking (for example, assuming that typing in gateway addresses
> would be commonplace in your operations).
> 
> I think address randomization is of little value and of even less consequence
> in most cases. I strongly recommend against it for routers, servers, or
> anything else that needs to be reachable by name. Even in the case of hosts
> that use randomized addresses, most implementations also preserve the
> "well-known" MAC-based address as well and generally I recommend that
> traffic using the host as the "server" side of the conversation should use that
> address (or a statically assigned address) while any host using address
> randomization should be using that randomized address only for flows
> initiated by the host as client.

Are you against randomization in general or just rotating addresses?

> > I don't believe there are absolutes with IPv6 security - I am just trying to
> understand both sides of address randomization so I can be a good guide
> when helping people on their IPv6 journey.
> >
> 
> There are not. It's not even true that address randomization is absolutely
> unrelated to security. However, it is almost entirely unrelated to security.

Thanks for the comments - much appreciated!

--Jim