[ipv6hackers] Pros and Cons of Address Randomization

[Owen DeLong]

>> 
>> A statically assigned address won't be subject to randomization, so it isn't
>> really part of this discussion as far as I am concerned.
> 
> Point of clarification - I see two options here:
> 1) Randomized initial address which doesn't change unless the prefix changes
> 2) Randomized address which rotates
> 
> For the enterprise use case, I am completely opposed to option 2 and I doubt someone could convince me this is a good thing.  I understand the privacy implications but I don't believe the small potential gain outweighs the loss of security and accountability.  My entire thread is advocating option 1.  Option 1 could be via SLAAC with the proposal Fernando has in front of the IETF.  Or option 1 could be achieved via the right DHCPv6 service which returns a randomized IID with a fairly long lifetime (e.g. 1 week+).
> 

For a portable system in the enterprise, I can see potential cases for case 1. For a non-portable system, I see no advantage to case 1 over an EUI-64 address.

>> If you're using static IPv4 for a host today, then you probably want to use
>> static IPv6 for that host in IPv6. Clearly address privacy isn't a concern for such
>> a host, so there's no reason to think that privacy addressing should be
>> applicable here.
> 
> Agreed - I am trying to see the security through obscurity gain by using a "permanent" but initially randomized (versus a simple pattern) IID.  I don't personally see a lot of value here but I would like to hear from someone who believes in this approach.  Perhaps if I ran a University network which can be more open I would have a totally different view point.  My world is the Enterprise which has its own set of paradigms.  For example, in enterprise networks I seldom see things like DHCP snooping or DAI employed because they don't want to deal with the added complexity.  However, from asking around it appears that this is common for University environments.
> 

You are looking for something that isn't there. As a general rule, if something is being statically addressed, it's generally because you want people to be able to find it. Thus, either use an EUI-64 (which is nearly as random as a random address) or a static address with the first 12 bits 0. Assigning a permanent randomized 64-bit address forever doesn't offer any useful advantage in this case.

>>>>> The use of DNS or even full DDI is virtually forced - this is another
>> potential
>>>> cost/barrier to deploy IPv6
>>>> 
>>>> Not really. mDNS and other service discovery mechanisms still apply
>> equally
>>>> to what is available in IPv4. Generally the same rules about using static
>>>> addresses on servers would also apply.
>>> 
>>> What I'm saying here is that if you use a randomized IPv6 address, you will
>> have to use DNS.  In order to maintain synchronization between DHCP and
>> DNS you may also need a DDI solution.
>>> 
>> 
>> And what I am saying is that is not necessarily true. You can skip DNS and just
>> use mDNS or other service discovery for many applications.
> 
> Applications are a separate thread.  Specifically just for infrastructure devices (routers, switches, firewalls) and clients/servers - if you do an initially randomized IID (whether it's permanent or chosen by a DHCPv6 service) then I believe you would have to use a really good Dynamic DNS or more likely DDI.  Disagree?

If it's permanent, it doesn't have to be dynamic, it can be static DNS. Dynamic is more convenient to administer in some ways, but there are tradeoffs.

If you're not using applications, then what is it that cares about knowing the addresses?

> 
>>>>> ** Questioning Value:
>>>>>              Loopback interfaces, management interfaces, default gateways,
>>>> VIPs (routers/load balancers)
>>>>> ** Possible Value:
>>>>>              Where devices are transparently bridging and need an address
>> but
>>>> it's not the default gateway or used for management
>>>>>              Where DNS can be used though I'm skeptical of this as it hasn't
>>>> seemed to work very well in IPv4 - perhaps I'm saddled by IPv4 thinking
>>>> here...
>>>>> 
>>>> 
>>>> Given that you learn your router as a link-local address obtained via
>> multicast
>>>> anyway, why do you even care what the address of your router is?
>>> 
>>> Well IMHO you should do it this way.  However, I have seen many
>> examples where the link-local or VIP is manually configured.  Some
>> people/organizations are terrified of anything dynamic because of the
>> publicized issues with NDP attacks (e.g. Windows DoS).  Therefore they do
>> everything statically.  I am not in favor of this, but where it is done I can see
>> doing it with a pattern.
>>> 
>> 
>> Well, if you're starting from the premise of someone determined to shoot
>> themselves in the foot, it's really hard to advocate what is the best advice to
>> provide on where in the foot to aim.
> 
> I can be somewhat sympathetic to those with security concerns.  However, I think that tremendous progress has been made on the L2 front and that with a little testing and documentation we should be able to give people confidence to securely use RAs/DHCPv6.

I'm extremely sympathetic to those with security concerns. I just think it's better to actually address the security concerns than merely make people's life harder in the name of pretending to have security.

> 
>>>> I don't
>>>> find that having a random address on my router makes any difference vs.
>> a
>>>> static address on the router. I work in environments that contain
>> examples of
>>>> both and I have not noticed any difference in the complexity of
>> operations in
>>>> those environments. I have more than 5 years experience in both
>>>> environments (yes, on IPv6 in large scale networks) at this point, so I think
>>>> you need to make a better case for your claim that it makes operations
>> much
>>>> harder. I simply haven't seen that to be the case in actual real world
>>>> deployments.
>>> 
>>> So for example - if my router has a loopback of 2001:db8::1 it's easier to ssh
>> to than if it's 2001:db8::fea2:ec02:578a:129f.  You could use DNS and have a
>> naming convention for everything - in fact that's probably the way to go.
>> However for organizations that prefer to use addresses instead of names I
>> can see using a pattern as a desirable thing.
>>> 
>> 
>> Yes, DNS is definitely the way to go. If your router has a loopback of ::1, then
>> your
>> other routers have loopbacks of ::x where x is something else. If you make
>> those
>> sequential, then you make it easy for someone that compromises one router
>> to know
>> where to find the others. If you're using ::1 as your loopback, you've even
>> strongly
>> hinted to them that is the case.
> 
> Maybe this is an enterprise bias but my experience has been that loopbacks (at least with IPv4) are numbered sequentially with predictable patterns for ease of use.  These can be protected with ACLs/firewalls.  I would like to do something similar for IPv6.  Maybe this is legacy thinking but I would dread giving this up and completely depending on DNS.  What about outages where you're using an Out Of Band network and DNS is down/unavailable?  This one would be hard for me…
> 
You certainly can do something similar for IPv6 and I would actually generally advocate doing so. I just wouldn't start from ::1 in most cases.

However, in an installation of meaningful size (anything with more than about 20 routers), memorizing the loopback numbers really doesn't scale.

Owen