[ipv6hackers] Pros and Cons of Address Randomization

[Fernando Gont]

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



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

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.



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


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


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


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



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


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



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

For this (mostly local) servers, you can probably get off with using
predictable addresses, and doing packet filtering at the border network.


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

I guess this depends on the number of servers that you're running. -- If
you're running dozens of them, then knowing the address range in use by
the server does not really buy you much.


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

Agreed. Also, such addresses are usually easily learnt by means of
traceroute6 and the like.


> I guess the question is - does the potential security value of 
> address randomization outweigh the increased operational complexity 
> incurred?

I'd argue that the only case in which you might not want to do
draft-ietf-6man-stable-privacy-addresses-01.txt but rather rely on
predictable (typically "low-byte") addresses are routers. For most other
cases, there are no increased cost in employing
draft-ietf-6man-stable-privacy-addresses-01.txt.


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

My take is that, the more you can reuse your v4 thinking, the better.
You don't really want to waste years and years of experience.

Change the thinking only where necessary. IMO, trying to force people to
change their "mode of operation" is one of the things that has not
played in favor of IPv6 deployment (besides economical motivation, of
course).

Cheers,
-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1