[core] UEID device identifier and RFC 9039

Laurence Lundblade <lgl@island-resort.com> Sat, 31 July 2021 00:47 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DF23A1AEC for <core@ietfa.amsl.com>; Fri, 30 Jul 2021 17:47:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 YgIChXs3clGx for <core@ietfa.amsl.com>; Fri, 30 Jul 2021 17:47:23 -0700 (PDT)
Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36B63A1AD3 for <core@ietf.org>; Fri, 30 Jul 2021 17:47:23 -0700 (PDT)
Received: from [192.168.0.100] ([71.92.144.145]) by :SMTPAUTH: with ESMTPSA id 9d9umBqMo31BX9d9umRF7r; Fri, 30 Jul 2021 17:47:23 -0700
X-CMAE-Analysis: v=2.4 cv=T49J89GQ c=1 sm=1 tr=0 ts=61049d9b a=E5cCtQzjhQJ5yJ7bKjC7Hg==:117 a=E5cCtQzjhQJ5yJ7bKjC7Hg==:17 a=48vgC7mUAAAA:8 a=OfDViWQvA1O8X5BytuIA:9 a=QEXdDO2ut3YA:10 a=d2TqRZ6kbDWfyFeT:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8FAE8B98-6B98-486A-B213-7364565CBAF7"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Message-Id: <A3A116A5-986A-47BB-88A0-814009625E02@island-resort.com>
Date: Fri, 30 Jul 2021 17:47:22 -0700
To: rats@ietf.org, core@ietf.org
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-CMAE-Envelope: MS4xfDADkh355glnxFI0tNgedkc4vxs9uJuNqK62WB/HTeBgrq+PCbY7aJiTTozJdxDf+8Gj8xAKYXdBYucOnxW5b24kNR1WC6J5GvSUGugLaKCEeJvrY2B0 HDFNJg4Ne9p+TkXkLbfoLcSjAmWVD4i6b83UKb/FOIhizG1uvq2hixiS+WKPcSVpohDKsZV4kC8Wl7vCmDxXYEn5/Hwh2CuAbWA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/70HkvS8Yjkh2V-dR49-JlwaheV4>
Subject: [core] UEID device identifier and RFC 9039
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Jul 2021 00:47:37 -0000

This is to check-in with the WG that defined the RFC 9039 device identifier URN and others on the UEID <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-10#section-3.4>, a new device identifier proposed by EAT in the RATS WG. Wanted you to know about UEID and see if you have any comments. RFC 9039 and UEIDs seem largely complementary to me.

I plan to add a registration for urn:dev:ueid:xxxxxxxx to the registry established in 9039.

LL


Here’s some background that might be helpful.

A UEID (Universal Entity ID) is intended to be universal in ways that an EUI-64 / MAC and IMEI aren’t.

When designing a new device or for some existing, it may be too expensive, impractical or otherwise not possible to have and EUI-64 or an IMEI. For example, the fees for these identifiers may be too high, or the maker of the device may be politically not able to transact with the IEEE or 3GPP.

The UEID addresses this issue by allowing for the generation of an identifier that is statistically unique, one that doesn’t require any organization to track assignments. This is accomplished by making sure there enough true random bits in the UEID that the probability of collision is negligible. The statistical analysis for this is here <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-10#appendix-B.1>  Note that this is similar to using a UUID, however it is explicitly not a UUID for reasons given here <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-10#appendix-B.2>.

That is, a UEID is universal in that it can apply to more use cases than EUI-64 and IMEI. 

It is also universal in another way.

The UEID can be the only device identifier that a back-end or service decodes and tracks.  For example, without something like a UEID, a back-end that works with phones and laptops may need to track both by IMEI and by EUI-64 / MAC. Its database has two fields for device identifier, and may be more. It has to decode incoming messages for all the different types of device identifiers it knows about. Some devices have one, others the other, or maybe both.

A system that uses a UEID only has to decode and track only the UEID and is thus simpler.

Here’s a little more detail for how UEIDs are designed. In addition to the random bits and statistical uniqueness, a UEID may be made out of an IMEI or an EUI-64. The UEID has minimal internal structure to make sure there is no collision between the three types of UEIDS (random/hash, EUI-64 and IMEI). See here <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-10#section-3.4> for details. Note that the IMEI and EUI-64 have an advantage of being shorter.