[要約] RFC 9031は、6TiSCHネットワークにおけるデバイスの安全な参加を可能にするためのプロトコル、Constrained Join Protocol (CoJP)に関するものです。このプロトコルの目的は、リソースが限られたデバイス間でのセキュアな通信とネットワークへの参加を効率的に行うことにあります。利用場面としては、IoT環境やスマートシティ、工場など、セキュリティと効率が求められる低電力ワイヤレスネットワークが挙げられます。
Internet Engineering Task Force (IETF) M. Vučinić, Ed.
Request for Comments: 9031 Inria
Category: Standards Track J. Simon
ISSN: 2070-1721 Analog Devices
K. Pister
University of California Berkeley
M. Richardson
Sandelman Software Works
May 2021
Constrained Join Protocol (CoJP) for 6TiSCH
6Tischの制約付き結合プロトコル（COJP）
Abstract
概要
This document describes the minimal framework required for a new device, called a "pledge", to securely join a 6TiSCH (IPv6 over the Time-Slotted Channel Hopping mode of IEEE 802.15.4) network. The framework requires that the pledge and the JRC (Join Registrar/ Coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network, and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and it describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework.
このドキュメントでは、「Predge」と呼ばれる新しいデバイスに必要な最小限のフレームワークについて、6Tisch（IEEE 802.15.4のタイムスロットチャネルホッピングモードにわたってIPv6）ネットワークを安全に結合します。フレームワークには、PREDGEとJRC（JOIN REGISTRAR /コーディネータ、中央エンティティ）が必要です。対称キーを共有します。このキーのプロビジョニング方法はこの文書の範囲外です。単一のCOAP（制約付きアプリケーションプロトコル）を通じて、OSCOREによって保護された要求応答エクスプレス（拘束されたRESTFUL環境のためのオブジェクトセキュリティ）、Predge要求はネットワークへの入場を要求し、JRCはそれをリンク層のキー化された材料および他のパラメータで構成します。 JRCは、OSCOREによって保護された別の要求応答交換を通じてパラメータをいつでも更新することができます。この仕様は、制約付き結合プロトコルとそのCBOR（簡潔なバイナリオブジェクト表現）データ構造を定義し、この結合プロセスのために6tisch通信スタックの残りの部分を安全な方法で行う方法を説明します。この最小限のフレームワークの上に追加のセキュリティメカニズムを追加することができます。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、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/rfc9031.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9031で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. Provisioning Phase
4. Join Process Overview
4.1. Step 1 - Enhanced Beacon
4.2. Step 2 - Neighbor Discovery
4.3. Step 3 - Constrained Join Protocol (CoJP) Execution
4.4. The Special Case of the 6LBR Pledge Joining
5. Link-Layer Configuration
5.1. Distribution of Time
6. Network-Layer Configuration
6.1. Identification of Unauthenticated Traffic
7. Application-Layer Configuration
7.1. Statelessness of the JP
7.2. Recommended Settings
7.3. OSCORE
8. Constrained Join Protocol (CoJP)
8.1. Join Exchange
8.2. Parameter Update Exchange
8.3. Error Handling
8.4. CoJP Objects
8.5. Recommended Settings
9. Security Considerations
10. Privacy Considerations
11. IANA Considerations
11.1. Constrained Join Protocol (CoJP) Parameters
11.2. Constrained Join Protocol (CoJP) Key Usage
11.3. Constrained Join Protocol (CoJP) Unsupported Configuration
Codes
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Example
Appendix B. Lightweight Implementation Option
Acknowledgments
Authors' Addresses
This document defines a "secure join" solution for a new device, called a "pledge", to securely join a 6TiSCH network. The term "secure join" refers to network access authentication, authorization, and parameter distribution as defined in [RFC9030]. The Constrained Join Protocol (CoJP) defined in this document handles parameter distribution needed for a pledge to become a joined node. Mutual authentication during network access and implicit authorization are achieved through the use of a secure channel as configured according to this document. This document also specifies a configuration of different layers of the 6TiSCH protocol stack that reduces the Denial of Service (DoS) attack surface during the join process.
この文書は、6Tischネットワークを安全に結合するために、「Predge」と呼ばれる新しいデバイスに対する「セキュア参加」ソリューションを定義します。「Secure Join」という用語は、[RFC9030]で定義されているネットワークアクセス認証、承認、およびパラメータ配布を指します。この文書で定義されている制約付き結合プロトコル（COJP）は、誓約が結合されたノードになるために必要なパラメータ分布を処理します。ネットワークアクセス中の相互認証および暗黙の認証は、この文書に従って構成されているように安全なチャネルを使用することによって達成されます。この文書はまた、結合プロセス中にサービス拒否（DOS）攻撃面を縮小する6tischプロトコルスタックの異なる層の構成も指定しています。
This document presumes a 6TiSCH network as described by [RFC7554] and [RFC8180]. By design, nodes in a 6TiSCH network [RFC7554] have their radio turned off most of the time in order to conserve energy. As a consequence, the link used by a new device for joining the network has limited bandwidth [RFC8180]. The secure join solution defined in this document therefore keeps the number of over-the-air exchanges to a minimum.
この文書は、[RFC7554]と[RFC8180]で説明されている6Tischネットワークと推定されます。設計では、6Tischネットワークのノード[RFC7554]エネルギーを節約するために、ラジオがほとんどの時間をオフにしました。結果として、ネットワークに参加するための新しい装置によって使用されるリンクは限られた帯域幅[RFC8180]を有する。したがって、この文書で定義されているセキュア結合ソリューションは、空気の越境交換の数を最小限に抑えます。
The microcontrollers at the heart of 6TiSCH nodes have small amounts of code memory. It is therefore paramount to reuse existing protocols available as part of the 6TiSCH stack. At the application layer, the 6TiSCH stack already relies on CoAP [RFC7252] for web transfer and on OSCORE [RFC8613] for its end-to-end security. The secure join solution defined in this document therefore reuses those two protocols as its building blocks.
6tischノードの中心部のマイクロコントローラは、少量のコードメモリを有する。したがって、6Tischスタックの一部として使用可能な既存のプロトコルを再利用することは最優先です。アプリケーション層では、6TischスタックはすでにWeb転送用のCOAP [RFC7252]、およびエンドツーエンドのセキュリティのためのOSCCOR [RFC8613]に依存しています。したがって、このドキュメントで定義されているセキュア結合ソリューションは、それらの2つのプロトコルをビルディングブロックとして再利用します。
CoJP is a generic protocol that can be used as-is in all modes of IEEE Std 802.15.4 [IEEE802.15.4], including the Time-Slotted Channel Hopping (TSCH) mode on which 6TiSCH is based. CoJP may also be used in other (low-power) networking technologies where efficiency in terms of communication overhead and code footprint is important. In such a case, it may be necessary to define through companion documents the configuration parameters specific to the technology in question. The overall process is described in Section 4, and the configuration of the stack is specific to 6TiSCH.
COJPは、6tischが基づくタイムスロットチャネルホッピング（TSCH）モードを含む、IEEE STD 802.15.4 [IEEE802.15.4]のすべてのモードで使用できる一般的なプロトコルです。COJPはまた、通信オーバーヘッドおよびコードフットプリントに関して効率が重要である他の（低電力）ネットワーキング技術でも使用され得る。そのような場合、当該技術に特有の構成パラメータをコンパニオン文書を介して定義する必要があるかもしれません。全体のプロセスはセクション4で説明され、スタックの構成は6tischに固有のものである。
CoJP assumes the presence of a Join Registrar/Coordinator (JRC), a central entity. The configuration defined in this document assumes that the pledge and the JRC share a unique symmetric cryptographic key, called PSK (pre-shared key). The PSK is used to configure OSCORE to provide a secure channel to CoJP. How the PSK is installed is out of scope of this document: this may happen during the provisioning phase or by a key exchange protocol that may precede the execution of CoJP.
COJPは中央エンティティであるJOINレジストラ/コーディネータ（JRC）の存在を想定しています。このドキュメントで定義されている構成は、PREDGEとJRCがPSK（事前共有キー）と呼ばれる固有の対称暗号鍵を共有していると想定しています。PSKは、COJPに安全なチャネルを提供するためにOSCOREを設定するために使用されます。PSKがインストールされている方法はこの文書の範囲外です。これは、プロビジョニングフェーズ中、またはCOJPの実行に先行する可能性のある鍵交換プロトコルの間に発生する可能性があります。
When the pledge seeks admission to a 6TiSCH network, it first synchronizes to it by initiating the passive scan defined in [IEEE802.15.4]. The pledge then exchanges CoJP messages with the JRC; for this end-to-end communication to happen, the messages are forwarded by nodes, called Join Proxies, that are already part of the 6TiSCH network. The messages exchanged allow the JRC and the pledge to mutually authenticate based on the properties provided by OSCORE. They also allow the JRC to configure the pledge with link-layer keying material, a short identifier, and other parameters. After this secure join process successfully completes, the joined node can interact with its neighbors to request additional bandwidth using the 6TiSCH Operation Sublayer (6top) Protocol [RFC8480] and can start sending application traffic.
誓約が6Tischネットワークへの入場を求めると、それは最初に[IEEE802.15.4]で定義されたパッシブスキャンを開始することによってそれに同期します。その後、誓約はCOJPメッセージをJRCと交換します。このエンドツーエンドの通信が起こるためには、メッセージは結合プロキシと呼ばれるノードによって転送され、すでに6Tischネットワークの一部です。交換されたメッセージは、OSCOREによって提供されるプロパティに基づいてJRCとPREDGEを互いに認証することを可能にします。また、JRCはリンクレイヤのキーイングマテリアル、短い識別子、およびその他のパラメータを備えた誓約を設定することもできます。この安全な結合プロセスが正常に完了した後、結合されたノードはその隣接者と対話して、6Tisch操作サブレイヤ（6top）プロトコル[RFC8480]を使用して追加の帯域幅を要求し、アプリケーショントラフィックの送信を開始できます。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The reader is expected to be familiar with the terms and concepts defined in [RFC9030], [RFC7252], [RFC8613], and [RFC8152].
リーダーは[RFC9030]、[RFC7252]、[RFC8613]、[RFC8152]で定義されている用語と概念に精通していると予想されます。
The specification also includes a set of informative specifications using the Concise Data Definition Language (CDDL) [RFC8610].
この仕様には、簡潔なデータ定義言語（CDDL）[RFC8610]を使用した有益な仕様のセットも含まれています。
The following terms defined in [RFC9030] are used extensively throughout this document:
[RFC9030]で定義されている次の用語は、この文書全体で広く使用されています。
* pledge
* 誓約
* joined node
* ノードに参加しました
* Join Proxy (JP)
* プロキシ（JP）に参加する
* Join Registrar/Coordinator (JRC)
* 登録レジストラ/コーディネーター（JRC）
* Enhanced Beacon (EB)
* 強化されたビーコン（EB）
* join protocol
* プロトコルに参加します
* join process
* プロセスに参加します
The following terms defined in [RFC8505] are also used throughout this document:
[RFC8505]で定義されている以下の用語もこの文書全体で使用されます。
* 6LoWPAN Border Router (6LBR)
* 6ローパンボーダールーター（6LBR）
* 6LoWPAN Node (6LN)
* 6LOWPANノード（6LN）
The term "6LBR" is used interchangeably with the term "DODAG root" defined in [RFC6550] on the assumption that the two entities are co-located, as recommended by [RFC9030].
「6LBR」という用語は、[RFC9030]によって推奨されるように、2つのエンティティが同一に配置されているという仮定で、[RFC6550]で定義された「DODAGルート」という用語と互換的に使用される。
The term "pledge", as used throughout the document, explicitly denotes non-6LBR devices attempting to join the network using their IEEE Std 802.15.4 network interface. The device that attempts to join as the 6LBR of the network and does so over another network interface is explicitly denoted as the "6LBR pledge". When the text applies equally to the pledge and the 6LBR pledge, the "(6LBR) pledge" form is used.
文書全体を通して使用される「Pledge」という用語は、IEEE STD 802.15.4ネットワークインタフェースを使用してネットワークに参加しようとしている非6LBRデバイスを明示的に表します。ネットワークの6LBRとして参加しようとし、別のネットワークインターフェースを介しても、「6LBR PREDDE」として明示的に表されます。テキストが誓約と6LBR誓約に等しく適用されると、「（6LBR）誓約」フォームが使用されます。
In addition, we use generic terms "pledge identifier" and "network identifier". See Section 3.
また、一般的な用語「PREDGE ID」と「ネットワーク識別子」を使用しています。3を参照してください。
The (6LBR) pledge is provisioned with certain parameters before attempting to join the network, and the same parameters are provisioned to the JRC. There are many ways by which this provisioning can be done. Physically, the parameters can be written into the (6LBR) pledge with a number of mechanisms, such as using a JTAG (Joint Test Action Group) interface, using a serial (craft) console interface, pushing buttons simultaneously on different devices, configuring over-the-air in a Faraday cage, etc. The provisioning can be done by the vendor, the manufacturer, the integrator, etc.
ネットワークに参加しようとする前に（6LBR）誓約が特定のパラメータをプロビジョニングし、同じパラメータがJRCにプロビジョニングされています。このプロビジョニングを行うことができる多くの方法があります。物理的には、シリアル（Craft）コンソールインタフェースを使用して、JTAG（Joint Test Action Group）インタフェースを使用して、異なるデバイスでボタンを押すなどの（6LBR）誓約書にパラメータを（6LBR）誓約してください。 - ファラデーケージなどの空気は、ベンダー、製造業者、積分器などによって行うことができます。
Details of how this provisioning is done are out of scope of this document. What is assumed is that there can be a secure, private conversation between the JRC and the (6LBR) pledge, and that the two devices can exchange the parameters.
このプロビジョニングが行われる方法の詳細は、この文書の範囲外です。仮定されているのは、JRCと（6LBR）誓約の間に安全で個人的な会話がある可能性があり、2つのデバイスがパラメータを交換できることです。
Parameters that are provisioned to the (6LBR) pledge include:
（6LBR）誓約にプロビジョニングされているパラメータは次のとおりです。
pledge identifier: The pledge identifier identifies the (6LBR) pledge. The pledge identifier MUST be unique in the set of all pledge identifiers managed by a JRC. The pledge identifier uniqueness is an important security requirement, as discussed in Section 9. The pledge identifier is typically the globally unique 64-bit Extended Unique Identifier (EUI-64) of the IEEE Std 802.15.4 device, in which case it is provisioned by the hardware manufacturer. The pledge identifier is used to generate the IPv6 addresses of the (6LBR) pledge and to identify it during the execution of the join protocol. Depending on the configuration, the pledge identifier may also be used after the join process to identify the joined node. For privacy reasons (see Section 10), it is possible to use a pledge identifier different from the EUI-64. For example, a pledge identifier may be a random byte string, but care needs to be taken that such a string meets the uniqueness requirement.
PREDGE ID：PREDGE IDは（6LBR）誓約を識別します。PREDGE IDは、JRCによって管理されているすべての誓約識別子のセット内で一意でなければなりません。PELDGED IDの一意性は、セクション9で説明されているように、重要なセキュリティ要件です.PELDGE IDは通常、IEEE STD 802.15.4デバイスのグローバルに一意の64ビット拡張固有ID（EUI-64）であり、その場合はプロビジョニングされています。ハードウェアメーカーによって。PREDGE IDは、（6LBR）誓約のIPv6アドレスを生成し、結合プロトコルの実行中に識別するために使用されます。構成に応じて、結合されたノードを識別するための結合プロセスの後にPREDGE識別子を使用することもできる。プライバシー上の理由から（セクション10を参照）、EUI-64とは異なる誓約識別子を使用することが可能です。例えば、PREDGE識別子はランダムバイト文字列であり得るが、そのような文字列が一意性要件を満たすと注意する必要がある。
Pre-Shared Key (PSK): A symmetric cryptographic key shared between the (6LBR) pledge and the JRC. To look up the PSK for a given pledge, the JRC additionally needs to store the corresponding pledge identifier. Each (6LBR) pledge MUST be provisioned with a unique PSK. The PSK MUST be a cryptographically strong key, with at least 128 bits of entropy, indistinguishable by feasible computation from a random uniform string of the same length. How the PSK is generated and/or provisioned is out of scope of this specification. This could be done during a provisioning step, or companion documents can specify the use of a key-agreement protocol. Common pitfalls when generating PSKs are discussed in Section 9. In the case of recommissioning a device to a new owner, the PSK MUST be changed. Note that the PSK is different from the link-layer keys K1 and K2 specified in [RFC8180]. The PSK is a long-term secret used to protect the execution of the secure join protocol specified in this document; the link-layer keys are transported as part of the secure join protocol.
事前共有キー（PSK）：（6LBR）誓約とJRCの間で共有されている対称暗号鍵。与えられた誓約のPSKを調べるために、JRCは対応する誓約識別子をさらに格納する必要があります。各（6LBR）の誓約書をユニークなPSKでプロビジョニングする必要があります。 PSKは、少なくとも128ビットのエントロピーを持つ、暗号的に強いキーでなければなりません。エントロピーは、同じ長さのランダムな均一なストリングから実現可能な計算によって区別できません。 PSKがどのように生成および/またはプロビジョニングされているかは、この仕様の範囲外です。これは、プロビジョニングステップ中に行うこともできます。また、コンパニオン文書は、契約契約プロトコルの使用を指定できます。一般的な落とし穴PSKを生成する際には、セクション9で説明します。デバイスを新しい所有者に推奨する場合は、PSKを変更する必要があります。 PSKは、[RFC8180]で指定されているリンク層K1、K2とは異なる。 PSKは、このドキュメントで指定されたセキュア参加プロトコルの実行を保護するために使用される長期秘密です。リンク層キーは、セキュアジョインプロトコルの一部として転送されます。
Optionally, a network identifier: The network identifier identifies the 6TiSCH network. The network identifier MUST be carried within Enhanced Beacon (EB) frames. Typically, the 16-bit Personal Area Network Identifier (PAN ID) defined in [IEEE802.15.4] is used as the network identifier. However, PAN ID is not considered a stable network identifier as it may change during network lifetime if a collision with another network is detected. Companion documents can specify the use of a different network identifier for join purposes, but this is out of scope of this specification. Provisioning the network identifier to a pledge is RECOMMENDED. However, due to operational constraints, the network identifier may not be known at the time of provisioning. If this parameter is not provisioned to the pledge, the pledge will attempt to join one advertised network at a time, which significantly prolongs the join process. This parameter MUST be provisioned to the 6LBR pledge.
任意選択で、ネットワーク識別子：ネットワーク識別子は6tischネットワークを識別する。ネットワーク識別子は、強化されたビーコン（EB）フレーム内で運ばなければなりません。典型的には、[IEEE802.15.4]で定義されている16ビット個人領域ネットワーク識別子（PAN ID）がネットワーク識別子として使用される。ただし、PAN IDは、他のネットワークとの衝突が検出された場合にネットワークの寿命中に変わる可能性があるため、安定したネットワーク識別子とは見なされません。コンパニオン文書は、結合目的のための異なるネットワーク識別子の使用を指定できますが、これはこの仕様の範囲外です。ネットワーク識別子を誓約にプロビジョニングすることをお勧めします。しかしながら、動作上の制約のために、ネットワーク識別子はプロビジョニング時に知られていない可能性がある。このパラメータがPredgeにプロビジョニングされていない場合、Predgeは一度に広告されたネットワークを1つに参加しようとします。これにより、結合プロセスが大幅に延長されます。このパラメータは6LBR誓約にプロビジョニングする必要があります。
Optionally, any non-default algorithms: The default algorithms are specified in Section 7.3.3. When algorithm identifiers are not provisioned, the use of these default algorithms is implied.
オプションで、デフォルト以外のアルゴリズム：デフォルトのアルゴリズムはセクション7.3.3で指定されています。アルゴリズム識別子がプロビジョニングされていない場合は、これらのデフォルトのアルゴリズムの使用が暗示されます。
Additionally, the 6LBR pledge that is not co-located with the JRC needs to be provisioned with the following:
さらに、JRCと同じ場所に配置されていない6LBR誓約書を次のようにしてプロビジョニングする必要があります。
Global IPv6 address of the JRC: This address is used by the 6LBR pledge to address the JRC during the join process. The 6LBR pledge may also obtain the IPv6 address of the JRC through other available mechanisms, such as DHCPv6 [RFC8415], Generic Autonomic Signaling Protocol (GRASP) [RFC8990], or Multicast DNS (mDNS) [RFC6762]; the use of these mechanisms is out of scope of this document. Pledges do not need to be provisioned with this address as they discover it dynamically through CoJP.
JRCのグローバルIPv6アドレス：このアドレスは、結合プロセス中にJRCに対処するために6LBR PREDGEDによって使用されます。6LBR誓約は、DHCPv6 [RFC8415]、一般的な自律型シグナリングプロトコル（GRASP）[RFC8990]、またはマルチキャストDNS（MDNS）[RFC6762]など、他の利用可能なメカニズムを介してJRCのIPv6アドレスを取得することもできます。これらのメカニズムの使用はこの文書の範囲外です。PLEDGESは、COJPを介して動的に発見されたように、このアドレスをプロビジョニングする必要はありません。
This section describes the steps taken by a pledge in a 6TiSCH network. When a pledge seeks admission to a 6TiSCH network, the following exchange occurs:
このセクションでは、6Tischネットワーク内の誓約によって取られるステップについて説明します。誓約が6Tischネットワークへの入場を求めると、次の交換が行われます。
1. The pledge listens for an Enhanced Beacon (EB) frame [IEEE802.15.4]. This frame provides network synchronization information, telling the device when it can send a frame to the node sending the beacons, which acts as a Join Proxy (JP) for the pledge, and when it can expect to receive a frame. The EB provides the link-layer address of the JP, and it may also provide its link-local IPv6 address.
1. Pledgeは拡張ビーコン（EB）フレーム[IEEE802.15.4]を聴取します。このフレームはネットワーク同期情報を提供し、デバイスにビーコンを送信するノードにフレームを送信できるときに、Predgeの結合プロキシ（JP）として機能し、フレームを受信することが期待できるときにデバイスに伝えます。EBは、JPのリンク層アドレスを提供し、そのリンクローカルIPv6アドレスを提供してもよい。
2. The pledge configures its link-local IPv6 address and advertises it to the JP using Neighbor Discovery. The advertisement step may be omitted if the link-local address has been derived from a known unique interface identifier, such as an EUI-64 address.
2. PREDCKはリンクローカルIPv6アドレスを設定し、それをネイバーディスカバリーを使用してJPにアドバタイズします。リンクローカルアドレスがEUI-64アドレスなどの既知の固有のインターフェイス識別子から派生した場合、広告ステップは省略されてもよい。
3. The pledge sends a Join Request to the JP in order to securely identify itself to the network. The Join Request is forwarded to the JRC.
3. PLEDGEは、ネットワークに安全に識別するためにJPに結合要求を送信します。結合要求はJRCに転送されます。
4. In the case of successful processing of the request, the pledge receives a Join Response from the JRC (via the JP). The Join Response contains configuration parameters necessary for the pledge to join the network.
4. 要求の成功した処理の場合、PREDGEはJRCから（JPを介して）JRCからの結合応答を受信する。結合応答には、ネットワークに参加するために必要な構成パラメータが含まれています。
From the pledge's perspective, joining is a local phenomenon -- the pledge only interacts with the JP, and it needs not know how far it is from the 6LBR or how to route to the JRC. Only after establishing one or more link-layer keys does it need to know about the particulars of a 6TiSCH network.
誓約の観点からは、参加は地元の現象です - 誓約はJPと交流するだけで、6LBRからの距離またはJRCへの道の距離までにはわかりません。1つ以上のリンク層キーを確立した後にのみ、6Tischネットワークの詳細について知る必要があります。
The join process is shown as a transaction diagram in Figure 1:
結合プロセスは図1のトランザクション図として表示されます。
+--------+ +-------+ +--------+
| pledge | | JP | | JRC |
| | | | | |
+--------+ +-------+ +--------+
| | |
|<---Enhanced Beacon (1)---| |
| | |
|<-Neighbor Discovery (2)->| |
| | |
|-----Join Request (3a)----|----Join Request (3a)---->| \
| | | | CoJP
|<----Join Response (3b)---|----Join Response (3b)----| /
| | |
Figure 1: Overview of a successful join process.
図1：結合プロセスが成功した概要
As for other nodes in the network, the 6LBR node may act as the JP. The 6LBR may in addition be co-located with the JRC.
ネットワーク内の他のノードに関しては、6LBRノードはJPとして機能することがある。6LBRはさらにJRCと同じ場所に配置されていてもよい。
The details of each step are described in the following sections.
各ステップの詳細は以下のセクションで説明されています。
The pledge synchronizes to the network by listening for, and receiving, an EB sent by a node already in the network. This process is entirely defined by [IEEE802.15.4] and described in [RFC7554].
誓約は、ネットワーク内に既にネットワーク内に送られたEBを受信し、受信することによってネットワークに同期します。このプロセスは[IEEE802.15.4]で完全に定義され、[RFC7554]に記載されています。
Once the pledge hears an EB, it synchronizes to the joining schedule using the cells contained in the EB. The pledge can hear multiple EBs; the selection of which EB to use is out of the scope for this document and is discussed in [RFC7554]. Implementers should make use of information such as the following: which network identifier the EB contains, the value of the Join Metric field within EBs, whether the source link-layer address of the EB has been tried before, at which signal strength the different EBs were received, etc. In addition, the pledge may be preconfigured to search for EBs with a specific network identifier.
誓約がEBを聞くと、EBに含まれるセルを使用して接合スケジュールに同期させます。誓約は複数のEBSを聞くことができます。使用するEBの使用はこの文書の範囲外であり、[RFC7554]で説明されています。実装者は、次のような情報を利用する必要があります。どのネットワーク識別子に、EBが含まれているネットワーク識別子、EB内の結合メトリックフィールドの値、EBのソースリンクレイヤアドレスが前に試行されたかどうか、その信号強度が異なるEBSさらに、受信されたなど、特定のネットワーク識別子を用いてEBSを検索するために誓約を事前設定することができる。
If the pledge is not provisioned with the network identifier, it attempts to join one network at a time, as described in Section 8.1.1.
誓約がネットワーク識別子とプロビジョニングされていない場合は、セクション8.1.1で説明されているように、一度に1つのネットワークに参加しようとします。
Once the pledge selects the EB, it synchronizes to it and transitions into a low-power mode. It follows the schedule information contained in the EB, which indicates the slots that the pledge may use for the join process. During the remainder of the join process, the node that has sent the EB to the pledge acts as the JP.
誓約がEBを選択すると、それに同期して低電力モードに移行します。EBに含まれるスケジュール情報に続き、これは、誓約が結合プロセスに使用できるスロットを示す。結合プロセスの残りの部分では、EBをPREDGEに送信したノードはJPとして機能します。
At this point, the pledge may either proceed to step 2 or continue to listen for additional EBs.
この時点で、誓約はステップ2に進むか、追加のEBSを聴き続けることができます。
The pledge forms its link-local IPv6 address based on the interface identifier per [RFC4944]. The pledge MAY perform the Neighbor Solicitation / Neighbor Advertisement exchange with the JP per Section 5.6 of [RFC8505]. Per [RFC8505], there is no need to perform duplicate address detection for the link-local address. The pledge and the JP use their link-local IPv6 addresses for all subsequent communication during the join process.
Predgeは、[RFC4944]のインターフェイス識別子に基づいて、そのリンクローカルIPv6アドレスを形成します。誓約は、[RFC8505]のセクション5.6あたりのJPとの隣接勧誘/近隣広告交換を実行することができる。[RFC8505]ごとに、リンクローカルアドレスに対して重複アドレス検出を実行する必要はありません。PREDGEとJPは、結合プロセス中の後続のすべての通信に対して、リンクローカルIPv6アドレスを使用します。
Note that Neighbor Discovery exchanges at this point are not protected with link-layer security as the pledge is not in possession of the keys. How the JP accepts these unprotected frames is discussed in Section 5.
この時点でのネイバーディスカバリ交換は、誓約が鍵を所有していないので、リンク層のセキュリティで保護されていません。JPがこれらの未保護されていないフレームをどのように受け入れるかをセクション5で説明します。
The pledge triggers the join exchange of the Constrained Join Protocol (CoJP). The join exchange consists of two messages: the Join Request message (Step 3a (Section 4.3.1)) and the Join Response message, conditioned on the successful security processing of the request (Step 3b (Section 4.3.2)).
誓約は、制約付き結合プロトコル（COJP）の結合交換を引き起こします。結合交換は、要求のセキュリティ処理を成功させるために、結合要求メッセージ（ステップ3a（セクション3a（セクション3a（セクション4.3.1））および結合応答メッセージ（ステップ3b（セクション4.3.2））で構成されている。
All CoJP messages are exchanged over a secure end-to-end channel that provides confidentiality, data authenticity, and replay protection. Frames carrying CoJP messages are not protected with link-layer security when exchanged between the pledge and the JP as the pledge is not in possession of the link-layer keys in use. How the JP and pledge accept these unprotected frames is discussed in Section 5. When frames carrying CoJP messages are exchanged between nodes that have already joined the network, the link-layer security is applied according to the security configuration used in the network.
すべてのCOJPメッセージは、機密性、データの真正性、および再生保護を提供する安全なエンドツーエンドのチャネルで交換されます。COJPメッセージを運ぶフレームは、PREDGEとJPとの間で交換されたときにリンクレイヤのセキュリティで保護されていません。JPとPREDGNがこれらの保護されていないフレームをどのように受け入れているかについて説明します。
The Join Request is a message sent from the pledge to the JP, and which the JP forwards to the JRC. The pledge indicates in the Join Request the role it requests to play in the network, as well as the identifier of the network it requests to join. The JP forwards the Join Request to the JRC on the existing links. How exactly this happens is out of scope of this document; some networks may wish to dedicate specific link-layer resources for this join traffic.
結合要求は、誓約からJPに送信され、JPがJRCに転送されるメッセージです。PREDGEは、結合を要求する役割を、ネットワーク内で再生要求する役割、および結合を要求するネットワークの識別子を示します。JPは既存のリンクのJRCに結合要求を転送します。これが起こるのはこの文書の範囲外です。一部のネットワークは、この参加トラフィックの特定のリンクレイヤリソースを専用にしたい場合があります。
The Join Response is sent by the JRC to the pledge, and it is forwarded through the JP. The packet containing the Join Response travels from the JRC to the JP using the operating routes in the network. The JP delivers it to the pledge. The JP operates as an application-layer proxy, see Section 7.
結合応答はJRCによって誓約によって送信され、JPを通して転送されます。結合応答を含むパケットは、ネットワーク内の動作ルートを使用してJRCからJPへ移動します。JPはそれを誓約に供給します。JPはアプリケーションレイヤプロキシとして動作します。セクション7を参照してください。
The Join Response contains various parameters needed by the pledge to become a fully operational network node. These parameters include the link-layer key(s) currently in use in the network, the short address assigned to the pledge, the IPv6 address of the JRC needed by the pledge to operate as the JP, among others.
結合応答には、完全運用ネットワークノードになるために誓約者に必要なさまざまなパラメータが含まれています。これらのパラメータは、ネットワークで現在使用されているリンクレイヤキー、Predgeに割り当てられている短いアドレス、とりわけJPとして動作するPREDGEに必要なJRCのIPv6アドレスを含む。
The 6LBR pledge performs Section 4.3 of the join process just like any other pledge, albeit over a different network interface. There is no JP intermediating the communication between the 6LBR pledge and the JRC, as described in Section 6. The other steps of the described join process do not apply to the 6LBR pledge. How the 6LBR pledge obtains an IPv6 address and triggers the execution of CoJP is out of scope of this document.
異なるネットワークインタフェースを介しても、6LBR PREDGEは、他の誓約と同じように、他の誓約と同じようにセクション4.3を実行します。セクション6に記載されているように、6LBR PREDGESとJRCとの間の通信を中間にするJPはない。説明された参加プロセスの他のステップは、6LBR誓約には適用されない。6LBR誓約がIPv6アドレスを取得し、COJPの実行をトリガする方法は、この文書の範囲外です。
In an operational 6TiSCH network, all frames use link-layer frame security [RFC8180]. The IEEE Std 802.15.4 security attributes include frame authenticity and optionally frame confidentiality (i.e., encryption).
オペレーショナル6Tischネットワークでは、すべてのフレームはリンクレイヤフレームセキュリティ[RFC8180]を使用します。IEEE STD 802.15.4セキュリティ属性には、フレームの真正性と任意選択でフレーム機密性（すなわち暗号化）が含まれます。
Any node sending EB frames MUST be prepared to act as a JP for potential pledges.
EBフレームを送信する任意のノードは、潜在的なPLEDGESのためのJPとして機能するように準備する必要があります。
The pledge does not initially perform an authenticity check of the EB frames because it does not possess the link-layer key(s) in use. The pledge is still able to parse the contents of the received EBs and synchronize to the network, as EBs are not encrypted [RFC8180].
誓約は最初は使用中のリンク層キーを持たないため、EBフレームの真正性チェックを実行しません。EBSは暗号化されていないように、誓約は依然として受信したEBSの内容を解析し、ネットワークに同期することができます[RFC8180]。
When sending frames during the join process, the pledge sends unencrypted and unauthenticated frames at the link layer. In order for the join process to be possible, the JP must accept these unsecured frames for the duration of the join process. This behavior may be implemented by setting the "secExempt" attribute in the IEEE Std 802.15.4 security configuration tables. It is expected that the lower layer provides an interface to indicate to the upper layer that unsecured frames are being received from a device. The upper layer can use that information to determine that a join process is in place and that the unsecured frames should be processed. How the JP makes such a determination and interacts with the lower layer is out of scope of this specification. The JP can additionally use information such as the value of the join rate parameter (Section 8.4.2) set by the JRC, physical button press, etc.
結合プロセス中にフレームを送信するとき、Predgeは暗号化されていないフレームをリンク層に送信します。結合プロセスが可能になるために、JPはこれらの無担保フレームを参加させる必要があります。この動作は、IEEE STD 802.15.4セキュリティ構成表の「secexempt」属性を設定することによって実装されてもよい。下位層は、無担保フレームが装置から受信されていることを上位層に示すためのインターフェースを提供することが予想される。上位層は、その情報を使用して、結合プロセスが所定の位置にあると判断し、無担保フレームを処理する必要があると判断できます。JPがそのような決定を行い、下位層と対話する方法は、本明細書の範囲外である。JPは、JRC、Physical Button Pressなどによって設定されている結合レートパラメータ（8.4.2節）などの情報を追加的に使用できます。
When the pledge initially synchronizes with the network, it has no means of verifying the authenticity of EB frames. Because an attacker can craft a frame that looks like a legitimate EB frame, this opens up a DoS vector, as discussed in Section 9.
誓約が最初にネットワークと同期するとき、それはEBフレームの信憑性を検証する手段はありません。攻撃者は正当なEBフレームのように見えるフレームを作ることができるので、これはセクション9で説明したように、DOSベクトルを開きます。
Nodes in a 6TiSCH network keep a global notion of time known as the Absolute Slot Number. The Absolute Slot Number is used in the construction of the link-layer nonce, as defined in [IEEE802.15.4]. The pledge initially synchronizes with the EB frame sent by the JP and uses the value of the Absolute Slot Number found in the TSCH Synchronization Information Element. At the time of the synchronization, the EB frame can neither be authenticated nor its freshness verified. During the join process, the pledge sends frames that are unprotected at the link-layer and protected end-to-end instead. The pledge does not obtain the time information as the output of the join process as this information is local to the network and may not be known at the JRC.
6Tischネットワーク内のノードは、絶対スロット番号として知られている時間のグローバルな概念を保持します。絶対スロット番号は、[IEEE802.15.4]で定義されているように、リンクレイヤのNONCEの構成に使用されます。PLEDDEは最初にJPによって送信されたEBフレームと同期し、TSCH同期情報要素にある絶対スロット番号の値を使用する。同期時には、EBフレームを認証することもその鮮度を検証することもできません。結合プロセス中に、Predgeはリンク層で保護されていないフレームを送信し、代わりにエンドツーエンドを保護します。この情報がネットワークに対してローカルであり、JRCではわからないため、誓約は結合プロセスの出力として時間情報を取得しません。
This enables an attack on the pledge where the attacker replays to the pledge legitimate EB frames obtained from the network and acts as a man-in-the-middle between the pledge and the JP. The EB frames will make the pledge believe that the replayed Absolute Slot Number value is the current notion of time in the network. By forwarding the join traffic to the legitimate JP, the attacker enables the pledge to join the network. Under different conditions relating to the reuse of the pledge's short address by the JRC or its attempt to rejoin the network, this may cause the pledge to reuse the link-layer nonce in the first frame it sends protected after the join process is completed.
これにより、攻撃者がネットワークから得られた誓約書に再生され、誓約とJPとの間の中央のマンインテリアとして機能する誓約書への攻撃を可能にします。EBフレームは、再生された絶対スロット数値がネットワーク内の時間の現在の概念であると誓約を信じるでしょう。結合トラフィックを正当なJPに転送することによって、攻撃者は誓約がネットワークに参加することを可能にします。JRCによるPREDGEの短いアドレスの再利用に関する異なる条件下で、またはネットワークを再調整するためのその試行に基づいて、結合プロセスが完了した後に保護された最初のフレーム内のリンクレイヤのノンスを再利用することがある。
For this reason, all frames originated at the JP and destined to the pledge during the join process MUST be authenticated at the link layer using the key that is normally in use in the network. Link-layer security processing at the pledge for these frames will fail as the pledge is not yet in possession of the key. The pledge acknowledges these frames without link-layer security, and JP accepts the unsecured acknowledgment due to the secExempt attribute set for the pledge. The frames should be passed to the upper layer for processing using the promiscuous mode of [IEEE802.15.4] or another appropriate mechanism. When the upper-layer processing on the pledge is completed, and the link-layer keys are configured, the upper layer MUST trigger the security processing of the corresponding frame. Once the security processing of the frame carrying the Join Response message is successful, the current Absolute Slot Number kept locally at the pledge SHALL be declared as valid.
このため、JPで発信されたすべてのフレームと結合プロセス中に誓約済みのすべてのフレームは、通常ネットワークで使用されているキーを使用してリンク層で認証されなければなりません。これらのフレームの誓約でのリンク層セキュリティ処理は、誓約がまだ鍵を所有していないため失敗します。Predgeはリンクレイヤのセキュリティなしでこれらのフレームを確認し、JPはPredgeのsecexempt属性セットのために無担保の確認応答を受け入れます。フレームは、[IEEE802.15.4]または他の適切なメカニズムの無差別モードを使用して処理のために上位層に渡されるべきです。誓約上の上位層処理が完了し、リンク層キーが設定されている場合、上位レイヤは対応するフレームのセキュリティ処理をトリガする必要がある。結合応答メッセージを搬送するフレームのセキュリティ処理が成功すると、現在の絶対スロット数は誓約で局所的に保持されていると宣言されなければならない。
The pledge and the JP SHOULD keep a separate neighbor cache for untrusted entries and use it to store each other's information during the join process. Mixing neighbor entries belonging to pledges and nodes that are part of the network opens up the JP to a DoS attack, as the attacker may fill the JP's neighbor table and prevent the discovery of legitimate neighbors.
PREDGEとJPは、信頼できないエントリのための別々のネイバーキャッシュを保持し、それを使用して結合プロセス中に互いの情報を保存します。攻撃者がJPの隣人のテーブルを埋めることができ、正当な隣人の発見を防ぐことができるので、ネットワークの一部である隣接エントリを混在させることは、JPをDOS攻撃に開きます。
Once the pledge obtains link-layer keys and becomes a joined node, it is able to securely communicate with its neighbors, obtain the network IPv6 prefix, and form its global IPv6 address. The joined node then undergoes an independent process to bootstrap its neighbor cache entries, possibly with a node that formerly acted as a JP, following [RFC8505]. From the point of view of the JP, there is no relationship between the neighbor cache entry belonging to a pledge and the joined node that formerly acted as a pledge.
PLEDGEがリンク層キーを取得して結合されたノードになると、その隣接者と安全に通信し、ネットワークIPv6プレフィックスを入手し、そのグローバルIPv6アドレスを作成することができます。次いで、結合されたノードは独立したプロセスを受信し、おそらく[RFC8505]に続くJPとして実行されていたノードを使用して、そのネイバーキャッシュエントリを起動する。JPの観点からは、誓約に属する隣接キャッシュエントリと、以前は誓約として行動する結合ノードとの間には関係がない。
The pledge does not communicate with the JRC at the network layer. This allows the pledge to join without knowing the IPv6 address of the JRC. Instead, the pledge communicates with the JP at the network layer using link-local addressing, and with the JRC at the application layer, as specified in Section 7.
誓約はネットワーク層でJRCと通信しません。これにより、JRCのIPv6アドレスを知らずに誓約が参加することができます。代わりに、誓約は、セクション7で指定されているように、リンクローカルアドレッシングを使用して、ネットワークレイヤのJPとネットワーク層と通信します。
The JP communicates with the JRC over global IPv6 addresses. The JP discovers the network IPv6 prefix and configures its global IPv6 address upon successful completion of the join process and the obtention of link-layer keys. The pledge learns the IPv6 address of the JRC from the Join Response, as specified in Section 8.1.2; it uses it once joined in order to operate as a JP.
JPは、グローバルIPv6アドレスを介してJRCと通信します。JPはネットワークIPv6の接頭辞を検出し、結合プロセスが正常に完了したときにグローバルIPv6アドレスを構成し、リンクレイヤキーの獲得を行います。誓約は、8.1.2項で規定されているように、JON応答からJRCのIPv6アドレスを学習します。JPとして動作するために一度結合されたものを使用します。
As a special case, the 6LBR pledge may have an additional network interface that it uses in order to obtain the configuration parameters from the JRC and to start advertising the 6TiSCH network. This additional interface needs to be configured with a global IPv6 address, by a mechanism that is out of scope of this document. The 6LBR pledge uses this interface to directly communicate with the JRC using global IPv6 addressing.
特別な場合として、6LBR誓約は、JRCから構成パラメータを取得し、6Tischネットワークを広告するために使用する追加のネットワークインタフェースを有することができる。この追加のインターフェースは、この文書の範囲外のメカニズムによって、グローバルIPv6アドレスで設定する必要があります。6LBR PREDGEは、このインタフェースを使用して、グローバルIPv6アドレス指定を使用してJRCと直接通信します。
The JRC can be co-located on the 6LBR. In this special case, the IPv6 address of the JRC can be omitted from the Join Response message for space optimization. The 6LBR then MUST set the DODAGID field in the RPL DODAG Information Objects (DIOs) [RFC6550] to its IPv6 address. The pledge learns the address of the JRC once joined and upon the reception of the first RPL DIO message, and uses it to operate as a JP.
JRCは6LBR上に同じ場所に配置できます。この特別な場合では、スペース最適化のためにJON応答メッセージからJRCのIPv6アドレスを省略することができます。その後、6LBRはRPL DoDag Information Objects（DIOS）[RFC6550]のDoDagIDフィールドをIPv6アドレスに設定する必要があります。誓約は、JRCのアドレスを結合して最初のRPL DIOメッセージを受信し、JPとして動作するように使用します。
The traffic that is proxied by the JP comes from unauthenticated pledges, and there may be an arbitrary amount of it. In particular, an attacker may send fraudulent traffic in an attempt to overwhelm the network.
JPによってプロキシされているトラフィックは認証されていない誓約から来て、任意の量があるかもしれません。特に、攻撃者はネットワークを圧倒するために不正なトラフィックを送信することがあります。
When operating as part of a 6TiSCH minimal network [RFC8180] using distributed scheduling algorithms, the traffic from unauthenticated pledges may cause intermediate nodes to request additional bandwidth. An attacker could use this property to cause the network to overcommit bandwidth (and energy) to the join process.
分散スケジューリングアルゴリズムを使用して6tisch最小ネットワーク[RFC8180]の一部として動作すると、認証されていないPLedgesからのトラフィックは、中間ノードが追加の帯域幅を要求する可能性があります。攻撃者はこのプロパティを使用して、ネットワークに帯域幅（およびエネルギー）を結合プロセスに克服させる可能性があります。
The JP is aware of what traffic originates from unauthenticated pledges, and so can avoid allocating additional bandwidth itself. The JP implements a data cap on outgoing join traffic by implementing the recommendation of 1 packet per 3 seconds in Section 3.1.3 of [RFC8085]. This can be achieved with the congestion control mechanism specified in Section 4.7 of [RFC7252]. This cap will not protect intermediate nodes as they cannot tell join traffic from regular traffic. Despite the data cap implemented separately on each JP, the aggregate join traffic from many JPs may cause intermediate nodes to decide to allocate additional cells. It is undesirable to do so in response to the traffic originated from unauthenticated pledges. In order to permit the intermediate nodes to avoid this, the traffic needs to be tagged. [RFC2597] defines a set of per-hop behaviors that may be encoded into the Diffserv Code Points (DSCPs). Based on the DSCP, intermediate nodes can decide whether to act on a given packet.
JPは、どのトラフィックが認証されていない誓約から発生するかを認識しているため、追加の帯域幅を割り当てることはできません。 JPは、[RFC8085]のセクション3.1.3で3秒あたり1パケットの推奨を実装することによって、発信結合トラフィック上のデータキャップを実装しています。これは、[RFC7252]のセクション4.7で指定された輻輳制御メカニズムで実現できます。このCAPは、通常のトラフィックからの参加トラフィックに通知できないため、中間ノードを保護しません。データキャップが各JPで別々に実装されているにもかかわらず、多くのJPSからの集約結合トラフィックは、中間ノードが追加のセルを割り当てることを決定する可能性があります。認証されていない誓約から発生した交通に応じてそうすることは望ましくありません。中間ノードがこれを回避することを許可するためには、トラフィックをタグ付けする必要があります。 [RFC2597] DIFFSERVコードポイント（DSCP）にエンコードされている可能性のある1つのホップの動作のセットを定義します。 DSCPに基づいて、中間ノードは特定のパケットに動作するかどうかを決定できます。
The JP SHOULD set the DSCP of packets that it produces as part of the forwarding process to AF43 code point (See Section 6 of [RFC2597]). A JP that does not require a specific DSCP value on forwarded traffic should set it to zero so that it is compressed out.
JPは、転送プロセスの一部としてPacketのDSCPをAF43コードポイントに設定する必要があります（[RFC2597]のセクション6を参照）。転送されたトラフィック上の特定のDSCP値を必要としないJPは、圧縮されるようにゼロに設定されます。
A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT allocate additional cells as a result of traffic with code point AF43. Companion SF documents SHOULD specify how this recommended behavior is achieved.
6Tischノード上で実行されているスケジューリング関数（SF）は、コードポイントAF43のトラフィックの結果として追加のセルを割り当てないでください。コンパニオンSF文書は、この推奨される行動がどのように達成されるかを指定する必要があります。
The JRC SHOULD set the DSCP of Join Response packets addressed to the JP to the AF42 code point. AF42 has lower drop probability than AF43, giving this traffic priority in buffers over the traffic going towards the JRC.
JRCは、JPにアドレス指定された結合応答パケットのDSCPをAF42コードポイントに設定する必要があります。AF42はAF43より低いドロップ確率が低いため、このトラフィックの優先順位は、JRCに向かって行くトラフィックの上にあります。
The 6LBR links are often the most congested within a DODAG, and from that point down, there is progressively less (or equal) congestion. If the 6LBR paces itself when sending Join Response traffic, then it ought to never exceed the bandwidth allocated to the best effort traffic cells. If the 6LBR has the capacity (if it is not constrained), then it should provide some buffers in order to satisfy the Assured Forwarding behavior.
6LBRリンクは、しばしばDODAG内で最も渋滞しており、その点から、次第に（または等しい）輻輳があります。結合応答トラフィックを送信するときに6LBRがそれ自体をペースでペースすると、最良の努力トラフィックセルに割り当てられている帯域幅を超えてはいけません。6LBRが容量を持つ（それが制約されていない場合）、保証された転送動作を満たすためにいくつかのバッファを提供する必要があります。
Companion SF documents SHOULD specify how traffic with code point AF42 is handled with respect to cell allocation. If the recommended behavior described in this section is not followed, the network may become prone to the attack discussed in Section 6.1.
コンパニオンSF文書は、コード点AF42のトラフィックがセル割り当てに関してどのように処理されるかを指定する必要があります。このセクションで説明されている推奨される動作に従わないと、ネットワークはセクション6.1で説明した攻撃に起動する可能性があります。
The CoJP join exchange in Figure 1 is carried over CoAP [RFC7252] and the secure channel provided by OSCORE [RFC8613]. The (6LBR) pledge acts as a CoAP client; the JRC acts as a CoAP server. The JP implements CoAP forward proxy functionality [RFC7252]. Because the JP can also be a constrained device, it cannot implement a cache.
図1のCOJP結合交換は、COAP [RFC7252]とOSCORE [RFC8613]によって提供されたセキュアチャネルを介して運ばれます。（6LBR）の誓約は、CoAPクライアントとして機能します。JRCはCoAPサーバーとして機能します。JPはCOAP順方向プロキシ機能[RFC7252]を実装しています。JPは制約付きデバイスにすることもできますので、キャッシュを実装できません。
The pledge designates a JP as a proxy by including the Proxy-Scheme option in the CoAP requests that it sends to the JP. The pledge also includes in the requests the Uri-Host option with its value set to the well-known JRC's alias, as specified in Section 8.1.1.
PLEDDEは、JPに送信するCOAP要求にプロキシスキームオプションを含めることで、プロキシとしてJPを指定します。プロジェッジには、セクション8.1.1で指定されているように、その値を使用してURI-HOSTオプションを要求にも含まれています。
The JP resolves the alias to the IPv6 address of the JRC that it learned when it acted as a pledge and joined the network. This allows the JP to reach the JRC at the network layer and forward the requests on behalf of the pledge.
JPは、それが誓約として機能してネットワークに参加したときに学んだJRCのIPv6アドレスにエイリアスを解決します。これにより、JPはネットワーク層でJRCに到達し、誓約に代わって要求を転送することができます。
The CoAP proxy defined in [RFC7252] keeps per-client state information in order to forward the response towards the originator of the request. This state information includes at least the CoAP token, the IPv6 address of the client, and the UDP source port number. Since the JP can be a constrained device that acts as a CoAP proxy, memory limitations make it prone to a DoS attack.
[RFC7252]で定義されたCOAPプロキシは、応答を要求の発信者に向けるために、クライアントごとの状態情報を保持します。この状態情報は、少なくともCoAPトークン、クライアントのIPv6アドレス、およびUDPソースポート番号を含む。JPは、COAPプロキシとして機能する制約付きデバイスになる可能性があるため、メモリの制限はDOS攻撃を受けやすくなります。
This DoS vector on the JP can be mitigated by making the JP act as a stateless CoAP proxy, where "state" encompasses the information related to individual pledges. The JP can wrap the state it needs to keep for a given pledge throughout the network stack in a "state object" and include it as a CoAP token in the forwarded request to the JRC. The JP may use the CoAP token as defined in [RFC7252], if the size of the serialized state object permits, or use the extended CoAP token defined in [RFC8974] to transport the state object. The JRC and any other potential proxy on the JP-JRC path MUST support extended token lengths, as defined in [RFC8974]. Since the CoAP token is echoed back in the response, the JP is able to decode the state object and configure the state needed to forward the response to the pledge. The information that the JP needs to encode in the state object to operate in a fully stateless manner with respect to a given pledge is implementation specific.
JP上のこのDOSベクトルは、JPをステートレスCOAPプロキシとして機能させることによって軽減できます。ここで、「状態」は個々のPLEDGESに関連する情報を網羅します。JPは、ネットワークスタック全体を通して「状態オブジェクト」内のネットワークスタック全体を通して保持する必要がある状態をラップすることができ、それをJRCへの転送要求内のCOAPトークンとして含めることができる。JPは、シリアライズされた状態オブジェクトのサイズが許可されている場合、[RFC7252]で定義されているCOAPトークンを使用したり、[RFC8974]で定義されている拡張COAAトークンを使用して状態オブジェクトを転送したりできます。JRCとJP-JRCパスの他の潜在的なプロキシは、[RFC8974]で定義されているように、拡張トークン長をサポートしている必要があります。COAASトークンは応答でエコーバックされているため、JPは状態オブジェクトを復号化し、応答を誓約に転送するために必要な状態を設定することができます。JPが所与の誓約に関して完全にステートレスに動作するように状態オブジェクトでエンコードする必要があるという情報は実装固有のものである。
It is RECOMMENDED that the JP operates in a stateless manner and signals the per-pledge state within the CoAP token for every request that it forwards into the network on behalf of unauthenticated pledges. When the JP is operating in a stateless manner, the security considerations from [RFC8974] apply, and the type of the CoAP message that the JP forwards on behalf of the pledge MUST be non-confirmable (NON), regardless of the message type received from the pledge. The use of a non-confirmable message by the JP alleviates the JP from keeping CoAP message exchange state. The retransmission burden is then entirely shifted to the pledge. A JP that operates in a stateless manner still needs to keep congestion control state with the JRC, see Section 9. Recommended values of CoAP settings for use during the join process, both by the pledge and the JP, are given in Section 7.2.
JPはステートレス方法で動作し、認証されていない誓約に代わってネットワークに転送するすべての要求について、COAPトークン内のプレッケージの状態をシグナリングすることをお勧めします。JPがステートレス方式で動作している場合は、[RFC8974]からのセキュリティ上の考慮事項、および受信したメッセージの種類に関係なく、PLEDDEに代わってJP転送が不可欠である必要があるCOAPメッセージの種類が適用されます。誓約から。JPによる確認不可能なメッセージの使用は、COAPメッセージ交換状態を保つことからJPを軽減する。再送信負担は完全に誓約にシフトされます。ステートレスの方法で動作するJPはまだJRCで輻輳制御状態を維持する必要があります。セクション9を参照してください.JONプロセス中の使用のためのCOAP設定の推奨値は、PLEDSEとJPの両方で、セクション7.2に示されています。
Note that in some networking stack implementations, a fully (per-pledge) stateless operation of the JP may be challenging from the implementation's point of view. In those cases, the JP may operate as a stateful proxy that stores the per-pledge state until the response is received or timed out, but this comes at a price of a DoS vector.
いくつかのネットワーキングスタックの実装では、JPの完全（PELEDGE PERDEDGE）ステートレス操作は、実装の観点から困難である可能性があります。そのような場合、JPは、応答が受信されるかタイミングされるまでプレッケードごとの状態を格納するステートフルプロキシとして動作しますが、これはDOSベクトルの価格で来ます。
This section gives RECOMMENDED values of CoAP settings during the join process.
このセクションでは、結合プロセス中にCOAP設定の推奨値が表示されます。
+===================+===============+
| Name | Default Value |
+===================+===============+
| ACK_TIMEOUT | 10 seconds |
+-------------------+---------------+
| ACK_RANDOM_FACTOR | 1.5 |
+-------------------+---------------+
| MAX_RETRANSMIT | 4 |
+-------------------+---------------+
| NSTART | 1 |
+-------------------+---------------+
| DEFAULT_LEISURE | 5 seconds |
+-------------------+---------------+
| PROBING_RATE | 1 byte/second |
+-------------------+---------------+
Table 1: Recommended CoAP settings.
表1：推奨されるCOAP設定。
These values may be configured to values specific to the deployment. The default values have been chosen to accommodate a wide range of deployments, taking into account dense networks.
これらの値は、展開に固有の値に設定できます。密集したネットワークを考慮して、幅広い展開に対応するために、デフォルト値が選択されています。
The PROBING_RATE value at the JP is controlled by the join rate parameter, see Section 8.4.2. Following [RFC7252], the average data rate in sending to the JRC must not exceed PROBING_RATE. For security reasons, the average data rate SHOULD be measured over a rather short window, e.g., ACK_TIMEOUT, see Section 9.
JPのprobing_rate値は、結合レートパラメータによって制御されます.8.4.2項を参照してください。[RFC7252]に続いて、JRCへの送信中の平均データレートはProcing_Rateを超えてはいけません。セキュリティ上の理由から、平均データレートは、かなり短いウィンドウ、例えばACK_TIMEOUTで測定されるべきである。
Before the (6LBR) pledge and the JRC start exchanging CoAP messages protected with OSCORE, they need to derive the OSCORE security context from the provisioned parameters, as discussed in Section 3.
（6LBR）の誓約およびJRCがOSCOREで保護されたCoAPメッセージの交換を開始する前に、セクション3で説明したように、プロビジョニングされたパラメータからオスアセキュリティコンテキストを導出する必要があります。
The OSCORE security context MUST be derived per Section 3 of [RFC8613].
[RFC8613]のセクション3ごとに、オスアセキュリティコンテキストを派生させる必要があります。
* The Master Secret MUST be the PSK.
* マスターシークレットはPSKでなければなりません。
* The Master Salt MUST be the empty byte string.
* マスターソルトは空のバイト文字列でなければなりません。
* The ID Context MUST be set to the pledge identifier.
* IDコンテキストはPREDGE IDに設定する必要があります。
* The ID of the pledge MUST be set to the empty byte string. This identifier is used as the OSCORE Sender ID of the pledge in the security context derivation, since the pledge initially acts as a CoAP client.
* PLEDCKのIDを空のバイト文字列に設定する必要があります。この識別子は、最初はCoAPクライアントとして機能するため、セキュリティコンテキスト導出における誓約のOSCORE送信者IDとして使用されます。
* The ID of the JRC MUST be set to the byte string 0x4a5243 ("JRC" in ASCII). This identifier is used as the OSCORE Recipient ID of the pledge in the security context derivation, as the JRC initially acts as a CoAP server.
* JRCのIDをバイト文字列0x4A5243（ASCIIの "jrc"）に設定する必要があります。この識別子は、JRCが最初にCOAPサーバとして機能するため、セキュリティコンテキストの導出における誓約のOSCORE受信者IDとして使用されます。
* The Algorithm MUST be set to the value from [RFC8152], agreed to out-of-band by the same mechanism used to provision the PSK. The default is AES-CCM-16-64-128.
* PSKをプロビジョニングするために使用されたのと同じメカニズムによって、andof-and-and-and-and-and-and-and-sublyに合意された値にアルゴリズムを値に設定する必要があります。デフォルトはAES-CCM-16-64-128です。
* The key derivation function MUST be agreed out-of-band by the same mechanism used to provision the PSK. Default is HKDF SHA-256 [RFC5869].
* PSKをプロビジョニングするために使用されるのと同じメカニズムによって、鍵導出機能は帯域外に合意されなければなりません。デフォルトはHKDF SHA-256 [RFC5869]です。
Since the pledge's OSCORE Sender ID is the empty byte string, when constructing the OSCORE option, the pledge sets the 'kid' flag in the OSCORE flag bits but indicates a 0-length 'kid'. The pledge transports its pledge identifier within the 'kid context' field of the OSCORE option. The derivation in [RFC8613] results in OSCORE keys and a Common Initialization Vector (IV) for each side of the conversation. Nonces are constructed by XORing the Common IV with the current sequence number. For details on nonce and OSCORE option construction, refer to [RFC8613].
PLEDDEのOSCORE SENDER IDは空のバイト文字列です.OSCOREオプションを作成するときは、プロジェッジはOSCOREフラグビット内の 'KID'フラグを設定しますが、0-length 'Kid'を示します。PREDGEは、OSCOREオプションの「KID CONTECTION」フィールド内にそのPREDGE IDを輸送します。[RFC8613]の派生は、会話の各側のオスアーキーと共通の初期化ベクトル（IV）をもたらします。Nonceは、現在のシーケンス番号を使用して共通IVをXORGEに構築します。NonceおよびOSCOREオプションの構成については、[RFC8613]を参照してください。
Implementations MUST ensure that multiple CoAP requests, including to different JRCs, are properly incrementing the sequence numbers, so that the same sequence number is never reused in distinct requests protected under the same PSK. The pledge typically sends requests to different JRCs if it is not provisioned with the network identifier and attempts to join one network at a time. Failure to comply will break the security guarantees of the Authenticated Encryption with Associated Data (AEAD) algorithm because of nonce reuse.
実装は、異なるJRCを含む複数のCOAP要求がシーケンス番号を正しくインクリメントしていることを確認しなければなりませんので、同じPSKの下で保護された異なるリクエストで同じシーケンス番号が再利用されません。誓約は通常、ネットワーク識別子とプロビジョニングされていない場合は、さまざまなJRCに要求を送信し、一度に1つのネットワークに参加しようとします。準拠しなかった失敗は、NONCEの再利用のために、認証された暗号化のセキュリティ保証を関連付けられたデータ（AEAD）アルゴリズムを壊します。
This OSCORE security context is used for the initial joining of the (6LBR) pledge, where the (6LBR) pledge acts as a CoAP client, as well as for any later parameter updates, where the JRC acts as a CoAP client and the joined node as a CoAP server, as discussed in Section 8.2. Note that when the (6LBR) pledge and the JRC change roles between CoAP client and CoAP server, the same OSCORE security context as initially derived remains in use, and the derived parameters are unchanged, for example, Sender ID when sending and Recipient ID when receiving (see Section 3.1 of [RFC8613]). A (6LBR) pledge is expected to have exactly one OSCORE security context with the JRC.
このOSCOREセキュリティコンテキストは、（6LBR）誓約を初期結合しており、ここで（6LBR）誓約はCOAAクライアントとして機能し、JRCがCOAPクライアントと結合されたノードとして機能する任意のパラメータ更新と同様に機能します。セクション8.2で説明したように、CoAPサーバーとして。（6LBR）の誓約とJRCがCOAPクライアントとCOAPサーバー間のロールを変更すると、最初に導出されたのと同じOSCORセキュリティコンテキストが使用されており、派生パラメータは変更されず、送信元IDと受信側IDの場合は送信者IDなどです。受信（[RFC8613]のセクション3.1を参照）。A（6LBR）の誓約は、JRCと正確に1つのオスアセキュリティコンテキストを持つことが期待されています。
Both the (6LBR) pledge and the JRC MUST implement a replay-protection mechanism. The use of the default OSCORE replay-protection mechanism specified in Section 3.2.2 of [RFC8613] is RECOMMENDED.
（6LBR）誓約とJRCの両方が再生保護メカニズムを実装する必要があります。[RFC8613]の3.2.2項で指定されているデフォルトのOSCORE再生保護メカニズムを使用することをお勧めします。
Implementations MUST ensure that mutable OSCORE context parameters (Sender Sequence Number, Replay Window) are stored in persistent memory. A technique detailed in Appendix B.1.1 of [RFC8613] that prevents reuse of sequence numbers MUST be implemented. Each update of the OSCORE Replay Window MUST be written to persistent memory.
実装は、可変オスアコンテキストパラメータ（送信者シーケンス番号、再生ウィンドウ）が永続メモリに格納されていることを確認する必要があります。シーケンス番号の再利用を防ぐ[RFC8613]の付録B.1.1に詳述されている技術を実装する必要があります。OSCOREリプレイウィンドウの各更新は、永続メモリに書き込む必要があります。
This is an important security requirement in order to guarantee nonce uniqueness and resistance to replay attacks across reboots and rejoins. Traffic between the (6LBR) pledge and the JRC is rare, making security outweigh the cost of writing to persistent memory.
これは、再起動および再参加を介してリプレイ攻撃を再生するための非CCEの一意性と抵抗を保証するための重要なセキュリティ要件です。（6LBR）誓約とJRCの間のトラフィックはまれであり、セキュリティは永続的なメモリへの書き込みのコストを上回る。
Errors raised by OSCORE during the join process MUST be silently dropped, with no error response being signaled. The pledge MUST silently discard any response not protected with OSCORE, including error codes.
結合プロセス中にOSCOREによって発生したエラーは静的にドロップされなければならず、エラー応答はシグナリングされません。誓約書は、エラーコードを含むOSCOREで保護されていない応答を静的に破棄しなければなりません。
Such errors may happen for a number of reasons, including failed lookup of an appropriate security context (e.g., the pledge attempting to join a wrong network), failed decryption, positive Replay Window lookup, formatting errors (possibly due to malicious alterations in transit). Silently dropping OSCORE messages prevents a DoS attack on the pledge where the attacker could send bogus error responses, forcing the pledge to attempt joining one network at a time, until all networks have been tried.
そのようなエラーは、適切なセキュリティコンテキストの検索の失敗（誤ったネットワークに参加しようとした誓約）、復号化の失敗、肯定的な再生ウィンドウの検索、フォーマットエラー（おそらくトランジット内の悪意のある変更による）を含む、いくつかの理由で発生する可能性があります。。黙ってOSCOREメッセージを削除すると、攻撃者がボーガスのエラー回答を送信し、すべてのネットワークが試行されるまで、攻撃者が偽のエラー回答を送信することができる誓約者に対するDOS攻撃を防ぎます。
The mandatory-to-implement AEAD algorithm for use with OSCORE is AES-CCM-16-64-128 from [RFC8152]. This is the algorithm used for securing IEEE Std 802.15.4 frames, and hardware acceleration for it is present in virtually all compliant radio chips. With this choice, CoAP messages are protected with an 8-byte CCM authentication tag, and the algorithm uses 13-byte long nonces.
OSCOREで使用するための必須のAEDアルゴリズムは、[RFC8152]からAES-CCM-16-64-128です。これは、IEEE STD 802.15.4フレームを保護するために使用されるアルゴリズムであり、それに対するハードウェア加速度は実質的にすべての準拠のラジオチップに存在します。この選択では、COAPメッセージは8バイトのCCM認証タグで保護されており、アルゴリズムは13バイトの長いノンスを使用します。
The mandatory-to-implement hash algorithm is SHA-256 [RFC4231]. The mandatory-to-implement key derivation function is HKDF [RFC5869], instantiated with a SHA-256 hash. See Appendix B for implementation guidance when code footprint is important.
義務的な実施ハッシュアルゴリズムはSHA-256 [RFC4231]です。義務的な実施キー派生機能は、SHA-256ハッシュでインスタンス化されたHKDF [RFC5869]です。コードのフットプリントが重要な場合は、実装ガイダンスについては付録Bを参照してください。
The Constrained Join Protocol (CoJP) is a lightweight protocol over CoAP [RFC7252] and a secure channel provided by OSCORE [RFC8613]. CoJP allows a (6LBR) pledge to request admission into a network managed by the JRC. It enables the JRC to configure the pledge with the necessary parameters. The JRC may update the parameters at any time, by reaching out to the joined node that formerly acted as a (6LBR) pledge. For example, network-wide rekeying can be implemented by updating the keying material on each node.
制約付き結合プロトコル（COJP）は、COAP [RFC7252]の上の軽量プロトコルとOSCCOR [RFC8613]によって提供されるセキュアチャネルです。COJPでは、（6LBR）誓約をすることで、JRCによって管理されているネットワークへの入場を要求することができます。それはJRCが必要なパラメータを持つ誓約を構成することを可能にします。JRCは、以前は（6LBR）誓約として行動する結合ノードに達することによって、いつでもパラメータを更新することができる。例えば、各ノード上のキーイングマテリアルを更新することによってネットワーク全体の生の生活を実現することができる。
CoJP relies on the security properties provided by OSCORE. This includes end-to-end confidentiality, data authenticity, replay protection, and a secure binding of responses to requests.
COJPはOSCOREによって提供されるセキュリティプロパティに依存しています。これには、エンドツーエンドの機密性、データの信頼性、再生保護、および要求に対する応答の安全なバインディングが含まれます。
+-----------------------------------+
| Constrained Join Protocol (CoJP) |
+-----------------------------------+
+-----------------------------------+ \
| Requests / Responses | |
|-----------------------------------| |
| OSCORE | | CoAP
|-----------------------------------| |
| Messaging Layer | |
+-----------------------------------+ /
+-----------------------------------+
| UDP |
+-----------------------------------+
Figure 2: Abstract layering of CoJP.
図2：CO JPの抽象層化。
When a (6LBR) pledge requests admission to a given network, it undergoes the CoJP join exchange that consists of:
（6LBR）の誓約要求が特定のネットワークへの入場を要求するとき、それは以下からなるCOJP結合交換を受ける。
* The Join Request message, sent by the (6LBR) pledge to the JRC, potentially proxied by the JP. The Join Request message and its mapping to CoAP is specified in Section 8.1.1.
* JRCに送信される（6LBR）JRCに送信された参加要求メッセージは、JPによって潜在的にプロキシされています。結合要求メッセージとCOAPへのマッピングはセクション8.1.1で指定されています。
* The Join Response message, sent by the JRC to the (6LBR) pledge, if the JRC successfully processes the Join Request using OSCORE and it determines through a mechanism that is out of scope of this specification that the (6LBR) pledge is authorized to join the network. The Join Response message is potentially proxied by the JP. The Join Response message and its mapping to CoAP is specified in Section 8.1.2.
* JRCから（6LBR）PREDDDERがOSCOREを使用してJRCに送信され、（6LBR）誓約の範囲外のメカニズムを介して、JRCから（6LBR）PREDCKに送信され、（6LBR）の誓約が参加することを許可されているメカニズムを決定します。ネットワーク結合応答メッセージは、JPによって潜在的にプロキシされます。結合応答メッセージとそのCOAPへのマッピングはセクション8.1.2で指定されています。
When the JRC needs to update the parameters of a joined node that formerly acted as a (6LBR) pledge, it executes the CoJP parameter update exchange that consists of the following:
JRCが（6LBR）誓約として行動されていた参加ノードのパラメータを更新する必要がある場合は、次のものからなるCOJPパラメータ更新交換を実行します。
* The Parameter Update message, sent by the JRC to the joined node that formerly acted as a (6LBR) pledge. The Parameter Update message and its mapping to CoAP is specified in Section 8.2.1.
* JRCによって（6LBR）誓約として行動されていた参加ノードにJRCによって送信されたパラメータ更新メッセージ。パラメータ更新メッセージとそのCOAPへのマッピングはセクション8.2.1で指定されています。
The payload of CoJP messages is encoded with CBOR [RFC8949]. The CBOR data structures that may appear as the payload of different CoJP messages are specified in Section 8.4.
COJPメッセージのペイロードはCBOR [RFC8949]でエンコードされています。さまざまなCOJPメッセージのペイロードとして表示される可能性があるCBORデータ構造はセクション8.4で指定されています。
This section specifies the messages exchanged when the (6LBR) pledge requests admission and configuration parameters from the JRC.
このセクションでは、（6LBR）PREDDERがJRCからの入場パラメータと構成パラメータが要求されたときに交換されたメッセージを指定します。
The Join Request message that the (6LBR) pledge sends SHALL be mapped to a CoAP request:
（6LBR）の誓約がCOAPリクエストにマッピングされるものとする結合要求メッセージ。
* The request method is POST.
* 要求方法はPOSTです。
* The type is Confirmable (CON).
* タイプは確認可能（CON）です。
* The Proxy-Scheme option is set to "coap".
* プロキシスキームオプションは「COAP」に設定されています。
* The Uri-Host option is set to "6tisch.arpa". This is an anycast type of identifier of the JRC that is resolved to its IPv6 address by the JP or the 6LBR pledge.
* URI-hostオプションは "6tisch.arpa"に設定されています。これは、JPまたは6LBR誓約によってIPv6アドレスに解決されるJRCの識別子のAnycastタイプです。
* The Uri-Path option is set to "j".
* URIパスオプションは "j"に設定されています。
* The OSCORE option SHALL be set according to [RFC8613]. The OSCORE security context used is the one derived in Section 7.3. The OSCORE 'kid context' allows the JRC to retrieve the security context for a given pledge.
* OSCOREオプションは[RFC8613]に従って設定されます。使用されているオスアセキュリティコンテキストは、セクション7.3で導出されたものです。OSCORE 'KID CONTEXT'は、JRCが特定の誓約のセキュリティコンテキストを取得することを可能にします。
* The payload is a Join_Request CBOR object, as defined in Section 8.4.1.
* ペイロードは、セクション8.4.1で定義されているように、join_request CBOBORオブジェクトです。
Since the Join Request is a confirmable message, the transmission at (6LBR) pledge will be controlled by CoAP's retransmission mechanism. The JP, when operating in a stateless manner, forwards this Join Request as a non-confirmable (NON) CoAP message, as specified in Section 7. If the CoAP implementation at the (6LBR) pledge declares the message transmission a failure, the (6LBR) pledge SHOULD attempt to join a 6TiSCH network advertised with a different network identifier. See Section 7.2 for recommended values of CoAP settings to use during the join exchange.
結合要求は確認可能なメッセージであるので、（6LBR）誓約における送信は、COAPの再送信メカニズムによって制御されます。JPはステートレス方式で動作するときに、セクション7で指定されているように、この結合要求を確認不可能な（非）COAPメッセージとして転送します。（6LBR）PREDGEでのCoAP実装がメッセージ送信を宣言した場合は（6LBR）PREDGEは、異なるネットワーク識別子に広告されている6Tischネットワークに参加しようと試みるべきです。結合交換中に使用するCOAP設定の推奨値については、セクション7.2を参照してください。
If all join attempts to advertised networks have failed, the (6LBR) pledge SHOULD signal the presence of an error condition, through some out-of-band mechanism.
全ての結合が宣伝されたネットワークを宣伝しようとした試みが失敗した場合、（6LBR）誓約はいくつかの帯域外機構を通してエラー状態の存在を知らせるべきである。
BCP 190 [RFC8820] provides guidelines on URI design and ownership. It recommends that whenever a third party wants to mandate a URI to web authority that it SHOULD go under "/.well-known" (per [RFC8615]). In the case of CoJP, the Uri-Host option is always set to "6tisch.arpa", and based upon the recommendations in Section 1 of [RFC8820], it is asserted that this document is the owner of the CoJP service. As such, the concerns of [RFC8820] do not apply, and thus the Uri-Path is only "j".
BCP 190 [RFC8820]はURI設計と所有権に関するガイドラインを提供します。第三者が「/.well-known」（[RFC8615]ごとに）にアクセスする必要があるというURIをWeb認証局に義務付けることを望んでいることをお勧めします。COJPの場合、URI-hostオプションは常に "6tisch.arpa"に設定されており、[RFC8820]のセクション1の推奨事項に基づいて、この文書はCOJPサービスの所有者であると主張されます。このように、[RFC8820]の懸念は適用されないため、URIパスは "j"だけです。
The Join Response message that the JRC sends SHALL be mapped to a CoAP response:
JRC送信がCOAP応答にマッピングされるものとする結合応答メッセージ。
* The Response Code is 2.04 (Changed).
* 応答コードは2.04（変更）です。
* The payload is a Configuration CBOR object, as defined in Section 8.4.2.
* ペイロードは、セクション8.4.2で定義されているように、構成CBOBORオブジェクトです。
During the network lifetime, parameters returned as part of the Join Response may need to be updated. One typical example is the update of link-layer keying material for the network, a process known as rekeying. This section specifies a generic mechanism when this parameter update is initiated by the JRC.
ネットワークの有効期間中に、結合応答の一部として返されるパラメータを更新する必要があるかもしれません。1つの典型的な例は、ネットワークのためのリンク層キーイング材料の更新、生後に知られているプロセスである。このセクションは、このパラメータ更新がJRCによって開始されたときの一般的なメカニズムを指定します。
At the time of the join, the (6LBR) pledge acts as a CoAP client and requests the network parameters through a representation of the "/j" resource exposed by the JRC. In order for the update of these parameters to happen, the JRC needs to asynchronously contact the joined node. The use of the CoAP Observe option for this purpose is not feasible due to the change in the IPv6 address when the pledge becomes the joined node and obtains a global address.
結合時に、（6LBR）誓約はCOAPクライアントとして機能し、JRCによって公開された「/ J」リソースの表現を通してネットワークパラメータを要求する。これらのパラメータの更新が起こるためには、JRCは結合ノードに非同期的に連絡する必要がある。この目的のためのCOAP観測オプションの使用は、PELDGEが結合されたノードになったときにIPv6アドレスの変更が可能であり、グローバルアドレスを取得します。
Instead, once the (6LBR) pledge receives and successfully validates the Join Response and so becomes a joined node, it becomes a CoAP server. The joined node creates a CoAP service at the Uri-Host value of "6tisch.arpa", and the joined node exposes the "/j" resource that is used by the JRC to update the parameters. Consequently, the JRC operates as a CoAP client when updating the parameters. The request/ response exchange between the JRC and the (6LBR) pledge happens over the already-established OSCORE secure channel.
代わりに、（6LBR）の誓約が受信して結合応答を正常に検証したら、結合ノードになると、CoAPサーバーになります。結合されたノードは、URIホスト値「6tisch.ARPA」でCOAPサービスを作成し、結合されたノードは、JRCによって使用される「/ j」リソースを公開してパラメータを更新する。その結果、パラメータを更新するときにJRCはCOAPクライアントとして動作します。JRCと（6LBR）誓約の間の要求/応答交換は、既存のオスアセキュアチャネルを介して行われます。
The Parameter Update message that the JRC sends to the joined node SHALL be mapped to a CoAP request:
JRCが結合されたノードに送信するパラメータ更新メッセージは、COAP要求にマッピングされます。
* The request method is POST.
* 要求方法はPOSTです。
* The type is Confirmable (CON).
* タイプは確認可能（CON）です。
* The Uri-Host option is set to "6tisch.arpa".
* URI-hostオプションは "6tisch.arpa"に設定されています。
* The Uri-Path option is set to "j".
* URIパスオプションは "j"に設定されています。
* The OSCORE option SHALL be set according to [RFC8613]. The OSCORE security context used is the one derived in Section 7.3. When a joined node receives a request with the Sender ID set to 0x4a5243 (ID of the JRC), it is able to correctly retrieve the security context with the JRC.
* OSCOREオプションは[RFC8613]に従って設定されます。使用されているオスアセキュリティコンテキストは、セクション7.3で導出されたものです。結合されたノードが送信者IDを0x4A5243に設定されている要求を受信すると（JRCのID）、JRCでセキュリティコンテキストを正しく取得することができます。
* The payload is a Configuration CBOR object, as defined in Section 8.4.2.
* ペイロードは、セクション8.4.2で定義されているように、構成CBOBORオブジェクトです。
The JRC has implicit knowledge of the global IPv6 address of the joined node, as it knows the pledge identifier that the joined node used when it acted as a pledge and the IPv6 network prefix. The JRC uses this implicitly derived IPv6 address of the joined node to directly address CoAP messages to it.
JRCには、結合されたノードのグローバルIPv6アドレスに関する暗黙の知識が、PredgeとIPv6ネットワークプレフィックスとして機能したときに使用されるPELDGE IDを知っています。JRCは、この暗黙的に派生したノードの暗黙的に派生したIPv6アドレスを使用して、COAPメッセージを直接アドレスにします。
If the JRC does not receive a response to a Parameter Update message, it attempts multiple retransmissions as configured by the underlying CoAP retransmission mechanism triggered for confirmable messages. Finally, if the CoAP implementation declares the transmission a failure, the JRC may consider this as a hint that the joined node is no longer in the network. How the JRC decides when to stop attempting to contact a previously joined node is out of scope of this specification, but the security considerations on the reuse of assigned resources apply, as discussed in Section 9.
JRCがパラメータ更新メッセージに対する応答を受け取らない場合、確認可能なメッセージに対してトリガされた基礎となるCOAP再送メカニズムによって構成されている複数の再送信を試みます。最後に、COAP実装が送信を失敗したことを宣言した場合、JRCは、結合されたノードがネットワーク内でもはやネットワーク内ではないというヒントとして考慮することができます。JRCが以前に参加したノードと連絡を試みることを停止するかを決定する方法は、この仕様の範囲外ですが、セクション9で説明したように、割り当てられたリソースの再利用に関するセキュリティ上の考慮事項が適用されます。
CoJP CBOR objects are transported within both CoAP requests and responses. This section describes handling the cases in which certain CoJP CBOR object parameters are not supported by the implementation or their processing fails. See Section 7.3.2 for the handling of errors that may be raised by the underlying OSCORE implementation.
COJP CBOBORオブジェクトは、COAP要求と応答の両方で輸送されます。このセクションでは、特定のCOJP CBORオブジェクトパラメータが実装によってサポートされていない場合、またはそれらの処理が失敗する場合について説明します。基礎となるOSCORORE実装によって発生する可能性があるエラーの処理については、セクション7.3.2を参照してください。
When such a parameter is detected in a CoAP request (Join Request message, Parameter Update message), a Diagnostic Response message MUST be returned. A Diagnostic Response message maps to a CoAP response and is specified in Section 8.3.2.
このようなパラメータがCoAP要求（結合要求メッセージ、パラメータ更新メッセージ）で検出された場合、診断応答メッセージを返す必要があります。診断応答メッセージはCoAP応答にマッピングされ、8.3.2項で指定されています。
When a parameter that cannot be acted upon is encountered while processing a CoJP object in a CoAP response (Join Response message), a (6LBR) pledge SHOULD reattempt to join. In this case, the (6LBR) pledge SHOULD include the Unsupported Configuration CBOR object within the Join Request object in the following Join Request message. The Unsupported Configuration CBOR object is self-contained and enables the (6LBR) pledge to signal any parameters that the implementation of the networking stack may not support. A (6LBR) pledge MUST NOT attempt more than COJP_MAX_JOIN_ATTEMPTS number of attempts to join if the processing of the Join Response message fails each time. If the COJP_MAX_JOIN_ATTEMPTS number of attempts is reached without success, the (6LBR) pledge SHOULD signal the presence of an error condition through some out-of-band mechanism.
COJPオブジェクトの処理中にCOJPオブジェクトを処理している間に行われないパラメータが発生した場合（Join Response Message）、（6LBR）誓約は結合を再試行する必要があります。この場合、（6LBR）誓約には、次の結合要求メッセージの中で結合要求オブジェクト内にサポートされていない構成CBOBORオブジェクトを含める必要があります。サポートされていない構成CBOBORオブジェクトは自己完結型であり、（6LBR）誓約が可能になると、ネットワークスタックの実装がサポートされていない可能性があるパラメータを表示できます。a（6LBR）PREDDNは、結合応答メッセージの処理が毎回失敗した場合に、COJP_MAX_JOIN_ATTEMPTS数を結合しようとしてはいけません。COJP_MAX_JOIN_ATTEMPTSの試行回数が成功せずに達すると、（6LBR）誓約は、帯域外のメカニズムを介してエラー状態の存在を信号にするはずです。
Note that COJP_MAX_JOIN_ATTEMPTS relates to the application-layer handling of the CoAP response and is different from CoAP's MAX_RETRANSMIT setting, which drives the retransmission mechanism of the underlying CoAP message.
COJP_MAX_JOIN_ATTEMPTSは、COAP応答のアプリケーションレイヤの処理に関連し、COAPのMAX_RETRANSMIT設定とは異なります。これは、基礎となるCOAPメッセージの再送信メカニズムを駆動します。
The Diagnostic Response message is returned for any CoJP request when the processing of the payload failed. The Diagnostic Response message is protected by OSCORE as any other CoJP message.
ペイロードの処理が失敗したときに、診断応答メッセージがCOJP要求に対して返されます。診断応答メッセージは、他のどのCOJPメッセージとしてOSCOREによって保護されています。
The Diagnostic Response message SHALL be mapped to a CoAP response:
診断応答メッセージは、COAP応答にマッピングされなければならない。
* The Response Code is 4.00 (Bad Request).
* 応答コードは4.00（不良要求）です。
* The payload is an Unsupported Configuration CBOR object, as defined in Section 8.4.5, containing more information about the parameter that triggered the sending of this message.
* ペイロードは、このメッセージの送信をトリガーしたパラメータに関する詳細情報を含む、サポートされていない構成CBOBORオブジェクトです。
The parameter update exchange may be triggered at any time during the network lifetime, which may span several years. During this period, a joined node or the JRC may experience unexpected events such as reboots or complete failures.
パラメータ更新交換は、ネットワークの有効期間中いつでもトリガされ、これは数年間及ぶ可能性があります。この期間中、結合されたノードまたはJRCは、再起動や完全な失敗などの予期しないイベントを経験する可能性があります。
This document mandates that the mutable parameters in the security context are written to persistent memory (see Section 7.3.1) by both the JRC and pledges (joined nodes). As the pledge (joined node) is typically a constrained device that handles the write operations to persistent memory in a predictable manner, the retrieval of mutable security-context parameters is feasible across reboots such that there is no risk of AEAD nonce reuse due to reinitialized Sender Sequence Numbers or of a replay attack due to the reinitialized Replay Window. The JRC may be hosted on a generic machine where the write operation to persistent memory may lead to unpredictable delays due to caching. If a reboot event occurs at the JRC before the cached data is written to persistent memory, the loss of mutable security-context parameters is likely, which consequently poses the risk of AEAD nonce reuse.
この文書は、セキュリティコンテキスト内の可変パラメータがJRCとPLEDGES（結合ノード）の両方によって永続メモリ（7.3.1項を参照）に書き込まれていることを義務付けています。PREDGE（結合ノード）は、通常、予測可能な方法で永続的なメモリへの書き込み操作を処理する制約付きデバイスであるため、再起動のリスクがないため、再起動のリスクがないように、変更可能なセキュリティコンテキストパラメータの検索は実行可能です。再初期化再生ウィンドウによる送信者シーケンス番号または再生攻撃。JRCは、持続的メモリへの書き込み動作がキャッシングによる予測不可能な遅延をもたらす可能性がある一般的なマシン上でホストされてもよい。キャッシュされたデータが永続的なメモリに書き込まれる前にJRCで再起動イベントが発生した場合、可変のセキュリティコンテキストパラメータの損失は可能性があり、その結果、AED NOCEの再利用のリスクが発生します。
In the event of a complete device failure, where the mutable security-context parameters cannot be retrieved, it is expected that a failed joined node will be replaced with a new physical device, using a new pledge identifier and a PSK. When such a failure event occurs at the JRC, it is possible that the static information on provisioned pledges, like PSKs and pledge identifiers, can be retrieved through available backups. However, it is likely that the information about joined nodes, their assigned short identifiers and mutable security-context parameters, is lost. If this is the case, the network administrator MUST force all the networks managed by the failed JRC to rejoin through out-of-band means during the process of JRC reinitialization, e.g., reinitialize the 6LBR nodes and freshly generate dynamic cryptographic keys and other parameters that influence the security properties of the network.
完全なデバイス障害が発生した場合、可変のセキュリティコンテキストパラメータを取得できない場合は、新しいPredge IdentifierとPSKを使用して、失敗した参加ノードが新しい物理デバイスに置き換えられます。このような障害発生イベントがJRCで発生すると、PSKとPREDGE IDのようなプロビジョニングされたPLEDGESの静的情報が使用可能なバックアップを通じて取得できる可能性があります。ただし、結合されたノードの情報、割り当てられた短識別子、および可変セキュリティコンテキストパラメータが失われる可能性があります。この場合、ネットワーク管理者は、障害が発生したJRCによって管理されているすべてのネットワークを、JRC再初期化のプロセス中に帯域外の手段を介して再獲得して、6LBRノードを再初期化し、新たなダイナミック暗号化キーやその他のパラメータを生成するように強制する必要があります。それはネットワークのセキュリティプロパティに影響を与えます。
In order to recover from such a failure event, the reinitialized JRC can trigger the renegotiation of the OSCORE security context through the procedure described in Appendix B.2 of [RFC8613]. Aware of the failure event, the reinitialized JRC responds to the first Join Request of each pledge it is managing with a 4.01 (Unauthorized) error and a random nonce. The pledge verifies the error response and then initiates the CoJP join exchange using a new OSCORE security context derived from an ID Context consisting of the concatenation of two nonces, one that it received from the JRC and the other that the pledge generates locally. After verifying the Join Request with the new ID Context and the derived OSCORE security context, the JRC should consequently map the new ID Context to the previously used pledge identifier. How the JRC handles this mapping is out of scope of this document.
このような故障イベントから回復するために、再初期化されたJRCは[RFC8613]の付録B.2に記載されている手順を通じて、オスアセキュリティコンテキストの再交渉を引き起こす可能性がある。失敗イベントを認識しているため、再初期化されたJRCは、4.01（不正な）エラーとランダムなノンスで管理されている各誓約の最初の結合要求に応答します。PLEDGEはエラー応答を検証し、次に、2つのノンスの連結からなるIDコンテキストから派生した新しいOSCORセキュリティコンテキストを使用して、COJP結合交換を開始します.1つはJRCから受信し、もう一方がローカルに生成されます。新しいIDコンテキストと派生オスアセキュリティコンテキストを使用して結合要求を検証した後、JRCは新しいIDコンテキストを以前に使用されたPLEDDE IDにマッピングする必要があります。JRCがこのマッピングを処理する方法はこの文書の範囲外です。
The use of the procedure specified in Appendix B.2 of [RFC8613] is RECOMMENDED in order to handle the failure events or any other event that may lead to the loss of mutable security-context parameters. The length of nonces exchanged using this procedure MUST be at least 8 bytes.
[RFC8613]の付録B.2で指定された手順を使用することは、障害イベントまたは変更可能なセキュリティコンテキストパラメータの損失につながる可能性のあるその他のイベントを処理するために推奨されます。この手順を使用して交換されたノンスの長さは少なくとも8バイトでなければなりません。
The procedure requires both the pledge and the JRC to have good sources of randomness. While this is typically not an issue at the JRC side, the constrained device hosting the pledge may pose limitations in this regard. If the procedure outlined in Appendix B.2 of [RFC8613] is not supported by the pledge, the network administrator MUST reprovision the concerned devices with freshly generated parameters through out-of-band means.
この手順では、誓約源とJRCの両方がランダム性の原因を持つ必要があります。これは通常JRC側での問題ではありませんが、誓約をホストしている制約付きデバイスはこの点に関して制限事項を維持する可能性があります。[RFC8613]の付録B.2に概説されている手順がPREDCKによってサポートされていない場合、ネットワーク管理者は、帯域外の手段を介して、関連するデバイスを新たに生成されたパラメータで再プロビジョニングする必要があります。
This section specifies the structure of CoJP CBOR objects that may be carried as the payload of CoJP messages. Some of these objects may be received both as part of the CoJP join exchange when the device operates as a (CoJP) pledge or as part of the parameter update exchange when the device operates as a joined (6LBR) node.
このセクションでは、COJPメッセージのペイロードとして実行できるCOJP CBOORオブジェクトの構造を指定します。デバイスが（COJP）PREDGESとして動作したとき、またはデバイスが結合された（6LBR）ノードとして動作している場合は、これらのオブジェクトの一部をCOJP結合交換の一部として受信することができます。
The Join_Request structure is built on a CBOR map object.
join_request構造体はCBOBOR MAPオブジェクトに構築されています。
The set of parameters that can appear in a Join_Request object is summarized below. The labels can be found in the "Constrained Join Protocol (CoJP) Parameters" registry, Section 11.1.
join_requestオブジェクトに表示できるパラメータのセットは以下のとおりです。ラベルは、「制約付き結合プロトコル（COJP）パラメータ」レジストリ、セクション11.1にあります。
role: The identifier of the role that the pledge requests to play in the network once it joins, encoded as an unsigned integer. Possible values are specified in Table 3. This parameter MAY be included. If the parameter is omitted, the default value of 0, i.e., the role "6TiSCH Node", MUST be assumed.
役割：PREDGEがネットワーク内で再生される要求の識別子は、結合されたときに符号化されていない整数としてエンコードされます。可能な値は表3に指定されています。このパラメータを含めることができます。パラメータが省略されている場合、デフォルト値の0、すなわちロール「6tischノード」を想定する必要があります。
network identifier: The identifier of the network, as discussed in Section 3, encoded as a CBOR byte string. When present in the Join_Request, it hints to the JRC which network the pledge is requesting to join, enabling the JRC to manage multiple networks. The pledge obtains the value of the network identifier from the received EB frames. This parameter MUST be included in a Join_Request object regardless of the role parameter value.
ネットワーク識別子：セクション3で説明したネットワークの識別子は、CBOBOBORバイト文字列としてエンコードされています。join_requestに存在する場合、それはPLEDDEが参加しているネットワークがjrcにヒントし、JRCが複数のネットワークを管理することを可能にします。誓約は、受信したEBフレームからネットワーク識別子の値を取得します。このパラメータは、役割パラメータ値に関係なく、join_requestオブジェクトに含める必要があります。
unsupported configuration: The identifier of the parameters that are not supported by the implementation, encoded as an Unsupported_Configuration object described in Section 8.4.5. This parameter MAY be included. If a (6LBR) pledge previously attempted to join and received a valid Join Response message over OSCORE but failed to act on its payload (Configuration object), it SHOULD include this parameter to facilitate the recovery and debugging.
サポートされていない構成：実装によってサポートされていないパラメータの識別子は、セクション8.4.5で説明されているUNSUPPORTED_CONFIGURATIONオブジェクトとしてエンコードされています。このパラメータを含めることができます。（6LBR）PREDSDが以前にオスコーアを介して有効な参加応答メッセージを受信しようとしたが、そのペイロード（構成オブジェクト）に行動できなかった場合は、回復とデバッグを容易にするためにこのパラメータを含める必要があります。
Table 2 summarizes the parameters that may appear in a Join_Request object.
表2は、join_requestオブジェクトに表示されるパラメータをまとめたものです。
+===========================+=======+==================+
| Name | Label | CBOR Type |
+===========================+=======+==================+
| role | 1 | unsigned integer |
+---------------------------+-------+------------------+
| network identifier | 5 | byte string |
+---------------------------+-------+------------------+
| unsupported configuration | 8 | array |
+---------------------------+-------+------------------+
Table 2: Summary of Join_Request parameters.
表2：join_requestパラメータの概要。
The CDDL fragment that represents the text above for the Join_Request follows:
join_requestの上記のテキストを表すCDDLフラグメントは次のとおりです。
Join_Request = {
? 1 : uint, ; role
5 : bstr, ; network identifier
? 8 : Unsupported_Configuration ; unsupported configuration
}
+========+=======+==============================+===========+
| Name | Value | Description | Reference |
+========+=======+==============================+===========+
| 6TiSCH | 0 | The pledge requests to play | RFC 9031 |
| Node | | the role of a regular 6TiSCH | |
| | | node, i.e., non-6LBR node. | |
+--------+-------+------------------------------+-----------+
| 6LBR | 1 | The pledge requests to play | RFC 9031 |
| | | the role of 6LoWPAN Border | |
| | | Router (6LBR). | |
+--------+-------+------------------------------+-----------+
Table 3: Role values.
表3：役割の値。
The Configuration structure is built on a CBOR map object. The set of parameters that can appear in a Configuration object is summarized below. The labels can be found in "Constrained Join Protocol (CoJP) Parameters" registry, Section 11.1.
構成構造はCBOBOR MAPオブジェクトに構築されています。構成オブジェクトに表示できるパラメータのセットは以下のとおりです。ラベルは、「制約付き結合プロトコル（COJP）パラメータ」レジストリ、セクション11.1にあります。
link-layer key set: An array encompassing a set of cryptographic keys and their identifiers that are currently in use in the network or that are scheduled to be used in the future. The encoding of individual keys is described in Section 8.4.3. The link-layer key set parameter MAY be included in a Configuration object. When present, the link-layer key set parameter MUST contain at least one key. This parameter is also used to implement rekeying in the network. The installation and use of keys differs for the 6LBR and other (regular) nodes, and this is explained in Sections 8.4.3.1 and 8.4.3.2.
リンク層キー・セット：ネットワーク内で現在使用されている、または将来使用される予定の暗号化キーとそれらの識別子のセットを包含するアレイ。個々のキーの符号化は8.4.3節で説明されています。リンク層鍵設定パラメータは、構成オブジェクトに含まれていてもよい。存在する場合、リンクレイヤのキーSETパラメータには少なくとも1つのキーが含まれている必要があります。このパラメータは、ネットワーク内での再確認を実装するためにも使用されます。キーのインストールと使用は6LBRおよび他の（通常の）ノードで異なります。これはセクション8.4.3.1と8.4.3.2で説明されています。
short identifier: A compact identifier assigned to the pledge. The short identifier structure is described in Section 8.4.4. The short identifier parameter MAY be included in a Configuration object.
短識別子：誓約に割り当てられたコンパクトな識別子。短識別子構造は8.4.4項で説明されています。短識別子パラメータは、構成オブジェクトに含まれていてもよい。
JRC address: The IPv6 address of the JRC, encoded as a byte string, with the length of 16 bytes. If the length of the byte string is different from 16, the parameter MUST be discarded. If the JRC is not co-located with the 6LBR and has a different IPv6 address than the 6LBR, this parameter MUST be included. In the special case where the JRC is co-located with the 6LBR and has the same IPv6 address as the 6LBR, this parameter MAY be included. If the JRC address parameter is not present in the Configuration object, this indicates that the JRC has the same IPv6 address as the 6LBR. The joined node can then discover the IPv6 address of the JRC through network control traffic. See Section 6.
JRCアドレス：16バイトの長さのバイト文字列としてエンコードされたJRCのIPv6アドレス。バイト文字列の長さが16と異なる場合は、パラメータを破棄する必要があります。JRCが6LBRと同じ場所に配置されておらず、6LBRとは異なるIPv6アドレスを持つ場合、このパラメータを含める必要があります。JRCが6LBRと同じ場所に配置され、6LBRと同じIPv6アドレスを持つ特別な場合では、このパラメータを含めることができます。JRCアドレスパラメータが構成オブジェクトに存在しない場合、これはJRCが6LBRと同じIPv6アドレスを持つことを示しています。結合されたノードは、ネットワーク制御トラフィックを介してJRCのIPv6アドレスを検出できます。セクション6を参照してください。
blacklist: An array encompassing a list of pledge identifiers that are blacklisted by the JRC, with each pledge identifier encoded as a byte string. The blacklist parameter MAY be included in a Configuration object. When present, the array MUST contain zero or more byte strings encoding pledge identifiers. The joined node MUST silently drop any link-layer frames originating from the pledge identifiers enclosed in the blacklist parameter. When this parameter is received, its value MUST overwrite any previously set values. This parameter allows the JRC to configure the node acting as a JP to filter out traffic from misconfigured or malicious pledges before their traffic is forwarded into the network. If the JRC decides to remove a given pledge identifier from a blacklist, it omits the pledge identifier in the blacklist parameter value it sends next. Since the blacklist parameter carries the pledge identifiers, privacy considerations apply. See Section 10.
BlackList：JRCによってブラックリストに登録されているPREDGE IDのリストを含む配列。各PREDDE IDはバイト文字列としてエンコードされています。BlackListパラメータは構成オブジェクトに含まれていてもよい。存在する場合、配列には、誓約識別子を符号化するゼロ以上の文字列を含める必要があります。結合されたノードは、BlackListパラメータに囲まれたPELDGE識別子から発生するリンクレイヤフレームを静的にドロップする必要があります。このパラメータを受信すると、その値は以前に設定された値を上書きする必要があります。このパラメータを使用すると、JRCは、トラフィックがネットワークに転送される前に、誤った構成または悪意のみの施肥からトラフィックを除去するためのJPとして機能するノードを設定できます。JRCがブラックリストから与えられたPREDDE IDを削除することを決定した場合、それは次に送信するBlackListパラメータ値のPregedd IDを省略します。BlackListパラメータはPregedd Identifiersを搭載しているため、プライバシーに関する考慮事項が適用されます。10を参照してください。
join rate: The average data rate (in units of bytes/second) of join traffic forwarded into the network that should not be exceeded when a joined node operates as a JP, encoded as an unsigned integer. The join rate parameter MAY be included in a Configuration object. This parameter allows the JRC to configure different nodes in the network to operate as JP and to act in case of an attack by throttling the rate at which JP forwards unauthenticated traffic into the network. When this parameter is present in a Configuration object, the value MUST be used to set the PROBING_RATE of CoAP at the joined node for communication with the JRC. If this parameter is set to zero, a joined node MUST silently drop any join traffic coming from unauthenticated pledges. If this parameter is omitted, the value of positive infinity SHOULD be assumed. A node operating as a JP MAY use another mechanism that is out of scope of this specification to configure the PROBING_RATE of CoAP in the absence of a join rate parameter from the Configuration object.
結合率：結合されたノードが符号なしの整数としてエンコードされたJPとして動作していないネットワークに転送されてはならない、ネットワークに転送されるべきではありません。結合レートパラメータは、構成オブジェクトに含まれていてもよい。このパラメータは、JRCがネットワーク内のさまざまなノードを構成し、JPとして動作し、JPが認証されていないトラフィックをネットワークに転送するレートを調整することで攻撃の場合に行動することができます。このパラメータが構成オブジェクトに存在する場合、その値はJRCとの通信のために結合ノードにCOAPのprobing_rateを設定する必要があります。このパラメータがゼロに設定されている場合、結合ノードは、認証されていないPLedgesからの結合トラフィックを静かにドロップする必要があります。このパラメータを省略すると、正の無限大の値が想定されるべきです。 JPとして動作するノードは、この仕様の範囲外の別のメカニズムを使用して、構成オブジェクトからの結合レートパラメータがない場合のCOAPのprobing_rateを構成することができる。
Table 4 summarizes the parameters that may appear in a Configuration object.
表4は、構成オブジェクトに表示される可能性があるパラメータをまとめたものです。
+====================+=======+==================+
| Name | Label | CBOR Type |
+====================+=======+==================+
| link-layer key set | 2 | array |
+--------------------+-------+------------------+
| short identifier | 3 | array |
+--------------------+-------+------------------+
| JRC address | 4 | byte string |
+--------------------+-------+------------------+
| blacklist | 6 | array |
+--------------------+-------+------------------+
| join rate | 7 | unsigned integer |
+--------------------+-------+------------------+
Table 4: Summary of Configuration parameters.
表4：構成パラメータの概要
The CDDL fragment that represents the text above for the Configuration follows. The structures Link_Layer_Key and Short_Identifier are specified in Sections 8.4.3 and 8.4.4, respectively.
上記のテキストを表すCDDLフラグメントは次のとおりです。構造物link_layer_keyとshort_identifierは、それぞれ8.4.3と8.4.4で指定されています。
Configuration = {
? 2 : [ +Link_Layer_Key ], ; link-layer key set
? 3 : Short_Identifier, ; short identifier
? 4 : bstr, ; JRC address
? 6 : [ *bstr ], ; blacklist
? 7 : uint ; join rate
}
+===============+=======+==========+====================+===========+
| Name | Label | CBOR | Description | Reference |
| | | type | | |
+===============+=======+==========+====================+===========+
| role | 1 | unsigned | Identifies the | RFC 9031 |
| | | integer | role parameter | |
+---------------+-------+----------+--------------------+-----------+
| link-layer | 2 | array | Identifies the | RFC 9031 |
| key set | | | array carrying | |
| | | | one or more | |
| | | | link-layer | |
| | | | cryptographic | |
| | | | keys | |
+---------------+-------+----------+--------------------+-----------+
| short | 3 | array | Identifies the | RFC 9031 |
| identifier | | | assigned short | |
| | | | identifier | |
+---------------+-------+----------+--------------------+-----------+
| JRC address | 4 | byte | Identifies the | RFC 9031 |
| | | string | IPv6 address | |
| | | | of the JRC | |
+---------------+-------+----------+--------------------+-----------+
| network | 5 | byte | Identifies the | RFC 9031 |
| identifier | | string | network | |
| | | | identifier | |
| | | | parameter | |
+---------------+-------+----------+--------------------+-----------+
| blacklist | 6 | array | Identifies the | RFC 9031 |
| | | | blacklist | |
| | | | parameter | |
+---------------+-------+----------+--------------------+-----------+
| join rate | 7 | unsigned | Identifier the | RFC 9031 |
| | | integer | join rate | |
| | | | parameter | |
+---------------+-------+----------+--------------------+-----------+
| unsupported | 8 | array | Identifies the | RFC 9031 |
| configuration | | | unsupported | |
| | | | configuration | |
| | | | parameter | |
+---------------+-------+----------+--------------------+-----------+
Table 5: CoJP parameters map labels.
表5：COJPパラメータマップラベル。
The Link_Layer_Key structure encompasses the parameters needed to configure the link-layer security module: the key identifier; the value of the cryptographic key; the link-layer algorithm identifier and the security level and the frame types with which it should be used for both outgoing and incoming security operations; and any additional information that may be needed to configure the key.
link_layer_key構造体は、リンク層セキュリティモジュールを構成するために必要なパラメータを包含する。暗号鍵の値。リンク層アルゴリズム識別子とセキュリティレベルとそれを発信するセキュリティ操作と着信セキュリティ操作の両方に使用する必要があるフレームタイプ。キーを設定するために必要な追加情報。
For encoding compactness, the Link_Layer_Key object is not enclosed in a top-level CBOR object. Rather, it is transported as a sequence of CBOR elements [RFC8742], some being optional.
コンパクト性を符号化するために、LINK_LAYER_KEYオブジェクトは最上位のCBORオブジェクトに囲まれていません。むしろ、それはCBOR要素[RFC8742]のシーケンスとして輸送され、いくつかは任意である。
The set of parameters that can appear in a Link_Layer_Key object is summarized below, in order:
link_layer_keyオブジェクトに表示できるパラメータのセットは以下のとおりです。
key_id: The identifier of the key, encoded as a CBOR unsigned integer. This parameter MUST be included. If the decoded CBOR unsigned integer value is larger than the maximum link-layer key identifier, the key is considered invalid. If the key is considered invalid, the key MUST be discarded, and the implementation MUST signal the error as specified in Section 8.3.1.
key_id：鍵の識別子.CBOBOR符号なし整数としてエンコードされています。このパラメータを含める必要があります。デコードされたCBOBOR符号なし整数値が最大リンクレイヤキー識別子より大きい場合、キーは無効と見なされます。キーが無効と見なされる場合、そのキーは破棄されなければならず、実装は8.3.1項で指定されているようにエラーを知らなければなりません。
key_usage: The identifier of the link-layer algorithm, security level, and link-layer frame types that can be used with the key, encoded as an integer. This parameter MAY be included. Possible values and the corresponding link-layer settings are specified in the IANA "Constrained Join Protocol (CoJP) Key Usage" registry (Section 11.2). If the parameter is omitted, the default value of 0 (6TiSCH-K1K2-ENC-MIC32) from Table 6 MUST be assumed. This default value has been chosen because it results in byte savings in the most constrained settings; its selection does not imply a recommendation for its general usage.
key_usage：整数としてエンコードされたキーで使用できるリンク層アルゴリズム、セキュリティレベル、およびリンク層のフレームタイプの識別子。このパラメータを含めることができます。可能な値と対応するリンク層設定は、IANA "制約付き結合プロトコル（COJP）キー使用法"レジストリ（セクション11.2）に指定されています。パラメータを省略すると、表6からのデフォルト値0（6tisch-k1k2-enc-mic32）を想定する必要があります。このデフォルト値は、最も制約された設定でバイト節約をもたらすために選択されました。その選択はその一般的な使用法に対する推奨事項を意味するものではありません。
key_value: The value of the cryptographic key, encoded as a byte string. This parameter MUST be included. If the length of the byte string is different than the corresponding key length for a given algorithm specified by the key_usage parameter, the key MUST be discarded, and the implementation MUST signal the error as specified in Section 8.3.1.
key_value：暗号鍵の値は、バイト文字列としてエンコードされます。このパラメータを含める必要があります。BYTE文字列の長さが、key_usageパラメータで指定された所定のアルゴリズムの対応するキー長と異なる場合、そのキーは破棄されなければならず、実装はセクション8.3.1で指定されているようにエラーを通知する必要があります。
key_addinfo: Additional information needed to configure the link-layer key, encoded as a byte string. This parameter MAY be included. The processing of this parameter is dependent on the link-layer technology in use and a particular keying mode.
key_addinfo：リンクレイヤキーをバイト文字列としてエンコードするために必要な追加情報。このパラメータを含めることができます。このパラメータの処理は、使用中のリンク層技術と特定のキーイングモードによって異なります。
To be able to decode the keys that are present in the link-layer key set and to identify individual parameters of a single Link_Layer_Key object, the CBOR decoder needs to differentiate between elements based on the CBOR type. For example, a uint that follows a byte string signals to the decoder that a new Link_Layer_Key object is being processed.
リンクレイヤキーセットに存在し、単一のLINK_LAYER_KEYオブジェクトの個々のパラメータを識別するためのキーを復号することができるようにするには、CBORデコーダはCBOBORタイプに基づいて要素を区別する必要があります。たとえば、新しいlink_layer_keyオブジェクトが処理されていることをデコーダにバイト文字列信号に続くUINT。
The CDDL fragment for the Link_Layer_Key that represents the text above follows:
上記のテキストを表すlink_layer_keyのCDDLフラグメントは次のとおりです。
Link_Layer_Key = (
key_id : uint,
? key_usage : int,
key_value : bstr,
? key_addinfo : bstr,
)
+======================+=====+======================+===============+
|Name |Value|Algorithm |Description |
+======================+=====+======================+===============+
|6TiSCH-K1K2-ENC-MIC32 |0 |IEEE802154-AES-CCM-128|Use MIC-32 for |
| | | |EBs, ENC-MIC-32|
| | | |for DATA and |
| | | |ACKNOWLEDGMENT.|
+----------------------+-----+----------------------+---------------+
|6TiSCH-K1K2-ENC-MIC64 |1 |IEEE802154-AES-CCM-128|Use MIC-64 for |
| | | |EBs, ENC-MIC-64|
| | | |for DATA and |
| | | |ACKNOWLEDGMENT.|
+----------------------+-----+----------------------+---------------+
|6TiSCH-K1K2-ENC-MIC128|2 |IEEE802154-AES-CCM-128|Use MIC-128 for|
| | | |EBs, ENC- |
| | | |MIC-128 for |
| | | |DATA and |
| | | |ACKNOWLEDGMENT.|
+----------------------+-----+----------------------+---------------+
|6TiSCH-K1K2-MIC32 |3 |IEEE802154-AES-CCM-128|Use MIC-32 for |
| | | |EBs, DATA and |
| | | |ACKNOWLEDGMENT.|
+----------------------+-----+----------------------+---------------+
|6TiSCH-K1K2-MIC64 |4 |IEEE802154-AES-CCM-128|Use MIC-64 for |
| | | |EBs, DATA and |
| | | |ACKNOWLEDGMENT.|
+----------------------+-----+----------------------+---------------+
|6TiSCH-K1K2-MIC128 |5 |IEEE802154-AES-CCM-128|Use MIC-128 for|
| | | |EBs, DATA and |
| | | |ACKNOWLEDGMENT.|
+----------------------+-----+----------------------+---------------+
|6TiSCH-K1-MIC32 |6 |IEEE802154-AES-CCM-128|Use MIC-32 for |
| | | |EBs. |
+----------------------+-----+----------------------+---------------+
|6TiSCH-K1-MIC64 |7 |IEEE802154-AES-CCM-128|Use MIC-64 for |
| | | |EBs. |
+----------------------+-----+----------------------+---------------+
|6TiSCH-K1-MIC128 |8 |IEEE802154-AES-CCM-128|Use MIC-128 for|
| | | |EBs. |
+----------------------+-----+----------------------+---------------+
|6TiSCH-K2-MIC32 |9 |IEEE802154-AES-CCM-128|Use MIC-32 for |
| | | |DATA and |
| | | |ACKNOWLEDGMENT.|
+----------------------+-----+----------------------+---------------+
|6TiSCH-K2-MIC64 |10 |IEEE802154-AES-CCM-128|Use MIC-64 for |
| | | |DATA and |
| | | |ACKNOWLEDGMENT.|
+----------------------+-----+----------------------+---------------+
|6TiSCH-K2-MIC128 |11 |IEEE802154-AES-CCM-128|Use MIC-128 for|
| | | |DATA and |
| | | |ACKNOWLEDGMENT.|
+----------------------+-----+----------------------+---------------+
|6TiSCH-K2-ENC-MIC32 |12 |IEEE802154-AES-CCM-128|Use ENC-MIC-32 |
| | | |for DATA and |
| | | |ACKNOWLEDGMENT.|
+----------------------+-----+----------------------+---------------+
|6TiSCH-K2-ENC-MIC64 |13 |IEEE802154-AES-CCM-128|Use ENC-MIC-64 |
| | | |for DATA and |
| | | |ACKNOWLEDGMENT.|
+----------------------+-----+----------------------+---------------+
|6TiSCH-K2-ENC-MIC128 |14 |IEEE802154-AES-CCM-128|Use ENC-MIC-128|
| | | |for DATA and |
| | | |ACKNOWLEDGMENT.|
+----------------------+-----+----------------------+---------------+
Table 6: Key Usage values.
表6：キー使用量の値。
When the 6LBR receives the Configuration object containing a link-layer key set, it MUST immediately install and start using the new keys for all outgoing traffic and remove any old keys it has installed from the previous key set after a delay of COJP_REKEYING_GUARD_TIME has passed. This mechanism is used by the JRC to force the 6LBR to start sending traffic with the new key. The decision is made by the JRC when it has determined that the new key has been made available to all (or some overwhelming majority) of nodes. Any node that the JRC has not yet reached at that point is either nonfunctional or in extended sleep such that it will not be reached. To get the key update, such a node will need to go through the join process anew.
6LBRがリンクレイヤキーセットを含む構成オブジェクトを受信すると、すべての発信トラフィックの新しいキーをすぐにインストールして開始し、COJP_REKYING_TIMEの遅延が経過した後に前のキーセットからインストールされた古いキーを削除する必要があります。このメカニズムは、JRCが新しいキーを使用してトラフィックの送信を開始するように6LBRを強制するために使用されます。その決定は、新しいキーがすべての（またはいくつかの圧倒的多数）ノードに利用可能にされたと判断したときにJRCによって行われます。その時点でJRCがまだ達していないノードは、それが到達しないように機能しないまたは拡張スリープ内のいずれかです。キーアップデートを取得するために、そのようなノードは参加プロセスを新しくする必要があります。
When a regular 6LN receives the Configuration object with a link-layer key set, it MUST install the new keys. The 6LN will use both the old and the new keys to decrypt and authenticate any incoming traffic that arrives based upon the key identifier in the packet. It MUST continue to use the old keys for all outgoing traffic until it has detected that the network has switched to the new key set.
通常の6LNがリンクレイヤーのキーセットを使用して構成オブジェクトを受信すると、新しいキーをインストールする必要があります。6LNは、古いキーと新しいキーの両方を使用して、パケット内のキー識別子に基づいて到着する着信トラフィックを復号化および認証します。ネットワークが新しいキーセットに切り替わったことが検出されるまで、すべての発信トラフィックの古いキーを使用する必要があります。
The detection of the network switch is based upon the receipt of traffic secured with the new keys. Upon the reception and the successful security processing of a link-layer frame secured with a key from the new key set, a 6LN MUST then switch to sending all outgoing traffic using the keys from the new set. The 6LN MUST remove any keys it had installed from the previous key set after waiting COJP_REKEYING_GUARD_TIME since it started using the new key set.
ネットワークスイッチの検出は、新しいキーで保護されたトラフィックの受信に基づいています。新しいキーセットからキーで保護されたリンクレイヤフレームの受信とセキュリティ処理が成功したら、新しいセットからのキーを使用してすべての発信トラフィックを送信するように6LNを切り替える必要があります。6LNは、COJP_REKYING_GUARD_TIMEを待機してから新しいキー・セットを使用して開始した後、前のキー・セットからインストールしたキーを削除する必要があります。
Sending traffic with the new keys signals to other downstream nodes to switch to their new key, causing a ripple of key updates around each 6LBR.
新しいキーを他のダウンストリームノードに送信するトラフィックを送信して新しいキーに切り替わり、各6LBRの周囲にキーアップデートのリップルが発生します。
When Link_Layer_Key is used in the context of [IEEE802.15.4], the following considerations apply.
[IEEE802.15.4]のコンテキストでlink_layer_keyが使用されている場合、以下の考慮事項が適用されます。
Signaling of different keying modes of [IEEE802.15.4] is done based on the parameter values present in a Link_Layer_Key object. For instance, the value of the key_id parameter in combination with key_addinfo denotes which of the four Key ID modes of [IEEE802.15.4] is used and how.
[IEEE802.15.4]の異なるキーイングモードのシグナリングは、link_layer_keyオブジェクトに存在するパラメータ値に基づいて行われます。たとえば、KEY_ADDINFOと組み合わせたKEY_IDパラメーターの値は、[IEEE802.15.4]の4つのキーIDモードのどれを使用していますか。
Key ID Mode 0x00 (Implicit, pairwise): The key_id parameter MUST be set to 0. The key_addinfo parameter MUST be present. The key_addinfo parameter MUST be set to the link-layer address(es) of a single peer with whom the key should be used. Depending on the configuration of the network, key_addinfo may carry the peer's long link-layer address (i.e., pledge identifier), short link-layer address, or their concatenation with the long address being encoded first. Which address type(s) is carried is determined from the length of the byte string.
キーIDモード0x00（暗黙的、ペアワイズ）：key_idパラメータは0に設定する必要があります。key_addinfoパラメータが存在している必要があります。key_addinfoパラメータは、キーを使用するシングルピアのリンクレイヤアドレス（ES）に設定する必要があります。ネットワークの構成に応じて、key_addinfoはピアのロングリンク層アドレス（すなわち、誓約識別子）、ショートリンクレイヤアドレス、またはそれらの連結が最初にエンコードされている長いアドレスとの連結を搬送することができる。どのアドレスタイプが搭載されているかは、バイト文字列の長さから決定されます。
Key ID Mode 0x01 (Key Index): The key_id parameter MUST be set to a value different from 0. The key_addinfo parameter MUST NOT be present.
キーIDモード0x01（キーインデックス）：key_idパラメータは0とは異なる値に設定する必要があります.key_addinfoパラメータは存在してはいけません。
Key ID Mode 0x02 (4-byte Explicit Key Source): The key_id parameter MUST be set to a value different from 0. The key_addinfo parameter MUST be present. The key_addinfo parameter MUST be set to a byte string, exactly 4 bytes long. The key_addinfo parameter carries the Key Source parameter used to configure [IEEE802.15.4].
キーIDモード0x02（4バイトの明示キーソース）：key_idパラメータは0とは異なる値に設定する必要があります.key_addinfoパラメータが存在している必要があります。key_addinfoパラメータは、正確に4バイトの長さで、バイト文字列に設定する必要があります。key_addinfoパラメーターには、[IEEE802.15.4]の設定に使用される鍵ソースパラメーターが掲載されています。
Key ID Mode 0x03 (8-byte Explicit Key Source): The key_id parameter MUST be set to a value different from 0. The key_addinfo parameter MUST be present. The key_addinfo parameter MUST be set to a byte string, exactly 8 bytes long. The key_addinfo parameter carries the Key Source parameter used to configure [IEEE802.15.4].
キーIDモード0x03（8バイトの明示キーソース）：key_idパラメータは0とは異なる値に設定する必要があります。key_addinfoパラメータが存在している必要があります。key_addinfoパラメータは、正確に8バイトの長さで、バイト文字列に設定する必要があります。key_addinfoパラメーターには、[IEEE802.15.4]の設定に使用される鍵ソースパラメーターが掲載されています。
In all cases, the key_usage parameter determines how a particular key should be used with respect to incoming and outgoing security policies.
すべての場合において、key_usageパラメータは、着信および発信セキュリティポリシーに関して特定のキーをどのように使用するかを決定します。
For Key ID Modes 0x01 through 0x03, the key_id parameter sets the "secKeyIndex" parameter of [IEEE802.15.4] that is signaled in all outgoing frames secured with a given key. The maximum value that key_id can have is 254. The value of 255 is reserved in [IEEE802.15.4] and is therefore considered invalid.
キーIDモード0x01~0x03の場合、key_idパラメータは、指定されたキーで保護されたすべての発信フレームでシグナリングされている[IEEE802.15.4]の「seckeyIndex」パラメータを設定します。key_idが持つことができる最大値は254です.255の値は[IEEE802.15.4]に予約されており、したがって無効と見なされます。
Key ID Mode 0x00 (Implicit, pairwise) enables the JRC to act as a trusted third party and assign pairwise keys between nodes in the network. How the JRC learns about the network topology is out of scope of this specification, but it could be done through 6LBR-JRC signaling, for example. Pairwise keys could also be derived through a key agreement protocol executed between the peers directly, where the authentication is based on the symmetric cryptographic material provided to both peers by the JRC. Such a protocol is out of scope of this specification.
キーIDモード0x00（暗黙的、ペアワイズ）は、JRCが信頼できる第三者として機能し、ネットワーク内のノード間でペアワイズキーを割り当てることができます。ネットワークトポロジについてJRCがどのように学習するかは、この仕様の範囲外ですが、たとえば6LBR-JRCシグナリングを通じて行うことができます。ペアワイズキーは、ピア間で直接実行されるキー契約プロトコルを通じて、認証はJRCによって両方のピアに提供される対称暗号材料に基づいています。そのようなプロトコルはこの仕様の範囲外である。
Implementations MUST use different link-layer keys when using different authentication tag (MIC) lengths, as using the same key with different authentication tag lengths might be unsafe. For example, this prohibits the usage of the same key for both MIC-32 and MIC-64 levels. See Annex B.4.3 of [IEEE802.15.4] for more information.
異なる認証タグの長さを持つ同じキーを使用すると、実際の認証タグ（MIC）の長さを使用するときに実装が異なるリンクレイヤキーを使用する必要があります。たとえば、MIC-32とMIC-64レベルの両方に同じキーの使用を禁止します。詳細については、[IEEE802.15.4]の附属書B.4.3を参照してください。
The Short_Identifier object represents an identifier assigned to the pledge. It is encoded as a CBOR array object and contains, in order:
short_identifierオブジェクトは、誓約に割り当てられている識別子を表します。これはCBOBOR配列オブジェクトとしてエンコードされ、次のようになります。
identifier: The short identifier assigned to the pledge, encoded as a byte string. This parameter MUST be included. The identifier MUST be unique in the set of all identifiers assigned in a network that is managed by a JRC. If the identifier is invalid, the decoder MUST silently ignore the Short_Identifier object.
識別子：BYTE文字列としてエンコードされたPREDGEに割り当てられている短識別子。このパラメータを含める必要があります。識別子は、JRCによって管理されているネットワークで割り当てられているすべての識別子のセット内で一意である必要があります。識別子が無効な場合、デコーダはShort_Identifierオブジェクトを黙って無視する必要があります。
lease_time: The validity of the identifier in hours after the reception of the CBOR object, encoded as a CBOR unsigned integer. This parameter MAY be included. The node MUST stop using the assigned short identifier after the expiry of the lease_time interval. It is up to the JRC to renew the lease before the expiry of the previous interval. The JRC updates the lease by executing the parameter update exchange with the node and including the Short_Identifier in the Configuration object, as described in Section 8.2. If the lease expires, then the node SHOULD initiate a new join exchange, as described in Section 8.1. If this parameter is omitted, then the value of positive infinity MUST be assumed, meaning that the identifier is valid for as long as the node participates in the network.
LEASE_TIME：CBOBORオブジェクトの受信後の時間単位での識別子の有効性は、CBOR符号なし整数としてエンコードされます。このパラメータを含めることができます。ノードは、LEASE_TIME間隔の有効期限後に割り当てられた短識別子を使用するのを停止しなければなりません。前の間隔の満了前にリースを更新するのはJRC次第です。JRCは、セクション8.2で説明されているように、ノードとパラメータ更新交換を実行することによってリースを更新します。リースが期限切れになると、セクション8.1で説明されているように、ノードは新しい結合交換を開始する必要があります。このパラメータが省略されている場合、正の無限大の値を想定する必要があります。つまり、識別子はノードがネットワークに参加する限り有効です。
The CDDL fragment for the Short_Identifier that represents the text above follows:
上記のテキストを表すshort_identifierのCDDLフラグメントは次のとおりです。
Short_Identifier = [
identifier : bstr,
? lease_time : uint
]
When the Short_Identifier is used in the context of [IEEE802.15.4], the following considerations apply.
[IEEE802.15.4]のコンテキストでShort_Identifierが使用されている場合、以下の考慮事項が適用されます。
The identifier MUST be used to set the short address of the IEEE Std 802.15.4 module. When operating in TSCH mode, the identifier MUST be unique in the set of all identifiers assigned in multiple networks that share link-layer key(s). If the length of the byte string corresponding to the identifier parameter is different from 2, the identifier is considered invalid. The values 0xfffe and 0xffff are reserved by [IEEE802.15.4], and their use is considered invalid.
IEEE STD 802.15.4モジュールの短いアドレスを設定するには、識別子を使用する必要があります。TSCHモードで動作するとき、識別子は、リンクレイヤキーを共有する複数のネットワークで割り当てられているすべての識別子のセット内で一意でなければなりません。識別子パラメータに対応するバイト文字列の長さが2と異なる場合、識別子は無効と見なされます。値0xFFFEと0xFFFFは[IEEE802.15.4]で予約されており、それらの使用は無効と見なされます。
The security properties offered by the [IEEE802.15.4] link-layer in TSCH mode are conditioned on the uniqueness requirement of the short identifier (i.e., short address). The short address is one of the inputs in the construction of the nonce, which is used to protect link-layer frames. If a misconfiguration occurs, and the same short address is assigned twice under the same link-layer key, the loss of security properties is imminent. For this reason, practices where the pledge generates the short identifier locally are not safe and are likely to result in the loss of link-layer security properties.
TSCHモードの[IEEE802.15.4]リンク層が提供するセキュリティプロパティは、短識別子の一意性要件（すなわち、短いアドレス）で調整される。短いアドレスは、リンク層のフレームを保護するために使用されるNonceの構築における入力の1つです。誤構成が発生し、同じ短いアドレスが同じリンクレイヤキーの下で2回割り当てられている場合、セキュリティプロパティの損失は差し迫っています。このため、誓約が短識別子をローカルに生成する慣行は安全ではなく、リンク層のセキュリティプロパティの損失をもたらす可能性があります。
The JRC MUST ensure that at any given time there are never two of the same short identifiers being used under the same link-layer key. If the lease_time parameter of a given Short_Identifier object is set to positive infinity, care needs to be taken that the corresponding identifier is not assigned to another node until the JRC is certain that it is no longer in use, potentially through out-of-band signaling. If the lease_time parameter expires for any reason, the JRC should take into consideration potential ongoing transmissions by the joined node, which may be hanging in the queues, before assigning the same identifier to another node.
JRCは、同じリンクレイヤキーの下で使用されているのと同じ短識別子のうちの2つが使用されていないことを確認する必要があります。与えられたShort_IdentifierオブジェクトのLEASE_TIMEパラメータが正の無限大に設定されている場合、JRCが使用されなくなったことが、潜在的には帯域外になるまで、対応する識別子が別のノードに割り当てられていないことを注意する必要がある。シグナリングLEASE_TIMEパラメータが何らかの理由で期限切れば、JRCは、同じ識別子を別のノードに割り当てる前に、キューにぶら下がっている可能性がある結合ノードによる潜在的な送信伝送を考慮に入れる必要があります。
Care needs to be taken on how the pledge (joined node) configures the expiration of the lease. Since units of the lease_time parameter are in hours after the reception of the CBOR object, the pledge needs to convert the received time to the corresponding Absolute Slot Number in the network. The joined node (pledge) MUST only use the Absolute Slot Number as the appropriate reference of time to determine whether the assigned short identifier is still valid.
Predge（結合ノード）がリースの満了を設定する方法については、注意が必要です。LEASE_TIMEパラメータの単位はCBORオブジェクトの受信後の数時間であるため、受信した時間をネットワーク内の対応する絶対スロット番号に変換する必要があります。結合されたノード（PLEDDE）は、割り当てられた短識別子がまだ有効であるかどうかを判断するために、適切な時間の参照として絶対スロット番号を使用する必要があります。
The Unsupported_Configuration object is encoded as a CBOR array, containing at least one Unsupported_Parameter object. Each Unsupported_Parameter object is a sequence of CBOR elements without an enclosing top-level CBOR object for compactness. The set of parameters that appear in an Unsupported_Parameter object is summarized below, in order:
Unsupported_Configurationオブジェクトは、少なくとも1つのUnsupported_Parameterオブジェクトを含むCBOBOR配列としてエンコードされています。各UNSUPPORTED_PARAMETERオブジェクトは、コンパクトさのために囲まれた最上位炭素オブジェクトなしのCBOR要素のシーケンスです。Unsupported_Parameterオブジェクトに表示されるパラメータのセットは、以下に要約されています。
code: Indicates the capability of acting on the parameter signaled by parameter_label, encoded as an integer. This parameter MUST be included. Possible values of this parameter are specified in the IANA "Constrained Join Protocol (CoJP) Unsupported Configuration Codes" registry (Section 11.3).
コード：整数としてエンコードされたPARAMETER_LABELによってシグナリングされたパラメータに行動する機能を示します。このパラメータを含める必要があります。このパラメータの可能な値は、IANA "制約付き結合プロトコル（COJP）サポートされていないコンフィギュレーションコード"レジストリ（セクション11.3）に指定されています。
parameter_label: Indicates the parameter. This parameter MUST be included. Possible values of this parameter are specified in the label column of the IANA "Constrained Join Protocol (CoJP) Parameters" registry" (Section 11.1).
parameter_label：パラメータを示します。このパラメータを含める必要があります。このパラメータの可能な値は、IANA "制約付き結合プロトコル（COJP）パラメータ"レジストリ "のラベル列に指定されています（セクション11.1）。
parameter_addinfo: Additional information about the parameter that cannot be acted upon. This parameter MUST be included. If the code is set to "Unsupported", parameter_addinfo gives additional information to the JRC. If the parameter indicated by parameter_label cannot be acted upon regardless of its value, parameter_addinfo MUST be set to null, signaling to the JRC that it SHOULD NOT attempt to configure the parameter again. If the pledge can act on the parameter, but cannot configure the setting indicated by the parameter value, the pledge can hint this to the JRC. In this case, parameter_addinfo MUST be set to the value of the parameter that cannot be acted upon following the normative parameter structure specified in this document. For example, it is possible to include the link-layer key set object, signaling that either a subset or the entire key set that was received cannot be acted upon. In that case, the value of parameter_addinfo follows the link-layer key set structure defined in Section 8.4.2. If the code is set to "Malformed", parameter_addinfo MUST be set to null, signaling to the JRC that it SHOULD NOT attempt to configure the parameter again.
PARAMETER_ADDINFO：実行できないパラメータに関する追加情報。このパラメータを含める必要があります。コードが「サポートされていない」に設定されている場合、PARAMETER_ADDINFOはJRCに追加情報を提供します。 PARAMETER_LABELによって示されたパラメーターをその値に関係なく行動できない場合、PARAMETER_ADDINFOをNULLに設定する必要があります。 PREDGEがパラメータに作用できるが、パラメータ値で示される設定を構成できない場合、PREDGEはこれをJRCにヒントすることができます。この場合、このドキュメントで指定されている規範的なパラメータ構造に従って、PARAMETER_ADDINFOをパラメータの値に設定する必要があります。例えば、リンクレイヤキーセットオブジェクトを含めることができ、サブセットまたは受信したキーセット全体のいずれかを行動することができないことを知らせることが可能である。その場合、PARAMETER_ADDINFOの値は、セクション8.4.2で定義されているリンクレイヤのキー・セット構造に従います。コードが "malformed"に設定されている場合、parameter_addinfoをnullに設定する必要があります。これは、パラメータを再度設定しようとしないであろうJRCへのシグナリングです。
The CDDL fragment for the Unsupported_Configuration and Unsupported_Parameter objects that represents the text above follows:
上記のテキストを表すunsupported_configurationおよびsupported_parameterオブジェクトのCDDLフラグメント。
Unsupported_Configuration = [
+ parameter : Unsupported_Parameter
]
Unsupported_Parameter = (
code : int,
parameter_label : int,
parameter_addinfo : nil / any
)
+=============+=======+==============================+===========+
| Name | Value | Description | Reference |
+=============+=======+==============================+===========+
| Unsupported | 0 | The indicated setting is not | RFC 9031 |
| | | supported by the networking | |
| | | stack implementation. | |
+-------------+-------+------------------------------+-----------+
| Malformed | 1 | The indicated parameter | RFC 9031 |
| | | value is malformed. | |
+-------------+-------+------------------------------+-----------+
Table 7: Unsupported Configuration code values.
表7：サポートされていない構成コード値。
This section gives RECOMMENDED values of CoJP settings.
このセクションでは、COJP設定の推奨値を示します。
+==========================+===============+
| Name | Default Value |
+==========================+===============+
| COJP_MAX_JOIN_ATTEMPTS | 4 |
+--------------------------+---------------+
| COJP_REKEYING_GUARD_TIME | 12 seconds |
+--------------------------+---------------+
Table 8: Recommended CoJP settings.
表8：推奨されるCOJP設定。
The COJP_REKEYING_GUARD_TIME value SHOULD take into account possible retransmissions at the link layer due to imperfect wireless links.
cojp_reking_guard_time値は、不完全な無線リンクのためにリンク層での再送信の可能性を考慮に入れるべきです。
Since this document uses the pledge identifier to set the ID Context parameter of OSCORE, an important security requirement is that the pledge identifier is unique in the set of all pledge identifiers managed by a JRC. The uniqueness of the pledge identifier ensures unique (key, nonce) pairs for the AEAD algorithm used by OSCORE. It also allows the JRC to retrieve the correct security context upon the reception of a Join Request message. The management of pledge identifiers is simplified if the globally unique EUI-64 is used, but this comes with privacy risks, as discussed in Section 10.
このドキュメントはPELDGED IDを使用してOSCOREのIDコンテキストパラメータを設定するため、重要なセキュリティ要件は、JRCによって管理されているすべての誓約識別子のセット内で一意であることです。PELDGED IDの一意性は、OSCOREによって使用されるAEDアルゴリズムのための固有の（キー、NONCE）ペアを保証します。また、JRCは、結合要求メッセージを受信したときに正しいセキュリティコンテキストを検索することもできます。グローバルにユニークなEUI-64が使用されている場合、誓約識別子の管理は単純化されていますが、セクション10で説明したように、プライバシーリスクが付属しています。
This document further mandates that the (6LBR) pledge and the JRC are provisioned with unique PSKs. While the process of provisioning PSKs to all pledges can result in a substantial operational overhead, it is vital to do so for the security properties of the network. The PSK is used to set the OSCORE Master Secret during security context derivation. This derivation process results in OSCORE keys that are important for mutual authentication of the (6LBR) pledge and the JRC. The resulting security context shared between the pledge (joined node) and the JRC is used for the purpose of joining and is long-lived in that it can be used throughout the lifetime of a joined node for parameter update exchanges. Should an attacker come to know the PSK, then a man-in-the-middle attack is possible.
この文書では、（6LBR）の誓約とJRCに固有のPSKがプロビジョニングされていることをさらに説明します。PSKをすべてのPLEDGESにプロビジョニングするプロセスは、実質的な操作上のオーバーヘッドをもたらす可能性がありますが、ネットワークのセキュリティプロパティのためにそれをすることは重要です。PSKは、セキュリティコンテキスト導出中にOSCOREマスターシークレットを設定するために使用されます。この派生プロセスは、（6LBR）誓約とJRCの相互認証にとって重要なオスアキーをもたらす。結果として生じるセキュリティコンテキストは、誓約（結合ノード）とJRCとの間で共有されているセキュリティコンテキストが結合する目的で使用され、パラメータ更新の交換のために結合されたノードの寿命を通して使用できるという点で長期にわたる。攻撃者がPSKを知るようになると、中間攻撃が可能です。
Note that while OSCORE provides replay protection, it does not provide an indication of freshness in the presence of an attacker that can drop and/or reorder traffic. Since the Join Request contains no randomness, and the sequence number is predictable, the JRC could in principle anticipate a Join Request from a particular pledge and pre-calculate the response. In such a scenario, the JRC does not have to be alive at the time the request is received. This could be relevant in the case when the JRC was temporarily compromised and control was subsequently regained by the legitimate owner.
OSCOREは再生保護を提供するが、トラフィックを削除することができる攻撃者の存在下での鮮度の表示は提供されないことに注意してください。結合要求にはランダム性が含まれず、シーケンス番号が予測可能であるため、JRCは原則として特定の誓約からの結合要求を予測し、応答を事前計算することができます。このようなシナリオでは、要求が受信された時点でJRCは生きている必要はありません。JRCが一時的に損なわれ、続いて正当な所有者によって制御された場合に関連がある可能性があります。
It is of utmost importance to avoid unsafe practices when generating and provisioning PSKs. The use of a single PSK shared among a group of devices is a common pitfall that results in poor security. In this case, the compromise of a single device is likely to lead to a compromise of the entire batch, with the attacker having the ability to impersonate a legitimate device and join the network, generate bogus data, and disturb the network operation. Additionally, some vendors use methods such as scrambling or hashing device serial numbers or their EUI-64 identifiers to generate "unique" PSKs. Without any secret information involved, the effort that the attacker needs to invest into breaking these unsafe derivation methods is quite low, resulting in the possible impersonation of any device from the batch, without even needing to compromise a single device. The use of cryptographically secure random number generators to generate the PSK is RECOMMENDED, see [NIST800-90A] for different mechanisms using deterministic methods.
PSKを生成しプロビジョニングするときの安全でない慣行を避けることは最も重要です。一連のデバイス間で共有されている単一のPSKの使用は、セキュリティが悪いと一般的な落とし穴です。この場合、単一の装置の妥協点は、攻撃者が正当な装置を偽装してネットワークに参加し、ボーガスデータを生成し、ネットワーク操作を妨害することができるにつれて、バッチ全体の妥協をもたらす可能性が高い。さらに、いくつかのベンダーは、スクランブリングまたはハッシュデバイスのシリアル番号またはそれらのEUI-64識別子などの方法を使用して「固有の」PSKを生成する方法を使用します。秘密の情報が含まれていなければ、攻撃者がこれらの危険な導出方法を破壊するために投資する必要があるという努力は非常に低いため、単一の装置を危うくする必要とさえも、バッチからの任意の装置の偽装が可能になります。 PSKを生成するための暗号的に安全な乱数発生器の使用を推奨します。決定論的方法を使用したさまざまなメカニズムについては、[NIST800-90A]を参照してください。
The JP forwards the unauthenticated join traffic into the network. A data cap on the JP prevents it from forwarding more traffic than the network can handle and enables throttling in case of an attack. Note that this traffic can only be directed at the JRC so that the JRC needs to be prepared to handle such unsanitized inputs. The data cap can be configured by the JRC by including a join rate parameter in the Join Response, and it is implemented through the CoAP's PROBING_RATE setting. The use of a data cap at a JP forces attackers to use more than one JP if they wish to overwhelm the network. Marking the join traffic packets with a nonzero DSCP allows the network to carry the traffic if it has capacity, but it encourages the network to drop the extra traffic rather than add bandwidth due to that traffic.
JPは、未認証されていない結合トラフィックをネットワークに転送します。JP上のデータキャップは、ネットワークが扱うことができるよりも多くのトラフィックを転送するのを防ぎ、攻撃の場合にはスロットルを可能にします。このトラフィックはJRCにのみ向けられているため、JRCをこのような不整数型の入力を処理する準備をする必要があることに注意してください。データキャップは、結合応答に結合レートパラメータを含めることによってJRCによって構成することができ、それはCOAPのProbing_Rate設定を通して実装される。JPでデータキャップを使用すると、ネットワークを圧倒したい場合は、攻撃者が複数のJPを使用するように強制します。ゼロ以外のDSCPを使用してTraffic Packetをマークすると、ネットワークが容量がある場合はトラフィックを伝送できますが、そのトラフィックのために帯域幅を追加するのではなく、ネットワークが追加のトラフィックを削除することを奨励します。
The shared nature of the "minimal" cell used for the join traffic makes the network prone to a DoS attack by congesting the JP with bogus traffic. Such an attacker is limited by its maximum transmit power. The redundancy in the number of deployed JPs alleviates the issue and also gives the pledge the possibility to use the best available link for joining. How a network node decides to become a JP is out of scope of this specification.
結合トラフィックに使用される「最小」セルの共有された性質は、JPを偽トラフィックで輻輳することによってネットワークをDOS攻撃に起動させる。そのような攻撃者はその最大送信電力によって制限されている。展開されたJPSの数の冗長性は問題を軽減し、参加のために最高の利用可能なリンクを使用する可能性を提供します。ネットワークノードがJPになることを決定する方法は、この仕様の範囲外です。
At the beginning of the join process, the pledge has no means of verifying the content in the EB and has to accept it at "face value". If the pledge tries to join an attacker's network, the Join Response message will either fail the security check or time out. The pledge may implement a temporary blacklist in order to filter out undesired EBs and try to join using the next seemingly valid EB. This blacklist alleviates the issue but is effectively limited by the node's available memory. Note that this temporary blacklist is different from the one communicated as part of the CoJP Configuration object as it helps the pledge fight a DoS attack. The bogus beacons prolong the join time of the pledge and so does the time spent in "minimal" duty cycle mode [RFC8180]. The blacklist communicated as part of the CoJP Configuration object helps the JP fight a DoS attack by a malicious pledge.
結合プロセスの開始時に、PredgeはEB内のコンテンツを検証する手段はありませんが、「顔の値」でそれを受け入れる必要があります。誓約が攻撃者のネットワークに参加しようとすると、結合応答メッセージはセキュリティチェックまたはタイムアウトに失敗します。誓約は、望ましくないEBSを除外し、次の一見有効なEBを使用して参加しようとするために一時的なブラックリストを実装することができる。このブラックリストは問題を軽減しますが、ノードの使用可能なメモリによって効果的に制限されています。この一時的なブラックリストは、誓約がDOS攻撃と戦うのに役立つので、COJP構成オブジェクトの一部として通信されたものとは異なることに注意してください。Bogusビーコンは、誓約の結合時間を延ばし、そのため、「最小」デューティサイクルモード[RFC8180]に費やされた時間を過ごします。COJP構成オブジェクトの一部として通信されたブラックリストは、JPが悪意のある誓約によるDOS攻撃と戦うのに役立ちます。
During the network lifetime, the JRC may at any time initiate a parameter update exchange with a joined node. The Parameter Update message uses the same OSCORE security context as is used for the join exchange, except that the server and client roles are interchanged. As a consequence, each Parameter Update message carries the well-known OSCORE Sender ID of the JRC. A passive attacker may use the OSCORE Sender ID to identify the Parameter Update traffic if the link-layer protection does not provide confidentiality. A countermeasure against such a traffic-analysis attack is to use encryption at the link layer. Note that the join traffic does not undergo link-layer protection at the first hop, as the pledge is not yet in possession of cryptographic keys. Similarly, EB traffic in the network is not encrypted. This makes it easy for a passive attacker to identify these types of traffic.
ネットワークの有効期間中、JRCはいつでも接続されたノードとのパラメータ更新交換を開始することができる。Parameter Updateメッセージは、サーバーとクライアントの役割が交換されている点を除いて、JOIN Exchangeに使用されるのと同じOSCOREセキュリティコンテキストを使用します。結果として、各パラメータ更新メッセージは、JRCの周知のオスア送信者IDを搬送する。パッシブ攻撃者は、リンク層保護が機密性を提供しない場合、オスア送信者IDを使用してパラメータ更新トラフィックを識別することができる。そのようなトラフィック分析攻撃に対する対策は、リンク層で暗号化を使用することです。誓約がまだ暗号鍵を所有していないので、結合トラフィックは最初のホップでリンク層保護を受けないことに注意してください。同様に、ネットワーク内のEBトラフィックは暗号化されていません。これにより、受動的な攻撃者がこれらのタイプのトラフィックを特定するのが簡単になります。
The join solution specified in this document relies on the uniqueness of the pledge identifier in the set of all pledge identifiers managed by a JRC. This identifier is transferred in the clear as an OSCORE 'kid context'. The use of the globally unique EUI-64 as pledge identifier simplifies the management but comes with certain privacy risks. The implications are thoroughly discussed in [RFC7721] and comprise correlation of activities over time, location tracking, address scanning, and device-specific vulnerability exploitation. Since the join process occurs rarely compared to the network lifetime, long-term threats that arise from using EUI-64 as the pledge identifier are minimal. However, after the join process completes, the use of EUI-64 in the form of a Layer 2 or Layer 3 address extends the aforementioned privacy threats to the long term.
この文書で指定された結合ソリューションは、JRCによって管理されているすべての誓約識別子のセット内のPREDGE IDの一意性に依存しています。この識別子は、オスアの子コンテキストとしてクリアに転送されます。PLEDDE IDとしてグローバルに独自のEUI-64を使用すると、管理が簡単になりますが、特定のプライバシーリスクが付属しています。影響は[RFC7721]で徹底的に議論され、経時的、位置追跡、アドレススキャン、および装置固有の脆弱性活動の経過とともに活動の相関関係を含む。結合プロセスはネットワークの寿命と比較して行われるので、eUI-64をPELDGE-64として使用することから生じる長期的な脅威は最小限です。しかしながら、結合プロセスが完了した後、レイヤ2またはレイヤ3アドレスの形式のEUI-64の使用は、前述のプライバシーの脅威を長期的に拡張する。
As an optional mitigation technique, the Join Response message may contain a short address that is assigned by the JRC to the (6LBR) pledge. The assigned short address SHOULD be uncorrelated with the long-term pledge identifier. The short address is encrypted in the response. Once the join process completes, the new node may use the short addresses for all further Layer 2 (and Layer 3) operations. This reduces the privacy threats as the short Layer 2 address (visible even when the network is encrypted) does not disclose the manufacturer, as is the case of EUI-64. However, an eavesdropper with access to the radio medium during the join process may be able to correlate the assigned short address with the extended address based on timing information with a non-negligible probability. This probability decreases with an increasing number of pledges joining concurrently.
オプションの緩和技術として、結合応答メッセージは、JRCによって（6LBR）誓約に割り当てられている短いアドレスを含み得る。割り当てられた短いアドレスは、長期誓約識別子と相関しないはずです。短いアドレスは応答で暗号化されています。結合プロセスが完了すると、新しいノードはさらなるレイヤ2（およびレイヤ3）操作に対して短いアドレスを使用することができる。これにより、短いレイヤ2アドレス（ネットワークが暗号化されている場合でも表示されている）としてプライバシーの脅威が減少します（ネットワークが暗号化されている場合でも表示されます）。しかしながら、結合プロセス中に無線媒体にアクセスする盗聴者は、無視されない確率でタイミング情報に基づいて割り当てられた短いアドレスを拡張アドレスと相関させることができるかもしれない。この確率は、同時に接合する施行量が増加するにつれて減少する。
This document allocates a well-known name under the .arpa name space according to the rules given in [RFC3172] and [RFC6761]. The name "6tisch.arpa" is requested. No subdomains are expected, and addition of any such subdomains requires the publication of an IETF Standards Track RFC. No A, AAAA, or PTR record is requested.
この文書は、[RFC3172]と[RFC6761]で指定された規則に従って、.ARPAの名前空間の下にある有名な名前を割り当てます。"6tisch.arpa"という名前が要求されます。サブドメインは予想されず、そのようなサブドメインの追加は、IETF規格トラックRFCの出版を必要とします。A、AAAA、またはPTRレコードが要求されていません。
This section defines a subregistry within the "IPv6 Over the TSCH Mode of IEEE 802.15.4 (6TiSCH)" registry with the name "Constrained Join Protocol (CoJP) Parameters".
このセクションでは、「IEEE 802.15.4（6tisch）」の「IEEE 802.15.4（6tisch）」レジストリを「制約付き結合プロトコル（COJP）パラメータ」と定義しています。
The columns of the registry are:
レジストリの列は次のとおりです。
Name: This is a descriptive name that enables an easier reference to the item. It is not used in the encoding. The name MUST be unique.
name：これはアイテムをより簡単にすることを可能にする説明的な名前です。エンコーディングには使用されません。名前は一意である必要があります。
Label: The value to be used to identify this parameter. The label is an integer. The label MUST be unique.
レーベル：このパラメータを識別するために使用される値。ラベルは整数です。ラベルは一意でなければなりません。
CBOR Type: This field contains the CBOR type for the field.
CBORタイプ：このフィールドには、フィールドのCBOR型が含まれています。
Description: This field contains a brief description for the field. The description MUST be unique.
説明：このフィールドには、フィールドの簡単な説明が含まれています。説明は一意でなければなりません。
Reference: This field contains a pointer to the public specification for the field, if one exists.
リファレンス：このフィールドには、存在する場合は、フィールドのパブリック指定へのポインタが含まれています。
This registry is populated with the values in Table 5.
このレジストリには、表5の値が入力されています。
The amending formula for this subregistry is: Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are designated as Expert Review. Integer values less than -65536 are marked as Private Use.
このサブレジストの修正式は次のとおりです。値の異なる範囲は、異なる登録ポリシーを使用します[RFC8126]。-256から255の整数値は標準アクションとして指定されています。-65536から-257および256から65535までの整数値は、必要な仕様として指定されています。65535より大きい整数値はエキスパートレビューとして指定されています。-65536未満の整数値はプライベート使用としてマークされています。
This section defines a subregistry within the "IPv6 Over the TSCH Mode of IEEE 802.15.4 (6TiSCH)" registry with the name "Constrained Join Protocol (CoJP) Key Usage".
このセクションでは、 "IEEE 802.15.4（6tisch）"のTSCHモードの "IPv6 over of IEEE 802.15.4（6tisch）"レジストリ "という名前の" "" increded Join Protocol（COJP）キー使用法 "。
The columns of this registry are:
このレジストリの列は次のとおりです。
Name: This is a descriptive name that enables easier reference to the item. It is not used in the encoding. The name MUST be unique.
name：これは、アイテムをより簡単に参照できるような説明的な名前です。エンコーディングには使用されません。名前は一意である必要があります。
Value: This is the value used to identify the key usage setting. These values MUST be unique. The value is an integer.
値：これは、キー使用法設定を識別するために使用される値です。これらの値は一意でなければなりません。値は整数です。
Algorithm: This is a descriptive name of the link-layer algorithm in use and uniquely determines the key length. The name is not used in the encoding. The algorithm MUST be unique.
アルゴリズム：これは、使用中のリンク層アルゴリズムの説明的な名前であり、キーの長さを一意に決定します。名前はエンコーディングでは使用されません。アルゴリズムは一意でなければなりません。
Description: This field contains a description of the key usage setting. The field should describe in enough detail how the key is to be used with different frame types, specific for the link-layer technology in question. The description MUST be unique.
説明：このフィールドには、キー使用法設定の説明が含まれています。このフィールドは、問題のリンクレイヤー技術に特有のさまざまなフレームタイプでキーの使用方法を十分に詳細に説明する必要があります。説明は一意でなければなりません。
Reference: This contains a pointer to the public specification for the field, if one exists.
参照：これには、フィールドのパブリック仕様へのポインタがあります。
This registry is populated with the values in Table 6.
このレジストリには表6の値が入力されています。
The amending formula for this subregistry is: Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are designated as Expert Review. Integer values less than -65536 are marked as Private Use.
このサブレジストの修正式は次のとおりです。値の異なる範囲は、異なる登録ポリシーを使用します[RFC8126]。-256から255の整数値は標準アクションとして指定されています。-65536から-257および256から65535までの整数値は、必要な仕様として指定されています。65535より大きい整数値はエキスパートレビューとして指定されています。-65536未満の整数値はプライベート使用としてマークされています。
This section defines a subregistry within the "IPv6 Over the TSCH Mode of IEEE 802.15.4 (6TiSCH)" registry with the name "Constrained Join Protocol (CoJP) Unsupported Configuration Codes".
このセクションでは、 "IEEE 802.15.4（6tisch）"の "IEEE 802.15.4（6tisch）"レジストリのTSCHモードで "IPv6の" "" Snalsided Join Protocol（cojp）サポートされていないコンフィギュレーションコード "。
The columns of this registry are:
このレジストリの列は次のとおりです。
Name: This is a descriptive name that enables easier reference to the item. It is not used in the encoding. The name MUST be unique.
name：これは、アイテムをより簡単に参照できるような説明的な名前です。エンコーディングには使用されません。名前は一意である必要があります。
Value: This is the value used to identify the diagnostic code. These values MUST be unique. The value is an integer.
値：これは診断コードを識別するために使用される値です。これらの値は一意でなければなりません。値は整数です。
Description: This is a descriptive human-readable name. The description MUST be unique. It is not used in the encoding.
説明：これは記述的な人間読み取り可能な名前です。説明は一意でなければなりません。エンコーディングには使用されません。
Reference: This contains a pointer to the public specification for the field, if one exists.
参照：これには、フィールドのパブリック仕様へのポインタがあります。
This registry is to be populated with the values in Table 7.
このレジストリには、表7の値が入力されます。
The amending formula for this subregistry is: Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are designated as Expert Review. Integer values less than -65536 are marked as Private Use.
このサブレジストの修正式は次のとおりです。値の異なる範囲は、異なる登録ポリシーを使用します[RFC8126]。-256から255の整数値は標準アクションとして指定されています。-65536から-257および256から65535までの整数値は、必要な仕様として指定されています。65535より大きい整数値はエキスパートレビューとして指定されています。-65536未満の整数値はプライベート使用としてマークされています。
[IEEE802.15.4] IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE Standard 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875, April 2016, <https://ieeexplore.ieee.org/document/7460875>.
[IEEE802.15.4] IEEE、「低速ワイヤレスネットワークのためのIEEE規格」、IEEEスタンダード802.15.4-2015、DOI 10.1109 / IEEESTD.2016.7460875、2016年4月、<https：//ieeexplore.ieee.org/document/7460875>。
[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/RFC2597, June 1999, <https://www.rfc-editor.org/info/rfc2597>.
[RFC2597] Heinanen、J.、Baker、F.、Weiss、W.、およびJ.Wroclawski、「保証された転送PHBグループ」、RFC 2597、DOI 10.17487 / RFC2597、1999年6月、<https：///www.rfc-editor.org/info/rfc2597>。
[RFC3172] Huston, G., Ed., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, September 2001, <https://www.rfc-editor.org/info/rfc3172>.
[RFC3172] Huston、G.、ED。、「アドレスおよびルーティングパラメータエリアドメイン（「ARPA」）」、BCP 52、RFC 3172、DOI 10.17487 / RFC3172、2001年9月、<https：//www.rfc-editor.org/info/rfc3172>。
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.
[RFC5869] Krawczyk、H.およびP. Eronen、「HMACベースの抽出と拡張キー派生機能（HKDF）」、RFC 5869、DOI 10.17487 / RFC 5869、2010年5月、<https：//www.rfc-編集者.org / info / rfc5869>。
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, <https://www.rfc-editor.org/info/rfc6761>.
[RFC6761] Cheshire、S.およびM. KroChmal、RFC 6761、RFC 6761、DOI 10.17487 / RFC6761、2013年2月、<https：//www.rfc-editor.org/info/rfc6761>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K.、C. Bormann、「制約付きアプリケーションプロトコル（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<https：//www.rfc-編集者。ORG / INFO / RFC7252>。
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015, <https://www.rfc-editor.org/info/rfc7554>.
[RFC7554] Watteyne、T.、ED。、Palattella、M.、およびL.Grieco、「IEEE 802.15.4Eタイムスロットチャンネルホッピング（TSCH）（IoT）：問題声明 "、RFC 7554、DOI 10.17487 / RFC7554、2015年5月、<https://www.rfc-editor.org/info/rfc7554>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085] eggert、L.、Fairhurst、G.、およびG.Shepherd、 "UDP使用ガイドライン"、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<https：//www.rfc-editor.org/ info / rfc8085>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, <https://www.rfc-editor.org/info/rfc8152>.
[RFC8152] Schaad、J.、 "CBORオブジェクトの署名と暗号化（CORE）"、RFC 8152、DOI 10.17487 / RFC8152、2017年7月、<https://www.rfc-editor.org/info/rfc8152>。
[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>。
[RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, May 2017, <https://www.rfc-editor.org/info/rfc8180>.
[RFC8180] Vilajosana、X.、ED。、Pister、K.、およびT.Watteyne、「IEEE 802.15.4EのTSCHモードでの最小IPv6（6tisch）構成」、BCP 210、RFC 8180、DOI 10.17487 / RFC8180、2017年5月、<https：//www.rfc-editor.org/info/rfc8180>。
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, <https://www.rfc-editor.org/info/rfc8505>.
[RFC8505] Thubert、P.、Ed。、Nordmark、E.、Chakrabarti、S.およびPerkins、「低電力無線パーソナルエリアネットワーク（6lowpan）隣接ディスカバリーに関するIPv6の登録拡張」、RFC 8505、DOI10.17487 / RFC8505、2018年11月、<https：//www.rfc-editor.org/info/rfc8505>。
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, <https://www.rfc-editor.org/info/rfc8613>.
[RFC8613] Selander、G.、Mattsson、J.、Palombini、F.、およびL.Seitz、「制約のあるRESTFUL環境のためのオブジェクトセキュリティ（OSCORE）」、RFC 8613、DOI 10.17487 / RFC8613、2019年7月、<https：//www.rfc-editor.org/info/rfc8613>。
[RFC8820] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 8820, DOI 10.17487/RFC8820, June 2020, <https://www.rfc-editor.org/info/rfc8820>.
[RFC8820]ノッティンガム、M。、「URI設計と所有権」、BCP 190、RFC 8820、DOI 10.17487 / RFC8820、2020年6月、<https：//www.rfc-editor.org/info/rfc8820>。
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.
[RFC8949] Bormann、C.およびP.HOFFMAN、「簡潔なバイナリオブジェクト表現（CBOR）」、STD 94、RFC 8949、DOI 10.17487 / RFC8949、2020年12月、<https：//www.rfc-editor.org/info/ RFC8949>。
[RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021, <https://www.rfc-editor.org/info/rfc8974>.
[RFC8974] Hartke、K.およびM. Richardson、「制約付きアプリケーションプロトコル（CoAP）」、RFC 8974、DOI 10.17487 / RFC8974、<https：///www.rfc-編集者の拡張トークンおよびステートレスクライアント。ORG / INFO / RFC8974>。
[RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", RFC 9030, DOI 10.17487/RFC9030, May 2021, <https://www.rfc-editor.org/info/rfc9030>.
[RFC9030]「IEEE 802.15.4（6tisch）のタイムスロットチャネルホッピングモード（6Tisch）」、RFC 9030、DOI 10.17487 / RFC9030、<https：//のタイムスロットチャネルホッピングモードでのIPv6のアーキテクチャー。www.rfc-editor.org/info/rfc9030>。
[NIST800-90A] National Institute of Standards and Technology, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", Special Publication 800-90A, Revision 1, DOI 10.6028/NIST.SP.800-90Ar1, June 2015, <https://doi.org/10.6028/NIST.SP.800-90Ar1>.
[NIST800-90A]国立標準技術研究所、「決定論的ランダムビットジェネレータを使用した乱数生成の推奨事項」、特別出版物800-90A、リビジョン1、DOI 10.6028 / NIST.SP.800-90AR1、2015年6月、<HTTPS//doi.org/10.6028/nist.sp.800-90ar1>。
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, DOI 10.17487/RFC4231, December 2005, <https://www.rfc-editor.org/info/rfc4231>.
[RFC4231] NYSTROM、M、「HMAC-SHA-224、HMAC-SHA-384、HMAC-SHA-384、およびHMAC-SHA-384、およびHMAC-SHA-512」、RFC 4231、DOI 10.17487 / RFC4231、2005年12月<https://www.rfc-editor.org/info/rfc4231>。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <https://www.rfc-editor.org/info/rfc4944>.
[RFC4944]モンテネグロ、G.、Kushalnagar、N.、Hui、J.、およびD.Culler、「IEEE 802.15.4ネットワーク上のIPv6パケットの送信」、RFC 4944、DOI 10.17487 / RFC4944、2007年9月、<https：//www.rfc-editor.org/info/rfc4944>。
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <https://www.rfc-editor.org/info/rfc6550>.
[RFC6550]冬、T.、ED。、Thubert、P.、Ed。、Brandt、A.、Hui、J.、Kelsey、R.、Levis、P.、Pister、K.、Struik、R.、Vasseur、JP。、およびR.RPL：低消費電力ネットワークの「RPL：IPv6ルーティングプロトコル」、RFC 6550、DOI 10.17487 / RFC6550、2012年3月、<https：//www.rfc-editor.org/info/RFC6550>。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.
[RFC6762] Cheshire、S.およびM. Krochmal、「マルチキャストDNS」、RFC 6762、DOI 10.17487 / RFC6762、2013年2月、<https：//www.rfc-editor.org/info/rfc6762>。
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <https://www.rfc-editor.org/info/rfc7721>.
[RFC7721] Cooper、A.、Gont、F.、およびD.Thaler、「IPv6アドレス生成メカニズムのためのセキュリティとプライバシーに関する考察」、RFC 7721、DOI 10.17487 / RFC7721、2016年3月、<https：///www.rfc-Editor.org/info/rfc7721>。
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8415] Mrugalski、T.、Sodelski、M.、Volz、B.、Yourtchenko、A.、Richardson、M.、Jiang、S.、Lemon、T.、T.Winters、「IPv6用動的ホスト構成プロトコル」（DHCPv6） "、RFC 8415、DOI 10.17487 / RFC8415、2018年11月、<https：//www.rfc-editor.org/info/rfc8415>。
[RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH Operation Sublayer (6top) Protocol (6P)", RFC 8480, DOI 10.17487/RFC8480, November 2018, <https://www.rfc-editor.org/info/rfc8480>.
[RFC8480] Wang、Q.、ED。、Vilajosana、X.、およびT.Watteyne、 "6tisch操作サブレイヤ（6P）プロトコル（6P）"、RFC 8480、DOI 10.17487 / RFC8480、2018年11月、<https：//www.rfc-editor.org/info/rfc8480>。
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8610] Birkholz、H.、Vigano、C. Bormann、「簡潔なデータ定義言語（CDDL）：簡潔なバイナリオブジェクト表現（CBOR）とJSONデータ構造を表現する表記規則」、RFC 8610、DOI 10.17487/ RFC8610、2019年6月、<https://www.rfc-editor.org/info/rfc8610>。
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/info/rfc8615>.
[RFC8615]ノッティンガム、M、「よく知られているユニフォーム識別子（URIS）」、RFC 8615、DOI 10.17487 / RFC8615、2019年5月、<https：//www.rfc-editor.org/info/rfc8615>。
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, <https://www.rfc-editor.org/info/rfc8742>.
[RFC8742] Bormann、C.、「CBOR）シーケンス」、RFC 8742、DOI 10.17487 / RFC8742、2020年2月、<https://www.rfc-editor.org/info/rfc8742>。
[RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic Autonomic Signaling Protocol (GRASP)", RFC 8990, DOI 10.17487/RFC8990, May 2021, <https://www.rfc-editor.org/info/rfc8990>.
[RFC8990] Bormann、C、Carpenter、B.、ED。、およびB.IU、ED。、「GENICAL自律型シグナリングプロトコル（GRASP）」、RFC 8990、DOI 10.17487 / RFC8990、2021年5月、<https：//www.rfc-editor.org/info/rfc8990>。
Figure 3 illustrates a successful join protocol exchange. The pledge instantiates the OSCORE context and derives the OSCORE keys and nonces from the PSK. It uses the instantiated context to protect the Join Request addressed with a Proxy-Scheme option, the well-known host name of the JRC in the Uri-Host option, and it uses its EUI-64 as pledge identifier and OSCORE 'kid context'. Triggered by the presence of a Proxy-Scheme option, the JP forwards the request to the JRC and sets the CoAP token to the internally needed state. The JP learned the IPv6 address of the JRC when it acted as a pledge and joined the network. Once the JRC receives the request, it looks up the correct context based on the 'kid context' parameter. The OSCORE data authenticity verification ensures that the request has not been modified in transit. In addition, replay protection is ensured through persistent handling of mutable context parameters.
図3は、成功した結合プロトコル交換を示しています。PREDGEはオスアコンテキストをインスタンス化し、PSKからオスアキーとノンスを導きます。インスタンス化されたコンテキストを使用して、プロキシスキームオプション、URI-hostオプションでJRCの有名なホスト名でアドレス指定された参加要求を保護し、そのEUI-64をPLEDDE IDとOSCORE 'KIDコンテキストとして使用します。。プロキシスキームオプションの存在によってトリガーされ、JPは要求をJRCに転送し、CoAPトークンを内部必要な状態に設定します。JPは、それが誓約として機能し、ネットワークに参加したときにJRCのIPv6アドレスを学びました。JRCが要求を受信すると、 'Kid Context'パラメータに基づいて正しいコンテキストを調べます。OSCOREデータの認証検証は、要求がトランジットで変更されていないことを保証します。さらに、再生保護は、可変コンテキストパラメータの永続的な処理によって保証されます。
Once the JP receives the Join Response, it authenticates the state within the CoAP token before deciding where to forward. The JP sets its internal state to that found in the token and forwards the Join Response to the correct pledge. Note that the JP does not possess the key to decrypt the CoJP object (configuration) present in the payload. At the pledge, the Join Response is matched to the Join Request and verified for replay protection using OSCORE processing rules. In this example, the Join Response does not contain the IPv6 address of the JRC, hence the pledge understands that the JRC is co-located with the 6LBR.
JPが結合応答を受信すると、転送先を決定する前に、COAPトークン内の状態を認証します。JPは、その内部状態をトークンにあるものに設定し、結合応答を正しい誓約に転送します。JPは、ペイロードに存在するCOJPオブジェクト（構成）を復号化するための鍵を持たないことに注意してください。PLEDDEでは、結合応答は結合要求と一致し、OSCORE処理規則を使用して再生保護を検証します。この例では、結合応答にJRCのIPv6アドレスが含まれていないため、JRCが6LBRと同じ場所にあることを理解しています。
<-----E2E OSCORE------>
Client Proxy Server
Pledge JP JRC
| | |
| Join | | Code: 0.02 (POST)
| Request | | Token: -
+--------->| | Proxy-Scheme: coap
| | | Uri-Host: 6tisch.arpa
| | | OSCORE: kid: -,
| | | kid_context: EUI-64,
| | | Partial IV: 1
| | | Payload: { Code: 0.02 (POST),
| | | Uri-Path: "j",
| | | join_request, <Tag> }
| | |
| | Join | Code: 0.02 (POST)
| | Request | Token: opaque state
| +--------->| OSCORE: kid: -,
| | | kid_context: EUI-64,
| | | Partial IV: 1
| | | Payload: { Code: 0.02 (POST),
| | | Uri-Path: "j",
| | | join_request, <Tag> }
| | |
| | |
| | Join | Code: 2.04 (Changed)
| | Response | Token: opaque state
| |<---------+ OSCORE: -
| | | Payload: { Code: 2.04 (Changed),
| | | configuration, <Tag> }
| | |
| | |
| Join | | Code: 2.04 (Changed)
| Response | | Token: -
|<---------+ | OSCORE: -
| | | Payload: { Code: 2.04 (Changed),
| | | configuration, <Tag> }
| | |
Figure 3: Example of a successful join protocol exchange. { ... } denotes authenticated encryption, <Tag> denotes the authentication tag.
図3：結合プロトコル交換が成功した例。{...}は認証された暗号化を表し、<tag>は認証タグを表します。
Where the join_request object is:
join_requestオブジェクトが次のとおりです。
join_request:
{
5 : h'cafe' / PAN ID of the network pledge is attempting to join /
}
Since the role parameter is not present, the default role of "6TiSCH Node" is implied.
役割パラメータが存在しないので、 "6tischノード"のデフォルトの役割が暗示されます。
The join_request object is converted to h'a10542cafe' with a size of 5 bytes.
join_requestオブジェクトは、5バイトのサイズのH'A10542CAFE 'に変換されます。
And the configuration object is the following:
そして構成オブジェクトは次のとおりです。
configuration:
{
2 : [ / link-layer key set /
1, / key_id /
h'e6bf4287c2d7618d6a9687445ffd33e6' / key_value /
],
3 : [ / short identifier /
h'af93' / assigned short address /
]
}
Since the key_usage parameter is not present in the link-layer key set object, the default value of "6TiSCH-K1K2-ENC-MIC32" is implied. Since the key_addinfo parameter is not present and key_id is different from 0, Key ID Mode 0x01 (Key Index) is implied. Similarly, since the lease_time parameter is not present in the short identifier object, the default value of positive infinity is implied.
key_usageパラメータはリンク層鍵セットオブジェクトに存在しないので、デフォルト値 "6tisch-k1k2-enc-mic32"が暗示されます。key_addinfoパラメーターが存在せず、key_idは0と異なるため、キーIDモード0x01（キーインデックス）が暗示されます。同様に、LEASE_TIMEパラメータは短識別子オブジェクトに存在しないため、正の無限大のデフォルト値が暗黙的にされます。
The configuration object is converted to the following:
構成オブジェクトは次のように変換されます。
h'a202820150e6bf4287c2d7618d6a9687445ffd33e6038142af93' with a size of 26 bytes.
26バイトのサイズを有するH'A202820150E6BF4287C2D7618D6A9687445FFD333J6038142AF93 '。
In environments where optimizing the implementation footprint is important, it is possible to implement this specification without having the implementations of HKDF [RFC5869] and SHA [RFC4231] on constrained devices. HKDF and SHA are used during the OSCORE security context derivation phase. This derivation can also be done by the JRC or a provisioning device on behalf of the (6LBR) pledge during the provisioning phase. In that case, the derived OSCORE security context parameters are written directly into the (6LBR) pledge, without requiring the PSK to be provisioned to the (6LBR) pledge.
実装フットプリントを最適化する環境では、HKDF [RFC5869]とSHA [RFC4231]の実装を制約付きデバイスに実装せずに本明細書を実装することができます。HKDFおよびSHAは、オスアセキュリティコンテキスト派生段階で使用されます。この導出は、プロビジョニング段階中に（6LBR）誓約を代表してJRCまたはプロビジョニング装置によっても行うことができる。その場合、派生オスアセキュリティコンテキストパラメータは、PSKを（6LBR）誓約にプロビジョニングされることを必要とせずに、（6LBR）誓約に直接書き込まれます。
The use of HKDF to derive OSCORE security context parameters ensures that the resulting OSCORE keys have good security properties and are unique as long as the input varies for different pledges. This specification ensures the uniqueness by mandating unique pledge identifiers and a unique PSK for each (6LBR) pledge. From the AEAD nonce reuse viewpoint, having a unique pledge identifier is a sufficient condition. However, as discussed in Section 9, the use of a single PSK shared among many devices is a common security pitfall. The compromise of this shared PSK on a single device would lead to the compromise of the entire batch. When using the implementation/ deployment scheme outlined above, the PSK does not need to be written to individual pledges. As a consequence, even if a shared PSK is used, the scheme offers a level of security comparable to the scenario in which each pledge is provisioned with a unique PSK. In this case, there is still a latent risk of the shared PSK being compromised on the provisioning device, which would compromise all devices in the batch.
OSCOREセキュリティコンテキストパラメータを導出するためのHKDFの使用は、結果として得られるOSCOREキーが良好なセキュリティプロパティを持ち、入力が異なるPLEDGESに対して異なる限り、独自のものであることを保証します。この仕様は、固有の誓約識別子と各（6LBR）誓約書の固有のPSKを義務付けることによる一意性を保証します。 AED Nonceの再利用ビューポイントから、独自のPREDGE IDを持つことは十分な条件です。ただし、セクション9で説明したように、多くのデバイス間で共有された単一のPSKの使用は一般的なセキュリティの落とし穴です。単一の装置上のこの共有PSKの妥協は、バッチ全体の妥協をもたらすだろう。上記の実装/展開スキームを使用する場合、PSKは個々のPLEDGESに書き込まれる必要はありません。結果として、共有PSKが使用されていても、スキームは各誓約がユニークなPSKでプロビジョニングされているシナリオに匹敵するレベルのセキュリティを提供します。この場合、共有PSKがプロビジョニング装置上で侵入されている潜在的なリスクが依然としてあり、これはバッチ内のすべての装置を危険にさらすであろう。
Acknowledgments
謝辞
The work on this document has been partially supported by the European Union's H2020 Programme for research, technological development and demonstration under grant agreements: No. 644852, project ARMOUR; No. 687884, project F-Interop and open-call project SPOTS; No. 732638, project Fed4FIRE+ and open-call project SODA.
この文書の作業は、助成金協定の下での研究、技術開発、および実証のための欧州連合のH2020プログラムによって部分的に支えられてきました：No。644852、プロジェクト装甲;第687884号、Project F InteropおよびOpen-Callプロジェクトスポット。No. 732638、FRID4FIREおよびOpen-Call Project Soda。
The following individuals provided input to this document (in alphabetic order): Christian Amsüss, Tengfei Chang, Roman Danyliw, Linda Dunbar, Vijay Gurbani, Klaus Hartke, Barry Leiba, Benjamin Kaduk, Tero Kivinen, Mirja Kühlewind, John Mattsson, Hilarie Orman, Alvaro Retana, Adam Roach, Jim Schaad, Göran Selander, Yasuyuki Tanaka, Pascal Thubert, William Vignat, Xavier Vilajosana, Éric Vyncke, and Thomas Watteyne.
次の個人はこの文書への入力を提供しました（アルファベット順）：ChristianAmsüsss、Tengfei Chang、Roman DanyLiw、リンダ・ダンバー、ビジャイ・ガービニ、クラウス・ハルケット、Barry Leiba、BenjaminKühlewind、MirjaKühlewind、John Mattsson、Hilarie Orman、Alvaro Retana、アダムロハド、ジムシャド、景色、田中康之、Pascal Thubert、ウィリアム・ビニャート、Xavier vilajosana、エリオス・ビンケ、そしてThomas Watteyne。
Authors' Addresses
著者の住所
Mališa Vučinić (editor) Inria 2 Rue Simone Iff 75012 Paris France
MalićaVužinić（編集）Inria 2 Rue Simone IFF 75012パリフランス
Email: malisa.vucinic@inria.fr
Jonathan Simon Analog Devices 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 United States of America
Jonathan Simon Analog Devices 32990 Alvarado-Niles Road、Suite 910 Union City、CA 94587アメリカ合衆国
Email: jonathan.simon@analog.com
Kris Pister University of California Berkeley 512 Cory Hall Berkeley, CA 94720 United States of America
カリフォルニア大学バークレー大学512 Cory Hall Berkeley、CA 94720アメリカ合衆国
Email: pister@eecs.berkeley.edu
Michael Richardson Sandelman Software Works 470 Dawson Avenue Ottawa ON K1Z5V7 Canada
Michael Richardson Sandelman Software Works 470 Dawson Avenue Ottawa on K1Z5V7カナダ
Email: mcr+ietf@sandelman.ca