Subject: [dhcwg] 3315bis question: Changing default DUID to DUID-LL?

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 23 May 2016 22:01:40 +0200

Hi,

People (in particular those people that run actual networks, but never
come to IETF) complained about DHCPv6 being difficult to use, because
DUIDs of new devices are unknown until the device is booted up. This is
opposed to MAC addresses that are typically printed on the devices. This
information could be used directly if the clients used DUID-LL rather
than DUID-LLT by default. See forwarded email below for more details.

The proposal is tweak existing text in RFC3315bis to explicitly say that
DUID-LL is the default (existing text suggested that DUID-LLT is the
default if device has clock and a stable storage and that's how it was
interpreted by most vendors).

Recently we discussed this on dhcpv6bis list. The responses were
favorable, but there's strong agreement that change of this scope
requires consensus in DHC WG. You can review the previous discussion on
dhcpv6bis here:
https://mailarchive.ietf.org/arch/msg/dhcpv6bis/0r50PZd_oGBtkzP3L3wRkBEqNUg

Two technical points were made:

1. Bernie pointed out that Cable labs already requires using DUID-LL for
cable modems.

2. Ted pointed out that DUID-LL does not reveal anything more than
DUID-LLT already does, so there's no problem from privacy perspective.

So, what's your opinion on this?

Tomek

-------- Forwarded Message --------
Subject: Changing default DUID to DUID-LL?
Date: Sat, 21 May 2016 18:58:16 +0200
From: Tomek Mrugalski <[email-masked]>
To: [email-masked] <[email-masked]>

I recall we did talk about this briefly, but I can't find anything
specific posted to dhcpv6bis.

Once in a while sysadmins keep asking why DHCPv6 is using DUID-LLT as
default, rather than just LL. Here's an example of such question asked
last week:
https://www.facebook.com/groups/2234775539/permalink/10154080188010540/
(if you don't have facebook account, you can still see the discussion by
clicking X comments link).

The details vary, but the general objection is still the same. There's a
large enterprise or similar organization and the sysadmin would like to
know DUIDs of the devices he's about to plug into his network to do host
reservation, access control or provide some options on a per host basis.
He can't do that without powering up every device and letting it
generate its LLT duid.

There are several twists to this. First, some people claim it's
difficult to extract generated DUIDs from many operating systems, so
cases where users themselves are expected to provide their DUID, even if
the device was booted up already, are problematic for users to handle.

Another objection is that most hardware these days have MAC address
printed on it. Vendors can't really print DUIDs as they are not known
during manufacturing phase.

As I understand it, the original rationale for using LLT rather than LL
as default was to avoid cases when switching faulty NIC would make the
client to change its DUID. This is very 1990s. If you disagree with
this, when was the last time you replaced faulty interface card? Also,
the mechanism we have right now - generate the DUID and store it -
effectively solves the concern.

So, what's your opinion on making the DUID-LL the default for regular
devices (i.e. those with clocks and stable storage for generated DUIDs)?

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 May 2016 16:19:49 -0400

On Mon, May 23, 2016 at 4:01 PM, Tomek Mrugalski <[email-masked]
> wrote:

> DUID-LLT already does, so there's no problem from privacy perspective.

Actually, that wasn't my point at all, although it's true.  My point was
that if you have a bar code scan of the link-layer address of a device, you
can see that data in both DUID-LL or DUID-LLT.   Really the difference
between the two is that DUID-LLT is better if you  have removable network
interfaces (which isn't so common anymore) and DUID-LL is better if you
have fixed interfaces (the more usual case nowadays).

One additional hiccup is that DUID is specific to the machine, not to the
interface.   So if you have a machine with more than one interface, you
still don't have a 1:1 mapping between bar code scanned link-layer
addresses and devices, unless your device uses the same link-layer address
on all its interfaces.

Since you brought up the privacy question, it's worth noting that neither
of these options has good privacy characteristics, so advice that we give
about which link-layer address to use in what format would be rightly
ignored by vendors who care about user privacy.   This is not an issue for
infrastructure equipment.   I don't think we should recommend either
without specifying the scope in which the recommendation is valid.

What I _would_ like to do is to clarify the language in this section so
that it doesn't forbid looking at the link-layer address in either DUID-LL
or DUID-LLT.   That was never the intention of the language in RFC 3315,
but it's been interpreted that way rather a lot.

And, BTW, Tomek, you shouldn't be asking us for our opinions.   Our
opinions don't matter.  What matters are the specific reasons we have for
favoring one or the other identifier.   If you ask for opinions, you will
wind up with a lot of votes, and what are you supposed to do with votes in
an IETF consensus call?   :)

---

From: Roy Marples <[email-masked]>
Date: Mon, 23 May 2016 21:50:40 +0100

Hi!

First post here, so let me introduce myself.
My name is Roy Marples and I've maintained dhcpcd for over 10 years.

> interpreted by most vendors).

This problem was also recently brought to my attention (dhcpcd uses DUID-LLT 
by default) by some people integrating NetBSD (where dhcpcd is the default 
client) into SmartOS as a VM.
SmartOS filters DHCPv4 requests to ensure that the ClientID matches predictable 
values, and DUID-LLT is not this.
I don't know off hand if they filter DHCPv6 in the same way.

> So, what's your opinion on this?

In the same way that DUID-LLT is not predictable or known before booting the 
host, neither is DUID-LL.
Consider the host with virtual or hot plugged interfaces. Some hosts also 
randomise their MAC address each boot. Depending on when the client starts in 
the boot order a different DUID-LL (especially for parallel booting systems) 
could be used each time unless persistently stored. To make it predicable and 
known, the DUID-LL would be to be different per interface which I think 
defaults the original goal of determining host (DUID) and interface (IAID).

I think that changing the default to DUID-LL just makes it worse for multi-
homed users.

Also, consider this text from RFC3315 Section 9.

   Clients and servers MUST treat DUIDs as opaque values and MUST only
   compare DUIDs for equality.  Clients and servers MUST NOT in any
   other way interpret DUIDs.

Given the use of MUST, I see no reason to change to DUID-LL use to save an 
admin time from booting a device to see the DUID being used or even bothering 
to parse it as a MAC address as that goes against the RFC.
Instead, maybe encourage device makers to pre-assign DUID-LLT by performing an 
initial bootstrap of the client before shipping and printing this alongside, 
or even replacing, the MAC address.

I'll note at this point that deriving the DUID of the host is hard - I don't 
know where it's stored on windows and some clients store a binary file with no 
easy means of viewing. For the dhcpcd case:
$ cat /etc/dhcpcd.duid
00:01:00:01:1e:b9:6d:46:42:33:df:0b:4c:04

It could also be edited for big orgs to use a Vendor-assigned unique ID based 
on Enterprise Number, which I'm pretty sure satisfied the provisioning case.

So it can be quite easy if you spend a little time thinking about it.

Roy

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 May 2016 17:33:16 -0400

> My name is Roy Marples and I've maintained dhcpcd for over 10 years.

Glad to have you here, Roy!

> I don't know off hand if they filter DHCPv6 in the same way.

Of course, the idea that there are "predictable values" for the DHCP client
identifier based on the link-layer address is totally mistaken, and in
violation of the specification.

> I think that changing the default to DUID-LL just makes it worse for multi-

Exactly.

> or even replacing, the MAC address.

Of course, that's the text I was talking about clarifying.   The point of
that text was to make sure that the entire DUID was used as a client
identifier, not a subset of it.   But it's totally fine to look in the DUID
to see what the link-layer address is, as long as you don't use _just the
link-layer address_ as a DUID.

> 00:01:00:01:1e:b9:6d:46:42:33:df:0b:4c:04

Is there really any need for that, though?   Once you're on the network,
the DHCP server knows the link between your IP address an DUID, so
registering the device is a simple matter of querying the DHCP server for
the DUID and matching that to the source IP address of the HTTP login (or
whatever).

> on Enterprise Number, which I'm pretty sure satisfied the provisioning

I've never actually heard of anyone doing this, although I agree that you
are correct in theory.   :)

---

From: Erik Kline <[email-masked]>
Date: Tue, 24 May 2016 09:09:23 +0900

> are correct in theory.   :)

But might this solve your use case?  If the vendor got an enterprise
number and each device was flashed with a unique DUID-EN that was also
printed on the box...?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 May 2016 21:18:43 -0400

Yeah, but they don't do that, so it doesn't matter.  That _is_ why we came
up with DUID-EN, but as far as I can tell it was a flop. :(

---

From: Erik Kline <[email-masked]>
Date: Tue, 24 May 2016 10:33:46 +0900

Hmm, that's not how I would have read that -EN section.  When I read
"enterprise" I think more of "for guaranteed unique use within a
private space" than "these are my unique numbers to give away to all
my friends".

I would never have guessed this use case was an intention (though of
course it makes sense).

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 May 2016 22:26:06 -0400

Hm, to be clear, the intention was that a large manufacturer of devices
might want their own number space, not that a large organization purchasing
heterogeneous devices might then generate DUIDs for those devices out of a
single enterprise number space.   I may have misunderstood what you were
suggesting.

On Mon, May 23, 2016 at 9:33 PM, Erik Kline <[email-masked]> wrote:

> >> >> It could also be edited for big orgs to use a Vendor-assigned unique
> ID
> >> >> based
> >> >> on Enterprise Number, which I'm pretty sure satisfied the
> provisioning
> >> >> case.
> >> >
> >> >

---

From: Erik Kline <[email-masked]>
Date: Tue, 24 May 2016 11:41:25 +0900

I was guessing the latter, not the former.  Probably just a product of my
broken brain, though.

On 24 May 2016 at 11:26, Ted Lemon <[email-masked]> wrote:

>> >> >> It could also be edited for big orgs to use a Vendor-assigned
>> unique ID
>> >> >> based

---

From: Simon Hobson <[email-masked]>
Date: Tue, 24 May 2016 10:48:08 +0100

Ted Lemon <[email-masked]> wrote:

> Of course, the idea that there are "predictable values" for the DHCP client identifier based on the link-layer address is totally mistaken, and in violation of the specification.

But meanwhile, in the real world, many many people have workflows that require them to be able to identify equipment before it's plugged in. In this sense, it can be argued that the specification is in violation of real world needs.
Though in this case, I'd agree that the implementation is wrong.

>> randomise their MAC address each boot.

IMO, a device which has no persistent storage, and which uses a random MAC is not manageable by any system that relies on being able to identify a client - without using device class specific tools (like all those devices that can only be managed by the vendor's proprietary, and usually Windows only, programs) !
Virtual devices are another class - but do you have any example of such a device that has no persistent storage ?

Are we in danger of sacrificing functionality for many in pursuit of unattainable perfection ? There will always be corner cases, but the requirement for a "single homed device, with known MAC address, and a workflow already setup to capture that MAC address" is (going by the discussions here) very real - and would be serviced by using DUID-LL as default.

>> I think that changing the default to DUID-LL just makes it worse for multi-

Does it ? Assuming the device has persistent storage then once it's generated a DUID it'll keep that. So there is really no change in terms of functionality - only a very very very small chance of a clash if MAC addresses aren't unique.
I strongly suspect that devices using virtual NICs (eg virtual hosts) aren't using DUID-LL[T] and so the change would not affect them.

> Of course, that's the text I was talking about clarifying.   The point of that text was to make sure that the entire DUID was used as a client identifier, not a subset of it.   But it's totally fine to look in the DUID to see what the link-layer address is, as long as you don't use _just the link-layer address_ as a DUID.

I don't think clarifying is the right word. I cannot see any *reasonable* interpretation of that text other than "this is an opaque blob and you can only use it as an exact match to some other opaque blob". As a DUID-LL (and more so, DUID-LLT) is not the same thing as a MAC address, this text very clearly and explicitly prohibits matching the MAC address with the contents of the DUID.
For "clarify", I think you mean "significantly change" :-)

> Is there really any need for that, though?   Once you're on the network, the DHCP server knows the link between your IP address an DUID, so registering the device is a simple matter of querying the DHCP server for the DUID and matching that to the source IP address of the HTTP login (or whatever).

While that may work for some classes of device - eg a "computer" with a browser where the user lands in a captive portal until they've registered their device* - I don't think that's a valid statement for the general case. I strongly suspect the use case driving this is something like :
User/department/whoever gets a new printer. When it gets added to the network, network services need to ensure it goes to a sensible IP address and that relevant systems know about it so it can be used.
In the IPv4 world, as long as it's MAC is known (usually printed on the box, or at least on the device), that can be configured into DHCP to give it a known address, and from there it can be configured etc.
If it uses a predictable DUID (eg DUID-LL and the MAC address is known) then much the same process applies for IPv6 - and not much change to long established workflows are needed to support IPv6. If the DUID is not predictable then "some other means" is needed to find the device - using systems (DHCP server) that by design do not capture any known attribute of the device.

So the problem is easily stated. In a system where you have no knowledge of the IP address, and no knowledge of the DHCP identifier, how do you find and configure the new device ?
I suspect the answer comes back to : find out it's MAC address (the workflow captured it for the IPv4 config), then query a local device on the network for it's neighbour cache, and find the IP address from that, and only then can we query the DHCP server to find out it's DUID. That's a massive change to the workflow.

BTW - I have first hand experience of the problem in assuming that devices can be "registered" by using a portal or similar. A few years ago we (at work) were involved in something or other (I vaguely recall is was some sort of "design and build" project day for local schools) hosted at a local hotel. I wasn't involved in any pre-event stuff, but someone else had been told by the hotel that "yes we have wireless internet available".
Only problem was that access to it was by tickets and registering the device in a captive portal. This meant that we couldn't connect a printer to the network, and all printing ended up being by sneakernet. In hindsight there were probably other issues, but the key thing is that the system was designed on the assumption that every device needing to use the network was of a certain class - and that meant it didn't work for other classes of equipment.

* These are also really really annoying in that there's a gap between my laptop having "a connection" and getting past the captive portal. During this period, various bits of software (eg email clients) start spewing out security warnings as secure connections fail due to being redirected to the portal which (of course) lacks the right security certificates.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 May 2016 09:23:02 -0400

DUID-LL is specifically recommended for cases where the client has no
stable storage.   We are not proposing to change that.

Your printer example is a really good one, though.   I think the answer is
to do what most printers now do, which is to use mDNS to register the
printer, and do the authorization part from an already-authorized devices.

And yes, captive portals absolutely suck.   The O.S. should not tell
clients that the network is available before there is connectivity.   We
have better signaling mechanisms for captive portals now, but unfortunately
they are very new and nobody (AFAIK) implements them yet.

On Tue, May 24, 2016 at 5:48 AM, Simon Hobson <[email-masked]>
wrote:

> > Of course, the idea that there are "predictable values" for the DHCP
> client identifier based on the link-layer address is totally mistaken, and
> in violation of the specification.
>
> But meanwhile, in the real world, many many people have workflows that
> require them to be able to identify equipment before it's plugged in. In
> this sense, it can be argued that the specification is in violation of real
> world needs.
> IMO, a device which has no persistent storage, and which uses a random MAC
> is not manageable by any system that relies on being able to identify a
> client - without using device class specific tools (like all those devices
> that can only be managed by the vendor's proprietary, and usually Windows
> only, programs) !
> Are we in danger of sacrificing functionality for many in pursuit of
> unattainable perfection ? There will always be corner cases, but the
> requirement for a "single homed device, with known MAC address, and a
> workflow already setup to capture that MAC address" is (going by the
> discussions here) very real - and would be serviced by using DUID-LL as
> default.
>
> Does it ? Assuming the device has persistent storage then once it's
> generated a DUID it'll keep that. So there is really no change in terms of
> functionality - only a very very very small chance of a clash if MAC
> addresses aren't unique.
> I strongly suspect that devices using virtual NICs (eg virtual hosts)
> aren't using DUID-LL[T] and so the change would not affect them.
>
>
> > Of course, that's the text I was talking about clarifying.   The point
> of that text was to make sure that the entire DUID was used as a client
> I don't think clarifying is the right word. I cannot see any *reasonable*
> interpretation of that text other than "this is an opaque blob and you can
> only use it as an exact match to some other opaque blob". As a DUID-LL (and
> more so, DUID-LLT) is not the same thing as a MAC address, this text very
> clearly and explicitly prohibits matching the MAC address with the contents
> of the DUID.
> While that may work for some classes of device - eg a "computer" with a
> browser where the user lands in a captive portal until they've registered
> their device* - I don't think that's a valid statement for the general
> case. I strongly suspect the use case driving this is something like :
> User/department/whoever gets a new printer. When it gets added to the
> network, network services need to ensure it goes to a sensible IP address
> and that relevant systems know about it so it can be used.
> In the IPv4 world, as long as it's MAC is known (usually printed on the
> box, or at least on the device), that can be configured into DHCP to give
> it a known address, and from there it can be configured etc.
> If it uses a predictable DUID (eg DUID-LL and the MAC address is known)
> then much the same process applies for IPv6 - and not much change to long
> established workflows are needed to support IPv6. If the DUID is not
> predictable then "some other means" is needed to find the device - using
> systems (DHCP server) that by design do not capture any known attribute of
> the device.
>
> So the problem is easily stated. In a system where you have no knowledge
> of the IP address, and no knowledge of the DHCP identifier, how do you find
> and configure the new device ?
> I suspect the answer comes back to : find out it's MAC address (the
> workflow captured it for the IPv4 config), then query a local device on the
> network for it's neighbour cache, and find the IP address from that, and
> only then can we query the DHCP server to find out it's DUID. That's a
> massive change to the workflow.
>
>
> BTW - I have first hand experience of the problem in assuming that devices
> can be "registered" by using a portal or similar. A few years ago we (at
> work) were involved in something or other (I vaguely recall is was some
> sort of "design and build" project day for local schools) hosted at a local
> hotel. I wasn't involved in any pre-event stuff, but someone else had been
> told by the hotel that "yes we have wireless internet available".
> Only problem was that access to it was by tickets and registering the
> device in a captive portal. This meant that we couldn't connect a printer
> to the network, and all printing ended up being by sneakernet. In hindsight
> there were probably other issues, but the key thing is that the system was
> designed on the assumption that every device needing to use the network was
> of a certain class - and that meant it didn't work for other classes of
> equipment.
>
> * These are also really really annoying in that there's a gap between my
> laptop having "a connection" and getting past the captive portal. During
> this period, various bits of software (eg email clients) start spewing out
> security warnings as secure connections fail due to being redirected to the
> portal which (of course) lacks the right security certificates.
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>