idnits 2.17.1 draft-sipos-dtn-udpcl-00.txt: -(1136): 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 2 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 (7 February 2021) is 1168 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: 'RFC3986' is defined on line 1009, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-BUNDLE' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-PORTS' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-IPv4-MCAST' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-IPv6-MCAST' ** Downref: Normative reference to an Experimental RFC: RFC 5050 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-28) exists of draft-ietf-dtn-tcpclv4-24 == Outdated reference: A later version (-27) exists of draft-ietf-dtn-bpsec-26 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay-Tolerant Networking B. Sipos 3 Internet-Draft RKF Engineering 4 Intended status: Standards Track 7 February 2021 5 Expires: 11 August 2021 7 Delay-Tolerant Networking UDP Convergence Layer Protocol 8 draft-sipos-dtn-udpcl-00 10 Abstract 12 This document describes a UDP-based convergence layer (UDPCL) for 13 Delay-Tolerant Networking (DTN). This version of the UDPCL protocol 14 clarifies requirements of RFC7122, adds discussion of multicast 15 addressing, and updates to the Bundle Protocol (BP) contents, 16 encodings, and convergence layer requirements in BP Version 7. 17 Specifically, the UDPCL uses CBOR-encoded BPv7 bundles as its service 18 data unit being transported and provides a reliable transport of such 19 bundles. This version of UDPCL also includes security and 20 extensibility mechanisms. 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 11 August 2021. 39 Copyright Notice 41 Copyright (c) 2021 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 Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 58 1.3. Definitions Specific to the UDPCL Protocol . . . . . . . 5 59 2. General Protocol Description . . . . . . . . . . . . . . . . 6 60 2.1. Convergence Layer Services . . . . . . . . . . . . . . . 7 61 2.2. PKIX Environments and CA Policy . . . . . . . . . . . . . 8 62 2.3. Fragmentation Policies . . . . . . . . . . . . . . . . . 8 63 2.4. Error Checking Policies . . . . . . . . . . . . . . . . . 9 64 2.5. Congestion Control Policies . . . . . . . . . . . . . . . 9 65 3. UDPCL Operation . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.1. Destination Address . . . . . . . . . . . . . . . . . . . 9 67 3.2. UDP Header . . . . . . . . . . . . . . . . . . . . . . . 10 68 3.3. UDPCL Messaging . . . . . . . . . . . . . . . . . . . . . 10 69 3.4. UDPCL Extension Items . . . . . . . . . . . . . . . . . . 12 70 3.4.1. DTLS Initiation (STARTTLS) . . . . . . . . . . . . . 12 71 3.4.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . 13 72 3.5. UDPCL Security . . . . . . . . . . . . . . . . . . . . . 15 73 3.5.1. DTLS Handshake . . . . . . . . . . . . . . . . . . . 15 74 3.5.2. DTLS Authentication . . . . . . . . . . . . . . . . . 15 75 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 5.1. Threat: Passive Leak of Node Data . . . . . . . . . . . . 16 78 5.2. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 17 79 5.3. Threat: Transport Security Stripping . . . . . . . . . . 17 80 5.4. Threat: Weak DTLS Configurations . . . . . . . . . . . . 17 81 5.5. Threat: Untrusted End-Entity Certificate . . . . . . . . 18 82 5.6. Threat: Certificate Validation Vulnerabilities . . . . . 18 83 5.7. Threat: BP Node Impersonation . . . . . . . . . . . . . . 18 84 5.8. Threat: Denial of Service . . . . . . . . . . . . . . . . 18 85 5.9. Mandatory-to-Implement DTLS . . . . . . . . . . . . . . . 19 86 5.10. Alternate Uses of DTLS . . . . . . . . . . . . . . . . . 19 87 5.10.1. DTLS Without Authentication . . . . . . . . . . . . 19 88 5.10.2. Non-Certificate DTLS Use . . . . . . . . . . . . . . 20 89 5.11. Predictability of Transfer IDs . . . . . . . . . . . . . 20 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 91 6.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 20 92 6.2. UDPCL Extension Types . . . . . . . . . . . . . . . . . . 21 93 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 95 8.1. Normative References . . . . . . . . . . . . . . . . . . 22 96 8.2. Informative References . . . . . . . . . . . . . . . . . 24 98 Appendix A. Significant changes from RFC7122 . . . . . . . . . . 26 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 101 1. Introduction 103 This document describes the UDP-based convergence-layer protocol for 104 Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to- 105 end architecture providing communications in and/or through highly 106 stressed environments, including those with intermittent 107 connectivity, long and/or variable delays, and high bit error rates. 108 More detailed descriptions of the rationale and capabilities of these 109 networks can be found in "Delay-Tolerant Network Architecture" 110 [RFC4838]. 112 An important goal of the DTN architecture is to accommodate a wide 113 range of networking technologies and environments. The protocol used 114 for DTN communications is the Bundle Protocol Version 7 (BPv7) 115 [I-D.ietf-dtn-bpbis], an application-layer protocol that is used to 116 construct a store-and-forward overlay network. BPv7 requires the 117 services of a "convergence-layer adapter" (CLA) to send and receive 118 bundles using the service of some "native" link, network, or Internet 119 protocol. This document describes one such convergence-layer adapter 120 that uses the well-known User Datagram Protocol (UDP). This 121 convergence layer is referred to as UDP Convergence Layer (UDPCL). 122 For the remainder of this document, the abbreviation "BP" without the 123 version suffix refers to BPv7. 125 The locations of the UDPCL and the BP in the Internet model protocol 126 stack (described in [RFC1122]) are shown in Figure 1. In particular, 127 when BP is using UDP as its bearer with UDPCL as its convergence 128 layer, both BP and UDPCL reside at the application layer of the 129 Internet model. 131 +-------------------------+ 132 | DTN Application | -\ 133 +-------------------------| | 134 | Bundle Protocol (BP) | -> Application Layer 135 +-------------------------+ | 136 | UDP Conv. Layer (UDPCL) | | 137 +-------------------------+ | 138 | DTLS (optional) | -/ 139 +-------------------------+ 140 | UDP | ---> Transport Layer 141 +-------------------------+ 142 | IPv4/IPv6 | ---> Network Layer 143 +-------------------------+ 144 | Link-Layer Protocol | ---> Link Layer 145 +-------------------------+ 147 Figure 1: The Locations of the Bundle Protocol and the UDP 148 Convergence-Layer Protocol above the Internet Protocol Stack 150 1.1. Scope 152 This document describes the format of the protocol data units passed 153 between entities participating in UDPCL communications. This 154 document does not address: 156 * The format of protocol data units of the Bundle Protocol, as those 157 are defined elsewhere in [I-D.ietf-dtn-bpbis]. This includes the 158 concept of bundle fragmentation or bundle encapsulation. The 159 UDPCL transfers bundles as opaque data blocks. 161 * Mechanisms for locating or identifying other bundle entities 162 (peers) within a network or across an internet. The mapping of 163 Node ID to potential convergence layer (CL) protocol and network 164 address is left to implementation and configuration of the BP 165 Agent and its various potential routing strategies. 167 * Logic for routing bundles along a path toward a bundle's endpoint. 168 This CL protocol is involved only in transporting bundles between 169 adjacent entities in a routing sequence. 171 * Logic for performing rate control and congestion control of bundle 172 transfers, both incoming and outgoing from a UDPCL entity. 174 * Policies or mechanisms for issuing Public Key Infrastructure Using 175 X.509 (PKIX) certificates; provisioning, deploying, or accessing 176 certificates and private keys; deploying or accessing certificate 177 revocation lists (CRLs); or configuring security parameters on an 178 individual entity or across a network. 180 * Uses of Datagram Transport Layer Security (DTLS) which are not 181 based on PKIX certificate authentication (see Section 5.10.2) or 182 in which authentication of both entities is not possible (see 183 Section 5.10.1). 185 Any UDPCL implementation requires a BP agent to perform those above 186 listed functions in order to perform end-to-end bundle delivery. 188 1.2. Requirements Language 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 192 "OPTIONAL" in this document are to be interpreted as described in BCP 193 14 [RFC2119] [RFC8174] when, and only when, they appear in all 194 capitals, as shown here. 196 1.3. Definitions Specific to the UDPCL Protocol 198 This section contains definitions specific to the UDPCL protocol. 200 UDPCL Entity: This is the notional UDPCL application that initiates 201 UDPCL transfers. This design, implementation, configuration, and 202 specific behavior of such an entity is outside of the scope of 203 this document. However, the concept of an entity has utility 204 within the scope of this document as the container and initiator 205 of transfers. The relationship between a UDPCL entity and UDPCL 206 sessions is defined as follows: 208 * A UDPCL Entity MAY actively perform any number of transfers and 209 should do so whenever the entity has a bundle to forward to 210 another entity in the network. 212 * A UDPCL Entity MAY support zero or more passive listening 213 elements that listen for transfers from other entities in the 214 network, including non-unicast transfers. 216 These relationships are illustrated in Figure 2. For the 217 remainder of this document, the term "entity" without the prefix 218 "UDPCL" refers to a UDPCL entity. 220 UDP Conversation: This refers to datagrams exchanged between two 221 network peers, with each peer identified by a (unicast IP address, 222 UDP port) tuple. Because UDP is connectionless, there is no 223 notion of a conversation being "opened" or "closed". 225 Transfer: This refers to the procedures and mechanisms for 226 conveyance of an individual bundle from one entity to one or more 227 destinations. This version of UDPCL includes a fragmentation 228 mechanism to allow transfers which are larger than the allowable 229 UDP datagram size. 231 Transmit: This refers to a transfer outgoing from an entity as seen 232 from that transmitting entity. 234 Receive: This refers to a transfer incoming to an entity as seen 235 from that receiving entity. 237 +----------------------------------------+ 238 | UDPCL Entity | 239 | | +----------------+ 240 | +--------------------------------+ | | |-+ 241 | | Actively Initiated Transfer #1 +--------->| Other | | 242 | +--------------------------------+ | | UDPCL Entity's | | 243 | ... | | Passive | | 244 | +--------------------------------+ | | Listener | | 245 | | Actively Initiated Transfer #n +--------->| | | 246 | +--------------------------------+ | +----------------+ | 247 | | +-----------------+ 248 | +---------------------------+ | 249 | | +---------------------------+ | +----------------+ 250 | | | Optional Passive | | | |-+ 251 | +-| Listener(s) +<---------+ Other | | 252 | +---------------------------+ | | UDPCL Entity's | | 253 | ^ | | Active | | 254 | | | | Initiator(s) | | 255 | +-------------| | | 256 +----------------------------------------+ +----------------+ | 257 +-----------------+ 259 Figure 2: The relationships between UDPCL entities 261 2. General Protocol Description 263 The service of this protocol is the transmission of DTN bundles via 264 the User Datagram Protocol (UDP). This document specifies the 265 optional fragmentation of bundles, procedures for DTLS setup and 266 teardown, and a set of messages and entity requirements. The general 267 operation of the protocol is as follows. 269 Fundamentally, the UDPCL is a (logically) unidirectional "transmit 270 and forget" protocol which itself maintains no long-term state and 271 provides no feedback to the transmitter. The only long-term state 272 related to UDPCL is used by DTLS in its session keeping (which is 273 bound to a UDP conversation). An entity receiving a bundle from a 274 particular source address-and-port does not imply that the 275 transmitter is willing to accept bundle transfers on that same 276 address-and-port. It is the obligation of a BP agent and its routing 277 schemes to determine a bundle return path. 279 2.1. Convergence Layer Services 281 This version of the UDPCL provides the following services to support 282 the over-laying Bundle Protocol agent. In all cases, this is not an 283 API definition but a logical description of how the CL can interact 284 with the BP agent. Each of these interactions can be associated with 285 any number of additional metadata items as necessary to support the 286 operation of the CL or BP agent. 288 Begin Transmission: The principal purpose of the UDPCL is to allow a 289 BP agent to transmit bundle data to one or more other entities. 290 The receiver of each transfer is identified by an (destination) 291 IPv4 or IPv6 address and a UDP port number (see Section 3 for 292 details). The CL does not necessarily perform any transmission 293 queueing, but may block while transmissions are being processed at 294 the UDP layer. Any queueing of transmissions is the obligation of 295 the BP agent. 297 Transmission Started: The UDPCL entity indicates to the BP agent 298 when a bundle transmission begins sending UDP datagrams. Once 299 started, there is no notion of a UDPCL transmission failure; a BP 300 agent has to rely on bundle-level status reporting to track bundle 301 progress through the network. Because of potential queueing or 302 DTLS setup time, this may be delayed from the BP agent providing 303 the bundle-to-transmit. 305 Transmission Finished: The UDPCL entity indicates to the BP agent 306 when a bundle has been fully transmitted. This is not a positive 307 indication that any next-hop receiver has either received or 308 processed the transfer. 310 Reception Started: The UDPCL entity indicates to the BP agent when a 311 bundle transfer has begun, which may include information about the 312 total size of a fragmented transfer. 314 Reception Success: The UDPCL entity indicates to the BP agent when a 315 bundle has been fully transferred from a peer entity. The 316 transmitter of each transfer is identified by an (source) IP 317 address and a UDP port number (see Section 3 for details). 319 Reception Failure: The UDPCL entity indicates to the BP agent on 320 certain reasons for reception failure, notably upon an unfinished 321 transfer timeout (see Section 3.4.2). 323 Attempt DTLS Session: The UDPCL allows a BP agent to preemptively 324 attempt to establish a DTLS session with a peer entity (see 325 Section 3.5). Each session attempt can send a different set of 326 session negotiation parameters as directed by the BP agent. 328 Close DTLS Session: The UDPCL allows a BP agent to preemptively 329 close an established DTLS session with a peer entity. The closure 330 request is on a per-session basis. 332 DTLS Session State Changed: The UDPCL entity indicates to the BP 333 agent when a DTLS session state changes. The possible DTLS 334 session states are defined in [RFC6347]. 336 2.2. PKIX Environments and CA Policy 338 This specification gives requirements about how to use PKIX 339 certificates issued by a Certificate Authority (CA), but does not 340 define any mechanisms for how those certificates come to be. The 341 UDPCL uses the exact same mechanisms and makes the same assumptions 342 as TCPCL in Section 3.4 of [I-D.ietf-dtn-tcpclv4]. 344 2.3. Fragmentation Policies 346 It is a implementation matter for a sending entity to determine the 347 path maximum transmit unit (MTU) to be used as a target upper-bound 348 UDP datagram size. Some mechanisms to perform MTU discovery are 349 defined in [RFC8899]. All IP packets sent by a UDPCL entity SHOULD 350 have the "don't fragment" bit set to allow detection of path MTU 351 issues. 353 The priority order of fragmentation is the following: 355 1. When possible, bundles too large to fit in one path-MTU-sized 356 packet SHOULD be fragmented at the BP layer. Bundle payload 357 fragmentation does not help a large bundle if extension blocks 358 are a major contributor to bundle size, so in some circumstances 359 BP layer fragmentation will not reduce the bundle size 360 sufficiently. It is outside the scope of UDPCL to manage BP 361 agent fragmentation policies; bundles are received from the BP 362 agent either already fragmented or not. 364 2. Bundles too large to fit in one path-MTU-sized packet SHALL be 365 fragmented as a UDPCL transfer (see Section 3.4.2). 366 Fragmentation at this level treats bundle transfers as opaque 367 data, so it is independent of bundle block sizes or counts. 369 3. All IP packets larger than expected path MTU SHALL be fragmented 370 by the transmitting entity to fit within one path MTU. Because 371 of the issues listed in Section 3.2 of [RFC8085], it is best to 372 avoid IP fragmentation as much as possible. 374 A UDPCL entity SHOULD NOT proactively drop an outgoing transfer due 375 to datagram size. If intermediate network nodes drop IP packets it 376 is an implementation matter to receive network feedback. 378 2.4. Error Checking Policies 380 The core Bundle Protocol specification assumes that bundles are 381 transferring over an erasure channel, i.e., a channel that either 382 delivers packets correctly or not at all. 384 A UDP transmitter SHALL NOT disable UDP checksums. A UDP receiver 385 SHALL NOT disable the checking of received UDP checksums. 387 Even when UDP checksums are enabled, a small probability of UDP 388 packet corruption remains. In some environments, it may be 389 acceptable for a BP agent to occasionally receive corrupted input. 390 In general, however, a UDPCL entity SHOULD insure the a bundle's 391 blocks are either covered by a CRC or a BPSec integrity check. 393 2.5. Congestion Control Policies 395 The applications using UDPCL for bundle transport SHALL conform to 396 the congestion control requirements of Section 3.1 of [RFC8085]. The 397 application SHALL either perform active congestion control of bundles 398 or behave as the Low Data-Volume application as defined in 399 Section 3.1.3 of [RFC8085]. 401 When nodes have bidirectional transfer capability, the bundle 402 deletion reason code "traffic pared" can be used by a receiving agent 403 to signal to the bundle source application that throttling of bundles 404 along that path SHOULD occur. 406 3. UDPCL Operation 408 This section defines the UDPCL protocol and its interactions with 409 under-layers (IP and UDP) and over-layers (BP). The section is 410 organized from the network layer up toward the BP layer. 412 3.1. Destination Address 414 The earlier UDPCL specification in [RFC7122] did not include guidance 415 on IP addressing and potential use of multicast, though the 416 architecture of [RFC4838] explicitly includes multicast and anycast 417 as expected network modes. 419 The BP agent determines the mapping from destination EID to next-hop 420 CL parameters, including transfer destination address. Some EIDs 421 represent unicast destinations and others non-unicast destinations as 422 defined in Section 4.2.5.1 of [I-D.ietf-dtn-bpbis]. The unicast-ness 423 of an EID does not necessarily correspond with the unicast-ness, as 424 some bundle routing schemes involve attempting multiple parallel 425 paths to a unicast endpoint. 427 For unicast transfers to a single node, the destination address SHALL 428 be a unicast IPv4 or IPv6 address. When performing unicast 429 transfers, a UDPCL entity SHOULD restrict the network to one 430 protected by IPsec or some other under-layer security mechanism 431 (e.g., a virtual private network). 433 For multicast transfers to one or more nodes, the destination address 434 SHALL be a multicast IPv4 [IANA-IPv4-MCAST] or IPv6 [IANA-IPv6-MCAST] 435 address. 437 3.2. UDP Header 439 To perform UDPCL messaging, the active entity SHALL transmit a UDP 440 datagram to a listening passive entity in accordance with [RFC0768], 441 typically by using the services provided by the operating system. 442 Destination port number 4556 has been assigned by IANA as the 443 Registered Port number for the UDP convergence layer and SHALL be 444 used as a default. Other destination port numbers MAY be used per 445 local configuration. Determining a passive entity's destination port 446 number (if different from the registered UDPCL port number) is up to 447 the implementation. Any source port number MAY be used for UDPCL 448 transfers. Typically an operating system assigned number in the UDP 449 Ephemeral range (49152-65535) is used. 451 3.3. UDPCL Messaging 453 The lower layer of UDPCL communication is individual-datagram 454 messaging. For backward compatibility with [RFC7122], UDPCL has no 455 explicit message type identifier. The message type is inferred by 456 the inspecting the data contents according to the following rules: 458 The message type is inferred by the inspecting the data contents 459 according to the following rules: 461 Keepalive: Keepalive data SHALL be a total of four octets all with 462 value 0x00. Data with a leading octet value of 0x00 SHALL be 463 treated as keepalive. 465 Extension Map: All UDPCL extensions SHALL be contained in a CBOR map 466 in accordance with the definitions of Section 3.4. The encoded 467 Extension Map SHALL NOT have any CBOR tags. Data with a leading 468 octet value indicating CBOR map (major type 5) SHALL be treated as 469 an Extension Map. 471 Unframed Bundle: Bundles can be transmitted outside of a (fragmented 472 or not) Transfer item. This provides backward compatibility with 473 [RFC7122] and a allows a trivial use of UDPCL which is just 474 embedding an encoded bundle in a UDP datagram. The encoded bundle 475 is one of the following: 477 BPv6 Bundle: All encoded BP version 6 bundles begin with the 478 version identifier octet 0x06 in accordance with [RFC5050]. 479 Data with a leading octet value of 0x06 SHALL be treated as a 480 BPv6 bundle. 482 BPv7 Bundle: All encoded BP version 7 bundles begin with a CBOR 483 array head in accordance with [I-D.ietf-dtn-bpbis]. Data with 484 a leading octet value indicating CBOR array (major type 4) 485 SHALL be treated as a BPv7 bundle. 487 BPv7 bundles transmitted via UDPCL SHALL NOT include any 488 leading CBOR tag. If the BP agent provides bundles with such 489 tags the UDPCL entity SHALL remove them. 491 DTLS Record: In addition to the UDPCL specific messaging, 492 immediately after a DTLS Initiation (see Section 3.4.1) the DTLS 493 handshake sequence will begin. Data with a leading octet value of 494 0x16 SHALL be treated as a DTLS handshake record in accordance 495 with Section 4.1 of [RFC6347]. 497 If the datagram with the DTLS Initiation extension is not received 498 by an entity, the entity SHOULD still detect the DTLS handshake 499 records and start the handshake sequence at that point. Data with 500 a leading octet value of 0x17--0x19 SHALL be treated as a DTLS 501 sequencing failure; DTLS non-handshake records should never be 502 seen by the UDPCL messaging layer. 504 A summary of how a receiving UDPCL entity can interpret the first 505 octet of a datagram is listed in Table 1. When inspecting using CBOR 506 major types, the range of values is caused by the CBOR head encoding 507 of [RFC8949]. 509 +=============+==========================+ 510 | Octet Value | Message Content | 511 +=============+==========================+ 512 | 0x00 | Keepalive | 513 +-------------+--------------------------+ 514 | 0x06 | BPv6 Bundle | 515 +-------------+--------------------------+ 516 | 0x16--0x19 | DTLS Record | 517 +-------------+--------------------------+ 518 | 0x80--0x9F | BPv7 Bundle (CBOR array) | 519 +-------------+--------------------------+ 520 | 0xA0--0xBF | Extension Map (CBOR map) | 521 +-------------+--------------------------+ 522 | others | unused | 523 +-------------+--------------------------+ 525 Table 1: First-Octet Contents 527 3.4. UDPCL Extension Items 529 Extensions to UDPCL are encoded per-datagram in a single CBOR map as 530 defined in Section 3.3. Each UDPCL extension item SHALL be 531 identified by a unique integer (the Extension ID) used as a key in 532 the Extension Map. Extension ID assignments are listed in 533 Section 6.2. 535 Unless prohibited by particular extension type requirements, a single 536 Extension Map MAY contain any combination of extension items. 537 Receivers SHALL ignore extension items with unknown Extension ID and 538 continue to process known extension items. 540 The following subsections define the initial UDPCL extension types. 542 3.4.1. DTLS Initiation (STARTTLS) 544 This extension item indicates that the transmitter is about to begin 545 a DTLS handshake sequence in accordance with Section 3.5. 547 The DTLS Initiation value SHALL be an untagged null value. There are 548 no DTLS parameters actually transmitted as part of this extension, it 549 only serves to indicate to the recipient that the next datagram will 550 be a DTLS ClientHello. Although the datagram containing this 551 extension is not retransmitted, the DTLS handshake itself will 552 retransmit ClientHello messages until confirmation is received. 554 The Extension Map containing a DTLS Initiation item SHALL NOT contain 555 any other items. A DTLS Initiation item SHALL NOT be present in any 556 message transmitted within a DTLS session. A receiver of a DTLS 557 Initiation item within a DTLS session SHALL ignore it. 559 If the entity is configured to enable exchanging messages according 560 to DTLS 1.2 [RFC6347] or any successors which are compatible with 561 that DTLS ClientHello, the first message in any sequence to a unicast 562 recipient SHALL be an Extension Map with the DTLS Initiation item. 563 The RECOMMENDED policy is to enable DTLS for all unicast recipients, 564 even if security policy does not allow or require authentication. 565 This follows the opportunistic security model of [RFC7435], though an 566 active attacker could interfere with the exchange in such cases (see 567 Section 5.3). 569 3.4.2. Bundle Transfer 571 This extension item allows CL-layer fragmentation of bundle 572 transfers. It also allows a bundle transfer to be transmitted along 573 with extension items, which the unframed bundle data does not. 575 The Transfer value SHALL be an untagged CBOR array of four items. 576 The items are defined in the following order: 578 Transfer ID: This field SHALL be a CBOR unit item, which is used to 579 correlate multiple fragments. 581 Total Length: This field SHALL be a CBOR unit item, which is used to 582 indicate the total length (in octets) of the transfer. If 583 multiple Transfers for the same Transfer ID are received with 584 differing Total Length values, the receiver SHALL treat the 585 transfer as being malformed. 587 Fragment Offset: This field SHALL be a CBOR unit item, which is used 588 to indicate the offset (in octets) into the transfer for the start 589 of this fragment. 591 Fragment Data: This field SHALL be a CBOR bstr item, in which the 592 fragment data is contained. The bstr itself indicates the length 593 of the fragment data. 595 3.4.2.1. Bundle Transfer ID 597 Each Transfer item contains a Transfer ID which is used to correlate 598 messages for a single bundle transfer. A Transfer ID does not 599 attempt to address uniqueness of the bundle data itself and has no 600 relation to concepts such as bundle fragmentation. Each invocation 601 of UDPCL by the BP agent, requesting transmission of a bundle 602 (fragmentary or otherwise), results in the initiation of a single 603 UDPCL transfer. 605 Because UDPCL operation is connectionless, Transfer IDs from each 606 entity SHALL be unique for the operating duration of the entity. In 607 practice, the ID needs only be unique for the longest receiver 608 reassembly time window; but because that information is not part of 609 the protocol there is no way for an entity to When there are 610 bidirectional bundle transfers between UDPCL entities, an entity 611 SHOULD NOT rely on any relation between Transfer IDs originating from 612 each side of the conversation. 614 Although there is not a strict requirement for Transfer ID initial 615 values or ordering (see Section 5.11), in the absence of any other 616 mechanism for generating Transfer IDs an entity SHALL use the 617 following algorithm: the initial Transfer ID from each entity is 618 zero; subsequent Transfer ID values are incremented from the prior 619 Transfer ID value by one; upon exhaustion of the entire 64-bit 620 Transfer ID space, the subsequent Transfer ID value is zero. 622 3.4.2.2. Transfer Fragmentation and Reassembly 624 The full data content of a transfer SHALL be either a BPv6 or BPv7 625 Bundle as defined in Section 3.3. A receiving entity SHALL discard 626 any reassembled transfer which does not properly contain a bundle. 628 A transmitting entity MAY produce a Transfer with a single fragment 629 (i.e., a Fragment Data size identical to the Total Length). A 630 transmitting entity SHALL NOT produce Transfer fragments with 631 overlapping span. A transmitting entity SHOULD transmit Transfer 632 fragments in order of Fragment Offset; this makes the behavior 633 deterministic. 635 Because of the nature of UDP transport, there is no guaranteed order 636 or timing of received Transfer items. A receiving entity SHALL 637 consider a transport as finished when Fragment Data has been received 638 which fully covers the Total Length of the transfer. 640 A receiving entity SHALL discard any Transfer item containing 641 different CBOR types than defined in this document. A receiving 642 entity SHALL discard any Transfer item containing a fragment with an 643 overlapping span. Because there is no feedback indication at the 644 UDPCL layer, a transmitter has no indication when a transfer is 645 discarded by the receiver. 647 A receiving entity SHOULD discard unfinished transfer state after an 648 implementation-defined timeout since the last received fragment. 649 Entities SHOULD choose a transfer timeout interval no longer than one 650 minute (60 seconds). Discarding an unfinished transfer causes no 651 indication to the transmitting entity, but does indicate this to the 652 BP agent. 654 3.5. UDPCL Security 656 This version of the UDPCL supports establishing a DTLS session within 657 an existing UDP conversation. When DTLS is used within the UDPCL it 658 affects the entire conversation. 660 Once established, the lifetime of a DTLS session SHALL be bound by 661 the DTLS session ticket lifetime or either peer sending a Closure 662 Alert record. 664 Subsequent DTLS session attempts to the same passive entity MAY 665 attempt to use the DTLS session resumption feature. There is no 666 guarantee that the passive entity will accept the request to resume a 667 DTLS session, and the active entity cannot assume any resumption 668 outcome. 670 3.5.1. DTLS Handshake 672 The signaling for TLS Initiation is described in Section 3.4.1. 673 After sending or receiving an Extension Map containing a DTLS 674 Initiation item, an entity SHALL begin the handshake procedure of 675 Section 4.2 of [RFC6347]. By convention, this protocol uses the 676 entity which sent the DTLS Initiation (the active peer) as the 677 "client" role of the TLS handshake request. 679 Upon receiving an unexpected ClientHello record outside of a DTLS 680 session, an entity SHALL begin the DTLS handshake procedure as if a 681 DTLS Initiation had been received. This allows recovering from a 682 dropped packet containing DTLS Initiation. 684 3.5.2. DTLS Authentication 686 The function and mechanism of DTLS authentication for UDPCL is 687 exactly the same as that defined for TCPCL in Section 4.4.4 of 688 [I-D.ietf-dtn-tcpclv4]. 690 4. Implementation Status 692 This section is to be removed before publishing as an RFC. 694 [NOTE to the RFC Editor: please remove this section before 695 publication, as well as the reference to [RFC7942], 696 [github-dtn-demo-agent], and [github-dtn-wireshark].] 698 This section records the status of known implementations of the 699 protocol defined by this specification at the time of posting of this 700 Internet-Draft, and is based on a proposal described in [RFC7942]. 701 The description of implementations in this section is intended to 702 assist the IETF in its decision processes in progressing drafts to 703 RFCs. Please note that the listing of any individual implementation 704 here does not imply endorsement by the IETF. Furthermore, no effort 705 has been spent to verify the information presented here that was 706 supplied by IETF contributors. This is not intended as, and must not 707 be construed to be, a catalog of available implementations or their 708 features. Readers are advised to note that other implementations can 709 exist. 711 An example implementation of the this draft of UDPCL has been created 712 as a GitHub project [github-dtn-demo-agent] and is intended to use as 713 a proof-of-concept and as a possible source of interoperability 714 testing. This example implementation uses D-Bus as the CL-BP Agent 715 interface, so it only runs on hosts which provide the Python "dbus" 716 library. 718 A wireshark dissector for UDPCL has been created as a GitHub project 719 [github-dtn-wireshark] and has been kept in-sync with the latest 720 encoding of this specification. 722 5. Security Considerations 724 This section separates security considerations into threat categories 725 based on guidance of BCP 72 [RFC3552]. 727 5.1. Threat: Passive Leak of Node Data 729 When used without DTLS security, the UDPCL can expose the Node ID and 730 other configuration data to passive eavesdroppers. This can occur 731 even if no bundle transfers are transmitted. This can be avoided by 732 always using DTLS, even if authentication is not available (see 733 Section 5.10). 735 5.2. Threat: Passive Leak of Bundle Data 737 UDPCL can be used to provide point-to-point unicast transport 738 security, but does not provide multicast security, security of data- 739 at-rest, and does not guarantee end-to-end bundle security. In those 740 cases the bundle security mechanisms defined in [I-D.ietf-dtn-bpsec] 741 are to be used instead. 743 When used without DTLS security, the UDPCL exposes all bundle data to 744 passive eavesdroppers. This can be avoided by always using DTLS for 745 unicast messaging, even if authentication is not available (see 746 Section 5.10). 748 5.3. Threat: Transport Security Stripping 750 When security policy allows non-DTLS messaging, UDPCL does not 751 protect against active network attackers. It is possible for a on- 752 path attacker to drop or alter packets containing Extension Map and/ 753 or DTLS handshake records, which will cause the receiver to not 754 negotiate a DTLS session. This leads to the "SSL Stripping" attack 755 described in [RFC7457]. 757 When DTLS is available on an entity, it is strongly encouraged that 758 the security policy disallow non-DTLS messaging for unicast purposes. 759 This requires that the DTLS handshake occurs before any other UDPCL 760 messaging, regardless of the policy-driven parameters of the 761 handshake and policy-driven handling of the handshake outcome. 763 One mechanism to mitigate the possibility of DTLS stripping is the 764 use of DNS-based Authentication of Named Entities (DANE) [RFC6698] 765 toward the passive peer. This mechanism relies on DNS and is 766 unidirectional, so it doesn't help with applying policy toward the 767 active peer, but it can be useful in an environment using 768 opportunistic security. The configuration and use of DANE are 769 outside of the scope of this document. 771 The negotiated use of DTLS is identical behavior to STARTTLS use in 772 [RFC2595], [RFC4511], and others. 774 5.4. Threat: Weak DTLS Configurations 776 Even when using DTLS to secure the UDPCL session, the actual 777 ciphersuite negotiated between the DTLS peers can be insecure. 778 Recommendations for ciphersuite use are included in BCP 195 779 [RFC7525]. It is up to security policies within each UDPCL entity to 780 ensure that the negotiated DTLS ciphersuite meets transport security 781 requirements. 783 5.5. Threat: Untrusted End-Entity Certificate 785 The profile in Section 3.5.2 uses end-entity certificates chained up 786 to a trusted root CA. During DTLS handshake, either entity can send 787 a certificate set which does not contain the full chain, possibly 788 excluding intermediate or root CAs. In an environment where peers 789 are known to already contain needed root and intermediate CAs there 790 is no need to include those CAs, but this has a risk of an entity not 791 actually having one of the needed CAs. 793 5.6. Threat: Certificate Validation Vulnerabilities 795 Even when DTLS itself is operating properly an attacker can attempt 796 to exploit vulnerabilities within certificate check algorithms or 797 configuration to establish a secure DTLS session using an invalid 798 certificate. An invalid certificate exploit could lead to bundle 799 data leaking and/or denial of service to the Node ID being 800 impersonated. 802 There are many reasons, described in [RFC5280] and [RFC6125], why a 803 certificate can fail to validate, including using the certificate 804 outside of its valid time interval, using purposes for which it was 805 not authorized, or using it after it has been revoked by its CA. 806 Validating a certificate is a complex task and can require network 807 connectivity outside of the primary UDPCL network path(s) if a 808 mechanism such as OCSP [RFC6960] is used by the CA. The 809 configuration and use of particular certificate validation methods 810 are outside of the scope of this document. 812 5.7. Threat: BP Node Impersonation 814 The UDPCL does not provide any guarantees of or binding to the source 815 of transferred bundles. 817 One mitigation is to use the block integrity mechanisms defined in 818 [I-D.ietf-dtn-bpsec] with a security context which provides node 819 identity binding. 821 5.8. Threat: Denial of Service 823 The behaviors described in this section all amount to a potential 824 denial-of-service to a UDPCL entity. The denial-of-service could be 825 limited to an individual UDPCL entity, or could affect all entities 826 on a host or network segment. 828 An entity can send a large amount of data to a UDPCL entity, 829 requiring the receiving entity to handle the data. The victim entity 830 can block UDP packets from network peers which are thought to be 831 incorrectly behaving within network. 833 An entity can also send only one fragment of a seemingly valid 834 transfer and never send the remaining fragments, which will cause 835 resources on the receiver to be wasted on transfer reassembly state. 836 The victim entity can either block packets from network peers or 837 intentionally keep a short unfinished transfer timeout (see 838 Section 3.4.2.2). 840 The keepalive mechanism can be abused to waste throughput within a 841 network link which would otherwise be usable for bundle 842 transmissions. 844 5.9. Mandatory-to-Implement DTLS 846 Following IETF best current practice, DTLS is mandatory to implement 847 for all UDPCL implementations but DTLS is optional to use for a any 848 given transfer. The recommended configuration of Section 3.4.1 is to 849 always attempt DTLS, but entities are permitted to disable DTLS based 850 on local configuration. The configuration to enable or disable DTLS 851 for an entity or a session is outside of the scope of this document. 852 The configuration to disable DTLS is different from the threat of 853 DTLS stripping described in Section 5.3. 855 5.10. Alternate Uses of DTLS 857 This specification makes use of PKIX certificate validation and 858 authentication within DTLS. There are alternate uses of DTLS which 859 are not necessarily incompatible with the security goals of this 860 specification, but are outside of the scope of this document. The 861 following subsections give examples of alternate DTLS uses. 863 5.10.1. DTLS Without Authentication 865 In environments where PKI is available but there are restrictions on 866 the issuance of certificates (including the contents of 867 certificates), it may be possible to make use of DTLS in a way which 868 authenticates only the passive entity of a UDPCL transfer or which 869 does not authenticate either entity. Using DTLS in a way which does 870 not successfully authenticate some claim of both peer entities of a 871 UDPCL transfer is outside of the scope of this document but does have 872 similar properties to the opportunistic security model of [RFC7435]. 874 5.10.2. Non-Certificate DTLS Use 876 In environments where PKI is unavailable, alternate uses of DTLS 877 which do not require certificates such as pre-shared key (PSK) 878 authentication [RFC5489] and the use of raw public keys [RFC7250] are 879 available and can be used to ensure confidentiality within UDPCL. 880 Using non-PKI node authentication methods is outside of the scope of 881 this document. 883 5.11. Predictability of Transfer IDs 885 The only requirement on Transfer IDs is that they are unique from the 886 transmitting peer only. The trivial algorithm of the first transfer 887 starting at zero and later transfers incrementing by one causes 888 absolutely predictable Transfer IDs. Even when UDPCL is not DTLS 889 secured and there is a on-path attacker altering UDPCL messages, 890 there is no UDPCL feedback mechanism to interrupt or refuse a 891 transfer so there is no benefit in having unpredictable Transfer IDs. 893 6. IANA Considerations 895 Registration procedures referred to in this section are defined in 896 [RFC8126]. 898 6.1. Port Number 900 Within the port registry of [IANA-PORTS], UDP port number 4556 has 901 been previously assigned as the default port for the UDP convergence 902 layer in [RFC7122]. This assignment to UDPCL is unchanged, but the 903 assignment reference is updated to this specification. There is no 904 UDPCL version indication on-the-wire but this specification is a 905 superset of [RFC7122] and is fully backward compatible. The related 906 assignment for DCCP port 4556 (registered by [RFC7122]) is unchanged. 908 +========================+============================+ 909 | Parameter | Value | 910 +========================+============================+ 911 | Service Name: | dtn-bundle | 912 +------------------------+----------------------------+ 913 | Transport Protocol(s): | UDP | 914 +------------------------+----------------------------+ 915 | Assignee: | IESG | 916 +------------------------+----------------------------+ 917 | Contact: | IESG | 918 +------------------------+----------------------------+ 919 | Description: | DTN Bundle UDP CL Protocol | 920 +------------------------+----------------------------+ 921 | Reference: | This specification. | 922 +------------------------+----------------------------+ 923 | Port Number: | 4556 | 924 +------------------------+----------------------------+ 926 Table 2 928 6.2. UDPCL Extension Types 930 EDITOR NOTE: sub-registry to-be-created upon publication of this 931 specification. 933 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 934 a sub-registry titled "Bundle Protocol UDP Convergence-Layer 935 Extension Types" and initialize it with the contents of Table 3. For 936 positive code points the registration procedure is Specification 937 Required. Negative code points are reserved for use on private 938 networks for functions not published to the IANA. 940 Specifications of new extension types need to define the CBOR item 941 structure of the extension data as well as the purpose and 942 relationship of the new extension to existing session/transfer state 943 within the baseline UDPCL sequencing. Receiving entities will ignore 944 items with unknown Extension ID, and that behavior needs to be 945 considered by new extension types. 947 Expert(s) are encouraged to be biased towards approving registrations 948 unless they are abusive, frivolous, or actively harmful (not merely 949 aesthetically displeasing, or architecturally dubious). 951 +==============+==================+===========+=====================+ 952 | Extension ID | Name | Item | References | 953 | | | Type | | 954 +==============+==================+===========+=====================+ 955 | negative | Private/ | any | This specification. | 956 | | Experimental Use | | | 957 +--------------+------------------+-----------+---------------------+ 958 | 0 | Reserved | | This specification. | 959 +--------------+------------------+-----------+---------------------+ 960 | 2 | Transfer | array | Section 3.4.2 of | 961 | | | | this specification. | 962 +--------------+------------------+-----------+---------------------+ 963 | 5 | DTLS Initiation | null | Section 3.4.1 of | 964 | | (STARTTLS) | | this specification. | 965 +--------------+------------------+-----------+---------------------+ 967 Table 3: Extension Type Codes 969 7. Acknowledgments 971 TBD 973 8. References 975 8.1. Normative References 977 [IANA-BUNDLE] 978 IANA, "Bundle Protocol", 979 . 981 [IANA-PORTS] 982 IANA, "Service Name and Transport Protocol Port Number 983 Registry", . 986 [IANA-IPv4-MCAST] 987 IANA, "IPv4 Multicast Address Space Registry", 988 . 990 [IANA-IPv6-MCAST] 991 IANA, "IPv6 Multicast Address Space Registry", 992 . 995 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 996 DOI 10.17487/RFC0768, August 1980, 997 . 999 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1000 Communication Layers", STD 3, RFC 1122, 1001 DOI 10.17487/RFC1122, October 1989, 1002 . 1004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1005 Requirement Levels", BCP 14, RFC 2119, 1006 DOI 10.17487/RFC2119, March 1997, 1007 . 1009 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1010 Resource Identifier (URI): Generic Syntax", STD 66, 1011 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1012 . 1014 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 1015 Specification", RFC 5050, DOI 10.17487/RFC5050, November 1016 2007, . 1018 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1019 Housley, R., and W. Polk, "Internet X.509 Public Key 1020 Infrastructure Certificate and Certificate Revocation List 1021 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1022 . 1024 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1025 Verification of Domain-Based Application Service Identity 1026 within Internet Public Key Infrastructure Using X.509 1027 (PKIX) Certificates in the Context of Transport Layer 1028 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1029 2011, . 1031 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1032 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1033 January 2012, . 1035 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1036 Galperin, S., and C. Adams, "X.509 Internet Public Key 1037 Infrastructure Online Certificate Status Protocol - OCSP", 1038 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1039 . 1041 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1042 "Recommendations for Secure Use of Transport Layer 1043 Security (TLS) and Datagram Transport Layer Security 1044 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1045 2015, . 1047 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1048 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1049 March 2017, . 1051 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1052 Writing an IANA Considerations Section in RFCs", BCP 26, 1053 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1054 . 1056 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1057 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1058 May 2017, . 1060 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1061 Representation (CBOR)", STD 94, RFC 8949, 1062 DOI 10.17487/RFC8949, December 2020, 1063 . 1065 [I-D.ietf-dtn-bpbis] 1066 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 1067 Version 7", Work in Progress, Internet-Draft, draft-ietf- 1068 dtn-bpbis-31, 25 January 2021, 1069 . 1071 [I-D.ietf-dtn-tcpclv4] 1072 Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay- 1073 Tolerant Networking TCP Convergence Layer Protocol Version 1074 4", Work in Progress, Internet-Draft, draft-ietf-dtn- 1075 tcpclv4-24, 7 December 2020, 1076 . 1078 8.2. Informative References 1080 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1081 RFC 2595, DOI 10.17487/RFC2595, June 1999, 1082 . 1084 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1085 Text on Security Considerations", BCP 72, RFC 3552, 1086 DOI 10.17487/RFC3552, July 2003, 1087 . 1089 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 1090 Protocol (LDAP): The Protocol", RFC 4511, 1091 DOI 10.17487/RFC4511, June 2006, 1092 . 1094 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 1095 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 1096 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 1097 April 2007, . 1099 [RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for 1100 Transport Layer Security (TLS)", RFC 5489, 1101 DOI 10.17487/RFC5489, March 2009, 1102 . 1104 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1105 of Named Entities (DANE) Transport Layer Security (TLS) 1106 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 1107 2012, . 1109 [RFC7122] Kruse, H., Jero, S., and S. Ostermann, "Datagram 1110 Convergence Layers for the Delay- and Disruption-Tolerant 1111 Networking (DTN) Bundle Protocol and Licklider 1112 Transmission Protocol (LTP)", RFC 7122, 1113 DOI 10.17487/RFC7122, March 2014, 1114 . 1116 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1117 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1118 Transport Layer Security (TLS) and Datagram Transport 1119 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1120 June 2014, . 1122 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1123 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1124 December 2014, . 1126 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1127 Known Attacks on Transport Layer Security (TLS) and 1128 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1129 February 2015, . 1131 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1132 Code: The Implementation Status Section", BCP 205, 1133 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1134 . 1136 [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. 1137 Völker, "Packetization Layer Path MTU Discovery for 1138 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 1139 September 2020, . 1141 [I-D.ietf-dtn-bpsec] 1142 Birrane, E. and K. McKeever, "Bundle Protocol Security 1143 Specification", Work in Progress, Internet-Draft, draft- 1144 ietf-dtn-bpsec-26, 8 January 2021, 1145 . 1147 [github-dtn-demo-agent] 1148 Sipos, B., "UDPCL Example Implementation", 1149 . 1151 [github-dtn-wireshark] 1152 Sipos, B., "UDPCL Wireshark Dissector", 1153 . 1155 Appendix A. Significant changes from RFC7122 1157 The areas in which changes from [RFC7122] have been made to existing 1158 requirements: 1160 * Made explicit references to UDP- and IP-related RFCs. 1162 * Made more strict Keepalive requirements. 1164 * Defined UDPCL security and made mandatory-to-implement. 1166 The areas in which extensions from [RFC7122] have been made as new 1167 behaviors are: 1169 * Added BPv7 bundle as a possible UDPCL payload. 1171 * Added Extension Map message type and initial extension types. 1173 * Defined semantics for UDPCL multicast addressing. 1175 Author's Address 1177 Brian Sipos 1178 RKF Engineering Solutions, LLC 1179 7500 Old Georgetown Road 1180 Suite 1275 1181 Bethesda, MD 20814-6198 1182 United States of America 1184 Email: BSipos@rkf-eng.com