I understand that MACs can be changed/spoofed. But that is the exception, not the rule.
That isn't the biggest issue, though. The biggest issue is how to correlate the MAC and the DUID. That is the only way to properly authenticate and account for users that have both v4 and v6 (which is everyone) I don't care if their MAC changes, if that happens, they just need to reauthenticate. But, not having any way to know what their DUID is going to be, makes it impossible to also give them v6. -Randy ----- Original Message ----- > "You shouldn't assume a MAC isn't constant" should read "is", double > negative failure. > > On Tue, Jan 24, 2012 at 8:49 AM, Ray Soucy <r...@maine.edu> wrote: > > You shouldn't assume a MAC isn't constant. Our students spoof > > their > > MACs all the time (thinking it will save them from getting a DMCA > > notice). > > > > The RFC suggests that DUIDs are stored in non-volatile memory or > > that > > an algorithm be used that can consistently reproduce the DUID (and > > IAID) for a system in the absence of persistent storage. > > > > For fixed hardware devices, I suspect most would opt for the use of > > DUID-LL type, which essentially the MAC with a DUID preamble, and > > doesn't need to be stored in memory since it's based on a MAC that > > can > > not be changed. It would be simple to create a DUID sticker at > > that > > point, even retroactively. I think the idea that DUID is random > > and > > getting worked up that it's not written on the side of the device > > is a > > little more FUD than fact. > > > > There _are_ things we need to address to make DHCPv6 easier to roll > > out (mainly on the server side), but just making bogus nitpick > > attacks > > distracts from the real issues, IMHO. > > > > > > > > > > On Mon, Jan 23, 2012 at 6:12 PM, Randy Carpenter > > <rcar...@network1.net> wrote: > >> > >> Controlled by software = not constant. > >> > >> It is also not likely to be something that is knowable on a piece > >> of electronic gear that is not a PC, nor will it be something > >> that can be printed on the outside of the device, like most > >> today. > >> > >> -Randy > >> > >> > >> ----- Original Message ----- > >>> Yes, DUID and IAID should be persistent on systems. If they are > >>> not > >>> then they are not following the RFC. > >>> > >>> Note that bad practices, though, can remove that persistence > >>> (e.g. > >>> deleting the DUID, or replicating the DUID on other systems). > >>> > >>> On Mon, Jan 23, 2012 at 5:56 PM, Karl Auer <ka...@biplane.com.au> > >>> wrote: > >>> > On Mon, 2012-01-23 at 17:26 -0500, Randy Carpenter wrote: > >>> >> One major issue is that there is no way to associate a user's > >>> >> MAC > >>> >> (for > >>> >> IPv4) with their DUID. I haven't been able to find a way to > >>> >> account > >>> >> for this without making the user authenticate once for IPv4, > >>> >> and > >>> >> then > >>> >> again for IPv6. This is cumbersome to the user. Also, in the > >>> >> past > >>> >> there have been various reason why we want to pre-authenticate > >>> >> a > >>> >> client's MAC address (mostly for game consoles, and such, > >>> >> which > >>> >> have > >>> >> the MAC written on the outside of the machine). How can this > >>> >> be > >>> >> done > >>> >> with IPv6, which the DUID is not constant? > >>> > > >>> > Perhaps I misunderstand you (or the RFCs) but it seems to me > >>> > that > >>> > the > >>> > DUID *is* constant. Reading section 9 of RFC 3315, it's pretty > >>> > clear > >>> > that a DUID is generated once, according to simple rules, and > >>> > does > >>> > not > >>> > change once it has been generated. Barring intervention, of > >>> > course. > >>> > > >>> > The problem is how to either find out ahead of time what DUID a > >>> > client > >>> > has OR how to impose a specific DUID on a client as part of > >>> > provisioning > >>> > it. Neither of those issues looks particularly intractable, > >>> > especially > >>> > if vendors start shipping with pre-configured DUIDs that are > >>> > written on > >>> > the boxes. > >>> > > >>> > What do you mean by "authenticate"? Do you mean something like > >>> > 802.1x? > >>> > > >>> > Regards, K. > >>> > > >>> > -- > >>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>> > Karl Auer (ka...@biplane.com.au) > >>> > http://www.biplane.com.au/kauer > >>> > > >>> > GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE > >>> > 6017 > >>> > Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 > >>> > F687 > >>> > >>> > >>> > >>> -- > >>> Ray Soucy > >>> > >>> Epic Communications Specialist > >>> > >>> Phone: +1 (207) 561-3526 > >>> > >>> Networkmaine, a Unit of the University of Maine System > >>> http://www.networkmaine.net/ > >>> > >>> > >>> > > > > > > > > -- > > Ray Soucy > > > > Epic Communications Specialist > > > > Phone: +1 (207) 561-3526 > > > > Networkmaine, a Unit of the University of Maine System > > http://www.networkmaine.net/ > > > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ > >
