rfc9575.original | rfc9575.txt | |||
---|---|---|---|---|
DRIP Working Group A. Wiethuechter, Ed. | Internet Engineering Task Force (IETF) A. Wiethuechter, Ed. | |||
Internet-Draft S. Card | Request for Comments: 9575 S. Card | |||
Intended status: Standards Track AX Enterprize, LLC | Category: Standards Track AX Enterprize, LLC | |||
Expires: 24 August 2024 R. Moskowitz | ISSN: 2070-1721 R. Moskowitz | |||
HTT Consulting | HTT Consulting | |||
21 February 2024 | April 2024 | |||
DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote | DRIP Entity Tag Authentication Formats and Protocols for Broadcast | |||
ID | Remote Identification | |||
draft-ietf-drip-auth-49 | ||||
Abstract | Abstract | |||
The Drone Remote Identification Protocol (DRIP), plus trust policies | The Drone Remote Identification Protocol (DRIP), plus trust policies | |||
and periodic access to registries, augments Unmanned Aircraft System | and periodic access to registries, augments Unmanned Aircraft System | |||
(UAS) Remote Identification (RID), enabling local real time | (UAS) Remote Identification (RID), enabling local real-time | |||
assessment of trustworthiness of received RID messages and observed | assessment of trustworthiness of received RID messages and observed | |||
UAS, even by Observers lacking Internet access. This document | UAS, even by Observers lacking Internet access. This document | |||
defines DRIP message types and formats to be sent in Broadcast RID | defines DRIP message types and formats to be sent in Broadcast RID | |||
Authentication Messages to verify that attached and recent detached | Authentication Messages to verify that attached and recently detached | |||
messages were signed by the registered owner of the DRIP Entity Tag | messages were signed by the registered owner of the DRIP Entity Tag | |||
(DET) claimed. | (DET) claimed. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This is an Internet Standards Track document. | |||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at https://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on 24 August 2024. | 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/rfc9575. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
extracted from this document must include Revised BSD License text as | to this document. Code Components extracted from this document must | |||
described in Section 4.e of the Trust Legal Provisions and are | include Revised BSD License text as described in Section 4.e of the | |||
provided without warranty as described in the Revised BSD License. | Trust Legal Provisions and are provided without warranty as described | |||
in the Revised BSD License. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction | |||
1.1. DRIP Entity Tag (DET) Authentication Goals for Broadcast | 1.1. DRIP Entity Tag (DET) Authentication Goals for Broadcast | |||
RID . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | RID | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Terminology | |||
2.1. Required Terminology . . . . . . . . . . . . . . . . . . 5 | 2.1. Required Terminology | |||
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 | 2.2. Definitions | |||
3. UAS RID Authentication Background & Procedures . . . . . . . 5 | 3. UAS RID Authentication Background and Procedures | |||
3.1. DRIP Authentication Protocol Description . . . . . . . . 6 | 3.1. DRIP Authentication Protocol Description | |||
3.1.1. Usage of DNS . . . . . . . . . . . . . . . . . . . . 6 | 3.1.1. Usage of DNS | |||
3.1.2. Providing UAS RID Trust . . . . . . . . . . . . . . . 7 | 3.1.2. Providing UAS RID Trust | |||
3.2. ASTM Authentication Message Framing . . . . . . . . . . . 8 | 3.2. ASTM Authentication Message Framing | |||
3.2.1. Authentication Page . . . . . . . . . . . . . . . . . 8 | 3.2.1. Authentication Page | |||
3.2.2. Authentication Payload Field . . . . . . . . . . . . 9 | 3.2.2. Authentication Payload Field | |||
3.2.3. Specific Authentication Method (SAM) . . . . . . . . 10 | 3.2.3. Specific Authentication Method (SAM) | |||
3.2.4. ASTM Broadcast RID Constraints . . . . . . . . . . . 11 | 3.2.4. ASTM Broadcast RID Constraints | |||
4. DRIP Authentication Formats . . . . . . . . . . . . . . . . . 13 | 4. DRIP Authentication Formats | |||
4.1. UA Signed Evidence Structure . . . . . . . . . . . . . . 13 | 4.1. UA Signed Evidence Structure | |||
4.2. DRIP Link . . . . . . . . . . . . . . . . . . . . . . . . 15 | 4.2. DRIP Link | |||
4.3. DRIP Wrapper . . . . . . . . . . . . . . . . . . . . . . 17 | 4.3. DRIP Wrapper | |||
4.3.1. Wrapped Count & Format Validation . . . . . . . . . . 18 | 4.3.1. Wrapped Count and Format Validation | |||
4.3.2. Wrapper over Extended Transports . . . . . . . . . . 18 | 4.3.2. Wrapper over Extended Transports | |||
4.3.3. Wrapper Limitations . . . . . . . . . . . . . . . . . 20 | 4.3.3. Wrapper Limitations | |||
4.4. DRIP Manifest . . . . . . . . . . . . . . . . . . . . . . 20 | 4.4. DRIP Manifest | |||
4.4.1. Hash Count & Format Validation . . . . . . . . . . . 21 | 4.4.1. Hash Count and Format Validation | |||
4.4.2. Manifest Ledger Hashes . . . . . . . . . . . . . . . 22 | 4.4.2. Manifest Ledger Hashes | |||
4.4.3. Hash Algorithms and Operation . . . . . . . . . . . . 22 | 4.4.3. Hash Algorithms and Operation | |||
4.5. DRIP Frame . . . . . . . . . . . . . . . . . . . . . . . 23 | 4.5. DRIP Frame | |||
5. Forward Error Correction . . . . . . . . . . . . . . . . . . 24 | 5. Forward Error Correction | |||
5.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 25 | 5.1. Encoding | |||
5.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . . 26 | 5.2. Decoding | |||
5.3. FEC Limitations . . . . . . . . . . . . . . . . . . . . . 29 | 5.3. FEC Limitations | |||
6. Requirements & Recommendations . . . . . . . . . . . . . . . 29 | 6. Requirements and Recommendations | |||
6.1. Legacy Transports . . . . . . . . . . . . . . . . . . . . 29 | 6.1. Legacy Transports | |||
6.2. Extended Transports . . . . . . . . . . . . . . . . . . . 29 | 6.2. Extended Transports | |||
6.3. Authentication . . . . . . . . . . . . . . . . . . . . . 29 | 6.3. Authentication | |||
6.4. Operational . . . . . . . . . . . . . . . . . . . . . . . 30 | 6.4. Operational | |||
6.4.1. DRIP Wrapper . . . . . . . . . . . . . . . . . . . . 31 | 6.4.1. DRIP Wrapper | |||
6.4.2. UAS RID Trust Assessment . . . . . . . . . . . . . . 31 | 6.4.2. UAS RID Trust Assessment | |||
7. Summary of Addressed DRIP Requirements . . . . . . . . . . . 31 | 7. Summary of Addressed DRIP Requirements | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 | 8. IANA Considerations | |||
8.1. IANA DRIP Registry . . . . . . . . . . . . . . . . . . . 32 | 8.1. IANA DRIP Registry | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 | 9. Security Considerations | |||
9.1. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 33 | 9.1. Replay Attacks | |||
9.2. Wrapper vs Manifest . . . . . . . . . . . . . . . . . . . 34 | 9.2. Wrapper vs Manifest | |||
9.3. VNA Timestamp Offsets for DRIP Authentication Formats . . 35 | 9.3. VNA Timestamp Offsets for DRIP Authentication Formats | |||
9.4. DNS Security in DRIP . . . . . . . . . . . . . . . . . . 36 | 9.4. DNS Security in DRIP | |||
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 | 10. Acknowledgments | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 | 11. References | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 37 | 11.1. Normative References | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 38 | 11.2. Informative References | |||
Appendix A. Authentication States . . . . . . . . . . . . . . . 38 | Appendix A. Authentication States | |||
A.1. None: Black . . . . . . . . . . . . . . . . . . . . . . . 40 | A.1. None: Black | |||
A.2. Partial: Gray . . . . . . . . . . . . . . . . . . . . . . 40 | A.2. Partial: Gray | |||
A.3. Unsupported: Brown . . . . . . . . . . . . . . . . . . . 41 | A.3. Unsupported: Brown | |||
A.4. Unverifiable: Yellow . . . . . . . . . . . . . . . . . . 41 | A.4. Unverifiable: Yellow | |||
A.5. Verified: Green . . . . . . . . . . . . . . . . . . . . . 41 | A.5. Verified: Green | |||
A.6. Trusted: Blue . . . . . . . . . . . . . . . . . . . . . . 41 | A.6. Trusted: Blue | |||
A.7. Questionable: Orange . . . . . . . . . . . . . . . . . . 41 | A.7. Questionable: Orange | |||
A.8. Unverified: Red . . . . . . . . . . . . . . . . . . . . . 42 | A.8. Unverified: Red | |||
A.9. Conflicting: Purple . . . . . . . . . . . . . . . . . . . 42 | A.9. Conflicting: Purple | |||
Appendix B. Operational Recommendation Analysis . . . . . . . . 42 | Appendix B. Operational Recommendation Analysis | |||
B.1. Page Counts vs Frame Counts . . . . . . . . . . . . . . . 42 | B.1. Page Counts vs Frame Counts | |||
B.1.1. Special Cases . . . . . . . . . . . . . . . . . . . . 44 | B.1.1. Special Cases | |||
B.2. Full Authentication Example . . . . . . . . . . . . . . . 44 | B.2. Full Authentication Example | |||
B.2.1. Raw Example . . . . . . . . . . . . . . . . . . . . . 46 | B.2.1. Raw Example | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 | Authors' Addresses | |||
1. Introduction | 1. Introduction | |||
The initial regulations (e.g., [FAA-14CFR]) and standards (e.g., | The initial regulations (e.g., [FAA-14CFR]) and standards (e.g., | |||
[F3411]) for Unmanned Aircraft (UA) Systems (UAS) Remote | [F3411]) for Unmanned Aircraft Systems (UAS) Remote Identification | |||
Identification and tracking (RID) do not address trust. However, | (RID) and tracking do not address trust. However, this is a | |||
this is a requirement that needs to be addressed for various | requirement that needs to be addressed for various different parties | |||
different parties that have a stake in the safe operation of National | that have a stake in the safe operation of National Airspace Systems | |||
Airspace Systems (NAS). Drone Remote ID Protocol's (DRIP's) goal is | (NAS). Drone Remote ID Protocol's (DRIP's) goal is to specify how | |||
to specify how RID can be made trustworthy and available in both | RID can be made trustworthy and available in both Internet and local- | |||
Internet and local-only connected scenarios, especially in emergency | only connected scenarios, especially in emergency situations. | |||
situations. | ||||
UAS often operate in a volatile environment. Small UA offer little | UAS often operate in a volatile environment. A small Unmanned | |||
capacity for computation and communication. UAS RID must also be | Aircraft (UA) offers little capacity for computation and | |||
accessible with ubiquitous and inexpensive devices without | communication. UAS RID must also be accessible with ubiquitous and | |||
modification. This limits options. Most current small UAS are IoT | inexpensive devices without modification. This limits options. Most | |||
devices even if not typically thought of as such. Thus many IoT | current small UAS are Internet of Things (IoT) devices even if they | |||
considerations apply here. Some DRIP work, currently strongly scoped | are not typically thought of as such. Thus many IoT considerations | |||
to UAS RID, is likely to be applicable to some other IoT use-cases. | apply here. Some DRIP work, currently strongly scoped to UAS RID, is | |||
likely to be applicable to some other IoT use cases. | ||||
Generally, two communication schemes for UAS RID are considered: | Generally, two communication schemes for UAS RID are considered: | |||
Broadcast and Network. This document focuses on adding trust to | Broadcast and Network. This document focuses on adding trust to | |||
Broadcast RID (Section 3.2 of [RFC9153] and Section 1.2.2 of | Broadcast RID (Section 3.2 of [RFC9153] and Section 1.2.2 of | |||
[RFC9434]). As defined in [F3411] and outlined in [RFC9153] and | [RFC9434]). As defined in [F3411] and outlined in [RFC9153] and | |||
[RFC9434], Broadcast RID is a one-way RF transmission of MAC layer | [RFC9434], Broadcast RID is a one-way Radio Frequency (RF) | |||
messages over Bluetooth or Wi-Fi. | transmission of Media Access Control (MAC) layer messages over | |||
Bluetooth or Wi-Fi. | ||||
Senders can make any claims the RID message formats allow. Observers | Senders can make any claims the RID message formats allow. Observers | |||
have no standardized means to assess the trustworthiness of message | have no standardized means to assess the trustworthiness of message | |||
content, nor verify whether the messages were sent by the UA | content, nor verify whether the messages were sent by the UA | |||
identified therein, nor confirm that the UA identified therein is the | identified therein, nor confirm that the UA identified therein is the | |||
one they are visually observing. Indeed, Observers have no way to | one they are visually observing. Indeed, Observers have no way to | |||
detect whether the messages were sent by a UA, or spoofed by some | detect whether the messages were sent by a UA or spoofed by some | |||
other transmitter (e.g., a laptop or smartphone) anywhere in direct | other transmitter (e.g., a laptop or smartphone) anywhere in direct | |||
wireless broadcast range. Authentication is the primary strategy for | wireless broadcast range. Authentication is the primary strategy for | |||
mitigating this issue. | mitigating this issue. | |||
1.1. DRIP Entity Tag (DET) Authentication Goals for Broadcast RID | 1.1. DRIP Entity Tag (DET) Authentication Goals for Broadcast RID | |||
ASTM [F3411] Authentication Messages (Message Type 0x2), when used | ASTM [F3411] Authentication Messages (Message Type 0x2), when used | |||
with DRIP Entity Tag (DET) [RFC9374] based formats, enable a high | with DET-based formats [RFC9374], enable a high level of trust that | |||
level of trust that the content of other ASTM Messages was generated | the content of other ASTM Messages was generated by their claimed | |||
by their claimed registered source. These messages are designed to | registered source. These messages are designed to provide the | |||
provide the Observers with trustworthy and immediately actionable | Observers with trustworthy and immediately actionable information. | |||
information. Appendix A provides a high-level overview of the | Appendix A provides a high-level overview of the various states of | |||
various states of trustworthiness that may be used along with these | trustworthiness that may be used along with these formats. | |||
formats. | ||||
This authentication approach also provides some error correction | This authentication approach also provides some error correction | |||
(Section 5) as mandated by the United States (US) Federal Aviation | (Section 5) as mandated by the United States (US) Federal Aviation | |||
Administration (FAA) [FAA-14CFR], which is missing from [F3411] over | Administration (FAA) [FAA-14CFR], which is missing from [F3411] over | |||
Legacy Transports (Bluetooth 4.x). | Legacy Transports (Bluetooth 4.x). | |||
These DRIP enhancements to ASTM's [F3411] further support the | These DRIP enhancements to ASTM's specification for RID and tracking | |||
important use case of Observers who may be offline at the time of | [F3411] further support the important use case of Observers who may | |||
observation. | be offline at the time of observation. | |||
A summary of DRIP requirements [RFC9153] addressed herein is provided | Section 7 summarizes the DRIP requirements [RFC9153] addressed | |||
in Section 7. | herein. | |||
Note: The Endorsement (used in Section 4.2) that proves that a DET | Note: The Endorsement (used in Section 4.2) that proves that a DET is | |||
is registered MUST come from its immediate parent in the | registered MUST come from its immediate parent in the registration | |||
registration hierarchy, e.g., a DRIP Identity Management Entity | hierarchy, e.g., a DRIP Identity Management Entity (DIME) [DRIP-REG]. | |||
(DIME) [drip-registries]. In the definitive hierarchy, the parent | In the definitive hierarchy, the parent of the UA is its HHIT Domain | |||
of the UA is its HHIT Domain Authority (HDA), the parent of an HDA | Authority (HDA), the parent of an HDA is its Registered Assigning | |||
is its Registered Assigning Authority (RAA), etc. It is also | Authority (RAA), etc. It is also assumed that all DRIP-aware | |||
assumed that all DRIP-aware entities use a DET as their identifier | entities use a DET as their identifier during interactions with other | |||
during interactions with other DRIP-aware entities. | DRIP-aware entities. | |||
2. Terminology | 2. Terminology | |||
2.1. Required Terminology | 2.1. Required Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
2.2. Definitions | 2.2. Definitions | |||
This document makes use of the terms (CAA, Observer, USS, UTM, etc.) | This document makes use of the terms (CAA, Observer, USS, UTM, etc.) | |||
defined in [RFC9153]. Other terms (such as DIME) are from [RFC9434], | defined in [RFC9153]. Other terms (such as DIME) are from [RFC9434], | |||
while others (HI, DET, RAA, HDA, etc.) are from [RFC9374]. | while others (HI, DET, RAA, HDA, etc.) are from [RFC9374]. | |||
In addition, the following terms are defined for this document: | In addition, the following terms are defined for this document: | |||
Extended Transports: | Extended Transports: Use of extended advertisements (Bluetooth 5.x), | |||
service info (Wi-Fi Neighbor Awareness Networking (NAN)), or IEEE | ||||
Use of extended advertisements (Bluetooth 5.x), service info (Wi- | 802.11 Beacons with the vendor-specific information element as | |||
Fi Neighbor Awareness Networking (NAN)), or IEEE 802.11 Beacons | specified in [F3411]. Must use ASTM Message Pack (Message Type | |||
with vendor specific information element as specified in [F3411]. | 0xF). | |||
Must use ASTM Message Pack (Message Type 0xF). | ||||
Legacy Transports: | ||||
Use of broadcast frames (Bluetooth 4.x) as specified in [F3411]. | Legacy Transports: Use of broadcast frames (Bluetooth 4.x) as | |||
specified in [F3411]. | ||||
Manifest: | Manifest: An immutable list of items being transported (in this | |||
specific case over wireless communication). | ||||
an immutable list of items being transported (in this specific | 3. UAS RID Authentication Background and Procedures | |||
case over wireless communication). | ||||
3. UAS RID Authentication Background & Procedures | ||||
3.1. DRIP Authentication Protocol Description | 3.1. DRIP Authentication Protocol Description | |||
[F3411] defines Authentication Message framing only. It does not | [F3411] defines Authentication Message framing only. It does not | |||
define authentication formats or methods. It explicitly anticipates | define authentication formats or methods. It explicitly anticipates | |||
several signature options but does not fully define those. Annex A1 | several signature options but does not fully define those. Annex A1 | |||
of [F3411] defines a Broadcast Authentication Verifier Service, which | of [F3411] defines a Broadcast Authentication Verifier Service, which | |||
has a heavy reliance on Observer real-time connectivity to the | has a heavy reliance on Observer real-time connectivity to the | |||
Internet. Fortunately, [F3411] also allows third party standard | Internet. Fortunately, [F3411] also allows third-party standard | |||
Authentication Types using Type 5 Specific Authentication Method | Authentication Types using the Type 5 Specific Authentication Method | |||
(SAM), several of which DRIP defines herein. | (SAM), several of which DRIP defines herein. | |||
The standardization of specific formats to support the DRIP | The standardization of specific formats to support the DRIP | |||
requirements in UAS RID for trustworthy communications over Broadcast | requirements in UAS RID for trustworthy communications over Broadcast | |||
RID is an important part of the chain of trust for a UAS ID. Per | RID is an important part of the chain of trust for a UAS ID. Per | |||
Section 5 of [RFC9434], Authentication formats are needed to relay | Section 5 of [RFC9434], Authentication formats are needed to relay | |||
information for Observers to determine trust. No existing formats | information for Observers to determine trust. No existing formats | |||
(defined in [F3411] or other organizations leveraging this feature) | (defined in [F3411] or other organizations leveraging this feature) | |||
provide the functionality to satisfy this goal resulting in the work | provide functionality to satisfy this goal, resulting in the work | |||
reflected in this document. | reflected in this document. | |||
3.1.1. Usage of DNS | 3.1.1. Usage of DNS | |||
Like most aviation matters, the overall objectives here are security | Like most aviation matters, the overall objectives here are security | |||
and ultimately safety oriented. Since DRIP depends on DNS for some | and ultimately safety oriented. Since DRIP depends on DNS for some | |||
of its functions, DRIP usage of DNS needs to be protected as per best | of its functions, DRIP usage of DNS needs to be protected per best | |||
security practices. Many participating nodes will have limited local | security practices. Many participating nodes will have limited local | |||
processing power and/or poor, low bandwidth QoS paths. Appropriate | processing power and/or poor, low-bandwidth QoS paths. Appropriate | |||
and feasible security techniques will be highly UAS and Observer | and feasible security techniques will be highly dependent on the UAS | |||
situation dependent. Therefore specification of particular DNS | and Observer situation. Therefore, specification of particular DNS | |||
security options, transports, etc. is outside the scope of this | security options, transports, etc. is outside the scope of this | |||
document (see also Section 9.4). | document (see also Section 9.4). | |||
In DRIP Observers MUST validate all signatures received. This | In DRIP, Observers MUST validate all signatures received. This | |||
requires the Host Identity (HI) corresponding to a DET [RFC9374]. | requires that the Host Identity (HI) correspond to a DET [RFC9374]. | |||
HI's MAY be retrieved from a local cache, if present. The local | HI's MAY be retrieved from a local cache, if present. The local | |||
cache is pre-configured with well knowns HIs (such as those of CAA | cache is pre-configured with well-known HIs (such as those of CAA | |||
DIMEs) and further populated by received Broadcast Endorsements (BEs) | DIMEs) and is further populated by received Broadcast Endorsements | |||
(Section 3.1.2.1) and DNS lookups (when available). | (BEs) (Section 3.1.2.1) and DNS lookups (when available). | |||
The Observer MUST perform a DNS query, when connectivity allows, to | The Observer MUST perform a DNS query, when connectivity allows, to | |||
obtain an HI not previously known. If a query can not be performed, | obtain a previously unknown HI. If a query cannot be performed, the | |||
the message SHOULD be cached by the Observer to be validated once the | message SHOULD be cached by the Observer to be validated once the HI | |||
HI is obtained. | is obtained. | |||
A more comprehensive specification of DRIP's use of DNS is out of | A more comprehensive specification of DRIP's use of DNS is out of | |||
scope for this document and can be found in [drip-registries]. | scope for this document and can be found in [DRIP-REG]. | |||
3.1.2. Providing UAS RID Trust | 3.1.2. Providing UAS RID Trust | |||
For DRIP, two actions together provide a mechanism for an Observer to | For DRIP, two actions together provide a mechanism for an Observer to | |||
trust in UAS RID using Authentication Messages. | trust in UAS RID using Authentication Messages. | |||
First is the transmission of an entire trust chain via Broadcast | First is the transmission of an entire trust chain via Broadcast | |||
Endorsements (Section 3.1.2.1). This provides a hierarchy of DIMEs | Endorsements (Section 3.1.2.1). This provides a hierarchy of DIMEs | |||
down to and including an individual UA's registration of a claimed | down to and including an individual UA's registration of a claimed | |||
DET and corresponding HI (public key). This alone cannot be trusted | DET and corresponding HI (public key). This alone cannot be trusted | |||
as having any relevance to the observed UA because replay attacks are | as having any relevance to the observed UA because replay attacks are | |||
trivial. | trivial. | |||
After an Observer has gathered such a complete key trust chain (from | After an Observer has gathered such a complete key trust chain (from | |||
pre-configured cache entries, Broadcast Endorsements received over | pre-configured cache entries, Broadcast Endorsements received over | |||
the air and/or DNS lookups) and verified all of its links, that | the air and/or DNS lookups) and verified all of its links, that | |||
device can trust that claimed DET and corresponding public key are | device can trust that the claimed DET and corresponding public key | |||
properly registered, but the UA has not yet been proven to possess | are properly registered, but the UA has not yet been proven to | |||
the corresponding private key. | possess the corresponding private key. | |||
It is necessary for the UA to prove possession by dynamically signing | It is necessary for the UA to prove possession by dynamically signing | |||
data that is unique and unpredictable but easily verified by the | data that is unique and unpredictable but easily verified by the | |||
Observer (Section 3.1.2.2). Verification of this signed data MUST be | Observer (Section 3.1.2.2). Verification of this signed data MUST be | |||
performed by the Observer as part of the received UAS RID information | performed by the Observer as part of the received UAS RID information | |||
trust assessment (Section 6.4.2). | trust assessment (Section 6.4.2). | |||
3.1.2.1. DIME Endorsements of Subordinate DETs | 3.1.2.1. DIME Endorsements of Subordinate DETs | |||
Observers receive DRIP Link Authentication Messages (Section 4.2) | Observers receive DRIP Link Authentication Messages (Section 4.2) | |||
containing Broadcast Endorsements by DIMEs of child DET | containing Broadcast Endorsements by DIMEs of child DET | |||
registrations. A series of these Endorsements confirms a path | registrations. A series of these Endorsements confirms a path | |||
through the hierarchy, defined in [drip-registries], from the DET | through the hierarchy, defined in [DRIP-REG], from the DET Prefix | |||
Prefix Owner all the way to an individual UA DET registration. | Owner all the way to an individual UA DET registration. | |||
Note: For the remainder of this document Broadcast Endorsement: | Note: For the remainder of this document, Broadcast Endorsement: | |||
Parent, Child will be abbreviated to BE: Parent, Child. For | Parent, Child will be abbreviated as BE: Parent, Child. For example, | |||
example Broadcast Endorsement: RAA, HDA will be abbreviated to BE: | Broadcast Endorsement: RAA, HDA will be abbreviated as BE: RAA, HDA. | |||
RAA, HDA. | ||||
3.1.2.2. UA Signed Evidence | 3.1.2.2. UA Signed Evidence | |||
To prove possession of the private key associated to the DET, the UA | To prove possession of the private key associated with the DET, the | |||
MUST send data that is unique and unpredictable but easily validated | UA MUST send data that is unique and unpredictable but easily | |||
by the Observer, that is signed over. The data can be an ASTM | validated by the Observer, that is signed over. The data can be an | |||
Message that fulfills the requirements to be unpredictable but easily | ASTM Message that fulfills the requirements to be unpredictable but | |||
validated. An Observer receives this UA-signed Evidence from DRIP- | easily validated. An Observer receives this UA signed Evidence from | |||
based Authentication Messages (Section 4.3 or Section 4.4). | DRIP-based Authentication Messages (Sections 4.3 or 4.4). | |||
Whether the content is true is a separate question which DRIP cannot | Whether the content is true is a separate question that DRIP cannot | |||
address, but validation performed using observable and/or out of band | address, but validation performed using observable and/or out-of-band | |||
data (Section 6) are possible and encouraged. | data (Section 6) is possible and encouraged. | |||
3.2. ASTM Authentication Message Framing | 3.2. ASTM Authentication Message Framing | |||
The Authentication Message (Message Type 0x2) is unique in the ASTM | The Authentication Message (Message Type 0x2) is unique in the ASTM | |||
[F3411] Broadcast standard as it is the only message that can be | [F3411] Broadcast standard, as it is the only message that can be | |||
larger than the Legacy Transport size. To address this limitation | larger than the Legacy Transport size. To address this limitation | |||
around transport size, it is defined as a set of "pages", each of | around transport size, it is defined as a set of "pages", each of | |||
which fits into a single Legacy Transport frame. For Extended | which fits into a single Legacy Transport frame. For Extended | |||
Transports, pages are still used but all are in a single frame. | Transports, pages are still used but they are all in a single frame. | |||
Informational Note: Message Pack (Message Type 0xF) is also larger | Informational Note: Message Pack (Message Type 0xF) is also larger | |||
than the Legacy Transport size but is limited for use only on | than the Legacy Transport size but is limited for use only on | |||
Extended Transports where is can be supported. | Extended Transports where is can be supported. | |||
The following sub-sections are a brief overview of the Authentication | The following subsections are a brief overview of the Authentication | |||
Message format defined in [F3411] for better context on how DRIP | Message format defined in [F3411] for better context on how DRIP | |||
Authentication fills and uses various fields already defined by ASTM | Authentication fills and uses various fields already defined by ASTM | |||
[F3411]. | [F3411]. | |||
3.2.1. Authentication Page | 3.2.1. Authentication Page | |||
This document leverages Authentication Type 0x5, Specific | This document leverages Authentication Type 0x5 (Specific | |||
Authentication Method (SAM), as the principal authentication | Authentication Method (SAM)) as the principal authentication | |||
container, defining a set of SAM Types in Section 4. Authentication | container, defining a set of SAM Types in Section 4. Authentication | |||
Type is encoded in every Authentication Page in the Page Header. The | Type is encoded in every Authentication Page in the Page Header. The | |||
SAM Type is defined as a field in the Authentication Payload (see | SAM Type is defined as a field in the Authentication Payload (see | |||
Section 3.2.3.1). | Section 3.2.3.1). | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| Page Header | | | | Page Header | | | |||
+---------------+ | | +---------------+ | | |||
| | | | | | |||
| | | | | | |||
| Authentication Payload | | | Authentication Payload | | |||
| | | | | | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 1: Standard ASTM Authentication Message Page | Figure 1: Standard ASTM Authentication Message Page | |||
Page Header: (1 octet) | Page Header: (1 octet) | |||
Authentication Type (4 bits) and Page Number (4 bits) | Authentication Type (4 bits) and Page Number (4 bits) | |||
Authentication Payload: (23 octets per page) | Authentication Payload: (23 octets per page) | |||
Authentication Payload, including headers. Null padded. See | Authentication Payload, including headers. Null padded. See | |||
Section 3.2.2. | Section 3.2.2. | |||
The Authentication Message is structured as a set of pages per | The Authentication Message is structured as a set of pages per | |||
Figure 1. There is a technical maximum of 16 pages (indexed 0 to 15) | Figure 1. There is a technical maximum of 16 pages (indexed 0 to 15) | |||
that can be sent for a single Authentication Message, with each page | that can be sent for a single Authentication Message, with each page | |||
carrying a maximum 23 octet Authentication Payload. See | carrying a maximum 23-octet Authentication Payload. See | |||
Section 3.2.4 for more details. Over Legacy Transports, these | Section 3.2.4 for more details. Over Legacy Transports, these | |||
messages are "fragmented", with each page sent in a separate Legacy | messages are "fragmented", with each page sent in a separate Legacy | |||
Transport frame. | Transport frame. | |||
Either as a single Authentication Message or a set of fragmented | Either as a single Authentication Message or a set of fragmented | |||
Authentication Message Pages, the structure is further wrapped by | Authentication Message Pages, the structure is further wrapped by | |||
outer ASTM framing and the specific link framing. | outer ASTM framing and the specific link framing. | |||
3.2.2. Authentication Payload Field | 3.2.2. Authentication Payload Field | |||
Figure 2 is the source data view of the data fields found in the | Figure 2 is the source data view of the data fields found in the | |||
Authentication Message as defined by [F3411]. This data is placed | Authentication Message as defined by [F3411]. This data is placed | |||
into Figure 1's Authentication Payload, spanning multiple | into the Authentication Payload shown in Figure 1, which spans | |||
Authentication Pages. | multiple Authentication Pages. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| Authentication Headers | | | Authentication Headers | | |||
| +---------------+---------------+ | | +---------------+---------------+ | |||
| | | | | | | | |||
+---------------+---------------+ | | +---------------+---------------+ | | |||
. . | . . | |||
. Authentication Data / Signature . | . Authentication Data / Signature . | |||
skipping to change at page 9, line 51 ¶ | skipping to change at line 411 ¶ | |||
| ADL | | | | ADL | | | |||
+---------------+ | | +---------------+ | | |||
. . | . . | |||
. Additional Data . | . Additional Data . | |||
. . | . . | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 2: ASTM Authentication Message Fields | Figure 2: ASTM Authentication Message Fields | |||
Authentication Headers: (6 octets) | Authentication Headers: (6 octets) | |||
As defined in [F3411]. | As defined in [F3411]. | |||
Authentication Data / Signature: (0 to 255 octets) | Authentication Data / Signature: (0 to 255 octets) | |||
Opaque authentication data. The length of this payload is known | Opaque authentication data. The length of this payload is known | |||
through a field in the Authentication Headers (defined in | through a field in the Authentication Headers (defined in | |||
[F3411]). | [F3411]). | |||
Additional Data Length (ADL): (1 octet - unsigned) | Additional Data Length (ADL): (1 octet - unsigned) | |||
Length in octets of Additional Data. The value of ADL is | Length in octets of Additional Data. The value of ADL is | |||
calculated as the minimum of 361 - Authentication Data / Signature | calculated as the minimum of 361 - Authentication Data / Signature | |||
Length and 255. Only present with Additional Data. | Length and 255. Only present with Additional Data. | |||
Additional Data: (ADL octets) | Additional Data: (ADL octets) | |||
Data that follows the Authentication Data / Signature but is not | Data that follows the Authentication Data / Signature but is not | |||
considered part of the Authentication Data thus is not covered by | considered part of the Authentication Data, and thus is not | |||
a signature. For DRIP, this field is used to carry Forward Error | covered by a signature. For DRIP, this field is used to carry | |||
Correction (FEC) generated by transmitters and parsed by receivers | Forward Error Correction (FEC) generated by transmitters and | |||
as defined in Section 5. | parsed by receivers as defined in Section 5. | |||
3.2.3. Specific Authentication Method (SAM) | 3.2.3. Specific Authentication Method (SAM) | |||
3.2.3.1. SAM Data Format | 3.2.3.1. SAM Data Format | |||
Figure 3 is the general format to hold authentication data when using | Figure 3 is the general format to hold authentication data when using | |||
SAM and is placed inside the Authentication Data/Signature field in | SAM and is placed inside the Authentication Data / Signature field in | |||
Figure 2. | Figure 2. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| SAM Type | | | | SAM Type | | | |||
+---------------+ | | +---------------+ | | |||
. . | . . | |||
. SAM Authentication Data . | . SAM Authentication Data . | |||
. . | . . | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 3: SAM Data Format | Figure 3: SAM Data Format | |||
SAM Type: (1 octet) | SAM Type: (1 octet) | |||
The following SAM Types are allocated to DRIP: | The following SAM Types are allocated to DRIP: | |||
+==========+=============================+ | +==========+=============================+ | |||
| SAM Type | Description | | | SAM Type | Description | | |||
+==========+=============================+ | +==========+=============================+ | |||
| 0x01 | DRIP Link (Section 4.2) | | | 0x01 | DRIP Link (Section 4.2) | | |||
+----------+-----------------------------+ | +----------+-----------------------------+ | |||
| 0x02 | DRIP Wrapper (Section 4.3) | | | 0x02 | DRIP Wrapper (Section 4.3) | | |||
+----------+-----------------------------+ | +----------+-----------------------------+ | |||
| 0x03 | DRIP Manifest (Section 4.4) | | | 0x03 | DRIP Manifest (Section 4.4) | | |||
+----------+-----------------------------+ | +----------+-----------------------------+ | |||
| 0x04 | DRIP Frame (Section 4.5) | | | 0x04 | DRIP Frame (Section 4.5) | | |||
+----------+-----------------------------+ | +----------+-----------------------------+ | |||
Table 1: DRIP SAM Types | Table 1: DRIP SAM Types | |||
Note: ASTM International is the owner of these code points as they | Note: ASTM International is the owner of these code points as they | |||
are defined in [F3411]. In accordance with Annex 5 of the ASTM's | are defined in [F3411]. In accordance with Annex 5 of [F3411], the | |||
[F3411], the International Civil Aviation Organization (ICAO) has | International Civil Aviation Organization (ICAO) has been selected by | |||
been selected by ASTM as the registrar to manage allocations of | ASTM as the registrar to manage allocations of these code points. | |||
these code points. The list of which can be found at | The list is available at [ASTM-Remote-ID]. | |||
[ASTM-Remote-ID]. | ||||
SAM Authentication Data: (0 to 200 octets) | SAM Authentication Data: (0 to 200 octets) | |||
Contains opaque authentication data formatted as defined by the | Contains opaque authentication data formatted as defined by the | |||
preceding SAM Type. | preceding SAM Type. | |||
3.2.4. ASTM Broadcast RID Constraints | 3.2.4. ASTM Broadcast RID Constraints | |||
3.2.4.1. Wireless Frame Constraints | 3.2.4.1. Wireless Frame Constraints | |||
A UA has the option of broadcasting using Bluetooth (4.x and 5.x), | A UA has the option to broadcast using Bluetooth (4.x and 5.x), Wi-Fi | |||
Wi-Fi NAN, or IEEE 802.11 Beacon, see Section 6. With Bluetooth, FAA | NAN, or IEEE 802.11 Beacon; see Section 6. With Bluetooth, FAA and | |||
and other Civil Aviation Authorities (CAA) mandate transmitting | other Civil Aviation Authorities (CAA) mandate transmitting | |||
simultaneously over both 4.x and 5.x. The same application layer | simultaneously over both 4.x and 5.x. The same application-layer | |||
information defined in [F3411] MUST be transmitted over all the | information defined in [F3411] MUST be transmitted over all the | |||
physical layer interfaces performing the function of RID. This is | physical-layer interfaces performing RID, because Observer transports | |||
because Observer transports may be limited. If an Observer can | may be limited. If an Observer can support multiple transports, it | |||
support multiple transports it should be assumed to use the latest | should be assumed to use the latest data regardless of the transport | |||
data regardless of the transport received over. | received over. | |||
Bluetooth 4.x presents a payload size challenge in that it can only | Bluetooth 4.x presents a payload-size challenge in that it can only | |||
transmit 25 octets of payload per frame while other transports can | transmit 25 octets of payload per frame, while other transports can | |||
support larger payloads per frame. However, the [F3411] messaging | support larger payloads per frame. However, the [F3411] message | |||
framing dictated by Bluetooth 4.x constraints is inherited by [F3411] | framing dictated by Bluetooth 4.x constraints is inherited by [F3411] | |||
over other media. | over other media. | |||
It should be noted that Extended Transports by definition have Error | It should be noted that Extended Transports by definition have Error | |||
Correction built in, unlike Legacy Transports. For Authentication | Correction built in, unlike Legacy Transports. For Authentication | |||
Messages this means that over Legacy Transport pages could be not | Messages, this means that over Legacy Transport pages may not | |||
received by Observers resulting in incomplete messages during | received by Observers resulting in incomplete messages during | |||
operation, although the use of DRIP FEC (Section 5) reduces the | operation, although the use of DRIP FEC (Section 5) reduces its | |||
likelihood of this. Authentication Messages sent using Extended | likelihood. Authentication Messages sent using Extended Transports | |||
Transports do not suffer this issue as the full message (all pages) | do not suffer this issue, as the full message (all pages) is sent | |||
are sent using a single Message Pack. Furthermore the use of one-way | using a single Message Pack. Furthermore, the use of one-way RF | |||
RF broadcasts prohibits the use of any congestion control or loss | broadcasts prohibits the use of any congestion-control or loss- | |||
recovery schemes that require ACKs or NACKs. | recovery schemes that require ACKs or NACKs. | |||
3.2.4.2. Paged Authentication Message Constraints | 3.2.4.2. Paged Authentication Message Constraints | |||
To keep consistent formatting across the different transports (Legacy | To keep consistent formatting across the different transports (Legacy | |||
and Extended) and their independent restrictions, the authentication | and Extended) and their independent restrictions, the authentication | |||
data being sent is REQUIRED to fit within the page limit that the | data being sent is REQUIRED to fit within the page limit that the | |||
most constrained existing transport can support. Under Broadcast | most constrained existing transport can support. Under Broadcast | |||
RID, the Extended Transport that can hold the least amount of | RID, the Extended Transport that can hold the least amount of | |||
authentication data is Bluetooth 5.x at 9 pages. | authentication data is Bluetooth 5.x at 9 pages. | |||
As such DRIP transmitters are REQUIRED to adhere to the following | As such, DRIP transmitters are REQUIRED to adhere to the following | |||
when using the Authentication Message: | when using the Authentication Message: | |||
1. Authentication Data / Signature data MUST fit in the first 9 | 1. Authentication Data / Signature data MUST fit in the first 9 | |||
pages (Page Numbers 0 through 8). | pages (Page Numbers 0 through 8). | |||
2. The Length field in the Authentication Headers (which encodes the | 2. The Length field in the Authentication Headers (which encodes the | |||
length in octets of Authentication Data / Signature only) MUST | length in octets of Authentication Data / Signature only) MUST | |||
NOT exceed the value of 201. This includes the SAM Type but | NOT exceed the value of 201. This includes the SAM Type but | |||
excludes Additional Data. | excludes Additional Data. | |||
3.2.4.3. Timestamps | 3.2.4.3. Timestamps | |||
In ASTM [F3411] timestamps are a Unix-style timestamp with an epoch | In ASTM [F3411], timestamps are a Unix-style timestamp with an epoch | |||
of 2019-01-01 00:00:00 UTC. For DRIP this format is adopted for | of 2019-01-01 00:00:00 UTC. For DRIP, this format is adopted for | |||
Authentication to keep a common time format in Broadcast payloads. | Authentication to keep a common time format in Broadcast payloads. | |||
Under DRIP there are two timestamps defined Valid Not Before (VNB) | Under DRIP, there are two timestamps defined: Valid Not Before (VNB) | |||
and Valid Not After (VNA). | and Valid Not After (VNA). | |||
Valid Not Before (VNB) Timestamp: (4 octets) | Valid Not Before (VNB) Timestamp: (4 octets) | |||
Timestamp denoting recommended time to start trusting data in. | Timestamp denoting the recommended time at which to start trusting | |||
MUST follow the format defined in [F3411] as described above. | data. MUST follow the format defined in [F3411] as described | |||
MUST be set no earlier than the time the signature (across a given | above. MUST be set no earlier than the time the signature (across | |||
structure) is generated. | a given structure) is generated. | |||
Valid Not After (VNA) Timestamp: (4 octets) | Valid Not After (VNA) Timestamp: (4 octets) | |||
Timestamp denoting recommended time to stop trusting data. MUST | ||||
follow the format defined in [F3411] as described above. Has an | Timestamp denoting the recommended time at which to stop trusting | |||
additional offset to push a short time into the future (relative | data. MUST follow the format defined in [F3411] as described | |||
to VNB) to avoid replay attacks. The exact offset is not defined | above. Has an additional offset to push a short time into the | |||
in this document. Best practice identifying an acceptable offset | future (relative to VNB) to avoid replay attacks. The exact | |||
should be used taking into consideration the UA environment, and | offset is not defined in this document. Best practice for | |||
propagation characteristics of the messages being sent, and clock | identifying an acceptable offset should be used and should take | |||
differences between the UA and Observers. A reasonable time would | into consideration the UA environment, propagation characteristics | |||
be to set VNA 2 minutes after VNB. | of the messages being sent, and clock differences between the UA | |||
and Observers. A reasonable time would be to set VNA 2 minutes | ||||
after VNB. | ||||
4. DRIP Authentication Formats | 4. DRIP Authentication Formats | |||
All formats defined in this section are the content of the | All formats defined in this section are contained in the | |||
Authentication Data / Signature field in Figure 2 and use the | Authentication Data / Signature field in Figure 2 and use the | |||
Specific Authentication Method (SAM, Authentication Type 0x5). The | Specific Authentication Method (SAM, Authentication Type 0x5). The | |||
first octet of the Authentication Data / Signature of Figure 2 is | first octet of the Authentication Data / Signature of Figure 2 is | |||
used to multiplex among these various formats. | used to multiplex among these various formats. | |||
When sending data over a medium that does not have underlying FEC, | When sending data over a medium that does not have underlying FEC, | |||
for example Legacy Transports, then Section 5 MUST be used. | for example Legacy Transports, then Section 5 MUST be used. | |||
Examples of Link, Wrapper and Manifest are shown as part of an | Examples of Link, Wrapper, and Manifest are shown as part of an | |||
operational schedule in Appendix B.2.1. | operational schedule in Appendix B.2.1. | |||
4.1. UA Signed Evidence Structure | 4.1. UA Signed Evidence Structure | |||
The UA Signed Evidence Structure (Figure 4) is used by the UA during | The UA Signed Evidence Structure (Figure 4) is used by the UA during | |||
flight to sign over information elements using the private key | flight to sign over information elements using the private key | |||
associated with the current UA DET. It is encapsulated by the SAM | associated with the current UA DET. It is encapsulated by the SAM | |||
Authentication Data field of Figure 3. | Authentication Data field of Figure 3. | |||
This structure is used by the DRIP Wrapper (Section 4.3), Manifest | This structure is used by the DRIP Wrapper (Section 4.3), Manifest | |||
Section 4.4, and Frame (Section 4.5). DRIP Link (Section 4.2) MUST | Section 4.4), and Frame (Section 4.5). DRIP Link (Section 4.2) MUST | |||
NOT use it as it will not fit in the ASTM Authentication Message with | NOT use it, as it will not fit in the ASTM Authentication Message | |||
its intended content (i.e., a Broadcast Endorsement). | with its intended content (i.e., a Broadcast Endorsement). | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| VNB Timestamp by UA | | | VNB Timestamp by UA | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| VNA Timestamp by UA | | | VNA Timestamp by UA | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| | | | | | |||
. . | . . | |||
skipping to change at page 14, line 43 ¶ | skipping to change at line 629 ¶ | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 4: Endorsement Structure for UA Signed Evidence | Figure 4: Endorsement Structure for UA Signed Evidence | |||
Valid Not Before (VNB) Timestamp by UA: (4 octets) | Valid Not Before (VNB) Timestamp by UA: (4 octets) | |||
See Section 3.2.4.3. Set by the UA. | See Section 3.2.4.3. Set by the UA. | |||
Valid Not After (VNA) Timestamp by UA: (4 octets) | Valid Not After (VNA) Timestamp by UA: (4 octets) | |||
See Section 3.2.4.3. Set by the UA. | See Section 3.2.4.3. Set by the UA. | |||
Evidence: (0 to 112 octets) | Evidence: (0 to 112 octets) | |||
The evidence section MUST be filled in with data in the form of an | ||||
The evidence section MUST filled in with data in the form of an | ||||
opaque object specified in the DRIP Wrapper (Section 4.3), | opaque object specified in the DRIP Wrapper (Section 4.3), | |||
Manifest (Section 4.4), or Frame (Section 4.5). | Manifest (Section 4.4), or Frame (Section 4.5). | |||
UA DRIP Entity Tag: (16 octets) | UA DRIP Entity Tag: (16 octets) | |||
This is the current DET [RFC9374] being used by the UA assumed to | This is the current DET [RFC9374] being used by the UA assumed to | |||
be a Specific Session ID (a type of UAS ID). | be a Specific Session ID (a type of UAS ID). | |||
UA Signature: (64 octets) | UA Signature: (64 octets) | |||
Signature over concatenation of preceding fields (VNB, VNA, | Signature over concatenation of preceding fields (VNB, VNA, | |||
Evidence, and UA DET) using the keypair of the UA DET. The | Evidence, and UA DET) using the keypair of the UA DET. The | |||
signature algorithm is specified by the HHIT Suite ID of the DET. | signature algorithm is specified by the Hierarchical Host Identity | |||
Tags (HHIT) Suite ID of the DET. | ||||
When using this structure, the UA is minimally self-endorsing its | When using this structure, the UA is minimally self-endorsing its | |||
DET. The HI of the UA DET can be looked up by mechanisms described | DET. The HI of the UA DET can be looked up by mechanisms described | |||
in [drip-registries] or by extracting it from a Broadcast Endorsement | in [DRIP-REG] or by extracting it from a Broadcast Endorsement (see | |||
(see Section 4.2 and Section 6.3). | Sections 4.2 and 6.3). | |||
4.2. DRIP Link | 4.2. DRIP Link | |||
This SAM Type is used to transmit Broadcast Endorsements. For | This SAM Type is used to transmit Broadcast Endorsements. For | |||
example, the BE: HDA, UA is sent (see Section 6.3) as a DRIP Link | example, the BE: HDA, UA is sent (see Section 6.3) as a DRIP Link | |||
message. | message. | |||
DRIP Link is important as its contents are used to provide trust in | DRIP Link is important as its contents are used to provide trust in | |||
the DET/HI pair that the UA is currently broadcasting. This message | the DET/HI pair that the UA is currently broadcasting. This message | |||
does not require Internet connectivity to perform signature | does not require Internet connectivity to perform signature | |||
skipping to change at page 16, line 51 ¶ | skipping to change at line 724 ¶ | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 5: Broadcast Endorsement / DRIP Link | Figure 5: Broadcast Endorsement / DRIP Link | |||
VNB Timestamp by Parent: (4 octets) | VNB Timestamp by Parent: (4 octets) | |||
See Section 3.2.4.3. Set by Parent Entity. | See Section 3.2.4.3. Set by Parent Entity. | |||
VNA Timestamp by Parent: (4 octets) | VNA Timestamp by Parent: (4 octets) | |||
See Section 3.2.4.3. Set by Parent Entity. | See Section 3.2.4.3. Set by Parent Entity. | |||
DET of Child: (16 octets) | DET of Child: (16 octets) | |||
DRIP Entity Tag of Child Entity. | DRIP Entity Tag of Child Entity. | |||
HI of Child: (32 octets) | HI of Child: (32 octets) | |||
Host Identity of Child Entity. | Host Identity of Child Entity. | |||
DET of Parent: (16 octets) | DET of Parent: (16 octets) | |||
DRIP Entity Tag of Parent Entity in DIME Hierarchy. | DRIP Entity Tag of Parent Entity in DIME Hierarchy. | |||
Signature by Parent: (64 octets) | Signature by Parent: (64 octets) | |||
Signature over concatenation of preceding fields (VNB, VNA, DET of | Signature over concatenation of preceding fields (VNB, VNA, DET of | |||
Child, HI of Child, and DET of Parent) using the keypair of the | Child, HI of Child, and DET of Parent) using the keypair of the | |||
Parent DET. | Parent DET. | |||
This DRIP Authentication Message is used in conjunction with other | This DRIP Authentication Message is used in conjunction with other | |||
DRIP SAM Types (such as the Manifest or the Wrapper) that contain | DRIP SAM Types (such as the Manifest or the Wrapper) that contain | |||
data (e.g., the ASTM Location/Vector Message, Message Type 0x2) that | data (e.g., the ASTM Location/Vector Message, Message Type 0x2) that | |||
is guaranteed to be unique, unpredictable, and easily cross-checked | is guaranteed to be unique, unpredictable, and easily cross-checked | |||
by the receiving device. | by the receiving device. | |||
A hash of the final link (BE: HDA on UA) in the Broadcast Endorsement | A hash of the final link (BE: HDA on UA) in the Broadcast Endorsement | |||
chain MUST be included in each DRIP Manifest Section 4.4. | chain MUST be included in each DRIP Manifest (Section 4.4). | |||
4.3. DRIP Wrapper | 4.3. DRIP Wrapper | |||
This SAM Type is used to wrap and sign over a list of other [F3411] | This SAM Type is used to wrap and sign over a list of other [F3411] | |||
Broadcast RID messages. | Broadcast RID messages. | |||
The evidence section of the UA Signed Evidence Structure | The evidence section of the UA Signed Evidence Structure | |||
(Section 4.1) is populated with up to four ASTM [F3411] Messages in a | (Section 4.1) is populated with up to four ASTM Messages [F3411] in a | |||
contiguous octet sequence. Only ASTM Message Types 0x0, 0x1, 0x3, | contiguous octet sequence. Only ASTM Message Types 0x0, 0x1, 0x3, | |||
0x4, and 0x5 are allowed and must be in Message Type order as defined | 0x4, and 0x5 are allowed and must be in Message Type order as defined | |||
by [F3411]. These messages MUST include the Message Type and | by [F3411]. These messages MUST include the Message Type and | |||
Protocol Version octet and MUST NOT include the Message Counter octet | Protocol Version octet and MUST NOT include the Message Counter octet | |||
(thus are fixed at 25 octets in length). | (thus are fixed at 25 octets in length). | |||
4.3.1. Wrapped Count & Format Validation | 4.3.1. Wrapped Count and Format Validation | |||
When decoding a DRIP Wrapper on a receiver, a calculation of the | When decoding a DRIP Wrapper on a receiver, a calculation of the | |||
number of messages wrapped and a validation MUST be performed by | number of messages wrapped and a validation MUST be performed by | |||
using the number of octets (defined as wrapperLength) between the VNA | using the number of octets (defined as wrapperLength) between the VNA | |||
Timestamp by UA and the UA DET as shown in Figure 6. | Timestamp by UA and the UA DET as shown in Figure 6. | |||
<CODE BEGINS> | <CODE BEGINS> | |||
if (wrapperLength MOD 25) != 0 { | if (wrapperLength MOD 25) != 0 { | |||
return DECODE_FAILURE; | return DECODE_FAILURE; | |||
} | } | |||
skipping to change at page 18, line 27 ¶ | skipping to change at line 794 ¶ | |||
if (wrappedCount == 0) { | if (wrappedCount == 0) { | |||
// DECODE_SUCCESS; treat as DRIP Wrapper over extended transport | // DECODE_SUCCESS; treat as DRIP Wrapper over extended transport | |||
} | } | |||
else if (wrappedCount > 4) { | else if (wrappedCount > 4) { | |||
return DECODE_FAILURE; | return DECODE_FAILURE; | |||
} else { | } else { | |||
// DECODE_SUCCESS; treat as standard DRIP Wrapper | // DECODE_SUCCESS; treat as standard DRIP Wrapper | |||
} | } | |||
<CODE ENDS> | <CODE ENDS> | |||
Figure 6: Pseudo-code for Wrapper validation and number of | Figure 6: Pseudocode for Wrapper Validation and Number of | |||
messages calculation | Messages calculation | |||
4.3.2. Wrapper over Extended Transports | 4.3.2. Wrapper over Extended Transports | |||
When using Extended Transports an optimization can be made to DRIP | When using Extended Transports, an optimization to DRIP Wrapper can | |||
Wrapper to sign over co-located data in an ASTM Message Pack (Message | be made to sign over co-located data in an ASTM Message Pack (Message | |||
Type 0xF). | Type 0xF). | |||
To perform this optimization the UA Signed Evidence Structure is | To perform this optimization, the UA Signed Evidence Structure is | |||
filled with the ASTM Messages to be in the ASTM Message Pack, the | filled with the ASTM Messages to be in the ASTM Message Pack, the | |||
signature is generated, then the evidence field is cleared leaving | signature is generated, and then the evidence field is cleared, | |||
the encoded form shown in Figure 7. | leaving the encoded form shown in Figure 7. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| VNB Timestamp by UA | | | VNB Timestamp by UA | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| VNA Timestamp by UA | | | VNA Timestamp by UA | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| | | | | | |||
| UA | | | UA | | |||
skipping to change at page 19, line 38 ¶ | skipping to change at line 841 ¶ | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 7: DRIP Wrapper over Extended Transports | Figure 7: DRIP Wrapper over Extended Transports | |||
To verify the signature, the receiver MUST concatenate all the | To verify the signature, the receiver MUST concatenate all the | |||
messages in the Message Pack (excluding Authentication Message found | messages in the Message Pack (excluding the Authentication Message | |||
in the same Message Pack) in ASTM Message Type order and set the | found in the same Message Pack) in ASTM Message Type order and set | |||
evidence section of the UA Signed Evidence Structure before | the evidence section of the UA Signed Evidence Structure before | |||
performing signature verification. | performing signature verification. | |||
The functionality of a Wrapper in this form is equivalent to Message | The functionality of a Wrapper in this form is equivalent to Message | |||
Set Signature (Authentication Type 0x3) when running over Extended | Set Signature (Authentication Type 0x3) when running over Extended | |||
Transports. What the Wrapper provides is the same format but over | Transports. The Wrapper provides the same format but over both | |||
both Extended and Legacy Transports allowing the transports to be | Extended and Legacy Transports, which allows the transports to be | |||
similar. Message Set Signature also implies using the ASTM validator | similar. Message Set Signature also implies using the ASTM validator | |||
system architecture which depends on Internet connectivity for | system architecture, which depends on Internet connectivity for | |||
verification which the receiver may not have at the time of receipt | verification that the receiver may not have at the time an | |||
of an Authentication Message. This is something the Wrapper, and all | Authentication Message is received. This is something the Wrapper, | |||
DRIP Authentication Formats, avoid when the UA key is obtained via a | and all DRIP Authentication Formats, avoid when the UA key is | |||
DRIP Link Authentication Message. | obtained via a DRIP Link Authentication Message. | |||
4.3.3. Wrapper Limitations | 4.3.3. Wrapper Limitations | |||
The primary limitation of the Wrapper is the bounding of up to 4 ASTM | The primary limitation of the Wrapper is the bounding of up to four | |||
Messages that can be sent within it. Another limitation is that the | ASTM Messages that can be sent within it. Another limitation is that | |||
format cannot be used as a surrogate for messages it is wrapping due | the format cannot be used as a surrogate for messages it is wrapping | |||
to the potential that an Observer on the ground does not support | due to the potential that an Observer on the ground does not support | |||
DRIP. Thus, when a Wrapper is being used, the wrapped data must | DRIP. Thus, when a Wrapper is being used, the wrapped data must | |||
effectively be sent twice, once as a single framed message (as | effectively be sent twice, once as a single-framed message (as | |||
specified in [F3411]) and then again within the Wrapper. | specified in [F3411]) and again within the Wrapper. | |||
4.4. DRIP Manifest | 4.4. DRIP Manifest | |||
This SAM Type is used to create message manifests that contain hashes | This SAM Type is used to create message manifests that contain hashes | |||
of previously sent ASTM Messages. | of previously sent ASTM Messages. | |||
By hashing previously sent messages and signing them, we gain trust | By hashing previously sent messages and signing them, we gain trust | |||
in a UA's previous reports without re-transmitting them. This is a | in a UA's previous reports without retransmitting them. This is a | |||
way to evade the limitation of a maximum of 4 messages in the Wrapper | way to evade the limitation of a maximum of four messages in the | |||
(Section 4.3.3) and greatly reduce overhead. | Wrapper (Section 4.3.3) and greatly reduce overhead. | |||
Observers MUST hash all received ASTM Messages and cross-check them | Observers MUST hash all received ASTM Messages and cross-check them | |||
against hashes in received Manifests. | against hashes in received Manifests. | |||
Judicious use of a Manifest enables an entire Broadcast RID message | Judicious use of a Manifest enables an entire Broadcast RID message | |||
stream to be strongly authenticated with less than 100% overhead | stream to be strongly authenticated with less than 100% overhead | |||
relative to a completely unauthenticated message stream (see | relative to a completely unauthenticated message stream (see | |||
Section 6.3 and Appendix B). | Section 6.3 and Appendix B). | |||
The evidence section of the UA Signed Evidence Structure | The evidence section of the UA Signed Evidence Structure | |||
(Section 4.1) is populated with 8-octet hashes of [F3411] Broadcast | (Section 4.1) is populated with 8-octet hashes of [F3411] Broadcast | |||
RID messages (up to 11) and three special hashes (Section 4.4.2). | RID messages (up to 11) and three special hashes (Section 4.4.2). | |||
All these hashes MUST be concatenated to form a contiguous octet | All of these hashes MUST be concatenated to form a contiguous octet | |||
sequence in the evidence section. It is RECOMMENDED the max number | sequence in the evidence section. It is RECOMMENDED that the maximum | |||
of ASTM Message Hashes be used is 10 (see Appendix B.1.1.2). | number of ASTM Message Hashes used be 10 (see Appendix B.1.1.2). | |||
The Previous Manifest Hash, Current Manifest Hash, and DRIP Link (BE: | The Previous Manifest Hash, Current Manifest Hash, and DRIP Link (BE: | |||
HDA, UA) Hash MUST always come before the ASTM Message Hashes as seen | HDA, UA) Hash MUST always come before the ASTM Message Hashes as seen | |||
in Figure 8. | in Figure 8. | |||
An Observer MUST use the Manifest to verify each ASTM Message hashed | An Observer MUST use the Manifest to verify each ASTM Message hashed | |||
therein that it has previously received. It can do this without | therein that it has previously received. It can do this without | |||
having received them all. A Manifest SHOULD typically encompass a | having received them all. A Manifest SHOULD typically encompass a | |||
single transmission cycle of messages being sent, see Section 6.4 and | single transmission cycle of messages being sent; see Section 6.4 and | |||
Appendix B. | Appendix B. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| Previous Manifest | | | Previous Manifest | | |||
| Hash | | | Hash | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| Current Manifest | | | Current Manifest | | |||
| Hash | | | Hash | | |||
skipping to change at page 21, line 26 ¶ | skipping to change at line 923 ¶ | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| | | | | | |||
. . | . . | |||
. ASTM Message Hashes . | . ASTM Message Hashes . | |||
. . | . . | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 8: DRIP Manifest Evidence Structure | Figure 8: DRIP Manifest Evidence Structure | |||
Previous Manifest Hash: (8 octets) | Previous Manifest Hash: (8 octets) | |||
Hash of the previously sent Manifest Message. | Hash of the previously sent Manifest Message. | |||
Current Manifest Hash: (8 octets) | Current Manifest Hash: (8 octets) | |||
Hash of the current Manifest Message. | Hash of the current Manifest Message. | |||
DRIP Link (BE: HDA, UA): (8 octets) | DRIP Link (BE: HDA, UA): (8 octets) | |||
Hash of the DRIP Link Authentication Message carrying BE: HDA, UA | Hash of the DRIP Link Authentication Message carrying BE: HDA, UA | |||
(see Section 4.2). | (see Section 4.2). | |||
ASTM Message Hash: (8 octets) | ASTM Message Hash: (8 octets) | |||
Hash of a single full ASTM Message using hash operations described | Hash of a single full ASTM Message using hash operations described | |||
in Section 4.4.3. | in Section 4.4.3. | |||
4.4.1. Hash Count & Format Validation | 4.4.1. Hash Count and Format Validation | |||
When decoding a DRIP Manifest on a receiver, a calculation of the | When decoding a DRIP Manifest on a receiver, a calculation of the | |||
number of hashes and a validation can be performed by using the | number of hashes and a validation can be performed by using the | |||
number of octets (defined as manifestLength) between the UA DET and | number of octets between the UA DET and the VNB Timestamp by UA | |||
the VNB Timestamp by UA such as shown in Figure 9. | (defined as manifestLength) such as shown in Figure 9. | |||
<CODE BEGINS> | <CODE BEGINS> | |||
if (manifestLength MOD 8) != 0 { | if (manifestLength MOD 8) != 0 { | |||
return DECODE_FAILURE | return DECODE_FAILURE | |||
} | } | |||
hashCount = (manifestLength / 8) - 3; | hashCount = (manifestLength / 8) - 3; | |||
<CODE ENDS> | <CODE ENDS> | |||
Figure 9: Pseudo-code for Manifest Sanity Check and Number of Hashes | Figure 9: Pseudocode for Manifest Sanity Check and Number of | |||
Calculation | Hashes Calculation | |||
4.4.2. Manifest Ledger Hashes | 4.4.2. Manifest Ledger Hashes | |||
Three special hashes are included in all Manifests. The Previous | Three special hashes are included in all Manifests. The Previous | |||
Manifest Hash, links to the previous Manifest, and the Current | Manifest Hash, links to the previous Manifest, and the Current | |||
Manifest Hash is of the Manifest in which it appears. These two | Manifest Hash is of the Manifest in which it appears. These two | |||
hashes act as a ledger of provenance to the Manifest that could be | hashes act as a ledger of provenance to the Manifest that could be | |||
traced back if the Observer was present for extended periods of time. | traced back if the Observer was present for extended periods of time. | |||
The DRIP Link (BE: HDA, UA) is included so there is a direct | The DRIP Link (BE: HDA, UA) is included so there is a direct | |||
signature by the UA over the Broadcast Endorsement (see Section 4.2). | signature by the UA over the Broadcast Endorsement (see Section 4.2). | |||
Typical operation would expect that the list of ASTM Message Hash's | Typical operation would expect that the list of ASTM Message Hashes | |||
contain nonce-link data. To enforce a binding between the BE: HDA, | contain nonce-like data. To enforce a binding between the BE: HDA, | |||
UA and avoid trivial replay attack vectors (see Section 9.1) at least | UA and avoid trivial replay attack vectors (see Section 9.1), at | |||
1 ASTM Message Hash MUST be from an [F3411] message that satisfies | least one ASTM Message Hash MUST be from an [F3411] message that | |||
the 4th requirement in Section 6.3. | satisfies the fourth requirement in Section 6.3. | |||
4.4.3. Hash Algorithms and Operation | 4.4.3. Hash Algorithms and Operation | |||
The hash algorithm used for the Manifest is the same hash algorithm | The hash algorithm used for the Manifest is the same hash algorithm | |||
used in creation of the DET [RFC9374] that is signing the Manifest. | used in creation of the DET [RFC9374] that is signing the Manifest. | |||
This is encoded as part of the DET using the HHIT Suite ID. | This is encoded as part of the DET using the HHIT Suite ID. | |||
DET's using cSHAKE128 [NIST.SP.800-185] compute the hash as follows: | DETs that use cSHAKE128 [NIST.SP.800-185] compute the hash as | |||
follows: | ||||
cSHAKE128(ASTM Message, 64, "", "Remote ID Auth Hash") | cSHAKE128(ASTM Message, 64, "", "Remote ID Auth Hash") | |||
For OGAs other than "5" [RFC9374], use the construct appropriate for | For ORCHID Generation Algorithms (OGAs) other than "5" (EdDSA/ | |||
the associated hash. For example, for "2" which is ECDSA/SHA-384: | cSHAKE128) [RFC9374], use the construct appropriate for the | |||
associated hash. For example, the hash for "2" (ECDSA/SHA-384) is | ||||
computed as follows: | ||||
Ltrunc( SHA-384( ASTM Message | "Remote ID Auth Hash" ), 8 ) | ||||
Ltrunc( SHA-384( ASTM Message | "Remote ID Auth Hash" ), 8 ) | ||||
When building the list of hashes, the Previous Manifest Hash is known | When building the list of hashes, the Previous Manifest Hash is known | |||
from the previous Manifest. For the first built Manifest this value | from the previous Manifest. For the first built Manifest, this value | |||
is filled with a random nonce. The Current Manifest Hash is null | is filled with a random nonce. The Current Manifest Hash is null | |||
filled while ASTM Messages are hashed and fill the ASTM Messages | filled while ASTM Messages are hashed and fill the ASTM Messaged | |||
Hashes section. When all messages are hashed, the Current Manifest | Hashes section. When all messages are hashed, the Current Manifest | |||
Hash is computed over the Previous Manifest Hash, Current Manifest | Hash is computed over the Previous Manifest Hash, Current Manifest | |||
Hash (null filled) and ASTM Messages Hashes. This hash value | Hash (null filled), and ASTM Message Hashes. This hash value | |||
replaces the null filled Current Manifest Hash and becomes the | replaces the null-filled Current Manifest Hash and becomes the | |||
Previous Manifest Hash for the next Manifest. | Previous Manifest Hash for the next Manifest. | |||
4.4.3.1. Legacy Transport Hashing | 4.4.3.1. Legacy Transport Hashing | |||
Under this transport DRIP hashes the full ASTM Message being sent | Under this transport, DRIP hashes the full ASTM Message being sent | |||
over the Bluetooth Advertising frame. This is the 25-octet object | over the Bluetooth Advertising frame. This is the 25-octet object | |||
start with the Message Type and Protocol Version octet along with the | that starts with the Message Type and Protocol Version octet along | |||
24 octets of message data. The hash MUST NOT included the Message | with the 24 octets of message data. The hash MUST NOT include the | |||
Counter octet. | Message Counter octet. | |||
For paged ASTM Messages (currently only Authentication Messages) all | For paged ASTM Messages (currently only Authentication Messages), all | |||
the pages are concatenated together in Page Number order and hashed | of the pages are concatenated together in Page Number order and | |||
as one object. | hashed as one object. | |||
4.4.3.2. Extended Transport Hashing | 4.4.3.2. Extended Transport Hashing | |||
Under this transport DRIP hashes the full ASTM Message Pack (Message | Under this transport, DRIP hashes the full ASTM Message Pack (Message | |||
Type 0xF) regardless of its content. The hash MUST NOT included the | Type 0xF) regardless of its content. The hash MUST NOT include the | |||
Message Counter octet. | Message Counter octet. | |||
4.5. DRIP Frame | 4.5. DRIP Frame | |||
This SAM Type is defined to enable the use of Section 4.1 in the | This SAM Type is defined to enable the use of Section 4.1 in the | |||
future beyond the previously defined formats (Wrapper and Manifest) | future beyond the previously defined formats (Wrapper and Manifest) | |||
by the inclusion of a single octet to signal the format of evidence | by the inclusion of a single octet to signal the format of evidence | |||
data (up to 111 octets). | data (up to 111 octets). | |||
The content format of Frame Evidence Data is not defined in this | The content format of Frame Evidence Data is not defined in this | |||
document. Other specifications MUST define the contents and register | document. Other specifications MUST define the contents and register | |||
for a Frame Type. At the time of publication there are no defined | for a Frame Type. At the time of publication, there are no defined | |||
Frame Types other than an Experimental range. | Frame Types other than an Experimental range. | |||
Observers MUST check the signature of the structure (Section 4.1) per | Observers MUST check the signature of the structure (Section 4.1) per | |||
Section 3.1.2.2 and MAY, if the specification of Frame Type is known, | Section 3.1.2.2 and MAY, if the specification of Frame Type is known, | |||
parse the content in Frame Evidence Data. | parse the content in Frame Evidence Data. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| Frame Type | | | | Frame Type | | | |||
+---------------+ . | +---------------+ . | |||
. Frame Evidence Data . | . Frame Evidence Data . | |||
. . | . . | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 10: DRIP Frame | Figure 10: DRIP Frame | |||
Frame Type: (1 octet) | Frame Type: (1 octet) | |||
Byte to sub-type for future different DRIP Frame formats. It | Byte to subtype for future different DRIP Frame formats. It takes | |||
takes the first octet in Figure 10, leaving 111 octets available | the first octet in Figure 10, leaving 111 octets available for | |||
for Frame Evidence Data. See Section 8.1 for Frame Type | Frame Evidence Data. See Section 8.1 for Frame Type allocations. | |||
allocations. | ||||
5. Forward Error Correction | 5. Forward Error Correction | |||
For Broadcast RID, FEC is provided by the lower layers in Extended | For Broadcast RID, FEC is provided by the lower layers in Extended | |||
Transports. The Bluetooth 4.x Legacy Transport does not have | Transports. The Bluetooth 4.x Legacy Transport does not support FEC, | |||
supporting FEC, so with DRIP Authentication the following application | so the following application-level scheme is used with DRIP | |||
level scheme is used to add some FEC. When sending data over a | Authentication to add some FEC. When sending data over a medium that | |||
medium that does not have underlying FEC, for example Bluetooth 4.x, | does not have underlying FEC, for example Bluetooth 4.x, this section | |||
then this section MUST be used. | MUST be used. | |||
The Bluetooth 4.x lower layers have error detection but not | The Bluetooth 4.x lower layers have error detection but not | |||
correction. Any frame in which Bluetooth detects an error is dropped | correction. Any frame in which Bluetooth detects an error is dropped | |||
and not delivered to higher layers (in our case, DRIP). Thus it can | and not delivered to higher layers (in our case, DRIP). Thus it can | |||
be treated as an erasure. | be treated as an erasure. | |||
DRIP standardizes a single page FEC scheme using XOR parity across | DRIP standardizes a single page FEC scheme using XOR parity across | |||
all page data of an Authentication Message. This allows the | all page data of an Authentication Message. This allows the | |||
correction of single erased page in an Authentication Message. If | correction of a single erased page in an Authentication Message. If | |||
more than a single page is missing then handling of an incomplete | more than a single page is missing, then handling of an incomplete | |||
Authentication Message is determined by higher layers. | Authentication Message is determined by higher layers. | |||
Other FEC schemes, to protect more than a single page of an | Other FEC schemes, to protect more than a single page of an | |||
Authentication Message or multiple [F3411] Messages, is left for | Authentication Message or multiple [F3411] Messages, are left for | |||
future standardization if operational experience proves it necessary | future standardization if operational experience proves it necessary | |||
and/or practical. | and/or practical. | |||
The data added during FEC is not included in the Authentication Data | The data added during FEC is not included in the Authentication Data | |||
/ Signature, but instead in the Additional Data field of Figure 2. | / Signature, but instead in the Additional Data field of Figure 2. | |||
This may cause the Authentication Message to exceed 9-pages, up to a | This may cause the Authentication Message to exceed 9 pages, up to a | |||
maximum of 16-pages. | maximum of 16 pages. | |||
5.1. Encoding | 5.1. Encoding | |||
When encoding two things are REQUIRED: | When encoding, two things are REQUIRED: | |||
1. The FEC data MUST start on a new Authentication Page. To do | 1. The FEC data MUST start on a new Authentication Page. To do | |||
this, the results of parity encoding MUST be placed in the | this, the results of parity encoding MUST be placed in the | |||
Additional Data field of Figure 2 with null padding before it to | Additional Data field of Figure 2 with null padding before it to | |||
line up with the next page. The Additional Data Length field | line up with the next page. The Additional Data Length field | |||
MUST be set to number of padding octets + number of parity | MUST be set to number of padding octets + number of parity | |||
octets. | octets. | |||
2. The Last Page Index field (in Page 0) MUST be incremented from | 2. The Last Page Index field (in Page 0) MUST be incremented from | |||
what it would have been without FEC by the number of pages | what it would have been without FEC by the number of pages | |||
required for the Additional Data Length field, null padding and | required for the Additional Data Length field, null padding, and | |||
FEC. | FEC. | |||
To generate the parity, a simple XOR operation using the previous | To generate the parity, a simple XOR operation using the previous | |||
parity page and current page is used. Only the 23-octet | parity page and current page is used. Only the 23-octet | |||
Authentication Payload field of Figure 1 is used in the XOR | Authentication Payload field of Figure 1 is used in the XOR | |||
operations. For Page 0, a 23-octet null pad is used for the previous | operations. For Page 0, a 23-octet null pad is used for the previous | |||
parity page. | parity page. | |||
Figure 11 shows an example of the last two pages (out of N) of an | Figure 11 shows an example of the last two pages (out of N) of an | |||
Authentication Message using DRIP Single Page FEC. The Additional | Authentication Message using DRIP Single Page FEC. The Additional | |||
Data Length is set to 33 as there are always 23 octets of FEC data | Data Length is set to 33, as there are always 23 octets of FEC data | |||
and in this example 10 octets of padding to line it up into Page N. | and there are 10 octets of padding in this example to line it up into | |||
Page N. | ||||
Page N-1: | Page N-1: | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| Page Header | | | | Page Header | | | |||
+---------------+ | | +---------------+ | | |||
| Authentication Data / Signature | | | Authentication Data / Signature | | |||
| | | | | | |||
| +---------------+---------------+---------------+ | | +---------------+---------------+---------------+ | |||
skipping to change at page 26, line 37 ¶ | skipping to change at line 1144 ¶ | |||
| Forward Error Correction | | | Forward Error Correction | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
Figure 11: Example Single Page FEC Encoding | Figure 11: Example Single Page FEC Encoding | |||
5.2. Decoding | 5.2. Decoding | |||
Frame decoding is independent of the transmit media. However the | Frame decoding is independent of the transmit media. However, the | |||
decoding process can determine from the first Authentication page | decoding process can determine from the first Authentication page | |||
that there may be a Bluetooth 4.x FEC page at the end. The decoding | that there may be a Bluetooth 4.x FEC page at the end. The decoding | |||
process MUST test for the presence of FEC and apply it as follows. | process MUST test for the presence of FEC and apply it as follows. | |||
To determine if FEC has been used, a check of the Last Page Index is | To determine if FEC has been used, a check of the Last Page Index is | |||
performed. In general if the Last Page Index field is one greater | performed. In general, if the Last Page Index field is one greater | |||
than that necessary to hold Length octets of Authentication Data then | than that necessary to hold Length octets of Authentication Data, | |||
FEC has been used. Note that if Length octets are exhausted exactly | then FEC has been used. Note that if Length octets are exhausted | |||
at the end of an Authentication Page, the Additional Data Length | exactly at the end of an Authentication Page, the Additional Data | |||
field will occupy the first octet of the following page. The | Length field will occupy the first octet of the following page. The | |||
remainder of this page will be null padded under DRIP to align the | remainder of this page will be null padded under DRIP to align the | |||
FEC to its own page. In this case the Last Page Index will have been | FEC to its own page. In this case, the Last Page Index will have | |||
incremented once for initializing the Additional Data Length field | been incremented once for initializing the Additional Data Length | |||
and once for FEC page, for a total of two additional pages, as in the | field and once for the FEC page, for a total of two additional pages, | |||
last row of Table 5. | as in the last row of Table 5. | |||
To decode FEC in DRIP, a rolling XOR is used on each Authentication | To decode FEC in DRIP, a rolling XOR is used on each Authentication | |||
Page received in the current Authentication Message. A Message | Page received in the current Authentication Message. A Message | |||
Counter, outside of the ASTM Message but specified in [F3411], is | Counter, outside of the ASTM Message but specified in [F3411], is | |||
used to signal a different Authentication Message and to correlate | used to signal a different Authentication Message and to correlate | |||
pages to messages. This Message Counter is only single octet in | pages to messages. This Message Counter is only a single octet in | |||
length, so it will roll over (to 0x00) after reaching its maximum | length, so it will roll over (to 0x00) after reaching its maximum | |||
value (0xFF). If only a single page is missing in the Authentication | value (0xFF). If only a single page is missing in the Authentication | |||
Message the resulting parity octets should be the data of the erased | Message the resulting parity octets should be the data of the erased | |||
page. | page. | |||
Authentication Page 0 contains various important fields, only located | Authentication Page 0 contains various important fields, only located | |||
on that page, that help decode the full ASTM Authentication Message. | on that page, that help decode the full ASTM Authentication Message. | |||
If Page 0 has been reconstructed, the Last Page Index and Length | If Page 0 has been reconstructed, the Last Page Index and Length | |||
fields MUST be validated by DRIP. The pseudo-code in Figure 12 can | fields MUST be validated by DRIP. The pseudocode in Figure 12 can be | |||
be used for both checks. | used for both checks. | |||
<CODE BEGINS> | <CODE BEGINS> | |||
function decode_check(auth_pages[], decoded_lpi, decoded_length) { | function decode_check(auth_pages[], decoded_lpi, decoded_length) { | |||
// check decoded_lpi does not exceed maximum value | // check decoded_lpi does not exceed maximum value | |||
if (decoded_lpi >= 16) { | if (decoded_lpi >= 16) { | |||
return DECODE_FAILURE | return DECODE_FAILURE | |||
} | } | |||
// check that decoded length does not exceed DRIP maximum value | // check that decoded length does not exceed DRIP maximum value | |||
if (decoded_length > 201) { | if (decoded_length > 201) { | |||
skipping to change at page 28, line 45 ¶ | skipping to change at line 1217 ¶ | |||
presumed_lpi = (presumed_adl + decoded_length - 17) / 23 | presumed_lpi = (presumed_adl + decoded_length - 17) / 23 | |||
// check that presumed LPI and decoded LPI match | // check that presumed LPI and decoded LPI match | |||
if (presumed_lpi not equal decoded_lpi) { | if (presumed_lpi not equal decoded_lpi) { | |||
return DECODE_FAILURE | return DECODE_FAILURE | |||
} | } | |||
return DECODE_SUCCESS | return DECODE_SUCCESS | |||
} | } | |||
<CODE ENDS> | <CODE ENDS> | |||
Figure 12: Pseudo-code for Decode Checks | Figure 12: Pseudocode for Decode Checks | |||
5.3. FEC Limitations | 5.3. FEC Limitations | |||
The worst-case scenario is when the Authentication Data / Signature | The worst-case scenario is when the Authentication Data / Signature | |||
ends perfectly on a page boundary (Page N-1). This means the | ends perfectly on a page boundary (Page N-1). This means the | |||
Additional Data Length would start the next page (Page N) and have 22 | Additional Data Length would start the next page (Page N) and have 22 | |||
octets worth of null padding to align the FEC to begin at the start | octets worth of null padding to align the FEC to begin at the start | |||
of the next page (Page N+1). In this scenario, an entire page (Page | of the next page (Page N+1). In this scenario, an entire page (Page | |||
N) is being wasted just to carry the Additional Data Length. | N) is being wasted just to carry the Additional Data Length. | |||
6. Requirements & Recommendations | 6. Requirements and Recommendations | |||
6.1. Legacy Transports | 6.1. Legacy Transports | |||
Under DRIP, the goal is to attempt to bring reliable receipt of the | Under DRIP, the goal is to bring reliable receipt of the paged | |||
paged Authentication Message using Legacy Transports. FEC | Authentication Message using Legacy Transports. FEC (Section 5) MUST | |||
(Section 5) MUST be used, per mandated RID rules (for example the US | be used, per mandated RID rules (for example, the US FAA RID Rules | |||
FAA RID Rule [FAA-14CFR]), when using Legacy Transports (such as | [FAA-14CFR]), when using Legacy Transports (such as Bluetooth 4.x). | |||
Bluetooth 4.x). | ||||
Under [F3411], Authentication Messages are transmitted at the static | Under [F3411], Authentication Messages are transmitted at the static | |||
rate (at least every 3 seconds). Any DRIP Authentication Messages | rate (at least every 3 seconds). Any DRIP Authentication Messages | |||
containing dynamic data (such as the DRIP Wrapper) MAY be sent at the | containing dynamic data (such as the DRIP Wrapper) MAY be sent at the | |||
dynamic rate (at least every 1 second). | dynamic rate (at least every 1 second). | |||
6.2. Extended Transports | 6.2. Extended Transports | |||
Under the ASTM specification, Extended Transports of RID must use the | Under the ASTM specification, Extended Transports of RID must use the | |||
Message Pack (Message Type 0xF) format for all transmissions. Under | Message Pack (Message Type 0xF) format for all transmissions. Under | |||
Message Pack, ASTM Messages are sent together (in Message Type order) | Message Pack, ASTM Messages are sent together (in Message Type order) | |||
in a single frame (up to 9 single frame equivalent messages under | in a single frame (up to 9 single-frame equivalent messages under | |||
Legacy Transports). Message Packs are required by [F3411] to be sent | Legacy Transports). Message Packs are required by [F3411] to be sent | |||
at a rate of 1 per second (like dynamic messages). | at a rate of 1 per second (like dynamic messages). | |||
Message Packs are sent only over Extended Transports that provide | Message Packs are sent only over Extended Transports that provide | |||
FEC. Thus, the DRIP decoders will never be presented with a Message | FEC. Thus, the DRIP decoders will never be presented with a Message | |||
Pack from which a constituent Authentication Page has been dropped; | Pack from which a constituent Authentication Page has been dropped; | |||
DRIP FEC could never provide a benefit to a Message Pack, only | DRIP FEC could never provide benefit to a Message Pack, only consume | |||
consume its precious payload space. Therefore, DRIP FEC (Section 5) | its precious payload space. Therefore, DRIP FEC (Section 5) MUST NOT | |||
MUST NOT be used in Message Packs. | be used in Message Packs. | |||
6.3. Authentication | 6.3. Authentication | |||
To fulfill the requirements in [RFC9153], a UA: | To fulfill the requirements in [RFC9153], a UA: | |||
1. MUST: send DRIP Link (Section 4.2) using the BE: Apex, RAA | 1. MUST: send DRIP Link (Section 4.2) using the BE: Apex, RAA | |||
(partially satisfying GEN-3); at least once per 5 minutes. Apex | (partially satisfying GEN-3); at least once per 5 minutes. Apex | |||
in this context is the DET prefix owner | in this context is the DET prefix owner. | |||
2. MUST: send DRIP Link (Section 4.2) using the BE: RAA, HDA | 2. MUST: send DRIP Link (Section 4.2) using the BE: RAA, HDA | |||
(partially satisfying GEN-3); at least once per 5 minutes | (partially satisfying GEN-3); at least once per 5 minutes. | |||
3. MUST: send DRIP Link (Section 4.2) using the BE: HDA, UA | 3. MUST: send DRIP Link (Section 4.2) using the BE: HDA, UA | |||
(satisfying ID-5, GEN-1 and partially satisfying GEN-3); at least | (satisfying ID-5, GEN-1 and partially satisfying GEN-3); at least | |||
once per minute | once per minute. | |||
4. MUST: send any other DRIP Authentication Format (non-DRIP Link) | 4. MUST: send any other DRIP Authentication Format (non-DRIP Link) | |||
where the UA is dynamically signing data that is guaranteed to be | where the UA is dynamically signing data that is guaranteed to be | |||
unique, unpredictable and easily cross checked by the receiving | unique, unpredictable, and easily cross checked by the receiving | |||
device (satisfying ID-5, GEN-1 and GEN-2); at least once per 5 | device (satisfying ID-5, GEN-1 and GEN-2); at least once per 5 | |||
seconds | seconds. | |||
These four transmission requirements collectively satisfy GEN-3. | These four transmission requirements collectively satisfy GEN-3. | |||
6.4. Operational | 6.4. Operational | |||
UAS operation may impact the frequency of sending DRIP Authentication | UAS operation may impact the frequency of sending DRIP Authentication | |||
messages. When a UA dwells at an approximate location, and the | messages. When a UA dwells at an approximate location, and the | |||
channel is heavily used by other devices, less frequent message | channel is heavily used by other devices, less frequent message | |||
authentication may be effective (to minimize RF packet collisions) | authentication may be effective (to minimize RF packet collisions) | |||
for an Observer. Contrast this with a UA transiting an area, where | for an Observer. Contrast this with a UA transiting an area, where | |||
authenticated messages SHOULD be sufficiently frequent for an | authenticated messages SHOULD be sufficiently frequent for an | |||
Observer to have a high probability of receiving an adequate number | Observer to have a high probability of receiving an adequate number | |||
for validation during the transit. | for validation during the transit. | |||
A RECOMMENDED operational configuration (in alignment with | A RECOMMENDED operational configuration (in alignment with | |||
Section 6.3) with reasoning can be found in Appendix B. It consists | Section 6.3) with rationale can be found in Appendix B. It consists | |||
of the following recommendations for every second: | of the following recommendations for every second: | |||
* Under Legacy Transport: | * Under Legacy Transport: | |||
- Two sets of those ASTM Messages required by a CAA in its | - Two sets of those ASTM Messages required by a CAA in its | |||
jurisdiction (example: Basic ID, Location and System) and one | jurisdiction (example: Basic ID, Location and System) and one | |||
set of other ASTM Messages (example: Self ID, Operator ID) | set of other ASTM Messages (example: Self ID, Operator ID) | |||
- An FEC protected DRIP Manifest enabling authentication of those | - An FEC-protected DRIP Manifest enabling authentication of those | |||
ASTM Messages sent | ASTM Messages sent | |||
- A single page of an FEC protected DRIP Link | - A single page of an FEC-protected DRIP Link | |||
* Under Extended Transport: | * Under Extended Transport: | |||
- A Message Pack of ASTM Messages (up to 4) and a DRIP Wrapper | - A Message Pack of ASTM Messages (up to 4) and a DRIP Wrapper | |||
(per Section 4.3.2) | (per Section 4.3.2) | |||
- A Message Pack of a DRIP Link | - A Message Pack of a DRIP Link | |||
6.4.1. DRIP Wrapper | 6.4.1. DRIP Wrapper | |||
If DRIP Wrappers are sent, they MUST be sent in addition to any | If DRIP Wrappers are sent, they MUST be sent in addition to any | |||
required ASTM Messages in a given jurisdiction. An implementation | required ASTM Messages in a given jurisdiction. An implementation | |||
MUST NOT send DRIP Wrappers in place of any required ASTM Messages it | MUST NOT send DRIP Wrappers in place of any required ASTM Messages it | |||
may encapsulate. Thus, messages within a Wrapper are sent twice: | may encapsulate. Thus, messages within a Wrapper are sent twice: | |||
once in the clear and once authenticated within the Wrapper. | once in the clear and once authenticated within the Wrapper. | |||
The DRIP Wrapper has a specific use case for DRIP aware Observers. | The DRIP Wrapper has a specific use case for DRIP-aware Observers. | |||
For an Observer plotting Location Messages (Message Type 0x2) on a | For an Observer plotting Location Messages (Message Type 0x2) on a | |||
map, display an embedded Location Message in a DRIP Wrapper can be | map, display of an embedded Location Message in a DRIP Wrapper can be | |||
marked differently (e.g., via color) to signify trust in the Location | marked differently (e.g., via color) to signify trust in the Location | |||
data. | data. | |||
6.4.2. UAS RID Trust Assessment | 6.4.2. UAS RID Trust Assessment | |||
As described in Section 3.1.2, the Observer MUST perform validation | As described in Section 3.1.2, the Observer MUST perform validation | |||
of the data being received in Broadcast RID. This is because trust | of the data being received in Broadcast RID. This is because trust | |||
in a key is different from trust that an observed UA possesses that | in a key is different from trust that an observed UA possesses that | |||
key. | key. | |||
skipping to change at page 31, line 43 ¶ | skipping to change at line 1352 ¶ | |||
with or observed in real time by) the agent with the key. | with or observed in real time by) the agent with the key. | |||
After signature verification of any DRIP Authentication Message | After signature verification of any DRIP Authentication Message | |||
containing UAS RID information elements (e.g., DRIP Wrapper | containing UAS RID information elements (e.g., DRIP Wrapper | |||
Section 4.3) the Observer MUST use other sources of information to | Section 4.3) the Observer MUST use other sources of information to | |||
correlate against and perform validation. An example of another | correlate against and perform validation. An example of another | |||
source of information is a visual confirmation of the UA position. | source of information is a visual confirmation of the UA position. | |||
When correlation of these different data streams does not match in | When correlation of these different data streams does not match in | |||
acceptable thresholds, the data MUST be rejected as if the signature | acceptable thresholds, the data MUST be rejected as if the signature | |||
failed to validate. Acceptable thresholds limits and what happens | failed to validate. Acceptable threshold limits and what happens | |||
after such a rejection are out of scope for this document. | after such a rejection are out of scope for this document. | |||
7. Summary of Addressed DRIP Requirements | 7. Summary of Addressed DRIP Requirements | |||
The following [RFC9153] requirements are addressed in this document: | The following requirements as defined in [RFC9153] are addressed in | |||
this document: | ||||
ID-5: Non-spoofability | ||||
ID-5: Non-spoofability | ||||
Addressed using the DRIP Wrapper (Section 4.3), DRIP Manifest | Addressed using the DRIP Wrapper (Section 4.3), DRIP Manifest | |||
(Section 4.4) or DRIP Frame (Section 4.5). | (Section 4.4), or DRIP Frame (Section 4.5). | |||
GEN-1: Provable Ownership | GEN-1: Provable Ownership | |||
Addressed using the DRIP Link (Section 4.2) and DRIP Wrapper | Addressed using the DRIP Link (Section 4.2) and DRIP Wrapper | |||
(Section 4.3), DRIP Manifest (Section 4.4) or DRIP Frame | (Section 4.3), DRIP Manifest (Section 4.4), or DRIP Frame | |||
(Section 4.5). | (Section 4.5). | |||
GEN-2: Provable Binding | GEN-2: Provable Binding | |||
Addressed using the DRIP Wrapper (Section 4.3), DRIP Manifest | Addressed using the DRIP Wrapper (Section 4.3), DRIP Manifest | |||
(Section 4.4) or DRIP Frame (Section 4.5). | (Section 4.4) or DRIP Frame (Section 4.5). | |||
GEN-3: Provable Registration | GEN-3: Provable Registration | |||
Addressed using the DRIP Link (Section 4.2). | Addressed using the DRIP Link (Section 4.2). | |||
8. IANA Considerations | 8. IANA Considerations | |||
8.1. IANA DRIP Registry | 8.1. IANA DRIP Registry | |||
This document requests two new registries, for DRIP SAM Type and DRIP | IANA has created the "DRIP SAM Types" and "DRIP Frame Types" | |||
Frame Type, under the DRIP registry group | registries within the "Drone Remote ID Protocol" registry group | |||
(https://www.iana.org/assignments/drip/drip.xhtml). | (https://www.iana.org/assignments/drip). | |||
DRIP SAM Type: This registry is a mirror for SAM Types containing | DRIP SAM Types: | |||
the subset of allocations used by DRIP Authentication Messages. | This registry is a mirror for SAM Types containing the subset of | |||
Future additions MUST be done through ASTM's designated registrar | allocations used by DRIP Authentication Messages. Future | |||
which at the time of publication of this RFC is ICAO | additions MUST be done through ASTM's designated registrar, which | |||
[ASTM-Remote-ID]. Additions for DRIP will be coordinated by IANA | is ICAO [ASTM-Remote-ID] at the time of publication of this RFC. | |||
and the ASTM designated registrar before final publication as | Additions for DRIP will be coordinated by IANA and the ASTM | |||
Standards Track RFCs. The following values have been allocated to | designated registrar before final publication as Standards Track | |||
the IETF and are defined here: | RFCs. The following values have been allocated to the IETF: | |||
+==========+===============+=======================================+ | +==========+===========+=======================================+ | |||
| SAM Type | Name | Description | | | SAM Type | Name | Description | | |||
+==========+===============+=======================================+ | +==========+===========+=======================================+ | |||
| 0x01 | DRIP Link | Format to hold Broadcast Endorsements | | | 0x01 | DRIP Link | Format to hold Broadcast Endorsements | | |||
+----------+---------------+---------------------------------------+ | +----------+-----------+---------------------------------------+ | |||
| 0x02 | DRIP Wrapper | Authenticate full ASTM Messages | | | 0x02 | DRIP | Authenticate full ASTM Messages | | |||
+----------+---------------+---------------------------------------+ | | | Wrapper | | | |||
| 0x03 | DRIP Manifest | Authenticate hashes of ASTM Messages | | +----------+-----------+---------------------------------------+ | |||
+----------+---------------+---------------------------------------+ | | 0x03 | DRIP | Authenticate hashes of ASTM Messages | | |||
| 0x04 | DRIP Frame | Format for future DRIP authentication | | | | Manifest | | | |||
+----------+---------------+---------------------------------------+ | +----------+-----------+---------------------------------------+ | |||
| 0x04 | DRIP | Format for future DRIP authentication | | ||||
| | Frame | | | ||||
+----------+-----------+---------------------------------------+ | ||||
Table 2: DRIP SAM Types | Table 2: DRIP SAM Types | |||
DRIP Frame Type: This 8-bit valued registry is for Frame Types in | DRIP Frame Types: | |||
DRIP Frame Authentication Messages. Future additions to this | This 8-bit value registry is for Frame Types in DRIP Frame | |||
registry are to be made through Expert Review (Section 4.5 of | Authentication Messages. Future additions to this registry are to | |||
[RFC8126]) for the values of 0x01 to 0x9F and First Come, First | be made through Expert Review (Section 4.5 of [RFC8126]) for | |||
Served (Section 4.4 of [RFC8126]) for values 0xA0 to 0xEF. The | values 0x01 to 0x9F and First Come First Served (Section 4.4 of | |||
following values are defined: | [RFC8126]) for values 0xA0 to 0xEF. The following values are | |||
defined: | ||||
+=============+==============+====================================+ | +=============+==============+===============================+ | |||
| Frame Type | Name | Description | | | Frame Type | Name | Description | | |||
+=============+==============+====================================+ | +=============+==============+===============================+ | |||
| 0x00 | Reserved | Reserved | | | 0x00 | Reserved | Reserved | | |||
+-------------+--------------+------------------------------------+ | +-------------+--------------+-------------------------------+ | |||
| 0x01 - 0x9F | Reserved | Reserved: Expert Review | | | 0x01 - 0xEF | Unassigned | | | |||
+-------------+--------------+------------------------------------+ | +-------------+--------------+-------------------------------+ | |||
| 0xA0 - 0xEF | Reserved | Reserved: First Come, First Served | | | 0xF0-0xFF | Experimental | Reserved for Experimental Use | | |||
+-------------+--------------+------------------------------------+ | +-------------+--------------+-------------------------------+ | |||
| 0xF0 - 0xFF | Experimental | Experimental Use | | ||||
+-------------+--------------+------------------------------------+ | ||||
Table 3: DRIP Frame Types | Table 3: DRIP Frame Types | |||
Criteria that should be applied by the designated experts includes | Criteria that should be applied by the designated experts includes | |||
determining whether the proposed registration duplicates existing | determining whether the proposed registration duplicates existing | |||
functionality and whether the registration description is clear and | functionality and whether the registration description is clear and | |||
fits the purpose of this registry. | fits the purpose of this registry. | |||
Registration requests MUST be sent to drip-reg-review@ietf.org | Registration requests MUST be sent to drip-reg-review@ietf.org | |||
(mailto:drip-reg-review@ietf.org) and be evaluated within a three- | (mailto:drip-reg-review@ietf.org) and be evaluated by one or more | |||
week review period on the advice of one or more designated experts. | designated experts within a three-week review period. Within that | |||
Within that review period, the designated experts will either approve | review period, the designated experts will either approve or deny the | |||
or deny the registration request, and communicate their decision to | registration request, and communicate their decision to the review | |||
the review list and IANA. Denials should include an explanation and, | list and IANA. Denials should include an explanation and, if | |||
if applicable, suggestions to successfully register the DRIP Frame | applicable, suggestions to successfully register the DRIP Frame Type. | |||
Type. | ||||
Registration requests that are undetermined for a period longer than | Registration requests that are undetermined for a period longer than | |||
28 days can be brought to the IESG's attention for resolution. | 28 days can be brought to the IESG's attention for resolution. | |||
9. Security Considerations | 9. Security Considerations | |||
9.1. Replay Attacks | 9.1. Replay Attacks | |||
[F3411] (regardless of transport) lacks replay protection, as it more | [F3411] (regardless of transport) lacks replay protection, as it more | |||
fundamentally lacks fully specified authentication. An attacker can | fundamentally lacks fully specified authentication. An attacker can | |||
spoof the UA sender MAC address and UAS ID, replaying (with or | spoof the UA sender MAC address and UAS ID, replaying (with or | |||
without modification) previous genuine messages, and/or crafting | without modification) previous genuine messages, and/or crafting | |||
entirely new messages. Using DRIP in [F3411] Authentication message | entirely new messages. Using DRIP in [F3411] Authentication message | |||
framing enables verification that messages were signed with | framing enables verification that messages were signed with | |||
registered keys, but when naively used may be vulnerable to replay | registered keys, but when naively used may be vulnerable to replay | |||
attacks. Technologies such as Single Emitter Identification can | attacks. Technologies such as Single Emitter Identification can | |||
detect such attacks, but are not readily available and can be | detect such attacks, but they are not readily available and can be | |||
prohibitively expensive, especially for typical Observer devices such | prohibitively expensive, especially for typical Observer devices such | |||
as smartphones. | as smartphones. | |||
Replay attack detection using DRIP requires Observer devices to | Replay attack detection using DRIP requires Observer devices to | |||
combine information from multiple messages and sources other than | combine information from multiple messages and sources other than | |||
Broadcast RID. A complete chain of Link messages (Section 4.2), from | Broadcast RID. A complete chain of Link messages (Section 4.2) from | |||
an Endorsement root of trust to the claimed sender, must be collected | an Endorsement root of trust to the claimed sender must be collected | |||
and verified by the Observer device to provide trust in a key. | and verified by the Observer device to provide trust in a key. | |||
Successful signature verification, using that key, of a Wrapper | Successful signature verification, using that key, of a Wrapper | |||
(Section 4.3) or Manifest (Section 4.4) message, authenticating | (Section 4.3) or Manifest (Section 4.4) message, authenticating | |||
content that is nonce-like, provides trust that the sender actually | content that is nonce-like, provides trust that the sender actually | |||
possesses that key. | possesses that key. | |||
By "nonce-like" is meant data that is unique, not accurately | The term "nonce-like" means the that data is unique, not accurately | |||
predictable long in advance, and readily validated by the Observer. | predictable long in advance, and readily validated by the Observer. | |||
This is described in Section 6.3 (requirement 4) and Section 3.1.2.2. | This is described in Section 6.3 (requirement 4) and Section 3.1.2.2. | |||
The [F3411] Location message reporting precise UA position and | The Location message [F3411] reporting precise UA position and | |||
velocity at a precise very recent time, to be checked by the Observer | velocity at a precise and very recent time is to be checked by the | |||
against visual observations of the UA within RF and thus typically | Observer against visual observations of the UA within RF. Thus, | |||
visual Line Of Sight is the recommended form of this data. For | Visual Line of Sight is typically the recommended form of this data. | |||
specification of the foregoing, see Section 3.1.2 and Section 6.4.2. | For specification of the foregoing, see Sections 3.1.2 and 6.4.2. | |||
Messages that pass signature verification with trusted keys could | Messages that pass signature verification with trusted keys could | |||
still be replays if they contain only static information (e.g., | still be replays if they contain only static information (e.g., | |||
Broadcast Endorsements (Section 4.2), [F3411] Basic ID or [F3411] | Broadcast Endorsements (Section 4.2), [F3411] Basic ID or [F3411] | |||
Operator ID) or information that cannot be readily validated (e.g., | Operator ID), or information that cannot be readily validated (e.g., | |||
[F3411] Self-ID). Replay of Link messages is harmless (unless sent | [F3411] Self-ID). Replay of Link messages is harmless (unless sent | |||
so frequently as to cause RF data link congestion) and indeed can | so frequently as to cause RF data link congestion) and indeed can | |||
increase the likelihood of an Observer device collecting an entire | increase the likelihood of an Observer device collecting an entire | |||
trust chain in a short time window. Replay of other messages | trust chain in a short time window. Replay of other messages | |||
([F3411] Basic ID, [F3411] Operator ID, or [F3411] Self-ID) remains a | ([F3411] Basic ID, [F3411] Operator ID, or [F3411] Self-ID) remains a | |||
vulnerability, unless they are combined with messages containing | vulnerability, unless they are combined with messages containing | |||
nonce-like data ([F3411] Location or [F3411] System) in a Wrapper or | nonce-like data ([F3411] Location or [F3411] System) in a Wrapper or | |||
Manifest. For specification of this last requirement, see | Manifest. For specification of this last requirement, see | |||
Section 4.4.2. | Section 4.4.2. | |||
9.2. Wrapper vs Manifest | 9.2. Wrapper vs Manifest | |||
Implementations have a choice on using Wrapper (Section 4.3), | Implementations have a choice of using Wrapper (Section 4.3), | |||
Manifest (Section 4.4), or a combination to satisfy the 4th | Manifest (Section 4.4), or a combination to satisfy the fourth | |||
requirement in Section 6.3. | requirement in Section 6.3. | |||
Wrapper is an attached signature of the full content of one or more | Wrapper is an attached signature of the full content of one or more | |||
[F3411] messages, providing strong authentication. However, the size | [F3411] messages, providing strong authentication. However, the size | |||
limitation means it can not support such signatures over other | limitation means it cannot support such signatures over other | |||
Authentication Messages, thus it can not provide a direct binding to | Authentication Messages; thus, it cannot provide a direct binding to | |||
any part of the trust chain (Section 3.1.2 and Section 6.4.2). | any part of the trust chain (Sections 3.1.2 and 6.4.2). | |||
Manifest explicitly provides the binding of the last link in the | Manifest explicitly provides the binding of the last link in the | |||
trust chain (with the inclusion of the hash of the Link containing | trust chain (with the inclusion of the hash of the Link containing | |||
BE: HDA, UA). The use of hashes and their length also allows for a | BE: HDA, UA). The use of hashes and their length also allows for a | |||
larger (11 vs 4) number of any [F3411] messages to be authenticated, | larger number (11 vs 4) of [F3411] messages to be authenticated, | |||
making it more efficient compared to the Wrapper. However, the | making it more efficient compared to the Wrapper. However, the | |||
detached signature requires additional Observer overhead in storing | detached signature requires additional Observer overhead in storing | |||
and comparing hashes of received messages (some that may not be | and comparing hashes of received messages (some of which may not be | |||
received) of those in a Manifest. | received) with those in a Manifest. | |||
Appendix B contains a breakdown of frame counts and an example of a | Appendix B contains a breakdown of frame counts and an example of a | |||
schedule using both Manifest and Wrapper. Typical operation may see | schedule using both Manifest and Wrapper. Typical operation may see | |||
(as an example) 2x Basic ID, 2x Location, 2x System, 1x Operator ID | (as an example) 2x Basic ID, 2x Location, 2x System, 1x Operator ID | |||
and 1x Self ID broadcast per second to comply with jurisdiction | and 1x Self ID broadcast per second to comply with jurisdiction | |||
mandates. Each of these messages are a single frame in size. A Link | mandates. Each of these messages is a single frame in size. A Link | |||
message is 8 frames long (including FEC). This is a base frame count | message is 8 frames long (including FEC). This is a base frame count | |||
of *16 frames*. | of *16 frames*. | |||
When Wrapper is used, up to 4 of the previous messages (except the | When Wrapper is used, up to four of the previous messages (except the | |||
Link) can be authenticated. For this comparison, we will sign all | Link) can be authenticated. For this comparison, we will sign all | |||
the messages we can in two Wrappers. This results in _20 frames_ | the messages we can in two Wrappers. This results in _20 frames_ | |||
(with FEC). Due to not being able to fit, the Link message is left | (with FEC). Due to size constraints, the Link message is left | |||
unauthenticated. The total frame count using Wrappers is *36 frames* | unauthenticated. The total frame count using Wrappers is *36 frames* | |||
(wrapper frame count + base frame count). | (wrapper frame count + base frame count). | |||
When Manifest is used, up to 10 previous messages can be | When Manifest is used, up to 10 previous messages can be | |||
authenticated. For this example all messages (8) are hashed | authenticated. For this example, all messages (8) are hashed | |||
(including the Link) resulting in a single Manifest that is _9 | (including the Link) resulting in a single Manifest that is _9 | |||
frames_ (with FEC). The total frame count using Manifest is *25 | frames_ (with FEC). The total frame count using Manifest is *25 | |||
frames* (manifest frame count + base frame count). | frames* (manifest frame count + base frame count). | |||
9.3. VNA Timestamp Offsets for DRIP Authentication Formats | 9.3. VNA Timestamp Offsets for DRIP Authentication Formats | |||
Note the discussion of VNA Timestamp offsets here is in the context | Note the discussion of VNA Timestamp offsets here is in the context | |||
of the DRIP Wrapper (Section 4.3), DRIP Manifest (Section 4.4), and | of the DRIP Wrapper (Section 4.3), DRIP Manifest (Section 4.4), and | |||
DRIP Frame (Section 4.5). For DRIP Link (Section 4.2) these offsets | DRIP Frame (Section 4.5). For DRIP Link (Section 4.2), these offsets | |||
are set by the DIME and have their own set of considerations in | are set by the DIME and have their own set of considerations in | |||
[drip-registries]. | [DRIP-REG]. | |||
The offset of the VNA Timestamp by UA is one that needs careful | The offset of the VNA Timestamp by UA is one that needs careful | |||
consideration for any implementation. The offset should be shorter | consideration for any implementation. The offset should be shorter | |||
than any given flight duration (typically less than an hour) but be | than any given flight duration (typically less than an hour) but be | |||
long enough to be received and processed by Observers (larger than a | long enough to be received and processed by Observers (larger than a | |||
few seconds). It is recommended that 3-5 minutes should be | few seconds). It is recommended that 3-5 minutes should be | |||
sufficient to serve this purpose in any scenario, but is not limited | sufficient to serve this purpose in any scenario, but it is not | |||
by design. | limited by design. | |||
9.4. DNS Security in DRIP | 9.4. DNS Security in DRIP | |||
As stated in Section 3.1 specification of particular DNS security | As stated in Section 3.1 specification of particular DNS security | |||
options, transports, etc. is outside the scope of this document. | options, transports, etc. is outside the scope of this document. | |||
[drip-registries] is the main specification for DNS operations in | [DRIP-REG] is the main specification for DNS operations in DRIP and | |||
DRIP and as such will specify DRIP usage of best common practices for | as such will specify DRIP usage of best common practices for security | |||
security (such as [RFC9364]). | (such as [RFC9364]). | |||
10. Acknowledgments | 10. Acknowledgments | |||
* Ryan Quigley, James Mussi and Joseph Stanton of AX Enterprize, LLC | * Ryan Quigley, James Mussi, and Joseph Stanton of AX Enterprize, | |||
for early prototyping to find holes in the draft specifications | LLC for early prototyping to find holes in earlier drafts of this | |||
specification | ||||
* Carsten Bormann for the simple approach of using bit-column-wise | * Carsten Bormann for the simple approach of using bit-column-wise | |||
parity for erasure (dropped frame) FEC | parity for erasure (dropped frame) FEC | |||
* Soren Friis for pointing out that Wi-Fi implementations would not | * Soren Friis for pointing out that Wi-Fi implementations would not | |||
always give access to the MAC Address, originally used in | always give access to the MAC Address, as was originally used in | |||
calculation of the hashes for DRIP Manifest. Also, for confirming | calculation of the hashes for DRIP Manifest. Also, for confirming | |||
that Message Packs (0xF) can only carry up to 9 ASTM frames worth | that Message Packs (0xF) can only carry up to 9 ASTM frames worth | |||
of data (9 Authentication pages) | of data (9 Authentication pages) | |||
* Gabriel Cox (chair of the working group that produced [F3411]) in | * Gabriel Cox (chair of the working group that produced [F3411]) for | |||
reviewing the specification for the SAM Type request as the ASTM | reviewing the specification for the SAM Type request as the ASTM | |||
Designated Expert | Designated Expert | |||
* Mohamed Boucadair (Document Shepherd) for his many patches and | * Mohamed Boucadair (Document Shepherd) for his many patches and | |||
comments | comments | |||
* Eric Vyncke (DRIP AD) for his guidance through the documents path | * Eric Vyncke (DRIP AD) for his guidance regarding the document's | |||
to publication | path to publication | |||
* Thanks to the following reviewers: | * Thanks to the following reviewers: | |||
- Rick Salz (secdir) | - Rick Salz (secdir) | |||
- Matt Joras (genart) | - Matt Joras (genart) | |||
- Di Ma (dnsdir) | - Di Ma (dnsdir) | |||
- Gorry Fairhurst (tsvart) | - Gorry Fairhurst (tsvart) | |||
skipping to change at page 37, line 27 ¶ | skipping to change at line 1625 ¶ | |||
11. References | 11. References | |||
11.1. Normative References | 11.1. Normative References | |||
[F3411] ASTM International, "Standard Specification for Remote ID | [F3411] ASTM International, "Standard Specification for Remote ID | |||
and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July | and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July | |||
2022, <https://www.astm.org/f3411-22a.html>. | 2022, <https://www.astm.org/f3411-22a.html>. | |||
[NIST.SP.800-185] | [NIST.SP.800-185] | |||
Kelsey, J., Change, S., Perlner, R., and NIST, "SHA-3 | Kelsey, J., Chang, S., and R. Perlner, "SHA-3 Derived | |||
derived functions: cSHAKE, KMAC, TupleHash and | Functions: cSHAKE, KMAC, TupleHash and ParallelHash", NIST | |||
ParallelHash", NIST Special Publications | Special Publication 800-185, DOI 10.6028/NIST.SP.800-185, | |||
(General) 800-185, DOI 10.6028/NIST.SP.800-185, December | December 2016, | |||
2016, | ||||
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ | <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ | |||
NIST.SP.800-185.pdf>. | NIST.SP.800-185.pdf>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
skipping to change at page 38, line 18 ¶ | skipping to change at line 1660 ¶ | |||
<https://www.rfc-editor.org/info/rfc9374>. | <https://www.rfc-editor.org/info/rfc9374>. | |||
[RFC9434] Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed., | [RFC9434] Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed., | |||
and A. Gurtov, "Drone Remote Identification Protocol | and A. Gurtov, "Drone Remote Identification Protocol | |||
(DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July | (DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July | |||
2023, <https://www.rfc-editor.org/info/rfc9434>. | 2023, <https://www.rfc-editor.org/info/rfc9434>. | |||
11.2. Informative References | 11.2. Informative References | |||
[ASTM-Remote-ID] | [ASTM-Remote-ID] | |||
"ICAO Remote ID Number Registration", December 2023, | International Civil Aviation Organization (ICAO), "Remote | |||
ID Number Registration", December 2023, | ||||
<https://www.icao.int/airnavigation/IATF/Pages/ASTM- | <https://www.icao.int/airnavigation/IATF/Pages/ASTM- | |||
Remote-ID.aspx>. | Remote-ID.aspx>. | |||
[drip-registries] | [DRIP-REG] Wiethuechter, A. and J. Reid, "DRIP Entity Tag (DET) | |||
Wiethuechter, A. and J. Reid, "DRIP Entity Tag (DET) | ||||
Identity Management Architecture", Work in Progress, | Identity Management Architecture", Work in Progress, | |||
Internet-Draft, draft-ietf-drip-registries-14, 4 December | Internet-Draft, draft-ietf-drip-registries-15, 1 April | |||
2023, <https://datatracker.ietf.org/doc/html/draft-ietf- | 2024, <https://datatracker.ietf.org/doc/html/draft-ietf- | |||
drip-registries-14>. | drip-registries-15>. | |||
[FAA-14CFR] | [FAA-14CFR] | |||
"Remote Identification of Unmanned Aircraft", January | Federal Aviation Administration (FAA), "Remote | |||
2021, <https://www.govinfo.gov/content/pkg/FR-2021-01-15/ | Identification of Unmanned Aircraft", January 2021, | |||
<https://www.govinfo.gov/content/pkg/FR-2021-01-15/ | ||||
pdf/2020-28948.pdf>. | pdf/2020-28948.pdf>. | |||
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | |||
Writing an IANA Considerations Section in RFCs", BCP 26, | Writing an IANA Considerations Section in RFCs", BCP 26, | |||
RFC 8126, DOI 10.17487/RFC8126, June 2017, | RFC 8126, DOI 10.17487/RFC8126, June 2017, | |||
<https://www.rfc-editor.org/info/rfc8126>. | <https://www.rfc-editor.org/info/rfc8126>. | |||
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, | [RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, | |||
RFC 9364, DOI 10.17487/RFC9364, February 2023, | RFC 9364, DOI 10.17487/RFC9364, February 2023, | |||
<https://www.rfc-editor.org/info/rfc9364>. | <https://www.rfc-editor.org/info/rfc9364>. | |||
Appendix A. Authentication States | Appendix A. Authentication States | |||
ASTM Authentication has only three states: None, Invalid, and Valid. | ASTM Authentication has only three states: None, Invalid, and Valid. | |||
This is because, under ASTM, the authentication is done by an | This is because, under ASTM, the authentication is done by an | |||
external service hosted somewhere on the Internet so it is assumed an | external service hosted somewhere on the Internet so it is assumed an | |||
authoritative response will always be returned. This classification | authoritative response will always be returned. This classification | |||
becomes more complex in DRIP with the support of "offline" scenarios | becomes more complex in DRIP with the support of "offline" scenarios | |||
where a Observer does not have Internet connectivity. With the use | where an Observer does not have Internet connectivity. With the use | |||
of asymmetric cryptography this means that the public key (PK) must | of asymmetric cryptography, this means that the public key (PK) must | |||
somehow be obtained. [drip-registries] gets more into detail how | somehow be obtained. [DRIP-REG] provides more detail on how these | |||
these keys are stored on DNS and one use of DRIP Authentication | keys are stored on the DNS and how DRIP Authentication messages can | |||
messages is to send PK's over Broadcast RID. | be used to send PK's over Broadcast RID. | |||
There are a few keys of interest: the PK of the UA and the PK's of | There are a few keys of interest: the PK of the UA and the PKs of | |||
relevant DIMEs. This document describes how to send the PK of the UA | relevant DIMEs. This document describes how to send the PK of the UA | |||
over the Broadcast RID messages. The key of DIMEs are sent over | over the Broadcast RID messages. The keys of DIMEs are sent over | |||
Broadcast RID using the same mechanisms (see Section 4.2 and | Broadcast RID using the same mechanisms (see Sections 4.2 and 6.3) | |||
Section 6.3) but MAY be sent at a far lower rate due to potential | but MAY be sent at a far lower rate due to potential operational | |||
operational constraints (such as saturation of limited bandwidth). | constraints (such as saturation of limited bandwidth). As such, | |||
As such, there are scenarios where part of the key-chain may be | there are scenarios where part of the key-chain may be unavailable at | |||
unavailable at the moment a full Authentication Message is received | the moment a full Authentication Message is received and processed. | |||
and processed. | ||||
The intent of this informative appendix is to give a recommended way | The intent of this informative appendix is to recommend a way to | |||
to classify these various states and convey it to the user through | classify these various states and convey it to the user through | |||
colors and state names/text. These states can apply to either a | colors and state names/text. These states can apply to either a | |||
single authentication message, a DET (and its associated public key), | single authentication message, a DET (and its associated public key), | |||
and/or a sender. | and/or a sender. | |||
The table below lays out the recommended colors to associate with | The table below lays out the recommended colors to associate with | |||
state and a brief description of each. | state and a brief description of each. | |||
+==============+========+=================================+ | +==============+========+===================================+ | |||
| State | Color | Details | | | State | Color | Details | | |||
+==============+========+=================================+ | +==============+========+===================================+ | |||
| None | Black | No Authentication being | | | None | Black | No Authentication being received | | |||
| | | received (as yet) | | | | | (as yet) | | |||
+--------------+--------+---------------------------------+ | +--------------+--------+-----------------------------------+ | |||
| Partial | Gray | Authentication being received | | | Partial | Gray | Authentication being received but | | |||
| | | but missing pages | | | | | missing pages | | |||
+--------------+--------+---------------------------------+ | +--------------+--------+-----------------------------------+ | |||
| Unsupported | Brown | Authentication Type/SAM Type of | | | Unsupported | Brown | Authentication Type / SAM Type of | | |||
| | | received message not supported | | | | | received message not supported | | |||
+--------------+--------+---------------------------------+ | +--------------+--------+-----------------------------------+ | |||
| Unverifiable | Yellow | Data needed for signature | | | Unverifiable | Yellow | Data needed for signature | | |||
| | | verification is missing | | | | | verification is missing | | |||
+--------------+--------+---------------------------------+ | +--------------+--------+-----------------------------------+ | |||
| Verified | Green | Valid signature verification | | | Verified | Green | Valid signature verification and | | |||
| | | and content validation | | | | | content validation | | |||
+--------------+--------+---------------------------------+ | +--------------+--------+-----------------------------------+ | |||
| Trusted | Blue | evidence of Verified and DIME | | | Trusted | Blue | Evidence of Verified and DIME is | | |||
| | | is marked as only registering | | | | | marked as only registering DETs | | |||
| | | DETs for trusted entities | | | | | for trusted entities | | |||
+--------------+--------+---------------------------------+ | +--------------+--------+-----------------------------------+ | |||
| Unverified | Red | Invalid signature verification | | | Unverified | Red | Invalid signature verification or | | |||
| | | or content validation | | | | | content validation | | |||
+--------------+--------+---------------------------------+ | +--------------+--------+-----------------------------------+ | |||
| Questionable | Orange | evidence of both Verified & | | | Questionable | Orange | Evidence of both"Verified and | | |||
| | | Unverified for the same claimed | | | | | Unverified for the same claimed | | |||
| | | sender | | | | | sender | | |||
+--------------+--------+---------------------------------+ | +--------------+--------+-----------------------------------+ | |||
| Conflicting | Purple | evidence of both Trusted & | | | Conflicting | Purple | Evidence of both Trusted and | | |||
| | | Unverified for the same claimed | | | | | Unverified for the same claimed | | |||
| | | sender | | | | | sender | | |||
+--------------+--------+---------------------------------+ | +--------------+--------+-----------------------------------+ | |||
Table 4: Authentication State Names, Colors & Descriptions | Table 4: Authentication State Names, Colors, and Descriptions | |||
A.1. None: Black | A.1. None: Black | |||
The default state where no authentication information has yet to be | The default state where no authentication information has been | |||
received. | received. | |||
A.2. Partial: Gray | A.2. Partial: Gray | |||
A pending state where authentication pages are being received but a | A pending state where authentication pages are being received, but a | |||
full authentication message has yet to be compiled. | full authentication message has yet to be compiled. | |||
A.3. Unsupported: Brown | A.3. Unsupported: Brown | |||
A state wherein authentication data is being or has been received, | A state wherein authentication data is being or has been received but | |||
but cannot be used, as the Authentication Type or SAM Type is not | cannot be used, as the Authentication Type or SAM Type is not | |||
supported by the Observer. | supported by the Observer. | |||
A.4. Unverifiable: Yellow | A.4. Unverifiable: Yellow | |||
A pending state where a full authentication message has been received | A pending state where a full authentication message has been received | |||
but other information, such as public keys to verify signatures, is | but other information, such as public keys to verify signatures, is | |||
missing. | missing. | |||
A.5. Verified: Green | A.5. Verified: Green | |||
A state where all authentication messages that have been received, up | A state where all authentication messages that have been received | |||
to that point from that claimed sender, pass signature verification | from that claimed sender up to that point pass signature verification | |||
and the requirement of Section 6.4.2 has been met. | and the requirement of Section 6.4.2 has been met. | |||
A.6. Trusted: Blue | A.6. Trusted: Blue | |||
A state where all authentication messages that have been received, up | A state where all authentication messages that have been received | |||
to that point, from that claimed sender, have passed signature | from that claimed sender up to that point have passed signature | |||
verification, the requirement of Section 6.4.2 has been met, and the | verification, the requirement of Section 6.4.2 has been met, and the | |||
public key of the sending UA is marked as trusted. | public key of the sending UA has been marked as trusted. | |||
The sending UA key will have been marked as trusted if the relevant | The sending UA key will have been marked as trusted if the relevant | |||
DIMEs only register DETs (of subordinate DIMEs, UAS operators, and | DIMEs only register DETs (of subordinate DIMEs, UAS operators, and | |||
UA) that have been vetted as per their published registration | UA) that have been vetted as per their published registration | |||
policies, and those DIMEs have been marked, by the owner (individual | policies, and those DIMEs have been marked, by the owner (individual | |||
or organizational) of the Observer, as per that owner's policy, as | or organizational) of the Observer, as per that owner's policy, as | |||
trusted to register DETs only for trusted parties. | trusted to register DETs only for trusted parties. | |||
A.7. Questionable: Orange | A.7. Questionable: Orange | |||
A state where there is a mix of authentication messages received that | A state where there is a mix of authentication messages received that | |||
are Verified (Appendix A.5) and Unverified (Appendix A.8). | are Verified (Appendix A.5) and Unverified (Appendix A.8). | |||
Transition to this state is from Verified if a subsequent message | State transitions from Verified to Questionable if a subsequent | |||
fails verification so would have otherwise been marked Unverified, or | message fails verification, so it would have otherwise been marked | |||
from Unverified if a subsequent message passes verification or | Unverified. State transitions from Unverified to Questionable if a | |||
validation so would otherwise have been marked Verified, or from | subsequent message passes verification or validation, so it would | |||
either of those state upon mixed results on the requirement of | otherwise have been marked Verified. It may transition from either | |||
of those states upon mixed results on the requirement of | ||||
Section 6.4.2. | Section 6.4.2. | |||
A.8. Unverified: Red | A.8. Unverified: Red | |||
A state where all authentication messages that have been received, up | A state where all authentication messages that have been received | |||
to that point, from that claimed sender, failed signature | from that claimed sender up to that point failed signature | |||
verification or the requirement of Section 6.4.2. | verification or the requirement of Section 6.4.2. | |||
A.9. Conflicting: Purple | A.9. Conflicting: Purple | |||
A state where there is a mix of authentication messages received that | A state where there is a mix of authentication messages received that | |||
are Trusted (Appendix A.6) and Unverified (Appendix A.8) and the | are Trusted (Appendix A.6) and Unverified (Appendix A.8) and the | |||
public key of the aircraft is marked as trusted. | public key of the aircraft is marked as trusted. | |||
Transition to this state is from Trusted if a subsequent message | State transitions from Trusted to Conflicting if a subsequent message | |||
fails verification so would have otherwise been marked Unverified, or | fails verification, so it would have otherwise been marked | |||
from Unverified if a subsequent message passes verification or | Unverified. State transitions from Unverified to Conflicting if a | |||
validation and policy checks so would otherwise have been marked | subsequent message passes verification or validation and policy | |||
Trusted, or from either of those state upon mixed results on the | checks, so it would otherwise have been marked Trusted. It may | |||
transition from either of those states upon mixed results on the | ||||
requirement of Section 6.4.2. | requirement of Section 6.4.2. | |||
Appendix B. Operational Recommendation Analysis | Appendix B. Operational Recommendation Analysis | |||
The recommendations found in Section 6.4 may seem heavy handed and | The recommendations in Section 6.4 may seem heavy-handed and | |||
specific. This informative appendix lays out the math and | specific. This informative appendix lays out the math and | |||
assumptions made to come to the recommendations listed there as well | assumptions made that resulted in those recommendations and provides | |||
as an example. | an example. | |||
In many jurisdictions, the required ASTM Messages to be transmitted | In many jurisdictions, the required ASTM Messages to be transmitted | |||
every second are: Basic ID (0x1), Location (0x2), and System (0x4). | every second are: Basic ID (0x1), Location (0x2), and System (0x4). | |||
Typical implementations will most likely send at a higher rate (2x | Typical implementations will most likely send at a higher rate (2x | |||
sets per cycle) resulting in 6 frames sent per cycle. Transmitting | sets per cycle) resulting in 6 frames sent per cycle. Transmitting | |||
this set of message more than once a second is not discouraged but | this set of messages more than once a second is not discouraged, but | |||
awareness is needed to avoid congesting the RF spectrum, causing | awareness is needed to avoid congesting the RF spectrum, causing | |||
further issues. | further issues. | |||
Informational Note: In Europe, the Operator ID Message (0x5) is | Informational Note: In Europe, the Operator ID Message (0x5) is also | |||
also required. In Japan, two Basic ID (0x0), Location (0x1), and | required. In Japan, two Basic ID (0x0), Location (0x1), and | |||
Authentication (0x2) are required. Self ID (0x3) is optional but | Authentication (0x2) are required. Self ID (0x3) is optional but can | |||
can carry Emergency Status information. | carry Emergency Status information. | |||
B.1. Page Counts vs Frame Counts | B.1. Page Counts vs Frame Counts | |||
There are two formulas to determine the number of Authentication | There are two formulas to determine the number of Authentication | |||
Pages required, one for Wrapper: | Pages required. The following formula is for Wrapper: | |||
<CODE BEGINS> | <CODE BEGINS> | |||
wrapper_struct_size = 89 + (25 * num_astm_messages) | wrapper_struct_size = 89 + (25 * num_astm_messages) | |||
wrapper_page_count = ceiling((wrapper_struct_size - 17) / 23) + 1 | wrapper_page_count = ceiling((wrapper_struct_size - 17) / 23) + 1 | |||
<CODE ENDS> | <CODE ENDS> | |||
and one for Manifest: | ||||
The following formula is for Manifest: | ||||
<CODE BEGINS> | <CODE BEGINS> | |||
manifest_struct_size = 89 + (8 * (num_astm_hashes + 3)) | manifest_struct_size = 89 + (8 * (num_astm_hashes + 3)) | |||
manifest_page_count = ceiling((manifest_struct_size - 17) / 23) + 1 | manifest_page_count = ceiling((manifest_struct_size - 17) / 23) + 1 | |||
<CODE ENDS> | <CODE ENDS> | |||
A similar formula can be applied to Link as they are of fixed size: | A similar formula can be applied to Links, as they are of fixed size: | |||
<CODE BEGINS> | <CODE BEGINS> | |||
link_page_count = ceiling((137 - 17) / 23) + 1 = 7 | link_page_count = ceiling((137 - 17) / 23) + 1 = 7 | |||
<CODE ENDS> | <CODE ENDS> | |||
Comparing Wrapper and Manifest Authentication Message page counts | Comparing Wrapper and Manifest Authentication Message page counts | |||
against total frame counts we have the following: | against total frame counts, we have the following: | |||
+==========+=========+==========+=================+===============+ | +==========+=========+==========+=================+===============+ | |||
| ASTM | Wrapper | Manifest | ASTM Messages + | ASTM Messages | | | ASTM | Wrapper | Manifest | ASTM Messages + | ASTM Messages | | |||
| Messages | (w/FEC) | (w/FEC) | Wrapper (w/FEC) | + Manifest | | | Messages | (w/FEC) | (w/FEC) | Wrapper (w/FEC) | + Manifest | | |||
| | | | | (w/FEC) | | | | | | | (w/FEC) | | |||
+==========+=========+==========+=================+===============+ | +==========+=========+==========+=================+===============+ | |||
| 0 | 5 (6) | 6 (7) | 5 (6) | 6 (7) | | | 0 | 5 (6) | 6 (7) | 5 (6) | 6 (7) | | |||
+----------+---------+----------+-----------------+---------------+ | +----------+---------+----------+-----------------+---------------+ | |||
| 1 | 6 (7) | 6 (7) | 7 (8) | 7 (8) | | | 1 | 6 (7) | 6 (7) | 7 (8) | 7 (8) | | |||
+----------+---------+----------+-----------------+---------------+ | +----------+---------+----------+-----------------+---------------+ | |||
skipping to change at page 43, line 50 ¶ | skipping to change at line 1904 ¶ | |||
+----------+---------+----------+-----------------+---------------+ | +----------+---------+----------+-----------------+---------------+ | |||
| 8 | N/A | 8 (9) | N/A | 16 (17) | | | 8 | N/A | 8 (9) | N/A | 16 (17) | | |||
+----------+---------+----------+-----------------+---------------+ | +----------+---------+----------+-----------------+---------------+ | |||
| 9 | N/A | 9 (10) | N/A | 18 (19) | | | 9 | N/A | 9 (10) | N/A | 18 (19) | | |||
+----------+---------+----------+-----------------+---------------+ | +----------+---------+----------+-----------------+---------------+ | |||
| 10 | N/A | 9 (10) | N/A | 19 (20) | | | 10 | N/A | 9 (10) | N/A | 19 (20) | | |||
+----------+---------+----------+-----------------+---------------+ | +----------+---------+----------+-----------------+---------------+ | |||
| 11 | N/A | 9 (11) | N/A | 20 (22) | | | 11 | N/A | 9 (11) | N/A | 20 (22) | | |||
+----------+---------+----------+-----------------+---------------+ | +----------+---------+----------+-----------------+---------------+ | |||
Table 5: Page & Frame Counts | Table 5: Page and Frame Counts | |||
Link shares the same page counts as Manifest with 5 ASTM Messages. | Link shares the same page counts as Manifest with 5 ASTM Messages. | |||
B.1.1. Special Cases | B.1.1. Special Cases | |||
B.1.1.1. Zero ASTM Messages | B.1.1.1. Zero ASTM Messages | |||
Zero ASTM Messages in Table 5 is where Extended Wrapper | Zero ASTM Messages (see Table 5) is where Extended Wrapper | |||
(Section 4.3.2) without FEC is used in Message Packs. With a max of | (Section 4.3.2) without FEC is used in Message Packs. With a maximum | |||
9 "message slots" in a Message Pack an Extended Wrapper fills 5 | of nine "message slots" in a Message Pack, an Extended Wrapper fills | |||
slots, thus can authenticate up to 4 ASTM Messages co-located in the | five slots; thus it can authenticate up to four ASTM Messages co- | |||
same Message Pack. | located in the same Message Pack. | |||
B.1.1.2. Eleven ASTM Messages | B.1.1.2. Eleven ASTM Messages | |||
Eleven ASTM Messages in Table 5 is where a Manifest with FEC invokes | Eleven ASTM Messages (see Table 5) is where a Manifest with FEC | |||
the situation mentioned in Section 5.3. | invokes the situation mentioned in Section 5.3. | |||
Eleven is the max number of ASTM Messages Hashes that can be | Eleven is the maximum number of ASTM Message Hashes that can be | |||
supported resulting in 14 total hashes. This completely fills the | supported resulting in 14 total hashes. This completely fills the | |||
evidence section of the structure making its total size 200 octets. | evidence section of the structure making its total size 200 octets. | |||
This fits on exactly 9 Authentication Pages ((201 - 17) / 23 == 8) so | This fits on exactly 9 Authentication Pages ((201 - 17) / 23 == 8), | |||
when the ADL is added it is placed on the next page (Page 10). Per | so when the ADL is added, it is placed on the next page (Page 10). | |||
rule 1 in Section 5.1 this means that all of Page 10 is null padded | Per rule 1 in Section 5.1, this means that all of Page 10 is null | |||
(expect the ADL octet) and FEC data fills Page 11, resulting in a | padded (expect the ADL octet) and FEC data fills Page 11, resulting | |||
plus two page count when FEC is applied. | in a plus-two page count when FEC is applied. | |||
This drives the recommendation is Section 4.4 to only use up to 10 | This drives the recommendation is Section 4.4 to only use up to 10 | |||
ASTM Message Hashes and not 11. | ASTM Message Hashes, not 11. | |||
B.2. Full Authentication Example | B.2. Full Authentication Example | |||
This example is focused on showing that 100% of ASTM Messages can be | This example is focused on showing that 100% of ASTM Messages can be | |||
authenticated over Legacy Transports with up to 125% overhead in | authenticated over Legacy Transports with up to 125% overhead in | |||
Authentication Pages. Extended Transports is not shown as | Authentication Pages. Extended Transport is not shown as | |||
Authentication with DRIP in that case is covered using Extended | Authentication with DRIP in that case is covered using Extended | |||
Wrapper (Section 4.3.2). Two ASTM Message Packs are sent in a given | Wrapper (Section 4.3.2). Two ASTM Message Packs are sent in a given | |||
cycle: one containing up to 4 ASTM Messages and an Extended Wrapper | cycle: one containing up to four ASTM Messages and an Extended | |||
(authenticating the pack) and one containing a Link message with a | Wrapper (authenticating the pack), and one containing a Link message | |||
Broadcast Endorsement and up to two other ASTM Messages. | with a Broadcast Endorsement and up to two other ASTM Messages. | |||
This example transmit scheme covers and meets every known regulatory | This example transmit scheme covers and meets every known regulatory | |||
case enabling manufacturers to use the same firmware worldwide. | case enabling manufacturers to use the same firmware worldwide. | |||
+------------------------------------------------------+ | +------------------------------------------------------+ | |||
| Frame Slots | | | Frame Slots | | |||
| 00 - 04 | 05 - 07 | 08 - 16 | 17 | | | 00 - 04 | 05 - 07 | 08 - 16 | 17 | | |||
+-------------------+---------------+---------+--------+ | +-------------------+---------------+---------+--------+ | |||
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[0] | | | {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[0] | | |||
+-------------------+---------------+---------+--------+ | +-------------------+---------------+---------+--------+ | |||
skipping to change at page 45, line 44 ¶ | skipping to change at line 1988 ¶ | |||
L[y,z] = DRIP Link Authentication Message (0x2) | L[y,z] = DRIP Link Authentication Message (0x2) | |||
W[y,z] = DRIP Wrapper Authentication Message (0x2) | W[y,z] = DRIP Wrapper Authentication Message (0x2) | |||
M[y,z] = DRIP Manifest Authentication Message (0x2) | M[y,z] = DRIP Manifest Authentication Message (0x2) | |||
y = Start Page | y = Start Page | |||
z = End Page | z = End Page | |||
# = Empty Frame Slot | # = Empty Frame Slot | |||
* = Message in DRIP Manifest Authentication Message | * = Message in DRIP Manifest Authentication Message | |||
Figure 13: Full Authenticated Legacy Transport Transmit Schedule | Figure 13: Example of a Fully Authenticated Legacy Transport | |||
Example | Transmit Schedule | |||
Every common required message (Basic ID, Location and System) is sent | Every common required message (Basic ID, Location, and System) is | |||
twice plus Operator ID and Self ID in a single second. The Manifest | sent twice along with Operator ID and Self ID in a single second. | |||
is over all messages (8) in slots 00 - 04 and 05 - 07. | The Manifest is over all messages (8) in slots 00 - 04 and 05 - 07. | |||
In two seconds either a Link or Wrapper are sent. The content and | In two seconds, either a Link or Wrapper are sent. The content and | |||
order of Links and Wrappers runs as follows: | order of Links and Wrappers runs as follows: | |||
Link: HDA on UA | Link: HDA on UA | |||
Link: RAA on HDA | Link: RAA on HDA | |||
Link: HDA on UA | Link: HDA on UA | |||
Link: Apex on RAA | Link: Apex on RAA | |||
Link: HDA on UA | Link: HDA on UA | |||
Link: RAA on HDA | Link: RAA on HDA | |||
Link: HDA on UA | Link: HDA on UA | |||
Wrapper: Location (0x1), System (0x4) | Wrapper: Location (0x1), System (0x4) | |||
Link: HDA on UA | Link: HDA on UA | |||
Link: RAA on HDA | Link: RAA on HDA | |||
Link: HDA on UA | Link: HDA on UA | |||
Link: Apex on RAA | Link: Apex on RAA | |||
Link: HDA on UA | Link: HDA on UA | |||
Link: RAA on HDA | Link: RAA on HDA | |||
Link: HDA on UA | Link: HDA on UA | |||
Wrapper: Location (0x1), System (0x4) | Wrapper: Location (0x1), System (0x4) | |||
Link: IANA on UAS RID Apex | Link: IANA on UAS RID Apex | |||
With perfect receipt of all messages, in 8 seconds all messages (up | With perfect receipt of all messages, all messages (up to that point | |||
to that point then all in future) are authenticated using the | then all in future) are authenticated within 8 seconds using the | |||
Manifest. Within 136 seconds the entire Broadcast Endorsement chain | Manifest. Within 136 seconds, the entire Broadcast Endorsement chain | |||
is received and can be validated; interspersed with 4 messages | is received and can be validated; interspersed with four messages | |||
directly signed over via Wrapper. | directly signed over via Wrapper. | |||
B.2.1. Raw Example | B.2.1. Raw Example | |||
Assuming the following DET and HI: | Assuming the following DET and HI: | |||
2001:3f:fe00:105:a29b:3ff4:2226:c04e | 2001:3f:fe00:105:a29b:3ff4:2226:c04e | |||
b5fef530d450dedb59ebafa18b00d7f5ed0ac08a81975034297bea2b00041813 | b5fef530d450dedb59ebafa18b00d7f5ed0ac08a81975034297bea2b00041813 | |||
The following ASTM Messages to be sent in a single second: | The following ASTM Messages are to be sent in a single second: | |||
0240012001003ffe000105a29b3ff42226c04e000000000000 | 0240012001003ffe000105a29b3ff42226c04e000000000000 | |||
12000000000000000000000000000000000000000060220000 | 12000000000000000000000000000000000000000060220000 | |||
32004578616d706c652053656c662049440000000000000000 | 32004578616d706c652053656c662049440000000000000000 | |||
420000000000000000000100000000000000000010ea510900 | 420000000000000000000100000000000000000010ea510900 | |||
52004578616d706c65204f70657261746f7220494400000000 | 52004578616d706c65204f70657261746f7220494400000000 | |||
0240012001003ffe000105a29b3ff42226c04e000000000000 | 0240012001003ffe000105a29b3ff42226c04e000000000000 | |||
12000000000000000000000000000000000000000060220000 | 12000000000000000000000000000000000000000060220000 | |||
420000000000000000000100000000000000000010ea510900 | 420000000000000000000100000000000000000010ea510900 | |||
This is Link with FEC that would be spread out over 8 seconds: | This is a Link with FEC that would be spread out over 8 seconds: | |||
2250078910ea510904314b8564b17e66662001003ffe000105 | 2250078910ea510904314b8564b17e66662001003ffe000105 | |||
2251a29b3ff42226c04eb5fef530d450dedb59ebafa18b00d7 | 2251a29b3ff42226c04eb5fef530d450dedb59ebafa18b00d7 | |||
2252f5ed0ac08a81975034297bea2b000418132001003ffe00 | 2252f5ed0ac08a81975034297bea2b000418132001003ffe00 | |||
22530105b82bf1c99d87273103fc83f6ecd9b91842f205c222 | 22530105b82bf1c99d87273103fc83f6ecd9b91842f205c222 | |||
2254dd71d8e165ad18ca91daf9299a73eec850c756a7e9be46 | 2254dd71d8e165ad18ca91daf9299a73eec850c756a7e9be46 | |||
2255f51dddfa0f09db7bfdde14eec07c7a6dd1061c1d5ace94 | 2255f51dddfa0f09db7bfdde14eec07c7a6dd1061c1d5ace94 | |||
2256d9ad97940d280000000000000000000000000000000000 | 2256d9ad97940d280000000000000000000000000000000000 | |||
2257a03b0f7a6feb0d198167045058cfc49f73129917024d22 | 2257a03b0f7a6feb0d198167045058cfc49f73129917024d22 | |||
End of changes. 228 change blocks. | ||||
615 lines changed or deleted | 622 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |