[ipv6hackers] Pros and Cons of Address Randomization

[Fernando Gont]

Hi, Owen,

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

What's desirable is the larger addresses, not the "changes".



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

You assume the tool would do the reverse mapping before logging, or what?



>> 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 mean *stable-privacy-addresses are likely to replace RFC4941?


> You might have some luck getting Micr0$0ft to replace their current
> broken undocumented pointless tactic.

Still better than mac-derived IIDs.....



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

I seem to recall DHCPv6 doing sequential addresses by default, instead...



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

Of the top of my head, there's no standardized support for randomized
addresses.


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

Sorry, I meant IPv4+IPv6.


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

Well, it's not a good thing if we're wasting bits "by design".



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

Well, that's "hope" or "guesswork" rather than "fact".



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

Generation of EUI-64 from Ethernet is specified. (0xfffe word, etc.)



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

We simply disagree. My analysis is in draft-ietf-opsec-ipv6-host-scanning


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

Ok. But in v6 you wouldn't do a pure brute-force address-scanning attacks.



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

Agreed.



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

And 24 bits is feasible.



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

Even if you didn't know the OUI, you don't need to brute force all those
bits -- just try the "current" ones from the relevant IEEE registry.



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

If someone cracks that, the last of your concerns will be this IPv6
addressing issue.


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

But since you cannot assume that v6 addresses will have mac-derived
IIDs, the test is not really meaningful.



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

Chaos is already there because there's no way to enforce a policy or at
least suggest a policy for address generation.



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

I disagree. You cannot be tracked across networks with 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.
> 
> But I can rely on SLAAC being used if I configure the subnet router to instruct
> hosts to use SLLAC.

But you cannot rely on any specific IID-generation policy, so....



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

Where would you do the logging and correlation? -- Because unless you've
communicated with the corresponding nodes, you won't have such entries
in the ND cache.


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

You're wrong. I never was an advocate of "RFC4941 on by default". OTOH,
I did try to make this managable (see draft-gont-6man-managing-slaac-policy)



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

At the point at which that become an issue, you should probably be doing
something else.



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

Errors? What kind of troubleshooting would you be doing?



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

The same arguement could probably be done about anything in life.


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

I would never have a guy that just received a 30' DNS training
administering a production DNS server.



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

The math is in draft-ietf-opsec-ipv6-host-scanning. Why do you argue
that they don't mitigate scanning attacks?


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

How do you get to that number of "32 years"?



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

The brain damage is to assume that you'll find a piece of layer-2 shit
in a layer-3 address.



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

Where's the screen door here?



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

They are not. And they are hard to remember. I usually need to look at
least twice to copy one v6 address from one place to another.


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

The draft doesn't obsolete the mac-derived IIDs. It just gives you the
option to do something different. If you don't like it, you can still do
mac-derived IIDs.



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

Can you cite your references?

I seem to recall RFC 4941 arguing otherwise.



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

That comes from stability, not from predictability.


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

How can you leverage the mac address if I implement
draft-ietf-6man-stable-privacy-addresses?

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