]> AX Enterprize, LLC

4947 Commercial Drive Yorkville NY 13495 USA adam.wiethuechter@axenterprize.com

Internet drip Working Group Internet-Draft This document standardizes an architecture to enable trust to sensors that provide Air Domain Awareness. Broadcast Remote ID is used as the primary example to define data models and methods used.

Introduction

• Note: This document is directly related and builds from expanding it to be more general for ADA. That draft is a "top, down" approach to understand the concept and high level design. This document is a "bottom, up" implementation of the CS-RID concept. The content of this draft is subject to change and adapt as further development continues.

Purpose Air Domain Awareness (ADA) is an important part of safe operations for aviation. While this document will focus on adding Broadcast RID for ADA to UTM, the concepts, models and methods in this document can be expanded and used in other domain areas.

Background TBD

Scope This document uses Broadcast RID as a titular example to define a basic architecture and initial method of providing sensor data to UTM in a way that enables trust. This specific scenario is referred to as Crowd Sourced RID (CS-RID).

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 when, and only when, they appear in all capitals, as shown here.

Additional Definitions This document uses terms defined in and as well as those defined below. Finder: Device acting as a sensor of one or more inputs in a domain. For this document the domain is aviation with the inputs being of various types such as audio, video, radio frequency, etc. Supplemental Data Service Provider (SDSP): A server that Finders report updates to and acts as a gateway into UTM. Web Token: An encapsulation mechanism for data. Can be either a CBOR Web Token (CWT, ) or JSON Web Token (JWT, ).

Architecture With the initial use case of providing Broadcast RID for ADA to UTM this architecture closely follows and integrates into the wider UTM. See for more information. All data models in this document are defined in the Concise Data Definition Language (CDDL, ).

Simplified Architecture for Crowd Sourced ADA

• Author TODO: expand to showcase different Finder sources and optional SDSP-to-SDSP interactions.

In this architecture the SDSP depends upon Finders to provide data via its "ingress" and exposes to clients on its "egress" data that has been filtered, aggregated and/or fused. For CS-RID, defined in , Finders report a mix of raw detections or pre-processed UAS data (detected from Broadcast RID) to the SDSP to be further refined and translated to Network RID for UTM Clients. Links between the SDSP and other entities is assumed to be bi-directional unless otherwise noted by a specific use-case. It is up to a given sensor use case to determine more in depth interaction models between the entities. SDSPs can redirect "ingress" reports with unknown data elements if it knows another SDSP under the same ADA ecosystem that will process those unknown elements. An SDSPs "egress" may feed into another SDSP for further aggregation/fusion with other data sources. It is RECOMMENDED that all participating entities of this ecosystem have a DRIP Entity Tag (DET, ) to enable between the parties during all interactions.

Reporting

Reporting Model reporter-datum, ? status => status-datum, * &(tstr, int) => any } ]]>

The reporting model is primarily used between the Finder and SDSP but MAY be used between SDSP and its clients. A report is filled with various different models under unique keys. This document defines required report keys and models for CS-RID in and additional OPTIONAL ones in .

Encapsulation & Transporting Reports MUST be authenticated and SHOULD be encrypted by its original source. These attributes can come from the combination of the transport and the application layer between the source and destination party. At the application layer the report can be encapsulated in a Web Token to provide both of these attributes. Selection of certain transports can also securely enable for the SDSP to "push" information to Finders, such as provisioning and filtering requests. This problem can be considered a "configuration" problem, thus bringing a number of different alternatives to be used to solve rather than creating another domain specific solution. This problem, while noted, is out of scope for this document. Selection of transport and supported interactions for given use-case, other than Broadcast RID, are out of scope for this document.

Web Token Encapsulation The use of Web Token is RECOMMENDED when the transport layer does not provider either authentication of the source or encryption capabilities. Hosts SHOULD use a DET as the kid in the Web Token but MAY provider either a different kid or place the public key directly in the Web Token header.

HTTPS Transport When using the HTTPS transport Reports MUST be encapsulated in a Web Token as described in to provide client authentication and encryption. It is RECOMMENDED that the SDSP serve their endpoints under /.well-known/csada for interoperability. Support for both Web Token encodings is RECOMMENDED. The use of Mutual TLS as part of the HTTPS exchange has not been explored for this architecture, but is theoretically possible for small and large scale deployments in both public and private domains when using the DRIP Key Infrastructure X.509 (DKIX).

HIP Transport The Host Identity Protocol (HIP, ) can be used and provides, via the Base Exchange (BEX), authentication and encryption for both parties. DETs MUST be used and Reports MUST be CBOR encoded.

CoAP Transport The Constrained Application Protocol (CoAP, ) is another supported transport that can provide both parties authentication and encryption. DTLS is RECOMMENDED for use and MUST use the DET, and the Report MUST be sent encoded in CBOR. When using UDP, Reports MUST be encapsulated in a CWT per . Use of ./well-known/cs-ada/ similar to HTTPS is encouraged.

Crowd Sourced Remote ID This document defines two data models, and , to be used between the Finder and SDSP. The UTM, RID data encapsulation and transportation is already standardized with an overview provided in . For CS-RID, Finders and SDSP MUST support Web Tokens over HTTPS () as the primary encapsulation and transport method. The other defined transports in MAY be supported by an SDSP. Interactions started by the SDSP to the Finder are out of scope for this document with that link (Finder to SDSP) expected to be unidirectional.

Detection Report

Detections Model

UAS Datum Report

UAS Datum Model utc, ? uas_type => 0..15, ? uas_ids => [ + [ id_type: 0..15, uas_id: uas-id ] ], ? ua_status => 0..15, ? ua_position => [ lla: position, barometric_altitude: number / null ], ? ua_bearing => uint, ? ua_speed => [ vertical: number / null, horizontal: number / null ], ? ua_height => [ agl: bool, height: number ], ? accuracy => [ vertical: 0..15, horizontal: 0..15, altitude: 0..15, barometric: 0..15, timestamp: 0..15 ], ? auth => [ + [ auth_type: 0..15, data: auth-data ] ], ? self_id => [ desc_type: 0..255, desc: tstr .size 23 ], ? fixed_operator_position => position, ? gnss_operator_position => position, ? take_off_position => position, ? classification => [ region: 0..8, category: 0..15, class: 0..15 ], ? area => [ count: 1..255, radius: number, floor: number, ceiling: number ], ? operator_id => [ operator_type: 0..255, operator_id: tstr .size 20 ], ? compliance => [+ uint] } ] transport-enum = ( 0: UKN, 1: BLE, 2: BLR, 3: BCN, 4: NAN, 5: SIK ) ]]>

DRIP Requirements Addressed This document addresses the following requirements from : GEN-5 (Gateway)

IANA Considerations

Well-Known URIs IANA is requested to add the following entries in the "Well-Known URIs" registry . Additions to Well-Known URIs Registry

URI Suffix	Change Controller	Reference	Status	Related Information
csada	IETF	This RFC	permanent	N/A

Security Considerations TBD

Privacy & Transparency Considerations TBD

Acknowledgments The Crowd Sourcing idea in this document came from the Apple "Find My Device" presentation at the International Association for Cryptographic Research's Real World Crypto 2020 conference.

References Normative References JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This document defines terminology and requirements for solutions produced by the Drone Remote Identification Protocol (DRIP) Working Group. These solutions will support Unmanned Aircraft System Remote Identification and tracking (UAS RID) for security, safety, and other purposes (e.g., initiation of identity-based network sessions supporting UAS applications). DRIP will facilitate use of existing Internet resources to support RID and to enable enhanced related services, and it will enable online and offline verification that RID information is trustworthy. This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses, which makes them trustable identifiers for use in Unmanned Aircraft System Remote Identification (UAS RID) and tracking. Within the context of RID, HHITs will be called DRIP Entity Tags (DETs). HHITs provide claims to the included explicit hierarchy that provides registry (via, for example, DNS, RDAP) discovery for third-party identifier endorsement. This document updates RFCs 7401 and 7343. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. This document describes an architecture for protocols and services to support Unmanned Aircraft System Remote Identification and tracking (UAS RID), plus UAS-RID-related communications. This architecture adheres to the requirements listed in the Drone Remote Identification Protocol (DRIP) Requirements document (RFC 9153). HTT Consulting AX Enterprize AX Enterprize Intel Fraunhofer SIT This document describes using the ASTM Broadcast Remote ID (B-RID) specification in a "crowd sourced" smart phone or fixed receiver asset environment to provide much of the ASTM and FAA envisioned Network Remote ID (Net-RID) functionality. This crowd sourced B-RID (CS-RID) data will use multilateration to add a level of reliability in the location data on the Uncrewed Aircraft (UA). The crowd sourced environment will also provide a monitoring coverage map to authorized observers. ASTM International IANA

ASTM Network RID Overview This appendix is normative and an overview of the Network RID portion of . This appendix is intended a guide to the overall object of Network RID and generally how it functions in context with a SDSP supporting CS-RID. Please refer to the actual standard of for specifics in implementing said protocol. For CS-RID the goal is for the SDSP to act as both a Network RID Service Provider (SP) and Network RID Display Provider (DP). The endpoints and models MUST follow the specifications for these roles so UTM clients do not need to implement specific endpoints for CS-RID and can instead leverage existing endpoints. An SDSP SHOULD use Network RID, as it is able, to query a USS for UAS sending telemetry in a given area to integrate into the Broadcast RID it is receiving from Finders. How the SDSP discovers which USS to query is out of scope for this document. An SDSP MUST provide the Network RID DP interface for clients that wish to subscribe for updates on aircraft in the SDSP aggregated coverage area.

Additional Report Models

Global Navigation Satellite System (GNSS)

GNSS Model

Reporter

Reporter Model any } ]]>

Finder Status

Status Model any } ]]>