[要約] RFC 9238は、MUD定義を持たないデバイスに対してRFC 8520からMUD URLを読み込むプロトコルを提供し、インターネットコミュニティにそのメカニズムを通知し、相互運用性を可能にすることを目的としています。
Independent Submission M. Richardson
Request for Comments: 9238 Sandelman Software Works
Category: Informational J. Latour
ISSN: 2070-1721 CIRA Labs
H. Habibi Gharakheili
UNSW Sydney
May 2022
Loading Manufacturer Usage Description (MUD) URLs from QR Codes
QRコードからのメーカーの使用法の説明（泥）URL
Abstract
概要
This informational document details a protocol to load Manufacturer Usage Description (MUD) definitions from RFC 8520 for devices that do not have them integrated.
この情報ドキュメントは、統合されていないデバイスのRFC 8520の製造業者の使用法の説明（MUD）定義をロードするプロトコルを詳しく説明しています。
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.
このドキュメントは、このメカニズムをインターネットコミュニティに通知して、相互運用性を可能にし、関心がある場合は他の標準作業の基礎として機能するために公開されています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9238.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction
2. Terminology
3. Protocol
3.1. The SQRL Protocol
3.2. Manufacturer Usage Descriptions in SQRL
3.2.1. B000 Company Name
3.2.2. B001 Product Name
3.2.3. B002 Model Number
3.2.4. MUD URL Data Record
3.2.5. Device MAC Address
4. Applicability
5. Generic URL or Version-Specific URL
6. Crowd Supply of MUD Files
7. Privacy Considerations
8. Security Considerations
8.1. QR Codes Are Not Assurances
8.2. MUD Files Can Have Signatures
8.3. URL Shortening Services Can Change Content
8.4. MUD QR Code Stickers Could Be Confused
8.5. QR Code Can Include a MAC Address
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Authors' Addresses
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 communicate the MUD URL (i.e., the URL of the resulting MUD file in JSON [RFC8259]) to a network enforcement point: via DHCP, within an X.509 certificate extension, and via the Link Local Discovery Protocol (LLDP).
メーカーの使用法の説明（MUD）[RFC8520]は、Yangデータモデルを定義して、デバイスが正しく動作するために必要なアクセスの種類を表現します。このドキュメントは、デバイスが泥URL（つまり、JSONの結果の泥ファイルのURL [RFC8259]のURL）をネットワークの執行ポイントに通知する3つの方法をさらに定義します。ローカルディスカバリープロトコル（LLDP）をリンクします。
Each of the above mechanisms conveys the MUD URL in band and requires modifications to the device firmware. Most small Internet of Things (IoT) devices do not have LLDP and often have very restricted DHCP clients. Adding LLDP or DHCP options requires at least some minimal configuration change and possibly entirely new subsystems. Meanwhile, use of the PKIX certification extension only makes sense as part of a larger deployment based on an Initial Device Identifier (IDevID) [IEEE802-1AR], for instance, as described in [RFC8995].
上記の各メカニズムは、バンドの泥URLを伝え、デバイスファームウェアの変更が必要です。ほとんどの小さなモノのインターネット（IoT）デバイスにはLLDPがなく、多くの場合、DHCPクライアントが非常に制限されています。LLDPまたはDHCPオプションを追加するには、少なくとも最小限の構成変更と、おそらくまったく新しいサブシステムが必要です。一方、PKIX認証拡張機能の使用は、[RFC8995]で説明されているように、初期デバイス識別子（IDEVID）[IEEE802-1AR]に基づくより大きな展開の一部としてのみ理にかなっています。
In the above cases, these mechanisms can only be implemented by persons with access to modify and update the firmware of the device.
上記の場合、これらのメカニズムは、デバイスのファームウェアを変更および更新するためにアクセスできる人によってのみ実装できます。
In the meantime, there is a chicken or egg problem [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 or disseminate URLs.
それまでの間、鶏肉や卵の問題があります[Chickenegg]。つまり、メーカーは、これらのURLを使用しているゲートウェイがないと考えているため、製品に泥URLを含めるように動機付けられていません（したがって、そうではないでしょう）。同時に、Gatewaysには、製品がない、または普及していると考えられているため、Mud URLを処理するコードを含めるインセンティブはほとんどありません（したがって、そうではない可能性があります）。
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.
このドキュメントで説明されているプロトコルにより、デバイスに物理的にアクセスできる人は、後でエンドユーザーがスキャンできる泥URLへの参照を貼り付けることができます。
The QR-based protocol is presented as a convenient alternative when the mechanisms from [RFC8520] are not available to use on the device or the gateway.
QRベースのプロトコルは、[RFC8520]のメカニズムがデバイスまたはゲートウェイで使用できない場合に便利な代替品として提示されます。
Affixing a sticker can be done by:
ステッカーを貼り付けてください。
* the marketing department of the manufacturer,
* メーカーのマーケティング部門、
* an outsourced assembler plant,
* アウトソーシングされたアセンブラープラント、
* value-added resellers (perhaps in response to a local request for proposal (RFP)),
* 付加価値再販業者（おそらく、提案のためのローカルリクエスト（RFP）に応じて）、
* a company importing the product (possibly to comply with a local regulation),
* 製品を輸入する会社（おそらく地元の規制に準拠するため）、
* a network administrator (perhaps before sending devices home with employees or to remote sites), and
* ネットワーク管理者（おそらく、従業員またはリモートサイトにデバイスを家に送る前）、および
* a retailer as a value-added service.
* 付加価値サービスとしての小売業者。
QR codes are informally described in [qrcode] and formally defined in [isoiec18004]. The protocol described in this document uses a 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].
QRコードは[QRCode]で非公式に説明され、[ISOIEC18004]で正式に定義されています。このドキュメントで説明されているプロトコルは、QRコードを使用して泥URLをエンコードします。具体的には、プロトコルは、Reverse Logistics Associationのロジスティクスのための標準化されたクイック応答[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 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, or recycling of the components of the product.
SQRLコードは、多くの状況に対処するために、特にデバイスの終末期処理のために、ステッカーまたはレーザーエッチングを介してデバイスに配置されています。取り組みの背後にある重要なアイデアは、製品を明確に特定することで、製品のコンポーネントの適切な処分、改修、またはリサイクルが可能になることです。
There are also use cases for SQRL in which the codes are used as part of regular maintenance for a product.
コードが製品の定期的なメンテナンスの一部として使用されるSQRLのユースケースもあります。
SQRL is an application of the 12N Data Identifier system specified by the ANSI MH10.8.2 Committee [mh10] in a format appropriate for QR codes, as well as other things like Normalization Form C (NFC) transmissions.
SQRLは、QRコードに適した形式でANSI MH10.8.2委員会[MH10]によって指定された12Nデータ識別子システムの適用と、正規化フォームC（NFC）送信などの他のものです。
QR code generators are available as web services or as programs, such as [qrencode].
QRコードジェネレーターは、[QRENCODE]などのWebサービスまたはプログラムとして利用できます。
Section 5 summarizes the considerations contained in "Updating files vs Updating MUD URLs" (Section 7.1 of [MUD-URLS]). Due to the immutable nature of the QR code, MUD URLs in this document will need to be non-firmware specific.
セクション5では、「ファイルの更新対泥URLの更新」（[ムードURL]のセクション7.1）に含まれる考慮事項をまとめたものです。QRコードの不変の性質により、このドキュメントの泥URLは、非企業固有である必要があります。
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.
このドキュメントはIETF標準トラックの公開ではありませんが、実装者に指示の明確さを提供するために規範的言語の規則を採用しています。キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "of" bould "、" becommended "、" bodement "、" may "、" optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Readers should be familiar with the terminology in [RFC8520], including: MUD file, MUD URL, manufacturer, MUD manager, and controller.
読者は、[RFC8520]の用語に精通している必要があります。
The QR code protocol builds upon the work by [SQRL]. That protocol is very briefly described in Section 3.1. Then, the list of needed Data Records to be filled in is explained.
QRコードプロトコルは、[SQRL]による作業に基づいています。そのプロトコルについては、セクション3.1で非常に簡単に説明しています。次に、記入する必要のあるデータレコードのリストについて説明します。
[SQRL] documents an octet protocol that can be efficiently encoded into QR codes using a sequence of US-ASCII bytes, plus six control codes (see Section 3.1 of [SQRL]):
[SQRL]は、一連のUS-ASCIIバイトを使用してQRコードに効率的にエンコードできるオクテットプロトコルと、6つの制御コードを使用して文書化します（[SQRL]のセクション3.1を参照）：
* <RS> Record Separator (US-ASCII 30)
* <EoT> End of Transmission (US-ASCII 4)
* <FS> Field Separator (US-ASCII 28)
* <GS> Group Separator (US-ASCII 29)
* <US> Unit Separator (US-ASCII 31)
* Concatenation Operator (US-ASCII 43: "+")
* 連結演算子（US-ASCII 43： ""）
Section 7.2 of [SQRL] gives the details, which can be summarized as:
[SQRL]のセクション7.2に詳細を示します。これは次のように要約できます。
1. The QR code header starts with:
1. QRコードヘッダーは以下で始まります。
"[)>" <RS> "06" <GS> "12N"
2. Include one or more Data Records. This consists of a four-letter Field Identifier, followed by US-ASCII characters terminated with a <Unit Separator>.
2. 1つ以上のデータレコードを含めます。これは、4文字のフィールド識別子で構成され、その後に<ユニットセパレーター>で終了したUS-ASCII文字が続きます。
3. End with:
3. 終了：
<RS><EoT>
Additionally, there are optional flags that may be present in every Data Record, as described in Section 7.4 of [SQRL]. These flags have no bearing on MUD processing. A parser that is only collecting MUD URLs will not need to parse those flags. A general-purpose SQRL parser will need more complexity.
さらに、[SQRL]のセクション7.4で説明されているように、すべてのデータレコードに存在する可能性のあるオプションのフラグがあります。これらのフラグには、泥処理には関係がありません。泥URLのみを収集しているパーサーは、これらのフラグを解析する必要はありません。汎用SQRLパーサーには、より複雑なものが必要になります。
Field Separator characters are used in SQRL to signify the beginning of a new unit of data. A 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.
フィールドセパレーター文字は、SQRLで使用され、新しいデータユニットの開始を意味します。フィールドセパレーターに遭遇し、まだ正しい泥情報を収集していない泥固有のパーサーは、これまでに収集されたキャラクターを無視してから再起動する必要があります。
Environment records, as described in 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 and MAY be ignored.
[SQRL]のセクション7.4で説明されているように、環境記録は、特別なフィールド識別子を備えたフィールドとまったく同じように見え、機能します。彼らは泥情報を探すときに目的を果たさず、無視されるかもしれません。
The B000 Data Record is mandatory in [SQRL]. It MUST be in 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, the MUD file can contain arbitrary UTF-8 for this name, while the SQRL files are expected to be 7-bit US-ASCII.
B000データレコードは[SQRL]で必須です。それは米国ASCII表現にあるに違いありません。それは会社またはブランド名の代表でなければなりません。MUDファイルのIETF-MUD/MUD/MFG-NAMEと一致するはずです。ただし、MUDファイルにはこの名前の任意のUTF-8を含めることができますが、SQRLファイルは7ビットUS-ASCIIであると予想されます。
The B001 Data Record is optional in [SQRL]. It is the Product Name in US-ASCII. Its presence is RECOMMENDED. Some third parties that create QR code stickers might not know the product name with 100% certainty and MAY prefer to omit this rather than create further confusion.
B001データレコードは[SQRL]でオプションです。それはUS-ASCIIの製品名です。その存在が推奨されます。QRコードステッカーを作成する一部の第三者は、100％確実に製品名を知らない場合があり、さらに混乱を引き起こすのではなく、これを省略することを好む場合があります。
The B002 Data Record is optional in [SQRL] but is MANDATORY in this profile. It is the Model Name in 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 UTF-8 for the model-name, while the SQRL files are expected to be 7-bit US-ASCII.
B002データレコードは[SQRL]でオプションですが、このプロファイルでは必須です。これは、us-asciiのモデル名です。そのエントリがMUDファイルに存在する場合、MUDファイルのオプションのIETF-MUD/MUD/MODEL-NAMEと一致するはずです。MUDファイルには、モデル名の任意のUTF-8を含めることができますが、SQRLファイルは7ビットのUS-ASCIIであると予想されます。
If a third party that is creating QR codes cannot locate an official model number when creating their MUD file and QR code, then the third party SHOULD make one up.
QRコードを作成している第三者が、MUDファイルとQRコードを作成するときに公式モデル番号を見つけることができない場合、第三者は1つを作成する必要があります。
A new Field Identifier has been assigned by the Reverse Logistics Association, which is "M180". This record MUST be filled with the MUD URL.
新しいフィールド識別子は、「M180」というリバースロジスティクス協会によって割り当てられています。このレコードは泥URLで満たされている必要があります。
Short URLs are easier to encode into a QR code because they require fewer pixels of QR code. More content in the QR code requires a bigger image.
短いURLは、QRコードのピクセルが少ないため、QRコードにエンコードしやすくなります。QRコードのコンテンツを増やすには、より大きな画像が必要です。
Use of URL shortening services (see [URLshorten]) can be useful, provided that the service is stable throughout the lifetime of the device and QR code and that the privacy stance of the service is well understood. The Security Considerations section of [RFC3986] applies, particularly Section 7.1.
URL短縮サービスの使用（[urlshortenを参照]）は、デバイスとQRコードの生涯を通じてサービスが安定しており、サービスのプライバシースタンスがよく理解されていることを条件に、有用です。[RFC3986]のセキュリティに関する考慮事項セクション、特にセクション7.1が適用されます。
Section 8.1 of [SQRL] also has some good advice on longevity concerns with URLs.
[SQRL]のセクション8.1には、URLに関する長寿の懸念に関する良いアドバイスもあります。
The URL provided MUST NOT have a query (?) portion present. If one is present, the query portion MUST be removed before processing.
提供されるURLには、クエリ（？）部分が存在してはなりません。存在する場合、処理する前にクエリ部分を削除する必要があります。
If a 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.
Media Access Control（MAC）アドレスが一意のデバイス識別子（可能であれば推奨される）として使用される場合、このデータレコードに含める必要があります。
Section 9.10 of [SQRL] defines the Data Record "M06C" as the MAC address. No format for the MAC address is provided in that document.
[SQRL]のセクション9.10は、データレコード「M06C」をMACアドレスとして定義しています。そのドキュメントには、Macアドレスの形式は提供されていません。
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 64-bit Extended Unique Identifier (EUI-64) format used in [IEEE.802.15.4] and some next generation Ethernet proposals). In this document, it is RECOMMENDED that uppercase hexadecimal letters be used.
このドキュメントでは、スペースや句読点なしで12（または16）ヘックスオクテットを使用することをお勧めします。（[IEEE.802.15.4]およびいくつかの次世代イーサネット提案で使用されるIEEE 64ビット拡張ユニークな識別子（EUI-64）形式で16個のオクテットが使用されます）。このドキュメントでは、大文字の16進状の文字を使用することをお勧めします。
Parsers that find punctuation (such as colons (":"), dashes ("-"), US-ASCII Space (32), US-ASCII TAB (0), US-ASCII linefeed (10), or US-ASCII carriage return (13)) MUST skip over the punctuation. Parsers MUST tolerate hexadecimal in uppercase, lowercase, and even mixed case. Systems SHOULD canonicalize it to uppercase.
句読点（コロン（ "："）、ダッシュ（ " - "）、us-asciiスペース（32）、us-ascii tab（0）、us-ascii linefeed（10）、またはus-asciiキャリッジなどのパーサーreturn（13））は、句読点をスキップする必要があります。パーサーは、大文字、小文字、さらには混合ケースで16進数を容認する必要があります。システムはそれを大文字に正規化する必要があります。
The use of stickers to convey MUD URLs would appear to have little value when the stickers are applied by the 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, the installer handling the device would scan the QR code to get the appropriate MUD file reference and have to input the associated MAC address as well.
ステッカーがエンドユーザー組織によって適用され、同じで消費される場合、泥URLを伝えるためのステッカーの使用はほとんど価値がないように見えます。これは、QRコードにデバイスMACアドレスが含まれていない場合に特に当てはまります。このような状況では、デバイスを処理するインストーラーがQRコードをスキャンして適切なMUDファイル参照を取得し、関連するMACアドレスも入力する必要があります。
In such a case, one might wonder why the installer couldn't just enter the appropriate MAC address and select the appropriate Access Control Lists (ACLs) for the device. Then a MUD file or QR code to convey the MAC address would not be needed. However, the use of a MUD file (or QR code or other way to convey the MAC address) is advantageous because it offers several layers of indirection:
そのような場合、インストーラーが適切なMACアドレスを入力して、デバイスの適切なアクセス制御リスト（ACLS）を選択できなかった理由を疑問に思うかもしれません。次に、MACアドレスを伝えるための泥ファイルまたはQRコードは必要ありません。ただし、泥ファイル（またはQRコードまたはMACアドレスを伝えるためのその他の方法）の使用は、間接的ないくつかの層を提供するため有利です。
1. The ACLs for a given device may be added or removed.
1. 特定のデバイスのACLSを追加または削除することができます。
2. The ACLs may refer to DNS names, which may map to IPv4 or IPv6 addresses.
2. ACLSは、IPv4またはIPv6アドレスにマッピングできるDNS名を参照する場合があります。
3. The entire file may be replaced and may also include supply chain information, such as Software Bill of Materials (SBOM).
3. ファイル全体が置き換えられる場合があり、ソフトウェア請求書（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.
さらに、新しいデバイス（MACアドレス）をMUDファイルマッピングにインストールするメカニズムは、インストールを行っている人が他のネットワークセキュリティ設定を変更できるようにする必要はありません。
MUD URLs that are communicated in band by the device and that are programmed into the device's firmware may provide a firmware-specific version of the MUD URL. The advantage of this is that the resulting ACLs enforced in the network are specific to the needs of that version of the firmware.
デバイスによってバンドで通信され、デバイスのファームウェアにプログラムされている泥URLは、MUD URLのファームウェア固有のバージョンを提供する場合があります。これの利点は、ネットワークで実施される結果のACLがそのバージョンのファームウェアのニーズに固有であることです。
A MUD URL that is affixed to the device with a sticker or etched into the case cannot be changed.
ステッカーでデバイスに貼られたり、ケースにエッチングされたりする泥URLを変更することはできません。
Given the considerations of "Updating MUD URLs vs Updating MUD files" (Section 6.1 of [MUD-URLS]), it is prudent to use a MUD URL that points to a MUD file that will only have new features added over time and never have features removed. To recap, if a feature is removed from the firmware and the MUD file still permits it, then there is a potential hole that could perhaps be exploited. The opposite situation, where a MUD file wrongly forbids 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.
「MUD URLとMUDファイルの更新の更新」（[ムードURLS]のセクション6.1）の考慮事項を考えると、時間の経過とともに新しい機能が追加されていない泥ファイルを指す泥URLを使用することは賢明です。削除された機能。要約すると、ファームウェアから機能が削除され、泥ファイルがまだ許可されている場合、おそらく悪用される可能性のある穴があります。泥のファイルが誤って何かを禁止するという反対の状況は、セキュリティシステムで誤検知につながり、これがシステム全体が無視されるという証拠があります。コアインフラストラクチャへの攻撃を防ぐことは、ACLを完璧にするよりも重要かもしれません。
When the firmware eventually receives built-in MUD URL support, then a more-specific URL may be used.
ファームウェアが最終的に組み込みのMUD URLサポートを受信すると、より固有のURLが使用される場合があります。
Note that in many cases, it will be third parties who are generating these QR codes, so the MUD file may be hosted by the third party.
多くの場合、これらのQRコードを生成しているのは第三者であるため、泥ファイルは第三者によってホストされる可能性があることに注意してください。
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], 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.
執筆時点では、IETF泥は新しいIETF提案標準です。したがって、IoTデバイスメーカーは、デバイスにまだ泥プロファイルを提供していません。ニューサウスウェールズ大学（UNSWシドニー）の研究グループは、Mudgee [Mudgee]と呼ばれるオープンソースツールを開発しました。より速く、より簡単で、より正確に処理します。生成されたプロファイルの完全性は、入力トラフィックトレースの完全性にのみ依存することに注意してください。マッジーは、見られるすべての活動が意図され、良性であると仮定しています。
UNSW researchers have applied MUDgee to about 30 consumer IoT devices from their lab testbed and publicly released their MUD files [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 organizational policies.
UNSWの研究者は、ラボのテストベッドから約30の消費者IoTデバイスにマッジーを適用し、泥ファイル[Mudfiles]を公開しています。Mudgeeは、IoTメーカーが泥プロファイルの開発と検証を支援することができ、これらのデバイスの採用者が組織のポリシーと互換性があることを確認するのを支援します。
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 and to be applied in the field.
同様のプロセスは、他の多くのパブリックラボおよび民間ラボで行われています。この仕様の強い動機の1つは、この作業がラボを離れ、フィールドに適用できるようにすることです。
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.
QRコードに泥URLが存在すると、デバイスのメーカー、デバイスのタイプまたはモデル、およびおそらくデバイスのファームウェアバージョンが明らかになります。
The MAC address of the device will also need to be present, and this is potentially Personally Identifiable Information (PII). Such QR codes should not be placed on the outside of the packaging and only on the device itself, ideally on a non-prominent part of the device (e.g., the bottom).
デバイスのMACアドレスも存在する必要があり、これは潜在的に個人を特定できる情報（PII）です。このようなQRコードは、パッケージの外側とデバイス自体のみに配置しないでください。理想的には、デバイスの非普及部分（底部など）にはありません。
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.
QRコードステッカーは、同じ領域のマシンビジョンシステムに表示される可能性のあるデバイスのどの部分にも配置しないでください。これには、セキュリティシステム、ロボットバキュームクリーナー、またはカメラで写真を撮っている人が含まれます。このようなシステムは、画像の将来の視聴者が、おそらく複数の写真のアセンブリを介してQRコードをデコードできるように、画像を保存する場合があります。もちろん、QRコードは、デバイスが存在するという特定の指標ではなく、デバイスに付属しているQRコードステッカーが存在することだけです。
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, short URLs to track and correlate requests.
セクション3.2.4で議論されているURLショートサービスの使用は、サービスプロバイダーがデバイスごとまたは顧客ごとに活用する可能性があるため、プライバシーとの利便性と効率を取引する可能性があります。
The mere presence of a QR code on a device does not in itself create any security issues on its own. Neither an attached paper sticker nor a laser-etched code in a plastic case will affect the device operation.
デバイス上のQRコードの単なる存在自体は、それ自体でセキュリティの問題を作成しません。添付の紙ステッカーも、プラスチックケースのレーザーエッチングコードもデバイスの動作に影響しません。
The QR code is not active; in general, it is not able to communicate using nearby networks. It is conceivable that something more active is concealed in the sticker, e.g., an NFC or a Radio Frequency Identification (RFID) tag. But, any sticker could contain such a thing, e.g., on some university campuses, stickers are often used as part of political campaigns and can be found attached all over the place.
QRコードはアクティブではありません。一般に、近くのネットワークを使用して通信できません。よりアクティブなものがステッカー、たとえばNFCまたは無線周波数識別（RFID）タグに隠されていると考えられます。しかし、どんなステッカーにもそのようなものが含まれている可能性があります。たとえば、一部の大学のキャンパスでは、ステッカーが政治キャンペーンの一部としてよく使用され、あちこちに添付されることがよくあります。
Security issues that this protocol creates are related to assumptions that the presence of the QR code might imply. The presence of the QR code may imply to some owners or network operators that the behavior of the device has been vetted by some authority. It is here that some caution is required.
このプロトコルが作成するセキュリティの問題は、QRコードの存在が暗示される可能性のある仮定に関連しています。QRコードの存在は、一部の所有者またはネットワークオペレーターに、デバイスの動作が何らかの権限によって審査されていることを意味する場合があります。ここで、ある程度の注意が必要です。
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, could convey to occupants of the establishment that this device is an official device, for instance, a university 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, e.g., any device with a reasonable-looking QR code may be seen as a trusted device (even though such trust is not justified based on that 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.
その場合、リスクはソーシャルエンジニアリングのものです。たとえば、合理的に見えるQRコードを備えたデバイスは、信頼できるデバイスと見なされる場合があります（そのような信頼はその証拠に基づいて正当化されませんが）。独自のデバイスに潜入したい攻撃者は、正当性を伝えるために適切なステッカーでデバイスを適切にカモフラージュするだけではありません。
The network operator who takes the MUD file designated by the QR code needs to be careful that they are validating the signature on the MUD file. The network operator needs to verify that the file is intact and that the signer of the file is authorized to sign MUD files for that vendor, or if a MUD file is a 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.
QRコードによって指定された泥ファイルを取得するネットワークオペレーターは、泥ファイルの署名を検証していることに注意する必要があります。ネットワークオペレーターは、ファイルが無傷であり、ファイルの署名者がそのベンダーの泥ファイルに署名することを許可されていることを確認する必要があります。または、泥ファイルがクラウドソースの定義である場合、信頼できるかどうかを確立する必要があります。[RFC8520]は、泥ファイル署名者を認証または承認するインフラストラクチャを定義していません。
If a URL shortening service is used, it is possible that the MUD 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.
URL短縮サービスを使用すると、泥コントローラーが異なるコンテンツを持つ別の泥ファイルにリダイレクトされる可能性があります。泥署名の使用は、ファイルの完全性に対する攻撃を検出できます。これを行うには、泥コントローラーがファイルの署名を確認できる必要があります。
If a Trust-On-First-Use (TOFU) policy is used for signature trust anchors, then the URL shortening service can still 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.
署名の信頼アンカーに信頼対1回の使用（豆腐）ポリシーが使用されている場合、URL短縮サービスは、最初の使用にコンテンツと署名を置き換えた場合でも攻撃できます。泥コントローラーとそれらを操作する人々は、豆腐を使用する際に慎重にする必要があります。
Another issue with the stickers is that the wrong sticker could be applied to a device by a reseller or another trusted party, either in error or via some physical or socially engineered attack against that party. The network operator now onboards a 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.
ステッカーのもう1つの問題は、間違ったステッカーを、誤って、またはその当事者に対する物理的または社会的に設計された攻撃を介して、再販業者または別の信頼できる当事者によってデバイスに適用できることです。ネットワークオペレーターは現在、デバイスを搭載しており、デバイスの正当なネットワークポリシーであると思われるものを手の中で適用します。実際、別の種類のデバイスのポリシーです。
Careful examination of stickers is in order!
ステッカーの慎重な検査が適切です！
Inclusion of the device-specific MAC address (described in Section 3.2.5) in the QR code makes use of the MUD code much 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.
QRコードにデバイス固有のMACアドレス（セクション3.2.5で説明）を含めることで、デバイスを具体的に識別するため、泥コードをはるかに簡単に利用できます。MACアドレスが含まれていない場合、デバイスを手にするネットワークオペレーターは、他のインターフェイスを介してデバイスにポリシーを関連付ける必要があります。
Despite the significant advantage of having the MAC address included, it is unlikely that third-party stickers will include it. Including the MAC address requires that a unique sticker with a QR code be created for each device. This is possible if the sticker is applied by a manufacturer; it is already common to have a serial number and MAC address on the outside of the device. In that case, if the QR code is part of that sticker, then the customization problem is not that complex.
MACアドレスを含めるという大きな利点にもかかわらず、サードパーティのステッカーがそれを含めることはまずありません。MACアドレスを含めるには、各デバイスにQRコードを備えた一意のステッカーを作成する必要があります。これは、ステッカーがメーカーによって適用されている場合に可能です。デバイスの外側にシリアル番号とMACアドレスを持つことがすでに一般的です。その場合、QRコードがそのステッカーの一部である場合、カスタマイズの問題はそれほど複雑ではありません。
For cases where a third party has produced the QR code, it is likely that every device of a particular model will have the same QR code applied, omitting the MAC address. This increases the possibility that the wrong policy will be applied to a device.
サードパーティがQRコードを作成した場合、特定のモデルのすべてのデバイスが同じQRコードを適用してMACアドレスを省略している可能性があります。これにより、間違ったポリシーがデバイスに適用される可能性が高まります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<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>.
[RFC8520] Lear、E.、Droms、R。、およびD. Romascanu、「メーカーの使用説明仕様」、RFC 8520、DOI 10.17487/RFC8520、2019年3月、<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>.
[SQRL]リバースロジスティクス協会、「SQRLコード：12Nデータ識別子を使用したロジスティクスの標準化されたクイック応答」、2017年2月、<https://rla.org/resource/12n-documentation>。
[chickenegg] Wikipedia, "Chicken or the egg", April 2022, <https://en.wikipedia.org/w/ index.php?title=Chicken_or_the_egg&oldid=1081728488>.
[Chickenegg] Wikipedia、「Chicken or the Egg」、2022年4月、<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 Std. 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875, April 2016, <https://ieeexplore.ieee.org/document/7460875>.
[IEEE.802.15.4] IEEE、「低料金のワイヤレスネットワークのIEEE標準」、IEEE STD。802.15.4-2015、doi 10.1109/ieeestd.2016.7460875、2016年4月、<https://ieeexplore.ieee.org/document/7460875>。
[IEEE802-1AR] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity", IEEE Std 802.1AR-2018, August 2018, <https://standards.ieee.org/ieee/802.1AR/6995/>.
[IEEE802-1AR] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - 安全なデバイスアイデンティティ」、IEEE STD 802.1AR-2018、2018年8月、<https://standards.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:2015, February 2015.
[ISOIEC18004] ISO/IEC、「情報技術 - 自動識別とデータキャプチャテクニック - QRコードバーコードシンボルの仕様」、ISO/IEC 18004：2015、2015年2月。
[mh10] ANSI, "Data Identifier and Application Identifier Standard", ANSI MH10.8.2-2016, June 2016, <https://webstore.ansi.org/Standards/MHIA/ANSIMH102016>.
[MH10] ANSI、「データ識別子およびアプリケーション識別子標準」、ANSI MH10.8.2-2016、2016年6月、<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>.
[Mud-urls] Richardson、M.、Pan、W。、およびE. Lear、「Mud URLの認可された更新」、Work in Progress、Internet-Draft、Draft-Itopsawg-Mud-Actecable-urls-04、2021年10月6日、<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-apicable-urls-04>。
[MUDfiles] UNSW Sydney, "MUD Profiles", <https://iotanalytics.unsw.edu.au/mud/>.
[Mudfiles] UNSW Sydney、「Mud Profiles」、<https://iotanalytics.unsw.edu.au/mud/>。
[MUDgee] "MUDgee", commit f63a88d, July 2019, <https://github.com/ayyoob/mudgee>.
[Mudgee] "Mudgee"、commit f63a88d、2019年7月、<https://github.com/ayyob/mudgee>。
[qrcode] Wikipedia, "QR code", April 2022, <https://en.wikipedia.org/w/ index.php?title=QR_code&oldid=1082559657>.
[QRCode] Wikipedia、「QR Code」、2022年4月、<https://en.wikipedia.org/w/ index.php？title = qr_code＆oldid = 1082559657>。
[qrencode] "libqrencode", commit 715e29f, September 2020, <https://github.com/fukuchi/libqrencode>.
[qrencode] "libqrencode"、commit 715e29f、2020年9月、<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>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、DOI 10.17487/RFC3986、2005年1月、<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>.
[RFC8259] Bray、T.、ed。、「JavaScriptオブジェクト表記（JSON）データインターチェンジ形式」、STD 90、RFC 8259、DOI 10.17487/RFC8259、2017年12月、<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>.
[RFC8995] Pritikin、M.、Richardson、M.、Eckert、T.、Behringer、M.、およびK. Watsen、「Bootstrapping Remote Secure Key Infrastructure（BRSKI）」、RFC 8995、DOI 10.17487/RFC8995、2021年5月、<https://www.rfc-editor.org/info/rfc8995>。
[URLshorten] Wikipedia, "URL shortening", April 2022, <https://en.wikipedia.org/w/ index.php?title=URL_shorteningg&oldid=1084979184>.
[urlshorten] wikipedia、 "url短縮"、2022年4月、<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).
この作業は、カナダのインターネット登録局（CIRA.CA）によってサポートされていました。
Authors' Addresses
著者のアドレス
Michael Richardson Sandelman Software Works Email: mcr+ietf@sandelman.ca
Michael Richardson Sandelman Software Works Email：mcr ietf@sandelman.ca
Jacques Latour CIRA Labs Email: Jacques.Latour@cira.ca
Jacques Latour Cira Labsメール：jacques.latour@cira.ca
Hassan Habibi Gharakheili UNSW Sydney Email: h.habibi@unsw.edu.au
Hassan Habibi Gharakheili UNSW Sydney Email：h.habibi@unsw.edu.au