[148843] in North American Network Operators' Group
Re: How are you doing DHCPv6 ?
daemon@ATHENA.MIT.EDU (Randy Carpenter)
Tue Jan 24 11:18:27 2012
Date: Tue, 24 Jan 2012 11:18:04 -0500 (EST)
From: Randy Carpenter <rcarpen@network1.net>
To: Ray Soucy <rps@maine.edu>
In-Reply-To: <CALFTrnOpYwGb-6OHzQTtcx2hBE0R5KNJ5qbyrLsiSthQ4Ta_Rg@mail.gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
I understand that MACs can be changed/spoofed. But that is the exception, n=
ot 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 ac=
count 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 reaut=
henticate. 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 <rps@maine.edu> wrote:
> > You shouldn't assume a MAC isn't constant. =C2=A0Our 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. =C2=A0It would be simple to create a DUID sticker at
> > that
> > point, even retroactively. =C2=A0I 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
> > <rcarpen@network1.net> wrote:
> >>
> >> Controlled by software =3D 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. =C2=A0If 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 <kauer@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 (kauer@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/
>
>
