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

Ted Lemon <mellon@fugue.com> Mon, 23 May 2016 21:34 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFC312DBD4 for <dhcwg@ietfa.amsl.com>; Mon, 23 May 2016 14:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7_XtPGYJ5lV for <dhcwg@ietfa.amsl.com>; Mon, 23 May 2016 14:33:59 -0700 (PDT)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912F112DBF9 for <dhcwg@ietf.org>; Mon, 23 May 2016 14:33:57 -0700 (PDT)
Received: by mail-lf0-x22d.google.com with SMTP id e130so42517570lfe.3 for <dhcwg@ietf.org>; Mon, 23 May 2016 14:33:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KIRTKSXMyUUhWcmJarE/J8wVMDr3nCHMyNTupeSvM58=; b=h2y4nMqgM7U/N6tQKD+MZoT69idCKrZYAVYygB9Ft1yEJh9pORGaSM5lYKRusuag7b K2LjN8MJk9HOHIdTzdMWNv1stCtfN+8QTmNlRUq1tUrOPfCbggqxU/6prKLmGunwnlTA jITrm1MKewhEm3YA+apNXnemxkeeA54ub/OKA1XuW0PM6xnm6JT2qKliQkewIXcDEeEs 1lQAnM2H12z7xgIxeJF0d4/+4FVdkZhUSUKGP4VopDeSAkvjmfnu3hv4FMk2djEWN7kJ ogQ4t1eC77GXmN7pTP1tQdyqoWRzMQ43KX0orKgMmMAi+Emw5ZG0QYDmLFzIiM+3oCiG 35KA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KIRTKSXMyUUhWcmJarE/J8wVMDr3nCHMyNTupeSvM58=; b=JBwhOkrheLV62xdP0GlB0u8i96T401Dn+NVerYrku096+iGWqQC7tv4lJotIsEeA+3 7bGyJ1MIdZGw94tCLrsh2IL4+M1KFTALJeSofkKVNZFGmzCuiiSoc5k/GGSlHAcHOLvB NQPogt0E9s3aCD25aovW9wPnWAruuU0UmFmyjs6jy/VLUWX+gAZ4LQ5b6qegJB0Bxui2 eBJgG5krh+BMoSdImag7sIGbane5+l+iDySwiHr8zQbCnjXxH7Cyinbi510LqnB1LYDY RmYyA9MSFi9QhTmVUdzWRrSEnZoEFkbg718BjmNl1QLDgcIsMBxWsF0oJRfZtn179PPC ORpg==
X-Gm-Message-State: AOPr4FVwPDv0EiG8SuASG9/cBBScOzCjRIYY+2NStcfeHkiodtBuFUxO5uzfwla88rd+ZzhA0HprfFKc14WISw==
X-Received: by 10.25.145.19 with SMTP id t19mr6859308lfd.109.1464039235691; Mon, 23 May 2016 14:33:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.153.135 with HTTP; Mon, 23 May 2016 14:33:16 -0700 (PDT)
In-Reply-To: <1914325.ChlqIaE1GT@uberpc.marples.name>
References: <574093A8.5040300@gmail.com> <574361A4.9040907@gmail.com> <1914325.ChlqIaE1GT@uberpc.marples.name>
From: Ted Lemon <mellon@fugue.com>
Date: Mon, 23 May 2016 17:33:16 -0400
Message-ID: <CAPt1N1=Zc-nfHX6F0EMDpnJ178+RUHV8cZRqBk6JRfSZPwjLYA@mail.gmail.com>
To: Roy Marples <roy@marples.name>
Content-Type: multipart/alternative; boundary=001a11401faa94c3ae0533893235
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/Ry1owmArtJnT1_gpaQA8qhg0dNM>
Cc: dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] 3315bis question: Changing default DUID to DUID-LL?
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 May 2016 21:34:01 -0000

On Mon, May 23, 2016 at 4:50 PM, Roy Marples <roy@marples.name> wrote:

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

Glad to have you here, Roy!


> 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.
>

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.


> 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.
>

Exactly.


>
> 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.
>

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'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
>

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).


> 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.
>

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