Network Working Group

Independent Submission                                     M. Richardson
Internet-Draft
Request for Comments: 9238                      Sandelman Software Works
Intended status:
Category: Informational                                        J. Latour
Expires: 22 September 2022
ISSN: 2070-1721                                                CIRA Labs
                                                   H. Habibi Gharakheili
                                                             UNSW Sydney
                                                           21 March
                                                                May 2022

                   On loading MUD

    Loading Manufacturer Usage Description (MUD) URLs from QR codes
                     draft-richardson-mud-qrcode-07 Codes

Abstract

   This informational document details a protocol to load MUD
   definitions for devices which have no integrated Manufacturer
   Usage Description (MUD) as described in RFC8520. 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.

   // RFC-EDITOR-please-remove: This work is tracked at
   // https://github.com/mcr/mud-qrcode

Status of This Memo

   This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the
   provisions RFC Series, independently of BCP 78 any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and BCP 79.

   Internet-Drafts makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are working documents not candidates for any level of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list Standard;
   see Section 2 of RFC 7841.

   Information about the current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 22 September 2022.
   https://www.rfc-editor.org/info/rfc9238.

Copyright Notice

   Copyright (c) 2022 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)
   (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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  The SQRL Protocol . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Manufacturer Usage Descriptions in SQRL . . . . . . . . .   5
       3.2.1.  B000 Company Name . . . . . . . . . . . . . . . . . .   6
       3.2.2.  B001 Product Name . . . . . . . . . . . . . . . . . .   6
       3.2.3.  B002 Model Number . . . . . . . . . . . . . . . . . .   6
       3.2.4.  MUD URL Data Record . . . . . . . . . . . . . . . . .   6
       3.2.5.  Device MAC Address  . . . . . . . . . . . . . . . . .   7
   4.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Generic URL or Version Specific Version-Specific URL . . . . . . . . . . . . .   8
   6.  Crowd Supply of MUD Files . . . . . . . . . . . . . . . . . .   8
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     8.1.  QR codes are not assurances . . . . . . . . . . . . . . .   9 Codes Are Not Assurances
     8.2.  MUD files can have signatures . . . . . . . . . . . . . .  10 Files Can Have Signatures
     8.3.  URL Shortening services can change content  . . . . . . .  10 Services Can Change Content
     8.4.  MUD QR code stickers could be confused  . . . . . . . . .  11 Code Stickers Could Be Confused
     8.5.  QR code can include Code Can Include a MAC address . . . . . . . . . . . . .  11 Address
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     11.1.
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     11.2.
     10.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Acknowledgements
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   The Manufacturer Usage Description (MUD) [RFC8520] defines a YANG
   data model to express what sort of access a device requires to
   operate correctly.  That document additionally defines three ways for
   the device to to communicate to a network enforcement point the MUD
   URL, i.e., URL (i.e., the URL of the resulting
   MUD file in JSON [RFC8259]: [RFC8259]) to a network enforcement point: via DHCP,
   within an X.509 certificate extension, and via LLDP. the Link Local
   Discovery Protocol (LLDP).

   Each of the above mechanism mechanisms conveys the MUD URL in-band, in band and requires
   modifications to the device firmware.  Most small IoT Internet of Things
   (IoT) devices do not have LLDP, LLDP and often have very restricted DHCP
   clients.  Adding the LLDP or DHCP options requires at least some minimal
   configuration
   change, change and possibly entire entirely new subsystems.
   Meanwhile, use of the PKIX certification extension only makes sense
   as part of a larger
   IDevID based [ieee802-1AR] deployment such based on an Initial Device Identifier
   (IDevID) [IEEE802-1AR], for instance, as described in [RFC8995].

   In the above cases cases, these mechanisms can only be implemented by
   persons with access to modify and update the firmware of the device.

   In the meantime meantime, there is a chicken or egg problem ([chickenegg]): [chickenegg].
   That is, manufacturers are not motivated to (and thus likely do not)
   include MUD URLs in their products, as they believe that there are no
   gateways using those URLs.  At the same time, gateways have little
   incentive to (and thus likely do not) include code that processes MUD
   URLs, as it is believed that no products have and or disseminate them. URLs.

   The protocol described in this document allows any person with
   physical access to the device to affix a reference to a MUD URL that
   can later be scanned by an end user.

   The QR-based protocol is presented as a convenient alternative when
   the mechanisms from RFC 8520 [RFC8520] are not available to use, use on the device
   or the gateway.

   Affixing a sticker can be done by by:

   *  the marketing department of the Manufacturer, manufacturer,

   *  an outsourced assembler plant,

   *  value added  value-added resellers (perhaps in response to a local RFP), request for
      proposal (RFP)),

   *  a company importing the product (possibly to comply with a local
      regulation),

   *  a network administrator (perhaps before sending devices home with
      employees,
      employees or to remote sites), and

   *  a retailer as a value added value-added service.

   QRcodes

   QR codes are informally described in [qrcode] and formally defined in
   [isoiec18004].  The protocol described in this document uses a QRcode QR
   code to encode the MUD URL.  Specifically, the protocol leverages the
   data format from the Reverse Logistics Association's Standardized
   Quick Response for Logistics [SQRL].

   SQRL codes are being put on devices via a sticker or via laser
   etching into the case in order to deal with many situations, situations but
   specifically for end-of-life processing for the device.  An important
   idea behind the effort is that clearly identifying a product permits
   appropriate disposal, refurbishment refurbishment, or recycling of the components
   of the product.

   There are also use cases for SQRL described in which the codes are used as part
   of regular maintenance for a product.

   SQRL is an application of the 12N Data Identifier system specified by
   the ANSI MH10.8.2 Committee [mh10] in a format appropriate for
   QRcodes QR
   codes, as well as other things like NFCs Normalization Form C (NFC)
   transmissions.

   QRcode

   QR code generators are available as web services [qrcodewebservice], or as programs programs, such
   as [qrencode].

   Section 5 summarizes the considerations contained in
   [I-D.ietf-opsawg-mud-acceptable-urls] section 6.1 ("Updating MUD URLs "Updating files
   vs Updating MUD files"). URLs" (Section 7.1 of [MUD-URLS]).  Due to the
   immutable nature of the QRcode, QR code, MUD URLs in this document will need
   to be non-firmware specific.

2.  Terminology

   Although this document is not an IETF Standards Track publication, it
   adopts the conventions for normative language to provide clarity of
   instructions to the implementer.  The key words "MUST", "MUST NOT",
   "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14 [RFC2119]
   [RFC8174] when, and only when, they appear in all capitals, as shown
   here.

   Readers should be familiar with the terminology in [RFC8520],
   including: MUD file, MUD URL, Manufacturer and manufacturer, MUD manager manager, and
   controller.

3.  Protocol

   This QRcode

   The QR code protocol builds upon the work by [SQRL].  That protocol
   is very briefly described in Section 3.1.  Then  Then, the list of needed
   Data Records to be filled in is explained.

3.1.  The SQRL Protocol

   [SQRL] documents an octet protocol that can be efficiently encoded
   into QRcodes QR codes using a sequence of ASCII US-ASCII bytes, plus six control
   codes (see section Section 3.1 of [SQRL]):

   *  <RS> Record Separator (ASCII (US-ASCII 30)

   *  <EoT> End of Transmission (ASCII (US-ASCII 4)

   *  <FS> Field Separator (ASCII (US-ASCII 28)

   *  <GS> Group Separator (ASCII (US-ASCII 29)

   *  <US> Unit Separator (ASCII 31), (US-ASCII 31)

   *  Concatenation Operator (ASCII (US-ASCII 43: "+"). "+")

   Section 7.2 of [SQRL] gives the details, which can be summarized as:

   1.  The QR code header starts with:

      "[)>" <RS> "06" <GS> "12N"

   1.

   2.  Include one or more Data Records.  This consists of a four letter four-letter
       Field Identifiers Identifier, followed by ASCII US-ASCII characters terminated with
       a <Unit Separator>.

   2.

   3.  End with:

      <RS><EoT>

   There

   Additionally, there are additionally optional flags that may be present in every
   Data Record Record, as described in section Section 7.4 of [SQRL].  These flags have
   no bearing on MUD processing.  A parser which that is only collecting MUD
   URLs will not need to parse those flags.  A general purpose general-purpose SQRL
   parser will need more complexity.

   Field Separator characters are used in SQRL to signify the beginning
   of a new unit of data.  A MUD specific MUD-specific parser that encounters a Field
   Separator and has not yet collected the right MUD information MUST
   ignore the characters collected so far and then restart.

   Environment records, as described in [SQRL] section 7.4, Section 7.4 of [SQRL], look and
   act exactly as fields, with a special Field Identifier.  They serve
   no purpose when looking for MUD information, information and MAY be ignored.

3.2.  Manufacturer Usage Descriptions in SQRL

3.2.1.  B000 Company Name

   The B000 Data Record is mandatory in [SQRL].  It MUST be in ASCII US-ASCII
   representation.  It should be a representation of the company or
   brand name.  It SHOULD match the ietf-mud/mud/mfg-name in the MUD
   file, however
   file; however, the MUD file can contain arbitrary UTF8 UTF-8 for this
   name, while the SQRL files are expected to be 7-bit US-ASCII.

3.2.2.  B001 Product Name

   The B001 Data Record is optional in [SQRL].  It is the Product Name
   in ASCII. US-ASCII.  Its presence is RECOMMENDED.  Some third parties that
   create QRcode QR code stickers might not know the product name with 100%
   certainty,
   certainty and MAY prefer to omit this rather than create further
   confusion.

3.2.3.  B002 Model Number

   The B002 Data Record is optional in [SQRL], [SQRL] but is MANDATORY in this
   profile.  It is the Model Name in ASCII. US-ASCII.  It SHOULD match the
   optional ietf-mud/mud/model-name in the MUD file if that entry is
   present in the MUD file.  MUD files can contain arbitrary UTF8 UTF-8 for
   the model-name, while the SQRL files are expected to be 7-bit US-
   ASCII.

   If a third party that is creating QRcodes can not QR codes cannot locate an official
   model number when creating their MUD file and QRcode, QR code, then the third
   party SHOULD make one up.

3.2.4.  MUD URL Data Record

   A new Field Identifier has been assigned by the Reverse Logistics
   Association (RLA),
   Association, which is "M180" "M180".  This record MUST be filled with the
   MUD URL.

   Short URLs are easier to encode into QRcode a QR code because they require
   fewer pixels of QRcode. QR code.  More content in the QRcode QR code requires a
   bigger image.

   Use of URL shortening services (see [URLshorten]) can be useful useful,
   provided that the service is stable throughout the lifetime of the
   device and QRcode, QR code and that the privacy stance of the service is well
   understood.  The Security Considerations section of [RFC3986]
   applies, particularly section Section 7.1.

   Section 8.1 of [SQRL] also has some good advice on longevity concerns
   with URLs.

   The URL provided MUST NOT have a query (?) portion present.  If one
   is present, the query portion MUST be removed before processing.

3.2.5.  Device MAC Address

   If a MAC Media Access Control (MAC) address is used as a unique device
   identifier (which is RECOMMENDED if possible), then it MUST be
   included in this Data Record.

   [SQRL] section

   Section 9.10 of [SQRL] defines the Data Record: Record "M06C" as the MAC
   address.  No format for the MAC address is provided in that document.

   This document RECOMMENDS

   In this document, it is RECOMMENDED that 12 (or 16) hex octets are
   used with no spaces or punctuation. (16 octets are used in the IEEE OUI-64
   64-bit Extended Unique Identifier (EUI-64) format used in 802.15.4,
   [IEEE.802.15.4] and some next generation Ethernet proposals) This
   document RECOMMENDS use of upper-case proposals).  In
   this document, it is RECOMMENDED that uppercase hexadecimal letters. letters
   be used.

   Parsers that find punctuation (such as colons (":"), dashes ("-"),
   US-ASCII Space (32), US-ASCII TAB (0), US-ASCII linefeed (10), or
   white space) US-
   ASCII carriage return (13)) MUST skip over it.  Parses the punctuation.  Parsers
   MUST tolerate hexadecimal in
   both upper, lower uppercase, lowercase, and even mixed
   case.  Systems SHOULD canonicalize it to upper case. uppercase.

4.  Applicability

   The use of stickers to convey MUD URLs would appear to have little
   value when the stickers are applied by the end user end-user organization and
   consumed by the same.  This is particularly the case when the QR code
   does not include the device MAC address.  In such a situation situation, the
   installer handling the device would scan the QR code to get the
   appropriate MUD file reference, reference and have to input the associated MAC
   address as well.

   In such a case, one might wonder why the installer couldn't just
   enter the appropriate MAC address and select the appropriate ACLs Access
   Control Lists (ACLs) for the device.  No  Then a MUD file or QR code to
   convey it the MAC address would not be useful at
   all.

   The needed.  However, the use of a
   MUD file (or QR code other or other way to convey it) has the advantage that MAC address) is
   advantageous because it offers several layers of indirection:

   1.  The list of ACLs for a given device may be added or removed.

   2.  The ACLs may refer to DNS names, which may map to IPv4 or IPv6
       addresses.

   3.  The entire file may be replaced, replaced and may also include supply chain
       information, such as Software Bill of Materials (SBOM).

   In addition, the mechanism to install a new device (MAC address) to
   MUD file mapping does not need to permit any other network security
   settings to be alterable by the person doing the installation.

5.  Generic URL or Version Specific Version-Specific URL

   MUD URLs which that are communicated in-band in band by the device, device and which that are
   programmed into the device's firmware may provide a firmware specific firmware-specific
   version of the MUD URL.  This has the  The advantage of this is that the resulting
   Access Control Lists (ACLs)
   ACLs enforced in the network are specific to the needs of that
   version of the firmware.

   A MUD URL which that is affixed to the device with a sticker, sticker or etched into
   the case can not cannot be changed.

   Given the considerations of [I-D.ietf-opsawg-mud-acceptable-urls]
   section 6.1 ("Updating "Updating MUD URLs vs Updating MUD files"), files"
   (Section 6.1 of [MUD-URLS]), it is prudent to use a MUD URL which that
   points to a MUD file which that will only have new features added over time, time
   and never have features removed.  To recap, if a feature is removed
   from the firmware, firmware and the MUD file still permits it it, then there is a
   potential hole that could perhaps be exploited.  The opposite
   situation, where a MUD file wrongly forbids
   something something, leads to false
   positives in the security system, and the evidence is that this
   results in the entire system being ignored.  Preventing attacks on
   core infrastructure may be more important than getting the ACL
   perfect.

   When the firmware eventually receives built-in MUD URL support, then
   a more specific more-specific URL may be used.

   Note that in many cases cases, it will be third parties who are generating
   these QRcodes, QR codes, so the MUD file may be hosted by the third party.

6.  Crowd Supply of MUD Files

   At the time of writing, the IETF MUD is a new IETF Proposed Standard.
   Hence, IoT device manufacturers have not yet provided MUD profiles
   for their devices.  A research group at the University of New South
   Wales (UNSW Sydney) has developed an open-source tool, called MUDgee
   ([MUDgee]),
   [MUDgee], which automatically generates a MUD file (profile) for an
   IoT device from its traffic trace in order to make this process
   faster, easier, and more accurate.  Note that the generated profile
   completeness solely depends on the completeness of the input traffic
   traces.  MUDgee assumes that all the activity seen is intended and
   benign.

   UNSW researchers have applied MUDgee to about 30 consumer IoT devices
   from their lab testbed, testbed and publicly released their MUD files
   ([MUDfiles]).
   [MUDfiles].  MUDgee can assist IoT manufacturers in developing and
   verifying MUD profiles, while also helping adopters of these devices
   to ensure they are compatible with their organisational organizational policies.

   Similar processes have been done in a number of other public and
   private labs.  One of the strong motivations for this specification
   is to allow for this work to leave the lab, lab and to be applied in the
   field.

7.  Privacy Considerations

   The presence of the MUD URL in the QR code reveals the manufacturer
   of the device, the type or model of the device, and possibly the
   firmware version of the device.

   The MAC address of the device will also need to be present, and this
   is potentially Personally Identifiable Information (PII).  Such
   QRcodes QR
   codes should not be placed on the outside of the packaging, packaging and only
   on the device itself, ideally on a non-prominent part of the
   device. device
   (e.g., the bottom).

   The QR code sticker should not be placed on any part of the device
   that might become visible to machine vision systems in the same area.
   This includes security systems, robotic vacuum cleaners, or anyone
   taking a picture with a camera.  Such systems may store the
   picture(s) in such a way that a future viewer of the image will be
   able to decode the QR code, possibly through an assembly of multiple
   pictures.  Of course, the QR code is not, however, a certain
   indicator that the device is present, only that the QR code sticker
   that came with the device is present.

   The use of URL shorting services discussed in Section 3.2.4 may
   result in trading convenience and efficiency with privacy, since the
   service provider might leverage per-device or per-customer per-customer, short
   URLs to track and correlate requests.

8.  Security Considerations

8.1.  QR codes are not assurances Codes Are Not Assurances

   The mere presence of a QRcode QR code on a device does not in itself create
   any security issues on its own.  Neither an attached paper sticker or
   nor a laser etched laser-etched code in a plastic case will affect the device
   operation.

   The QRcode QR code is not active, active; in general, it is not in general able to communicate on
   using nearby networks.  It is conceivable that something more active
   is concealed in the sticker: sticker, e.g., an NFC or RFID tag for instance. a Radio Frequency
   Identification (RFID) tag.  But, any sticker could contain such a thing:
   thing, e.g., on some university campuses campuses, stickers are often used as
   part of political campaigns, campaigns and can be found attached all over the
   place.

   Security issues that this protocol create creates are related to assumptions
   that the presence of the QRcode QR code might imply.  The presence of the
   QRcode QR
   code may imply to some owners or network operators that the
   behaviour behavior
   of the device has been vetted by some authority.  It is here that
   some caution is required.

   A possibly bigger risk from application of MUD file stickers to
   devices is that they may begin to convey a sense of safety to users
   of the device.  The presence of the sticker, possibly with the logo
   of the physical establishment in which the device is located located, could
   convey to occupants of the establishment that this device is an
   official device.  For device, for instance, a university which that only deploys sensors
   on the university campus that have been vetted for compliance against
   a MUD definition.

   The risk is then of social engineering: engineering, e.g., any device with a reasonable
   looking QRcode
   reasonable-looking QR code may be seen as a trusted device (even
   though such trust is not justified based on that evidence.) evidence).  An
   attacker that wishes to infiltrate their own devices need only
   suitably camouflage the device with an appropriate sticker in order
   to convey legitimacy.

8.2.  MUD files can have signatures Files Can Have Signatures

   The network operator who takes the MUD file designated by the QRcode QR code
   needs to be careful that they are validating the signature on the MUD
   file.  Not only  The network operator needs to verify that the file is intact, but intact
   and that the signer of the file is authorized to sign MUD files for
   that vendor, or that the
   network operator has some trust if the a MUD file is a crowd sourced
   definition.  At the time of writing, crowd-sourced definition, they
   need to establish if it can be trusted.  [RFC8520] does not define
   any infrastructure to authenticate or authorize MUD file signers.

8.3.  URL Shortening services can change content Services Can Change Content

   If a URL shorterning shortening service is used, it is possible that the MUD
   Controller is
   controller will be redirected to another MUD file with different
   content.  The use of MUD signatures can detect attacks on the
   integrity of the file.  To do this, the MUD controller needs to be
   able to verify the signature on the file.

   If a Trust On First Use Trust-On-First-Use (TOFU) policy is used for signature trust
   anchors, then the URL shortening service can still attack, attack if it
   substitutes content and signature on the first use.  MUD controllers
   and the people operating them need to be cautious when using TOFU.

8.4.  MUD QR code stickers could be confused Code Stickers Could Be Confused

   Another issue with the stickers is that the wrong sticker could be
   applied to a device by a reseller or other another trusted party, either in
   error,
   error or via some physical or socially engineered attack against that
   party.  The network operator now onboards a device, device and applies what
   they think is a legitimate network policy for the device in their
   hands, only it is in fact a policy for another kind of device.

   Careful examination of stickers is in order!

8.5.  QR code can include Code Can Include a MAC address Address

   Inclusion of the device specific device-specific MAC address (described in
   Section 3.2.5) in the QRcode QR code makes use of the MUD code much easier easier,
   as it identifies the device specifically.  If the MAC address is not
   included, then a network operator, having the device in their hands,
   has to associate the policy with the device through some other
   interface.

   Despite the significant advantage of having the MAC address included,
   it is unlikely that third party third-party stickers will include that. it.  Including
   the MAC address requires that a unique sticker with a
   QRcode QR code be
   created for each device.  This is possible if the sticker is applied
   by a manufacturer: manufacturer; it is already common to have a serial number and
   MAC address on the outside of the device.  In that case, if the QRcode QR
   code is part of that sticker, then the customization problem is not
   that complex.

   For cases where a third party has produced the QRcode, QR code, it is likely
   that every device of a particular model will have the same QRcode QR code
   applied, omitting the MAC address.  This increases the possibility
   that the wrong policy will be applied to a device.

9.  IANA Considerations

   This document makes has no request for IANA actions.

10.  Acknowledgements

   This work was supported by the Canadian Internet Registration
   Authority (cira.ca).

11.  References

11.1.

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8520]  Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
              Description Specification", RFC 8520,
              DOI 10.17487/RFC8520, March 2019,
              <https://www.rfc-editor.org/info/rfc8520>.

   [SQRL]     Reverse Logistics Association, "SQRL Codes: Standardized
              Quick Response for Logistics, Using the 12N Data
              Identifier", February 2017,
              <https://rla.org/resource/12n-documentation>.

11.2.

10.2.  Informative References

   [chickenegg]
              Wikipedia, "Chicken or the egg", December 2019,
              <https://en.wikipedia.org/wiki/Chicken_or_the_egg>.

   [I-D.ietf-opsawg-mud-acceptable-urls]
              Richardson, M., Pan, W., and E. Lear, "Authorized update
              to MUD URLs", Work in Progress, Internet-Draft, draft-
              ietf-opsawg-mud-acceptable-urls-04, 6 October 2021,
              <https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-
              acceptable-urls-04.txt>.

   [ieee802-1AR] April 2022,
              <https://en.wikipedia.org/w/
              index.php?title=Chicken_or_the_egg&oldid=1081728488>.

   [IEEE.802.15.4]
              IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE Standard,
              Std. 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875,
              April 2016,
              <https://ieeexplore.ieee.org/document/7460875>.

   [IEEE802-1AR]
              IEEE, "IEEE 802.1AR Standard for Local and Metropolitan Area
              Networks - Secure Device Identifier",
              2009, <http://standards.ieee.org/findstds/
              standard/802.1AR-2009.html>. Identity", IEEE Std 802.1AR-2018,
              August 2018,
              <https://standards.ieee.org/ieee/802.1AR/6995/>.

   [isoiec18004]
              ISO/IEC, "Information technology - Automatic
              identification and data capture techniques - QR Code bar
              code symbology specification (ISO/IEC 18004)", specification", ISO/IEC 18004:2015,
              February 2015.

   [mh10]     "ANSI MH10.8.2 Committee", May 2021,     ANSI, "Data Identifier and Application Identifier
              Standard", ANSI MH10.8.2-2016, June 2016,
              <https://webstore.ansi.org/Standards/MHIA/ANSIMH102016>.

   [MUD-URLS] Richardson, M., Pan, W., and E. Lear, "Authorized update
              to MUD URLs", Work in Progress, Internet-Draft, draft-
              ietf-opsawg-mud-acceptable-urls-04, 6 October 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
              mud-acceptable-urls-04>.

   [MUDfiles] UNSW Sydney, "MUD Profiles", July 2019,
              <https://iotanalytics.unsw.edu.au/mud/>.

   [MUDgee]   Hamza, A.,   "MUDgee", commit f63a88d, July 2019,
              <https://github.com/ayyoob/mudgee>.

   [qrcode]   Wikipedia, "QR Code", December 2019,
              <https://en.wikipedia.org/wiki/QR_code>.

   [qrcodewebservice]
              Internet, "QR Code Generators", December 2019,
              <https://duckduckgo.com/?q=QR+code+web+generator>. code", April 2022,
              <https://en.wikipedia.org/w/
              index.php?title=QR_code&oldid=1082559657>.

   [qrencode] Fukuchi, K., "QR encode", December 2019,
              <https://fukuchi.org/works/qrencode/index.html.en>. "libqrencode", commit 715e29f, September 2020,
              <https://github.com/fukuchi/libqrencode>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
              and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
              May 2021, <https://www.rfc-editor.org/info/rfc8995>.

   [URLshorten]
              Wikipedia, "URL shortening", May 2021,
              <https://en.wikipedia.org/wiki/URL_shortening>. April 2022,
              <https://en.wikipedia.org/w/
              index.php?title=URL_shorteningg&oldid=1084979184>.

Acknowledgements

   This work was supported by the Canadian Internet Registration
   Authority (cira.ca).

Authors' Addresses

   Michael Richardson
   Sandelman Software Works
   Email: mcr+ietf@sandelman.ca

   Jacques Latour
   CIRA Labs
   Email: Jacques.Latour@cira.ca

   Hassan Habibi Gharakheili
   UNSW Sydney
   Email: h.habibi@unsw.edu.au