]> Sandelman Software Works

mcr+ietf@sandelman.ca

Huawei

liuchunchi@huawei.com

Internet IOTOPS Working Group Internet-Draft 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.

Introduction Even before the first release of 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 . 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 . 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 , 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) 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 . This document proposes an active protocol by which the table of MAC addresses can be turned into a MUD URL.

Protocol Details There are three steps to doing this inventory: discovery, interrogation and

1. Make IPv6 Link-Local connection to SLAAC-Ethernet derived IPv6 address on port TBD2.
2. Start TLS on this port.
3. Device uses it's IDevID certificate to respond to TLS request.
4. Do some trivial request over TLS.
5. Extract MUD URL from IDevID certificate.

Privacy Considerations Many.

Security Considerations Even more. Much potential for abuse by malware.

IANA Considerations This will need a TCP port number allocated, and perhaps also a CoAPS/DTLS port number.

Acknowledgements Hello.

Changelog

References Normative References RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects. This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions. Fraunhofer SIT Sandelman Software Works Manufacturer Usage Description (MUD) files and the MUD URIs that point to them are defined in RFC 8520. This document introduces a new type of MUD file to be delivered in conjunction with a MUD file signature and/or to be referenced via a MUD URI embedded in other documents or messages, such as an IEEE 802.1AR Secure Device Identifier (DevID) or a CBOR Web Token (CWT). These signed documents can be presented to other entities, e.g., a network management system or network path orchestrator. If this entity also takes on the role of a verifier as defined by the IETF Remote ATtestation procedureS (RATS) architecture, this verifier can use the references included in the MUD file specified in this document to discover, for example, appropriate reference value providers, endorsement documents or endorsement distribution APIs, trust anchor stores, remote verifier services (sometimes referred to as Attestation Verification Services), or transparency logs. All theses references in the MUD file pointing to resources and auxiliary RATS services can satisfy general RATS prerequisite by enabling discovery or improve discovery resilience of corresponding resources or services. Informative References This informational document details a protocol to load Manufacturer Usage Description (MUD) definitions from RFC 8520 for devices that do not have them integrated. This document is published to inform the Internet community of this mechanism to allow interoperability and to serve as a basis of other standards work if there is interest. This document defines a method to inform a DHCPv6 server that a device has one or more self-generated or statically configured addresses. This document details considerations about how Internet of Things (IoT) devices use IP addresses and DNS names. These concerns become acute as network operators begin deploying Manufacturer Usage Descriptions (MUD), as specified in RFC 8520, to control device access. Also, this document makes recommendations on when and how to use DNS names in MUD files. The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial socks connection setup. This document describes one of those protocols, as it fits into the SOCKS Version 5 authentication "subnegotiation". [STANDARDS-TRACK] Internet users are becoming more aware that their activity over the Internet leaves a vast digital footprint, that communications might not always be properly secured, and that their location and actions can be tracked. One of the main factors that eases tracking of Internet users is the wide use of long-lasting, and sometimes persistent, identifiers at various protocol layers. This document focuses on Media Access Control (MAC) addresses. There have been several initiatives within the IETF and the IEEE 802 standards committees to address some of the privacy issues involved. This document provides an overview of these activities to help coordinate standardization activities in these bodies.