RFC 9575
DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast Remote Identification (RID)
RFC 9575: DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast Remote Identification (RID) 🦋
Series: Internet Engineering Task Force (IETF), Request for Comments 9575 Authors: A. Wiethuechter, Ed.; S. Card (AX Enterprize, LLC); R. Moskowitz (HTT Consulting) Category: Standards Track 💅 ISSN: 2070-1721 Date: June 2024 Obsoletes / Updates: none listed in this title block 🌸
Abstract ✨
Okay so this is the big picture bestie 🫶 The Drone Remote Identification Protocol (DRIP) is basically a set of trust rules plus regular check-ins with registries. It levels up Unmanned Aircraft System (UAS) Remote Identification (RID) so anyone nearby can check, right then and there, whether the RID messages they're getting are legit and whether the UAS is trustworthy. That works even for Observers who have no Internet access 😭 This doc defines the DRIP message types and formats that ride inside Broadcast RID Authentication Messages. The whole point is verifying that attached (and recently detached) messages were signed by the registered owner of the DRIP Entity Tag (DET) that they claim. Iconic. 👑
Status of This Memo 🎀
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841.
Want the current status, any errata, or a way to send feedback? Head to https://www.rfc-editor.org/info/rfc9575 💖
Copyright Notice 🌈
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read those carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License. 📜
Table of Contents 🧚
1. Introduction
1.1. DRIP Entity Tag (DET) Authentication Goals for Broadcast
RID
2. Terminology
2.1. Required Terminology
2.2. Definitions
3. UAS RID Authentication Background and Procedures
3.1. DRIP Authentication Protocol Description
3.1.1. Usage of DNS
3.1.2. Providing UAS RID Trust
3.2. ASTM Authentication Message Framing
3.2.1. Authentication Page
3.2.2. Authentication Payload Field
3.2.3. SAM Data Format
3.2.4. ASTM Broadcast RID Constraints
4. DRIP Authentication Formats
4.1. UA-Signed Evidence Structure
4.2. DRIP Link
4.3. DRIP Wrapper
4.3.1. Wrapped Count and Format Validation
4.3.2. Wrapper over Extended Transports
4.3.3. Wrapper Limitations
4.4. DRIP Manifest
4.4.1. Hash Count and Format Validation
4.4.2. Manifest Ledger Hashes
4.4.3. Hash Algorithms and Operation
4.5. DRIP Frame
5. Forward Error Correction
5.1. Encoding
5.2. Decoding
5.3. FEC Limitations
6. Requirements and Recommendations
6.1. Legacy Transports
6.2. Extended Transports
6.3. Authentication
6.4. Operational
6.4.1. DRIP Wrapper
6.4.2. UAS RID Trust Assessment
7. Summary of Addressed DRIP Requirements
8. IANA Considerations
8.1. IANA DRIP Registry
9. Security Considerations
9.1. Replay Attacks
9.2. Wrapper vs Manifest
9.3. VNA Timestamp Offsets for DRIP Authentication Formats
9.4. DNS Security in DRIP
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Authentication States
A.1. None: Black
A.2. Partial: Gray
A.3. Unsupported: Brown
A.4. Unverifiable: Yellow
A.5. Verified: Green
A.6. Trusted: Blue
A.7. Questionable: Orange
A.8. Unverified: Red
A.9. Conflicting: Purple
Appendix B. Operational Recommendation Analysis
B.1. Page Counts vs Frame Counts
B.1.1. Special Cases
B.2. Full Authentication Example
B.2.1. Raw Example
Acknowledgments
Authors' Addresses1. Introduction ✨
Okay so the early rules (think [FAA-14CFR]) and standards (think [F3411]) for UAS Remote Identification and tracking don't deal with trust at all 🙈 That's a problem, because lots of different people have a stake in keeping the National Airspace Systems (NAS) safe. DRIP's goal is to show how RID can be trustworthy and still available, both on the Internet and in local-only setups, especially in emergencies 🚨
UAS work in a pretty chaotic environment. A small Unmanned Aircraft (UA) has very little room for computing and talking to others. UAS RID also has to work on cheap, everyday devices without any modification, which really narrows the options 💀 Most small UAS are Internet of Things (IoT) devices, even if nobody thinks of them that way. So a lot of IoT considerations apply here too. Some DRIP work, even though it's currently scoped tightly to UAS RID, will probably be useful for other IoT use cases 🌸
There are two main ways UAS RID communicates: Broadcast and Network. This doc is all about adding trust to Broadcast RID (Section 3.2 of [RFC9153] and Section 1.2.2 of [RFC9434]). As [F3411] defines and [RFC9153] and [RFC9434] outline, Broadcast RID is a one-way Radio Frequency (RF) transmission of Media Access Control (MAC) layer messages over Bluetooth or Wi-Fi 📡
Senders can claim anything the RID message formats allow, and that's the core issue 😤 Observers have no standard way to assess whether the content is trustworthy, verify that the messages actually came from the UA they name, or confirm that the named UA is the one they're visually looking at. Honestly, Observers can't even tell whether a UA sent the messages or whether some other transmitter, like a laptop or smartphone within direct wireless broadcast range, spoofed them. Authentication is the main strategy for fixing this 🔐
1.1. DRIP Entity Tag (DET) Authentication Goals for Broadcast RID
ASTM [F3411] Authentication Messages (Message Type 0x2), when used with DET-based formats [RFC9374], give a high level of trust that the content of other ASTM Messages came from their claimed registered source 🫶 The idea is to give Observers trustworthy, immediately actionable info. Appendix A gives a high-level tour of the different trustworthiness states you can use with these formats ✨
This authentication approach also adds some error correction (Section 5). That's a big deal because the United States (US) Federal Aviation Administration (FAA) [FAA-14CFR] requires it, and [F3411] doesn't provide it over Legacy Transports (Bluetooth 4.x) 🙌
These DRIP upgrades to ASTM's RID and tracking spec [F3411] also make things work for Observers who might be offline when they're observing 🌙
Section 7 sums up the DRIP requirements [RFC9153] that this doc addresses 💜
2. Terminology 🎀
2.1. Required Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 💅
2.2. Definitions
This doc uses terms like CAA, Observer, USS, and UTM, which come from [RFC9153]. Some others, like DIME, are from [RFC9434], and the rest (HI, DET, RAA, HDA, and so on) are from [RFC9374] 📚
The doc also defines the following terms for itself:
- Extended Transports: Using extended advertisements (Bluetooth 5.x), service info (Wi-Fi Neighbor Awareness Networking (NAN)), or IEEE 802.11 Beacons with the vendor-specific information element, as specified in [F3411]. Must use ASTM Message Pack (Message Type 0xF). 🌈
- Legacy Transports: Using broadcast frames (Bluetooth 4.x), as specified in [F3411]. 🍓
- Manifest: An immutable list of items being transported (in this specific case, over wireless communication). 🧚
- Observation Session: The stretch of time when a given Observer's receiver is processing (even if only on and off) a series of UAS RID messages. At least some of them use DRIP extensions to [F3411], and they all nominally come from the same UA running a single flight operation ✈️
Note: For the rest of this document, Broadcast Endorsement: Parent, Child gets shortened to BE: Parent, Child. So, for example, Broadcast Endorsement: RAA, HDA becomes BE: RAA, HDA. 📝
3. UAS RID Authentication Background and Procedures 🦋
3.1. DRIP Authentication Protocol Description
[F3411] only defines the framing for Authentication Messages. It doesn't define authentication formats or methods. It clearly expects several signature options, but it doesn't fully spell them out 🤷♀️ Annex A1 of [F3411] describes a Broadcast Authentication Verifier Service, which leans really hard on the Observer being connected to the Internet in real time. Thankfully, [F3411] also lets third parties use standard Authentication Types through the Type 0x5 Specific Authentication Method (SAM), and DRIP defines several of those in this doc 🙌
Specific formats are a huge piece of the chain of trust for a UAS ID, so standardizing them matters. Per Section 5 of [RFC9434], Authentication formats are needed to pass along info so Observers can decide what to trust. Nothing that already exists (in [F3411] or in other organizations using this feature) does that job, and that gap is exactly why this document exists 💖
3.1.1. Usage of DNS ✨
Okay bestie, let's talk DNS 🌐. Like most aviation stuff, the big goals here are security and, ultimately, safety 🛫. DRIP leans on DNS for some of its jobs, so DRIP's use of DNS has to be protected with best security practices 🔐. A lot of the participating nodes are gonna have limited processing power and/or poor, low-bandwidth QoS paths 🥲. Which security techniques make sense depends heavily on the UAS and Observer situation, so picking specific DNS security options, transports, and so on is outside the scope of this document (see also Section 9.4) 💅.
Now the important rules 👑. In DRIP, Observers MUST validate all signatures received. This means the Host Identity (HI) has to correspond to a DET [RFC9374]. HIs MAY be pulled from a local cache, if there is one 🗂️. The local cache comes pre-configured with well-known HIs (like the ones belonging to CAA DIMEs), and it gets more entries from received Broadcast Endorsements (BEs) (Section 3.1.2.1) and DNS lookups (when available) 🧚.
The Observer MUST perform a DNS query, when connectivity allows, to get a HI it doesn't know yet 🔍. If a query can't be performed, the message SHOULD be cached by the Observer so it can be validated once the HI shows up 📦.
A more comprehensive spec for DRIP's use of DNS is out of scope for this document and lives in [DRIP-REG] 📚.
3.1.2. Providing UAS RID Trust
For DRIP, two actions together give an Observer a way to trust UAS RID using Authentication Messages 🦋.
First up is sending an entire trust chain via Broadcast Endorsements (Section 3.1.2.1) 🔗. This gives you a hierarchy of DIMEs, all the way down to an individual UA's registration of a claimed DET and its corresponding HI (public key). But on its own this can't be trusted as relevant to the UA being observed, because replay attacks are trivial 🙈.
Once an Observer has gathered a complete key trust chain (from pre-configured cache entries, Broadcast Endorsements received over the air, and/or DNS lookups) and verified all of its links, that device can trust that the claimed DET and corresponding public key are properly registered 💖. BUT the UA still hasn't been proven to possess the matching private key 😤.
Second is the UA proving it has the key by dynamically signing data that is unique and unpredictable but easily verified by the 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 trust assessment (Section 6.4.2) 🫶.
3.1.2.1. DIME Endorsements of Subordinate DETs
Observers receive DRIP Link Authentication Messages (Section 4.2) that contain Broadcast Endorsements from DIMEs of child DET registrations 💌. A series of these Endorsements confirms a path through the hierarchy (defined in [DRIP-REG]) from the DET Prefix Owner all the way down to an individual UA DET registration 🌳.
3.1.2.2. UA-Signed Evidence
To prove it has the private key tied to the DET, the UA MUST sign and send data that is unique and unpredictable but easily validated by the Observer 🫣. That data can be an ASTM Message, as long as it meets the requirements of being unpredictable but easily validated 🎀. An Observer gets this UA-signed Evidence from DRIP-based Authentication Messages (Sections 4.3 or 4.4) 📨. The Observer must verify the signature (cryptographically, as specified in Section 3.1.1) and validate the signed content (via non-cryptographic means, as specified in Section 6.3) 🕵️♀️.
Whether the content is actually true is a separate question that DRIP can't answer 🙃. Checking it with observable and/or out-of-band data (Section 6) is possible and encouraged 🌸.
3.2. ASTM Authentication Message Framing
The Authentication Message (Message Type 0x2) is super unique in the ASTM [F3411] Broadcast standard, because it's the only message that can be larger than the Legacy Transport size 🧩. To get around that transport size limit, it's defined as a set of "pages," and each page fits into a single Legacy Transport frame 📄. On Extended Transports, pages are still used, but they all fit in a single frame 🚀.
Informational Note: Message Pack (Message Type 0xF) is also larger than the Legacy Transport size, but it's only allowed on Extended Transports where it can be supported 💡.
The next subsections are a quick overview of the Authentication Message format defined in [F3411]. It's there to give you context on how DRIP Authentication fills in and uses the various fields that ASTM [F3411] already defined 🧠.
3.2.1. Authentication Page
This document uses Authentication Type 0x5 (Specific Authentication Method (SAM)) as the main authentication container, and it defines a set of SAM Types in Section 4 🎁. The Authentication Type is encoded in every Authentication Page in the Page Header. The SAM Type is a field in the Authentication Payload (see Section 3.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
+---------------+---------------+---------------+---------------+
| Page Header | |
+---------------+ |
| |
| |
| Authentication Payload |
| |
| |
+---------------+---------------+---------------+---------------+Figure 1: Standard ASTM Authentication Message Page
- Page Header (1 octet): Authentication Type (4 bits) and Page Number (4 bits) 📑
- Authentication Payload (23 octets per page): The Authentication Payload, including headers. Null padded. See Section 3.2.2 🧁
The Authentication Message is laid out as a set of pages, like in Figure 1 🧱. There's a technical maximum of 16 pages (indexed 0 to 15) that can be sent for a single Authentication Message, and each page carries a max of 23 octets of Authentication Payload. See Section 3.2.4 for more details 👀. Over Legacy Transports, these messages get "fragmented," with each page sent in its own separate Legacy Transport frame 🧃.
Whether it's one Authentication Message or a bunch of fragmented Authentication Message Pages, the whole thing gets wrapped in outer ASTM framing and the specific link framing 🎀.
3.2.2. Authentication Payload Field
Figure 2 is the source data view of the data fields in the Authentication Message, as defined by [F3411] 🗺️. This data goes into the Authentication Payload shown in Figure 1, which spans multiple Authentication Pages ✨.
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
+---------------+---------------+---------------+---------------+
| Authentication Headers |
| +---------------+---------------+
| | |
+---------------+---------------+ |
. .
. Authentication Data / Signature .
. .
| |
+---------------+---------------+---------------+---------------+
| ADL | |
+---------------+ |
. .
. Additional Data .
. .
| |
+---------------+---------------+---------------+---------------+Figure 2: ASTM Authentication Message Fields
- Authentication Headers (6 octets): As defined in [F3411] 📋.
- Authentication Data / Signature (0 to 255 octets): Opaque authentication data. The length of this payload is known through a field in the Authentication Headers (defined in [F3411]) 🔏.
- Additional Data Length (ADL) (1 octet - unsigned): The length in octets of Additional Data. The value of
ADLis calculated as the minimum of 361 - Authentication Data / Signature Length and 255. It's only present with Additional Data 🔢. - Additional Data (
ADLoctets): Data that follows the Authentication Data / Signature but is not considered part of the Authentication Data, so it isn't covered by a signature. For DRIP, this field carries Forward Error Correction (FEC) generated by transmitters and parsed by receivers, as defined in Section 5 🛠️.
3.2.3. SAM Data Format
Figure 3 shows the general format for holding authentication data when using SAM. It goes inside the Authentication Data / Signature field from Figure 2 🧩.
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
+---------------+---------------+---------------+---------------+
| SAM Type | |
+---------------+ |
. .
. SAM Authentication Data .
. .
| |
+---------------+---------------+---------------+---------------+Figure 3: SAM Data Format
- SAM Type (1 octet): The following SAM Types are allocated to DRIP 🎟️:
+==========+=============================+
| SAM Type | Description |
+==========+=============================+
| 0x01 | DRIP Link (Section 4.2) |
+----------+-----------------------------+
| 0x02 | DRIP Wrapper (Section 4.3) |
+----------+-----------------------------+
| 0x03 | DRIP Manifest (Section 4.4) |
+----------+-----------------------------+
| 0x04 | DRIP Frame (Section 4.5) |
+----------+-----------------------------+Table 1: DRIP SAM Types
Note: ASTM International is the owner of these code points, as they're defined in [F3411]. Following Annex 5 of [F3411], the International Civil Aviation Organization (ICAO) was selected by ASTM as the registrar to manage allocations of these code points. The list is available at [ASTM-Remote-ID] 📖.
- SAM Authentication Data (0 to 200 octets): Contains opaque authentication data, formatted as defined by the preceding SAM Type 🌈.
3.2.4. ASTM Broadcast RID Constraints
3.2.4.1. Wireless Frame Constraints ✨
Okay bestie, so a UA can broadcast over Bluetooth (4.x and 5.x), Wi-Fi NAN, or IEEE 802.11 Beacon 📡. See Section 6 for the details on those. With Bluetooth, the FAA and other Civil Aviation Authorities (CAA) mandate transmitting simultaneously over both 4.x and 5.x 🔥. The same application-layer information defined in [F3411] MUST be transmitted over all the physical-layer interfaces performing RID, because Observer transports may be limited 💅. If an Observer can support multiple transports, it should use (display, report, etc.) the latest data no matter which transport that data came in on 🫶.
Bluetooth 4.x is giving payload-size drama 😭. It can only transmit 25 octets of payload per frame, while other transports can fit bigger payloads per frame. The [F3411] message formats are the same for every medium, and their framing was designed to fit inside these legacy limits. So Extended Transports cannot send larger messages. Instead, the Message Pack format bundles multiple messages together, and each one still fits inside these legacy constraints 🧚.
By definition, Extended Transports provide FEC, but Legacy Transports lack FEC 💀. That means paged Authentication Messages may suffer the loss of one or more pages over Legacy Transports. The Observer application then gets incomplete messages that are typically unusable. So DRIP FEC (Section 5) is specified to recover a single lost page, which cuts down the odds of getting Authentication Messages that can't be fully rebuilt 🛠️. Authentication Messages sent over Extended Transports don't have this issue, since the full message (all pages) goes out in a single Message Pack. Also, one-way RF broadcasts rule out any congestion-control or loss-recovery schemes that depend on ACKs or NACKs 🙅♀️.
3.2.4.2. Paged Authentication Message Constraints 📄
To keep formatting consistent across the different transports (Legacy and Extended) and their separate restrictions, the authentication data being sent is REQUIRED to fit within the page limit that the most constrained existing transport can support. Under Broadcast RID, that's Bluetooth 5.x at 9 pages 🎯.
So DRIP transmitters are REQUIRED to adhere to the following when using the Authentication Message:
- Authentication Data / Signature data MUST fit in the first 9 pages (Page Numbers 0 through 8) 📖.
- The Length field in the Authentication Headers (which encodes the length in octets of Authentication Data / Signature only) MUST NOT exceed the value of
201. This includes the SAM Type but excludes Additional Data 🙈.
3.2.4.3. Timestamps ⏰
In ASTM [F3411], timestamps are Unix-style with an epoch of 2019-01-01 00:00:00 UTC. For DRIP, this format is adopted for Authentication so everything in the Broadcast payloads uses one common time format. Iconic consistency 👑.
Under DRIP, there are two timestamps defined: Valid Not Before (VNB) and Valid Not After (VNA) 💜.
Valid Not Before (VNB) Timestamp: (4 octets)
This is the recommended time to start trusting data. It MUST follow the format defined in [F3411] as described above. It MUST be set no earlier than the time the signature (across a given structure) is generated ⏳.
Valid Not After (VNA) Timestamp: (4 octets)
This is the recommended time to stop trusting data. It MUST follow the format defined in [F3411] as described above. It has an offset (relative to VNB) to avoid replay attacks 🚫. The exact offset is not defined in this document. Best practice for picking an acceptable offset should be used, and it should take into account the UA environment, the propagation characteristics of the messages being sent, and clock differences between the UA and Observers. For UA signatures in scenarios typical as of 2024, a reasonable offset would be to set VNA approximately 2 minutes after VNB. See Appendix B for examples that may help you tune this value 🎀.
4. DRIP Authentication Formats 🦋
All formats defined in this section are contained in the Authentication Data / Signature field in Figure 2 and use the Specific Authentication Method (SAM, Authentication Type 0x5). The first octet of the Authentication Data / Signature of Figure 2 is used to multiplex among these various formats 🌈.
When sending data over a medium that doesn't have underlying FEC, like Legacy Transports, then FEC (per Section 5) MUST be used 🔁.
Examples of Link, Wrapper, and Manifest are shown as part of an operational schedule in Appendix B.2.1 📅.
4.1. UA-Signed Evidence Structure 🔏
The UA-Signed Evidence Structure (Figure 4) is what the UA uses during flight to sign over information elements, using the private key tied to the current UA DET. It gets encapsulated by the SAM Authentication Data field of Figure 3 💅.
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 NOT use it, because it won't fit in the ASTM Authentication Message with its intended content (i.e., a Broadcast Endorsement) 🙅♀️.
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
+---------------+---------------+---------------+---------------+
| VNB Timestamp by UA |
+---------------+---------------+---------------+---------------+
| VNA Timestamp by UA |
+---------------+---------------+---------------+---------------+
| |
. .
. Evidence .
. .
| |
+---------------+---------------+---------------+---------------+
| |
| UA |
| DRIP Entity Tag |
| |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| |
| |
| |
| |
| UA Signature |
| |
| |
| |
| |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
Figure 4: Endorsement Structure for UA-Signed EvidenceVNB Timestamp by UA: (4 octets)
See Section 3.2.4.3. Set by the UA ⏰.
VNA Timestamp by UA: (4 octets)
See Section 3.2.4.3. Set by the UA ⏰.
Evidence: (0 to 112 octets)
The Evidence field MUST be filled in with data in the form of an opaque object specified in the DRIP Wrapper (Section 4.3), Manifest (Section 4.4), or Frame (Section 4.5) 🎁.
UA DRIP Entity Tag: (16 octets)
This is a DET [RFC9374] currently being used by the UA for 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)
This is the signature over the concatenation of the preceding fields (VNB, VNA, Evidence, and UA DET), made using the keypair of the UA DET. The 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 DET. The HI of the UA DET can be looked up by the mechanisms described in [DRIP-REG], or by extracting it from a Broadcast Endorsement (see Sections 4.2 and 6.3). So it's giving self-sufficient 👑💖.
4.2. DRIP Link 💌
Okay bestie, this SAM Type (Figure 5) is the one that carries Broadcast Endorsements 🦋. For example, the BE: HDA, UA gets sent as a DRIP Link message (see Section 6.3).
DRIP Link is a big deal because its contents give you trust in the DET/HI pair the UA is currently broadcasting 👑. This message doesn't need Internet connectivity to verify the signature when the DIME DET/HI is already in the Observer's cache 🙈. It also hands you the UA HI when it's filled with a BE: HDA, UA, so you don't need connectivity to verify other DRIP Authentication Messages either ✨.
Various Broadcast Endorsements get sent during each UAS flight operation so the full Broadcast Endorsement chain is available offline 🎀. See Section 6.3 for the deets.
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
+---------------+---------------+---------------+---------------+
| VNB Timestamp by Parent |
+---------------+---------------+---------------+---------------+
| VNA Timestamp by Parent |
+---------------+---------------+---------------+---------------+
| |
| DET |
| of Child |
| |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| HI of Child |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
| |
| DET |
| of Parent |
| |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| |
| |
| |
| |
| Signature by Parent |
| |
| |
| |
| |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
Figure 5: Broadcast Endorsement / DRIP LinkVNB Timestamp by Parent (4 octets) 🕐 See Section 3.2.4.3. Set by Parent Entity.
VNA Timestamp by Parent (4 octets) 🕑 See Section 3.2.4.3. Set by Parent Entity.
DET of Child (16 octets) 🧚 DRIP Entity Tag of Child Entity.
HI of Child (32 octets) 🌸 Host Identity of Child Entity.
DET of Parent (16 octets) 👑 DRIP Entity Tag of Parent Entity in DIME Hierarchy.
Signature by Parent (64 octets) 💅 Signature over concatenation of preceding fields (VNB, VNA, DET of Child, HI of Child, and DET of Parent) using the keypair of the Parent DET.
This DRIP Authentication Message gets used alongside other DRIP SAM Types (like the Manifest or the Wrapper) that carry data (for example, the ASTM Location/Vector Message, Message Type 0x2) that's guaranteed to be unique, unpredictable, and easy for the receiving device to cross-check 🔥.
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). 💜
Note: The Endorsement that proves a DET is registered MUST come from its immediate parent in the registration hierarchy, e.g., a DRIP Identity Management Entity (DIME) [DRIP-REG]. In the definitive hierarchy, the parent of the UA is its HHIT Domain Authority (HDA), the parent of an HDA is its Registered Assigning Authority (RAA), etc. It's also assumed that all DRIP-aware entities use a DET as their identifier when they interact with other DRIP-aware entities. 🌈
4.3. DRIP Wrapper 🎀
This SAM Type is used to wrap and sign over a list of other [F3411] Broadcast RID messages 🎁.
The Evidence field of the UA-Signed Evidence Structure (Section 4.1) gets filled with up to four ASTM Messages [F3411] in a contiguous octet sequence. Only ASTM Message Types 0x0, 0x1, 0x3, 0x4, and 0x5 are allowed, and they must be in Message Type order as defined by [F3411]. These messages MUST include the Message Type and Protocol Version octet and MUST NOT include the Message Counter octet (thus they're fixed at 25 octets in length) 🍓.
4.3.1. Wrapped Count and Format Validation 🔍
When a receiver decodes a DRIP Wrapper, it MUST calculate the number of messages wrapped and validate them, using the number of octets (defined as wrapperLength) between the VNA Timestamp by UA and the UA DET as shown in Figure 6 💖.
<CODE BEGINS>
if (wrapperLength MOD 25) != 0 {
return DECODE_FAILURE;
}
wrappedCount = wrapperLength / 25;
if (wrappedCount == 0) {
// DECODE_SUCCESS; treat as DRIP Wrapper over extended transport
}
else if (wrappedCount > 4) {
return DECODE_FAILURE;
} else {
// DECODE_SUCCESS; treat as standard DRIP Wrapper
}
<CODE ENDS>
Figure 6: Pseudocode for Wrapper Validation and Number of
Messages Calculation4.3.2. Wrapper over Extended Transports 🛸
When you're using Extended Transports, you can optimize DRIP Wrapper by signing over co-located data in an ASTM Message Pack (Message Type 0xF) ✨.
To do this, the UA-Signed Evidence Structure gets filled with the ASTM Messages that go in the ASTM Message Pack, the signature gets generated, and then the Evidence field gets cleared, leaving the encoded form shown in Figure 7 🦋.
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
+---------------+---------------+---------------+---------------+
| VNB Timestamp by UA |
+---------------+---------------+---------------+---------------+
| VNA Timestamp by UA |
+---------------+---------------+---------------+---------------+
| |
| UA |
| DRIP Entity Tag |
| |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| |
| |
| |
| |
| UA Signature |
| |
| |
| |
| |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
Figure 7: DRIP Wrapper over Extended TransportsTo verify the signature, the receiver MUST concatenate all the messages in the Message Pack (excluding the Authentication Message found in the same Message Pack) in ASTM Message Type order, and set the Evidence field of the UA-Signed Evidence Structure before it performs signature verification 🔐.
Honestly, the functionality of a Wrapper in this form is equivalent to Message Set Signature (Authentication Type 0x3) when running over Extended Transports 🧁. The Wrapper gives you the same format but over both Extended and Legacy Transports, which makes the transports feel similar 💜. Message Set Signature also means using the ASTM validator system architecture, which depends on Internet connectivity for verification that the receiver might not have at the time an Authentication Message arrives 🙃. The Wrapper, and all DRIP Authentication Formats, skip that problem when the UA key is obtained via a DRIP Link Authentication Message 🌈.
4.3.3. Wrapper Limitations ⚠️
The main limitation of the Wrapper is that it can only bound up to four ASTM Messages inside it 🥲. Another limitation is that the format can't be used as a surrogate for the messages it wraps, because an Observer on the ground might not support DRIP 💀. So when a Wrapper is being used, the wrapped data effectively has to be sent twice: once as a single-framed message (as specified in [F3411]) and again within the Wrapper 🫶.
4.4. DRIP Manifest 🧾
okay so this SAM Type is the one that makes message manifests, which are basically lists of hashes of ASTM Messages that were already sent. 💅
By hashing the earlier messages and signing that list, you get to trust a UA's previous reports without sending them all again. It's how you dodge the limit of four messages in the Wrapper (Section 4.3.3) and cut down on overhead by a lot. iconic 😭✨
Observers MUST hash all received ASTM Messages and cross-check them against the hashes in received Manifests. 🔍
Using Manifests wisely means a whole Broadcast RID message stream can get strongly authenticated with less than 100% overhead compared to a completely unauthenticated stream (see Section 6.3 and Appendix B). no cap, that's a W 🎀
The _Evidence_ field of the _UA-Signed Evidence Structure_ (Section 4.1) gets filled with 8-octet hashes of [F3411] Broadcast RID messages (up to 11) plus three special hashes (Section 4.4.2). ALL of these hashes MUST be concatenated into one contiguous octet sequence in the _Evidence_ field. It is RECOMMENDED that the maximum 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: HDA, UA) Hash_ MUST always come before the _ASTM Message Hashes_, as seen in Figure 8. 💜
An Observer MUST use the Manifest to verify each ASTM Message hashed in it that it has already received. And it doesn't need to have received them all to do that, which is so efficient 🦋 A Manifest SHOULD typically cover a single transmission cycle of messages being sent (see Section 6.4 and Appendix B). 🌸
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
+---------------+---------------+---------------+---------------+
| Previous Manifest |
| Hash |
+---------------+---------------+---------------+---------------+
| Current Manifest |
| Hash |
+---------------+---------------+---------------+---------------+
| DRIP Link (BE: HDA, UA) |
| Hash |
+---------------+---------------+---------------+---------------+
| |
. .
. ASTM Message Hashes .
. .
| |
+---------------+---------------+---------------+---------------+
Figure 8: DRIP Manifest Evidence Structure_Previous Manifest Hash_: (8 octets)
Hash of the previously sent Manifest Message. ⏮️
_Current Manifest Hash_: (8 octets)
Hash of the current Manifest Message. ⏭️
_DRIP Link (BE: HDA, UA)_: (8 octets)
Hash of the DRIP Link Authentication Message carrying BE: HDA, UA (see Section 4.2). 🔗
_ASTM Message Hash_: (8 octets)
Hash of a single full ASTM Message, using the hash operations described in Section 4.4.3. 🌈
4.4.1. Hash Count and Format Validation
When a receiver decodes a DRIP Manifest, it can do a hash count and a validation by using the number of octets between the _UA DET_ and the _VNB Timestamp by UA_ (defined as manifestLength), as shown in Figure 9. 🧮
if (manifestLength MOD 8) != 0 {
return DECODE_FAILURE
}
hashCount = (manifestLength / 8) - 3;Figure 9: Pseudocode for Manifest Sanity Check and Number of Hashes Calculation
4.4.2. Manifest Ledger Hashes
The following three special hashes are included in ALL Manifests: 📒
- the _Previous Manifest Hash_ links to the previous Manifest.
- 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. You should trace it 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 signature by the UA over the Broadcast Endorsement (see Section 4.2). Typical operation would expect the list of _ASTM Message Hashes_ to 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 one _ASTM Message Hash_ MUST be from an [F3411] message that satisfies the fourth requirement in Section 6.3. At least once per Observation Session, the Observer must process that message as specified in Section 6.3. 🚨
4.4.3. Hash Algorithms and Operation
The hash algorithm used for the Manifest is the same hash algorithm used in creating the DET [RFC9374] that is signing the Manifest. This is encoded as part of the DET using the HHIT Suite ID. 🔐
DETs that use cSHAKE128 [NIST.SP.800-185] compute the hash as follows:
cSHAKE128(ASTM Message, 64, "", "Remote ID Auth Hash")For ORCHID Generation Algorithms (OGAs) other than "5" (EdDSA/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 )When building a Manifest, this process MUST be followed:
- The _Previous Manifest Hash_
- is filled with a random nonce if and only if this is the first manifest being generated;
- otherwise, it contains the previous manifest's _Current Manifest Hash_.
- The _Current Manifest Hash_ is filled with null.
- _ASTM Message Hashes_ are filled per Section 4.4.3.1 or Section 4.4.3.2.
- A hash, as defined above in this section, is calculated over the _Previous Manifest Hash_, _Current Manifest Hash_ (null filled), and _ASTM Message Hashes_.
- The _Current Manifest Hash_ (null filled) is replaced with the hash generated in Step r.
4.4.3.1. Legacy Transport Hashing
Under this transport, DRIP hashes the full ASTM Message being sent over the Bluetooth Advertising frame. This is the 25-octet object that starts with the Message Type and Protocol Version octet, along with the 24 octets of message data. The hash MUST NOT include the Message Counter octet. 🙅♀️
For paged ASTM Messages (currently only Authentication Messages), all of the pages are concatenated together in Page Number order and hashed as one object. 📄
4.4.3.2. Extended Transport Hashing
Under this transport, DRIP hashes the full ASTM Message Pack (Message Type 0xF) regardless of its content. The hash MUST NOT include the Message Counter octet. 📦
4.5. DRIP Frame 🎞️
This SAM Type exists so the _UA-Signed Evidence Structure_ (Section 4.1) can be used in the future, beyond the formats already defined (Wrapper and Manifest). It does this with a single octet that signals the format of the _Evidence_ data (up to 111 octets). 🌟
The content format of _Frame Evidence Data_ is NOT defined in this document. Other specifications MUST define the contents and register for a _Frame Type_. At the time of publication (2024), there are no defined Frame Types; only an Experimental range has been defined. 🧪
Observers MUST check the signature of the structure (Section 4.1) per Section 3.1.2.2 and MAY, if the specification of the _Frame Type_ is known, parse the content in _Frame Evidence Data_. 👀
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
+---------------+---------------+---------------+---------------+
| Frame Type | |
+---------------+ .
. Frame Evidence Data .
. .
| |
+---------------+---------------+---------------+---------------+
Figure 10: DRIP Frame_Frame Type_: (1 octet)
As shown in Figure 10, the _Frame Type_ takes the first octet, which leaves 111 octets available for _Frame Evidence Data_. See Section 8.1 for Frame Type allocations. 🎀
5. Forward Error Correction 🛡️
For Broadcast RID, FEC is provided by the lower layers in Extended Transports. The Bluetooth 4.x Legacy Transport does not support FEC, so the following application-level scheme is used with DRIP Authentication to add some FEC. When sending data over a medium that does not have underlying FEC, for example Bluetooth 4.x, this section MUST be used. 📡
The Bluetooth 4.x lower layers have error detection but not correction. Any frame in which Bluetooth detects an error is dropped and not delivered to higher layers (in our case, DRIP). Thus it can be treated as an erasure. 🫠
DRIP standardizes a single page FEC scheme using XOR parity across all page data of an Authentication Message. This allows the correction of a single erased page in an Authentication Message. If more than a single page is missing, then handling of an incomplete Authentication Message is determined by higher layers. 🧩
Other FEC schemes, to protect more than a single page of an Authentication Message or multiple [F3411] Messages, are left for future standardization if operational experience proves it necessary and/or practical. 🔮
The data added during FEC is not included in the _Authentication Data / Signature_, but instead in the _Additional Data_ field of Figure 2. This may cause the Authentication Message to exceed 9 pages, up to a maximum of 16 pages. 📚
5.1. Encoding ✨
When you're encoding, there are two things that are REQUIRED 🫶
- The FEC data MUST start on a brand-new Authentication Page 🌸. To make that happen, the results of parity encoding MUST be placed in the
Additional Datafield of Figure 2, with null padding in front of it so it lines up with the next page. TheAdditional Data Lengthfield MUST be set to number of padding octets + number of parity octets. - The
Last Page Indexfield (in Page 0) MUST be incremented from what it would have been without FEC, by the number of pages needed for theAdditional Data Lengthfield, null padding, and FEC 💖
To generate the parity, it's a simple XOR operation using the previous parity page and the current page 🦋 Only the 23-octet Authentication Payload field of Figure 1 gets used in the XOR operations. For Page 0, a 23-octet null pad stands in for the previous parity page.
Figure 11 shows the last two pages (out of N) of an Authentication Message using DRIP Single Page FEC. The Additional Data Length is set to 33, because there are always 23 octets of FEC data and there are 10 octets of padding in this example to line it up into Page N 🧚
Page N-1:
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
+---------------+---------------+---------------+---------------+
| Page Header | |
+---------------+ |
| Authentication Data / Signature |
| |
| +---------------+---------------+---------------+
| | ADL=33 | |
+---------------+---------------+ |
| Null Padding |
| |
+---------------+---------------+---------------+---------------+
Page N:
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
+---------------+---------------+---------------+---------------+
| Page Header | |
+---------------+ |
| |
| Forward Error Correction |
| |
| |
| |
+---------------+---------------+---------------+---------------+Figure 11: Example Single Page FEC Encoding
5.2. Decoding 🔍
Frame decoding doesn't care what transmit media is in use 🎀 But the decoding process can tell from the first Authentication Page 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.
To figure out if FEC was used, you check the Last Page Index 👀 Generally speaking, if the Last Page Index is one greater than what's needed to hold Length octets of Authentication Data, then FEC has been used. Here's the tricky bit: if the Length octets run out exactly at the end of an Authentication Page, the Additional Data Length field ends up taking the first octet of the following page. The rest of that page gets null padded under DRIP so the FEC lands on its own page. In that case, the Last Page Index was bumped once for initializing the Additional Data Length field and once for the FEC page, so that's two extra pages total, like in the last row of Table 5 💅
To decode FEC in DRIP, a rolling XOR runs on each _Authentication Page_ received in the current Authentication Message. A Message Counter, which lives outside of the ASTM Message but is specified in [F3411], signals a new Authentication Message and helps match pages to messages 🌈 This Message Counter is only a single octet, so it rolls over (to 0x00) after it hits its max value (0xFF). If only a single page is missing from the Authentication Message, the resulting parity octets should be the data of the erased page ✨
Authentication Page 0 holds a bunch of important fields that only live on that page, and they're what help decode the full ASTM Authentication Message 🦋 If Page 0 has been reconstructed, the Last Page Index and Length fields MUST be validated by DRIP. The pseudocode in Figure 12 can be used for both checks.
function decode_check(auth_pages[], decoded_lpi, decoded_length) {
// check decoded_lpi does not exceed maximum value
if (decoded_lpi >= 16) {
return DECODE_FAILURE
}
// check that decoded length does not exceed DRIP maximum value
if (decoded_length > 201) {
return DECODE_FAILURE
}
// grab the page at index where length ends and extract its data
auth_data = auth_pages[(decoded_length - 17) / 23].data
// find the index of last auth byte
last_auth_byte = (17 + (23 * last_auth_page)) - decoded_length
// look for non-nulls after the last auth byte
if (auth_data[(last_auth_byte + 2):] has non-nulls) {
return DECODE_FAILURE
}
// check that byte directly after last auth byte is null
if (auth_data[last_auth_byte + 1] equals null) {
return DECODE_FAILURE
}
// we set our presumed Additional Data Length (ADL)
presumed_adl = auth_data[last_auth_byte + 1]
// use the presumed ADL to calculate a presumed
//Last Page Index (LPI, a field defined in [F3411])
presumed_lpi = (presumed_adl + decoded_length - 17) / 23
// check that presumed LPI and decoded LPI match
if (presumed_lpi not equal decoded_lpi) {
return DECODE_FAILURE
}
return DECODE_SUCCESS
}Figure 12: Pseudocode for Decode Checks
5.3. FEC Limitations 🙈
The worst-case scenario is when the Authentication Data / Signature ends perfectly on a page boundary (Page N-1). That means the Additional Data Length would start the next page (Page N) and need 22 octets of null padding to line the FEC up at the start of the page after that (Page N+1). So in that scenario, an entire page (Page N) gets wasted just to carry the Additional Data Length 😭
6. Requirements and Recommendations 👑
6.1. Legacy Transports 📡
Under DRIP, the goal is to get reliable receipt of the paged Authentication Message over Legacy Transports 💖 FEC (Section 5) MUST be used, per mandated RID rules (for example, the US FAA RID Rules [FAA-14CFR]), when you're using Legacy Transports (like Bluetooth 4.x).
Under [F3411], Authentication Messages get transmitted at the static rate (at least every 3 seconds). Any DRIP Authentication Messages containing dynamic data (like the DRIP Wrapper) MAY be sent at the dynamic rate (at least every 1 second) 🌸
6.2. Extended Transports 🚀
Under the ASTM specification, Extended Transports of RID must use the Message Pack (Message Type 0xF) format for all transmissions. With Message Pack, ASTM Messages get sent together (in Message Type order) in a single frame, up to 9 single-frame equivalent messages under Legacy Transports. Message Packs are required by [F3411] to be sent at a rate of 1 per second (like dynamic messages) ⏱️
Message Packs are only sent over Extended Transports that provide FEC. So DRIP decoders will never be handed a Message Pack with a constituent Authentication Page missing. DRIP FEC could never give a Message Pack any benefit, it would only eat up its precious payload space 🥺 Therefore, DRIP FEC (Section 5) MUST NOT be used in Message Packs.
6.3. Authentication 🔐
To meet the requirements in [RFC9153], a UA MUST:
- send DRIP Link (Section 4.2) using
BE: Apex, RAA(partially satisfying GEN-3), at least once per 5 minutes. Apex in this context is the DET prefix owner 🌷 - send DRIP Link (Section 4.2) using
BE: RAA, HDA(partially satisfying GEN-3), at least once per 5 minutes. - send DRIP Link (Section 4.2) using
BE: HDA, UA(satisfying ID-5, GEN-1 and partially satisfying GEN-3), at least once per minute. - send any other DRIP Authentication Format (non-DRIP Link) where the UA is dynamically signing data that is guaranteed to be unique, unpredictable, and easily cross checked by the receiving device (satisfying ID-5, GEN-1 and GEN-2), at least once per 5 seconds 💅
An Observer's receiver must verify the signature (cryptographically, as specified in Section 3.1.1) on each of the 4 messages sent in the operations listed right above, and the Observer MUST validate the signed content (via non-cryptographic means) of the 4th message sent in the last operation above (the non-DRIP Link message) 🦋
These transmission, receiver verification, and Observer validation requirements together satisfy GEN-3 ✨
6.4. Operational 🛸
UAS operation may affect how often DRIP Authentication Messages get sent. When a UA dwells at an approximate location and the channel is heavily used by other devices, less frequent message authentication may be effective (to cut down on RF packet collisions) for an Observer. Contrast that with a UA transiting an area, where authenticated messages SHOULD be frequent enough for an Observer to have a high probability of receiving an adequate number for validation during the transit 🏃♀️
A RECOMMENDED operational configuration (in line with Section 6.3), with rationale, can be found in Appendix B 📖 It recommends the following once per second:
- Under Legacy Transport:
- Two sets of those ASTM Messages required by a CAA in its jurisdiction (example: Basic ID, Location/Vector, and System) and one set of other ASTM Messages (example: Self ID, Operator ID)
- An FEC-protected DRIP Manifest enabling authentication of those ASTM Messages sent
- A single page of an FEC-protected DRIP Link
- Under Extended Transport:
- A Message Pack of ASTM Messages (up to 4) and a DRIP Wrapper (per Section 4.3.2)
- A Message Pack of a DRIP Link
6.4.1. DRIP Wrapper 🎁
If DRIP Wrappers are sent, they MUST be sent in addition to any required ASTM Messages in a given jurisdiction. An implementation MUST NOT send DRIP Wrappers in place of any required ASTM Messages it may encapsulate. So messages inside a Wrapper get sent twice: once in the clear, and once authenticated within the Wrapper 💜
The DRIP Wrapper has a specific use case for DRIP-aware Observers. For an Observer plotting Location/Vector Messages (Message Type 0x2) on a map, a Location/Vector Message shown from inside a DRIP Wrapper can be marked differently (e.g., via color) to signal trust in the Location/Vector data 🌈
6.4.2. UAS RID Trust Assessment 🦋
Okay so, like I said in Section 3.1.2, the Observer MUST validate the data it receives in Broadcast RID 🔍 Why? Because trusting a key is NOT the same as trusting that the UA actually has that key. Different vibes, bestie 🙈
A chain of DRIP Links gives you trust in a key 🔗 Then a message signed by that key, with data that changes fast and can't be predicted far ahead (compared to normal flight times), that Observers can actually check? That gives you trust that some agent with access to that data also has the key 💜 And if the check involves matching physical-world observations of the UA against the claims in that data, then it's highly likely the observed UA is the agent with the key (or is working with it, or being watched live by it) ✨
At least once per Observation session, after signature verification of any DRIP Authentication Message that carries UAS RID information elements (for example, DRIP Wrapper, Section 4.3), the Observer must use other sources of information to correlate against and validate (as specified in Section 6.3). One example of another source is visually confirming the UA's position 👀
When the correlation between these different data streams doesn't match within acceptable thresholds, the data MUST be rejected as if the signature failed to validate 🚫 What counts as acceptable thresholds, and what happens after a rejection, is out of scope for this document 🤷♀️
7. Summary of Addressed DRIP Requirements 🌸
Okay, here's the recap of the requirements from [RFC9153] that this document actually addresses 💅
ID-5: Non-spoofability
Addressed using the DRIP Wrapper (Section 4.3), DRIP Manifest (Section 4.4), or DRIP Frame (Section 4.5). 🛡️
GEN-1: Provable Ownership
Addressed using the DRIP Link (Section 4.2) and DRIP Wrapper (Section 4.3), DRIP Manifest (Section 4.4), or DRIP Frame (Section 4.5). 🔑
GEN-2: Provable Binding
Addressed using the DRIP Wrapper (Section 4.3), DRIP Manifest (Section 4.4) or DRIP Frame (Section 4.5). 🎀
GEN-3: Provable Registration
Addressed using the DRIP Link (Section 4.2). 📝
8. IANA Considerations 🧚
8.1. IANA DRIP Registry
IANA has created the "DRIP SAM Types" and "DRIP Frame Types" registries within the "Drone Remote ID Protocol" registry group (https://www.iana.org/assignments/drip). 🌈
DRIP SAM Types:
This registry is a mirror for SAM Types containing the subset of allocations used by DRIP Authentication Messages. Future additions MUST be done through ASTM's designated registrar, which is ICAO [ASTM-Remote-ID] at the time of publication of this RFC (2024). The registration procedure for DRIP (only) SAM Types is Standards Action [RFC8126]. Requests for new DRIP SAM Type 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 |
+==========+===========+=======================================+
| 0x01 | DRIP Link | Format to hold Broadcast Endorsements |
+----------+-----------+---------------------------------------+
| 0x02 | DRIP | Authenticate full ASTM Messages |
| | Wrapper | |
+----------+-----------+---------------------------------------+
| 0x03 | DRIP | Authenticate hashes of ASTM Messages |
| | Manifest | |
+----------+-----------+---------------------------------------+
| 0x04 | DRIP | Format for future DRIP authentication |
| | Frame | |
+----------+-----------+---------------------------------------+
Table 2: DRIP SAM TypesDRIP Frame Types:
This 8-bit value registry is for Frame Types in DRIP Frame Authentication Messages. Future additions to this registry are to be made through Expert Review (Section 4.5 of [RFC8126]) for values 0x01 to 0x9F and First Come First Served (Section 4.4 of [RFC8126]) for values 0xA0 to 0xEF. The following values are defined:
+=============+==============+===============================+
| Frame Type | Name | Description |
+=============+==============+===============================+
| 0x00 | Reserved | Reserved |
+-------------+--------------+-------------------------------+
| 0x01 - 0xEF | Unassigned | |
+-------------+--------------+-------------------------------+
| 0xF0-0xFF | Experimental | Reserved for Experimental Use |
+-------------+--------------+-------------------------------+
Table 3: DRIP Frame TypesCriteria that should be applied by the designated experts includes determining whether the proposed registration duplicates existing functionality and whether the registration description is clear and fits the purpose of this registry. 🧐
Registration requests MUST be sent to drip-reg-review@ietf.org (mailto:drip-reg-review@ietf.org) and be evaluated by one or more designated experts within a three-week review period. Within that review period, the designated experts will either approve or deny the registration request, and communicate their decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions to successfully register the DRIP Frame Type. 💌
Registration requests that are undetermined for a period longer than 28 days can be brought to the IESG's attention for resolution. ⏰
9. Security Considerations 💀🔥
Okay, this section is SERIOUS, so pay attention, bestie 😭
9.1. Replay Attacks
[F3411] (regardless of transport) lacks replay protection, as it more fundamentally lacks fully specified authentication. 😱 An attacker can spoof the UA sender MAC address and UAS ID, replay (with or without modification) previous genuine messages, and/or craft entirely new messages. Using DRIP in [F3411] Authentication Message framing lets you verify that messages were signed with registered keys, but when it's used naively it may be vulnerable to replay attacks. Technologies such as Single Emitter Identification can detect such attacks, but they aren't readily available and can be prohibitively expensive, especially for typical Observer devices such as smartphones. 📱💸
Replay attack detection using DRIP requires Observer devices to combine information from multiple Broadcast RID messages and from sources other than Broadcast RID. A complete chain of Link messages (Section 4.2) from an Endorsement root of trust to the claimed sender must be collected and verified by the Observer device to provide trust in a key. Successful signature verification, using that public key, of a Wrapper (Section 4.3) or Manifest (Section 4.4) message, authenticating content that is nonce-like (see below), provides trust that the sender actually possesses the corresponding private key. 🔐
The term "nonce-like" describes data that is unique, changes frequently, is not accurately predictable long in advance, and is easily validated (i.e., can be checked quickly at low computational cost using readily available data) by the Observer. A Location/Vector Message is an obvious choice. This is described in Section 3.1.2.2 and Section 6.3 (requirement 4). A Location/Vector Message [F3411] reporting precise UA position and velocity at a precise and very recent time can be checked by the Observer against visual observations of UA within both RF and Visual Line of Sight. 👁️✨
For normative specification of the foregoing, see Sections 3.1.2 and 6.4.2. As non-normative clarification, the requirements are satisfied as follows:
The public key corresponding to a given DET (i.e., the key attested in the DRIP Link (BE: HDA, UA) that is the last link in the relevant chain of DRIP Links) is used by an Observer's receiver to try to authenticate some signed message. 🗝️
If the signature check passes,
- and the message was a Wrapper or Manifest,
- and the wrapped or manifested message contained content that was nonce-like,
- and the Observer validated that content by non-cryptographic means (e.g., if the wrapped or manifested message was a Location/Vector Message and the UA was visually observed to be in approximately the claimed location at the reported time),
only then can the Observer trust that the currently observed sending UA actually possesses the corresponding private key (and thus owns the corresponding DET). 🎉👑
Messages that pass signature verification with trusted keys could still be replays if they contain only static information (e.g., Broadcast Endorsements (Section 4.2), [F3411] Basic ID, or [F3411] Operator ID), or information that cannot be readily validated (e.g., [F3411] Self-ID). Replay of Link messages is harmless (unless sent so frequently as to cause RF data link congestion) and indeed can increase the likelihood of an Observer device collecting an entire trust chain in a short time window. 🔗💕 Replay of other messages ([F3411] Basic ID, [F3411] Operator ID, or [F3411] Self-ID) remains a vulnerability, unless they are combined with messages containing nonce-like data ([F3411] Location/Vector or [F3411] System) in a Wrapper or Manifest. For specification of this last requirement, see Section 4.4.2. 🚨
9.2. Wrapper vs Manifest 🎀
Okay so, implementations get to pick between a Wrapper (Section 4.3), a Manifest (Section 4.4), or a mix of both to hit the fourth requirement in Section 6.3. 💅
A Wrapper is an attached signature over the full content of one or more [F3411] messages, and it gives you strong authentication. 🔥 The catch is the size limit. It can't fit signatures over other Authentication Messages, so it can't directly bind to any part of the trust chain (Sections 3.1.2 and 6.4.2). 🙈
A Manifest is the one that explicitly binds the last link in the trust chain, since it includes the hash of the Link that contains BE: HDA, UA. 🦋 Because it leans on hashes (which are shorter), it can authenticate a bigger pile of [F3411] messages, 11 vs 4 for the Wrapper, so it's more efficient overall. ✨ The tradeoff is that the detached signature means Observers have to do extra work storing and comparing hashes of received messages (some of which might never arrive) against the ones in a Manifest. 😭
Appendix B has a breakdown of frame counts and an example schedule that uses both Manifest and Wrapper. 🌈 As an example of typical operation, you might see 2x Basic ID, 2x Location/Vector, 2x System, 1x Operator ID and 1x Self ID broadcast per second to meet jurisdiction mandates. 🍓 Every one of those messages is a single frame. A Link message is 8 frames long (including FEC). So the base frame count is 16 frames. 🧚
With a Wrapper, up to four of the previous messages (except the Link) can be authenticated. For this comparison, we sign every message we can in two Wrappers, which gives us _20 frames_ (with FEC). The Link is left unauthenticated because of size constraints. 😤 Total frame count with Wrappers: 36 frames (wrapper frame count + base frame count). 💜
With a Manifest, up to 10 previous messages can be authenticated. In this example, all 8 messages get hashed (the Link included), and that squishes into one Manifest that's _9 frames_ (with FEC). 👑 Total frame count with a Manifest: 25 frames (manifest frame count + base frame count). Honestly, the Manifest wins on frames here. 🫶
9.3. VNA Timestamp Offsets for DRIP Authentication Formats 🕰️
Heads up, the VNA Timestamp offset stuff is being discussed in the context of the DRIP Wrapper (Section 4.3), DRIP Manifest (Section 4.4), and DRIP Frame (Section 4.5). For DRIP Link (Section 4.2), the DIME sets these offsets, and they come with their own considerations in [DRIP-REG]. 📚
The offset of the _VNA Timestamp by UA_ needs really careful thought in any implementation. 🧐 It should be shorter than any flight duration (typically less than an hour), but long enough that Observers can receive and process it (larger than a few seconds). It is recommended that 3-5 minutes should be sufficient for this in any scenario, but it is not limited by design. ✨ Basically, pick a sweet spot and don't treat it as a hard rule. 💖
9.4. DNS Security in DRIP 🔐
As stated in Section 3.1, specifying particular DNS security options, transports, and so on is outside the scope of this document. ⭐ The main spec for DNS operations in DRIP [DRIP-REG] is where the applicable best common security practices get spelled out (for example, from [RFC9364]). 🫶
10. References 📖
10.1. Normative References 💅
- [F3411] ASTM International, "Standard Specification for Remote ID and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July 2022,
https://www.astm.org/f3411-22a.html. - [NIST.SP.800-185] Kelsey, J., Chang, S., and R. Perlner, "SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash", NIST Special Publication 800-185, DOI 10.6028/NIST.SP.800-185, December 2016,
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
https://www.rfc-editor.org/info/rfc2119. - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
https://www.rfc-editor.org/info/rfc8174. - [RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Requirements and Terminology", RFC 9153, DOI 10.17487/RFC9153, February 2022,
https://www.rfc-editor.org/info/rfc9153. - [RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
https://www.rfc-editor.org/info/rfc9374. - [RFC9434] Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July 2023,
https://www.rfc-editor.org/info/rfc9434.
10.2. Informative References 🌸
- [ASTM-Remote-ID] International Civil Aviation Organization (ICAO), "Remote ID Number Registration", December 2023,
https://www.icao.int/airnavigation/IATF/Pages/ASTM-Remote-ID.aspx. - [DRIP-REG] Wiethuechter, A., Ed. and J. Reid, "DRIP Entity Tag (DET) Identity Management Architecture", Work in Progress, Internet-Draft, draft-ietf-drip-registries-16, 31 May 2024,
https://datatracker.ietf.org/doc/html/draft-ietf-drip-registries-16. - [FAA-14CFR] Federal Aviation Administration (FAA), "Remote Identification of Unmanned Aircraft", January 2021,
https://www.govinfo.gov/content/pkg/FR-2021-01-15/pdf/2020-28948.pdf. - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
https://www.rfc-editor.org/info/rfc8126. - [RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, February 2023,
https://www.rfc-editor.org/info/rfc9364.
Appendix A. Authentication States 🦋
ASTM Authentication only has three states: None, Invalid, and Valid. 🙃 That's because under ASTM, authentication is handled by an external service hosted somewhere on the Internet, so an authoritative response is always assumed to come back. 🌐 DRIP makes this messier because of "offline" scenarios, where an Observer has no Internet connection. 😵💫 With asymmetric cryptography, the public key (PK) has to be obtained somehow. [DRIP-REG] has more detail on how these keys are stored in the DNS and how DRIP Authentication Messages can be used to send PKs over Broadcast RID. 📡
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 over Broadcast RID messages. The DIME keys go over Broadcast RID using the same mechanisms (see Sections 4.2 and 6.3), but they MAY be sent at a much lower rate because of operational constraints (like saturating limited bandwidth). 🐢 So there are scenarios where part of the key chain might not be available at the moment a full Authentication Message is received and processed. 🥺
This informative appendix is here to recommend a way to classify these states and show them to the user with colors and state names/text. 🌈 The states can apply to a single Authentication Message, a DET (and its associated public key), and/or a sender. 💜
Table 4 briefly describes each state and recommends an associated color. 🎨
+==============+========+===================================+
| State | Color | Details |
+==============+========+===================================+
| None | Black | No Authentication has been or is |
| | | being received (as yet) |
+--------------+--------+-----------------------------------+
| Partial | Gray | Authentication being received but |
| | | missing pages |
+--------------+--------+-----------------------------------+
| Unsupported | Brown | Authentication Type / SAM Type of |
| | | received message not supported |
+--------------+--------+-----------------------------------+
| Unverifiable | Yellow | Data needed for signature |
| | | verification is missing |
+--------------+--------+-----------------------------------+
| Verified | Green | Valid signature verification and |
| | | content validation |
+--------------+--------+-----------------------------------+
| Trusted | Blue | Evidence of Verified and DIME is |
| | | marked as only registering DETs |
| | | for trusted entities |
+--------------+--------+-----------------------------------+
| Unverified | Red | Invalid signature verification or |
| | | content validation |
+--------------+--------+-----------------------------------+
| Questionable | Orange | Evidence of both"Verified and |
| | | Unverified for the same claimed |
| | | sender |
+--------------+--------+-----------------------------------+
| Conflicting | Purple | Evidence of both Trusted and |
| | | Unverified for the same claimed |
| | | sender |
+--------------+--------+-----------------------------------+
Table 4: Authentication State Names, Colors, and DescriptionsA.1. None: Black 🖤
The default state, where authentication information hasn't been received yet and isn't being received right now. 😴
A.2. Partial: Gray 🩶
A pending state where Authentication Pages are coming in, but a full Authentication Message hasn't been put together yet. 🧩
A.3. Unsupported: Brown 🤎
A state where authentication data is being or has been received but can't be used, because the Observer doesn't support the Authentication Type or SAM Type. 🙅♀️
A.4. Unverifiable: Yellow 💛
A pending state where a full Authentication Message has been received, but other info (like the public keys needed to verify signatures) is missing. 🔑
A.5. Verified: Green 💚
A state where every Authentication Message received from that claimed sender up to this point passes signature verification, and the requirement of Section 6.4.2 has been met. ✅
A.6. Trusted: Blue 💙
okay so Trusted is the state where every Authentication Message received from that claimed sender, up to that point, has passed signature verification, the requirement of Section 6.4.2 has been met, and the sending UA's public key has been marked as trusted. 🫶
The sending UA key only gets marked as trusted if the relevant DIMEs register DETs (from subordinate DIMEs, UAS operators, and the UA) that have been vetted under their published registration policies. The DIMEs also need to have been marked as trusted by the Observer's owner (an individual or an organization), following that owner's policy, for registering DETs only for trusted parties. The whole chain has to be vetted, bestie 🔐✨
A.7. Questionable: Orange 🧡
Questionable is the messy middle 😭. It's where you've received a mix of Authentication Messages that are Verified (Appendix A.5) and Unverified (Appendix A.8).
It moves from Verified to Questionable if a later message fails verification, which means it would otherwise have been marked Unverified. It moves from Unverified to Questionable if a later message passes verification or validation, which means it would otherwise have been marked Verified. It can also switch from either of those states based on mixed results against the requirement of Section 6.4.2. Not stable, not sus, just vibes in flux 🌈
A.8. Unverified: Red ❤️
Unverified is a no-glow-up zone 💀. It's where every Authentication Message received from that claimed sender, up to that point, has failed either signature verification or the requirement of Section 6.4.2.
A.9. Conflicting: Purple 💜
Conflicting is when the drama is real 🙈. There's a mix of Authentication Messages received that are Trusted (Appendix A.6) and Unverified (Appendix A.8), and the public key of the aircraft is marked as trusted.
It moves from Trusted to Conflicting if a later message fails verification, which means it would otherwise have been marked Unverified. It moves from Unverified to Conflicting if a later message passes verification or validation and policy checks, which means it would otherwise have been marked Trusted. Like Questionable, it can also shift from either of those states on mixed results against the requirement of Section 6.4.2. ngl this one is giving plot twist 🎭
Appendix B. Operational Recommendation Analysis 🧮
okay bestie, this part is informative, so it's the "why" behind all the Section 6.4 recommendations 🍓 Those recs might look a little heavy-handed and specific, and this appendix shows the math, the assumptions, and an example so you can see where they came from. ✨
In all jurisdictions known to the authors of this document as of its publication (2024), at least the following ASTM Messages are required to be transmitted at least once per second:
- Basic ID (0x1)
- Location (0x2)
- System (0x4)
Europe also requires:
- Operator ID Message (0x5)
Japan is extra 💅 and requires not one but two Basic ID messages:
- one carrying a manufacturer assigned serial number
- one carrying a CAA assigned registration number
Japan also requires:
- Authentication (0x2) using their own unique scheme
In all jurisdictions, one more message is optional, but highly recommended for carrying extra info about the nature of the emergency, if the Emergency value is sent in the Operational Status field of the Location/Vector Message:
- Self ID (0x3)
To improve the odds that regulator-required RID data elements get received on time, most implementations send at a higher rate. They either repeat the same messages within the same one-second interval, or update the message content and send more often than once per second. 📡 But sending too fast can congest the RF spectrum, which causes collisions and, counterintuitively, lowers the chance of timely receipt of RID data. Too much of a good thing, bestie 🙃
B.1. Page Counts vs Frame Counts 📄
There are two formulas for working out how many Authentication Pages you need. Here's the one for Wrapper:
wrapper_struct_size = 89 + (25 * num_astm_messages)
wrapper_page_count = ceiling((wrapper_struct_size - 17) / 23) + 1And here's the one for Manifest:
manifest_struct_size = 89 + (8 * (num_astm_hashes + 3))
manifest_page_count = ceiling((manifest_struct_size - 17) / 23) + 1Links are fixed size, so a similar formula works for them too:
link_page_count = ceiling((137 - 17) / 23) + 1 = 7Now let's compare Wrapper and Manifest Authentication Message page counts against total frame counts. It's giving spreadsheet energy 🌸
+==========+=========+==========+=================+===============+
| ASTM | Wrapper | Manifest | ASTM Messages + | ASTM Messages |
| Messages | (w/FEC) | (w/FEC) | Wrapper (w/FEC) | + Manifest |
| | | | | (w/FEC) |
+==========+=========+==========+=================+===============+
| 0 | 5 (6) | 6 (7) | 5 (6) | 6 (7) |
+----------+---------+----------+-----------------+---------------+
| 1 | 6 (7) | 6 (7) | 7 (8) | 7 (8) |
+----------+---------+----------+-----------------+---------------+
| 2 | 7 (8) | 6 (7) | 9 (10) | 8 (9) |
+----------+---------+----------+-----------------+---------------+
| 3 | 8 (9) | 7 (8) | 11 (12) | 10 (11) |
+----------+---------+----------+-----------------+---------------+
| 4 | 9 (10) | 7 (8) | 13 (14) | 11 (12) |
+----------+---------+----------+-----------------+---------------+
| 5 | N/A | 7 (8) | N/A | 12 (13) |
+----------+---------+----------+-----------------+---------------+
| 6 | N/A | 8 (9) | N/A | 14 (15) |
+----------+---------+----------+-----------------+---------------+
| 7 | N/A | 8 (9) | N/A | 15 (16) |
+----------+---------+----------+-----------------+---------------+
| 8 | N/A | 8 (9) | N/A | 16 (17) |
+----------+---------+----------+-----------------+---------------+
| 9 | N/A | 9 (10) | N/A | 18 (19) |
+----------+---------+----------+-----------------+---------------+
| 10 | N/A | 9 (10) | N/A | 19 (20) |
+----------+---------+----------+-----------------+---------------+
| 11 | N/A | 9 (11) | N/A | 20 (22) |
+----------+---------+----------+-----------------+---------------+
Table 5: Page and Frame CountsLink shares the same page counts as Manifest with 5 ASTM Messages. 🦋
B.1.1. Special Cases ✨
B.1.1.1. Zero ASTM Messages 🌷
Zero ASTM Messages (see Table 5) is where Extended Wrapper (Section 4.3.2) without FEC is used in Message Packs. A Message Pack has a maximum of nine "message slots", and an Extended Wrapper fills five of them. So it can authenticate up to four ASTM Messages co-located in the same Message Pack. Math checks out, iykyk 🧚
B.1.1.2. Eleven ASTM Messages 🔥
Eleven ASTM Messages (see Table 5) is where a Manifest with FEC runs into the situation mentioned in Section 5.3. 👀
Eleven is the maximum number of ASTM Message Hashes that can be supported, which gives 14 total hashes. That completely fills the _Evidence_ field of the _UA-Signed Evidence Structure_, making its total size 200 octets. This fits on exactly 9 Authentication Pages (((201 - 17) / 23 == 8)), so when the ADL is added, it lands on the next page (Page 10). Per rule 1 in Section 5.1, all of Page 10 is null padded, except for the ADL octet, and the FEC data fills Page 11. That's where the plus-two page count comes from when FEC is applied. 💖
This is why the recommendation in Section 4.4 is to only use up to 10 ASTM Message Hashes, not 11. 🙌
B.2. Full Authentication Example 🦋
okay so this example (Figure 13) is all about proving that 100% of ASTM Messages can be authenticated over Legacy Transports, even with up to 125% overhead in Authentication Pages 🔥. Extended Transports aren't shown here because, for those, Authentication with DRIP is done with the Extended Wrapper (Section 4.3.2) 💅. Two ASTM Message Packs get sent in each cycle. One has up to four ASTM Messages plus an Extended Wrapper that authenticates the pack. The other has a Link message with a Broadcast Endorsement plus up to two other ASTM Messages ✨.
This transmit scheme covers every known regulatory case, so manufacturers can use the same firmware worldwide 🌍🫶.
+------------------------------------------------------+
| Frame Slots |
| 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[1] |
+-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[2] |
+-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[3] |
+-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[4] |
+-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[5] |
+-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[6] |
+-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[7] |
+-------------------+---------------+---------+--------+
A = Basic ID Message (0x0) ID Type 1
B = Basic ID Message (0x0) ID Type 2
C = Basic ID Message (0x0) ID Type 3
D = Basic ID Message (0x0) ID Type 4
V = Location/Vector Message (0x1)
I = Self ID Message (0x3)
S = System Message (0x4)
O = Operator ID Message (0x5)
L[y,z] = DRIP Link Authentication Message (0x2)
W[y,z] = DRIP Wrapper Authentication Message (0x2)
M[y,z] = DRIP Manifest Authentication Message (0x2)
y = Start Page
z = End Page
# = Empty Frame Slot
* = Message in DRIP Manifest Authentication Message
Figure 13: Example of a Fully Authenticated Legacy Transport
Transmit ScheduleFigure 13 is the star of the show 🌟 and it's giving total order 😭. Every common required message (Basic ID, Location/Vector, and System) gets sent twice, along with Operator ID and Self ID, all in a single second 🎀. The Manifest covers all messages (8) in slots 00 - 04 and 05 - 07, so it's basically watching over the whole squad 🧚.
In two seconds, either a Link or a Wrapper gets sent. Here's how the content and order of Links and Wrappers goes 💜:
Link: HDA on UA
Link: RAA on HDA
Link: HDA on UA
Link: Apex on RAA
Link: HDA on UA
Link: RAA on HDA
Link: HDA on UA
Wrapper: Location/Vector (0x1), System (0x4)
Link: HDA on UA
Link: RAA on HDA
Link: HDA on UA
Link: Apex on RAA
Link: HDA on UA
Link: RAA on HDA
Link: HDA on UA
Wrapper: Location/Vector (0x1), System (0x4)
Link: IANA on UAS RID Apexngl the timing is so satisfying 🥹. After perfect receipt of all messages for a period of 8 seconds, every message sent during that period has been authenticated using the Manifest (except for the Authentication Messages themselves) ✅. Within 136 seconds, the entire Broadcast Endorsement chain is received and can be validated 🙌. There are also 4 messages sent in their basic [F3411] form and also inside DRIP Wrapper messages, together with their attached signatures. That's a little extra protection against attacks on the detached signatures provided by the Manifest messages 🛡️🫶.
B.2.1. Raw Example 🍓
okay now the raw bytes 🤓. Assume the following DET and HI:
2001:3f:fe00:105:a29b:3ff4:2226:c04e
b5fef530d450dedb59ebafa18b00d7f5ed0ac08a81975034297bea2b00041813These ASTM Messages are sent in a single second:
0240012001003ffe000105a29b3ff42226c04e000000000000
12000000000000000000000000000000000000000060220000
32004578616d706c652053656c662049440000000000000000
420000000000000000000100000000000000000010ea510900
52004578616d706c65204f70657261746f7220494400000000
0240012001003ffe000105a29b3ff42226c04e000000000000
12000000000000000000000000000000000000000060220000
420000000000000000000100000000000000000010ea510900This is a Link with FEC that gets spread out over 8 seconds 🌈:
2250078910ea510904314b8564b17e66662001003ffe000105
2251a29b3ff42226c04eb5fef530d450dedb59ebafa18b00d7
2252f5ed0ac08a81975034297bea2b000418132001003ffe00
22530105b82bf1c99d87273103fc83f6ecd9b91842f205c222
2254dd71d8e165ad18ca91daf9299a73eec850c756a7e9be46
2255f51dddfa0f09db7bfdde14eec07c7a6dd1061c1d5ace94
2256d9ad97940d280000000000000000000000000000000000
2257a03b0f7a6feb0d198167045058cfc49f73129917024d22This is a Wrapper with FEC that also gets spread out over 8 seconds 🦋:
2250078b10ea510902e0dd7c6560115e671200000000000000
22510000000000000000000000000060220000420000000000
2252000000000100000000000000000010ea5109002001003f
2253fe000105a29b3ff42226c04ef0ecad581a030ca790152a
22542f08df5762a463e24a742d1c530ec977bbe0d113697e2b
2255b909d6c7557bdaf1227ce86154b030daadda4a6b8474de
22569a62f6c375020826000000000000000000000000000000
2257f5e8eebcb04f8c2197526053e66c010d5d7297ff7c1fe0And this is the Manifest with FEC, sent in the same second as the original messages 💜:
225008b110ea510903e0dd7c6560115e670000000000000000
2251d57594875f8608b4d61dc9224ecf8b842bd4862734ed01
22522ca2e5f2b8a3e61547b81704766ba3eeb651be7eafc928
22538884e3e28a24fd5529bc2bd4862734ed012ca2e5f2b8a3
2254e61547b81704766ba3eeb62001003ffe000105a29b3ff4
22552226c04efb729846e7d110903797066fd96f49a77c5a48
2256c4c3b330be05bc4a958e9641718aaa31aeabad368386a2
22579ed2dce2769120da83edbcdc0858dd1e357755e7860317
2258e7c06a5918ea62a937391cbfe0983539de1b2e688b7c83Acknowledgments 🫶
the authors want to shoutout these amazing people 📣✨:
- Ryan Quigley, James Mussi, and Joseph Stanton of AX Enterprize, LLC for early prototyping to find holes in earlier drafts of this specification 🔍.
- Carsten Bormann for the simple approach of using bit-column-wise parity for erasure (dropped frame) FEC 🧠.
- Soren Friis for pointing out that Wi-Fi implementations would not always give access to the MAC Address, as was originally used in calculation of the hashes for DRIP Manifest. Also, for confirming that Message Packs (0xF) can only carry up to 9 ASTM frames worth of data (9 Authentication Pages) 👑.
- Gabriel Cox (chair of the working group that produced [F3411]) for reviewing the specification for the SAM Type request as the ASTM Designated Expert 💅.
- Mohamed Boucadair (Document Shepherd) for his many patches and comments 🍓.
- Eric Vyncke (DRIP AD) for his guidance regarding the document's path to publication 🌸.
The authors also thank these reviewers, who are absolutely iconic 🌟:
- Rick Salz (secdir)
- Matt Joras (genart)
- Di Ma (dnsdir)
- Gorry Fairhurst (tsvart)
- Carlos Bernardos (intdir)
- Behcet Sarikaya (iotdir)
- Martin Duke (IESG)
- Roman Danyliw (IESG)
- Murray Kucherawy (IESG)
- Erik Kline (IESG)
- Warren Kumari (IESG)
- Paul Wouters (IESG)
Authors' Addresses 💌
Adam Wiethuechter (editor)
AX Enterprize, LLC
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: adam.wiethuechter@axenterprize.com
Stuart Card
AX Enterprize, LLC
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: stu.card@axenterprize.com
Robert Moskowitz
HTT Consulting
Oak Park, MI 48237
United States of America
Email: rgm@labs.htt-consult.com📦 where this page comes from
- ietf: rfc9575 2024-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms