[ipv6hackers] Pros and Cons of Address Randomization

[Owen DeLong]

On Dec 6, 2012, at 6:17 PM, Fernando Gont <fgont at si6networks.com> wrote:

> On 12/06/2012 03:39 AM, Owen DeLong wrote:
>>>> 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?
>>> 
>>> Well, I don't see it as "focusing resources". At the very least, you
>>> should do draft-ietf-6man-stable-privacy-addresses-01.txt. That
>>> mitigates address scanning attacks, and traffic correlation *across
>>> networks*. For many/most cases, that's already good enough (even if you
>>> don't implement RFC 4941). And it doesn't require "more effort" --
>>> unless using a crypto function is deemed as "too expensive" (which at
>>> least in most cases, it is not).
>>> 
>> If you're using DHCPv6 for address assignment, then this doesn't
>> really apply. This would only apply if you're doing stateless DHCPv6
>> (i.e. DHCP for other configuration, but not address assignment).
> 
> Agreed (of course).
> 
> 
> 
>>>> * 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.
>>> 
>>> What makes operation harder is RFC 4941, because it changes things from
>>> RFC 4941: i.e., now addresses change over time, whereas in IPv4, they don't.
>> 
>> Except that with DHCPv4, they actually did change over time and at somewhat
>> unpredictable and irregular intervals that depended on a number of random
>> environmental factors.
> 
> In DHCPv4. you do have control over that, if you want. With SLAAC +
> RFC4941, for obvious reasons, you don't have such control.
> 

You don't actually… At least not on the client side. You can _REQUEST_ or
_HINT_ that you want to keep the same address, but the DHCP server is not
under any obligation to give it to you.

> 
> 
>>> However, draft-ietf-6man-stable-privacy-addresses-01.txt does not makes
>>> operation harder at all, and I would argue that in most cases it's
>>> already "good enough" even if you don't do RFC4941.
>> 
>> If you're going to use SLAAC, sure. However, I suspect most enterprises will
>> want to use DHCPv6 for address assignment, in which case this doesn't
>> really apply.
> 
> Agreed. However, the same algorithm could be employed with DHCPv6 for
> generating stable-privacy-addresses.
> 

Sure, but if you're getting your address via IPv6, who cares?

1.	DDNS is probably more useful than having the same address.
2.	If you care about the same address, just assign one by host ID
	and move on.

> 
> 
>>>> * 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
>>> 
>>> If you agree that many targeted attacks start with network
>>> reconnaissance, then it's clear that mitigating network reconnaissance
>>> does bring something in terms of security.
>> 
>> But given the nature of most network reconnaissance, this really
>> doesn't mitigate much. The only effect it has is to make brute
>> force scanning slightly harder and eliminate the ability to take
>> a list of MAC addresses gleaned from network A and use them
>> for a fishing expedition on network B.
> 
> Let's say that it also makes some use of the address-space waste that
> we're doing by employing /64 to subnets. :-)
> 

It's no more wasteful than leaving them on the self unused for 100s of years.

> 
> 
>>>> * 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.
>>> 
>>> One reason for which that's the case is that it's not possible to easily
>>> scan systems behind a NAT. If this changes, then that pattern *might*
>>> change.
>> 
>> It's no more difficult to scan systems behind a NAT than it is to scan
>> systems behind a proper stateful firewall. As such, there's no reason
>> that it should be easier to scan IPv6 systems behind a firewall than
>> it is to scan systems behind an IPv4 NAT.
> 
> Agreed. Unfortunately, some folks seem to think that if you deply v6,
> you should not deploy a firewall in replacement of the IPv4 NAT. -- see
> the discussion on the ipv6-ops list, for example.

Some folks think that they need NAT to make IPv6 secure.

There are many people in the world with absurd ideas and incorrect perceptions.
This doesn't make them right and doesn't mean anyone should listen to them.

> 
> 
>> The bigger reasons that most attacks don't come from simple scans is
>> because 
> 
> ... most of them are not really targeted?
> 
> 
>> it's much easier to simply deploy trojans on web sites and
>> then get people to download the trojans using their more than
>> cooperative email client, web browser, or other automated capability
>> and it doesn't make the miscreant nearly as visible as active scanning
>> would.
> 
> There's certainly at least some truth to this, of course. However, this
> isn't really an argument against address randomization.
> 

It wasn't intended as such. It was intended as a rebuttal to the argument in
favor of address randomization. As I see it, there are four pertinent 
questions:

	1.	What value or benefit does address randomization provide?
	2.	What are the costs or drawbacks of address randomization?
	3.	What value or benefit can be derived from non-random addresses?
	4.	What are the costs and/or drawbacks of non-random addresses?

The above statement was intended as pointing out that the answer to 1 is rather
limited in scope. Nothing more, nothing less.

> 
> 
>>>> Perhaps a case could be made for publicly accessible systems in a
>>>> DMZ, but in general? * 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
>>> 
>>> At the end of the day, if you operate a network with 100, I guess them
>>> being sequential/predictable doesn't bring you much (i.e., "what the
>>> heck was at 2001:db8::56?).
>> 
>> Which is why I think it's better to have useful names in DNS than worry
>> about making address patterns recognizable.
> 
> The DNS issue is somewhat orthogonal. Let's say that I want to target
> organization X. If they employ predictable addresses, I can easily learn
> the addresses of all their systems by doing an address scan. If they
> don't, I must rely on DNS  *disctionary/brute_force* attacks…
> 

You're looking at it purely from the attack surface perspective. I'm speaking
not only from the attack surface perspective, but also from the how usable
is the system. IMHO, regardless of the address patterning or not, DNS makes
IPv6 a whole lot easier to use than it is without DNS. If you're going to
use DNS anyway, then there's a whole lot less drawback to randomizing the
addresses. If you don't use DNS, then address randomization is asking for
some serious human factors challenges which will probably reduce effective
availability.  At the end of the day, let's face it, security is inseparable
from availability. Otherwise, we could simply unplug the machines and call
them secure.


> 
> 
>>>> The use of DNS or even full DDI is virtually forced - this is another
>>>> potential cost/barrier to deploy IPv6 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
>>> 
>>> This is probably true for routers, but probably not the case for
>>> servers. At the end of the day, of what real use is a web server that is
>>> not published in the DNS?
>> 
>> DNS really isn't that hard. Heck, if you are using Windows Servers,
>> you can administer DNS with mouse clicks and very little understanding
>> of what DNS is. It pretends to be part of Active Directory.
> 
> I guess Jim's point was that on some occasions, the DNS itself might be
> yet another point of failure. e.g., you don't want to be troubleshooting
> your network, and find that the very first problem is that you don't
> know which address to ssh to because the DNS is not working, either.

Fair point, but, seems to me that getting DNS working first isn't
an unreasonable priority.

> 
> 
> 
>> If you're willing to spend 30 minutes reading a book, you can learn
>> enough to manage a standard configuration of BIND on a few servers
>> pretty easily. (shameless plug for Cricket Liu's O'Reilly book on DNS 
>> and BIND and more specifically his IPv6 supplement to that book which
>> I did editorial review on).
> 
> I'd argue that it takes more than 30 minutes if you need to learn about
> the DNS, and then BIND.
> 

I'd argue that if you need to learn both, it's far more effective to do so
in parallel than sequentially. I've taught 30 minute seminars from zero
to DNS administrator, so I'll stand by my 30 minute estimate.

> 
> 
>>>> So there are classes of systems and a value proposition in regards
>>>> to address randomization for each of them: Good Value: * Clients -
>>>> For general clients I am a fan of randomized identifiers, especially
>>>> if Fernando's stable privacy address proposal gets adopted.
>>> 
>>> It has been adopted as a 6man wg item, already. And rumour has it ;-)
>>> that OpenBSD is planning to implement it.
>> 
>> Makes sense. OpenBSD is usually first to implement any poorly thought
>> out crackpot idea that purports to improve security. 
> 
> OpenBSD has a better security record than virtually any vendor you can
> think of. Point.
> 

That doesn't mean that they don't also do some spectacularly stupid things
in the name of security as well.

> That aside, can you shed some light on why you consider
> draft-ietf-6man-stable-privacy-addresses "poorly thought"? -- because
> that's what they seem to be willing to implement.

Actually, I don't consider that one poorly thought out, I just don't
consider it particularly related to security. I think arguing that it is
a security tool is poorly thought out and I'm sure BSD is willing to
implement it because they bought that poorly thought out argument
hook line and sinker.

>> Look at their stupidity with IPV6_V6ONLY.
> 
> Not sure what you're talking about. Could you please elaborate?
> 

Sane operating systems follow the RFCs and the IPV6_V6ONLY socket option
defaults to false. BSD, BSD derivatives, and Windows, OTOH, at best
default to IPV6_V6ONLY=true and in some cases do not allow you to set
it false.

This is harmful because it makes implementing dual-stack code more
difficult and requires double sockets. whereas if the system implements
the proper false default, you can write IPv6 code and get IPv4 support
on a dual-stack system for free.

From what I can tell, this resulted from someone thinking that there
was some inherent danger of IPv4 mapped addresses getting used on the
wire and somehow a belief that this was a security risk and having the
socket option default to IPv6 socket == dual-stack socket on dual-stack
host would create accidental exposures.

There still remains significant religion around this issue, but I have
yet to see a rational security argument in favor of IPV6_V6ONLY=true.

> 
>>>> ** Strongly against rotating addresses for the Enterprise - too
>>>> complex and limits accountability
>>> 
>>> As noted above, in this kind of scenario
>>> draft-ietf-6man-stable-privacy-addresses-01.txt brings most of the
>>> benefits that you want, without the hassle of rotating addresses....
>> 
>> Yes, there are now a multitude of random and pseudo-random
>> mechanisms to overload onto SLAAC. Or you can just use DHCP.
> 
> … and just *hope* that all your systems support it. <sigh>
> 

Meh… The few that don't probably will relatively soon. Of course, IMHO,
there's nothing wrong with EUI-64 based SLAAC addressing, so I'm probably
stupid or something anyway.

> In any case, I don't see your point against
> draft-ietf-6man-stable-privacy-addresses. It improves on SLAAC. If you
> do SLAAC, the current idea of "embedding the MAC address" is a bad idea,
> and the aforementioned I-D fixes that. OTOH, if you need/want DHCPv6, of
> course you don't need to bother about SLAAC… so what?

I'm not as convinced as you are that embedding the MAC address is so bad.

If you're not going to embed the MAC address, then I'm not convinced that
having your address randomized over time is such a bad thing. The way that
RFC-4941 is intended to work, you also get the advantage that inbound can
still use the EUI-64 based address, but outbound randomizes for privacy.

Owen