[要約] RFC 9434は、UAS RIDとUAS-RID関連通信をサポートするためのプロトコルとサービスのアーキテクチャを説明しています。このアーキテクチャは、RFC 9153のDRIP要件に準拠しています。
Internet Engineering Task Force (IETF) S. Card
Request for Comments: 9434 A. Wiethuechter
Category: Informational AX Enterprize
ISSN: 2070-1721 R. Moskowitz
HTT Consulting
S. Zhao, Ed.
Intel
A. Gurtov
Linköping University
July 2023
This document describes an architecture for protocols and services to support Unmanned Aircraft System Remote Identification and tracking (UAS RID), plus UAS-RID-related communications. This architecture adheres to the requirements listed in the Drone Remote Identification Protocol (DRIP) Requirements document (RFC 9153).
このドキュメントでは、無人の航空機システムのリモート識別と追跡（UAS RID）とUASリッド関連の通信をサポートするためのプロトコルとサービスのアーキテクチャについて説明します。このアーキテクチャは、ドローンリモート識別プロトコル（DRIP）要件ドキュメント（RFC 9153）にリストされている要件に準拠しています。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc9434.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9434で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Overview of UAS RID and Its Standardization
1.2. Overview of Types of UAS Remote ID
1.2.1. Broadcast RID
1.2.2. Network RID
1.3. Overview of USS Interoperability
1.4. Overview of DRIP Architecture
2. Terms and Definitions
2.1. Additional Abbreviations
2.2. Additional Definitions
3. HHIT as the DRIP Entity Identifier
3.1. UAS Remote Identifiers Problem Space
3.2. HHIT as a Cryptographic Identifier
3.3. HHIT as a Trustworthy DRIP Entity Identifier
3.4. HHIT for DRIP Identifier Registration and Lookup
4. DRIP Identifier Registration and Registries
4.1. Public Information Registry
4.1.1. Background
4.1.2. Public DRIP Identifier Registry
4.2. Private Information Registry
4.2.1. Background
4.2.2. Information Elements
4.2.3. Private DRIP Identifier Registry Methods
4.2.4. Alternative Private DRIP Registry Methods
5. DRIP Identifier Trust
6. Harvesting Broadcast Remote ID Messages for UTM Inclusion
6.1. The CS-RID Finder
6.2. The CS-RID SDSP
7. DRIP Contact
8. IANA Considerations
9. Security Considerations
9.1. Private Key Physical Security
9.2. Quantum Resistant Cryptography
9.3. Denial-of-Service (DoS) Protection
9.4. Spoofing and Replay Protection
9.5. Timestamps and Time Sources
10. Privacy and Transparency Considerations
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Overview of UAS Traffic Management (UTM)
A.1. Operation Concept
A.2. UAS Service Supplier (USS)
A.3. UTM Use Cases for UAS Operations
Appendix B. Automatic Dependent Surveillance Broadcast (ADS-B)
Acknowledgments
Authors' Addresses
This document describes an architecture for protocols and services to support Unmanned Aircraft System Remote Identification and tracking (UAS RID), plus UAS-RID-related communications. The architecture takes into account both current (including proposed) regulations and non-IETF technical standards.
このドキュメントでは、無人の航空機システムのリモート識別と追跡（UAS RID）とUASリッド関連の通信をサポートするためのプロトコルとサービスのアーキテクチャについて説明します。アーキテクチャは、現在の（提案されている）規制と非ITF技術基準の両方を考慮に入れています。
The architecture adheres to the requirements listed in the DRIP Requirements document [RFC9153] and illustrates how all of them can be met, except for GEN-7 QoS, which is left for future work. The requirements document provides an extended introduction to the problem space and use cases. Further, this architecture document frames the DRIP Entity Tag (DET) [RFC9374] within the architecture.
アーキテクチャは、DRIP要件ドキュメント[RFC9153]にリストされている要件に準拠しており、Gen-7 Qosを除き、将来の作業のために残されていることを除いて、それらのすべてをどのように満たすことができるかを示しています。要件ドキュメントは、問題のスペースとユースケースの拡張紹介を提供します。さらに、このアーキテクチャドキュメントは、アーキテクチャ内のDRIPエンティティタグ（DET）[RFC9374]をフレーム化します。
UAS RID is an application that enables UAS to be identified by UAS Traffic Management (UTM), UAS Service Suppliers (USS) (Appendix A), and third-party entities, such as law enforcement. Many considerations (e.g., safety and security) dictate that UAS be remotely identifiable.
UAS RIDは、UASがUASトラフィック管理（UTM）、UASサービスサプライヤー（USS）（付録A）、および法執行機関などのサードパーティエンティティによって識別できるようにするアプリケーションです。多くの考慮事項（安全性とセキュリティなど）は、UASがリモートで識別可能であることを決定します。
Civil Aviation Authorities (CAAs) worldwide are mandating UAS RID. CAAs currently promulgate performance-based regulations that do not specify techniques but rather cite industry consensus technical standards as acceptable means of compliance.
世界中の民間航空当局（CAAS）はUAS Redを義務付けています。CAASは現在、手法を指定していないが、コンプライアンスの許容可能な手段として業界のコンセンサス技術基準を引用するパフォーマンスベースの規制を公布しています。
USA Federal Aviation Administration (FAA)
米国連邦航空局（FAA）
The FAA published a Notice of Proposed Rule Making [NPRM] in 2019 and thereafter published a "Final Rule" in 2021 [FAA_RID], imposing requirements on UAS manufacturers and operators, both commercial and recreational. The rule states that Automatic Dependent Surveillance Broadcast (ADS-B) Out and transponders cannot be used to satisfy the UAS RID requirements on UAS to which the rule applies (see Appendix B).
FAAは、2019年に提案された規則作成[NPRM]の通知を公開し、その後2021年[FAA_RID]に「最終規則」を公開し、商業およびレクリエーションの両方のUASメーカーとオペレーターに要件を課しました。このルールでは、自動依存監視放送（ADS-B）を撤回し、トランスポンダーを使用して、ルールが適用されるUASのUAS RID要件を満たすことはできないと述べています（付録Bを参照）。
European Union Aviation Safety Agency (EASA)
欧州連合航空安全局（EASA）
In pursuit of the "U-space" concept of a single European airspace safely shared by manned and unmanned aircraft, the EASA published a [Delegated] regulation in 2019, imposing requirements on UAS manufacturers and third-country operators, including but not limited to UAS RID requirements. The same year, the EASA also published a regulation [Implementing], laying down detailed rules and procedures for UAS operations and operating personnel, which then was updated in 2021 [Implementing_update]. A Notice of Proposed Amendment [NPA] was published in 2021 to provide more information about the development of acceptable means of compliance and guidance material to support U-space regulations.
EASAは、有人および無人の航空機が安全に共有する単一のヨーロッパ空域の「Uスペース」概念を追求して、2019年に[委任]規制を発表し、UASメーカーと第3カントリーオペレーターに要件を課しました。UAS RID要件。同じ年に、EASAは規則[実装]を発行し、UAS運用と運営担当者の詳細なルールと手順を敷設し、2021年に更新されました[実装_Update]。修正案[NPA]の通知は、Uスペース規制をサポートするための許容可能なコンプライアンスとガイダンス資料の開発に関する詳細情報を提供するために、2021年に公開されました。
American Society for Testing and Materials (ASTM)
アメリカの試験材料協会（ASTM）
ASTM International, Technical Committee F38 (UAS), Subcommittee F38.02 (Aircraft Operations), Work Item WK65041 developed an ASTM standard [F3411-22a], titled "Standard Specification for Remote ID and Tracking".
ASTM International、Technical Committee F38（UAS）、小委員会F38.02（航空機操作）、作業項目WK65041は、「リモートIDと追跡の標準仕様」というタイトルのASTM標準[F3411-22A]を開発しました。
ASTM defines one set of UAS RID information and two means, Media Access Control (MAC) layer broadcast and IP layer network, of communicating it. If a UAS uses both communication methods, the same information must be provided via both means. [F3411-22a] is the technical standard basis of the Means Of Compliance (MOC) specified in [F3586-22]. The FAA has accepted [F3586-22] as a MOC to the FAA's UAS RID Final Rule [FAA_RID], with some caveats, as per [MOC-NOA]. Other CAAs are expected to accept the same or other MOCs likewise based on [F3411-22a].
ASTMは、1つのUAS RID情報と2つの手段、メディアアクセスコントロール（MAC）レイヤーブロードキャストとIPレイヤーネットワークを通信する2つの手段を定義します。UASが両方の通信方法を使用する場合、同じ情報を両方の手段で提供する必要があります。[F3411-22A]は、[F3586-22]で指定されたコンプライアンス手段（MOC）の技術的基準です。FAAは[F3586-22]をFAAのUAS RID最終規則[FAA_RID]のMOCとして受け入れました。他のCAAは、[F3411-22A]に基づいて、同じまたは他のMOCを受け入れることが期待されています。
3rd Generation Partnership Project (3GPP)
第3世代パートナーシッププロジェクト（3GPP）
With Release 16, the 3GPP completed the UAS RID requirement study [TR-22.825] and proposed a set of use cases in the mobile network and services that can be offered based on UAS RID. The Release 17 study [TR-23.755] and specification [TS-23.255] focus on enhanced UAS service requirements and provide the protocol and application architecture support that will be applicable for both 4G and 5G networks. The study of Further Architecture Enhancement for Uncrewed Aerial Vehicles (UAV) and Urban Air Mobility (UAM) in Release 18 [FS_AEUA] further enhances the communication mechanism between UAS and USS/UTM. The DET in Section 3 may be used as the 3GPP CAA-level UAS ID for RID purposes.
リリース16で、3GPPはUAS Ride要件調査[TR-22.825]を完了し、モバイルネットワークとUAS RIDに基づいて提供できるサービスのセットを提案しました。リリース17の研究[TR-23.755]および仕様[TS-23.255]は、強化されたUASサービス要件に焦点を当て、4Gと5Gの両方のネットワークに適用できるプロトコルおよびアプリケーションアーキテクチャサポートを提供します。リリース18 [FS_AEUA]における、非難されていない空中車両（UAV）および都市空気移動度（UAM）のさらなる建築強化の研究は、UASとUSS/UTMの間の通信メカニズムをさらに強化します。セクション3のDETは、RIDの目的で3GPP CAAレベルのUAS IDとして使用できます。
This specification introduces two types of UAS Remote IDs as defined in ASTM [F3411-22a].
この仕様では、ASTM [F3411-22A]で定義されている2種類のUASリモートIDを導入します。
[F3411-22a] defines a set of UAS RID messages for direct, one-way broadcast transmissions from the Unmanned Aircraft (UA) over Bluetooth or Wi-Fi. These are currently defined as MAC layer messages. Internet (or other Wide Area Network) connectivity is only needed for UAS registry information lookup by Observers using the directly received UAS ID. Broadcast RID should be functionally usable in situations with no Internet connectivity.
[F3411-22a]は、BluetoothまたはWi-Fiを介した無人航空機（UA）からの直接的な一方向放送送信のUAS RIDメッセージのセットを定義します。これらは現在、MACレイヤーメッセージとして定義されています。インターネット（またはその他の広い領域ネットワーク）接続は、直接受信したUAS IDを使用したオブザーバーによるUASレジストリ情報検索にのみ必要です。ブロードキャストRIDは、インターネット接続のない状況で機能的に使用可能である必要があります。
The minimum Broadcast RID data flow is illustrated in Figure 1.
最小ブロードキャストRIDデータフローを図1に示します。
+------------------------+
| Unmanned Aircraft (UA) |
+-----------o------------+
|
| app messages directly over
| one-way RF data link (no IP)
|
v
+------------------o-------------------+
| Observer's device (e.g., smartphone) |
+--------------------------------------+
Figure 1: Minimum Broadcast RID Data Flow
図1：最小ブロードキャストRIDデータフロー
Broadcast RID provides information only about UA within direct Radio Frequency (RF) Line Of Sight (LOS), typically similar to Visual LOS (VLOS), with a range up to approximately 1 km. This information may be 'harvested' from received broadcasts and made available via the Internet, enabling surveillance of areas too large for local direct visual observation or direct RF link-based identification (see Section 6).
Broadcast RIDは、通常、Visual Los（VLOS）に似た直接無線周波数（RF）ライン（RF）内のUAに関する情報のみを提供し、最大約1 kmの範囲を提供します。この情報は、受信した放送から「収穫」され、インターネットを介して利用可能になる場合があり、地域の直接的な視覚観測または直接RFリンクベースの識別には大きすぎる地域の監視を可能にします（セクション6を参照）。
[F3411-22a], using the same data dictionary that is the basis of Broadcast RID messages, defines a Network Remote Identification (Net-RID) data flow as follows.
[F3411-22a]は、ブロードキャストRIDメッセージの基礎と同じデータ辞書を使用して、ネットワークリモート識別（ネットリッド）データフローを次のように定義します。
* The information to be reported via UAS RID is generated by the UAS. Typically, some of this data is generated by the UA and some by the Ground Control Station (GCS), e.g., their respective locations derived from the Global Navigation Satellite System (GNSS).
* UAS RIDを介して報告される情報は、UASによって生成されます。通常、このデータの一部は、UAによって生成され、一部はグローバルナビゲーション衛星システム（GNSS）から派生したそれぞれの場所など、地上制御ステーション（GCS）によって生成されます。
* The information is sent by the UAS (UA or GCS) via unspecified means to the cognizant Network Remote Identification Service Provider (Net-RID SP), typically the USS under which the UAS is operating if it is participating in UTM.
* この情報は、UAS（UAまたはGCS）によって、Cognizant Network Remote Identification Service Provider（Net-Rid SP）に不特定の手段を介して送信されます。これは、UTMに参加している場合にUASが動作しているUSSです。
* The Net-RID SP publishes, via the Discovery and Synchronization Service (DSS) over the Internet, that it has operations in various 4-D airspace volumes (Section 2.2 of [RFC9153]), describing the volumes but not the operations.
* Net-rid SPは、インターネット上のディスカバリーおよび同期サービス（DSS）を介して、さまざまな4D空域ボリューム（[RFC9153]のセクション2.2）で動作を展開し、ボリュームを記述しますが、操作ではないことを公開しています。
* An Observer's device, which is expected but not specified to be based on the Web, queries a Network Remote Identification Display Provider (Net-RID DP), typically also a USS, about any operations in a specific 4-D airspace volume.
* Webに基づいていることが予想されているが指定されていないオブザーバーのデバイスは、特定の4D空域ボリュームの操作に関するネットワークリモート識別表示プロバイダー（ネットリッドDP）、通常はUSSもクエリします。
* Using fully specified Web-based methods over the Internet, the Net-RID DP queries all Net-RID SPs that have operations in volumes intersecting that of the Observer's query for details on all such operations.
* 完全に指定されたWebベースのメソッドをインターネット上で使用して、ネットリッドDPは、すべてのそのような操作の詳細については、オブザーバーのクエリの操作と交差するボリュームの操作を備えたすべてのネットリッドSPSをクエリします。
* The Net-RID DP aggregates information received from all such Net-RID SPs and responds to the Observer's query.
* ネットリッドDPは、そのようなすべてのネットリッドSPから受信した情報を集約し、オブザーバーのクエリに応答します。
The minimum Net-RID data flow is illustrated in Figure 2:
最小限のネットリッドデータフローを図2に示します。
+-------------+ ******************
| UA | * Internet *
+--o-------o--+ * *
| | * * +------------+
| '--------*--(+)-----------*-----o |
| * | * | |
| .--------*--(+)-----------*-----o Net-RID SP |
| | * * | |
| | * .------*-----o |
| | * | * +------------+
| | * | *
| | * | * +------------+
| | * '------*-----o |
| | * * | Net-RID DP |
| | * .------*-----o |
| | * | * +------------+
| | * | *
| | * | * +------------+
+--o-------o--+ * '------*-----o Observer's |
| GCS | * * | Device |
+-------------+ ****************** +------------+
Figure 2: Minimum Net-RID Data Flow
図2：最小ネットリッドデータフロー
Command and Control (C2) must flow from the GCS to the UA via some path. Currently (in the year 2023), this is typically a direct RF link; however, with increasing Beyond Visual Line Of Sight (BVLOS) operations, it is expected to often be a wireless link at either end with the Internet between.
コマンドと制御（C2）は、あるパスを介してGCSからUAに流れる必要があります。現在（2023年）、これは通常、直接RFリンクです。ただし、視覚的な視線（BVLOS）の操作を超えて増加すると、インターネットとの両端でワイヤレスリンクになることがよくあります。
Telemetry (at least the UA's position and heading) flows from the UA to the GCS via some path, typically the reverse of the C2 path. Thus, UAS RID information pertaining to both the GCS and the UA can be sent by whichever has Internet connectivity to the Net-RID SP, typically the USS managing the UAS operation.
テレメトリー（少なくともUAの位置と見出し）は、あるパス、通常はC2パスの逆を介してUAからGCSに流れます。したがって、GCSとUAの両方に関連するUAS RID情報は、ネットリッドSPへのインターネット接続がある場合、通常はUAS操作を管理するUSSによって送信できます。
The Net-RID SP forwards UAS RID information via the Internet to subscribed Net-RID DPs, typically the USS. Subscribed Net-RID DPs then forward RID information via the Internet to subscribed Observer devices. Regulations require and [F3411-22a] describes UAS RID data elements that must be transported end to end from the UAS to the subscribed Observer devices.
Net-Rid SPは、インターネットを介してUAS RID情報を転送し、通常はUSSを購読します。ネットリッドDPSを購読し、インターネットを介して情報を転送したオブザーバーデバイスに転送しました。規制が必要であり、[F3411-22A]は、UASから端まで端まで導かれなければならないUAS RIDデータ要素をサブスクライブオブザーバーデバイスに説明します。
[F3411-22a] prescribes the protocols between the Net-RID SP, Net-RID DP, and DSS. It also prescribes data elements (in JSON) between the Observer and the Net-RID DP. DRIP could address standardization of secure protocols between the UA and the GCS (over direct wireless and Internet connection), between the UAS and the Net-RID SP, and/or between the Net-RID DP and Observer devices.
[F3411-22a]は、ネットリッドSP、ネットリッドDP、およびDSSの間のプロトコルを規定しています。また、オブザーバーとネットリッドDPの間にデータ要素（JSON）を規定しています。DRIPは、UAとGCS（直接ワイヤレスおよびインターネット接続を超えて）、UASとNet-RID SPの間、および/またはネットリッドDPとオブザーバーデバイス間の安全なプロトコルの標準化に対処できます。
_Neither link-layer protocols nor the use of links (e.g., the link often existing between the GCS and the UA) for any purpose other than carriage of UAS RID information are in the scope of Network RID [F3411-22a]._
_リンク層プロトコルやリンクの使用（たとえば、GCSとUAの間に存在するリンク）の使用は、UAS RID情報のキャリッジ以外の目的で、ネットワークRID [F3411-22A]の範囲内にあります。
With Net-RID, there is direct communication between each UAS and its USS. Multiple USS exchange information with the assistance of a DSS so all USS collectively have knowledge about all activities in a 4-D airspace. The interactions among an Observer, multiple UAS, and their USS are shown in Figure 3.
ネットリッドを使用すると、各UAとそのUSSの間に直接通信があります。複数のUSSがDSSの支援を受けて情報を交換するため、すべてのUSSが4D空域でのすべてのアクティビティに関する知識をまとめて持っています。オブザーバー、複数のUAS、およびそのUS間の相互作用を図3に示します。
+------+ +----------+ +------+
| UAS1 | | Observer | | UAS2 |
+---o--+ +-----o----+ +--o---+
| | |
******|*************|************|******
* | | | *
* | +---o--+ | *
* | .------o USS3 o------. | *
* | | +--o---+ | | *
* | | | | | *
* +-o--o-+ +--o--+ +-o--o-+ *
* | o----o DSS o-----o | *
* | USS1 | +-----+ | USS2 | *
* | o----------------o | *
* +------+ +------+ *
* *
* Internet *
****************************************
Figure 3: Interactions Between Observers, UAS, and USS
図3：オブザーバー、UAS、およびUSS間の相互作用
Figure 4 illustrates a global UAS RID usage scenario. Broadcast RID links are not shown, as they reach from any UA to any listening receiver in range and thus would obscure the intent of the figure. Figure 4 shows, as context, some entities and interfaces beyond the scope of DRIP (as currently (2023) chartered). Multiple UAS are shown, each with its own UA controlled by its own GCS, potentially using the same or different USS, with the UA potentially communicating directly with each other (V2V), especially for low-latency, safety-related purposes (DAA).
図4は、グローバルUAS RID使用法のシナリオを示しています。放送リッドリンクは、範囲のリスニングレシーバーに到達するため、図の意図を曖昧にするため、放送リンクは表示されません。図4は、コンテキストとして、ドリップの範囲を超えた一部のエンティティとインターフェイスを示しています（現在（2023）チャーターされています）。複数のUAが示されており、それぞれが独自のGCで制御され、潜在的に同じまたは異なるUSを使用し、UAは互いに直接通信する可能性があります（V2V）、特に低遅延、安全関連の目的（DAA）。
*************** ***************
* UAS1 * * UAS2 *
* * * *
* +--------+ * DAA/V2V * +--------+ *
* | UA o--*----------------------------------------*--o UA | *
* +--o--o--+ * * +--o--o--+ *
* | | * +------+ Lookups +------+ * | | *
* | | * | GPOD o------. .------o PSOD | * | | *
* | | * +------+ | | +------+ * | | *
* | | * | | * | | *
* C2 | | * V2I ************ V2I * | | C2 *
* | '-----*--------------* *--------------*-----' | *
* | * * * * | *
* | o====Net-RID===* *====Net-RID===o | *
* +--o--+ * * Internet * * +--o--+ *
* | GCS o-----*--------------* *--------------*-----o GCS | *
* +-----+ * Registration * * Registration * +-----+ *
* * (and UTM) * * (and UTM) * *
*************** ************ ***************
| | |
+----------+ | | | +----------+
| Public o---' | '---o Private |
| Registry | | | Registry |
+----------+ | +----------+
+--o--+
| DNS |
+-----+
DAA: Detect And Avoid
GPOD: General Public Observer Device
PSOD: Public Safety Observer Device
V2I: Vehicle-to-Infrastructure
V2V: Vehicle-to-Vehicle
Figure 4: Global UAS RID Usage Scenario
図4：グローバルUAS RID使用シナリオ
Informative note: See [RFC9153] for detailed definitions.
有益な注意：詳細な定義については、[RFC9153]を参照してください。
DRIP is meant to leverage existing Internet resources (standard protocols, services, infrastructures, and business models) to meet UAS RID and closely related needs. DRIP will specify how to apply IETF standards, complementing [F3411-22a] and other external standards, to satisfy UAS RID requirements.
DRIPは、既存のインターネットリソース（標準プロトコル、サービス、インフラストラクチャ、およびビジネスモデル）を活用して、UAS RIDおよび密接に関連するニーズを満たすことを目的としています。DRIPは、UAS RID要件を満たすために、[F3411-22A]およびその他の外部標準を補完するIETF標準を適用する方法を指定します。
This document outlines the DRIP architecture in the context of the UAS RID architecture. This includes closing the gaps between the CAAs' concepts of operations and [F3411-22a] as it relates to the use of Internet technologies and UA-direct RF communications. Issues include, but are not limited to:
このドキュメントは、UAS RIDアーキテクチャのコンテキストでの点滴アーキテクチャの概要を説明しています。これには、Internet TechnologiesとUA-Direct RF Communicationsの使用に関連するCAASの操作の概念と[F3411-22A]の間のギャップを閉じることが含まれます。問題には以下が含まれますが、これらに限定されません。
* the design of trustworthy remote identifiers required by GEN-1 (Section 3), especially but not exclusively for use as single-use session IDs,
* Gen-1（セクション3）が必要とする信頼できるリモート識別子の設計、特に使い捨てセッションIDとしてのみ使用するためではありません。
* mechanisms to leverage the Domain Name System (DNS) [RFC1034] for registering and publishing public and private information (see Sections 4.1 and 4.2), as required by REG-1 and REG-2,
* reg-1およびreg-2で要求されるように、公開情報を登録および公開するために、ドメイン名システム（DNS）[RFC1034]を活用するメカニズム
* specific authentication methods and message payload formats to enable verification that Broadcast RID messages were sent by the claimed sender (Section 5) and that the sender is in the claimed DRIP Identity Management Entity (DIME) (see Sections 4 and 5), as required by GEN-2,
* 具体的な認証方法とメッセージペイロード形式は、請求された送信者によってブロードキャストRIDメッセージが送信され、送信者が請求されたDRIP ID管理エンティティ（DIME）にあることを有効にすることを可能にします（セクション4および5を参照）。Gen-2、
* harvesting Broadcast RID messages for UTM inclusion, with the optional DRIP extension of Crowdsourced Remote ID (CS-RID) (Section 6), using the DRIP support for gateways required by GEN-5 [RFC9153],
* Gen-5 [RFC9153]が必要とするゲートウェイのドリップサポートを使用して、クラウドソーシングリモートID（CS-RID）のオプションのドリップ拡張（CS-RID）（セクション6）を使用して、UTMインクルージョン用の放送RIDメッセージを収穫します。
* methods for instantly establishing secure communications between an Observer and the pilot of an observed UAS (Section 7), using the DRIP support for dynamic contact required by GEN-4 [RFC9153], and
* 観察者と観測されたUASのパイロットとの間の安全な通信を即座に確立する方法（セクション7）、Gen-4 [RFC9153]で必要な動的接触のためのDRIPサポートを使用し、
* privacy in UAS RID messages (personal data protection) (Section 10).
* UAS RIDメッセージのプライバシー（個人データ保護）（セクション10）。
This document should serve as a main point of entry into the set of IETF documents addressing the basic DRIP requirements.
このドキュメントは、基本的な点滴要件に対処するIETFドキュメントのセットへのエントリの主なポイントとして機能する必要があります。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
To encourage comprehension necessary for adoption of DRIP by the intended user community, the UAS community's norms are respected herein.
意図したユーザーコミュニティによるDRIPの採用に必要な理解を奨励するために、UASコミュニティの規範はここで尊重されます。
This document uses terms defined in [RFC9153].
このドキュメントでは、[RFC9153]で定義された用語を使用します。
Some of the acronyms have plural forms that remain the same as their singular forms, e.g., "UAS" can expand to "Unmanned Aircraft System" (singular) or "Unmanned Aircraft Systems" (plural), as appropriate for the context. This usage is consistent with Section 2.2 of [RFC9153].
いくつかの頭字語には、単数形と同じままである複数形があります。たとえば、「UAS」は、文脈に適しているように、「無人航空機システム」（単数形）または「無人航空機システム」（複数）に拡張できます。この使用法は、[RFC9153]のセクション2.2と一致しています。
DET:
DET：
DRIP Entity Tag
ドリップエンティティタグ
EdDSA:
eddsa：
Edwards-curve Digital Signature Algorithm
Edwards-Curve Digital Signature Algorithm
HHIT:
HHIT：
Hierarchical HIT
階層的ヒット
HI:
こんにちは：
Host Identity
ホストのアイデンティティ
HIP:
ヒップ：
Host Identity Protocol
ホストIDプロトコル
HIT:
打つ：
Host Identity Tag
ホストIDタグ
This section introduces the terms "Claim", "Evidence", "Endorsement", and "Certificate", as used in DRIP. A DRIP certificate has a different context compared with security certificates and Public Key Infrastructure used in X.509.
このセクションでは、DRIPで使用される「クレーム」、「証拠」、「承認」、および「証明書」という用語を紹介します。DRIP証明書は、X.509で使用されているセキュリティ証明書や公開キーインフラストラクチャと比較して異なるコンテキストを持っています。
Claim:
請求：
A claim shares the same definition as a claim in Remote ATtestation procedureS (RATS) [RFC9334]; it is a piece of asserted information, sometimes in the form of a name/value pair. It could also been seen as a predicate (e.g., "X is Y", "X has property Y", and most importantly "X owns Y" or "X is owned by Y").
クレームは、リモート証明手順（RAT）[RFC9334]の主張と同じ定義を共有します。それは、時には名前/値のペアの形で、主張された情報です。また、述語と見なされる可能性があります（たとえば、「xはy」、「xはプロパティy」、最も重要なことは「xはyを所有」、「xはyが所有しています」）。
Evidence:
証拠：
Evidence in DRIP borrows the same definition as in RATS [RFC9334], that is, a set of claims.
点滴の証拠は、ラット[RFC9334]、つまり一連のクレームと同じ定義を借りています。
Endorsement:
承認：
An Endorsement is inspired from RATS [RFC9334]; it is a secure (i.e., signed) statement vouching the integrity and veracity of evidence.
承認はラット[RFC9334]からインスピレーションを受けています。これは、証拠の完全性と真実性を保証する安全な（すなわち、署名された）声明です。
Certificate:
証明書：
A certificate in DRIP is an endorsement, strictly over identity information, signed by a third party. This third party should be one with no stake in the endorsement over which it is signing.
DRIPの証明書は、第三者によって署名された、Strictly over Identity情報を承認する承認です。この第三者は、署名している承認に利害関係がないものでなければなりません。
DRIP Identity Management Entity (DIME):
ドリップアイデンティティ管理エンティティ（DIME）：
A DIME is an entity that performs functions similar to a domain registrar/registry. A DIME vets Claims and/or Evidence from a registrant and delivers back Endorsements and/or Certificates in response. It is a high-level entity in the DRIP registration/ provisioning process that can hold the role of HHIT Domain Authority (HDA), Registered Assigning Authority (RAA), or root of trust (typically the HHIT prefix owner or DNS apex owner) for DETs.
DIMEは、ドメインレジストラ/レジストリと同様の関数を実行するエンティティです。Dime Vetsは、登録者からの主張および/または証拠を請求し、それに応じて支持および/または証明書を返済します。これは、HHITドメイン局（HDA）、登録機関（RAA）、または信頼のルート（通常はHHITプレフィックス所有者またはDNS Apex所有者）の役割を保持できるDRIP登録/プロビジョニングプロセスの高レベルエンティティです。dets。
This section describes the DRIP architectural approach to meeting the basic requirements of a DRIP entity identifier within the external technical standard ASTM [F3411-22a] and regulatory constraints. It justifies and explains the use of Hierarchical Host Identity Tags (HHITs) [RFC9374] as self-asserting IPv6 addresses suitable as a UAS ID type and, more generally, as trustworthy multipurpose remote identifiers.
このセクションでは、外部技術標準ASTM [F3411-22A]内のDRIPエンティティ識別子の基本要件を満たすための点滴アーキテクチャアプローチについて説明します。階層ホストIDタグ（HHITS）[RFC9374]の使用を正当化し、説明し、自己挿入IPv6はUAS IDタイプとして適切であり、より一般的には信頼できる多目的リモート識別子として適切です。
Self-asserting in this usage means that, given the Host Identity (HI), the HHIT Overlay Routable Cryptographic Hash IDentifier (ORCHID) construction (see Section 3.5 of [RFC9374]), and a signature of the DIME on the HHIT and HI, the HHIT can be verified by the receiver as a trusted UAS ID. The explicit registration hierarchy within the HHIT provides registration discovery (managed by a DIME) to either yield the HI for third-party (seeking UAS ID endorsement) validation or prove that the HHIT and HI have been registered uniquely.
この使用法における自己挿入とは、ホストのアイデンティティ（HI）を考えると、HHITオーバーレイルーティング可能な暗号ハッシュ識別子（蘭）構造（[RFC9374]のセクション3.5を参照）、およびHHITとHIのDIMEの署名を意味します。HHITは、受信者によって信頼できるUAS IDとして検証できます。HHIT内の明示的な登録階層は、登録発見（DIMEで管理）を提供して、サードパーティ（UAS ID承認を求めている）検証のHIを生成するか、HHITとHIが一意に登録されていることを証明します。
A DRIP entity identifier needs to be "Trustworthy" (see DRIP requirements GEN-1, ID-4, and ID-5 in [RFC9153]). This means that given a sufficient collection of UAS RID messages, an Observer can establish that the identifier claimed therein uniquely belongs to the claimant. To satisfy DRIP requirements and maintain important security properties, the DRIP identifier should be self-generated by the entity it names (e.g., a UAS) and registered (e.g., with a USS; see DRIP requirements GEN-3 and ID-2).
DRIPエンティティ識別子は「信頼できる」必要があります（[RFC9153]のDRIP要件GEN-1、ID-4、およびID-5を参照）。これは、UAS RIDメッセージの十分なコレクションを考えると、オブザーバーが識別子が請求者に属していることを確立できることを意味します。点滴要件を満たし、重要なセキュリティプロパティを維持するために、点滴識別子は、名前（例えば、UAS）と登録されているエンティティによって自己生成される必要があります（例えば、USSを使用します。DRIP要件Gen-3およびID-2を参照）。
However, Broadcast RID, especially its support for Bluetooth 4, imposes severe constraints. A previous revision of the ASTM UAS RID, [F3411-19], allowed a UAS ID of types (1, 2, and 3), each of 20 bytes. [F3411-22a] adds type 4, Specific Session ID, for other Standards Development Organizations (SDOs) to extend ASTM UAS RID. Type 4 uses one byte to index the Specific Session ID subtype, leaving 19 bytes (see ID-1 of DRIP Requirements [RFC9153]). As described in Section 3 of [RFC9153], ASTM has allocated Specific Session ID subtype 1 to IETF DRIP.
ただし、Broadcast RID、特にBluetooth 4のサポートは、深刻な制約を課しています。ASTM UAS RID [F3411-19]の以前の改訂により、それぞれ20バイトのタイプ（1、2、および3のUAS IDが許可されました。[F3411-22A]他の標準開発組織（SDO）のタイプ4、特定のセッションIDを追加して、ASTM UAS RIDを拡張します。タイプ4では、1バイトを使用して特定のセッションIDサブタイプにインデックスを付け、19バイトを残します（DRIP要件のID-1を参照[RFC9153]を参照）。[RFC9153]のセクション3で説明されているように、ASTMは特定のセッションIDサブタイプ1をIETF DRIPに割り当てました。
The maximum ASTM UAS RID Authentication Message payload is 201 bytes each for Authentication Types 1, 2, 3, and 4. [F3411-22a] adds Authentication Type 5 for other SDOs (including the IETF) to extend ASTM UAS RID with Specific Authentication Methods (SAMs). With Type 5, one of the 201 bytes is consumed to index the SAM Type, leaving only 200 bytes for DRIP authentication payloads, including one or more DRIP entity identifiers and associated authentication data.
最大ASTM UAS RID認証メッセージペイロードは、認証タイプ1、2、3、および4の場合、それぞれ201バイトです。（SAMS）。タイプ5では、SAMタイプのインデックスを作成するために201バイトの1つが消費され、1つ以上のDRIPエンティティ識別子と関連する認証データを含む、ドリップ認証ペイロードに200バイトしか残りません。
The only (known to the authors at the time of writing) existing types of IP-address-compatible identifiers cryptographically derived from the public keys of the identified entities are Cryptographically Generated Addresses (CGAs) [RFC3972] and Host Identity Tags (HITs) [RFC7401]. CGAs and HITs lack registration/retrieval capability. To provide this, each HHIT embeds plaintext information designating the hierarchy within which it is registered, a cryptographic hash of that information concatenated with the entity's public key, etc. Although hash collisions may occur, the DIME can detect them and reject registration requests rather than issue credentials, e.g., by enforcing a First Come First Served policy [RFC8126]. Preimage hash attacks are also mitigated through this registration process, locking the HHIT to a specific HI.
識別されたエンティティのパブリックキーから暗号化された既存のタイプのIPアドレス互換識別子の唯一の唯一のタイプのIPアドレス互換識別子は、暗号化されたアドレス（CGA）[RFC3972]およびホストアイデンティティタグ（HITS）[HOST ID [HITS] [RFC7401]。CGAとヒットには、登録/検索機能がありません。これを提供するために、各HHITは、登録されている階層を指定するプレーンテキスト情報、エンティティの公開キーなどと同時にその情報の暗号化ハッシュなどを埋め込みます。ハッシュの衝突が発生する可能性がありますが、DIMEはそれらを検出し、登録要求を拒否できます。たとえば、最初に提供される最初に提供されるポリシーを実施することにより、資格情報を発行します[RFC8126]。この登録プロセスを通じて、ハッシュ攻撃のプリイメージも軽減され、HHITを特定のHIにロックします。
A Remote UAS ID that can be trustworthy for use in Broadcast RID can be built from an asymmetric key pair. In this method, the UAS ID is cryptographically derived directly from the public key. The proof of UAS ID ownership (verifiable endorsement versus mere claim) is guaranteed by signing this cryptographic UAS ID with the associated private key. The association between the UAS ID and the private key is ensured by cryptographically binding the public key with the UAS ID; more specifically, the UAS ID results from the hash of the public key. The public key is designated as the HI, while the UAS ID is designated as the HIT.
ブロードキャストRIDで使用するために信頼できるリモートUAS IDは、非対称キーペアから構築できます。この方法では、UAS IDは公開鍵から直接暗号化されています。UAS IDの所有権の証明（検証可能な承認と単なる請求）は、この暗号化UAS IDに関連する秘密鍵に署名することにより保証されます。UAS IDと秘密鍵との関連は、公開鍵をUAS IDと暗号化することにより保証されます。より具体的には、UAS IDは公開キーのハッシュに起因します。公開キーはHIとして指定され、UAS IDはヒットとして指定されます。
By construction, the HIT is statistically unique through the mandatory use of cryptographic hash functions with second-preimage resistance. The cryptographically bound addition of the hierarchy and a HHIT registration process provide complete, global HHIT uniqueness. This registration forces the attacker to generate the same public key rather than a public key that generates the same HHIT. This is in contrast to general IDs (e.g., a Universally Unique Identifier (UUID) or device serial number) as the subject in an X.509 certificate.
構造により、ヒットは、2番目のプリメージ抵抗を備えた暗号化ハッシュ関数の必須使用を通じて統計的に一意になります。階層の暗号化に結合された追加とHHIT登録プロセスは、完全なグローバルなHHITユニーク性を提供します。この登録により、攻撃者は同じHHITを生成する公開キーではなく、同じ公開キーを生成するように強制されます。これは、X.509証明書の被験者としての一般的なID（普遍的に一意の識別子（UUID）またはデバイスのシリアル番号）とは対照的です。
A UA equipped for Broadcast RID MUST be provisioned not only with its HHIT but also with the HI public key from which the HHIT was derived and the corresponding private key to enable message signature.
放送用のUAは、そのHHITだけでなく、HHITが派生したHI公開鍵と、メッセージ署名を有効にするための対応する秘密鍵でもプロビジョニングする必要があります。
A UAS equipped for DRIP-enhanced Network RID MUST be provisioned likewise; the private key resides only in the ultimate source of Network RID messages. If the GCS is the source of the Network RID messages, the GCS MUST hold the private key. If the UA is the source of the Network RID messages and they are being relayed by the GCS, the UA MUST hold the private key, just as a UA that directly connects to the network rather than through its GCS.
DRIP強化ネットワークRIDに装備されたUASも同様にプロビジョニングする必要があります。秘密鍵は、ネットワークRIDメッセージの究極のソースにのみ存在します。GCSがネットワークRIDメッセージのソースである場合、GCSは秘密鍵を保持する必要があります。UAがネットワークRIDメッセージのソースであり、GCSによって中継されている場合、UAはGCSではなくネットワークに直接接続するUAとして、秘密鍵を保持する必要があります。
Each Observer device functioning with Internet connectivity MAY be provisioned either with public keys of the DRIP identifier root registries or certificates for subordinate registries; each Observer device that needs to operate without Internet connectivity at any time MUST be so provisioned.
インターネット接続で機能する各オブザーバーデバイスには、DRIP識別子ルートレジストリの公開キーまたは下位レジストリの証明書のいずれかをプロビジョニングできます。いつでもインターネット接続なしで動作する必要がある各オブザーバーデバイスは、そのようにプロビジョニングする必要があります。
HHITs can also be used throughout the USS/UTM system. Operators and Private Information Registries, as well as other UTM entities, can use HHITs for their IDs. Such HHITs can facilitate DRIP security functions, such as those used with HIP, to strongly mutually authenticate and encrypt communications.
HHITは、USS/UTMシステム全体で使用できます。オペレーターと個人情報登録、および他のUTMエンティティは、IDにHHITを使用できます。このようなHHITは、股関節とともに使用されているようなドリップセキュリティ機能を促進し、通信を強く認証して暗号化することができます。
A self-endorsement of a HHIT used as a UAS ID can be done in as little as 88 bytes when Ed25519 [RFC8032] is used by only including the 16-byte HHIT, two 4-byte timestamps, and the 64-byte Ed25519 signature.
UAS IDとして使用されるHHITの自己募集は、ED25519 [RFC8032]が16バイトのHHIT、2つの4バイトタイムスタンプ、64バイトのED25519署名を含むだけで、わずか88バイトで使用できます。。
Ed25519 [RFC8032] is used as the HHIT mandatory-to-implement signing algorithm, as GEN-1 and ID-5 [RFC9153] can best be met by restricting the HI to 32 bytes. A larger public key would rule out the offline endorsement feature that fits within the 200-byte Authentication Message maximum length. Other algorithms that meet this 32-byte constraint can be added as deemed needed.
ED25519 [RFC8032]は、Gen-1およびID-5 [RFC9153]が32バイトに制限することで最適に満たすことができるため、HHITの必須の実装署名アルゴリズムとして使用されます。より大きな公開キーは、200バイトの認証メッセージの最大長に適合するオフライン承認機能を除外します。この32バイトの制約を満たす他のアルゴリズムは、必要と思われるように追加できます。
A DRIP identifier can be assigned to a UAS as a static HHIT by its manufacturer, such as a single HI and derived HHIT encoded as a hardware serial number, per [CTA2063A]. Such a static HHIT SHOULD only be used to bind one-time-use DRIP identifiers to the unique UA. Depending upon implementation, this may leave a HI private key in the possession of the manufacturer (see also Section 9).
[CTA2063A]に従って、単一のHIおよびハードウェアシリアル番号としてエンコードされた単一のHIや派生HHITなど、製造業者が静的HHITとしてUASにドリップ識別子を割り当てることができます。このような静的HHITは、一度限りのUAに1回使用したドリップ識別子をバインドするためにのみ使用する必要があります。実装に応じて、これにより、製造業者が所有するHI秘密鍵が残る場合があります（セクション9も参照）。
In general, Internet access may be needed to validate Endorsements or Certificates. This may be obviated in the most common cases (e.g., endorsement of the UAS ID), even in disconnected environments, by prepopulating small caches on Observer devices with DIME public keys and a chain of Endorsements or Certificates (tracing a path through the DIME tree). This is assuming all parties on the trust path also use HHITs for their identities.
一般に、承認または証明書を検証するには、インターネットアクセスが必要になる場合があります。これは、DIMEパブリックキーと承認または証明書のチェーンを備えたオブザーバーデバイスの小さなキャッシュを前払いすることにより、最も一般的なケース（UAS IDの承認など）では、切断された環境でも回している可能性があります（ダイムツリーを通るパスを通過する）。これは、トラストパス上のすべての当事者がIDにHHITを使用することを前提としています。
UAS RID needs a deterministic lookup mechanism that rapidly provides actionable information about the identified UA. Given the size constraints imposed by the Bluetooth 4 broadcast media, the UAS ID itself needs to be a non-spoofable inquiry input into the lookup.
UAS RIDには、特定されたUAに関する実用的な情報を迅速に提供する決定論的ルックアップメカニズムが必要です。Bluetooth 4ブロードキャストメディアによって課されたサイズの制約を考えると、UAS ID自体はルックアップへのスプーフィング不可能な照会入力である必要があります。
A DRIP registration process based on the explicit hierarchy within a HHIT provides manageable uniqueness of the HI for the HHIT. The hierarchy is defined in [RFC9374] and consists of 2 levels: an RAA and then an HDA. The registration within this hierarchy is the defense against a cryptographic hash second-preimage attack on the HHIT (e.g., multiple HIs yielding the same HHIT; see Requirement ID-3 in [RFC9153]). The First Come First Served registration policy is adequate.
HHIT内の明示的な階層に基づいた点滴登録プロセスは、HHITのHIの管理可能な独自性を提供します。階層は[RFC9374]で定義されており、2つのレベルで構成されています：RAA、次にHDA。この階層内の登録は、HHITに対する暗号化のハッシュ2番目のプリメージ攻撃に対する防御です（たとえば、彼の複数のHHITを生成します。[RFC9153]の要件ID-3を参照）。最初に提供される最初の登録ポリシーは適切です。
A lookup of the HHIT into the DIME provides the registered HI for HHIT proof of ownership and deterministic access to any other needed actionable information based on inquiry access authority (more details in Section 4.2).
ダイムへのHHITの検索は、照会アクセス権限に基づいて、その他の必要な実用的な情報へのHHIT証明と決定論的アクセスのために登録されたHIを提供します（詳細については、セクション4.2の詳細）。
DRIP registries hold both public and private UAS information (see PRIV-1 in [RFC9153]) resulting from the DRIP identifier registration process. Given these different uses, and to improve scalability, security, and simplicity of administration, the public and private information can be stored in different registries. This section introduces the public and private information registries for DRIP identifiers. In this section, for ease of comprehension, the registry functions are described (using familiar terminology) without detailing their assignment to specific implementing entities (or using unfamiliar jargon). Elsewhere in this document, and in forthcoming documents detailing the DRIP registration processes and entities, the more specific term "DRIP Identity Management Entity" (DIME) will be used. This DRIP identifier registration process satisfies the following DRIP requirements defined in [RFC9153]: GEN-3, GEN-4, ID-2, ID-4, ID-6, PRIV-3, PRIV-4, REG-1, REG-2, REG-3, and REG-4.
ドリップレジストリは、Public and Private UAS情報の両方を保持しています（[RFC9153]のPRIC-1を参照）。これらのさまざまな用途を考えると、管理のスケーラビリティ、セキュリティ、および管理の単純さを改善するために、公開情報と個人情報はさまざまなレジストリに保存できます。このセクションでは、ドリップ識別子の公開および個人情報登録を紹介します。このセクションでは、理解を容易にするために、特定の実装エンティティへの割り当て（またはなじみのない専門用語を使用する）を詳細にすることなく、レジストリ機能について説明します（おなじみの用語を使用します）。このドキュメントの他の場所、および点滴登録プロセスとエンティティを詳述する今後のドキュメントでは、より具体的な用語「DRIP ID管理エンティティ」（DIME）が使用されます。このDRIP識別子登録プロセスは、[RFC9153]で定義されている次の点滴要件を満たしています：Gen-3、Gen-4、ID-2、ID-4、ID-6、PRIV-3、PRIV-4、REG-1、REG-2、reg-3、およびreg-4。
The public information registry provides trustable information, such as endorsements of UAS RID ownership and registration with the HDA. Optionally, pointers to the registries for the HDA and RAA implicit in the UAS RID can be included (e.g., for HDA and RAA HHIT|HI used in endorsement signing operations). This public information will be principally used by Observers of Broadcast RID messages. Data on UAS that only use Network RID is available via an Observer's Net-RID DP that would directly provide all public registry information. The Net-RID DP is the only source of information for a query on an airspace volume.
Public Information Registryは、UASの承認やHDAへの登録などの信頼できる情報を提供します。オプションで、UAS RIDに暗示されるHDAおよびRAAのレジストリへのポインターを含めることができます（たとえば、HDAおよびRAA HHIT | HIの承認署名操作で使用）。この公開情報は、主にブロードキャストRIDメッセージのオブザーバーによって使用されます。ネットワークRIDのみを使用するUASのデータは、すべてのパブリックレジストリ情報を直接提供するオブザーバーのネットリッドDPを介して利用可能です。ネットリッドDPは、空域のボリュームのクエリの唯一の情報源です。
Note: In the above paragraph, | signifies concatenation of information, e.g., X | Y is the concatenation of X and Y.
注：上記の段落では、|情報の連結、例えばx |yはxとyの連結です。
A DRIP identifier MUST be registered as an Internet domain name (at an arbitrary level in the hierarchy, e.g., in .ip6.arpa). Thus, the DNS can provide all the needed public DRIP information. A standardized HHIT Fully Qualified Domain Name (FQDN) can deliver the HI via a HIP Resource Record (RR) [RFC8005] and other public information (e.g., RAA and HDA PTRs and HIP Rendezvous Servers (RVSs) [RFC8004]). These public information registries can use DNSSEC to deliver public information that is not inherently trustable (e.g., everything other than endorsements).
点滴識別子は、インターネットドメイン名として登録する必要があります（階層の任意のレベルで、例えば、.ip6.arpa）。したがって、DNSは必要なすべての公開情報を提供できます。標準化されたHHIT完全資格のドメイン名（FQDN）は、股関節リソースレコード（RR）[RFC8005]およびその他の公開情報（RAAおよびHDA PTRSおよびHIP Rendezvousサーバー（RVSS）[RFC8004]）を介してHIを配信できます。これらの公開情報レジストリは、DNSSECを使用して、本質的に信頼できない公開情報（たとえば、承認以外）を提供できます。
This DNS entry for the HHIT can also provide a revocation service. For example, instead of returning the HI RR, it may return some record showing that the HI (and thus HHIT) has been revoked.
HHITのこのDNSエントリは、取り消しサービスを提供することもできます。たとえば、HI RRを返す代わりに、HI（したがってHHIT）が取り消されたことを示す記録を返す可能性があります。
The private information required for DRIP identifiers is similar to that required for Internet domain name registration. A DRIP identifier solution can leverage existing Internet resources, i.e., registration protocols, infrastructure, and business models, by fitting into a UAS ID structure compatible with DNS names. The HHIT hierarchy can provide the needed scalability and management structure. It is expected that the private information registry function will be provided by the same organizations that run a USS and likely integrated with a USS. The lookup function may be implemented by the Net-RID DPs.
点滴識別子に必要な個人情報は、インターネットドメイン名登録に必要なものと同様です。DRIP識別子ソリューションは、DNS名と互換性のあるUAS ID構造に適合することにより、既存のインターネットリソース、つまり登録プロトコル、インフラストラクチャ、およびビジネスモデルを活用できます。HHIT階層は、必要なスケーラビリティと管理構造を提供できます。個人情報レジストリ機能は、USSを実行し、USSと統合される可能性が高いのと同じ組織によって提供されると予想されます。ルックアップ関数は、ネットリッドDPSによって実装される場合があります。
When a DET is used as a UA's Session ID, the corresponding manufacturer-assigned serial number MUST be stored in a private information registry that can be identified uniquely from the DET. When a DET is used as either a UA's Session ID or a UA's manufacturer-assigned serial number, and the operation is being flown under UTM, the corresponding UTM-system-assigned Operational Intent Identifier SHOULD be so stored. Other information MAY be stored as such, and often must, to satisfy CAA regulations or USS operator policies.
DETがUAのセッションIDとして使用される場合、対応するメーカーが割り当てるシリアル番号は、DETから一意に識別できる個人情報レジストリに保存する必要があります。DETがUAのセッションIDまたはUAのメーカーが割り当てられたシリアル番号のいずれかとして使用され、操作がUTMの下で飛行されている場合、対応するUTM-Systemが割り当てられた運用意図識別子をそのように保存する必要があります。他の情報は、CAA規制またはUSSオペレーターポリシーを満たすために、そのように保存される場合があります。
A DRIP private information registry supports essential registry operations (e.g., add, delete, update, and query) using interoperable open standard protocols. It can accomplish this by leveraging aspects of the Extensible Provisioning Protocol (EPP) [RFC5730] and the Registry Data Access Protocol (RDAP) [RFC7480] [RFC9082] [RFC9083]. The DRIP private information registry in which a given UAS is registered needs to be findable, starting from the UAS ID, using the methods specified in [RFC9224].
DRIPの個人情報レジストリは、相互運用可能なオープン標準プロトコルを使用して、重要なレジストリ操作（たとえば、追加、削除、更新、クエリ）をサポートします。これは、拡張可能なプロビジョニングプロトコル（EPP）[RFC5730]およびレジストリデータアクセスプロトコル（RDAP）[RFC7480] [RFC9082] [RFC9083]の側面を活用することでこれを達成できます。[RFC9224]で指定された方法を使用して、特定のUASが登録されているDRIP個人情報レジストリは、UAS IDから開始する必要があります。
A DRIP private information registry might be an access-controlled DNS (e.g., via DNS over TLS). Additionally, WebFinger [RFC7033] can be supported. These alternative methods may be used by a Net-RID DP with specific customers.
DRIPの個人情報レジストリは、アクセス制御DNS（たとえば、TLSを超えるDNSを介して）である場合があります。さらに、WebFinger [RFC7033]をサポートできます。これらの代替方法は、特定の顧客を持つネットリッドDPによって使用される場合があります。
While the DRIP entity identifier is self-asserting, it alone does not provide the trustworthiness (i.e., non-repudiation, protection vs. spoofing, message integrity protection, scalability, etc.) essential to UAS RID, as justified in [RFC9153]. For that, it MUST be registered (under DRIP registries) and actively used by the party (in most cases the UA). A sender's identity cannot be proved merely by its possessing of a DRIP Entity Tag (DET) and broadcasting it as a claim that it belongs to that sender. Sending data signed using that HI's private key proves little, as it is subject to trivial replay attacks using previously broadcast messages. Only sending the DET and a signature on novel (i.e., frequently changing and unpredictable) data that can be externally validated by the Observer (such as a signed Location/Vector message that matches actually seeing the UA at the location and time reported in the signed message) proves that the observed UA possesses the private key and thus the claimed UAS ID.
DRIPエンティティ識別子は自己挿入ですが、それだけでは信頼性（つまり、非和解、保護対スプーフィング、メッセージの整合性保護、スケーラビリティなど）は、[RFC9153]に正当化されます。そのためには、（ドリップレジストリの下）登録し、パーティー（ほとんどの場合UA）が積極的に使用する必要があります。送信者の身元は、ドリップエンティティタグ（det）を所有し、それがその送信者に属するという主張として放送するだけでは証明することはできません。Hiの秘密鍵を使用して署名されたデータを送信しても、以前にブロードキャストされたメッセージを使用して些細なリプレイ攻撃の対象となるため、ほとんど証明されていません。DETと署名を、オブザーバーが外部的に検証できる小説（つまり、頻繁に変更して予測不可能な）データのみ（署名された場所と時間で実際にUAを見ることができる署名済みの場所/ベクターメッセージなど、メッセージ）観測されたUAが秘密鍵を所有していることを証明し、したがって請求されたUAS ID。
The severe constraints of Broadcast RID make it challenging to satisfy UAS RID requirements. From received Broadcast RID messages and information that can be looked up using the received UAS ID in online registries or local caches, it is possible to establish levels of trust in the asserted information and the operator.
Broadcast RIDの厳しい制約により、UAS RID要件を満たすことは困難です。オンラインレジストリまたはローカルキャッシュで受信したUAS IDを使用して検索できるブロードキャストRIDメッセージと情報から、主張された情報とオペレーターに対する信頼レベルを確立することができます。
A combination of different DRIP Authentication Messages enables an Observer, without Internet connection (offline) or with (online), to validate a UAS DRIP ID in real time. Some messages must contain the relevant registration of the UA's DRIP ID in the claimed DIME. Some messages must contain sender signatures over both static (e.g., registration) and dynamically changing (e.g., current UA location) data. Combining these two sets of information, an Observer can piece together a chain of trust, including real-time evidence to make a determination on the UA's claims.
異なる点滴認証メッセージの組み合わせにより、インターネット接続（オフライン）または（オンライン）を使用しないオブザーバーを、UASの点滴IDをリアルタイムで検証できます。一部のメッセージには、請求されたダイムにUAのドリップIDの関連する登録が含まれている必要があります。一部のメッセージには、静的（登録など）と動的に変化する（現在のUAロケーションなど）データの両方を介して送信者署名を含める必要があります。これらの2つの情報セットを組み合わせることで、オブザーバーは、UAの主張を決定するためのリアルタイムの証拠を含む、信頼の連鎖をつなぐことができます。
This process (combining the DRIP entity identifier, registries, and authentication formats for Broadcast RID) can satisfy the following DRIP requirements defined in [RFC9153]: GEN-1, GEN-2, GEN-3, ID-2, ID-3, ID-4, and ID-5.
このプロセス（DRIPエンティティ識別子、レジストリ、およびブロードキャストRIDの認証形式を組み合わせて）は、[RFC9153]で定義されている次のDRIP要件を満たすことができます：Gen-1、Gen-2、Gen-3、Id-2、ID-3、ID-4、およびID-5。
ASTM anticipated that regulators would require both Broadcast RID and Network RID for large UAS but allow UAS RID requirements for small UAS to be satisfied with the operator's choice of either Broadcast RID or Network RID. The EASA initially specified Broadcast RID for essentially all UAS and is now also considering Network RID. The FAA UAS RID Final Rules [FAA_RID] permit only Broadcast RID for rule compliance but still encourage Network RID for complementary functionality, especially in support of UTM.
ASTMは、規制当局が大型UASのブロードキャストRIDとネットワークRIDの両方を必要とするが、小規模UASのUAS RID要件が、オペレーターがブロードキャストRIDまたはネットワークRIDのいずれかの選択に満足できるようにすることを予想しました。EASAは当初、本質的にすべてのUASに対して放送を指定し、現在はネットワークRIDを検討しています。FAA UAS RID Final Rules [FAA_RID]は、ルールコンプライアンスのために放送のみを放送することを許可しますが、特にUTMをサポートするために、補完的な機能のネットワークRIDを奨励しています。
One opportunity is to enhance the architecture with gateways from Broadcast RID to Network RID. This provides the best of both and gives regulators and operators flexibility. It offers advantages over either form of UAS RID alone, i.e., greater fidelity than Network RID reporting of [FAA_RID] planned area operations, together with surveillance of areas too large for local direct visual observation and direct Radio Frequency Line Of Sight (RF-LOS) link-based Broadcast RID (e.g., a city or a national forest).
1つの機会は、ブロードキャストリドからネットワークRIDまでのゲートウェイでアーキテクチャを強化することです。これにより、両方が最適であり、規制当局とオペレーターに柔軟性が与えられます。これは、[FAA_RID]計画されたエリア操作のネットワークRIDレポートよりも、局所的な直接的な視覚観測と直接無線周波数の視覚線の監視とともに、[FAA_RID]計画されたエリア操作のネットワークRIDレポートよりも大きな忠実度よりも大きな忠実度よりも優れています（RF-LOS）リンクベースのブロードキャストRID（例：都市または国有林）。
These gateways could be pre-positioned (e.g., around airports, public gatherings, and other sensitive areas) and/or crowdsourced (as nothing more than a smartphone with a suitable app is needed). Crowdsourcing can be encouraged by quid pro quo, providing CS-RID Surveillance Supplemental Data Service Provider (SDSP) outputs only to CS-RID Finders. As Broadcast RID media have a limited range, messages claiming sender (typically UA) locations far from a physical layer receiver thereof ("Finder" below, typically Observer device) should arouse suspicion of possible intent to deceive; a fast and computationally inexpensive consistency check can be performed (by the Finder or the Surveillance SDSP) on application layer data present in the gateway (claimed UA location vs physical receiver location), and authorities can be alerted to failed checks. CS-RID SDSPs can use messages with precise date/time/position stamps from the gateways to multilaterate UA locations, independent of the locations claimed in the messages, which are entirely self-reported by the operator in UAS RID and UTM, and thus are subject not only to natural time lag and error but also operator misconfiguration or intentional deception.
これらのゲートウェイは、事前に位置することができます（たとえば、空港、公共の集まり、その他の敏感なエリア周辺）、および/またはクラウドソーシング（適切なアプリを備えたスマートフォンに過ぎないため）。クラウドソーシングは、Quid Pro Quoによって奨励され、CS-RID Supportal Data Serpy Service Provider（SDSP）がCS-RID Findersにのみ出力されます。ブロードキャストRIDメディアの範囲は限られているため、送信者（通常はUA）の位置がその物理レイヤーレシーバー（以下の「Finder」、通常はオブザーバーデバイス）から遠く離れた場所を主張するメッセージが、欺く意図の可能性の疑いを喚起するはずです。ゲートウェイに存在するアプリケーション層データ（UAロケーション対物理レシーバーの場所）で（FinderまたはSurveillance SDSPによって）高速で計算上の安価な一貫性チェックを実行できます。CS-RID SDSPSは、GatewaysからMultiLaterate UAの場所にゲートウェイから正確な日付/時刻/位置スタンプを持つメッセージを使用できます。これは、UAS RIDおよびUTMのオペレーターによって完全に自己報告されているメッセージで請求されている場所とは無関係です。自然なタイムラグとエラーだけでなく、オペレーターの誤解や意図的な欺ceptionも対象となります。
Multilateration technologies use physical layer information, such as precise Time Of Arrival (TOA) of transmissions from mobile transmitters at receivers with a priori precisely known locations, to estimate the locations of the mobile transmitters.
多面化技術は、モバイル送信機の場所を推定するために、正確に既知の場所を持つ受信機のモバイル送信機からの到着時間（TOA）の正確な時間（TOA）などの物理層情報を使用します。
Further, gateways with additional sensors (e.g., smartphones with cameras) can provide independent information on the UA type and size, confirming or refuting those claims made in the UAS RID messages.
さらに、追加のセンサー（カメラ付きのスマートフォンなど）を備えたゲートウェイは、UAタイプとサイズに関する独立した情報を提供し、UAS RIDメッセージで作成された主張を確認または反論することができます。
Sections 6.1 and 6.2 define two additional entities that are required to provide this Crowdsourced Remote ID (CS-RID).
セクション6.1および6.2は、このクラウドソーシングされたリモートID（CS-RID）を提供するために必要な2つの追加エンティティを定義します。
This approach satisfies the following DRIP requirements defined in [RFC9153]: GEN-5, GEN-11, and REG-1. As Broadcast messages are inherently multicast, GEN-10 is met for local-link multicast to multiple Finders (this is how multilateration is possible).
このアプローチは、[RFC9153]で定義されている次の点滴要件を満たしています：Gen-5、Gen-11、およびReg-1。ブロードキャストメッセージは本質的にマルチキャストであるため、Gen-10はローカルリンクマルチキャストに対して複数のファインダーに対して満たされています（これがマルチレートが可能です）。
A CS-RID Finder is the gateway for Broadcast Remote ID Messages into UTM. It performs this gateway function via a CS-RID SDSP. A CS-RID Finder could implement, integrate, or accept outputs from a Broadcast RID receiver. However, it should not depend upon a direct interface with a GCS, Net-RID SP, Net-RID DP, or Net-RID client. It would present a new interface to a CS-RID SDSP, similar to but readily distinguishable from that which a UAS (UA or GCS) presents to a Net-RID SP.
CS-RID Finderは、Remote IDメッセージをUTMにブロードキャストするためのゲートウェイです。CS-RID SDSPを介してこのゲートウェイ関数を実行します。CS-RIDファインダーは、放送のRIDレシーバーからの出力を実装、統合、または受け入れることができます。ただし、GCS、ネットリッドSP、ネットリッドDP、またはネットリッドクライアントを使用した直接インターフェイスに依存してはなりません。CS-RID SDSPへの新しいインターフェイスを提示します。これは、UAS（UAまたはGCS）がネットリッドspに示すものと同様ですが、容易に区別できます。
A CS-RID SDSP aggregates and processes (e.g., estimates UA locations using multilateration when possible) information collected by CS-RID Finders. A CS-RID SDSP should present the same interface to a Net-RID SP as it does to a Net-RID DP and to a Net-RID DP as it does to a Net-RID SP, but its data source must be readily distinguishable via Finders rather than direct from the UAS itself.
CS-RID SDSPの集合体とプロセス（たとえば、可能な場合は多層を使用してUAの場所を推定します）CS-RID Findersが収集した情報。CS-RID SDSPは、ネットリッドDPとネットリッドSPと同じネットリッドDPと同じネットリッドSPに同じインターフェイスを提示する必要がありますが、そのデータソースは容易に区別できる必要がありますUAS自体から直接ではなく、ファインダーを介して。
One of the ways in which DRIP can enhance [F3411-22a] with immediately actionable information is by enabling an Observer to instantly initiate secure communications with the UAS remote pilot, Pilot In Command, operator, USS under which the operation is being flown, or other entity potentially able to furnish further information regarding the operation and its intent and/or to immediately influence further conduct or termination of the operation (e.g., land or otherwise exit an airspace volume). Such potentially distracting communications demand strong "AAA" (Authentication, Attestation, Authorization, Access Control, Accounting, Attribution, Audit), per applicable policies (e.g., of the cognizant CAA).
すぐに実行可能な情報でDRIPが[F3411-22A]を強化できる方法の1つは、オブザーバーがUASリモートパイロット、パイロットのパイロット、オペレーター、操作が飛行中のUSS、またはUSSとの安全な通信を即座に開始できるようにすることです。他のエンティティは、操作とその意図に関するさらなる情報を提供できる可能性があり、/または操作のさらなる行動または終了（土地や空域の音量を出る）に直ちに影響を与えることができます。このような気を散らす可能性のあるコミュニケーションは、該当するポリシー（例：Cognizant CAA）ごとに、強力な「AAA」（認証、証明、許可、アクセス制御、アクセス制御、属性、監査）を要求します。
A DRIP entity identifier based on a HHIT, as outlined in Section 3, embeds an identifier of the DIME in which it can be found (expected typically to be the USS under which the UAS is flying), and the procedures outlined in Section 5 enable Observer verification of that relationship. A DRIP entity identifier with suitable records in public and private registries, as outlined in Section 5, can enable lookup not only of information regarding the UAS but also identities of and pointers to information regarding the various associated entities (e.g., the USS under which the UAS is flying an operation), including means of contacting those associated entities (i.e., locators, typically IP addresses).
セクション3で概説されているように、HHITに基づいたDRIPエンティティ識別子は、それが見つかるDIMEの識別子（通常UASが飛んでいるUSSであると予想される）を埋め込み、セクション5で概説した手順を有効にします。その関係のオブザーバーの検証。セクション5で概説されているように、パブリックレジストリおよびプライベートレジストリの適切な記録を持つDRIPエンティティ識別子は、UASに関する情報だけでなく、さまざまな関連エンティティに関する情報のアイデンティティとポインターの検索を可能にすることができます（例：USSがあるUSSUASは、それらの関連エンティティ（つまり、ロケーター、通常はIPアドレス）に連絡する手段を含む操作を飛行しています。
A suitably equipped Observer could initiate a secure communication channel, using the DET HI, to a similarly equipped and identified entity, i.e., the UA itself, if operating autonomously; the GCS, if the UA is remotely piloted and the necessary records have been populated in the DNS; the USS; etc. Assuming secure communication setup (e.g., via IPsec or HIP), arbitrary standard higher-layer protocols can then be used for Observer to Pilot (O2P) communications (e.g., SIP [RFC3261] et seq), Vehicle to Everything (V2X) (or more specifically Aircraft to Anything (A2X)) communications (e.g., [MAVLink]), etc. Certain preconditions are necessary: 1) each party needs a currently usable means (typically a DNS) of resolving the other party's DRIP entity identifier to a currently usable locator (IP address), and 2) there must be currently usable bidirectional IP connectivity (not necessarily via the Internet) between the parties. One method directly supported by the use of HHITs as DRIP entity identifiers is initiation of a HIP Base Exchange (BEX) and Bound End-to-End Tunnel (BEET).
適切に装備されたオブザーバーは、Det Hiを使用して、同様に装備され識別されたエンティティ、つまり自律的に操作する場合はUA自体に安全な通信チャネルを開始できます。GCSは、UAがリモートでパイロットされ、必要な記録がDNSに入力されている場合。USS;安全な通信セットアップ（IPSECまたは股関節など）を仮定すると、任意の標準的な高層プロトコルを使用して、オブザーバーからパイロット（O2P）通信（例：SIP [RFC3261] et seq）、すべての車両（v2x）（または、より具体的にはあらゆる航空機（A2X））通信（例：[Mavlink]）など。特定の前提条件が必要です。1）各当事者には、現在使用可能な手段が必要です（通常、DNS）相手のドリップエンティティ識別子を解決するための（通常はDNS）現在使用可能なロケーター（IPアドレス）、および2）は、当事者間に現在使用可能な双方向IP接続（必ずしもインターネット経由ではない）が必要です。HHITの使用によって直接サポートされる1つの方法は、ドリップエンティティ識別子としての使用によって直接サポートされています。股関節ベース交換（BEX）とエンドツーエンドトンネル（BEET）の開始です。
This approach satisfies DRIP requirement GEN-6 Contact, supports satisfaction of DRIP requirements GEN-8, GEN-9, PRIV-2, PRIV-5, and REG-3 [RFC9153], and is compatible with all other DRIP requirements.
このアプローチは、DRIP要件GEN-6の接触を満たし、DRIP要件の満足度をサポートし、Gen-8、Gen-9、Priv-2、Priv-5、およびREG-3 [RFC9153]をサポートし、他のすべてのDRIP要件と互換性があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
The size of the public key hash in the HHIT is vulnerable to a second-preimage attack. It is well within current server array technology to compute another key pair that hashes to the same HHIT (given the current ORCHID construction hash length to fit UAS RID and IPv6 address constraints). Thus, if a receiver were to check HHIT/HI pair validity only by verifying that the received HI and associated information, when hashed in the ORCHID construction, reproduce the received HHIT, an adversary could impersonate a validly registered UA. To defend against this, online receivers should verify the received HHIT and received HI with the HDA (typically USS) with which the HHIT/HI pair purports to be registered. Online and offline receivers can use a chain of received DRIP link endorsements from a root of trust through the RAA and the HDA to the UA, e.g., as described in [DRIP-AUTH] and [DRIP-REGISTRIES].
HHITの公開キーのハッシュのサイズは、2番目のプレイマージ攻撃に対して脆弱です。現在のサーバーアレイテクノロジー内では、同じHHITにハッシュする別のキーペアを計算することができます（UAS RIDとIPv6アドレスの制約に適合する現在のオーキッド構造ハッシュの長さを考えると）。したがって、受信者が、蘭の建設を妨害したときに受け取ったHIと関連する情報が受け取ったHHITを再現することを確認することによってのみ、HHIT/HIペアの妥当性をチェックする場合、敵は有効に登録されたUAになりすまします。これを防御するには、オンラインレシーバーは受信したHHITを検証し、HHIT/HIペアが登録されるHDA（通常はUSS）でHIを受信する必要があります。オンラインおよびオフラインの受信機は、[DRIP-Auth]および[DRIP-REGISTRIES]で説明されているように、RAAとHDAを介した信頼のルートからUAへの受信したドリップリンクの承認のチェーンを使用できます。
Compromise of a DIME private key could do widespread harm [DRIP-REGISTRIES]. In particular, it would allow bad actors to impersonate trusted members of said DIME. These risks are in addition to those involving key management practices and will be addressed as part of the DIME process. All DRIP public keys can be found in the DNS, thus they can be revoked in the DNS, and users SHOULD check the DNS when available. Specific key revocation procedures are as yet to be determined.
Dimeの秘密鍵の妥協は、広範囲にわたる害をもたらす可能性があります[Drip-Registries]。特に、悪い俳優は、当該ダイムの信頼できるメンバーになりすますことができます。これらのリスクは、主要な管理慣行を含むリスクに追加され、DIMEプロセスの一部として対処されます。すべてのドリップパブリックキーはDNSで見つけることができるため、DNSで取り消すことができ、ユーザーは利用可能な場合はDNSをチェックする必要があります。特定の重要な取り消し手順は、まだ決定されていません。
The security provided by asymmetric cryptographic techniques depends upon protection of the private keys. It may be necessary for the GCS to have the key pair to register the HHIT to the USS. Thus, it may be the GCS that generates the key pair and delivers it to the UA, making the GCS a part of the key security boundary. Leakage of the private key, from either the UA or the GCS, to the component manufacturer is a valid concern, and steps need to be in place to ensure safe keeping of the private key. Since it is possible for the UAS RID sender of a small harmless UA (or the entire UA) to be carried by a larger dangerous UA as a "false flag", it is out of scope to deal with secure storage of the private key.
非対称の暗号化技術によって提供されるセキュリティは、プライベートキーの保護に依存します。GCSがUSSにHHITを登録するためのキーペアを持つ必要がある場合があります。したがって、キーペアを生成してUAに配信するのはGCSである可能性があり、GCSは主要なセキュリティ境界の一部になります。UAまたはGCSからコンポーネントメーカーへの秘密鍵の漏れは有効な懸念事項であり、秘密鍵を安全に維持するためにステップを整える必要があります。小さな無害なUA（またはUA全体）のUAS RID送信者が「偽のフラグ」としてより大きな危険なUAによって運ばれる可能性があるため、秘密鍵の安全なストレージに対処することは範囲外です。
There has been no effort as of yet in DRIP to address post quantum computing cryptography. Small UAS and Broadcast Remote ID communications are so constrained that current post quantum computing cryptography is not applicable. Fortunately, since a UA may use a unique HHIT for each operation, the attack window can be limited to the duration of the operation. One potential future DRIP use for post quantum cryptography is for key pairs that have long usage lives but that rarely, if ever, need to be transmitted over bandwidth constrained links, such as for serial numbers or operators. As the HHIT contains the ID for the cryptographic suite used in its creation, a future post quantum computing safe algorithm that fits Remote ID constraints may be readily added. This is left for future work.
ポスト量子コンピューティング暗号化に対処するための点滴にはまだ努力がありませんでした。小型UASおよび放送リモートID通信は非常に制約されているため、現在のポスト量子コンピューティング暗号化は適用されません。幸いなことに、UAは各操作に一意のHHITを使用する可能性があるため、攻撃ウィンドウは操作の期間に制限できます。ポスト量子暗号化の潜在的な将来の点滴使用の1つは、使用寿命が長いが、シリアル番号や演算子などの帯域幅制限リンクを介して送信する必要はほとんどない場合は、めったに送信する必要はありません。HHITには、作成に使用される暗号化スイートのIDが含まれているため、リモートIDの制約に適合する将来のポスト量子コンピューティングセーフアルゴリズムを容易に追加できます。これは将来の仕事のために残されています。
Remote ID services from the UA use a wireless link in a public space. As such, they are open to many forms of RF jamming. It is trivial for an attacker to stop any UA messages from reaching a wireless receiver. Thus, it is pointless to attempt to provide relief from DoS attacks, as there is always the ultimate RF jamming attack. Also, DoS may be attempted with spoofing/replay attacks; for which, see Section 9.4.
UAのリモートIDサービスは、パブリックスペースでワイヤレスリンクを使用します。そのため、多くの形態のRFジャミングに開かれています。攻撃者がUAメッセージがワイヤレスレシーバーに届かないようにするのは簡単です。したがって、究極のRFジャミング攻撃が常にあるため、DOS攻撃からの救済を提供しようとすることは無意味です。また、DOSはスプーフィング/リプレイ攻撃で試みられる場合があります。そのため、セクション9.4を参照してください。
As noted in Section 5, spoofing is combatted by the intrinsic self-attesting properties of HHITs, plus their registration. Also, as noted in Section 5, to combat replay attacks, a receiver MUST NOT trust any claims nominally received from an observed UA (not even the Basic ID message purportedly identifying that UA) until the receiver verifies that the private key used to sign those claims is trusted, that the sender actually possesses that key, and that the sender appears indeed to be that observed UA. This requires receiving a complete chain of endorsement links from a root of trust to the UA's leaf DET, plus a message containing suitable nonce-like data signed with the private key corresponding to that DET, and verifying all the foregoing. The term "nonce-like" describes data that is readily available to the prover and the verifier, changes frequently, is not predictable by the prover, and can be checked quickly at low computational cost by the verifier; a Location/Vector message is an obvious choice.
セクション5で述べたように、スプーフィングは、HHITの本質的な自己触科の特性とその登録によって戦います。また、セクション5で述べたように、リプレイ攻撃と戦うために、受信者は、受信者が署名に使用されるために使用される秘密鍵が使用されることを確認するまで、観察されたUAから名目上受けたクレーム（UAを識別する基本的なIDメッセージでさえ）を信頼してはなりません。主張は信頼されており、送信者は実際にその鍵を所有しており、送信者が実際にその観察されたuaのように見えることを信頼しています。これには、信頼のルートからUAのLeaf Detへの完全な承認リンクを受け取る必要があります。さらに、そのDETに対応する秘密鍵で署名された適切な非CEのようなデータを含むメッセージが必要です。「NonCe-like」という用語は、プローバーと検証者が容易に利用できるデータを説明し、頻繁に変更され、Proverが予測できず、検証者が計算コストを低くすることができます。場所/ベクトルメッセージは明らかな選択です。
Section 6 and, more fundamentally, Section 3.3 both require timestamps. In Broadcast RID messages, [F3411-22a] specifies both 32-bit Unix-style UTC timestamps (seconds since midnight going into the 1st day of 2019, rather than 1970) and 16-bit relative timestamps (tenths of seconds since the start of the most recent hour or other specified event). [F3411-22a] requires that 16-bit timestamp accuracy, relative to the time of applicability of the data being timestamped, also be reported, with a worst allowable case of 1.5 seconds. [F3411-22a] does not specify the time source, but GNSS is generally assumed, as latitude, longitude, and geodetic altitude must be reported and most small UAS use GNSS for positioning and navigation.
セクション6およびより根本的に、セクション3.3はどちらもタイムスタンプが必要です。ブロードキャストRIDメッセージでは、[F3411-22A]は、32ビットUNIXスタイルのUTCタイムスタンプ（1970年ではなく2019年の1日目に真夜中から入る秒）と16ビットの相対タイムスタンプの両方（10分の1秒後から10分の1秒の両方の両方の両方を指定します。最新の時間またはその他の指定されたイベント）。[F3411-22A]では、タイムスタンプが行われるデータの適用可能性の時間と比較して、16ビットのタイムスタンプの精度も報告されており、最悪の許容可能なケースが1.5秒であることが報告されています。[F3411-22A]は時間源を指定しませんが、緯度、経度、測地高度を報告する必要があり、ほとんどの小型UAは位置決めと航海にGNSを使用するため、GNSSが一般的に想定されます。
Informative note: For example, to satisfy [FAA_RID], [F3586-22] specifies tamper protection of the entire RID subsystem and use of the GPS operated by the US Government. The GPS has sub-microsecond accuracy and 1.5-second precision. In this example, UA-sourced messages can be assumed to have timestamp accuracy and precision of 1.5 seconds at worst.
有益な注意：たとえば、[FAA_RID]、[F3586-22]を満たすために、RIDサブシステム全体の改ざん防止と米国政府が運営するGPSの使用を指定します。GPSには、サブマイクロ秒の精度と1.5秒の精度があります。この例では、UA-Sourcedメッセージは、最悪の場合はタイムスタンプの精度と1.5秒の精度があると想定できます。
GCS often have access to cellular LTE or other time sources better than the foregoing, and such better time sources would be required to support multilateration in Section 6, but such better time sources cannot be assumed generally for purposes of security analysis.
GCSは、多くの場合、細胞LTEまたは他の時間ソースに前述よりも優れているよりも優れているため、セクション6の多層をサポートするためにこのようなより良い時間源が必要になりますが、このようなより良い時間ソースは、セキュリティ分析の目的で一般的に想定することはできません。
Broadcast RID messages can contain personal data (Section 3.2 of [RFC6973]), such as the operator ID, and, in most jurisdictions, must contain the pilot/GCS location. The DRIP architectural approach for personal data protection is symmetric encryption of the personal data using a session key known to the UAS and its USS, as follows. Authorized Observers obtain plaintext in either of two ways: 1) an Observer can send the UAS ID and the cyphertext to a server that offers decryption as a service, and 2) an Observer can send just the UAS ID to a server that returns the session key so that the Observer can directly, locally decrypt all cyphertext sent by that UA during that session (UAS operation). In either case, the server can be a public safety USS, the Observer's own USS, or the UA's USS if the latter can be determined (which, under DRIP, can be from the UAS ID itself). Personal data is protected unless the UAS is otherwise configured, i.e., as part of DRIP-enhanced RID subsystem provisioning, as part of UTM operation authorization, or via subsequent authenticated communications from a cognizant authority. Personal data protection MUST NOT be used if the UAS loses connectivity to its USS; if the UAS loses connectivity, Observers nearby likely also won't have connectivity enabling decryption of the personal data. The UAS always has the option to abort the operation if personal data protection is disallowed, but if this occurs during flight, the UA then MUST broadcast the personal data without protection until it lands and is powered off. Note that normative language was used only minimally in this section, as privacy protection requires refinement of the DRIP architecture and specification of interoperable protocol extensions, which are left for future DRIP documents.
ブロードキャストRIDメッセージには、オペレーターIDなどの個人データ（[RFC6973]のセクション3.2）を含めることができ、ほとんどの管轄区域では、パイロット/GCSの場所を含める必要があります。個人データ保護のためのドリップアーキテクチャアプローチは、次のように、UASとそのUSSに知られているセッションキーを使用した個人データの対称暗号化です。許可されたオブザーバーは、2つの方法のいずれかでプレーンテキストを取得します。1）オブザーバーは、UAS IDとcyphertextをサービスとして復号化を提供するサーバーに送信でき、2）オブザーバーはUAS IDのみをセッションを返すサーバーに送信できます。オブザーバーが直接、そのセッション中にそのUAによって送信されたすべてのcyphertext（UAS操作）を局所的に復号化できるようにキー。どちらの場合でも、サーバーは公共の安全USS、オブザーバー自身のUSS、または後者を決定できる場合のUAのUSS（DRIPの下ではUAS ID自体からのものです）にすることができます。UASが特に構成されていない限り、つまり、UTM運用認証の一部として、またはその後の認証された機関からの認証された通信を介して、DRIP強化RIDサブシステムプロビジョニングの一部として構成されていない限り、個人データは保護されます。UASがUSSへの接続を失った場合、個人データ保護は使用しないでください。UASが接続性を失った場合、近くのオブザーバーには、個人データの復号化を可能にする接続性もありません。UASには、個人データ保護が許可されていない場合に操作を中止するオプションが常にありますが、これが飛行中に発生した場合、UAは着陸して電源を切るまで保護なしに個人データをブロードキャストする必要があります。プライバシー保護には点滴アーキテクチャの改良と相互運用可能なプロトコル拡張の仕様が必要であり、将来の点滴文書のために残されているため、規範的言語はこのセクションでのみ最小限に使用されたことに注意してください。
[F3411-22a]
ASTM International, "Standard Specification for Remote ID
and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July
2022, <https://www.astm.org/f3411-22a.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A.
Gurtov, "Drone Remote Identification Protocol (DRIP)
Requirements and Terminology", RFC 9153,
DOI 10.17487/RFC9153, February 2022,
<https://www.rfc-editor.org/info/rfc9153>.
[RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
"DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
<https://www.rfc-editor.org/info/rfc9374>.
[CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers",
ANSI/CTA 2063-A, September 2019.
[Delegated]
European Union Aviation Safety Agency (EASA), "Commission
Delegated Regulation (EU) 2019/945 of 12 March 2019 on
unmanned aircraft systems and on third-country operators
of unmanned aircraft systems", March 2019,
<https://eur-lex.europa.eu/eli/reg_del/2019/945/oj>.
[DRIP-AUTH]
Wiethuechter, A., Ed., Card, S., and R. Moskowitz, "DRIP
Entity Tag Authentication Formats & Protocols for
Broadcast Remote ID", Work in Progress, Internet-Draft,
draft-ietf-drip-auth-30, 28 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-
auth-30>.
[DRIP-REGISTRIES]
Wiethuechter, A. and J. Reid, "DRIP Entity Tag (DET)
Identity Management Architecture", Work in Progress,
Internet-Draft, draft-ietf-drip-registries-12, 10 July
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
drip-registries-12>.
[F3411-19] ASTM International, "Standard Specification for Remote ID
and Tracking", ASTM F3411-19, DOI 10.1520/F3411-19, May
2022, <https://www.astm.org/f3411-19.html>.
[F3586-22] ASTM International, "Standard Practice for Remote ID Means
of Compliance to Federal Aviation Administration
Regulation 14 CFR Part 89", ASTM F3586-22,
DOI 10.1520/F3586-22, July 2022,
<https://www.astm.org/f3586-22.html>.
[FAA_RID] United States Federal Aviation Administration (FAA),
"Remote Identification of Unmanned Aircraft", Federal
Register, Vol. 86, No. 10, January 2021,
<https://www.govinfo.gov/content/pkg/FR-2021-01-15/
pdf/2020-28948.pdf>.
[FAA_UAS_Concept_Of_Ops]
United States Federal Aviation Administration (FAA),
"Unmanned Aircraft System (UAS) Traffic Management (UTM)
Concept of Operations", v2.0, March 2020,
<https://www.faa.gov/sites/faa.gov/files/2022-08/
UTM_ConOps_v2.pdf>.
[FS_AEUA] "Study of Further Architecture Enhancement for UAV and
UAM", S2-2107092, October 2021,
<https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/
TSGS2_147E_Electronic_2021-10/Docs/S2-2107092.zip>.
[Implementing]
European Union Aviation Safety Agency (EASA), "Commission
Implementing Regulation (EU) 2019/947 of 24 May 2019 on
the rules and procedures for the operation of unmanned
aircraft (Text with EEA relevance.)", May 2019,
<https://eur-lex.europa.eu/legal-content/EN/
TXT/?uri=CELEX%3A32019R0947>.
[Implementing_update]
European Union Aviation Safety Agency (EASA), "Commission
Implementing Regulation (EU) 2021/664 of 22 April 2021 on
a regulatory framework for the U-space (Text with EEA
relevance)", April 2021, <https://eur-lex.europa.eu/legal-
content/EN/TXT/?uri=CELEX%3A32021R0664>.
[LAANC] United States Federal Aviation Administration (FAA), "Low
Altitude Authorization and Notification Capability",
<https://www.faa.gov/
air_traffic/publications/atpubs/foa_html/
chap12_section_9.html>.
[MAVLink] MAVLink, "Micro Air Vehicle Communication Protocol",
<http://mavlink.io/>.
[MOC-NOA] United States Federal Aviation Administration (FAA),
"Accepted Means of Compliance; Remote Identification of
Unmanned Aircraft", Document ID FAA-2022-0859-0001, August
2022,
<https://www.regulations.gov/document/FAA-2022-0859-0001>.
[NPA] European Union Aviation Safety Agency (EASA), "Notice of
Proposed Amendment 2021-14: Development of acceptable
means of compliance and guidance material to support the
U-space regulation", December 2021,
<https://www.easa.europa.eu/downloads/134303/en>.
[NPRM] United States Federal Aviation Administration (FAA),
"Remote Identification of Unmanned Aircraft Systems",
Notice of proposed rulemaking, December 2019,
<https://www.federalregister.gov/documents/2019/
12/31/2019-28100/remote-identification-of-unmanned-
aircraft-systems>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
"WebFinger", RFC 7033, DOI 10.17487/RFC7033, September
2013, <https://www.rfc-editor.org/info/rfc7033>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<https://www.rfc-editor.org/info/rfc7401>.
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7480, DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/info/rfc7480>.
[RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004,
October 2016, <https://www.rfc-editor.org/info/rfc8004>.
[RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name
System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005,
October 2016, <https://www.rfc-editor.org/info/rfc8005>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[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>.
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/info/rfc9082>.
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>.
[RFC9224] Blanchet, M., "Finding the Authoritative Registration Data
Access Protocol (RDAP) Service", STD 95, RFC 9224,
DOI 10.17487/RFC9224, March 2022,
<https://www.rfc-editor.org/info/rfc9224>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
[TR-22.825]
3GPP, "Study on Remote Identification of Unmanned Aerial
Systems (UAS)", Release 16, 3GPP TR 22.825, September
2018,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3527>.
[TR-23.755]
3GPP, "Study on application layer support for Unmanned
Aerial Systems (UAS)", Release 17, 3GPP TR 23.755, March
2021,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3588>.
[TS-23.255]
3GPP, "Application layer support for Uncrewed Aerial
System (UAS); Functional architecture and information
flows", Release 17, 3GPP TS 23.255, June 2021,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3843>.
[U-Space] European Organization for the Safety of Air Navigation
(EUROCONTROL), "U-space Concept of Operations", October
2019,
<https://www.sesarju.eu/sites/default/files/documents/u-
space/CORUS%20ConOps%20vol2.pdf>.
The efforts of the National Aeronautics and Space Administration (NASA) and FAA to integrate UAS operations into the national airspace system (NAS) led to the development of the concept of UTM and the ecosystem around it. The UTM concept was initially presented in 2013, and version 2.0 was published in 2020 [FAA_UAS_Concept_Of_Ops].
National Aeronautics and Space Administration（NASA）とFAAの努力は、UAS運用をNational Airspace System（NAS）に統合するために、UTMの概念とその周辺の生態系の開発につながりました。UTMコンセプトは最初に2013年に発表され、バージョン2.0は2020年に公開されました[FAA_UAS_CONCEPTE_OF_OPS]。
The eventual concept refinement, initial prototype implementation, and testing were conducted by the joint FAA and NASA UTM research transition team. World efforts took place afterward. The Single European Sky ATM Research (SESAR) started the Concept of Operation for EuRopean UTM Systems (CORUS) project to research its UTM counterpart concept, namely [U-Space]. This effort is led by the European Organization for the Safety of Air Navigation (EUROCONTROL).
最終的な概念の改良、初期プロトタイプの実装、およびテストは、共同FAAおよびNASA UTM研究移行チームによって実施されました。その後、世界の努力が行われました。単一のヨーロッパSky ATM Research（SESAR）は、欧州UTMシステム（CORUS）プロジェクトの操作の概念を開始し、UTMのカウンターパートコンセプト、すなわち[Uスペース]を調査しました。この取り組みは、欧州航空航海航空航空機関（Eurocontrol）が主導しています。
Both NASA and SESAR have published their UTM concepts of operations to guide the development of their future air traffic management (ATM) system and ensure safe and efficient integration of manned and unmanned aircraft into the national airspace.
NASAとSESARは、将来の航空交通管理（ATM）システムの開発を導き、有人および無人の航空機を国立航空機に安全で効率的な統合を確保するために、UTM運用の概念を公開しています。
UTM comprises UAS operations infrastructure, procedures, and local regulation compliance policies to guarantee safe UAS integration and operation. The main functionality of UTM includes, but is not limited to, providing means of communication between UAS operators and service providers and a platform to facilitate communication among UAS service providers.
UTMは、安全なUASの統合と運用を保証するために、UAS運用インフラストラクチャ、手順、およびローカル規制コンプライアンスポリシーで構成されています。UTMの主な機能には、UASオペレーターとサービスプロバイダー間のコミュニケーション手段と、UASサービスプロバイダー間のコミュニケーションを促進するプラットフォームが含まれますが、これらに限定されません。
A USS plays an important role to fulfill the key performance indicators (KPIs) that UTM has to offer. Such an entity acts as a proxy between UAS operators and UTM service providers. It provides services like real-time UAS traffic monitoring and planning, aeronautical data archiving, airspace and violation control, interacting with other third-party control entities, etc. A USS can coexist with other USS to build a large service coverage map that can load-balance, relay, and share UAS traffic information.
USSは、UTMが提供する重要なパフォーマンスインジケーター（KPI）を満たすために重要な役割を果たします。このようなエンティティは、UASオペレーターとUTMサービスプロバイダーの間のプロキシとして機能します。リアルタイムのUASトラフィックの監視と計画、航空データアーカイブ、空域と違反制御、他のサードパーティ制御エンティティとの対話などのサービスを提供します。USSは、他のUSと共存して、ロードできる大規模なサービスカバレッジマップを構築できます。 - バランス、リレー、およびUASトラフィック情報を共有します。
The FAA works with UAS industry shareholders and promotes the Low Altitude Authorization and Notification Capability [LAANC] program, which is the first system to realize some of the envisioned functionality of UTM. The LAANC program can automate UAS operational intent (flight plan) submissions and applications for airspace authorization in real time by checking against multiple aeronautical databases, such as airspace classification and operating rules associated with it, the FAA UAS facility map, special use airspace, Notice to Airmen (NOTAM), and Temporary Flight Restriction (TFR).
FAAはUAS業界の株主と協力し、UTMの想定されている機能の一部を実現する最初のシステムである低高度承認および通知能力[LAANC]プログラムを促進します。LAANCプログラムは、Airspaceの分類やそれに関連するFAA UAS施設マップ、Special Use Airspace、通知など、複数の航空データベースに対してチェックすることにより、UAS運用意図（フライトプラン）の提出とアプリケーションをリアルタイムでリアルタイムで自動化できます。航空会社（NOTAM）、および一時的な飛行制限（TFR）へ。
This section illustrates a couple of use case scenarios where UAS participation in UTM has significant safety improvement.
このセクションでは、UTMへのUAS参加が大幅に安全改善するいくつかのユースケースシナリオを示しています。
1. For a UAS participating in UTM and taking off or landing in controlled airspace (e.g., Class Bravo, Charlie, Delta, and Echo in the United States), the USS under which the UAS is operating is responsible for verifying UA registration, authenticating the UAS operational intent (flight plan) by checking against a designated UAS facility map database, obtaining the air traffic control (ATC) authorization, and monitoring the UAS flight path in order to maintain safe margins and follow the pre-authorized sequence of authorized 4-D volumes (route).
1. UTMに参加し、制御された空域（米国のクラスBravo、Charlie、Delta、Echoなど）に離陸または着陸するUASの場合、UASが運営しているUSSはUA登録の検証、UASの認証を担当します。指定されたUAS施設マップデータベースに対してチェックし、航空交通管制（ATC）認証を取得し、安全なマージンを維持し、認可された4-Dの事前に認可されたシーケンスに従うためにUASフライトパスを監視することにより、運用上（飛行計画）ボリューム（ルート）。
2. For a UAS participating in UTM and taking off or landing in uncontrolled airspace (e.g., Class Golf in the United States), preflight authorization must be obtained from a USS when operating BVLOS. The USS either accepts or rejects the received operational intent (flight plan) from the UAS. An accepted UAS operation may, and in some cases must, share its current flight data, such as GPS position and altitude, to the USS. The USS may maintain (and provide to authorized requestors) the UAS operation status near real time in the short term and may retain at least some of it in the longer term, e.g., for overall airspace air traffic monitoring.
2. UTMに参加し、制御されていない空域（米国のクラスゴルフなど）に離陸または着陸するUASの場合、BVLOを運営する際にはUSSからプリライト許可を取得する必要があります。USSは、UASから受信した運用意図（フライトプラン）を受け入れるか拒否します。受け入れられたUAS操作は、GPSの位置や高度などの現在の飛行データをUSSに共有することができます。USSは、短期的にはUASの操作ステータスを維持（および認可された要求者にリアルタイムに近い状態に維持し（および承認された要求者に提供）、たとえば、空域全体の航空交通監視のために、少なくともその一部を長期的に保持する場合があります。
ADS-B is the de jure technology used in manned aviation for sharing location information, from the aircraft to ground and satellite-based systems, designed in the early 2000s. Broadcast RID is conceptually similar to ADS-B but with the receiver target being the general public on generally available devices (e.g., smartphones).
ADS-Bは、2000年代初頭に設計された航空機から地上および衛星ベースのシステムまで、位置情報を共有するために有人航空で使用されるDe Jureテクノロジーです。ブロードキャストRIDは概念的にADS-Bに似ていますが、レシーバーターゲットは一般に利用可能なデバイス（例：スマートフォン）の一般的な一般の人々です。
For numerous technical reasons, ADS-B itself is not suitable for low-flying, small UAS. Technical reasons include, but are not limited to, the following:
多くの技術的な理由で、ADS-B自体は、低飛行の小さなUASには適していません。技術的な理由には、以下が含まれますが、これらに限定されません。
1. lack of support for the 1090-MHz ADS-B channel on any consumer handheld devices
1. 消費者ハンドヘルドデバイスの1090-MHzADS-Bチャンネルのサポートの欠如
2. Cost, Size, Weight, and Power (CSWaP) requirements of ADS-B transponders on CSWaP-constrained UA
2. CSWAPが制約したUA上のADS-Bトランスポンダーのコスト、サイズ、重量、および電力（CSWAP）要件
3. limited bandwidth of both uplink and downlink, which would likely be saturated by large numbers of UAS, endangering manned aviation
3. アップリンクとダウンリンクの両方の限られた帯域幅。これは、多数のUASによって飽和し、有人航空を危険にさらす可能性があります
Understanding these technical shortcomings, regulators worldwide have ruled out the use of ADS-B for the small UAS for which UAS RID and DRIP are intended.
これらの技術的欠点を理解して、世界中の規制当局は、UAS RIDおよびDRIPが意図している小さなUASに対するADS-Bの使用を除外しています。
The work of the FAA's UAS Identification and Tracking (UAS ID) Aviation Rulemaking Committee (ARC) is the foundation of later ASTM and IETF DRIP WG efforts. The work of ASTM F38.02 in balancing the interests of diverse stakeholders is essential to the necessary rapid and widespread deployment of UAS RID. Thanks to Alexandre Petrescu, Stephan Wenger, Kyle Rose, Roni Even, Thomas Fossati, Valery Smyslov, Erik Kline, John Scudder, Murray Kucheraway, Robert Wilton, Roman Daniliw, Warren Kumari, Zaheduzzaman Sarker, and Dave Thaler for the reviews and helpful positive comments. Thanks to Laura Welch for her assistance in greatly improving this document. Thanks to Dave Thaler for showing our authors how to leverage the RATS model for attestation in DRIP. Thanks to chairs Daniel Migault and Mohamed Boucadair for direction of our team of authors and editors, some of whom are relative newcomers to writing IETF documents. Thanks especially to Internet Area Director Éric Vyncke for guidance and support.
FAAのUAS識別および追跡（UAS ID）航空規則委員会（ARC）の作業は、後のASTMおよびIETFドリップWGの取り組みの基盤です。多様な利害関係者の利益のバランスをとる際のASTM F38.02の仕事は、UAS RIDの必要な迅速かつ広範な展開に不可欠です。アレクサンドル・ペトレスク、ステファン・ウェンガー、カイル・ローズ、ロニ・イヴ・ロニ、トーマス・フォッサティ、ヴァリー・スミスロフ、エリック・クライン、ジョン・スカダー、マレー・クチェラウェイ、ロバート・ウィルトン、ローマン・ダニリウ、ローマン・ダニリウ、ウォーレン・クマリ、ザヘダズザマン・サルカー、デイブ・タラーはレビューとハープ・ポジティブに感謝しますコメント。Laura Welchに、この文書を大幅に改善してくれたことに感謝します。Dave Thalerに、DRIPでの証明のためにラットモデルを活用する方法を著者に示してくれたことに感謝します。椅子のおかげで、Daniel MigaultとMohamed Boucadairのおかげで、著者と編集者のチームの指示については、その一部はIETFドキュメントを書くための比較的新人です。特にインターネットエリアディレクターのエリック・ヴィンケに、ガイダンスとサポートに感謝します。
Stuart W. Card
AX Enterprize
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: stu.card@axenterprize.com
Adam Wiethuechter
AX Enterprize
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: adam.wiethuechter@axenterprize.com
Robert Moskowitz
HTT Consulting
Oak Park, MI 48237
United States of America
Email: rgm@labs.htt-consult.com
Shuai Zhao (editor)
Intel
2200 Mission College Blvd.
Santa Clara, 95054
United States of America
Email: shuai.zhao@ieee.org
Andrei Gurtov
Linköping University
IDA
SE-58183 Linköping
Sweden
Email: gurtov@acm.org