idnits 2.17.1 draft-moskowitz-drip-crowd-sourced-rid-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 20, 2020) is 1429 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRIP R. Moskowitz 3 Internet-Draft HTT Consulting 4 Intended status: Standards Track S. Card 5 Expires: November 21, 2020 A. Wiethuechter 6 AX Enterprize 7 S. Zhao 8 Tencent 9 H. Birkholz 10 Fraunhofer SIT 11 May 20, 2020 13 Crowd Sourced Remote ID 14 draft-moskowitz-drip-crowd-sourced-rid-04 16 Abstract 18 This document describes using the ASTM Broadcast Remote ID (B-RID) 19 specification in a "crowd sourced" smart phone environment to provide 20 much of the FAA mandated Network Remote ID (N-RID) functionality. 21 This crowd sourced B-RID data will use multilateration to add a level 22 of reliability in the location data on the Unmanned Aircraft (UA). 23 The crowd sourced environment will also provide a monitoring coverage 24 map to authorized observers. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on November 21, 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Draft Status . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 64 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1. Meeting the needs of Network ID . . . . . . . . . . . . . 6 67 3.2. Advantages of Broadcast Remote ID . . . . . . . . . . . . 6 68 3.3. Trustworthiness of Proxied Data . . . . . . . . . . . . . 7 69 3.4. Defense against fraudulent RID Messages . . . . . . . . . 7 70 4. The Finder - SDSP Security Relationship . . . . . . . . . . . 7 71 4.1. The Finder Map . . . . . . . . . . . . . . . . . . . . . 8 72 4.2. Managing Finders . . . . . . . . . . . . . . . . . . . . 8 73 5. The CS-RID Messages . . . . . . . . . . . . . . . . . . . . . 8 74 5.1. CS-RID MESSAGE TYPE . . . . . . . . . . . . . . . . . . . 9 75 5.1.1. CDDL description for CS-RID message type . . . . . . 9 76 5.2. The CS-RID B-RID Proxy Message . . . . . . . . . . . . . 11 77 5.2.1. CS-RID ID . . . . . . . . . . . . . . . . . . . . . . 12 78 5.2.2. CDDL description for CS-RID B-RID Proxy Message . . . 12 79 5.3. CS-RID Finder Registration . . . . . . . . . . . . . . . 13 80 5.3.1. CDDL description for Finder Registration . . . . . . 14 81 5.4. CS-RID SDSP Response . . . . . . . . . . . . . . . . . . 14 82 5.4.1. CDDL description for SDSP Response . . . . . . . . . 15 83 5.5. CS-RID Location Update . . . . . . . . . . . . . . . . . 15 84 5.5.1. CDDL description for Location Update . . . . . . . . 16 85 6. The Full CS-RID CDDL specification . . . . . . . . . . . . . 16 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 88 8.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 19 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 91 9.2. Informative References . . . . . . . . . . . . . . . . . 19 92 Appendix A. Using LIDAR for UA location . . . . . . . . . . . . 21 93 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 96 1. Introduction 98 This document defines a mechanism to capture the ASTM Broadcast 99 Remote ID messages (B-RID) [F3411-19] on any Internet connected 100 device that receives them and can forward them to the SDSP(s) 101 responsible for the geographic area the UA and receivers are in. 102 This will create a ecosystem that will meet most if not all data 103 collection requirements that CAAs are placing on Network Remote ID 104 (N-RID). 106 These Internet connected devices are herein called "Finders", as they 107 find UAs by listening for B-RID messages. The Finders are B-RID 108 forwarding proxies. Their potentially limited spacial view of RID 109 messages could result in bad decisions on what messages to send to 110 the SDSP and which to drop. The SDSP will make any filtering 111 decisions in what it forwards to the UTM(s). 113 Finders can be smartphones, tablets, connected cars, or any computing 114 platform with Internet connectivity that can meet the requirements 115 defined in this document. It is not expected, nor necessary, that 116 Finders have any information about a UAS beyond the content in the 117 B-RID messages. 119 Finders MAY only need a loose association with the SDSP(s). They may 120 only have the SDSP's Public Key and FQDN. It would use these, along 121 with the Finder's Public Key to use ECIES, or other security methods, 122 to send the messages in a secure manner to the SDSP. The SDSP MAY 123 require a stronger relationship to the Finders. This may range from 124 the Finder's Public Key being registered to the SDSP with other 125 information so that the SDSP has some level of trust in the Finders 126 to requiring transmissions be sent over long-lived transport 127 connections like ESP or DTLS. 129 This document has minimal information about the actions of SDSPs. In 130 general the SDSP is out of scope of this document. That said, the 131 SDSPs should not simply proxy B-RID messages to the UTM(s). They 132 should perform some minimal level of filtering and content checking 133 before forwarding those messages that pass these tests in a secure 134 manner to the UTM(s). 136 The SDSPs are also capable of maintaining a monitoring map, based on 137 location of active Finders. UTMs may use this information to notify 138 authorized observers of where this is and there is not monitoring 139 coverage. They may also use this information of where to place pro- 140 active monitoring coverage. 142 An SDSP SHOULD only forward Authenticated B-RID messages like those 143 defined in [tmrid-auth] to the UTM(s). Further, the SDSP SHOULD 144 validate the Remote ID (RID) and the Authentication signature before 145 forwarding anything from the UA. 147 When 3 or more Finders are reporting to an SDSP on a specific UA, the 148 SDSP is in a unique position to perform multilateration on these 149 messages and compute the Finder's view of the UA location to compare 150 with the UA Location/Vector messages. This check against the UA's 151 location claims is both a validation on the UA's reliability as well 152 as the trustworthiness of the Finders. Other than providing data to 153 allow for multilateration, this SDSP feature is out of scope of this 154 document. 156 1.1. Draft Status 158 This draft is still incomplete. New features are being added as 159 capabilities are researched. The actual message formats also still 160 need work. 162 2. Terms and Definitions 164 2.1. Requirements Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 168 "OPTIONAL" in this document are to be interpreted as described in 169 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 170 capitals, as shown here. 172 2.2. Definitions 174 B-RID: 175 Broadcast Remote ID. A method of sending RID messages as 1-way 176 transmissions from the UA to any Observers within radio range. 178 CAA: 179 Civil Aeronautics Administration. An example is the Federal 180 Aviation Administration (FAA) in the United States of America. 182 DAA: 183 Detect and Avoid. The process of a UA detecting obstacles, like 184 other UAs and taking the necessary evasive action. 186 ECIES: 187 Elliptic Curve Integrated Encryption Scheme. A hybrid encryption 188 scheme which provides semantic security against an adversary who 189 is allowed to use chosen-plaintext and chosen-ciphertext attacks. 191 GCS: 193 Ground Control Station. The part of the UAS that the remote pilot 194 uses to exercise C2 over the UA, whether by remotely exercising UA 195 flight controls to fly the UA, by setting GPS waypoints, or 196 otherwise directing its flight. 198 Finder: 199 In Internet connected device that can receive B-RID messages and 200 forward them to a UTM. 202 Observer: 203 Referred to in other UAS documents as a "user", but there are also 204 other classes of RID users, so we prefer "observer" to denote an 205 individual who has observed an UA and wishes to know something 206 about it, starting with its RID. 208 Multilateration: 209 Multilateration (more completely, pseudo range multilateration) is 210 a navigation and surveillance technique based on measurement of 211 the times of arrival (TOAs) of energy waves (radio, acoustic, 212 seismic, etc.) having a known propagation speed. 214 NETSP: 215 Network RID Service Provider. USS receiving Network RID messages 216 from UAS (UA or GCS), storing for a short specified time, making 217 available to NETDP. 219 NETDP: 220 Network RID Display Provider. Entity (might be USS) aggregating 221 data from multiple NETSPs to answer query from observer (or other 222 party) desiring Situational Awareness of UAS operating in a 223 specific airspace volume. 225 N-RID: 226 Network Remote ID. A method of sending RID messages via the 227 Internet connection of the UAS directly to the UTM. 229 RID: 230 Remote ID. A unique identifier found on all UA to be used in 231 communication and in regulation of UA operation. 233 SDSP: 234 Supplemental Data Service Provider. Entity providing information 235 that is allowed, but not required to be present in the UTM system. 237 UA: 238 Unmanned Aircraft. In this document UA's are typically though of 239 as drones of commercial or military variety. This is a very 240 strict definition which can be relaxed to include any and all 241 aircraft that are unmanned. 243 UAS: 244 Unmanned Aircraft System. Composed of Unmanned Aircraft and all 245 required on-board subsystems, payload, control station, other 246 required off-board subsystems, any required launch and recovery 247 equipment, all required crew members, and C2 links between UA and 248 the control station. 250 UTM: 251 UAS Traffic Management. A "traffic management" ecosystem for 252 uncontrolled operations that is separate from, but complementary 253 to, the FAA's Air Traffic Management (ATM) system. 255 USS: 256 UAS Service Supplier. Provide UTM services to support the UAS 257 community, to connect Operators and other entities to enable 258 information flow across the USS network, and to promote shared 259 situational awareness among UTM participants. (From FAA UTM 260 ConOps V1, May 2018). 262 3. Problem Space 264 3.1. Meeting the needs of Network ID 266 The Federal (US) Aviation Authority (FAA), in the December 31, 2019 267 Remote ID Notice of Proposed Rulemaking [FAA-NPRM], is requiring 268 "Standard" and "Limited" Remote ID. Standard is when the UAS 269 provides both Network and Broadcast RID. Limited is when the UAS 270 provides only Network RID. The FAA has dropped their previous 271 position on allowing for only Broadcast RID. We can guess as to 272 their reasons; they are not spelled out in the NPRM. It may be that 273 just B-RID does not meet the FAA's statutory UA tracking 274 responsibility. 276 The UAS vendors have commented that N-RID places considerable demands 277 on currently used UAS. For some UAS like RC planes, meaningful N-RID 278 (via the Pilot's smartphone) are of limited value. A mechanism that 279 can augment B-RID to provide N-RID would help all members of the UAS 280 environment to provide safe operation and allow for new applications. 282 3.2. Advantages of Broadcast Remote ID 284 B-RID has its advantages over N-RID. 286 o B-RID can more readily be implemented directly in the UA. N-RID 287 will more frequently be provided by the GCS or a pilot's Internet 288 connected device. 290 * If Command and Control (C2) is bi-directional over a direct 291 radio connection, B-RID could be a straight-forward addition. 293 * Small IoT devices can be mounted on UA to provide B-RID. 295 o B-RID can also be used by the UA to assist in Detect and Avoid 296 (DAA). 298 o B-RID is available to observers even in situations with no 299 Internet like natural disaster situations. 301 3.3. Trustworthiness of Proxied Data 303 When a proxy is introduced in any communication protocol, there is a 304 risk of corrupted data and DOS attacks. 306 The Finders, in their role as proxies for B-RID, are authenticated to 307 the SDSP (see Section 4). The SDSP can compare the information from 308 multiple Finders to isolate a Finder sending fraudulent information. 309 SDSPs can additionally verify authenticated messages that follow 310 [tmrid-auth]. 312 The SPDP can manage the number of Finders in an area (see 313 Section 4.2) to limit DOS attacks from a group of clustered Finders. 315 3.4. Defense against fraudulent RID Messages 317 The strongest defense against fraudulent RID messages is to focus on 318 [tmrid-auth] conforming messages. Unless this behavior is mandated, 319 SPDPs will have to use assorted algorithms to isolate messages of 320 questionable content. 322 4. The Finder - SDSP Security Relationship 324 The SDSP(s) and Finders SHOULD use EDDSA [RFC8032] keys as their 325 trusted Identities. The public keys SHOULD be registered 326 Hierarchical HITS, [hierarchical-hit] and [hhit-registries]. 328 The SDSP uses some process (out of scope here) to register the 329 Finders and their EDDSA Public Key. During this registration, the 330 Finder gets the SDSP's EDDSA Public Key. These Public Keys allow for 331 the following options for authenticated messaging from the Finder to 332 the SDSP. 334 1. ECIES can be used with a unique nonce to authenticate each 335 message sent from a Finder to the SDSP. 337 2. ECIES can be used at the start of some period (e.g. day) to 338 establish a shared secret that is then used to authenticate each 339 message sent from a Finder to the SDSP sent during that period. 341 3. HIPv2 [RFC7401] can be used to establish a session secret that is 342 then used with ESP [RFC4303] to authenticate each message sent 343 from a Finder to the SDSP. 345 4. DTLS [RFC5238] can be used to establish a secure connection that 346 is then used to authenticate each message sent from a Finder to 347 the SDSP. 349 4.1. The Finder Map 351 The Finders are regularly providing their SDSP with their location. 352 This is through the B-RID Proxy Messages and Finder Location Update 353 Messages. With this information, the SDSP can maintain a monitoring 354 map. That is a map of where there Finder coverage. 356 4.2. Managing Finders 358 Finder density will vary over time and space. For example, sidewalks 359 outside an urban train station can be packed with pedestrians at rush 360 hour, either coming or going to their commute trains. An SDSP may 361 want to proactively limit the number of active Finders in such 362 situations. 364 Using the Finder mapping feature, the SDSP can instruct Finders to 365 NOT proxy B-RID messages. These Finders will continue to report 366 their location and through that reporting, the SDSP can instruct them 367 to again take on the proxying role. For example a Finder moving 368 slowly along with dozens of other slow-moving Finders may be 369 instructed to suspend proxying. Whereas a fast-moving Finder at the 370 same location (perhaps a connected car or a pedestrian on a bus) 371 would not be asked to suspend proxying as it will soon be out of the 372 congested area. 374 5. The CS-RID Messages 376 The CS-RID messages between the Finders and the SDSPs primarily 377 support the proxy role of the Finders in forwarding the B-RID 378 messages. There are also Finder registration and status messages. 380 CS-RID information is represented in CBOR [RFC7049]. The CDDL 381 [RFC8610] specification is used for CS-RID message description 382 CS-RID MAC and COAP [RFC7252] for the CS-RID protocol. 384 The following is a general representation of the content in the CS- 385 RID messages. 387 ( 388 CS-RID MESSAGE TYPE, 389 CS-RID MESSAGE CONTENT, 390 CS-RID MAC 391 ) 393 The CS-RID MESSAGE CONTENT varies by MESSAGE TYPE. 395 5.1. CS-RID MESSAGE TYPE 397 The CS-RID MESSAGE TYPE is defined in Figure 1: 399 Number CS-RID Message Type 400 ------ ----------------- 401 0 Reserved 402 1 B-RID Forwarding 403 2 Finder Registration 404 3 SDSP Response 405 4 Finder Location 407 Figure 1 409 5.1.1. CDDL description for CS-RID message type 411 The overall CS-RID CDDL description is structured in Figure 2. 413 CSRID_Object = { 414 application-context, 415 info => info_message, 416 proxy_message => broadcast_rid_proxy_message, 417 finder_registration => finder_registration_message, 418 sdsp_response => sdsp_response_message, 419 location_update => location_update_message, 420 } 422 info_message = { 423 common_message_members, 424 message_content => tstr, 425 } 427 common_message_members = ( 428 message_type => message_types, 429 mac_address => #6.37(bstr), 430 ) 432 message_types = &( 433 Reserved : 0, 434 BRD : 1, 435 Finder-Registration : 2, 436 SDSP-Response : 3, 437 Finder-Location : 4, 438 ) 440 Figure 2 442 The application context rule is defined in Figure 3 for CS-RID 443 application identification and version negotiation. 445 application-context = ( 446 application => "DRIP-CSRID", 447 ? version => uint .size(1..2), 448 ) 450 Figure 3 452 The predefined CDDL text string labels (author note: for JSON 453 currently, will move to CBOR uint keys in upcoming versions) used in 454 the specification is listed in Figure 4. 456 application = "application" 457 version = "version" 458 info = "message_info" 459 proxy_message = "proxy_message-type" 460 finder_registration = "finder_registration" 461 sdsp_response = "sdsp_response" 462 location_update = "location_update" 463 rid = "id" 464 message_type = "message_type" 465 mac_address = "mac_address" 466 message_content = "message_content" 467 timestamp = "timestamp" 468 gps = "gps" 469 radio_type = "radio_type" 470 broadcast_mac_address = "broadcast_mac_address" 471 broadcast_message = "broadcast_message" 472 sdsp_id = "sdsp_id" 473 proxy_status_type = "proxy_status_type" 474 update_interval = "update_interval" 476 Figure 4 478 5.2. The CS-RID B-RID Proxy Message 480 The Finders add their own information to the B-RID messages, 481 permitting the SDSP(s) to gain additional knowledge about the UA(s). 482 The RID information is the B-RID message content plus the MAC 483 address. The MAC address is critical, as it is the only field that 484 links a UA's B-RID messages together. Only the ASTM Basic ID Message 485 and possibly the Authentication Message contain the UAS ID field. 487 The Finders add an SDSP assigned ID, a 64 bit timestamp, GPS 488 information, and type of B-RID media to the B-RID message. Both the 489 timestamp and GPS information are for when the B-RID message(s) were 490 received, not forwarded to the SDSP. All this content is MACed using 491 a key shared between the Finder and SDSP. 493 The following is a representation of the content in the CS-RID 494 messages. 496 ( 497 CS-RID MESSAGE TYPE, 498 CS-RID ID, 499 RECEIVE TIMESTAMP, 500 RECEIVE GPS, 501 RECEIVE RADIO TYPE, 502 B-RID MAC ADDRESS, 503 B-RID MESSAGE, 504 CS-RID MAC 505 ) 507 5.2.1. CS-RID ID 509 The CS-RID ID is the ID recognized by the SDSP. This may be an HHIT 510 Hierarchical HITs [hierarchical-hit], or any ID used by the SDSP. 512 5.2.2. CDDL description for CS-RID B-RID Proxy Message 514 The broadcast CS-RID proxy CDDL is defined in Figure 5 515 broadcast_rid_proxy_message = { 516 common_message_members, 517 rid => tstr, 518 timestamp => tdate, 519 gps => gps-coordinates, 520 radio_type => radio_types, 521 broadcast_mac_address => #6.37(bstr), 522 broadcast_message => #6.37(bstr), 523 } 525 radio_types = &( 526 EFL : 0, 527 VLF : 1, 528 LF : 2, 529 MF : 3, 530 HF : 4, 531 HF : 5, 532 VHF : 6, 533 UHF : 7, 534 SHF : 8, 535 EHF : 9, 536 ) 538 gps-coordinates = [ 539 latitude : float, 540 longitude: float, 541 ] 543 Figure 5 545 5.3. CS-RID Finder Registration 547 The CS-RID Finder MAY use HIPv2 [RFC7401] with the SDSP to establish 548 a Security Association and a shared secret to use for the CS-RID MAC 549 generation. In this approach, the HIPv2 mobility functionality and 550 ESP [RFC4303] support are not used. 552 When HIPv2 is used as above, the Finder Registration is a SDSP "wake 553 up". It is sent prior to the Finder sending any proxied B-RID 554 messages to ensure that the SDSP is able to receive and process the 555 messages. 557 In this usage, the CS-RID is the Finder HIT. If the SDSP has lost 558 state with the Finder, it initiates the HIP exchange with the Finder 559 to reestablish HIP state and a new shared secret for the CS-RID B-RID 560 Proxy Messages. In this case the Finder Registration Message is: 562 ( 563 CS-RID MESSAGE TYPE, 564 CS-RID ID, 565 CS-RID TIMESTAMP, 566 CS-RID GPS, 567 CS-RID MAC 568 ) 570 5.3.1. CDDL description for Finder Registration 572 The CDDL for CS-RID Finder Registration is defined in Figure 6 574 finder_registration_message = { 575 common_message_members, 576 rid => tstr, 577 timestamp => tdate, 578 gps => gps-coordinates, 579 } 581 gps-coordinates = [ 582 latitude : float, 583 longitude: float, 584 ] 586 Figure 6 588 5.4. CS-RID SDSP Response 590 The SDSP MAY respond to any Finder messages to instruct the Finder on 591 its behavior. 593 ( 594 CS-RID MESSAGE TYPE, 595 SDSP ID, 596 CS-RID ID, 597 CS-RID PROXY STATUS, 598 CS-RID UPDATE INTERVAL, 599 CS-RID MAC 600 ) 602 The Proxy Status instructs the Finder if it should actively proxy 603 B-RID messages, or suspend proxying and only report its location. 605 The Update Interval is the frequency that the Finder SHOULD notify 606 the SDSP of its current location using the Location Update message. 608 5.4.1. CDDL description for SDSP Response 610 The CDDL for CS-RID SDSP response is defined in Figure 7 612 sdsp_response_message = { 613 common_message_members, 614 sdsp_id => tstr, 615 rid => tstr, 616 proxy_status_type => proxy_status_types, 617 update_interval => uint, 618 } 620 gps-coordinates = [ 621 latitude : float, 622 longitude: float, 623 ] 625 proxy_status_types = &( 626 0: "forward", 627 1: "reverse", 628 2: "bi-directional", 629 ) 631 Figure 7 633 5.5. CS-RID Location Update 635 The Finder SHOULD provide regular location updates to the SDSP. The 636 interval is based on the Update Interval from Section 5.4 plus a 637 random slew less than 1 second. The Location Update message is only 638 sent when no other CS-RID messages, containing the Finder's GPS 639 location, have been sent since the Update Interval. 641 If the Finder has not recieved a SDSP Registration Response, a 642 default of 5 minutes is used for the Update Interval. 644 ( 645 CS-RID MESSAGE TYPE, 646 CS-RID ID, 647 CS-RID TIMESTAMP, 648 CS-RID GPS, 649 CS-RID MAC 650 ) 652 5.5.1. CDDL description for Location Update 654 The CDDL for CS-RID Location update is defined in Figure 8 656 location_update_message = { 657 common_message_members, 658 rid => tstr, 659 timestamp => tdate, 660 gps => gps-coordinates, 661 } 663 gps-coordinates = [ 664 latitude : float, 665 longitude: float, 666 ] 668 Figure 8 670 6. The Full CS-RID CDDL specification 672 673 ; CDDL specification for Crowd source RID 674 ; It specifies a collection of CS message types 675 ; 677 ; 678 ; The CSRID overall data structure 680 CSRID_Object = { 681 application-context, 682 info => info_message, 683 proxy_message => broadcast_rid_proxy_message, 684 finder_registration => finder_registration_message, 685 sdsp_response => sdsp_response_message, 686 location_update => location_update_message, 687 } 689 ; 690 ; Application context: general information about CSRID message 692 application-context = ( 693 application => "DRIP-CSRID", ; TBD: consider CBOR tag 694 ? version => uint .size(1..2), 695 ) 697 ; These members are include in every message 698 common_message_members = ( 699 message_type => message_types, 700 mac_address => #6.37(bstr), 701 ) 703 ; 704 ; CSRID message general information 706 info_message = { 707 common_message_members, 708 message_content => tstr, 709 } 711 broadcast_rid_proxy_message = { 712 common_message_members, 713 rid => tstr, 714 timestamp => tdate, 715 gps => gps-coordinates, 716 radio_type => radio_types, 717 broadcast_mac_address => #6.37(bstr) 718 broadcast_message => #6.37(bstr) 719 } 721 finder_registration_message = { 722 common_message_members, 723 rid => tstr, 724 timestamp => tdate, 725 gps => gps-coordinates, 726 } 728 sdsp_response_message = { 729 common_message_members, 730 sdsp_id => tstr, 731 rid => tstr, 732 proxy_status_type => proxy_status_types, 733 update_interval => uint, 734 } 736 location_update_message = { 737 common_message_members, 738 rid => tstr, 739 timestamp => tdate, 740 gps => gps-coordinates, 741 } 743 ; 744 ; Common rule definition 746 message_types = &( 747 Reserved : 0, 748 BRD : 1, 749 Finder-Registration : 2, 750 SDSP-Response : 3, 751 Finder-Location : 4, 752 ) 754 gps-coordinates = [ 755 lat: float, 756 long: float, 757 ] 759 ; Radio types, choose from one of radio_types (required) 760 radio_types = &( 761 EFL : 0, 762 VLF : 1, 763 LF : 2, 764 MF : 3, 765 HF : 4, 766 HF : 5, 767 VHF : 6, 768 UHF : 7, 769 SHF : 8, 770 EHF : 9, 771 ) 773 proxy_status_types = &( 774 0: "forward", 775 1: "reverse", 776 2: "bi", 777 ) 779 ; 780 ; JSON label names 782 application = "application" 783 version = "version" 784 info = "message_info" 785 proxy_message = "proxy_message-type" 786 finder_registration = "finder_registration" 787 sdsp_response = "sdsp_response" 788 location_update = "location_update" 789 rid = "id" 790 message_type = "message_type" 791 mac_address = "mac_address" 792 message_content = "message_content" 793 timestamp = "timestamp" 794 gps = "gps" 795 radio_type = "radio_type" 796 broadcast_mac_address = "broadcast_mac_address" 797 broadcast_message = "broadcast_message" 798 sdsp_id = "sdsp_id" 799 proxy_status_type = "proxy_status_type" 800 update_interval = "update_interval" 802 804 7. IANA Considerations 806 TBD 808 8. Security Considerations 810 TBD 812 8.1. Privacy Concerns 814 TBD 816 9. References 818 9.1. Normative References 820 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 821 Requirement Levels", BCP 14, RFC 2119, 822 DOI 10.17487/RFC2119, March 1997, 823 . 825 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 826 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 827 May 2017, . 829 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 830 Definition Language (CDDL): A Notational Convention to 831 Express Concise Binary Object Representation (CBOR) and 832 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 833 June 2019, . 835 9.2. Informative References 837 [F3411-19] 838 ASTM International, "Standard Specification for Remote ID 839 and Tracking", February 2020, 840 . 842 [FAA-NPRM] 843 Federal (US) Aviation Authority, "FAA Remote ID Notice of 844 Proposed Rule Making", December 2019, 845 . 847 [hhit-registries] 848 Moskowitz, R., Card, S., and A. Wiethuechter, 849 "Hierarchical HIT Registries", draft-moskowitz-hip-hhit- 850 registries-02 (work in progress), March 2020. 852 [hierarchical-hit] 853 Moskowitz, R., Card, S., and A. Wiethuechter, 854 "Hierarchical HITs for HIPv2", draft-moskowitz-hip- 855 hierarchical-hit-05 (work in progress), May 2020. 857 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 858 RFC 4303, DOI 10.17487/RFC4303, December 2005, 859 . 861 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 862 the Datagram Congestion Control Protocol (DCCP)", 863 RFC 5238, DOI 10.17487/RFC5238, May 2008, 864 . 866 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 867 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 868 October 2013, . 870 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 871 Application Protocol (CoAP)", RFC 7252, 872 DOI 10.17487/RFC7252, June 2014, 873 . 875 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 876 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 877 RFC 7401, DOI 10.17487/RFC7401, April 2015, 878 . 880 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 881 Signature Algorithm (EdDSA)", RFC 8032, 882 DOI 10.17487/RFC8032, January 2017, 883 . 885 [tmrid-auth] 886 Wiethuechter, A., Card, S., and R. Moskowitz, "TM-RID 887 Authentication Formats", draft-wiethuechter-tmrid-auth-05 888 (work in progress), February 2020. 890 Appendix A. Using LIDAR for UA location 892 If the Finder has LIDAR or similar detection equipment (e.g. on a 893 connected car) that has full sky coverage, the Finder can use this 894 equipment to locate UAs in its airspace. The Finder would then be 895 able to detect non-participating UAs. A non-participating UA is one 896 that the Finder can "see" with the LIDAR, but not "hear" any B-RID 897 messages. 899 These Finders would then take the LIDAR data, construct appropriate 900 B-RID messages, and forward them to the SPDP as any real B-RID 901 messages. There is an open issue as what to use for the actual 902 RemoteID and MAC address. 904 The SDSP would do the work of linking information on a non- 905 participating UA that it has received from multiple Finders with 906 LIDAR detection. In doing so, it would have to select a RemoteID to 907 use. 909 A seemingly non-participating UA may actually be a UA that is beyond 910 range for its B-RID but in the LIDAR range. 912 This would provide valuable information to SDSPs to forward to UTMs 913 on potential at-risk situations. 915 At this time, research on LIDAR and other detection technology is 916 needed. there are full-sky LIDAR for automotive use with ranges 917 varying from 20M to 250M. Would more than UA location information be 918 available? What information can be sent in a CS-RID message for such 919 "unmarked" UAs? 921 Acknowledgments 923 The Crowd Sourcing idea in this document came from the Apple "Find My 924 Device" presentation at the International Association for 925 Cryptographic Research's Real World Crypto 2020 conference. 927 Authors' Addresses 929 Robert Moskowitz 930 HTT Consulting 931 Oak Park, MI 48237 932 USA 934 Email: rgm@labs.htt-consult.com 935 Stuart W. Card 936 AX Enterprize 937 4947 Commercial Drive 938 Yorkville, NY 13495 939 USA 941 Email: stu.card@axenterprize.com 943 Adam Wiethuechter 944 AX Enterprize 945 4947 Commercial Drive 946 Yorkville, NY 13495 947 USA 949 Email: adam.wiethuechter@axenterprize.com 951 Shuai Zhao 952 Tencent 953 2747 Park Blvd 954 Palo Alto, CA 94306 955 USA 957 Email: shuai.zhao@ieee.org 959 Henk Birkholz 960 Fraunhofer SIT 961 Rheinstrasse 75 962 Darmstadt 64295 963 Germany 965 Email: henk.birkholz@sit.fraunhofer.de