Subject: [dhcwg] DUID on a Virtual Host

From: Roy Brabson <[email-masked]>
Date: Fri, 16 Feb 2007 15:34:40 -0500

What is the preferred method to generate a DUID on a virtual host?  We
have a shared hardware platform that allows for multiple virtual hosts
to be started.  Each virtual host may share the same hardware (CPUs,
network interface adapters, etc.).

RFC 3315 defines several methods for generating a DUID (DUID-LLT,
DUID-EN, and DUID-LL).  These seem to assume that there is a globally
unique identifier tied to a hardware platform that may be used as a
DUID, which really isn't the case with virtual hosts.

Because of the shared nature of the hardware, DUID-EN can't be used.
DUID-LL can't use the burned-in MAC address, as each adapter may be used
simultaneously by more than one virtual host.  The same thing applies to
DUID-LLT.  Although the timestamp helps, when starting a large number of
virtual hosts for the first time, there is a chance the hosts will
startup at the same time and select the same timestamp, and there isn't
any algorithm defined to detect the collisions.

Is using a manually-configured MAC address for one of the methods
(DUID-LL or DUID-LLT) OK?  We allow a user to override the MAC address
used for the adapter on a per-host basis, and could use the
manually-configured MAC address in generating the DUID.  However, RFC
3315 seems to imply that the link-layer identifier needs to be globally
unique, which isn't necessarily true when manually configuring the MAC
(it really isn't true even when using the burned-in MAC address, but
that is another story.)

If not, does this mean that operating systems running on virtual hosts
need to have some other method defined?  Does anyone else run in a
similar configuration, and if so what did you do?

Roy

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Feb 2007 14:17:14 -0700

My personal take on this is that you should not form a fake mac  
address, because your chances of collision don't get any better than  
if you just chose random times.   What I would suggest is that you  
give the virtualization software a way to communicate a unique id to  
each host, separate from the mac address.   This could be a one-time  
ID, and you could form a DUID-LLT-like identifier from it, except  
that instead of being (link-layer, time) it would be (link-layer,  
time, uid).   I think this would provide sufficient safety from  
collision.   I can help you to write up a draft for it if you would  
like.   It was never the intention in RFC3315 that the DUID types  
specified be the only ones ever used - it's just that none of us  
thought of the virtualization case.

---

From: Roy Brabson <[email-masked]>
Date: Mon, 19 Feb 2007 10:24:15 -0500

Ted Lemon wrote:
> My personal take on this is that you should not form a fake mac address,
> because your chances of collision don't get any better than if you just
> chose random times.   What I would suggest is that you give the
> virtualization software a way to communicate a unique id to each host,
> separate from the mac address.   This could be a one-time ID, and you
> could form a DUID-LLT-like identifier from it, except that instead of
> being (link-layer, time) it would be (link-layer, time, uid).   I think
> this would provide sufficient safety from collision.   I can help you to
> write up a draft for it if you would like.   It was never the intention
> in RFC3315 that the DUID types specified be the only ones ever used -
> it's just that none of us thought of the virtualization case.

Lets get together off-list and get something written up.  It should be
fairly easy for us to implement, as we already have plenty of
configuration parameters that must be unique across the set of virtual
servers.

---

From: Thomas Narten <[email-masked]>
Date: Tue, 20 Feb 2007 08:47:22 -0500

> This could be a one-time ID, and you could form a DUID-LLT-like
> identifier from it, except that instead of being (link-layer, time)
> it would be (link-layer, time, uid).

To be clear, Do you think you can reuse the existing DUID-LLT type, or
do you think you need to define a new one?

In looking at the IANA considerations for DUIDs (see RFC3315), it says
new DUIDS are created (only) through Standards Action. I wonder if
that bar is too high. I'd think it would be sufficient to grant them
under other types of RFCs. I.e., is it appropriate/necessary to
_standardize_ all DUID types? I would imagine there will be special
cases that fairly unique to specific scenarios which don't justify
standardization.

That said, in this case (virtualized hosts), I suspect there is
utility/value in having a standardized approach, as it seems the
scenario is somewhat general.

Thomas

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 20 Feb 2007 10:11:04 -0500

Thomas:

The DUID-EN is likely a DUID type that can be used by an organization
(or standards body) to define a type of their liking. There may be some
subtle issues with the wording in RFC 3315 (section 9.3) for some uses
(such as when the identifier is assigned and how it is stored).

- Bernie 

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Tuesday, February 20, 2007 8:47 AM
To: Ted Lemon
Cc: [email-masked]
Subject: Re: [dhcwg] DUID on a Virtual Host 

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 20 Feb 2007 10:24:25 -0500

> (or standards body) to define a type of their liking.

Looking at this  more closely, I would tend to agree.

> There may be some subtle issues with the wording in RFC 3315
> (section 9.3) for some uses (such as when the identifier is assigned
> and how it is stored).

Not subtle actually. :-(

>    The source of the identifier is left up to the vendor defining it,
>    but each identifier part of each DUID-EN MUST be unique to the device
>    that is using it, and MUST be assigned to the device at the time it
>    is manufactured and stored in some form of non-volatile storage.  The

the wording above effectively rules out usage for virtual hosts. I'd
also argue that they wording above is too strong, or at least, I don't
understand why the requirement is so strong (in particular "assigned
... at the time it is manufactured..."), which I interpret to mean
assigned by the vendor BEFORE being shipped to the customer.

In the case of virtual hosts, the assignment would effectively be done
by the customer at deployment time.

Thomas

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 20 Feb 2007 10:33:02 -0500

Yeah, something to consider rewording for a 3315-bis.

- Bernie 

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Tuesday, February 20, 2007 10:24 AM
To: Bernie Volz (volz)
Cc: [email-masked]; Ted Lemon
Subject: Re: [dhcwg] DUID on a Virtual Host 

Not subtle actually. :-(

Thomas

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Feb 2007 07:34:14 -0800

> by the customer at deployment time.

DUID based on public key, maybe? Or, maybe I need to understand
more about virtual hosts, e.g., does each virtual host on a
physical platform get its own public key (or any other kind of
unique identifier) or is it one public key per physical platform?

Fred
[email-masked]

---

From: Roy Brabson <[email-masked]>
Date: Tue, 20 Feb 2007 16:18:48 -0500

> unique identifier) or is it one public key per physical platform?

On our systems, the choice of which certificates to use is left to the
administrator.  In some cases, it makes sense to use the same
certificate across multiple hosts.  For instance, the administrator may
want to use the same certificate across a set of applications running on
 separate hosts.  Or the administrator may want to use the same
certificate for a group of hosts within the same cluster, presenting a
single system image to clients that connect to the cluster.  In other
cases, the administrator may choose to use different certificates at the
various hosts.  Or the administrator may use a mixture of unique and
shared certificates.

But, stepping back for a second, are public keys considered unique,
anyway?  I'm not a security expert, but I  thought public keys were
generated by the end user, and there is nothing that prevents two users
from generating the same public key.  If so, how  does a a DHCP server
differentiate between two hosts that choose to use the same public key.

Roy

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Feb 2007 13:23:04 -0800

> differentiate between two hosts that choose to use the same 

Yes, I wondered about that too and that was why I suggested
earlier that additional information (e.g., a L2 address, a
timestamp, etc.) might also be needed.

Anyone else know about this?

Fred

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Feb 2007 14:52:38 -0700

> differentiate between two hosts that choose to use the same public  

In fact, what I would say about this whole conversation is that keys,  
like clients, are *things to be identified*, not *identifiers*.   You  
call a key something.   Every piece of key generation software I've  
ever used has worked that way - whether you're generating an ssh key  
or an SSL key or a DNS key, the key has a name, and you refer to it  
by name.   It may be that for some reason it makes sense to include a  
public key in a DHCP transaction, but including it *as the  
identifier* strikes me as confusing two functions - identification  
and authentication.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Feb 2007 14:55:49 -0700

> do you think you need to define a new one?

We would have to define a new one.   I don't think it makes sense to  
use the same format, because the documentation doesn't really match  
the proposed new use, and I would expect that to lead to needless  
confusion.

> cases that fairly unique to specific scenarios which don't justify

I think relaxing it to "documented in an RFC" might be okay - someone  
might define a private use and publish an informational RFC.   I'm  
not sure how important this is, though - it seems like a fairly  
unlikely scenario.

> scenario is somewhat general.

Agreed.

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 21 Feb 2007 11:28:43 +0900

> timestamp, etc.) might also be needed.

The answer is, it depends.. If you use a public key as-is, then, yes,  
collisions are possible but not probable  (probability of all say,  
1024 or 2048 bits being the same is roughly nil - think 1 in 2^1024  
and you find that it is very unlikely). Even intentionally creating  
same public key is insanely hard, equivalent in terms of effort to  
breaking the encryption itself.

Of course, lacking/broken sources of randomness (think: boxes with  
time that starts at 0, creating their first public keys at first boot  
with clock unset, and so forth) are different beast entirely.  With  
that sort of environment timestamp won't save you either.

I think the correct approach is just to promote semi-reasonable  
sources of randomness, and if that fails, initializing RNG with  
hardware parameters and then using the public keys as-is.

There is of course the question of what we want to accomplish with  
this scheme; raw public keys used like in SSH provide mostly just way  
of making sure that the users cannot easily pretend to be each other  
based on sniffed traffic (assuming you add signature option to the  
packets sent to the server, or alternatively receive encrypted  
subblocks from the server), and provide some protection of the  
content; however, are those desirable characteristics for DHCPv6?

Cheers,

-Markus

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 21 Feb 2007 07:03:58 -0800

Thanks Markus,

I won't pretend to have a deep knowledge of this space, but I
am also being told that public key is considered as a unique
identifier for the SPKI/SDSI framework:

  http://en.wikipedia.org/wiki/Simple_public_key_infrastructure

Fred

> From: Markus Stenberg [mailto:[email-masked]] 
> Sent: Tuesday, February 20, 2007 6:29 PM
> To: Templin, Fred L
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Wed, 21 Feb 2007 14:09:42 -0500

> anyway?

They'd better be, or you have even bigger problems. I.e., if two
public keys are the same, well so are the private keys. Oops!

Thomas