| Internet-Draft | IDevID scan | April 2025 |
| Richardson | Expires 17 October 2025 | [Page] |
This document describes a mechanism to do an inventory of devices on a network.¶
While there are significant abuse and privacy concerns with kind of scanning, the practice of scanning networks and fingerprinting devices has been occuring since the mid 1990s. But, the adhoc methods are not reliable and do not provide any kind of strong device identity.¶
This document takes the approach that if it will happen, it might as well be reliable and secure.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 17 October 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Even before the first release of [nmap] in 1998, network operators have wanted to know what systems are on their network.¶
One way to do this control has been to require authentication before a system can use the Internet in the form of authenticating firewall proxies, including standards work around SOCKSv5 [RFC1929]. For desktop users these mechanisms have been poorly received, and in many environments these controls have been turned off, or are never deployed. The authenticate before Internet use can create be used to create an inventory, but it does not directly create an inventory. Privacy considerations around IP address and MAC address disclosure have increasingly made that level of inventory even less useful [RFC9724].¶
None of the above heuristics are useful for devices which do not attempt to use Internet. Nor can any kind of person focused authenticated firewall traversal be easily applied to IoT devices. Many enterprises routinely scan DHCPv4 logs to make inventories of devices, but these only help for devices which do IPv4, and which use DHCP. One response is [RFC9686], to allow IPv6 devices to register their name via DHCP, and this is likely to be somewhat useful for some systems.¶
Enterprises also will collect data from the ARP and IPv6 Neighbor Discovery tables of their routers, and this is probably the most accurate way to create some kind of inventory. But the result are just ethernet addresses. When they are IEEE OUI derived, it might point to a brand of device, but it might also just point to the brand of Ethernet adapter used. Getting further information out the device can be difficult.¶
Manufacturer Usage Descriptions (MUD) [RFC8520] are an emerging technology which can provide a reliable link back to not just the manufacturer, but also the device type, and even provide access to ways in which to access the trustworthiness of the device [I-D.birkholz-rats-mud].¶
This document proposes an active protocol by which the table of MAC addresses can be turned into a MUD URL.¶
Many.¶
Even more.¶
Much potential for abuse by malware.¶
This will need a TCP port number allocated, and perhaps also a CoAPS/DTLS port number.¶
Hello.¶