rfc9575v1acks.txt   rfc9575.txt 
Internet Engineering Task Force (IETF) A. Wiethuechter, Ed. Internet Engineering Task Force (IETF) A. Wiethuechter, Ed.
Request for Comments: 9575 S. Card Request for Comments: 9575 S. Card
Category: Standards Track AX Enterprize, LLC Category: Standards Track AX Enterprize, LLC
ISSN: 2070-1721 R. Moskowitz ISSN: 2070-1721 R. Moskowitz
HTT Consulting HTT Consulting
April 2024 May 2024
DRIP Entity Tag Authentication Formats and Protocols for Broadcast DRIP Entity Tag Authentication Formats and Protocols for Broadcast
Remote Identification Remote Identification
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
skipping to change at line 71 skipping to change at line 71
3. UAS RID Authentication Background and Procedures 3. UAS RID Authentication Background and Procedures
3.1. DRIP Authentication Protocol Description 3.1. DRIP Authentication Protocol Description
3.1.1. Usage of DNS 3.1.1. Usage of DNS
3.1.2. Providing UAS RID Trust 3.1.2. Providing UAS RID Trust
3.2. ASTM Authentication Message Framing 3.2. ASTM Authentication Message Framing
3.2.1. Authentication Page 3.2.1. Authentication Page
3.2.2. Authentication Payload Field 3.2.2. Authentication Payload Field
3.2.3. Specific Authentication Method (SAM) 3.2.3. Specific Authentication Method (SAM)
3.2.4. ASTM Broadcast RID Constraints 3.2.4. ASTM Broadcast RID Constraints
4. DRIP Authentication Formats 4. DRIP Authentication Formats
4.1. UA Signed Evidence Structure 4.1. UA-Signed Evidence Structure
4.2. DRIP Link 4.2. DRIP Link
4.3. DRIP Wrapper 4.3. DRIP Wrapper
4.3.1. Wrapped Count and Format Validation 4.3.1. Wrapped Count and Format Validation
4.3.2. Wrapper over Extended Transports 4.3.2. Wrapper over Extended Transports
4.3.3. Wrapper Limitations 4.3.3. Wrapper Limitations
4.4. DRIP Manifest 4.4. DRIP Manifest
4.4.1. Hash Count and Format Validation 4.4.1. Hash Count and Format Validation
4.4.2. Manifest Ledger Hashes 4.4.2. Manifest Ledger Hashes
4.4.3. Hash Algorithms and Operation 4.4.3. Hash Algorithms and Operation
4.5. DRIP Frame 4.5. DRIP Frame
skipping to change at line 101 skipping to change at line 101
6.4.1. DRIP Wrapper 6.4.1. DRIP Wrapper
6.4.2. UAS RID Trust Assessment 6.4.2. UAS RID Trust Assessment
7. Summary of Addressed DRIP Requirements 7. Summary of Addressed DRIP Requirements
8. IANA Considerations 8. IANA Considerations
8.1. IANA DRIP Registry 8.1. IANA DRIP Registry
9. Security Considerations 9. Security Considerations
9.1. Replay Attacks 9.1. Replay Attacks
9.2. Wrapper vs Manifest 9.2. Wrapper vs Manifest
9.3. VNA Timestamp Offsets for DRIP Authentication Formats 9.3. VNA Timestamp Offsets for DRIP Authentication Formats
9.4. DNS Security in DRIP 9.4. DNS Security in DRIP
10. Acknowledgments 10. References
11. References 10.1. Normative References
11.1. Normative References 10.2. Informative References
11.2. Informative References
Appendix A. Authentication States Appendix A. Authentication States
A.1. None: Black A.1. None: Black
A.2. Partial: Gray A.2. Partial: Gray
A.3. Unsupported: Brown A.3. Unsupported: Brown
A.4. Unverifiable: Yellow A.4. Unverifiable: Yellow
A.5. Verified: Green A.5. Verified: Green
A.6. Trusted: Blue A.6. Trusted: Blue
A.7. Questionable: Orange A.7. Questionable: Orange
A.8. Unverified: Red A.8. Unverified: Red
A.9. Conflicting: Purple A.9. Conflicting: Purple
Appendix B. Operational Recommendation Analysis Appendix B. Operational Recommendation Analysis
B.1. Page Counts vs Frame Counts B.1. Page Counts vs Frame Counts
B.1.1. Special Cases B.1.1. Special Cases
B.2. Full Authentication Example B.2. Full Authentication Example
B.2.1. Raw Example B.2.1. Raw Example
Acknowledgments
Authors' Addresses 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 Systems (UAS) Remote Identification [F3411]) for Unmanned Aircraft Systems (UAS) Remote Identification
(RID) and tracking do not address trust. However, this is a (RID) and tracking do not address trust. However, this is a
requirement that needs to be addressed for various different parties requirement that needs to be addressed for various different parties
that have a stake in the safe operation of National Airspace Systems that have a stake in the safe operation of National Airspace Systems
(NAS). Drone Remote ID Protocol's (DRIP's) goal is to specify how (NAS). Drone Remote ID Protocol's (DRIP's) goal is to specify how
skipping to change at line 231 skipping to change at line 231
3. UAS RID Authentication Background and Procedures 3. UAS RID Authentication Background and 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 the Type 5 Specific Authentication Method Authentication Types using the Type 0x5 Specific Authentication
(SAM), several of which DRIP defines herein. Method (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 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.
skipping to change at line 307 skipping to change at line 307
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-REG], from the DET Prefix through the hierarchy, defined in [DRIP-REG], from the DET 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 as BE: Parent, Child. For example, Parent, Child will be abbreviated as BE: Parent, Child. For example,
Broadcast Endorsement: RAA, HDA will be abbreviated as BE: RAA, HDA. Broadcast Endorsement: RAA, HDA will be abbreviated as BE: RAA, HDA.
3.1.2.2. UA Signed Evidence 3.1.2.2. UA-Signed Evidence
To prove possession of the private key associated with the DET, the To prove possession of the private key associated with the DET, the
UA MUST send data that is unique and unpredictable but easily UA MUST sign and send data that is unique and unpredictable but
validated by the Observer, that is signed over. The data can be an easily validated by the Observer. The data can be an ASTM Message
ASTM Message that fulfills the requirements to be unpredictable but that fulfills the requirements to be unpredictable but easily
easily validated. An Observer receives this UA signed Evidence from validated. An Observer receives this UA-signed Evidence from DRIP-
DRIP-based Authentication Messages (Sections 4.3 or 4.4). based Authentication Messages (Sections 4.3 or 4.4).
Whether the content is true is a separate question that 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) is 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 they are all 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 it can be supported.
The following subsections 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_.
SAM Type is defined as a field in the Authentication Payload (see The SAM Type is defined as a field in the _Authentication Payload_
Section 3.2.3.1). (see 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 |
| | | |
skipping to change at line 496 skipping to change at line 496
3.2.4.1. Wireless Frame Constraints 3.2.4.1. Wireless Frame Constraints
A UA has the option to broadcast using Bluetooth (4.x and 5.x), Wi-Fi A UA has the option to broadcast using Bluetooth (4.x and 5.x), Wi-Fi
NAN, or IEEE 802.11 Beacon; see Section 6. With Bluetooth, FAA and NAN, or IEEE 802.11 Beacon; see Section 6. With Bluetooth, FAA 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 RID, because Observer transports physical-layer interfaces performing RID, because Observer transports
may be limited. If an Observer can support multiple transports, it may be limited. If an Observer can support multiple transports, it
should be assumed to use the latest data regardless of the transport SHOULD uses (display, report, etc.) the latest data regardless of the
received over. transport over which that data was received.
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] message support larger payloads per frame. As [F3411] message formats are
framing dictated by Bluetooth 4.x constraints is inherited by [F3411] the same for all media, and their framing was designed to fit within
over other media. these legacy constraints, Extended Transports cannot send larger
messages; instead, the Message Pack format encapsulates multiple
messages (each of which fits within these legacy constraints).
It should be noted that Extended Transports by definition have Error By definition Extended Transports provide FEC, but Legacy Transports
Correction built in, unlike Legacy Transports. For Authentication lack FEC. Thus over Legacy Transports, paged Authentication Messages
Messages, this means that over Legacy Transport pages may not may suffer the loss of one or more pages. This would result in
received by Observers resulting in incomplete messages during delivery to the Observer application of incomplete (typically
operation, although the use of DRIP FEC (Section 5) reduces its unusable) messages, so DRIP FEC (Section 5) is specified to enable
likelihood. Authentication Messages sent using Extended Transports recovery of a single lost page and thereby reduce the likelihood of
do not suffer this issue, as the full message (all pages) is sent receiving incompletely reconstructable Authentication Messages.
using a single Message Pack. Furthermore, the use of one-way RF Authentication Messages sent using Extended Transports do not suffer
broadcasts prohibits the use of any congestion-control or loss- this issue, as the full message (all pages) is sent using a single
recovery schemes that require ACKs or NACKs. Message Pack. Furthermore, the use of one-way RF broadcasts
prohibits the use of any congestion-control or loss-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.
skipping to change at line 562 skipping to change at line 566
Valid Not After (VNA) Timestamp: (4 octets) Valid Not After (VNA) Timestamp: (4 octets)
Timestamp denoting the recommended time at which to stop trusting Timestamp denoting the recommended time at which to stop trusting
data. MUST follow the format defined in [F3411] as described data. MUST follow the format defined in [F3411] as described
above. Has an additional offset to push a short time into the above. Has an additional offset to push a short time into the
future (relative to VNB) to avoid replay attacks. The exact future (relative to VNB) to avoid replay attacks. The exact
offset is not defined in this document. Best practice for offset is not defined in this document. Best practice for
identifying an acceptable offset should be used and should take identifying an acceptable offset should be used and should take
into consideration the UA environment, propagation characteristics into consideration the UA environment, propagation characteristics
of the messages being sent, and clock differences between the UA of the messages being sent, and clock differences between the UA
and Observers. A reasonable time would be to set VNA 2 minutes and Observers. For UA signatures in scenarios typical as of 2024,
after VNB. a reasonable offset would be to set VNA approximately 2 minutes
after VNB; see Appendix B for examples that may aid in tuning this
value.
4. DRIP Authentication Formats 4. DRIP Authentication Formats
All formats defined in this section are contained in 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 FEC 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 NOT use it, as it will not fit in the ASTM Authentication Message
with 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
skipping to change at line 627 skipping to change at line 633
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
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 filled in with data in the form of an The Evidence field MUST be 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 a DET [RFC9374] currently being used by the UA for
be a Specific Session ID (a type of UAS ID). authentication; it is assumed to be a Specific Session ID (a type
of UAS ID typically also used by the UA in the Basic ID Message).
UA Signature: (64 octets) UA Signature: (64 octets)
Signature over concatenation of preceding fields (VNB, VNA, Signature over the 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 Hierarchical Host Identity signature algorithm is specified by the Hierarchical Host Identity
Tags (HHIT) Suite ID of the DET. 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-REG] or by extracting it from a Broadcast Endorsement (see in [DRIP-REG] or by extracting it from a Broadcast Endorsement (see
Sections 4.2 and 6.3). Sections 4.2 and 6.3).
4.2. DRIP Link 4.2. DRIP Link
skipping to change at line 674 skipping to change at line 681
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
verification of the contents when the DIME DET/HI is in the verification of the contents when the DIME DET/HI is in the
Observer's cache. It also provides the UA HI, when it is filled with Observer's cache. It also provides the UA HI, when it is filled with
a BE: HDA, UA, so that connectivity is not required when performing a BE: HDA, UA, so that connectivity is not required when performing
signature verification of other DRIP Authentication Messages. signature verification of other DRIP Authentication Messages.
Various Broadcast Endorsements are sent during operation to ensure Various Broadcast Endorsements are sent during each UAS flight
that the full Broadcast Endorsement chain is available offline. See operation to ensure that the full Broadcast Endorsement chain is
Section 6.3 for further details. available offline. See Section 6.3 for further details.
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 Parent | | VNB Timestamp by Parent |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| VNA Timestamp by Parent | | VNA Timestamp by Parent |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
| DET | | DET |
skipping to change at line 764 skipping to change at line 771
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 field of the UA-Signed Evidence Structure (Section 4.1)
(Section 4.1) is populated with up to four ASTM Messages [F3411] in a is populated with up to four ASTM Messages [F3411] in a contiguous
contiguous octet sequence. Only ASTM Message Types 0x0, 0x1, 0x3, octet sequence. Only ASTM Message Types 0x0, 0x1, 0x3, 0x4, and 0x5
0x4, and 0x5 are allowed and must be in Message Type order as defined are allowed and must be in Message Type order as defined by [F3411].
by [F3411]. These messages MUST include the Message Type and These messages MUST include the Message Type and Protocol Version
Protocol Version octet and MUST NOT include the Message Counter octet octet and MUST NOT include the Message Counter octet (thus are fixed
(thus are fixed at 25 octets in length). at 25 octets in length).
4.3.1. Wrapped Count and 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 {
skipping to change at line 803 skipping to change at line 810
Figure 6: Pseudocode 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 to DRIP Wrapper can When using Extended Transports, an optimization to DRIP Wrapper can
be made 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, and then the evidence field is cleared, signature is generated, and then the Evidence field is cleared,
leaving 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 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
skipping to change at line 843 skipping to change at line 850
| | | |
| | | |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
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 the Authentication Message messages in the Message Pack (excluding the Authentication Message
found in the same Message Pack) in ASTM Message Type order and set found in the same Message Pack) in ASTM Message Type order and set
the evidence section of the UA Signed Evidence Structure before the Evidence field 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. The Wrapper provides the same format but over both Transports. The Wrapper provides the same format but over both
Extended and Legacy Transports, which allows 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 that the receiver may not have at the time an verification that the receiver may not have at the time an
Authentication Message is received. This is something the Wrapper, Authentication Message is received. This is something the Wrapper,
skipping to change at line 885 skipping to change at line 892
Wrapper (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 field of the UA-Signed Evidence Structure (Section 4.1)
(Section 4.1) is populated with 8-octet hashes of [F3411] Broadcast is populated with 8-octet hashes of [F3411] Broadcast RID messages
RID messages (up to 11) and three special hashes (Section 4.4.2). (up to 11) and three special hashes (Section 4.4.2). All of these
All of these hashes MUST be concatenated to form a contiguous octet hashes MUST be concatenated to form a contiguous octet sequence in
sequence in the evidence section. It is RECOMMENDED that the maximum the Evidence field. It is RECOMMENDED that the maximum number of
number of ASTM Message Hashes used be 10 (see Appendix B.1.1.2). 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.
skipping to change at line 960 skipping to change at line 967
return DECODE_FAILURE return DECODE_FAILURE
} }
hashCount = (manifestLength / 8) - 3; hashCount = (manifestLength / 8) - 3;
<CODE ENDS> <CODE ENDS>
Figure 9: Pseudocode for Manifest Sanity Check and Number of Figure 9: Pseudocode for Manifest Sanity Check and Number of
Hashes 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 The following three special hashes are included in all Manifests:
Manifest Hash, links to the previous Manifest, and the Current
Manifest Hash is of the Manifest in which it appears. These two * the Previous Manifest Hash links to the previous Manifest.
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. * the Current Manifest Hash is of the Manifest in which it appears.
* the DRIP Link (BE: HDA, UA) Hash ties the endorsed UA key to the
Manifest chain.
The Previous and Current hashes act as a ledger of provenance for the
Manifest chain, which should be traced back if the Observer and UA
were within Broadcast RID wireless range of each other for an
extended period 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 Hashes Typical operation would expect that the list of ASTM Message Hashes
contain nonce-like 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 UA and avoid trivial replay attack vectors (see Section 9.1), at
least one ASTM Message Hash MUST be from an [F3411] message that least one ASTM Message Hash MUST be from an [F3411] message that
satisfies the fourth 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
skipping to change at line 995 skipping to change at line 1010
For ORCHID Generation Algorithms (OGAs) other than "5" (EdDSA/ For ORCHID Generation Algorithms (OGAs) other than "5" (EdDSA/
cSHAKE128) [RFC9374], use the construct appropriate for the cSHAKE128) [RFC9374], use the construct appropriate for the
associated hash. For example, the hash for "2" (ECDSA/SHA-384) is associated hash. For example, the hash for "2" (ECDSA/SHA-384) is
computed as follows: 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 Messaged filled while ASTM Messages are hashed and fill the ASTM Message
Hashes section. When all messages are hashed, the Current Manifest Hashes field. 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 Message 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
that starts with the Message Type and Protocol Version octet along that starts with the Message Type and Protocol Version octet along
skipping to change at line 1022 skipping to change at line 1037
hashed 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 include 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 use of the UA-Signed Evidence
future beyond the previously defined formats (Wrapper and Manifest) Structure (Section 4.1) in the future beyond the previously defined
by the inclusion of a single octet to signal the format of evidence formats (Wrapper and Manifest) by the inclusion of a single octet to
data (up to 111 octets). signal the format of Evidence 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 (2024), there are no
Frame Types other than an Experimental range. defined Frame Types; only an Experimental range has been defined.
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 subtype for future different DRIP Frame formats. It takes As shown in Figure 10, the Frame Type takes the first octet, which
the first octet in Figure 10, leaving 111 octets available for leaves 111 octets available for Frame Evidence Data. See
Frame Evidence Data. See Section 8.1 for Frame Type allocations. Section 8.1 for Frame Type 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 support FEC, Transports. The Bluetooth 4.x Legacy Transport does not support FEC,
so the following application-level scheme is used with DRIP so the following application-level scheme is used with DRIP
Authentication to add some FEC. When sending data over a medium that Authentication to add some FEC. When sending data over a medium that
does not have underlying FEC, for example Bluetooth 4.x, this section does not have underlying FEC, for example Bluetooth 4.x, this section
MUST be used. MUST be used.
skipping to change at line 1206 skipping to change at line 1221
return DECODE_FAILURE return DECODE_FAILURE
} }
// check that byte directly after last auth byte is null // check that byte directly after last auth byte is null
if (auth_data[last_auth_byte + 1] equals null) { if (auth_data[last_auth_byte + 1] equals null) {
return DECODE_FAILURE return DECODE_FAILURE
} }
// we set our presumed Additional Data Length (ADL) // we set our presumed Additional Data Length (ADL)
presumed_adl = auth_data[last_auth_byte + 1] presumed_adl = auth_data[last_auth_byte + 1]
// use the presumed ADL to calculate a presumed LPI // use the presumed ADL to calculate a presumed
//Last Page Index (LPI, a field defined in <xref target="F3411"/>)
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>
skipping to change at line 1284 skipping to change at line 1300
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 rationale can be found in Appendix B. It consists Section 6.3) with rationale can be found in Appendix B. It
of the following recommendations for every second: recommends the following once per 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/Vector, and System)
set of other ASTM Messages (example: Self ID, Operator ID) and one 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)
skipping to change at line 1323 skipping to change at line 1340
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/Vector Messages (Message Type 0x2)
map, display of an embedded Location Message in a DRIP Wrapper can be on a map, display of an embedded Location/Vector Message in a DRIP
marked differently (e.g., via color) to signify trust in the Location Wrapper can be marked differently (e.g., via color) to signify trust
data. in the Location/Vector 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.
A chain of DRIP Links provides trust in a key. A message containing A chain of DRIP Links provides trust in a key. A message, signed by
rapidly changing, not predictable far in advance (relative to typical that key, containing data that changes rapidly and is not predictable
operational flight times) that can be validated by Observers, signed far in advance (relative to typical operational flight times) but
by that key, provides trust that some agent with access to that data that can be validated by Observers, provides trust that some agent
also possesses that key. If the validation involves correlating with access to that data also possesses that key. If the validation
physical world observations of the UA with claims in that data, then involves correlating physical world observations of the UA with
the probability is high that the observed UA is (or is collaborating claims in that data, then the probability is high that the observed
with or observed in real time by) the agent with the key. UA is (or is collaborating 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 threshold limits and what happens failed to validate. Acceptable threshold limits and what happens
skipping to change at line 1392 skipping to change at line 1410
8.1. IANA DRIP Registry 8.1. IANA DRIP Registry
IANA has created the "DRIP SAM Types" and "DRIP Frame Types" IANA has created the "DRIP SAM Types" and "DRIP Frame Types"
registries within the "Drone Remote ID Protocol" registry group registries within the "Drone Remote ID Protocol" registry group
(https://www.iana.org/assignments/drip). (https://www.iana.org/assignments/drip).
DRIP SAM Types: DRIP SAM Types:
This registry is a mirror for SAM Types containing the subset of This registry is a mirror for SAM Types containing the subset of
allocations used by DRIP Authentication Messages. Future allocations used by DRIP Authentication Messages. Future
additions MUST be done through ASTM's designated registrar, which additions MUST be done through ASTM's designated registrar, which
is ICAO [ASTM-Remote-ID] at the time of publication of this RFC. is ICAO [ASTM-Remote-ID] at the time of publication of this RFC
Additions for DRIP will be coordinated by IANA and the ASTM (2024). The registration procedure for DRIP (only) SAM Types is
designated registrar before final publication as Standards Track Standards Action [RFC8126]. Requests for new DRIP SAM Type
RFCs. The following values have been allocated to the IETF: registrations will be coordinated by IANA and the ASTM-designated
registrar of all SAM Types before being documented in Standards
Track 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 | Authenticate full ASTM Messages | | 0x02 | DRIP | Authenticate full ASTM Messages |
| | Wrapper | | | | Wrapper | |
+----------+-----------+---------------------------------------+ +----------+-----------+---------------------------------------+
| 0x03 | DRIP | Authenticate hashes of ASTM Messages | | 0x03 | DRIP | Authenticate hashes of ASTM Messages |
skipping to change at line 1458 skipping to change at line 1478
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 they 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 public key, of a
(Section 4.3) or Manifest (Section 4.4) message, authenticating Wrapper (Section 4.3) or Manifest (Section 4.4) message,
content that is nonce-like, provides trust that the sender actually authenticating content that is nonce-like, provides trust that the
possesses that key. sender actually possesses the corresponding private key.
The term "nonce-like" means the that data is unique, not accurately The term "nonce-like" describes data that is unique, changes
predictable long in advance, and readily validated by the Observer. frequently, is not accurately predictable long in advance, and is
This is described in Section 6.3 (requirement 4) and Section 3.1.2.2. easily validated (i.e., can be checked quickly at low computational
The Location message [F3411] reporting precise UA position and cost using readily available data) by the Observer. A Location/
velocity at a precise and very recent time is to be checked by the Vector Message is an obvious choice. This is described in
Observer against visual observations of the UA within RF. Thus, Section 6.3 (requirement 4) and Section 3.1.2.2. The Location/Vector
Visual Line of Sight is typically the recommended form of this data. Message [F3411] reporting precise UA position and velocity at a
For specification of the foregoing, see Sections 3.1.2 and 6.4.2. precise and very recent time is to be checked by the Observer against
visual observations of the UA within RF. Thus, Visual Line of Sight
is typically the recommended form of this data. 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/Vector or [F3411] System) in a
Manifest. For specification of this last requirement, see Wrapper or 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 of 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 fourth 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 on the full content of one or more
[F3411] messages, providing strong authentication. However, the size [F3411] messages, providing strong authentication. Wrapper is an
attached signature of the full content of one or more [F3411]
messages, providing strong authentication. However, the size
limitation means it cannot support such signatures over other limitation means it cannot support such signatures over other
Authentication Messages; thus, it cannot provide a direct binding to Authentication Messages; thus, it cannot provide a direct binding to
any part of the trust chain (Sections 3.1.2 and 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 number (11 vs 4) of [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 of which may not be and comparing hashes of received messages (some of which may not be
received) with 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/Vector, 2x System, 1x
and 1x Self ID broadcast per second to comply with jurisdiction Operator ID and 1x Self ID broadcast per second to comply with
mandates. Each of these messages is a single frame in size. A Link jurisdiction mandates. Each of these messages is a single frame in
message is 8 frames long (including FEC). This is a base frame count size. A Link message is 8 frames long (including FEC). This is a
of *16 frames*. base frame count of *16 frames*.
When Wrapper is used, up to four 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 size constraints, 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
skipping to change at line 1560 skipping to change at line 1585
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 it is not sufficient to serve this purpose in any scenario, but it is not
limited 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. The
[DRIP-REG] is the main specification for DNS operations in DRIP and main specification for DNS operations in DRIP [DRIP-REG] will specify
as such will specify DRIP usage of best common practices for security applicable best common security practices (e.g., from [RFC9364]).
(such as [RFC9364]).
11. References 10. References
11.1. Normative References 10.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., Chang, S., and R. Perlner, "SHA-3 Derived Kelsey, J., Chang, S., and R. Perlner, "SHA-3 Derived
Functions: cSHAKE, KMAC, TupleHash and ParallelHash", NIST Functions: cSHAKE, KMAC, TupleHash and ParallelHash", NIST
Special Publication 800-185, DOI 10.6028/NIST.SP.800-185, Special Publication 800-185, DOI 10.6028/NIST.SP.800-185,
December 2016, December 2016,
skipping to change at line 1606 skipping to change at line 1630
[RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, [RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
"DRIP Entity Tag (DET) for Unmanned Aircraft System Remote "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023, ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
<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 10.2. Informative References
[ASTM-Remote-ID] [ASTM-Remote-ID]
International Civil Aviation Organization (ICAO), "Remote International Civil Aviation Organization (ICAO), "Remote
ID Number Registration", December 2023, 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-REG] Wiethuechter, A. and J. Reid, "DRIP Entity Tag (DET) [DRIP-REG] 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-15, 1 April Internet-Draft, draft-ietf-drip-registries-15, 1 April
skipping to change at line 1645 skipping to change at line 1669
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 an 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-REG] provides more detail on how these somehow be obtained. [DRIP-REG] provides more detail on how these
keys are stored on the DNS and how DRIP Authentication messages can keys are stored on the DNS and how DRIP Authentication Messages can
be used 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 PKs 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 keys of DIMEs are sent over over the Broadcast RID messages. The keys of DIMEs are sent over
Broadcast RID using the same mechanisms (see Sections 4.2 and 6.3) Broadcast RID using the same mechanisms (see Sections 4.2 and 6.3)
but MAY be sent at a far lower rate due to potential operational but MAY be sent at a far lower rate due to potential operational
constraints (such as saturation of limited bandwidth). As such, constraints (such as saturation of limited bandwidth). As such,
there are scenarios where part of the key-chain may be unavailable at there are scenarios where part of the key-chain may be unavailable at
the moment a full Authentication Message is received and processed. the moment a full Authentication Message is received and processed.
The intent of this informative appendix is to recommend a way to The intent of this informative appendix is to recommend a way 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 briefly describes each state and recommends an
state and a brief description of each. associated color.
+==============+========+===================================+ +==============+========+===================================+
| State | Color | Details | | State | Color | Details |
+==============+========+===================================+ +==============+========+===================================+
| None | Black | No Authentication being received | | None | Black | No Authentication has been or is |
| | | (as yet) | | | | being received (as yet) |
+--------------+--------+-----------------------------------+ +--------------+--------+-----------------------------------+
| Partial | Gray | Authentication being received but | | Partial | Gray | Authentication being received 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 |
+--------------+--------+-----------------------------------+ +--------------+--------+-----------------------------------+
skipping to change at line 1704 skipping to change at line 1728
+--------------+--------+-----------------------------------+ +--------------+--------+-----------------------------------+
| Conflicting | Purple | Evidence of both Trusted and | | 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, and 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 been The default state where authentication information has not yet been
received. received and is not currently being 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 but A state wherein authentication data is being or has been received 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 A state where all Authentication Messages that have been received
from that claimed sender up to that point 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 A state where all Authentication Messages that have been received
from that claimed sender up to that point 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 has been 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).
State transitions from Verified to Questionable if a subsequent State transitions from Verified to Questionable if a subsequent
message fails verification, so it would have otherwise been marked message fails verification, so it would have otherwise been marked
Unverified. State transitions from Unverified to Questionable if a Unverified. State transitions from Unverified to Questionable if a
subsequent message passes verification or validation, so it would subsequent message passes verification or validation, so it would
otherwise have been marked Verified. It may transition from either otherwise have been marked Verified. It may transition from either
of those states upon mixed results on the requirement of 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 A state where all Authentication Messages that have been received
from that claimed sender up to that point 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.
State transitions from Trusted to Conflicting if a subsequent message State transitions from Trusted to Conflicting if a subsequent message
fails verification, so it would have otherwise been marked fails verification, so it would have otherwise been marked
Unverified. State transitions from Unverified to Conflicting if a Unverified. State transitions from Unverified to Conflicting if a
subsequent message passes verification or validation and policy subsequent message passes verification or validation and policy
checks, so it would otherwise have been marked Trusted. It may checks, so it would otherwise have been marked Trusted. It may
transition from either of those states upon mixed results on the 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 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 that resulted in those recommendations and provides assumptions made that resulted in those recommendations and provides
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 (0x0), Location/Vector (0x1), and System
Typical implementations will most likely send at a higher rate (2x (0x4). Typical implementations will most likely send at a higher
sets per cycle) resulting in 6 frames sent per cycle. Transmitting rate (2x sets per cycle) resulting in 6 frames sent per cycle.
this set of messages more than once a second is not discouraged, but Transmitting this set of messages more than once a second is not
awareness is needed to avoid congesting the RF spectrum, causing discouraged, but awareness is needed to avoid congesting the RF
further issues. spectrum, causing further issues.
Informational Note: In Europe, the Operator ID Message (0x5) is also Informational Note: In Europe, the Operator ID Message (0x5) is also
required. In Japan, two Basic ID (0x0), Location (0x1), and required. In Japan, two Basic ID (0x0), Location/Vector (0x1), and
Authentication (0x2) are required. Self ID (0x3) is optional but can Authentication (0x2) are required. Self ID (0x3) is optional but 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. The following formula is 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)
skipping to change at line 1874 skipping to change at line 1898
five slots; thus it can authenticate up to four ASTM Messages co- five slots; thus it can authenticate up to four ASTM Messages co-
located in the 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 (see Table 5) is where a Manifest with FEC Eleven ASTM Messages (see Table 5) is where a Manifest with FEC
invokes the situation mentioned in Section 5.3. invokes the situation mentioned in Section 5.3.
Eleven is the maximum number of ASTM Message 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 field of the UA-Signed Evidence Structure making its total
This fits on exactly 9 Authentication Pages ((201 - 17) / 23 == 8), size 200 octets. This fits on exactly 9 Authentication Pages ((201 -
so when the ADL is added, it is placed on the next page (Page 10). 17) / 23 == 8), so when the ADL is added, it is placed on the next
Per rule 1 in Section 5.1, this means that all of Page 10 is null page (Page 10). Per rule 1 in Section 5.1, this means that all of
padded (expect the ADL octet) and FEC data fills Page 11, resulting Page 10 is null padded (expect the ADL octet) and FEC data fills Page
in a plus-two page count when FEC is applied. 11, resulting 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, 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 Transport is not shown as Authentication Pages. Extended Transports are not shown in this
Authentication with DRIP in that case is covered using Extended example, because, for those, Authentication with DRIP is achieved
Wrapper (Section 4.3.2). Two ASTM Message Packs are sent in a given using Extended Wrapper (Section 4.3.2). Two ASTM Message Packs are
cycle: one containing up to four ASTM Messages and an Extended sent in a given cycle: one containing up to four ASTM Messages and an
Wrapper (authenticating the pack), and one containing a Link message Extended Wrapper (authenticating the pack), and one containing a Link
with a Broadcast Endorsement and up to two other ASTM Messages. message 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 line 1940 skipping to change at line 1965
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: Example of a Fully Authenticated Legacy Transport Figure 13: Example of a Fully Authenticated Legacy Transport
Transmit Schedule Transmit Schedule
Every common required message (Basic ID, Location, and System) is Every common required message (Basic ID, Location/Vector, and System)
sent twice along with Operator ID and Self ID in a single second. is sent twice along with Operator ID and Self ID in a single second.
The Manifest 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 is 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/Vector (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/Vector (0x1), System (0x4)
Link: IANA on UAS RID Apex Link: IANA on UAS RID Apex
With perfect receipt of all messages, all messages (up to that point After perfect receipt of all messages for a period of 8 seconds, all
then all in future) are authenticated within 8 seconds using the messages sent during that period have been authenticated using the
Manifest. Within 136 seconds, the entire Broadcast Endorsement chain Manifest (except for the Authentication Messages themselves). Within
is received and can be validated; interspersed with four messages 136 seconds, the entire Broadcast Endorsement chain is received and
directly signed over via Wrapper. can be validated. Interspersed in this schedule are 4 messages sent
not only in their basic [F3411] form, but also in DRIP Wrapper
messages, together with their attached signatures, to defend against
the possibility of attack against the detached signatures provided by
the Manifest messages.
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 are to be sent in a single second: The following ASTM Messages are to be sent in a single second:
skipping to change at line 2024 skipping to change at line 2053
225008b110ea510903e0dd7c6560115e670000000000000000 225008b110ea510903e0dd7c6560115e670000000000000000
2251d57594875f8608b4d61dc9224ecf8b842bd4862734ed01 2251d57594875f8608b4d61dc9224ecf8b842bd4862734ed01
22522ca2e5f2b8a3e61547b81704766ba3eeb651be7eafc928 22522ca2e5f2b8a3e61547b81704766ba3eeb651be7eafc928
22538884e3e28a24fd5529bc2bd4862734ed012ca2e5f2b8a3 22538884e3e28a24fd5529bc2bd4862734ed012ca2e5f2b8a3
2254e61547b81704766ba3eeb62001003ffe000105a29b3ff4 2254e61547b81704766ba3eeb62001003ffe000105a29b3ff4
22552226c04efb729846e7d110903797066fd96f49a77c5a48 22552226c04efb729846e7d110903797066fd96f49a77c5a48
2256c4c3b330be05bc4a958e9641718aaa31aeabad368386a2 2256c4c3b330be05bc4a958e9641718aaa31aeabad368386a2
22579ed2dce2769120da83edbcdc0858dd1e357755e7860317 22579ed2dce2769120da83edbcdc0858dd1e357755e7860317
2258e7c06a5918ea62a937391cbfe0983539de1b2e688b7c83 2258e7c06a5918ea62a937391cbfe0983539de1b2e688b7c83
10. Acknowledgments Acknowledgments
The authors acknowledge the following individuals:
* Ryan Quigley, James Mussi, and Joseph Stanton of AX Enterprize, * Ryan Quigley, James Mussi, and Joseph Stanton of AX Enterprize,
LLC for early prototyping to find holes in earlier drafts of this LLC for early prototyping to find holes in earlier drafts of this
specification 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, as was 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]) for * 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 regarding the document's * Eric Vyncke (DRIP AD) for his guidance regarding the document's
path to publication path to publication.
* Thanks to the following reviewers: The authors also thank 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)
- Carlos Bernardos (intdir) * Carlos Bernardos (intdir)
- Behcet Sarikaya (iotdir) * Behcet Sarikaya (iotdir)
- Martin Duke (IESG) * Martin Duke (IESG)
- Roman Danyliw (IESG) * Roman Danyliw (IESG)
- Murray Kucherawy (IESG) * Murray Kucherawy (IESG)
- Erik Kline (IESG) * Erik Kline (IESG)
- Warren Kumari (IESG) * Warren Kumari (IESG)
- Paul Wouters (IESG) * Paul Wouters (IESG)
Authors' Addresses Authors' Addresses
Adam Wiethuechter (editor) Adam Wiethuechter (editor)
AX Enterprize, LLC AX Enterprize, LLC
4947 Commercial Drive 4947 Commercial Drive
Yorkville, NY 13495 Yorkville, NY 13495
United States of America United States of America
Email: adam.wiethuechter@axenterprize.com Email: adam.wiethuechter@axenterprize.com
 End of changes. 88 change blocks. 
192 lines changed or deleted 223 lines changed or added

This html diff was produced by rfcdiff 1.48.