[ipv6hackers] Pros and Cons of Address Randomization

[Jim Small]

Hi Owen,

<Grin> - I'm chuckling because I agree with almost everything you stated.  It's pretty hard to play devil's advocate against you when I really agree.  However, RFC 5157 was published by a WG so there are advocates of this approach.

Fernando, Tim, randomization/privacy advocates - I am hoping you will offer some input.


Just a few questions though if you feel so inclined:

> >> First, I think it is important to define the type of randomization you are
> >> talking about...
> >
> > Good point - I'm talking about randomizing Interface Identifiers or the
> trailing 64 bits of the IPv6 address.
> 
> Re-examine the list of types I gave... All of them were suffix-oriented.

Yep - agreed, just removed because no contention/questions.

> >>> * Having more security options/tools is always a good thing.  The RFC and
> I-
> >> D provide some excellent points to think through especially if you use
> global
> >> multicast.
> >>
> >> Randomization is about privacy, not really security unless you buy into the
> >> concept of security through obscurity. Please do not continue to conflate
> the
> >> two. While it is not uncommon for people to do so, it really causes a lot of
> >> errors.
> >
> > Good point.  In this case I am more focused on the security via obscurity
> than the privacy aspect.  There is some value in a randomized address for a
> publicly accessible system.  For example, in the IPv4 Internet common
> services are scanned daily.  Just log access to a publicly accessible ssh service.
> So if I have a system that's not in DNS and allows ssh access, there is some
> value in having a random IPv6 address as it makes the system harder to brute
> force.  Mind you, I'm not advocating this - just trying to understand where
> address randomization can add some value.
> >
> 
> Yes, I operate several such systems. I'm well aware of this. Do you have ANY
> reason whatsoever to believe that address obfuscation would somehow
> reduce this? My bet is that the same sort of crawling locates these services
> independent of address scans. A useful public system is probably in DNS. A
> random address that isn't published in some form of directory isn't going to
> be all that useful as a public system.

Not really.  I don't personally believe in the security through obscurity approach.  However, I also think I have a lot to learn so I'm hoping advocates of this approach will enlighten me.

> It doesn't make the system harder to brute force. It _MIGHT_ make the
> system harder to locate prior to working on brute-forcing it.

Agreed, but see above comment.  :-)

> > Many are saddled in IPv4 thinking.  If I tell someone in this mindset that all
> addressing should be randomized and done via DNS that will be a tough sell.
> As a consultant I can tell you that many organizations like statically addressing
> all servers and prefer accessing systems via IP.  I'm not advocating this!  But
> as an observer of this practice I must advocate IPv6 to these organizations in
> a way that is palatable to them.
> >
> 
> Sure, but you should never tell anyone that. You lose in the first half of that
> sentence. "All addressing should be randomized" is no more accurate than
> "no addressing should be randomized". The first thing that has to be
> communicated is that there are no absolutes here.

Agreed.

> Second, you're going to need to help people unload those saddles. If we
> don't unburden ourselves from IPv4 thinking, we'll never get anywhere.

I'll have to work on my persuasiveness.  :-)

> >>> * 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
> >>
> >> This really doesn't differ from DHCP today. Nobody tends to memorize
> >> dynamically assigned host addresses in IPv4.
> >
> > This is true for dynamically assigned addresses.  However, statically
> assigned addresses is still popular in many places.
> >
> 
> 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+).

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

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


Thanks again for all the feedback,
  --Jim