[ipv6hackers] Pros and Cons of Address Randomization

[Owen DeLong]

On Dec 1, 2012, at 14:01 , Jim Small <jim.small at cdw.com> wrote:

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

Re-examine the list of types I gave... All of them were suffix-oriented.

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

Yes, I operate several such systems. I'm well aware of this. Do you have ANY reason whatsoever to believe that address obfuscation would somehow reduce this? My bet is that the same sort of crawling locates these services independent of address scans. A useful public system is probably in DNS. A random address that isn't published in some form of directory isn't going to be all that useful as a public system.

It doesn't make the system harder to brute force. It _MIGHT_ make the system harder to locate prior to working on brute-forcing it.

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

Right... But the key is to understand that the value is (almost entirely) privacy and that security through obscurity isn't.

All else being equal, one doesn't seek to eliminate obscurity unless there is value in doing so, but I don't know anyone who advocates increasing obscurity as a security practice because the cost of such obscurity generally exceeds any tangible benefit.

In terms of subnet scanning, it depends on whether you have access to the local subnet or not. If you do, then the obscurity is eliminated by the solicited node multicast address anyway. If you don't, then you need to consider the following...

Most hosts that have randomized "privacy" addresses ALSO maintain their EUI-64 address as well. The privacy address should only (according to the RFCs) be used for initiating flows. Flows aimed at the system should use its EUI-64 address or one of its static addresses. So, in fact, you not only don't gain security through obscurity as you describe, but, you in fact double the attack surface because your search now only needs to find EITHER the EUI-64 _OR_ the randomized address.

You might be able to use the combination for some form of enhanced security in that you could set up a stateful inspection on the host that permits inbound connections only on intended services on the EUI-64 address and is strictly outbound on the "privacy" address, but most administrators won't go to that kind of trouble and to the best of my knowledge there are currently no tools to automate any such practice.

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

You are correct.

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

Sure, but you should never tell anyone that. You lose in the first half of that sentence. "All addressing should be randomized" is no more accurate than "no addressing should be randomized". The first thing that has to be communicated is that there are no absolutes here.

Second, you're going to need to help people unload those saddles. If we don't unburden ourselves from IPv4 thinking, we'll never get anywhere.

Third, there's nothing wrong with statically addressing all servers, but organizations that prefer accessing systems via IP are shooting themselves in the foot at best. (Usually it's closer to a head-shot in the long run). So, if they're dead-set on this practice, then they should just continue it in IPv6 and there's no harm in doing so.

However, if I were you, I'd start by advocating that they fix this in IPv4 and then transition them to sane IPv6. Of course, you can always help them deploy IPv6 with the same problems and then transition both protocols.

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

A statically assigned address won't be subject to randomization, so it isn't really part of this discussion as far as I am concerned.

If you're using static IPv4 for a host today, then you probably want to use static IPv6 for that host in IPv6. Clearly address privacy isn't a concern for such a host, so there's no reason to think that privacy addressing should be applicable here.

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

And what I am saying is that is not necessarily true. You can skip DNS and just use mDNS or other service discovery for many applications.

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

Why are we advocating randomized addresses anywhere we're not already using DHCPv4?

I guess that's the part I don't get. Randomized addresses are a host-by-host decision. It's not all or nothing.

Also, I think you are failing to recognize how randomized addresses work:

For example, here is the interface configuration from a Mac running 10.8 with randomized addressing enabled:

en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1280
	ether 00:25:00:44:af:17 
	inet6 fe80::225:ff:fe44:af17%en1 prefixlen 64 scopeid 0x5 
	inet6 2620::930:0:225:ff:fe44:af17 prefixlen 64 autoconf 
	inet6 2620::930:0:157f:3fd2:df3a:cf5b prefixlen 64 deprecated autoconf temporary 
	inet 192.159.10.152 netmask 0xffffff00 broadcast 192.159.10.255
	inet6 2620::930:0:b5e5:8a46:2ae4:1d19 prefixlen 64 deprecated autoconf temporary 
	inet6 2620::930:0:691d:ca9e:7de6:c6b4 prefixlen 64 autoconf temporary 
	media: autoselect
	status: active

Note that there are 5 IPv6 addresses present.

The first one is link local and is EUI-64 based.
The second one is global and is EUI-64 based.
The third one is an old privacy address which is no longer being used to start new sessions, but which has not had its valid time expire.
The fourth one is an old privacy address which is no longer being used to start new sessions, but which has not had its valid time expire.
The fifth one is the current privacy address which is in use.

So, in fact, in terms of security through obscurity, I've multiplied the attack surface by 4 and have not eliminated the MAC address as an attackable address in the process.

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

Sure, but in that case, you're not really dealing with address randomization, you're dealing with address assignment via DHCPv6.

Yes, there (can be) a randomized component to that, but this thread was about the advantages/disadvantages of randomized 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.
> 
> 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.
> 

I would never advocate randomizing server addresses at all. IMHO, servers should be given static addresses, whether or not those addresses are applied to the interface via DHCP static host mappings or via static configuration methods, the addresses themselves should be administered statically.

OTOH, that does not mean that the address should necessarily be patterned.

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

I disagree. Once you learn the address of your DHCP server in a given environment, you'll use it regardless of whether it follows a simple pattern  or not. It's just not a use case that comes up often enough to care.

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

Yes, but nobody finds servers using dumb brute force scans anyway, so the disadvantages vastly outweigh the advantages. You're complicating the administration process without providing any meaningful benefit in return.

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

If you are using a usefully randomized address, then it rotates. If you are not rotating, then it doesn't matter whether you use random, EUI-64, or some other scheme for static assignment.

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

Well, if you're starting from the premise of someone determined to shoot themselves in the foot, it's really hard to advocate what is the best advice to provide on where in the foot to aim.

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

Yes, DNS is definitely the way to go. If your router has a loopback of ::1, then your
other routers have loopbacks of ::x where x is something else. If you make those
sequential, then you make it easy for someone that compromises one router to know
where to find the others. If you're using ::1 as your loopback, you've even strongly
hinted to them that is the case.

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

Except in extreme circumstances, yes. In extreme circumstances, I'm usually not
using the loopback address, but the neighbor interface address, so even in that
case, patterned loopbacks wouldn't help.

In the real world, also, the reality isn't IPv6-only, but dual-stack. Face it, if you're
resorting to typing a routers address in, it's a lot easier to type it's IPv4 address
than even the IPv6 prefix.

>>> 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'm neither for nor against either. I'm attempting to point out the true strengths
and weaknesses of each without advocating in either direction. There are
valid use cases for all of the above.

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

Any time.

Owen