[ipv6hackers] Pros and Cons of Address Randomization

[Fernando Gont]

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

Again: If you want, you can do it. With SLAAC, you simple can't -- even
if you want to. Period.


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

With SLAAC, address generation is not coordinated. Each system may
employ its own policy for generating the IID. In many networks, this is
undesirable.


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

This changes v4 practice -- which is undesirable. And the tool might not
yet support the DDNS bi-directionality you're referring to.


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

If anything, I'd say "increasing the number of variants". -- anarchy is
already there.

However, this proposal might actually *reduce* the number of variants if
nodes replace EUI-64 with this, and MS follows this standardized scheme
(in replacement of the "random - but stable across networks - IIDs" they
are using).



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

Can you provide a reference?


[....]
>>>> 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…

Well, that's not really "setting the bar high": think about IPv6+IPv6
routing tables, etc....



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

This makes an implicit assumption of ho addresses will be used in the
future. -- they might end up used in different ways!



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

What changes is the distribution -- that's the key point here.



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

>From starters, draft-ietf-6man-stable-privacy-addresses doesn't have the
privacy and address-scanning vulnerabilities of the MAC-derived IIDs.



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

They are not. Please elaborate.


> 	B: Not significantly less susceptible than EUI-64

MAC-derived IIDS, stable-priacy IIDS, and RFC4941 all contain modified
EUI-64 format identifiers....



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

Are you deeming them as unfeasible, or... something else?



> 3.	Hinted address scanning offers a similar attack surface
> 	with any persistent address,

The surface is the same, the difficulty in successfully leveraging it is
*not*


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

This analysis is only meaningful for the privacy aspect, rather than for
te address-scanning aspect.




>>> 	2.	What are the costs or drawbacks of address randomization?
>>
>> None.
>>
> 
> I call BS here.
> 	A:	Human Factors -- Increased error rate.

No worse than ma-derived-iids


> 	B:	Increased complexity
> 		1.	See A above

See my response above.


> 		2.	Harder to correlate nodes for logging as they move
> 			around the enterprise.

You don't realy on this kind of thing for v4... or do you?

That said, you might have the same difficulty even if you do dhcpv6, so....

FWIW, I call this argument "the game of finding a justification for
something that is wrong".

That said, even if you want to achive this, you don't need to use
predictable IIDs -- e.g., you could do what microsoft has done.



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

f anything, that does *not* require mac-derived IIDs. SO there's no
argument in favor of such IIDs.



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

Since you cannot rely in any specifich scheme being used, this argument
is essentially void.

Fr instance, when it comes to hosts, most connections will be
"outgoing", and hence you'd have to deal with eg.g RFC4941. At which
point, you need something along the lines of ipv6mon
(http://www.si6networks.com/tools/ipv6mon), or do DHCPv6 and hope all
nodes support it




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

The patterns arising from the IEEE OUI is clearly removed -- isn't that
a significant difference?



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

How are mac-derived IIDs any better than the IIDs specified in
*stable-privacy-addresses?



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

Yep.


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

That doesn't reduce the pain of communicating IPv6 addresses orally.
That said, good luck with having the staff learn thealpha-bravo stuff. :-)



>>>> 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…
[....]
> 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 just forwarding packets destined to someone else's server,
then failure of *your* DNS does not really affect the users, but just
your troubleshooting.



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

Me, I'd be much more concerned about such folks operating the DNS, than
about the human factors in communicating v6 addresses. YMMV, though.



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

This statement is misleading: you'd still need the DNS even when
deploying v6 on the same systems that are currently running v5.


[....]
>>> 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, 

mitigate != eliminate


> it just
> reduces the probability of doing informed/hinted scanning and not by
> all that much.

Please do the math. THe difference is significant.



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

Yes, you did miss Section 3:

---- cut here ---
3. Algorithm specification


   IPv6 implementations conforming to this specification MUST generate
   interface identifiers using the algorithm specified in this section
   in replacement of any other algorithms used for generating "stable"
   addresses (such as that specified in [RFC2464]).  The aforementioned
   algorithm MUST be employed for generating the interface identifiers
   for all of the IPv6 addresses configured with SLAAC for a given
   interface, including IPv6 link-local addresses.  Implementations
   conforming to this specification SHOULD provide the means for a
   system administrator to enable or disable the use of this algorithm
   for generating Interface Identifiers.  Implementations conforming to
   this specification MAY employ the algorithm specified in [RFC4941] to
   generate temporary addresses in addition to the addresses generated
   with the algorithm specified in this document.
---- cut here ----


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

FWIW, OpenBSD did not -- I thought it was a deliberate decision, but it
turned out that it was a bug... that was later patched.



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

mac-derived addresses have specific patterns that can be leveraged to
reduce the search space.



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

Security is not "this XOR that".



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

Can you name any that coul not be achieved without including the mac
address in the IID?



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

>From that pov, we should all shove stuff [complete the phrase as
appropriate :-) ] because there's people that love it....



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

That's not true. The only reason for which RFC4941 addresses vary over
time is that that prevent an external node from correlating activities
of nodes within the same network. -- i.e., be able to tell that this
connection request was issue by the same host that had issued that other
connection request a while ago.

Time-variance in RFC4941 has nothing to do with address-scanning.



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

Talk wth admins an operators that disable temporary addresses, and ask
them what's the property of RFC4941addresses that they don't like.


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

And that proves... what?

If I know your mac address, and know a set of possible network to which
you might be attached to, I can still track you even if you implement
RFC4941. So yes, RFC4941 does not eliminate all privacy issues related
with IPv6 addresses.

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