[ipv6hackers] Pros and Cons of Address Randomization

[Owen DeLong]

On Dec 5, 2012, at 17:49 , Fernando Gont <fernando at gont.com.ar> wrote:

> Hi, Jim,
> 
> Please find my comments in-line...
> 
> 
> On 12/01/2012 04:32 PM, Jim Small wrote:
> [....]
>> Read Fernando and Tim's Revised Internet Draft: 
>> http://tools.ietf.org/html/draft-gont-opsec-ipv6-host-scanning-02 
>> Note:  This is absolutely fantastic and should be mandatory reading 
>> for any network or security engineer.  The pros/cons of address 
>> randomization are by no means meant to take away from this 
>> publication.
>> 
>> Followed the conversations on the IETF WG and other places such as 
>> LinkedIn.
>> 
>> Are there other sources I should study?
> 
> In addition to the above, you may want to take a look at:
> <http://tools.ietf.org/id/draft-ietf-6man-stable-privacy-addresses-01.txt>
> 
> 
> 
>> 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).

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

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

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

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

The bigger reasons that most attacks don't come from simple scans is
because 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.

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

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

>> 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. Look at their stupidity
with IPV6_V6ONLY.

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

Owen