[ipv6hackers] Pros and Cons of Address Randomization

[Owen DeLong]

Hi Jim,

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

There is:
	1.	Pick a (quasi) random address once and stick to it. (Ala traditional SLAAC where MAC assignment serves as the randomization function)
	2.	Pick a new (quasi) random address for each network prefix, but always use the same address for a given prefix. (ala M$)
	3.	Pick a new (quasi) random address for each network attachment, but use the same address as long as attached. (some privacy address implementations)
	4.	Pick a new (quasi) random address every (t) time period. (most privacy address implementations other than M$)
	5.	Pick a new (quasi) random address every (n) flows where n>0
	6.	Pick a new (quasi) random address every (n) octets transferred

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

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.

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

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

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

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

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.

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

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

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

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

> 
> 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.
Permanent addresses make more sense than temporary addresses, but those permanent addresses can be random without any meaningful penalty.

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

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

There are probably other disadvantages as well.

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

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.

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

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

Owen
>