[ipv6hackers] Pros and Cons of Address Randomization

[Fernando Gont]

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.



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



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



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


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



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



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



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



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


> Look at their stupidity with IPV6_V6ONLY.

Not sure what you're talking about. Could you please elaborate?


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

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?

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492