idnits 2.17.1 draft-moskowitz-drip-secure-nrid-c2-07.txt: -(8): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. 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 (13 May 2022) is 713 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) == Missing Reference: 'F3411' is mentioned on line 386, but not defined == Unused Reference: 'RFC7252' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'RFC8949' is defined on line 655, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: 14 November 2022 A. Wiethuechter 6 AX Enterprize 7 A. Gurtov 8 Linköping University 9 13 May 2022 11 Secure UAS Network RID and C2 Transport 12 draft-moskowitz-drip-secure-nrid-c2-07 14 Abstract 16 This document defines a transport mechanism for Unmanned Aircraft 17 System (UAS) Network Remote ID (Net-RID). The Broadcast Remote ID 18 (B-RID) messages can be sent directly over UDP or via a more 19 functional protocol using CoAP/CBOR for the Net-RID messaging. This 20 is secured via either HIP/ESP or DTLS. HIP/ESP or DTLS secure 21 messaging Command-and-Control (C2) for is also described. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 14 November 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 59 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Network Remote ID . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Network RID Endpoints . . . . . . . . . . . . . . . . . . 5 62 3.1.1. Net-RID from the UA . . . . . . . . . . . . . . . . . 5 63 3.1.2. Net-RID from the GCS . . . . . . . . . . . . . . . . 6 64 3.1.3. Net-RID from the Operator . . . . . . . . . . . . . . 6 65 3.2. Network RID Messaging . . . . . . . . . . . . . . . . . . 6 66 3.2.1. Secure Link Setup . . . . . . . . . . . . . . . . . . 7 67 3.2.2. Static Messages . . . . . . . . . . . . . . . . . . . 7 68 3.2.3. Vector/Location Message . . . . . . . . . . . . . . . 8 69 3.3. The Minimal, UDP, Net-RID Protocol . . . . . . . . . . . 9 70 3.3.1. Compressing the MNet-RID message headers . . . . . . 9 71 3.4. CoAP Net-RID messages . . . . . . . . . . . . . . . . . . 10 72 4. Command and Control . . . . . . . . . . . . . . . . . . . . . 10 73 4.1. Securing MAVLink . . . . . . . . . . . . . . . . . . . . 11 74 4.1.1. Compressed ESP for MAVlink . . . . . . . . . . . . . 11 75 4.2. Compressed UDP/DTLS for MAVlink . . . . . . . . . . . . . 11 76 5. Secure Transports . . . . . . . . . . . . . . . . . . . . . . 11 77 5.1. HIP for Secure Transport . . . . . . . . . . . . . . . . 12 78 5.2. DTLS for Secure Transport . . . . . . . . . . . . . . . . 12 79 5.3. Ciphers for Secure Transport . . . . . . . . . . . . . . 13 80 5.4. HIP and DTLS contrasted and compared . . . . . . . . . . 13 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 83 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 86 9.2. Informative References . . . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 89 1. Introduction 91 This document defines a set of messages for Unmanned Aircraft System 92 (UAS) Network Remote ID (Net-RID) derived from the ASTM Remote ID 93 [F3411-19] broadcast messages and common data dictionary. These 94 messages are transported from the UAS to its USS Network Service 95 Provider (Net-RID SP) either directly over UDP or via CoAP/CBOR 96 ([RFC7252]/[RFC8949]). 98 Direct UDP, referred here as Minimal Net-RID (MNet-RID), and CoAP/ 99 CBOR were selected for their low communication "cost". This may not 100 be an issue if Net-RID originates from the Ground Control Station 101 (GCS, Section 3.1.2), but it may be an important determinant when 102 originating from the UA (Section 3.1.1). Particularly, very small 103 messages may open Net-RID transmissions over a variety of wireless 104 technologies. 106 This document also defines mechanisms to provide secure transport for 107 these Net-RID messages and Command and Control (C2) messaging. 109 A secure end-to-end transport for Net-RID (UAS to Network RID Service 110 Provider (Net-RID SP)) also should provide full Confidentiality, 111 Integrity, and Authenticity (CIA). It may seem that confidentiality 112 is optional, as most of the information in Net-RID is sent in the 113 clear in Broadcast Remote ID (B-RID), but this is a potentially 114 flawed analysis. Net-RID has evesdropping risks not in B-RID and may 115 contain more sensitive information than B-RID. The secure transport 116 for Net-RID should also manage IP address changes (IP mobility) for 117 the UAS. 119 A secure end-to-end transport for C2 is critical for UAS especially 120 for Beyond Line of Sight (BLOS) operations. It needs to provide data 121 CIA. Depending on the underlying network technology, this secure 122 transport may need to manage IP address changes (IP mobility) for 123 both the UA and GCS. 125 Two options for secure transport are provided: HIP [RFC7401] with ESP 126 [RFC7402] and DTLS 1.3 [DTLS-1.3-draft]. These options are generally 127 defined and their applicability is compared and contrasted. It is up 128 to Net-RID and C2 to select which is preferred for their situation. 130 MOBIKE [RFC5266] is an alternative to HIP for ESP key establishment. 131 It functions enough like HIP that it was left out, but implied, for 132 document simplicity. The may be some identity pieces needed to map 133 HHITs and HIs to what MOBIKE uses. 135 To further reduce the communication cost, SCHC [RFC8724] is defined 136 for both the direct UDP and CoAP layer [RFC8824]. For ESP 137 "compression", ESP Implicit IV, [RFC8750] and Diet ESP [diet-esp] may 138 be used together. SCHC for the IP/UDP layer is currently defined by 139 IP carrier (e.g. LoRaWAN, [RFC9011]) and will be covered in any 140 specific implementation. 142 2. Terms and Definitions 143 2.1. Requirements Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 2.2. Definitions 153 See Section 2.2 of [RFC9153] for common DRIP terms. The following 154 new terms are used in the document: 156 B-RID 157 Broadcast Remote ID. A method of sending RID messages as 1-way 158 transmissions from the UA to any Observers within radio range. 160 MNet-RID 161 A Minimal implementation of Network Remote ID, based on B-RID 162 messages directly over UDP. 164 Net-RID 165 Network Remote ID. A method of sending RID messages via the 166 Internet connection of the UAS directly to the UTM. 168 RID 169 Remote ID. A unique identifier found on all UA to be used in 170 communication and in regulation of UA operation. 172 3. Network Remote ID 174 In UAS Traffic Management (UTM), the purpose of Net-RID is to provide 175 situational awareness of UA (in the form of flight tracking) in a 176 user specified 3D volume. The data needed for this is already 177 defined in [F3411-19], but a standard message format, protocol, and 178 secure communications methodology are missing. F3411, and other UTM 179 based standards going through ASTM and other SDOs, provide JSON 180 objects and some of the messages for passing information between 181 various UTM entities (e.g., Net-RID SP to Net-RID SP and Net-RID SP 182 to Net-RID DP) but does not specify how the data gets into UTM to 183 begin with. This document will provide such an open standard. 185 A full-function CoAP-based Net-RID protocol is defined in 186 Section 3.4. This provides for either transport of the appropriate 187 B-RID messages and/or the [F3411-19] data elements encoded in CBOR. 189 A minimal messaging approach (MNet-RID, Section 3.3), only using the 190 Broadcast Remote ID (B-RID) messages in [F3411-19], is sufficient to 191 meet the needs of Net-RID. These messages can be sent to the Net-RID 192 SP when their contents change. Further, a UAS supporting B-RID will 193 have minimal development to add Net-RID support. 195 This approach has the added advantage of being very compact, 196 minimizing the Net-RID communications cost. 198 Other messages may be needed in some Net-RID situations. Thus a 199 simple message multiplexer is provided for MNet-RID and CoAP is 200 defined for a richer messaging environment. 202 3.1. Network RID Endpoints 204 The US FAA defines the Network Remote ID endpoints as a USS Network 205 Service Provider (Net-RID SP) and the UAS. Both of these are rather 206 nebulous items and what they actually are will impact how 207 communications flow between them. 209 The Net-RID SP may be provided by the same entity serving as the UAS 210 Service Provider (USS). This simplifies a number of aspects of the 211 Net-RID communication flow. The Net-RID SP is likely to be stable in 212 the network, that is its IP address will not change during a mission. 213 This simplifies maintaining the Net-RID communications. 215 The UAS component in Net-RID may be either the UA, GCS, or the 216 Operator's Internet connected device (e.g. smartphone or tablet that 217 is not the GCS). In all cases, mobility MUST be assumed. That is 218 the IP address of this end of the Net-RID communication may change 219 during an operation. The Net-RID mechanism MUST support this. The 220 UAS Identity for the secure connection may vary based on the UAS 221 endpoint. 223 3.1.1. Net-RID from the UA 225 Some UA will be equipped with direct Internet access. These UA will 226 also tend to have multiple radios for their Internet access (e.g., 227 Cellular and WiFi). Thus multi-homing with "make before break" 228 behavior is needed. This is on top of any IP address changes on any 229 of the interfaces while in use. 231 Multicast (GEN-10 in [RFC9153]) over multiple Internet connection 232 technologies MAY be used improve QOS (GEN-7 in [RFC9153]) for Net- 233 RID. (Author's question: Is this really qualify as multicast?) 235 3.1.2. Net-RID from the GCS 237 Many UA will lack direct Internet access, but their GCS are 238 connected. As an Operator is expected to register an operation with 239 its USS, this may be done via the Internet connected GCS. The GCS 240 could then be the source of the secure connection for Net-RID (acting 241 as a gateway). 243 There are two sources of the RID messages for the GCS, both from the 244 UA. These are UA B-RID messages, or content from C2 messages that 245 the GCS converts to RID message format. In either case, the GCS may 246 be mobile with changing IP addresses. The GCS may be in a fast 247 moving ground device (e.g. delivery van), so it can have as mobility 248 demanding connection needs as the UA. 250 In a constrained wireless environment for the UA that is not 251 functioning autonomously (i.e., at least C2 traffic to the GCS), this 252 approach may be the most economical. It only uses the wireless to 253 send the UA status once, to the GCS, that then provides the Net-RID 254 functionality. 256 3.1.3. Net-RID from the Operator 258 Many UAS will have no Internet connectivity, but the UA is sending 259 B-RID messages and the Operator, when within RF range, can receive 260 these B-RID messages on an Internet Connected device that can act as 261 the proxy for these messages, turning them into Net-RID messages. 263 3.2. Network RID Messaging 265 Net-RID messaging is tied to a UA operation (generally called a 266 flight or mission). This consists of an initial secure link setup, 267 followed by a set of mostly static information related to the 268 operation. During the operation, continuous location information is 269 sent by the UA with any needed updates to the mostly static operation 270 information. 272 The Net-RID SP SHOULD send regular "heartbeats" to the UAS. If the 273 UAS does not receive these heartbeats for some policy set time, the 274 UA MUST take the policy set response to loss of Net-RID SP 275 connectivity. For example, this could be a mandated immediate 276 landing. There may be other messages from the Net-RID SP to the UAS 277 (e.g., call the USS operator at this number NOW!). The UAS MUST 278 follow acknowledge policy for these messages. 280 If the Net-RID SP stops receiving messages from the UAS 281 (Section 3.2.3), it should notify the UTM of a non-communicating UA 282 while still in operation. 284 3.2.1. Secure Link Setup 286 The secure link setup MUST be done before the operation begins, thus 287 it can use a high capacity connection like WiFi. It MAY use the UA 288 RID for this setup, including other data elements provided in the 289 B-RID Basic ID (Msg Type 0x0) Message. If the Basic ID information 290 is NOT included via the secure setup (including the Net-RID SP 291 querying the USS for this information), it MUST be sent as part of 292 the Static Messages (Section 3.2.2) 294 3.2.1.1. UAS Identity 296 The UAS MAY use its RID if it is a HHIT (DET per [drip-uas-rid]). It 297 may use some other Identity, based on the Net-RID SP policy. 299 The GCS or Operator smart device may have a copy of the UA 300 credentials and use them in the connection to the Net-RID SP. In 301 this case, they are indistinguishable from the UA as seen from the 302 Net-RID SP. Alternatively, they may use their own credentials with 303 the Net-RID SP which would need some internal mechanism to tie that 304 to the UA. 306 3.2.1.2. HIP for ESP Secure Link 308 HIP [RFC7401] for ESP Secure Link is a natural choice for a DET RID. 309 For this, the Net-RID SP would also need a HHIT, possibly following 310 the process in [drip-registries]. 312 3.2.1.3. DTLS Secure Link 314 For DTLS [DTLS-1.3-draft] secure link, DANCE [dane-clients] may be 315 used with a DET's DNS lookup to retrieve a TLSA RR with the DET's HI 316 encoded in PKIX SubjectPublicKeyInfo format (per [RFC7250]). 318 The Net-RID SP DTLS credential may follow DANE [RFC6698] or any other 319 DTLS server credential method. 321 3.2.2. Static Messages 323 For simplicity, a class of UAS information is called here "Static", 324 though in practice any of it can change during the operation, but 325 will change infrequently. This information is the contents of the 326 B-RID Self-ID (Msg Type 0x3), Operator ID (Msg Type 0x5), and System 327 Messages (Msg Type 0x4). This information can simply be sent in the 328 same format as the B-RID messages. Alternatively the individual data 329 elements may be send as separate CBOR objects. 331 The Basic ID (Msg Type 0x0) Message may be included as a static 332 message if this information was not used for the secure setup. There 333 may be more than one Basic ID Message needed if as in the case where 334 the Japan Civil Aviation Bureau (JCAB) has mandated that the CAA 335 assigned ID (UA ID type 2) and Serial Number (UA ID type 1) be 336 broadcasted. 338 The information in the System Message is most likely to change during 339 an operation. Noteably the Operator Location data elements are 340 subject to change if the GCS is physically moving (e.g. hand-held 341 and the operator is walking or driving in a car). The whole System 342 Message may be sent, or only the changing data elements as CBOR 343 objects. 345 These static message elements may be sent before the operation 346 begins, thus their transmission can use a high capacity connection 347 like WiFi. Once the operation is underway, any updates will have to 348 traverse the operational link which may be very constrained and this 349 will impact data element formatting. 351 The Net-RID SP MUST acknowledge these messages. The UAS MUST receive 352 these ACKs. If no ACK is received, the UAS MUST resend the 353 message(s). This send/ACK sequence continues either until ACK is 354 received, or some policy number of tries. If this fails, the UAS 355 MUST act that the Net-RID SP connection is lost and MUST take the 356 policy set response to loss of Net-RID SP connectivity. If the 357 information changes during this cycle, the latest information MUST 358 always be sent. 360 3.2.3. Vector/Location Message 362 Many CAAs mandate that the UA Vector/Location information be updated 363 at least once per second. Without careful message design, this 364 messaging volume would overwhelm many wireless technologies. Thus to 365 enable the widest deployment choices, a highly compressed format is 366 recommended. 368 The B-RID Vector/Location Message (Msg Type 0x1) is the simplest 369 small object (24 bytes) for sending this information as a single CBOR 370 object or via MNet-RID. It may be possible to send only those data 371 elements that changed in the last time interval. This may result in 372 smaller individual transmissions, but should not be used if the 373 resulting message is larger than the Vector/Location Message. 375 3.3. The Minimal, UDP, Net-RID Protocol 377 The Minimal Network Remote ID protocol is a simple UDP messaging 378 consisting of a 1-byte message type field and a message field of 379 maximum 25-bytes length. 381 The Message Type Field is defined as follows: 383 Value Type 385 0 RESERVED 386 1 B-RID Message [F3411] 387 2 Net-RID SP ACK 388 3 Net-RID SP Heartbeat 390 The B-RID Message is 25 bytes: 392 Bytes Description 394 1 B-RID Message Type/version 395 24 B-RID Message 397 The Net-RID SP ACK is 5 bytes: 399 Bytes Description 401 4 Timestamp 402 1 B-RID Message Type/version from message ACKed 404 Should a 12byte hash of message be included as in Manifest? 406 The Net-RID SP Heartbeat is 4 bytes: 408 Bytes Description 410 4 Timestamp 412 3.3.1. Compressing the MNet-RID message headers 414 The security envelope (ESP of DTLS) and UDP headers may be compressed 415 to further minimize the communication cost of MN-RID. 417 3.3.1.1. Compressing ESP/UDP headers 419 A normal ESP/AES-GCM-12/UDP wrapper for the NMet-RID messages is 420 10+28+8=46 bytes. By applying the SCHC compression via [diet-esp] 421 and using [RFC8750] Implicit Cipher IVs, this is reduced to 4+12+0=16 422 bytes. 424 AES-CCM-12 has a smaller, but valuable, size reduction on 425 compression, as CCM's IV is only 8 bytes compared to GCM's 16-byte 426 IV. Thus uncompressed, the wrapper is 10+20+8=38 bytes. Compressed 427 it is 4+12+0=16 bytes. Or "over the wire", compressed CCM offers no 428 improvements to GCM and its 2-pass process will tend to result in a 429 poorer performace compared to GCM, even on these small messages. 430 Thus GCM is the recommended mode-of-operation for AES. 432 Note that [RFC8750] does not provide implicit IV use for AES-GCM-12. 433 At the time of writing the use case for the smaller ICV was not 434 apparent. Here, the smaller hash is not a lower risk given the 435 limited traffic within a single operation. If not provided 436 elsewhere, this document will request ENCR_AES_GCM_12_IIV for IKE and 437 both AES_GCM_12 and AES_GCM_12_IIV for HIP. 439 [diet-esp] may be completely statically configured, or may have HIP 440 or IKE negotiated values. This will be determined by Net-RID SP 441 policy. 443 TBD: diet-esp context and rules. 445 3.3.1.2. Compressing UDP/DTLS message headers 447 TBD. No current SCHC guidance for DTLS. 449 3.4. CoAP Net-RID messages 451 TBD 453 4. Command and Control 455 The Command and Control (C2) connection is between the UA and GCS. 456 This is often over a direct link radio. Some times, particularly for 457 BLOS, it is via Internet connections. In either case C2 SHOULD be 458 secure from eavesdropping and tampering. For design and 459 implementation consistency it is best to treat the direct link as a 460 local link Internet connection and use constrained networking 461 compression standards. 463 Both the UA and GCS need to be treated as fully mobile in the IP 464 networking sense. Either one can have its IP address change and both 465 could change at the same time (the double jump problem). It is 466 preferable to use a peer-to-peer (P2P) secure technology like HIPv2 467 [RFC7401]. 469 Finally UA may also tend to have multiple radios for their C2 470 communications. Thus multi-homing with "make before break" behavior 471 is needed. This is on top of any IP address changes on any of the 472 interfaces while in use. 474 4.1. Securing MAVLink 476 MAVLink [MAVLINK] is a commonly used protocol for C2 that uses UDP 477 port 14550 for transport over IP. Message authenticity was added in 478 MAVLink 2 in the form of a SHA-256 (secret | message) left-truncated 479 to 6 byte. This does not follow HMAC [RFC2104] security 480 recommendations, nor provides confidentiality. 482 The MAVlink authentication only provides 24-bit collision resistance 483 but is not susceptible to a hash length attack. By following the 484 security approach here, UAS C2 is superior to that currently provided 485 within MAVlink. It provides 48-bit collision resistance and full 486 confidentiality. 488 4.1.1. Compressed ESP for MAVlink 490 The approach in Section 3.3.1.1 can be used to fully secure MAVlink 491 and include the UDP header for IP transport. Further, MAVlink itself 492 can be compressed. 494 MAVlink messages contain a 1-byte Seq number and 2-byte CRC. Both of 495 these can be generated from SCHC rules. These 3 bytes along with the 496 13-byte MAVlink signature provides the 16 bytes so that the over-the- 497 wire cost is the same. 499 This secure MAVlink format may be sent directly over a local wireless 500 link. The UDP port processing adds little cost. Sending this over 501 IP provides the needed confidentiality at 8 bytes less than 502 unencrypted messages. 504 TBD: MAVlink SCHC context and rules. These will be part of the 505 MAVlink ESP setup. 507 4.2. Compressed UDP/DTLS for MAVlink 509 At this time, DTLS is NOT recommended for C2 security, as it is 510 challenged with server mobility. It may be added at a later time. 512 5. Secure Transports 514 Secure UDP-based protocols are preferred for both Network Remote ID 515 (Net-RID) and C2. Both HIPv2 and DTLS can be used. It will be shown 516 below that HIPv2 is better suited in most cases. 518 For IPv6 and CoAP over both WiFi and Bluetooth (or any other radio 519 link), SCHC [RFC8724] is defined to significantly reduce the per 520 packet transmission cost. SCHC is used both within the secure 521 envelope and before the secure envelope as shown in Section 5.2.10 of 522 [lpwan-architecture]. For Bluetooth, there is also IPv6 over 523 Bluetooth LE [RFC7668] for more guidance. 525 Local link (direct radio) C2 security is possible with the link's MAC 526 layer security. SCHC SHOULD still be used as above. Both WiFi and 527 Bluetooth link security can provide appropriate security, but this 528 would not provide trustworthy multi-homed security. 530 5.1. HIP for Secure Transport 532 HIP has already been used for C2 mobility, managing the ongoing 533 connectivity over WiFi at start of an operation, switching to LTE 534 once out of WiFi range, and returning to WiFi connectivity at the end 535 of the operation. This functionality is especially important for 536 BLOS. HHITs are already defined for RID, and need only be added to 537 the GCS via a GCS Registration as part of the UAS to USS registration 538 to be usedfor C2 HIP. 540 When the UA is the UAS endpoint for Net-RID (Section 3.1.1), and 541 particularly when HIP is used for C2, HIP for Net-RID simplifies 542 protocol use on the UA. The Net-RID SP endpoint may already support 543 HIP if it is also the HHIT Registrar. If the UA lacks any IP ability 544 and the RID HHIT registration was done via the GCS or Operator 545 device, then they may also be set for using HIP for Net-RID. 547 Further, double jump and multi-homing support is mandatory for C2 548 mobility. This is inherent in the HIP design. The HIP address 549 update can be improved with [hip-fast-mobility]. 551 5.2. DTLS for Secure Transport 553 DTLS is a good fit for Net-RID for any of the possible UAS endpoints. 554 There are challenges in using it for C2. To use DTLS for C2, the GCS 555 will need to be the DTLS server. How does it 'push' commands to the 556 UA? How does it reestablish DTLS security if state is lost? And 557 finally, how is the double jump scenario handled? 559 All the above DTLS for C2 probably have solutions. None of them are 560 inherent in the DTLS design. 562 5.3. Ciphers for Secure Transport 564 The cipher choice for either HIP or DTLS depends, in large measure, 565 on the UAS endpoint. If the endpoint is computationally constrained, 566 the cipher computations become important. If any of the links are 567 constrained or expensive, then the over-the-wire cost needs to be 568 minimized. AES-CCM and AES-GCM are the preferred, modern, AEAD 569 ciphers. Section 3.3.1.1 shows that proper compression can provide 570 the more efficient GCM at no over-the-wire cost. Thus AES-GCM is the 571 recommended AES mode-of-operation. 573 NIST is working on selecting a new lightweight cipher that may be the 574 best choice for use on a UA. The Keccak Xoodyak cipher in 575 [new-hip-crypto] is a good "Green Cipher". 577 5.4. HIP and DTLS contrasted and compared 579 This document specifies the use of DTLS 1.3 for its 0-RTT mobility 580 feature and improved (over 1.2) handshake. DTLS 1.3 is still an IETF 581 draft, so there is little data available to properly contrast it with 582 HIPv2. This section will be based on the current DTLS 1.2. The 583 basic client-server model is unchanged. 585 The use of DTLS vs HIPv2 (both over UDP, HIP in IPsec ESP BEET mode) 586 has pros and cons. DTLS is currently at version 1.2 and based on TLS 587 1.2. It is a more common protocol than HIP, with many different 588 implementations available for various platforms and languages. 590 DTLS implements a client-server model, where the client initiates the 591 communication. In HIP, two parties are equal and either can be an 592 Initiator or Responder of the Base Exchange. HIP provides separation 593 between key management (base exchange) and secure transport (for 594 example IPsec ESP BEET) while both parts are tightly coupled in DTLS. 596 DTLS 1.2 still has quite chatty connection establishment taking 3-5 597 RTTs and 15 packets. HIP connection establishment requires 4 packets 598 (I1,R1,I2,R2) over 2 RTTs. This is beneficial for constrained 599 environments of UAs. HIPv2 supports cryptoagility with possibility 600 to negotiate cryptography mechanisms during the Base Exchange. 602 Both DTLS and HIP support mobility with a change of IP address. 603 However, in DTLS only client mobility is well supported, while in HIP 604 either party can be mobile. The double-jump problem (simultaneous 605 mobility) is supported in HIP with a help of Rendezvous Server (RVS) 606 [RFC8004]. HIP can implement secure mobility with IP source address 607 validation in 2 RTTs, and in 1 RTT with fast mobility extension. 609 One study comparing DTLS and IPsec-ESP performance concluded that 610 DTLS is recommended for memory-constrained applications while IPSec- 611 ESP for battery power-constrained [Vignesh]. 613 6. IANA Considerations 615 TBD: May need ESP ciphers defined. 617 7. Security Considerations 619 Designing secure transports is challenging. Where possible, existing 620 technologies SHOULD be used. Both ESP and DTLS have stood "the test 621 of time" against many attack scenarios. Their use here for Net-RID 622 and C2 do not represent new uses, but rather variants on existing 623 depoyments. 625 The same can be said for both key establishment, using HIPv2 and 626 DTLS, and the actual cipher choice for per packet encryption and 627 authentication. Net-RID and C2 do not present new challenges, rather 628 new opportunities to provide communications security using well 629 researched technologies. 631 8. Acknowledgments 633 Stuart Card and Adam Wiethuechter provivded information on their use 634 of HIP for C2 at the Syracuse NY UAS test corridor. This, in large 635 measure, was the impetus to develop this document. 637 9. References 639 9.1. Normative References 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, 643 DOI 10.17487/RFC2119, March 1997, 644 . 646 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 647 Application Protocol (CoAP)", RFC 7252, 648 DOI 10.17487/RFC7252, June 2014, 649 . 651 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 652 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 653 May 2017, . 655 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 656 Representation (CBOR)", STD 94, RFC 8949, 657 DOI 10.17487/RFC8949, December 2020, 658 . 660 9.2. Informative References 662 [dane-clients] 663 Huque, S., Dukhovni, V., and A. Wilson, "TLS Client 664 Authentication via DANE TLSA records", Work in Progress, 665 Internet-Draft, draft-ietf-dance-client-auth-00, 24 March 666 2022, . 669 [diet-esp] Migault, D., Guggemos, T., Bormann, C., and D. Schinazi, 670 "ESP Header Compression and Diet-ESP", Work in Progress, 671 Internet-Draft, draft-mglt-ipsecme-diet-esp-07, 11 March 672 2019, . 675 [drip-registries] 676 Wiethuechter, A., Card, S., Moskowitz, R., and J. Reid, 677 "DRIP Entity Tag Registration & Lookup", Work in Progress, 678 Internet-Draft, draft-ietf-drip-registries-02, 30 April 679 2022, . 682 [drip-uas-rid] 683 Moskowitz, R., Card, S. W., Wiethuechter, A., and A. 684 Gurtov, "DRIP Entity Tag (DET) for Unmanned Aircraft 685 System Remote ID (UAS RID)", Work in Progress, Internet- 686 Draft, draft-ietf-drip-rid-24, 24 April 2022, 687 . 690 [DTLS-1.3-draft] 691 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 692 Datagram Transport Layer Security (DTLS) Protocol Version 693 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 694 dtls13-43, 30 April 2021, 695 . 698 [F3411-19] ASTM International, "Standard Specification for Remote ID 699 and Tracking", February 2020, 700 . 702 [hip-fast-mobility] 703 Moskowitz, R., Card, S. W., and A. Wiethuechter, "Fast HIP 704 Host Mobility", Work in Progress, Internet-Draft, draft- 705 moskowitz-hip-fast-mobility-03, 3 April 2020, 706 . 709 [lpwan-architecture] 710 Pelov, A., Thubert, P., and A. Minaburo, "LPWAN Static 711 Context Header Compression (SCHC) Architecture", Work in 712 Progress, Internet-Draft, draft-ietf-lpwan-architecture- 713 01, 26 November 2021, 714 . 717 [MAVLINK] "Micro Air Vehicle Communication Protocol", 2021, 718 . 720 [new-hip-crypto] 721 Moskowitz, R., Card, S. W., and A. Wiethuechter, "New 722 Cryptographic Algorithms for HIP", Work in Progress, 723 Internet-Draft, draft-moskowitz-hip-new-crypto-10, 2 724 August 2021, . 727 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 728 Hashing for Message Authentication", RFC 2104, 729 DOI 10.17487/RFC2104, February 1997, 730 . 732 [RFC5266] Devarapalli, V. and P. Eronen, "Secure Connectivity and 733 Mobility Using Mobile IPv4 and IKEv2 Mobility and 734 Multihoming (MOBIKE)", BCP 136, RFC 5266, 735 DOI 10.17487/RFC5266, June 2008, 736 . 738 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 739 of Named Entities (DANE) Transport Layer Security (TLS) 740 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 741 2012, . 743 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 744 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 745 Transport Layer Security (TLS) and Datagram Transport 746 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 747 June 2014, . 749 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 750 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 751 RFC 7401, DOI 10.17487/RFC7401, April 2015, 752 . 754 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 755 Encapsulating Security Payload (ESP) Transport Format with 756 the Host Identity Protocol (HIP)", RFC 7402, 757 DOI 10.17487/RFC7402, April 2015, 758 . 760 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 761 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 762 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 763 . 765 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 766 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 767 October 2016, . 769 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 770 Zuniga, "SCHC: Generic Framework for Static Context Header 771 Compression and Fragmentation", RFC 8724, 772 DOI 10.17487/RFC8724, April 2020, 773 . 775 [RFC8750] Migault, D., Guggemos, T., and Y. Nir, "Implicit 776 Initialization Vector (IV) for Counter-Based Ciphers in 777 Encapsulating Security Payload (ESP)", RFC 8750, 778 DOI 10.17487/RFC8750, March 2020, 779 . 781 [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static 782 Context Header Compression (SCHC) for the Constrained 783 Application Protocol (CoAP)", RFC 8824, 784 DOI 10.17487/RFC8824, June 2021, 785 . 787 [RFC9011] Gimenez, O., Ed. and I. Petrov, Ed., "Static Context 788 Header Compression and Fragmentation (SCHC) over LoRaWAN", 789 RFC 9011, DOI 10.17487/RFC9011, April 2021, 790 . 792 [RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A. 793 Gurtov, "Drone Remote Identification Protocol (DRIP) 794 Requirements and Terminology", RFC 9153, 795 DOI 10.17487/RFC9153, February 2022, 796 . 798 [Vignesh] Vignesh, K., "Performance analysis of end-to-end DTLS and 799 IPsec-based communication in IoT environments", Thesis 800 no. MSEE-2017: 42, 2017, . 803 Authors' Addresses 805 Robert Moskowitz 806 HTT Consulting 807 Oak Park, MI 48237 808 United States of America 809 Email: rgm@labs.htt-consult.com 811 Stuart W. Card 812 AX Enterprize 813 4947 Commercial Drive 814 Yorkville, NY 13495 815 United States of America 816 Email: stu.card@axenterprize.com 818 Adam Wiethuechter 819 AX Enterprize 820 4947 Commercial Drive 821 Yorkville, NY 13495 822 United States of America 823 Email: adam.wiethuechter@axenterprize.com 825 Andrei Gurtov 826 Linköping University 827 IDA 828 SE-58183 Linköping 829 Sweden 830 Email: gurtov@acm.org