[ipv6hackers] Pros and Cons of Address Randomization

[Owen DeLong]

On Dec 7, 2012, at 5:54 AM, Fernando Gont <fgont at si6networks.com> wrote:

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

In the IPv4 world, 99+% of DHCP servers do not enforce this, but merely respect
the client hint, so, I don't actually buy your argument here. Yes, you can, but
hardly anyone does.

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

IPv4, as seen from the IPv6 world, is a kind of anarchy. What's your point?

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

If you log based on name and your DDNS is bi-directional, what gain is there
to having the same address? Especially when you cannot guarantee that every
client will actually have the same address? Your specification merely adds
another option for how a client can decide to generate a 64-bit ESI during
SLAAC. There's no server-side control of whether those 64 bits are chosen
based on EUI-64, RFC-4941, or your proposal, or some other random client
process. If anything, you're merely increasing the anarchy.


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

That's already specified in DHCPv6.

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

I'll call bullshit on this. There's a huge difference between 640K and 2^64.

While I fully expect a day when 1TB of RAM may not be enough for most purposes,
I'm willing to bet IPv6 will run into some other scaling limit besides the
number of addresses long before we see a day when 1PB is not enough, let
alone 1XB. Given that 2^64 is more than 18XB…

Do you really expect to see a day when there are enough hosts in the world
to have more than 2,000,000,000 hosts per person in the world on a single
subnet, let alone 2,000,000,000 subnets per person in the world?

I'm willing to bet that's enough for well beyond my lifetime or the useful
lifetime of IPv6 as a protocol.

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

Not really. The host density of random IPv6 addresses is no greater than the
host density of EUI-64 addresses.

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

Given what I hear from "aviation experts" on the news whenever there is a
plane crash, I'm not convinced that being "deemed as experts" has anything
to do with expertise. Yes, idiots have an impact on the world. Frankly,
I'm far more concerned with the impact idiots are having on law and
our legal system than I am with the impact they will have on IPv6
deployments.

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

I think we have a long history of f* ups with unnecessary complexity for
the sake of complexity as well. Randomized addresses increase complexity.
There are tradeoffs in every choice.

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

I'm well aware of your agenda. I'm just not convinced that it is necessarily
any better than the alternatives. I'm also not convinced it's particularly
worse.

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

1.	We've already determined that these addresses are:
	A: More susceptible to scanning attacks than RFC4941
	B: Not significantly less susceptible than EUI-64

2.	Brute force address scanning attacks are not likely a
	common or effective attack vector in IPv6, even with
	EUI-64.

3.	Hinted address scanning offers a similar attack surface
	with any persistent address, whether EUI-64 the stable
	addresses you are proposing. You only get a slight reduction
	for systems which move to different networks because,
	for the moment, nobody has cracked a way to shortcut the
	math to predict likely changes in values based on the
	delta between two subnet values. I'm willing to bet
	that gets solved within the lifetime of IPv6.

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

I call BS here.
	A:	Human Factors -- Increased error rate.
	B:	Increased complexity
		1.	See A above
		2.	Harder to correlate nodes for logging as they move
			around the enterprise.
		3.	Increased opacity in audit trails even within a network.

Likely there are other drawbacks, but those are just the ones I can think of
off the top of my head. Again, you need to stop looking at these choices only
from the security perspective and look at them from the overall sustainability
and availability perspective.

If you look at things only from the security perspective, then disconnecting
everything from the electricity wins every time. There's nothing more secure
than a system with no flowing electrons.

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

Actually, there are benefits from having a host have the same stable ID across
multiple networks. True, those benefits may well be antithetical to some aspects
of security and are certainly antithetical to privacy, but, you cannot deny that
they are benefits from a host administration perspective on some levels.

> 
> 
>> 	4.	What are the costs and/or drawbacks of non-random addresses?
> 
> They allow for IPv6 address scanning attacks.

Other than on mobile/portable systems, not significantly more so than your
proposed draft.

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

And yet you refuse to grasp the implications of that limitation on your vision.

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

Sure, but what's your point?

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

I think you meant result rather than reduce, but it's very hard to know for
sure what the above paragraph is intended to mean given that ambiguity.

Requiring that addresses be communicated in written form is stupid. First,
it's a requirement that will go out the window at the only time it becomes
meaningful. Second, it would be far more effective to teach people the
requisite 6 words and 4 number pronunciations necessary to remove the
spoken ambiguity.
	6 words:
		Alpha
		Bravo
		Charlie
		Delta
		Echo
		Foxtrot
	4 Pronunciations:
		3		Tree
		4		Foh-wer
		5		Fife
		9		Niner

(Given that those work for communicating reliably over AM radios sufficiently
to be trusted for the purpose of life-and-death separation of aircraft in
instrument meteorological conditions and have withstood the test of time in
that application, I'm willing to go with it for communicating IPv6 addresses.)
Admittedly, in aviation, there are 20 additional words to cover G (Golf)
through Z (Zulu), but the point is still valid.

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

I'm not necessarily convinced of that. It depends on which routers and
who is affected by the DNS not working. If it's a client-side network,
then likely it doesn't matter whether the routers forward anything or
not if DNS cannot be resolved. Try this experiment…

	1.	Start with a network of random users.
	2.	Turn off the DNS resolvers.
	3.	Tally the number of help-desk calls as follows:
		1.	"The {internet, network, etc.} is down." +1
		2.	"I can't resolve names" -2
		3.	"{The, My} DNS resolvers are down" -5
		4.	"There's something wrong with DNS" -5

If you have a sample of more than 100 users and don't stack the population
with network engineers, systems administrators, etc., then I bet you
come out with a significantly positive tally.

In my mind, if you have a positive tally, that indicates that your user
population cannot distinguish between a working network with no DNS and
a non-working network.

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

I so love it when you tell me what I meant.

Yes, I have taught people from no knowledge to the point of successfully
editing zone files with A, AAAA, MX, and PTR records in 30 minutes. If
you teach them what the records mean at the same time you teach them
how the records fit in zone files in BIND, it can be done.

No, I didn't teach them how to troubleshoot DNS in that time. That's
another 30 minutes. Since nothing really changes for DNS with IPv6
other than A->AAAA and in-addr.arpa -> ip6.arpa, for people with no
prior knowledge, it's easier to just teach them in parallel rather than
bother with teaching one and then the changes for the other.
It's also faster.

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

Right… IPv6 will scale to places IPv4 couldn't. As a result, you will
need to approach deploying IPv6 in a more scalable manner.

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

I am not entirely convinced of that, but I don't have a sufficient sampling
of all vendors from which to accurately argue that one way or another. Since
I try to avoid the vendors that "simply suck" for the most part (I still don't
understand why anyone buys products from the felons in Redmond), so I may
have a pretty limited perspective on vendor suckage.

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

Except it doesn't really mitigate address scanning attacks, it just
reduces the probability of doing informed/hinted scanning and not by
all that much.

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

Except it doesn't entirely, but, if it has any value at all, it is in
its ability to (marginally) improve privacy.

(Unless I missed the part where your draft requires the host not to
also have an EUI-64 IID in addition to the random one. RFC-4941 requires
both to the best of my knowledge. Certainly the Linux, Mac, and BSD
implementations of RFC-4941 place both on the interface.)

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

Have fun.

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

If you are on the LAN, you can have more effective address scanning using
the SNM address (limits your scan to 2^24 bits). If you're not on the LAN,
then, EUI-64 only gives an advantage for locating systems that travel and
have been on the LAN with you somewhere else.

They don't protect you from scans hinted from, e.g. web logs, etc.

A stageful firewall will do far more to protect you from address scans
than unnecessary complexity in the addressing.

I've already agreed that they may provide some marginal privacy benefit.

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

Right. I never argued against the privacy part. However, there are benefits
to MAC-based IIDs, whether you care about them or not, so the "without
any benefits" claim is specious at best.

> 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 from the IPv4 world, of course).

But you aren't the only person on the planet and there are perfectly
valid reasons that others may want addresses to be predictable.

Rather than rehash my other arguments from above, I'll simply refer
you back to them.

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

I'm not mixing them up. I'm pointing out that if you eliminate time-invariance,
you lose some (or most or all) of your obfuscation value.

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

It's also what provides most of the benefits you are claiming arise from
randomization.

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

Yeah… I got that the first 20 times you explained it. In fact, I got it the
first time I read the title. My point is that stability is inherently
antithetical to the stated goals and once you add the complexity that comes
with randomization, you get most of the pain of address instability for
just as long as you get the benefit of randomization.

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

Yes and no. If the host is only receiving connections on that address and
never originating them, then, you haven't provided that information to anyone
that didn't already have it, so…

Owen