[ipv6hackers] Pros and Cons of Address Randomization

[Fernando Gont]

Hi, Owen,

On 12/07/2012 07:38 AM, Owen DeLong wrote:
>>>> 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.

Sure. But you can do it on the server side. And that's exactly were you
enforce that policy (if you really care about it).

SLAAC, is, as seen from the IPv4 world, a kind of anarchy.



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

Having the same address is useful for many other reasons: logging, etc.


> 2.	If you care about the same address, just assign one by host ID
> 	and move on.

And then again: how do you get a random address based on a host-id? --
you still need an algorithm for that.


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

1) You cannot really tell whether they would be used or not. -- "640K of
memory should be enough...". That said, I really hope we do find a use
for those extra bits. If not, we'd have been wasting time, energy,
space, etc. for 100 years for no bloody reason.

2) Randomizing the vv6 addresses over the /64 at least makes use of it.



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

Agreed. But many of those are deemed as experts (whether you like it or
not), and that will certainly affect emerging IPv6 deployments -- please
do take a look at the thread on ipv6-ops.



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

I think we have a long history of f* ups with predictable IDs. Whether
they are TCP SEQs, DNS TIDS, IPv{4, 6} Fragment IDs, etc. The lesson is
simple: whenever you need some kind of I-D, make it unpredictable,
unless you have a very good reason not to do so.

FWIW, I'm not (necessarily) advocating RFC4941, but rather something in
replacement of MAC-derived IIDs (such as
draft-ietf-6man-stable-privacy-addresses).


> As I see it, there are four pertinent 
> questions:
> 
> 	1.	What value or benefit does address randomization provide?

Mitigation to address scanning attacks.


> 	2.	What are the costs or drawbacks of address randomization?

None.


> 	3.	What value or benefit can be derived from non-random addresses?

None that draft-ietf-6man-stable-privacy-addresses cannot provide --
since the only benefits from MAC-derived IIDs come from the fact that
they are *stable*, rather than from the fact that they are predictable.



> 	4.	What are the costs and/or drawbacks of non-random addresses?

They allow for IPv6 address scanning attacks.


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

Fully agreed.


> If you're going to
> use DNS anyway, then there's a whole lot less drawback to randomizing the
> addresses.

Using the DNS *locally* does not mean that you're going to respond to
queries from the Internet.


> If you don't use DNS, then address randomization is asking for
> some serious human factors challenges which will probably reduce effective
> availability.  

IPv6 addresses will reduce in human f* ups if e.g. communicated over the
phone. That's a fact. -- Some companies that I know of have e.g.,
already established a rule that IP6 addresses should only be
communicated in written form.


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

IN the aforementioned scenarios, you probably care moer about routers
forwarding packets than about being able to use fancy names instead of
human-unreadable IPv6 addresses -- i.e., talking about priorities...


>>> 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.. your attendes learnt everything from "what is the DNS" to
"configuring BIND" in 30 minutes? -- I don't think you meant that. You
probably meant they were already savvy about the DNS, and you just
taught them about "what changes with IPv6".

And the point here is that IPv6 might for the use of the DNS in
scenarios in which it might not be being used for the IPv4 case.



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

Certainly fewer that most vendors do in the name of... "we simply suck" (?).



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

It's fairly simple:

* it mitigates address scanning attacks -- therefore it does have an
effect on security.

* it removes IIDs that are constant across networs -- hence it has an
effect on user privacy.



>>> 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.
[...]
> There still remains significant religion around this issue, but I have
> yet to see a rational security argument in favor of IPV6_V6ONLY=true.
> 

Will look at this one in more detail and come back to you.



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

There's nothing wrong with EUI-64 itself. There *is* something wrong
with deriving the EUI-64 identifiers from the underlying link-layer
addresses (address scans, and privacy issues).



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

Simply put, I don't want to include a "hey, I'm Fernando Gont" thing in
the IID without any benefits in doing so (privacy).

Additionally, there's no reason why I want my addresses to be
predictable. They are already human-unreadable when they employ
MAC-derived IIDs. SO if they are going to be human-unreadable, at least
let them be random. -- we have a long history of predictable IDs,
already (starting frmo the IPv4 world, of course).


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

You're mixing up two different characteristics: time-invariance and
predictability. Please see slide 4 of
<http://www.si6networks.com/presentations/IETF83/fgont-ietf83-6man-stable-privacy-addresses.pdf>

What hurts about RFC 4941 is not that the addresses are randomized, but
that they change over time.

draft-ietf-6man-stable-privacy-addresses produce *stable* and *random*
addresses.


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

As long as you have some address that employs constant IIDs across
networks, you still have privacy issues. Please see the discussion in
Appendix A of
<http://tools.ietf.org/id/draft-ietf-6man-stable-privacy-addresses-01.txt>

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