idnits 2.17.1 draft-moskowitz-drip-secure-nrid-c2-05.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 (21 April 2022) is 735 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) == Unused Reference: 'RFC7252' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'RFC8949' is defined on line 500, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 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: 23 October 2022 A. Wiethuechter 6 AX Enterprize 7 A. Gurtov 8 Linköping University 9 21 April 2022 11 Secure UAS Network RID and C2 Transport 12 draft-moskowitz-drip-secure-nrid-c2-05 14 Abstract 16 This document defines a transport mechanism for Unmanned Aircraft 17 System (UAS) Network Remote ID (N-RID). CoAP/CBOR is used for the 18 N-RID messaging. This is secured via either HIP/ESP or DTLS. HIP/ 19 ESP or DTLS secure messaging Command-and-Control (C2) for is also 20 described. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 23 October 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 58 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Secure Transports . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. HIP for Secure Transport . . . . . . . . . . . . . . . . 4 61 3.2. DTLS for Secure Transport . . . . . . . . . . . . . . . . 5 62 3.3. Ciphers for Secure Transport . . . . . . . . . . . . . . 5 63 3.4. HIP and DTLS contrasted and compared . . . . . . . . . . 5 64 4. Network Remote ID . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. Network RID Endpoints . . . . . . . . . . . . . . . . . . 7 66 4.1.1. N-RID from the UA . . . . . . . . . . . . . . . . . . 7 67 4.1.2. N-RID from the GCS . . . . . . . . . . . . . . . . . 7 68 4.1.3. N-RID from the Operator . . . . . . . . . . . . . . . 7 69 4.2. Network RID Messaging . . . . . . . . . . . . . . . . . . 8 70 4.2.1. Secure Link Setup . . . . . . . . . . . . . . . . . . 8 71 4.2.2. Static Messages . . . . . . . . . . . . . . . . . . . 9 72 4.2.3. Vector/Location Message . . . . . . . . . . . . . . . 9 73 4.3. CoAP N-RID messages . . . . . . . . . . . . . . . . . . . 10 74 5. Command and Control . . . . . . . . . . . . . . . . . . . . . 10 75 5.1. Securing MAVLink . . . . . . . . . . . . . . . . . . . . 10 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 9.2. Informative References . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 This document defines a set of messages for Unmanned Aircraft System 87 (UAS) Network Remote ID (N-RID) derived from the ASTM Remote ID 88 [F3411-19] broadcast messages and common data dictionary. These 89 messages are transported from the UAS to its USS Network Service 90 Provider (Net-RID SP) over CoAP/CBOR ([RFC7252]/[RFC8949]). 92 CoAP/CBOR were selected for their low communication "cost". This may 93 not be an issue if N-RID originates from the Ground Control Station 94 (GCS, Section 4.1.2), but it may be an important determinant when 95 originating from the UA (Section 4.1.1). Particularly, very small 96 messages may open N-RID transmissions over a variety of wireless 97 technologies. 99 To further reduce the communication cost, SCHC [RFC8724] is defined 100 for the CoAP layer ([RFC8824]) and security "compression" (ESP 101 Implicit IV, [RFC8750]) for ESP. SCHC for the IP/UDP layer is 102 currently defined by IP carrier (e.g. LoRaWAN, [RFC9011]) and will 103 be covered in any specific implementation. 105 This document defines mechanisms to provide secure transport for 106 these N-RID messages and Command and Control (C2) messaging. 108 A secure end-to-end transport for C2 is critical for UAS especially 109 for Beyond Line of Sight (BLOS) operations. It needs to provide data 110 Confidentiality, Integrity, and Authenticity (CIA). Depending on the 111 underlying network technology, this secure transport may need to 112 manage IP address changes (IP mobility) for both the UA and GCS. 114 A secure end-to-end transport for N-RID (UAS to Network RID Service 115 Provider (Net-RID SP)) also should provide full CIA. It may seem 116 that confidentiality is optional, as most of the information in N-RID 117 is sent in the clear in Broadcast Remote ID (B-RID), but this is a 118 potentially flawed analysis. N-RID has evesdropping risks not in 119 B-RID and may contain more sensitive information than B-RID. The 120 secure transport for N-RID should only need to manage IP address 121 changes (IP mobility) for the UAS. 123 Two options for secure transport are provided: HIPv2 [RFC7401] and 124 DTLS 1.3 [DTLS-1.3-draft]. These options are generally defined and 125 their applicability is compared and contrasted. It is up to N-RID 126 and C2 to select which is preferred for their situation. 128 2. Terms and Definitions 130 2.1. Requirements Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in BCP 135 14 [RFC2119] [RFC8174] when, and only when, they appear in all 136 capitals, as shown here. 138 2.2. Definitions 140 See Section 2.2 of [RFC9153] for common DRIP terms. The following 141 new terms are used in the document: 143 B-RID 144 Broadcast Remote ID. A method of sending RID messages as 1-way 145 transmissions from the UA to any Observers within radio range. 147 N-RID 148 Network Remote ID. A method of sending RID messages via the 149 Internet connection of the UAS directly to the UTM. 151 RID 152 Remote ID. A unique identifier found on all UA to be used in 153 communication and in regulation of UA operation. 155 3. Secure Transports 157 Secure UDP-based protocols are preferred for both Network Remote ID 158 (N-RID) and C2. Both HIPv2 and DTLS can be used. It will be shown 159 below that HIPv2 is better suited in most cases. 161 For IPv6 and CoAP over both WiFi and Bluetooth (or any other radio 162 link), SCHC [RFC8724] is defined to significantly reduce the per 163 packet transmission cost. SCHC is used both within the secure 164 envelope and before the secure envelope as shown in Section 5.2.10 of 165 [lpwan-architecture]. For Bluetooth, there is also IPv6 over 166 Bluetooth LE [RFC7668] for more guidance. 168 Local link (direct radio) C2 security is possible with the link's MAC 169 layer security. SCHC SHOULD still be used as above. Both WiFi and 170 Bluetooth link security can provide appropriate security, but this 171 would not provide trustworthy multi-homed security. 173 3.1. HIP for Secure Transport 175 HIP has already been used for C2 mobility, managing the ongoing 176 connectivity over WiFi at start of an operation, switching to LTE 177 once out of WiFi range, and returning to WiFi connectivity at the end 178 of the operation. This functionality is especially important for 179 BLOS. HHITs are already defined for RID, and need only be added to 180 the GCS via a GCS Registration as part of the UAS to USS registration 181 to be usedfor C2 HIP. 183 When the UA is the UAS endpoint for N-RID (Section 4.1.1), and 184 particularly when HIP is used for C2, HIP for N-RID simplifies 185 protocol use on the UA. The Net-RID SP endpoint may already support 186 HIP if it is also the HHIT Registrar. If the UA lacks any IP ability 187 and the RID HHIT registration was done via the GCS or Operator 188 device, then they may also be set for using HIP for N-RID. 190 Further, double jump and multi-homing support is mandatory for C2 191 mobility. This is inherent in the HIP design. The HIP address 192 update can be improved with [hip-fast-mobility]. 194 3.2. DTLS for Secure Transport 196 DTLS is a good fit for N-RID for any of the possible UAS endpoints. 197 There are challenges in using it for C2. To use DTLS for C2, the GCS 198 will need to be the DTLS server. How does it 'push' commands to the 199 UA? How does it reestablish DTLS security if state is lost? And 200 finally, how is the double jump scenario handled? 202 All the above DTLS for C2 probably have solutions. None of them are 203 inherent in the DTLS design. 205 3.3. Ciphers for Secure Transport 207 The cipher choice for either HIP or DTLS depends, in large measure, 208 on the UAS endpoint. If the endpoint is computationally constrained, 209 the cipher computations become important. If any of the links are 210 constrained or expensive, then the over-the-wire cost needs to be 211 minimized. AES-CCM and AES-GCM are the preferred, modern, AEAD 212 ciphers. 214 For ESP with HIP [RFC7402], an additional 4 - 8 bytes can be trimmed 215 by using the Implicit IV for ESP option [RFC8750]. 217 NIST is working on selecting a new lightweight cipher that may be the 218 best choice for use on a UA. The Keccak Xoodyak cipher in 219 [new-hip-crypto] is a good "Green Cipher". 221 3.4. HIP and DTLS contrasted and compared 223 This document specifies the use of DTLS 1.3 for its 0-RTT mobility 224 feature and improved (over 1.2) handshake. DTLS 1.3 is still an IETF 225 draft, so there is little data available to properly contrast it with 226 HIPv2. This section will be based on the current DTLS 1.2. The 227 basic client-server model is unchanged. 229 The use of DTLS vs HIPv2 (both over UDP, HIP in IPsec ESP BEET mode) 230 has pros and cons. DTLS is currently at version 1.2 and based on TLS 231 1.2. It is a more common protocol than HIP, with many different 232 implementations available for various platforms and languages. 234 DTLS implements a client-server model, where the client initiates the 235 communication. In HIP, two parties are equal and either can be an 236 Initiator or Responder of the Base Exchange. HIP provides separation 237 between key management (base exchange) and secure transport (for 238 example IPsec ESP BEET) while both parts are tightly coupled in DTLS. 240 DTLS 1.2 still has quite chatty connection establishment taking 3-5 241 RTTs and 15 packets. HIP connection establishment requires 4 packets 242 (I1,R1,I2,R2) over 2 RTTs. This is beneficial for constrained 243 environments of UAs. HIPv2 supports cryptoagility with possibility 244 to negotiate cryptography mechanisms during the Base Exchange. 246 Both DTLS and HIP support mobility with a change of IP address. 247 However, in DTLS only client mobility is well supported, while in HIP 248 either party can be mobile. The double-jump problem (simultaneous 249 mobility) is supported in HIP with a help of Rendezvous Server (RVS) 250 [RFC8004]. HIP can implement secure mobility with IP source address 251 validation in 2 RTTs, and in 1 RTT with fast mobility extension. 253 One study comparing DTLS and IPsec-ESP performance concluded that 254 DTLS is recommended for memory-constrained applications while IPSec- 255 ESP for battery power-constrained [Vignesh]. 257 4. Network Remote ID 259 In UAS Traffic Management (UTM), the purpose of N-RID is to provide 260 situational awareness of UA (in the form of flight tracking) in a 261 user specified 3D volume. The data needed for this is already 262 defined in [F3411-19], but a standard message format, protocol, and 263 secure communications methodology are missing. F3411, and other UTM 264 based standards going through ASTM, provide JSON objects and some of 265 the messages for passing information between various UTM entities 266 (e.g., Net-RID SP to Net-RID SP and Net-RID SP to Net-RID DP) but 267 does not specify how the data gets into UTM to begin with. This 268 document will provide such an open standard. 270 The Broadcast Remote ID (B-RID) messages in [F3411-19] are sufficient 271 to meet the needs of N-RID. These messages can be sent to the Net- 272 RID SP when their contents change. Further, a UAS supporting B-RID 273 will have minimal development to add N-RID support. 275 This approach has the added advantage of being very compact, 276 minimizing the N-RID communications cost. 278 4.1. Network RID Endpoints 280 The FAA defines the Network Remote ID endpoints as a USS Network 281 Service Provider (Net-RID SP) and the UAS. Both of these are rather 282 nebulous items and what they actually are will impact how 283 communications flow between them. 285 The Net-RID SP may be provided by the same entity serving as the UAS 286 Service Provider (USS). This simplifies a number of aspects of the 287 N-RID communication flow. An Operator is expected to register an 288 operation with the USS. If this is done via the GCS and the GCS is 289 the source (directly acting as a gateway), this could set up the 290 secure connection for N-RID. The Net-RID SP is likely to be stable 291 in the network, that is its IP address will not change during a 292 mission. This simplifies maintaining the N-RID communications. 294 The UAS component in N-RID may be either the UA, GCS, or the 295 Operator's Internet connected device (e.g. smartphone or tablet). In 296 all cases, mobility MUST be assumed. That is the IP address of this 297 end of the N-RID communication will change during an operation. The 298 N-RID mechanism MUST support this. The UAS Identity for the secure 299 connection may vary based on the UAS endpoint. 301 4.1.1. N-RID from the UA 303 Some UA will be equipped with direct Internet access. These UA will 304 also tend to have multiple radios for their Internet access (e.g. 305 Cellular and WiFi). Thus multi-homing with "make before break" 306 behavior is needed. This is on top of any IP address changes on any 307 of the interfaces while in use. 309 4.1.2. N-RID from the GCS 311 Many UA will lack direct Internet access, but their GCS are 312 connected. There are two sources for the GCS for the RID messages, 313 both from the UA. These are UA B-RID messages, or content from C2 314 messages that the GCS converts to RID message format. In either 315 case, the GCS may be mobile with changing IP addresses. The GCS may 316 be in a fast moving ground device (e.g. delivery van), so it can have 317 as mobility demanding connection needs as the UA. 319 4.1.3. N-RID from the Operator 321 Many UAS will have no Internet connectivity, but the UA is sending 322 B-RID messages and the Operator, when within RF range, can receive 323 these B-RID messages on an Internet Connected device that can act as 324 the proxy for these messages, turning them into N-RID messages. 326 4.2. Network RID Messaging 328 N-RID messaging is tied to a UA operation (generally called a flight 329 or mission). This consists of an initial secure link setup, followed 330 by a set of mostly static information related to the operation. 331 During the operation, continuous location information is sent by the 332 UA with any needed updates to the mostly static operation 333 information. 335 The Net-RID SP SHOULD send regular "heartbeats" to the UAS. If the 336 UAS does not receive these heartbeats for some policy set time, the 337 UA MUST take the policy set response to loss of Net-RID SP 338 connectivity. For example, this could be a mandated immediate 339 landing. There may be other messages from the Net-RID SP to the UAS 340 (e.g., call the USS operator at this number NOW!). The UAS MUST 341 acknowledge these messages. 343 If the Net-RID SP stops receiving messages from the UAS 344 (Section 4.2.3), it should notify the UTM of a non-communicating UA 345 while still in operation. 347 4.2.1. Secure Link Setup 349 The secure link setup MUST be done before the operation begins, thus 350 it can use a high capacity connection like WiFi. It MAY use the UA 351 RID for this setup, including other data elements provided in the 352 B-RID Basic ID (Msg Type 0x0) Message. If the Basic ID information 353 is NOT included via the secure setup (including the Net-RID SP 354 querying the USS for this information), it MUST be sent as part of 355 the Static Messages (Section 4.2.2) 357 4.2.1.1. UAS Identity 359 The UAS MAY use its RID if it is a HHIT [drip-uas-rid]. It may use 360 some other Identity, based on the Net-RID SP policy. 362 The GCS or Operator smart device may have a copy of the UA 363 credentials and use them in the connection to the Net-RID SP. In 364 this case, they are indistinguishable from the UA as seen from the 365 Net-RID SP. Alternatively, they may use their own credentials with 366 the Net-RID SP which would need some internal mechanism to tie that 367 to the UA. 369 4.2.2. Static Messages 371 For simplicity, a class of UAS information is called here "Static", 372 though in practice any of it can change during the operation, but 373 will change infrequently. This information is the contents of the 374 B-RID Self-ID (Msg Type 0x3), Operator ID (Msg Type 0x5), and System 375 Messages (Msg Type 0x4). This information can simply be sent in the 376 same format as the B-RID messages. Alternatively the individual data 377 elements may be send as separate CBOR objects. 379 The Basic ID (Msg Type 0x0) Message may be included as a static 380 message if this information was not used for the secure setup. There 381 may be more than one Basic ID Message needed if as in the case where 382 the Japan Civil Aviation Bureau (JCAB) has mandated that the CAA 383 assigned ID (UA ID type 2) and Serial Number (UA ID type 1) be 384 broadcasted. 386 The information in the System Message is most likely to change during 387 an operation. Noteably the Operator Location data elements are 388 subject to change if the GCS is physically moving (e.g. hand-held 389 and the operator is walking or driving in a car). The whole System 390 Message may be sent, or only the changing data elements as CBOR 391 objects. 393 These static message elements may be sent before the operation 394 begins, thus their transmission can use a high capacity connection 395 like WiFi. Once the operation is underway, any updates will have to 396 traverse the operational link which may be very constrained and this 397 will impact data element formatting. 399 The Net-RID SP MUST acknowledge these messages. The UAS MUST receive 400 these ACKs. If no ACK is received, the UAS MUST resent the 401 message(s). This send/ACK sequence continues either until ACK is 402 received, or some policy number of tries. If this fails, the UAS 403 MUST act that the Net-RID SP connection is lost and MUST take the 404 policy set response to loss of Net-RID SP connectivity. If the 405 information changes during this cycle, the latest information MUST 406 always be sent. 408 4.2.3. Vector/Location Message 410 Many CAAs mandate that the UA Vector/Location information be updated 411 at least once per second. Without careful message design, this 412 messaging volume would overwhelm many wireless technologies. Thus to 413 enable the widest deployment choices, a highly compressed format is 414 recommended. 416 The B-RID Vector/Location Message (Msg Type 0x1) is the simplest 417 small object (24 bytes) for sending this information as a single CBOR 418 object. It may be possible to send only those data elements that 419 changed in the last time interval. This may result in smaller 420 individual transmissions, but should not be used if the resulting 421 message is larger than the Vector/Location Message. 423 4.3. CoAP N-RID messages 425 TBD 427 5. Command and Control 429 The Command and Control (C2) connection is between the UA and GCS. 430 This is often this over a direct link radio. Some times, 431 particularly for BLOS, it is via Internet connections. In either 432 case C2 SHOULD be secure from eavesdropping and tampering. For 433 design and implementation consistency it is best to treat the direct 434 link as a local link Internet connection and use constrained 435 networking compression standards. 437 Both the UA and GCS need to be treated as fully mobile in the IP 438 networking sense. Either one can have its IP address change and both 439 could change at the same time (the double jump problem). It is 440 preferable to use a peer-to-peer (P2P) secure technology like HIPv2 441 [RFC7401]. 443 Finally UA may also tend to have multiple radios for their C2 444 communications. Thus multi-homing with "make before break" behavior 445 is needed. This is on top of any IP address changes on any of the 446 interfaces while in use. 448 5.1. Securing MAVLink 450 MAVLink [MAVLINK] is a commonly used protocol for C2. Message 451 authenticity was added in MAVLink 2 in the form of a SHA-256 (secret 452 + message hash) left-truncated to 6 byte. This does not follow HMAC 453 [RFC2104] security recommendations, nor provides confidentiality. 455 By following the security approach here, UAS C2 is superior to that 456 currently provided within MAVlink. 458 6. IANA Considerations 460 TBD 462 7. Security Considerations 464 Designing secure transports is challenging. Where possible, existing 465 technologies SHOULD be used. Both ESP and DTLS have stood "the test 466 of time" against many attack scenarios. Their use here for N-RID and 467 C2 do not represent new uses, but rather variants on existing 468 depoyments. 470 The same can be said for both key establishment, using HIPv2 and 471 DTLS, and the actual cipher choice for per packet encryption and 472 authentication. N-RID and C2 do not present new challenges, rather 473 new opportunities to provide communications security using well 474 researched technologies. 476 8. Acknowledgments 478 Stuart Card and Adam Wiethuechter provivded information on their use 479 of HIP for C2 at the Syracuse NY UAS test corridor. This, in large 480 measure, was the impetus to develop this document. 482 9. References 484 9.1. Normative References 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, 488 DOI 10.17487/RFC2119, March 1997, 489 . 491 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 492 Application Protocol (CoAP)", RFC 7252, 493 DOI 10.17487/RFC7252, June 2014, 494 . 496 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 497 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 498 May 2017, . 500 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 501 Representation (CBOR)", STD 94, RFC 8949, 502 DOI 10.17487/RFC8949, December 2020, 503 . 505 9.2. Informative References 507 [drip-uas-rid] 508 Moskowitz, R., Card, S. W., Wiethuechter, A., and A. 509 Gurtov, "DRIP Entity Tag (DET) for Unmanned Aircraft 510 System Remote ID (UAS RID)", Work in Progress, Internet- 511 Draft, draft-ietf-drip-rid-22, 13 April 2022, 512 . 515 [DTLS-1.3-draft] 516 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 517 Datagram Transport Layer Security (DTLS) Protocol Version 518 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 519 dtls13-43, 30 April 2021, 520 . 523 [F3411-19] ASTM International, "Standard Specification for Remote ID 524 and Tracking", February 2020, 525 . 527 [hip-fast-mobility] 528 Moskowitz, R., Card, S. W., and A. Wiethuechter, "Fast HIP 529 Host Mobility", Work in Progress, Internet-Draft, draft- 530 moskowitz-hip-fast-mobility-03, 3 April 2020, 531 . 534 [lpwan-architecture] 535 Pelov, A., Thubert, P., and A. Minaburo, "LPWAN Static 536 Context Header Compression (SCHC) Architecture", Work in 537 Progress, Internet-Draft, draft-ietf-lpwan-architecture- 538 01, 26 November 2021, 539 . 542 [MAVLINK] "Micro Air Vehicle Communication Protocol", 2021, 543 . 545 [new-hip-crypto] 546 Moskowitz, R., Card, S. W., and A. Wiethuechter, "New 547 Cryptographic Algorithms for HIP", Work in Progress, 548 Internet-Draft, draft-moskowitz-hip-new-crypto-10, 2 549 August 2021, . 552 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 553 Hashing for Message Authentication", RFC 2104, 554 DOI 10.17487/RFC2104, February 1997, 555 . 557 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 558 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 559 RFC 7401, DOI 10.17487/RFC7401, April 2015, 560 . 562 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 563 Encapsulating Security Payload (ESP) Transport Format with 564 the Host Identity Protocol (HIP)", RFC 7402, 565 DOI 10.17487/RFC7402, April 2015, 566 . 568 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 569 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 570 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 571 . 573 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 574 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 575 October 2016, . 577 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 578 Zuniga, "SCHC: Generic Framework for Static Context Header 579 Compression and Fragmentation", RFC 8724, 580 DOI 10.17487/RFC8724, April 2020, 581 . 583 [RFC8750] Migault, D., Guggemos, T., and Y. Nir, "Implicit 584 Initialization Vector (IV) for Counter-Based Ciphers in 585 Encapsulating Security Payload (ESP)", RFC 8750, 586 DOI 10.17487/RFC8750, March 2020, 587 . 589 [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static 590 Context Header Compression (SCHC) for the Constrained 591 Application Protocol (CoAP)", RFC 8824, 592 DOI 10.17487/RFC8824, June 2021, 593 . 595 [RFC9011] Gimenez, O., Ed. and I. Petrov, Ed., "Static Context 596 Header Compression and Fragmentation (SCHC) over LoRaWAN", 597 RFC 9011, DOI 10.17487/RFC9011, April 2021, 598 . 600 [RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A. 601 Gurtov, "Drone Remote Identification Protocol (DRIP) 602 Requirements and Terminology", RFC 9153, 603 DOI 10.17487/RFC9153, February 2022, 604 . 606 [Vignesh] Vignesh, K., "Performance analysis of end-to-end DTLS and 607 IPsec-based communication in IoT environments", Thesis 608 no. MSEE-2017: 42, 2017, . 611 Authors' Addresses 613 Robert Moskowitz 614 HTT Consulting 615 Oak Park, MI 48237 616 United States of America 617 Email: rgm@labs.htt-consult.com 619 Stuart W. Card 620 AX Enterprize 621 4947 Commercial Drive 622 Yorkville, NY 13495 623 United States of America 624 Email: stu.card@axenterprize.com 626 Adam Wiethuechter 627 AX Enterprize 628 4947 Commercial Drive 629 Yorkville, NY 13495 630 United States of America 631 Email: adam.wiethuechter@axenterprize.com 633 Andrei Gurtov 634 Linköping University 635 IDA 636 SE-58183 Linköping 637 Sweden 638 Email: gurtov@acm.org