[ipv6hackers] Pros and Cons of Address Randomization

[Owen DeLong]

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

128 bits in the address field changes IPv4 practice. This is desirable.

I don't know of any IPv6 DDNS tools that don't do forward and reverse, so I'm
not sure what you mean here.

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

We can agree to disagree.

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

But I don't think they are likely to do so. More likely they will replace
RFC-4941. You might have some luck getting Micr0$0ft to replace their current
broken undocumented pointless tactic.

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

Admittedly, I just took other peoples word when they said DHCPv6 addresses were
supposed to be randomized unless configured otherwise. I haven't been able to
find a reference.

The closest I came was the DHCPv6 support for IA_TA and IA_NA.


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

I'm not sure what you mean here. I still don't imagine that you will be able
to build hardware to support an IPv6+IPv6 routing table (whatever that is supposed
to mean).

In reality, bits are virtual and don't really take meaningful amounts of energy
or space. I'm not sure time is particularly relevant in this case, either.

I expect IPv6 to reach end of life with at least 50% still sitting in the free pool.

I don't expect any IPv6 subnet to ever reach 2% host density.

That's OK. That's expected. That's a good thing.

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

No, it actually doesn't. It assumes that subnets are finite. It assumes that the
number of humans inhabiting the world doesn't exceed ~9 billion (which is the
assumption most likely to get violated, but, even if we get to ~18 billion, then
we still have 1,000,000,000 subnets per person).

These are network addresses… They get assigned to subnets. I think that's a pretty
valid assumption. If you intend to violate that assumption, then you are misusing
the address space for a purpose other than intended.

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

Except that it doesn't change all that significantly unless you have very
homogeneous hardware purchasing habits. Given the strong progress towards
BYOD and away from HYOD that tends to be accelerating, I don't expect that
kind of homogeneity to persist even in organizations where it is currently
normal.

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

We can agree to disagree. I don't think it does anything about address-scanning
at all in most environments.

I accept that it solves the privacy question, but so does DHCPv6 regardless of
the order of DHCPv6 address assignment selected.

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

They are.

They are static over time. Therefore, I have no time limit in which I need
to complete my scan. Temporary addresses, OTOH, have to be caught within a
certain amount of time for the scan to be useful and then the scan result
os only useful as long as the address persists. If you don't manage to
pwn the host within that window, you don't get any advantage on finding
it again for your next attempt.

> 
>> 	B: Not significantly less susceptible than EUI-64
> 
> MAC-derived IIDS, stable-priacy IIDS, and RFC4941 all contain modified
> EUI-64 format identifiers….

Any 64 bit pattern can be argued to contain modified EUI-64 format
identifiers, so I'm not sure how this statement is expected to be
in any way contrary to what I said in B above.


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

I'm saying that except on networks using common static sequential assignment,
brute force scanning over the WAN is certainly infeasible and over the LAN is
infeasible unless your scan operates at such a rate that it is likely to
represent a significant fraction of LAN traffic and/or a DOS attack.

Note, I am speaking specifically of brute-force scanning, not hinted
scanning, multicast ND based scanning, etc.

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

I disagree.

If I can get on the LAN, I can do a 24 bit scan through multicast space and
find all of your stable privacy addresses.

If I need to scan for EUI-64-based addresses, the challenge is no less than
a 24 bit space to scan, even if I assume every target host has the same OUI.

If I can't get on the LAN, then, I either need to know the OUIs for all
of the devices I care about and do a 24-bit scan for each of them, or,
I need to scan the entire 64 bit space.

Admittedly, I don't get the OUI ability to reduce the first 24 bits, but
I would argue that in terms of real-world meaning for attack time from
a remote location, the difference between scanning a 40 bit address space
and a 64 bit address space isn't all that meaningful.

At 1,000 pps (which is pretty aggressive for a remote scan), it still takes
me 1,000,000,000 seconds or nearly 32 years tom complete such a scan.

> 
> 
>>      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
> the address-scanning aspect.
> 

Not really. If I know your address on subnet A and I can predict the resulting
suffix when A becomes B, then, I only need to scan you once. Point is that
if someone cracks that, then, your stable addresses become as transparent
across networks as EUI-64.

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

I disagree. With mac-derived kids, I can look at the mac and the IP address and
know pretty quickly that they don't match or that there is some other error.

With randomized addresses, not so much.


> 
>> 	B:	Increased complexity
>> 		1.	See A above
> 
> See my response above.
> 

Yes, and it's just as incorrect here as it was there.

> 
>> 		2.	Harder to correlate nodes for logging as they move
>> 			around the enterprise.
> 
> You don't really on this kind of thing for v4... or do you?
> 

It's not available in v4, so I have to scrape the mac addresses out of the
switch instead. Having said that…

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

If I do DHCPv6 (and I usually don't, frankly), then I can log the mapping
of the DUID for correlation.  With SLAAC, I can correlate using the MAC
address. With your proposal and with RFC-4941, it's chaos.

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

Funny… That's what I'd call most of the arguments in favor of using
stable privacy addresses.

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

Micr0$0ft has created yet another mutant form of predictable IIDs.

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

Sure there is… They provide a convenient consistent stable IID that is well
understood, well documented, and has no drawbacks unless you are concerned
about privacy, in which case, having a stable ID across multiple networks
should be a non-starter.


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

But I can rely on SLAAC being used if I configure the subnet router to instruct
hosts to use SLLAC.

> 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

Actually, I don't. I've got the MAC address and I know the SLAAC address
if I know the MAC address, so, all I need to do is track the privacy
address entries in the ND table and I have all the correlation I need.

Yes, the world would be a better place if RFC-4941 was something you had
to deliberately turn on. Unfortunately, people like you have convinced
vendors to go in the opposite direction.

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

No, it's not. If the address persists across a long time, then, pattern removal
becomes a less significant benefit.

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

I can more easily sanity check them for obvious typos. True, the last 24 bits
are still at risk, but, there are values I will come to expect in the ordinary
course for the first 24 bits and values I will consider suspect. The next 16
bits are predictably and reliably 0xfffe.

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

I have no problem reliably communicating IP addresses over the phone. It takes
discipline, practice, and perhaps some training, but it is not hard.

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

It does, actually. Frankly, if they learn that they need to use a word that
starts with the letter instead of saying "Eh, Bee, See, Dee, Eff", I'm happy.
I don't care if they say "Alpha", "Apple", "Adam", or "Angel".

True, getting them to use Tree, Fower, Fife, and Niner takes a little bit of
effort, but, believe it or not, it's not as hard as you think.

FWIW, pilots and amateur radio operators handle this every day and they don't
find it very difficult. Also, police officers, ambulance drivers, dispatchers,
firemen, military, and a host of others.

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

That depends on what you mean by "my DNS". If you mean my recursive resolvers,
then, guess what…

If you mean my authoritative servers, then, that's true, but I cannot remember
the last time my authoritative servers failed to such an extent that I would
need to troubleshoot the network equipment by address. You'd have to be really
bad at designing DNS infrastructure for that to be at all likely.

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

Not sure what you mean by that.

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

I'm not so convinced of that.

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

I am well aware of that. I'm arguing that it doesn't even effectively reduce
them, which is, IMHO, the requirement for claiming mitigation.

>> it just
>> reduces the probability of doing informed/hinted scanning and not by
>> all that much.
> 
> Please do the math. THe difference is significant.

I suppose that's a matter of perspective.

Host lasts 5 years. IMHO, the difference between 32 years and 6400 years
isn't all that meaningful.

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

Then I now oppose the specification as written because preventing the
host from accepting inbound connections to the known EUI-64 is an increase
in the brain damage beyond even that specified in RFC-4941.

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

OK.

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

Not below 2&24 on the LAN.

And not below about 2^40 on the WAN.

See above.

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

Sure, but putting a screen door on a bank vault is still stupid.

You can argue that the screen door adds a layer of security and you can
still be technically right in that argument. This is roughly equivalent.


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

I named several above.

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


First, I don't accept your premise that MAC derived IIDs are not human-
readable. I use them too often to believe that.

Second, until you pointed out section 3, I didn't oppose your draft, I
just didn't want to use it in my environment and didn't feel that it
offered any advantage.


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

Simply not true. If you don't rotate the random address, then it's only a
little harder to find than a non-random address and you now have an
arguably unlimited amount of time to do it.

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

I have. For most of the ones I've talked to, it's the loss of the convenience
of correlating the IP address to the switch port.


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

If you know my mac address, then you can track me no matter what.

Hence the value in having RFC-4941 addresses for outbound purposes while preserving
the MAC-based IID for inbound persistent addressing.

Owen