Re: IPv6 and DHCP

[randy marchany <marchany () VT EDU>]

On Wed, May 23, 2012 at 11:59 AM, Phillip Deneault <deneault () wpi edu> wrote:

> Woah... don't go blaming that on me. That's Randy's idea. ;-)

Yep, it's a suggestion that I made. I should also point out that our
networking guys say "static address assignements are for accountants". :-)
See the rest of my comments in this note.

> There are several methods one could use to address an IPv6 network.  I
> have a technical presentation in which I details lots of this
> information, but I'll go through a few quickly here so people get a
> sense of the problem and where to go with it.  Forgive me if you've
> heard this song before. :-)
>
> There are three main ways you address an IPv6 network, statically,
> dynamically via SLAAC, and dynamically via DHCPv6.  There are pros and
> cons to each one.

Absolutely correct. Not only are there pros and cons but it does require a
different way of looking at address assignment from a security perspective.
So, you also need to consider the security implication of the 3 address
schemes.

> Static addressing: Performed the same way you would with IPv4 in all the
> same situations, managed the same way, with all the same caveats and
> problems.  Most sites do not statically address large parts of their
> campus because it is a beast to maintain.
>
> To the point that Randy made, you could assign one address, or one
> subnet per device you ever see, but IPv6 still follows address
> allocation and subnetting conventions just like IPv4, so that model
> doesn't work because most sites don't build their networks that way.
> Additionally, it might be impractical to define that many routes in your
> router.  Additionally, the most traditional way an IPv6 address is
> broken down is by a 64-bit prefix length (AKA subnet identifier) and a
> 64-bit host length (host address) and in normal operation a system may
> have multiple host addresses in the same prefix, acting somewhat like a
> mini subnet (although routing for those instances is handled inside the
> system stack).
>
> In short, the common convention would NOT be to do it this way, but
> Randy is an out-of-the-box thinker and its an interesting scenario to
> think about.
I've been called a lot of things in my career but I'll go with Phil's
description on this topic. From a security perspective, I need to be able
to identify who owns a device connected to my v6 net. My suggestion about
static addresses has the shortcoming that Phil mentioned above. However, v6
forces you to think differently about the implications of these address
assignment methods. We were always constrained by the # of address in a
subnet under v4. That constraint no longer exists in v6.


> The more common conventions are SLAAC and DHCPv6.
>
> SLAAC (StateLess Address AutoConfiguration) takes information made
> available on an IPv6 network via router advertisements to populate the
> prefix length, and pairs it with a host address the system will
> automatically generate to make a valid address.  The address space is so
> large (2^64) that collisions are highly improbable.  SLAAC does NOT
> configure (at present) any other information useful for making
> enterprise networks run... like DNS servers or NTP servers.  That's
> generally not how most universities want to operate.  There is currently
> a RFC to add DNS information to SLAAC, but I have not seen an
> implementation yet.  (http://tools.ietf.org/html/rfc6106)

Absolutely correct.

> DHCPv6 has two modes, one that works WITH SLAAC to provide the
> additional information, and another mode where it provides everything
> including the routable addressing.  It is likely you will run a DHCPv6
> server on your network in one of these two modes.  A key difference in
> DHCPv6 and DHCPv4 is the use of a 'DUID' instead of a MAC address to key
> information from.  In fact, the MAC address does not have to be provided
> at all to a DHCPv6 server to get an address.  It was a design decision
> that the DUID would change as minimally as possible, typically ONLY
> changing when the system was re-formatted.  Since a DUID defines a
> system and not a network card, the same DUID can be used on multiple
> networks, which breaks the model of most campus's existing IPv4 network
> registration systems, so even if you thought about making people record
> their DUID in your netreg system, you might find yourself coding a
> special case.

You'll also need to consider the vendor solutions that are available for v6
addressing. Again, can you identify the owner of the system under this
scheme? Make sure your networking group is able to do so.

> At my university, using a MAC-based NAC system to only allow switches to
> pass traffic for which we have a registered MAC address, and utilizing
> SLAAC with DHCPv6 is _probably_ the way we are going to go initially
> that offers the most parity.  That might change as we develop more
> experience in managing hybrid v4/v6 networks and determine what the
> strengths and weaknesses of the approach are.
>
> What is going to make or break any of these strategies from a security
> perspective is:
>
> 1. How much oversight on IP utilization, user IP tracking, and
> user-to-physical-location tracking do you need for your environment?

User IP tracking is probably the most important thing. If I detect a
compromised machine, I need to contact the owner asap, remove/restrict the
machine from the general net asap and start remediation asap. Are there
privacy implications? Absolutely but that ship has sailed, I'm afraid.

> 2. What technologies do you have in place on IPv4 networks which can
> help you manage both similarly?  (v4/v6 feature parity on layer 2
> devices, NAC methodologies, firewalls and other security devices, etc)

IDS solutions, there are. I'm not sure about NAC solutions but I suspect
they're limited at the moment. Host based firewalls are v6 capable but
require some retraining. Next-gen firewalls are getting there but you will
need to verify any vendor claims.

> 3. Can you get some of this information by other means like polling
> routers for NDP information (the IPv6 equivalent of ARP)?

This is the path our networking guys want to use.  Makes sense to me.


> 4. What does your policy landscape looks like?
>
> Some of you might be realizing why I have a 90 minute presentation going
> over this sort of thing... :-)
>
> Shameless plug:  I am presenting my IPv6 technical talk in Connecticut
> on June 4th, so if you want to talk about these or other IPv6 topics and
> you are in the area, you may wish to sign up.
> http://www.nercomp.org/index.php?section=events&evtid=170
>
> Thanks,
> Phil
>
>
> I would encourage everyone to listen to Phil's talk. My point is that the
v6 address space will force a change in the way we approach security. No
more sequential scanning of a subnet (takes too long) but definitely more
cluster based scanning (found a v6 address, scan +-1 address on either side
to find clusters of similar services perhaps?). Our Moving Target Defense
work (google MT6D) and prototypes show dynamic address switching in v6
works. We're trying to figure out the implications of this with respect to
IDS/IPS and firewalls.

In other words, we (the US) will have to move to v6 eventually since the
rest of the world is (particularly the Asian countries), so start
investigating how to implement it.

-Randy