idnits 2.17.1 draft-sipos-dtn-udpcl-01.txt: -(1496): 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 (25 March 2021) is 1120 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) -- 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-SMI' ** 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 (~~), 4 warnings (==), 6 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 25 March 2021 5 Expires: 26 September 2021 7 Delay-Tolerant Networking UDP Convergence Layer Protocol 8 draft-sipos-dtn-udpcl-01 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 26 September 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. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 59 1.4. Definitions Specific to the UDPCL Protocol . . . . . . . 5 60 2. General Protocol Description . . . . . . . . . . . . . . . . 7 61 2.1. Convergence Layer Services . . . . . . . . . . . . . . . 8 62 2.2. PKIX Environments and CA Policy . . . . . . . . . . . . . 9 63 2.3. Fragmentation Policies . . . . . . . . . . . . . . . . . 9 64 2.4. Error Checking Policies . . . . . . . . . . . . . . . . . 10 65 2.5. Congestion Control Policies . . . . . . . . . . . . . . . 10 66 3. UDPCL Operation . . . . . . . . . . . . . . . . . . . . . . . 11 67 3.1. IP Addressing . . . . . . . . . . . . . . . . . . . . . . 11 68 3.2. UDP Header . . . . . . . . . . . . . . . . . . . . . . . 12 69 3.3. UDPCL Packets . . . . . . . . . . . . . . . . . . . . . . 12 70 3.4. UDPCL Messages . . . . . . . . . . . . . . . . . . . . . 12 71 3.5. UDPCL Extension Items . . . . . . . . . . . . . . . . . . 14 72 3.5.1. DTLS Initiation (STARTTLS) . . . . . . . . . . . . . 15 73 3.5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . 15 74 3.5.3. Sender Listen . . . . . . . . . . . . . . . . . . . . 16 75 3.5.4. Sender Node ID . . . . . . . . . . . . . . . . . . . 17 76 3.6. Explicit Transfers . . . . . . . . . . . . . . . . . . . 18 77 3.6.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 18 78 3.6.2. Fragmentation and Reassembly . . . . . . . . . . . . 19 79 3.7. UDPCL Security . . . . . . . . . . . . . . . . . . . . . 20 80 3.7.1. Entity Identification . . . . . . . . . . . . . . . . 20 81 3.7.2. Certificate Profile for UDPCL . . . . . . . . . . . . 20 82 3.7.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . 20 83 3.7.4. DTLS Authentication . . . . . . . . . . . . . . . . . 21 84 3.7.5. Policy Recommendations . . . . . . . . . . . . . . . 21 85 3.7.6. Example Secured and Bidirectional Transfers . . . . . 21 86 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 22 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 88 5.1. Threat: Passive Leak of Node Data . . . . . . . . . . . . 23 89 5.2. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 23 90 5.3. Threat: Transport Security Stripping . . . . . . . . . . 24 91 5.4. Threat: Weak DTLS Configurations . . . . . . . . . . . . 24 92 5.5. Threat: Untrusted End-Entity Certificate . . . . . . . . 24 93 5.6. Threat: Certificate Validation Vulnerabilities . . . . . 25 94 5.7. Threat: BP Node Impersonation . . . . . . . . . . . . . . 25 95 5.8. Threat: Denial of Service . . . . . . . . . . . . . . . . 26 96 5.9. Mandatory-to-Implement DTLS . . . . . . . . . . . . . . . 26 97 5.10. Alternate Uses of DTLS . . . . . . . . . . . . . . . . . 26 98 5.10.1. DTLS Without Authentication . . . . . . . . . . . . 27 99 5.10.2. Non-Certificate DTLS Use . . . . . . . . . . . . . . 27 100 5.11. Predictability of Transfer IDs . . . . . . . . . . . . . 27 101 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 102 6.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 27 103 6.2. UDPCL Extension Types . . . . . . . . . . . . . . . . . . 28 104 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 105 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 106 8.1. Normative References . . . . . . . . . . . . . . . . . . 29 107 8.2. Informative References . . . . . . . . . . . . . . . . . 32 108 Appendix A. Significant changes from RFC7122 . . . . . . . . . . 33 109 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 111 1. Introduction 113 This document describes the UDP-based convergence-layer protocol for 114 Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to- 115 end architecture providing communications in and/or through highly 116 stressed environments, including those with intermittent 117 connectivity, long and/or variable delays, and high bit error rates. 118 More detailed descriptions of the rationale and capabilities of these 119 networks can be found in "Delay-Tolerant Network Architecture" 120 [RFC4838]. 122 An important goal of the DTN architecture is to accommodate a wide 123 range of networking technologies and environments. The protocol used 124 for DTN communications is the Bundle Protocol Version 7 (BPv7) 125 [I-D.ietf-dtn-bpbis], an application-layer protocol that is used to 126 construct a store-and-forward overlay network. BPv7 requires the 127 services of a "convergence-layer adapter" (CLA) to send and receive 128 bundles using the service of some "native" link, network, or Internet 129 protocol. This document describes one such convergence-layer adapter 130 that uses the well-known User Datagram Protocol (UDP). This 131 convergence layer is referred to as UDP Convergence Layer (UDPCL). 132 For the remainder of this document, the abbreviation "BP" without the 133 version suffix refers to BPv7. 135 The locations of the UDPCL and the BP in the Internet model protocol 136 stack (described in [RFC1122]) are shown in Figure 1. In particular, 137 when BP is using UDP as its bearer with UDPCL as its convergence 138 layer, both BP and UDPCL reside at the application layer of the 139 Internet model. 141 +-------------------------+ 142 | DTN Application | -\ 143 +-------------------------| | 144 | Bundle Protocol (BP) | -> Application Layer 145 +-------------------------+ | 146 | UDP Conv. Layer (UDPCL) | | 147 +-------------------------+ | 148 | DTLS (optional) | -/ 149 +-------------------------+ 150 | UDP | ---> Transport Layer 151 +-------------------------+ 152 | IPv4/IPv6 | ---> Network Layer 153 +-------------------------+ 154 | Link-Layer Protocol | ---> Link Layer 155 +-------------------------+ 157 Figure 1: The Locations of the Bundle Protocol and the UDP 158 Convergence-Layer Protocol above the Internet Protocol Stack 160 1.1. Scope 162 This document describes the format of the protocol data units passed 163 between entities participating in UDPCL communications. This 164 document does not address: 166 * The format of protocol data units of the Bundle Protocol, as those 167 are defined elsewhere in [I-D.ietf-dtn-bpbis]. This includes the 168 concept of bundle fragmentation or bundle encapsulation. The 169 UDPCL transfers bundles as opaque data blocks. 171 * Mechanisms for locating or identifying other bundle entities 172 (peers) within a network or across an internet. The mapping of 173 Node ID to potential convergence layer (CL) protocol and network 174 address is left to implementation and configuration of the BP 175 Agent and its various potential routing strategies. 177 * Logic for routing bundles along a path toward a bundle's endpoint. 178 This CL protocol is involved only in transporting bundles between 179 adjacent entities in a routing sequence. 181 * Logic for performing rate control and congestion control of bundle 182 transfers, both incoming and outgoing from a UDPCL entity. 184 * Policies or mechanisms for issuing Public Key Infrastructure Using 185 X.509 (PKIX) certificates; provisioning, deploying, or accessing 186 certificates and private keys; deploying or accessing certificate 187 revocation lists (CRLs); or configuring security parameters on an 188 individual entity or across a network. 190 * Uses of Datagram Transport Layer Security (DTLS) which are not 191 based on PKIX certificate authentication (see Section 5.10.2) or 192 in which authentication of both entities is not possible (see 193 Section 5.10.1). 195 Any UDPCL implementation requires a BP agent to perform those above 196 listed functions in order to perform end-to-end bundle delivery. 198 1.2. Use of CDDL 200 This document defines CBOR structure using the Concise Data 201 Definition Language (CDDL) of [RFC8610]. The entire CDDL structure 202 can be extracted from the XML version of this document using the 203 XPath expression: 205 '//sourcecode[@type="cddl"]' 207 The following initial fragment defines the top-level symbols of this 208 document's CDDL. 210 start = udpcl-ext-map 212 1.3. Requirements Language 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 216 "OPTIONAL" in this document are to be interpreted as described in BCP 217 14 [RFC2119] [RFC8174] when, and only when, they appear in all 218 capitals, as shown here. 220 1.4. Definitions Specific to the UDPCL Protocol 222 This section contains definitions specific to the UDPCL protocol. 224 UDPCL Entity: This is the notional UDPCL application that initiates 225 UDPCL transfers. This design, implementation, configuration, and 226 specific behavior of such an entity is outside of the scope of 227 this document. However, the concept of an entity has utility 228 within the scope of this document as the container and initiator 229 of transfers. The relationship between a UDPCL entity and UDPCL 230 sessions is defined as follows: 232 * A UDPCL Entity MAY actively perform any number of transfers and 233 should do so whenever the entity has a bundle to forward to 234 another entity in the network. 236 * A UDPCL Entity MAY support zero or more passive listening 237 elements that listen for transfers from other entities in the 238 network, including non-unicast transfers. 240 These relationships are illustrated in Figure 2. For the 241 remainder of this document, the term "entity" without the prefix 242 "UDPCL" refers to a UDPCL entity. 244 UDP Conversation: This refers to datagrams exchanged between two 245 network peers, with each peer identified by a (unicast IP address, 246 UDP port) tuple. Because UDP is connectionless, there is no 247 notion of a conversation being "opened" or "closed" and some 248 conversations are uni-directional. 250 Transfer: This refers to the procedures and mechanisms for 251 conveyance of an individual bundle from one entity to one or more 252 destinations. This version of UDPCL includes a fragmentation 253 mechanism to allow transfers which are larger than the allowable 254 UDP datagram size. 256 Transmit: This refers to a transfer outgoing from an entity as seen 257 from that transmitting entity. 259 Receive: This refers to a transfer incoming to an entity as seen 260 from that receiving entity. 262 +----------------------------------------+ 263 | UDPCL Entity | 264 | | +----------------+ 265 | +--------------------------------+ | | |-+ 266 | | Actively Initiated Transfer #1 |--------->| Other | | 267 | +--------------------------------+ | | UDPCL Entity's | | 268 | ... | | Passive | | 269 | +--------------------------------+ | | Listener | | 270 | | Actively Initiated Transfer #n |--------->| | | 271 | | | | | | 272 | | Sender Listen |<---------| | | 273 | +--------------------------------+ | +----------------+ | 274 | | +-----------------+ 275 | +---------------------------+ | 276 | | +---------------------------+ | +----------------+ 277 | | | Optional Passive | | | |-+ 278 | +-| Listener(s) |<---------+ Other | | 279 | +---------------------------+ | | UDPCL Entity's | | 280 | ^ | | Active | | 281 | | | | Initiator(s) | | 282 | +-------------| | | 283 +----------------------------------------+ +----------------+ | 284 +-----------------+ 286 Figure 2: The relationships between UDPCL entities 288 2. General Protocol Description 290 The service of this protocol is the transmission of DTN bundles via 291 the User Datagram Protocol (UDP). This document specifies the 292 optional fragmentation of bundles, procedures for DTLS setup and 293 teardown, and a set of messages and entity requirements. The general 294 operation of the protocol is as follows. 296 Fundamentally, the UDPCL is a (logically) unidirectional "transmit 297 and forget" protocol which itself maintains no long-term state and 298 provides no feedback to the transmitter. The only long-term state 299 related to UDPCL is used by DTLS in its session keeping (which is 300 bound to a UDP conversation). An entity receiving a bundle from a 301 particular source address-and-port does not imply that the 302 transmitter is willing to accept bundle transfers on that same 303 address-and-port. It is the obligation of a BP agent and its routing 304 schemes to determine a bundle return path. 306 2.1. Convergence Layer Services 308 This version of the UDPCL provides the following services to support 309 the over-laying Bundle Protocol agent. In all cases, this is not an 310 API definition but a logical description of how the CL can interact 311 with the BP agent. Each of these interactions can be associated with 312 any number of additional metadata items as necessary to support the 313 operation of the CL or BP agent. 315 Begin Transmission: The principal purpose of the UDPCL is to allow a 316 BP agent to transmit bundle data to one or more other entities. 317 The receiver of each transfer is identified by an (destination) 318 IPv4 or IPv6 address and a UDP port number (see Section 3 for 319 details). The CL does not necessarily perform any transmission 320 queueing, but may block while transmissions are being processed at 321 the UDP layer. Any queueing of transmissions is the obligation of 322 the BP agent. 324 Transmission Started: The UDPCL entity indicates to the BP agent 325 when a bundle transmission begins sending UDP datagrams. Once 326 started, there is no notion of a UDPCL transmission failure; a BP 327 agent has to rely on bundle-level status reporting to track bundle 328 progress through the network. Because of potential queueing or 329 DTLS setup time, this may be delayed from the BP agent providing 330 the bundle-to-transmit. 332 Transmission Finished: The UDPCL entity indicates to the BP agent 333 when a bundle has been fully transmitted. This is not a positive 334 indication that any next-hop receiver has either received or 335 processed the transfer. 337 Reception Started: The UDPCL entity indicates to the BP agent when a 338 bundle transfer has begun, which may include information about the 339 total size of a fragmented transfer. 341 Reception Success: The UDPCL entity indicates to the BP agent when a 342 bundle has been fully transferred from a peer entity. The 343 transmitter of each transfer is identified by an (source) IP 344 address and a UDP port number (see Section 3 for details). 346 Reception Failure: The UDPCL entity indicates to the BP agent on 347 certain reasons for reception failure, notably upon an unfinished 348 transfer timeout (see Section 3.5.2). 350 Attempt DTLS Session: The UDPCL allows a BP agent to preemptively 351 attempt to establish a DTLS session with a peer entity (see 352 Section 3.5.1 and Section 3.7). Each session attempt can send a 353 different set of session negotiation parameters as directed by the 354 BP agent. 356 Close DTLS Session: The UDPCL allows a BP agent to preemptively 357 close an established DTLS session with a peer entity. The closure 358 request is on a per-session basis. 360 DTLS Session State Changed: The UDPCL entity indicates to the BP 361 agent when a DTLS session state changes. The possible DTLS 362 session states are defined in [RFC6347]. 364 Begin Sender Listen: The UDPCL allows a BP agent to indicate when 365 packets on a particular address-and-port is listened for (see 366 Section 3.5.3). The Sender Listen interval is configurable for 367 each peer address-and-port. 369 End Sender Listen: The UDPCL allows a BP agent to indicate when 370 packets on a particular address-and-port are no longer be 371 accepted. 373 Sender Listen Received: The UDPCL entity indicates to the BP agent 374 when a Sender Listen extension has been received from a peer. The 375 Sender Node ID, if present, is part of this indication. 377 2.2. PKIX Environments and CA Policy 379 This specification gives requirements about how to use PKIX 380 certificates issued by a Certificate Authority (CA), but does not 381 define any mechanisms for how those certificates come to be. The 382 UDPCL uses the exact same mechanisms and makes the same assumptions 383 as TCPCL in Section 3.4 of [I-D.ietf-dtn-tcpclv4]. 385 2.3. Fragmentation Policies 387 It is a implementation matter for a sending entity to determine the 388 path maximum transmit unit (PMTU) to be used as a target upper-bound 389 UDP datagram size. Some techniques to perform MTU discovery are 390 defined in [RFC8899]. All IP packets sent by a UDPCL entity SHOULD 391 have the "don't fragment" bit set to allow detection of PMTU issues. 393 The priority order of fragmentation is the following: 395 1. When possible, bundles too large to fit in one PMTU-sized packet 396 SHOULD be fragmented at the BP layer. Bundle payload 397 fragmentation does not help a large bundle if extension blocks 398 are a major contributor to bundle size, so in some circumstances 399 BP layer fragmentation will not reduce the bundle size 400 sufficiently. It is outside the scope of UDPCL to manage BP 401 agent fragmentation policies; bundles are received from the BP 402 agent either already fragmented or not. 404 2. Bundles too large to fit in one PMTU-sized packet SHALL be 405 fragmented as a UDPCL transfer (see Section 3.6). Fragmentation 406 at this level treats bundle transfers as opaque data, so it is 407 independent of bundle block sizes or counts. 409 3. All IP packets larger than expected PMTU SHALL be fragmented by 410 the transmitting entity to fit within one PMTU. Because of the 411 issues listed in Section 3.2 of [RFC8085] and [RFC8900], it is 412 best to avoid IP fragmentation as much as possible. 414 A UDPCL entity SHOULD NOT proactively drop an outgoing transfer due 415 to datagram size. If intermediate network nodes drop IP packets it 416 is an implementation matter to receive network feedback (e.g. ICMP 417 Packet Too Big). 419 2.4. Error Checking Policies 421 The core Bundle Protocol specification assumes that bundles are 422 transferring over an erasure channel, i.e., a channel that either 423 delivers packets correctly or not at all. 425 A UDP transmitter SHALL NOT disable UDP checksums. A UDP receiver 426 SHALL NOT disable the checking of received UDP checksums. 428 Even when UDP checksums are enabled, a small probability of UDP 429 packet corruption remains. In some environments, it may be 430 acceptable for a BP agent to occasionally receive corrupted input. 431 In general, however, a UDPCL entity SHOULD insure the a bundle's 432 blocks are either covered by a CRC or a BPSec integrity check. 434 2.5. Congestion Control Policies 436 The applications using UDPCL for bundle transport SHALL conform to 437 the congestion control requirements of Section 3.1 of [RFC8085]. The 438 application SHALL either perform active congestion control of bundles 439 or behave as the Low Data-Volume application as defined in 440 Section 3.1.3 of [RFC8085]. 442 When nodes have bidirectional transfer capability, the bundle 443 deletion reason code "traffic pared" can be used by a receiving agent 444 to signal to the bundle source application that throttling of bundles 445 along that path SHOULD occur. 447 3. UDPCL Operation 449 This section defines the UDPCL protocol and its interactions with 450 under-layers (IP and UDP) and over-layers (BP), as illustrated in 451 Figure 1. The section is organized from the network layer up toward 452 the BP layer. It also discusses behavior within the UDPCL layer, 453 which is illustrated in Figure 3. 455 +------------------------------------------+ 456 | Bundle Transfer | Extension Signaling | <- Sequencing / 457 +------------------------------------------+ fragmentation 458 | Bundle | Ext. Map | ... | Padding | <- Messaging 459 +------------------------------------------+ 460 | UDPCL Packet | <- Packetization 461 +------------------------------------------+ 463 Figure 3: Breakdown of sub-layers within the UDPCL 465 3.1. IP Addressing 467 The earlier UDPCL specification in [RFC7122] did not include guidance 468 on IP addressing, interface sourcing, or potential use of multicast, 469 though the architecture of [RFC4838] explicitly includes multicast 470 and anycast as expected network modes. 472 The BP agent determines the mapping from destination EID to next-hop 473 CL parameters, including transfer destination address and transfer 474 source interface. Some EIDs represent unicast destinations and 475 others non-unicast destinations as defined in Section 4.2.5.1 of 476 [I-D.ietf-dtn-bpbis]. The unicast-ness of an EID does not 477 necessarily correspond with the unicast-ness, as some bundle routing 478 schemes involve attempting multiple parallel paths to a unicast 479 endpoint. 481 For unicast transfers to a single node, the destination address SHALL 482 be a non-multicast IPv4 or IPv6 address (which does include link- 483 local addresses). For unicast transfers, the source interface 484 address MAY be supplied by the BP agent or otherwise determined by 485 the operating system IP routing. When performing unicast transfers, 486 a UDPCL entity SHOULD require DTLS use (see Section 3.7) or restrict 487 the network to one protected by IPsec or some other under-layer 488 security mechanism (e.g., a virtual private network). 490 For multicast transfers to one or more nodes, the destination address 491 SHALL be a multicast IPv4 [IANA-IPv4-MCAST] or IPv6 [IANA-IPv6-MCAST] 492 address. For multicast transfers, the source interface address MUST 493 be supplied by the BP agent rather than inferred by the UDPCL entity. 495 3.2. UDP Header 497 Destination port number 4556 has been assigned by IANA [IANA-PORTS] 498 as the Registered Port number for the UDP convergence layer and SHALL 499 be used as a default. Other destination port numbers MAY be used per 500 local configuration. Determining a passive entity's destination port 501 number (if different from the registered UDPCL port number) is up to 502 the implementation. 504 Any source port number MAY be used for UDPCL transfers. Typically an 505 operating system assigned number in the UDP Ephemeral range 506 (49152-65535) is used. For repeated messaging to the same 507 destination address-and-port, the active entity SHOULD reuse the same 508 source address-and-port. Reusing source address-and-port allows 509 simplifies network monitoring and analysis and also enables bi- 510 directional messaging as defined in Section 3.5.3. 512 3.3. UDPCL Packets 514 The lowest layer of UDPCL communication are individual-datagram 515 packets. To exchange UDPCL data, an active entity SHALL transmit a 516 UDP datagram to a listening passive entity in accordance with 517 [RFC0768], typically by using the services provided by the operating 518 system. For backward compatibility with [RFC7122], UDPCL has no 519 explicit message type identifier. 521 Each UDP datagram SHALL contain one or more UDPCL message as defined 522 in Section 3.4. Each type of message defines additional restrictions 523 on how it may be used in a packet. 525 The following are special cases of UDPCL packet uses. 527 Unframed Transfer: An unframed transfer packet SHALL consist of a 528 single encoded BPv6 or BPv7 bundle with no padding. This provides 529 backward compatibility with [RFC7122] and a allows a trivial use 530 of UDPCL which is just embedding an encoded bundle in a UDP 531 datagram. 533 Keepalive A keepalive packet SHALL consist of exactly four octets of 534 padding with no preceding message. This behavior maintains 535 backward compatibility with [RFC7122]. 537 3.4. UDPCL Messages 539 The middle layer of UDPCL communication are unframed, but self- 540 delimited, messages. Specific message types MAY be concatenated 541 together into a single packet, each message type indicates any 542 restrictions on how it can be used within a packet. 544 For backward compatibility with [RFC7122], UDPCL has no explicit 545 message type identifier. The message type is inferred by the 546 inspecting the data contents according to the following rules: 548 BPv6 Bundle: All encoded BP version 6 bundles begin with the version 549 identifier octet 0x06 in accordance with [RFC5050]. A message 550 with a leading octet value of 0x06 SHALL be treated as a BPv6 551 bundle. Multiple BPv6 Bundles SHOULD NOT be present in one UDPCL 552 packet to maintain compatibility with [RFC7122]. 554 BPv7 Bundle: All encoded BP version 7 bundles begin with a CBOR 555 array head in accordance with [I-D.ietf-dtn-bpbis]. A message 556 with a leading octet value indicating CBOR array (major type 4) 557 SHALL be treated as a BPv7 bundle. 559 BPv7 bundles transmitted via UDPCL SHALL NOT include any leading 560 CBOR tag. If the BP agent provides bundles with such tags the 561 transmitting UDPCL entity SHALL remove them. 563 Extension Map: All UDPCL extensions SHALL be contained in a CBOR map 564 in accordance with the definitions of Section 3.5. The encoded 565 Extension Map SHALL NOT have any CBOR tags. A message with a 566 leading octet value indicating CBOR map (major type 5) SHALL be 567 treated as an Extension Map. 569 Padding: Padding data SHALL be a sequence of octets all with value 570 0x00. A message with a leading octet value of 0x00 SHALL be 571 treated as padding. 573 Padding is used to ensure a UDP datagram is exactly a desired 574 size. Because padding has no intrinsic length indication, if 575 present it SHALL be the last contents of any UDPCL packet. A 576 receiving UDPCL entity SHALL ignore all padding, including any 577 trailing non-zero octets. 579 DTLS Record: In addition to the UDPCL specific messaging, 580 immediately after a DTLS Initiation (see Section 3.5.1) the DTLS 581 handshake sequence will begin. Data with a leading octet value of 582 0x16 SHALL be treated as a DTLS handshake record in accordance 583 with Section 4.1 of [RFC6347]. 585 If the datagram with the DTLS Initiation extension is not received 586 by an entity, the entity SHOULD still detect the DTLS handshake 587 records and start the handshake sequence at that point. Data with 588 a leading octet value of 0x17--0x19 SHALL be treated as a DTLS 589 sequencing failure; DTLS non-handshake records should never be 590 seen by the UDPCL messaging layer. 592 A summary of how a receiving UDPCL entity can interpret the first 593 octet of a datagram is listed in Table 1. When inspecting using CBOR 594 major types, the range of values is caused by the CBOR head encoding 595 of [RFC8949]. 597 +=============+===================================+ 598 | Octet Value | Message Content | 599 +=============+===================================+ 600 | 0x00 | Padding (remainder of packet) | 601 +-------------+-----------------------------------+ 602 | 0x06 | BPv6 Bundle | 603 +-------------+-----------------------------------+ 604 | 0x16--0x19 | DTLS Record (remainder of packet) | 605 +-------------+-----------------------------------+ 606 | 0x80--0x9F | BPv7 Bundle (CBOR array) | 607 +-------------+-----------------------------------+ 608 | 0xA0--0xBF | Extension Map (CBOR map) | 609 +-------------+-----------------------------------+ 610 | others | unused | 611 +-------------+-----------------------------------+ 613 Table 1: First-Octet Contents 615 3.5. UDPCL Extension Items 617 Extensions to UDPCL are encoded per-datagram in a single CBOR map as 618 defined in Section 3.4. Each UDPCL extension item SHALL be 619 identified by a unique Extension ID used as a key in the Extension 620 Map. Extension ID values SHALL be a CBOR int item no longer than 621 16-bits. Extension ID assignments are listed in Section 6.2. 623 Unless prohibited by particular extension type requirements, a single 624 Extension Map MAY contain any combination of extension items. 625 Receivers SHALL ignore extension items with unknown Extension ID and 626 continue to process known extension items. 628 ; Map structure requiring non-zero-int keys. 629 ; CDDL cannot enforce type-specific requirements about other items 630 ; being present (or not present) in the same map. 631 udpcl-ext-map = $udpcl-ext-map .within udpcl-ext-map-structure 632 $udpcl-ext-map = { 633 * $$udpcl-ext-item 634 } 635 udpcl-ext-map-structure = { 636 * ext-key => any 637 } 638 ext-key = (int .size 2) .ne 0 639 Figure 4: Extension Map structure CDDL 641 The following subsections define the initial UDPCL extension types. 643 3.5.1. DTLS Initiation (STARTTLS) 645 This extension item indicates that the transmitter is about to begin 646 a DTLS handshake sequence in accordance with Section 3.7. 648 The DTLS Initiation value SHALL be an untagged null value. There are 649 no DTLS parameters actually transmitted as part of this extension, it 650 only serves to indicate to the recipient that the next datagram will 651 be a DTLS ClientHello. Although the datagram containing this 652 extension is not retransmitted, the DTLS handshake itself will 653 retransmit ClientHello messages until confirmation is received. 655 $$udpcl-ext-item //= ( 656 5: null 657 ) 659 Figure 5: DTLS Initiation CDDL 661 If the entity is configured to enable exchanging messages according 662 to DTLS 1.2 [RFC6347] or any successors which are compatible with 663 that DTLS ClientHello, the first message in any sequence to a unicast 664 recipient SHALL be an Extension Map with the DTLS Initiation item. 665 The RECOMMENDED policy is to enable DTLS for all unicast recipients, 666 even if security policy does not allow or require authentication. 667 This follows the opportunistic security model of [RFC7435], though an 668 active attacker could interfere with the exchange in such cases (see 669 Section 5.3). 671 The Extension Map containing a DTLS Initiation item SHALL NOT contain 672 any other items. A DTLS Initiation item SHALL NOT be present in any 673 message transmitted within a DTLS session. A receiver of a DTLS 674 Initiation item within a DTLS session SHALL ignore it. Between 675 transmitting a DTLS Initiation item and finishing a DTLS handshake 676 (either success or failure) an entity SHALL NOT transmit any other 677 UDP datagrams in that same conversation. 679 3.5.2. Bundle Transfer 681 This extension item allows CL-layer fragmentation of bundle transfers 682 as defined in Section 3.6. 684 The Transfer value SHALL be an untagged CBOR array of four items. 685 The items are defined in the following order: 687 Transfer ID: This field SHALL be a CBOR uint item no larger than 688 32-bits, which is used to correlate multiple fragments. 690 Total Length: This field SHALL be a CBOR uint item no larger than 691 32-bits, which is used to indicate the total length (in octets) of 692 the transfer. If multiple Transfer items for the same Transfer ID 693 are received with differing Total Length values, the receiver 694 SHALL treat the transfer as being malformed and refuse to handle 695 any further fragments associated with the transfer. 697 Fragment Offset: This field SHALL be a CBOR uint item no larger than 698 32-bits, which is used to indicate the offset (in octets) into the 699 transfer for the start of this fragment. 701 Fragment Data: This field SHALL be a CBOR bstr item no larger than 702 2^32-1 octets, in which the fragment data is contained. The bstr 703 itself indicates the length of the fragment data. 705 $$udpcl-ext-item //= ( 706 2: [ 707 transfer-id: uint .size 4, 708 total-length: uint .size 4, 709 fragment-offset: uint .size 4, 710 fragment-data: bstr, 711 ] 712 ) 714 Figure 6: Transfer CDDL 716 3.5.3. Sender Listen 718 This extension item indicates that the transmitter is listening for 719 UDPCL packets on the source address-and-port used to transmit the 720 message containing this extension item. This is different from 721 simply listening on a UDP port (either the default or any other) when 722 the entity is behind a NAT or firewall which will not allow 723 unsolicited UDP/IP datagrams. Although the packet containing this 724 extension is not retransmitted, the time interval is finite and the 725 extension is sent repeatedly while the transmitter continues to 726 listen for packets. There is no positive indication that packets are 727 no longer accepted; the Sender Listen just stops being transmitted. 729 The Sender Listen value SHALL be an untagged uint value representing 730 the interval of time (in milliseconds) that the entity is willing to 731 accept UDPCL packets on the source address-and-port used for the 732 associated transmitted message. After transmitting a Sender Listen, 733 the entity SHALL listen for and accept datagrams on the source 734 address-and-port used for the associated transmitted message. As 735 long as the entity is still willing to accept packets, at the end of 736 one accept interval the entity SHALL transmit another Sender Listen 737 item. This repetition continues until the entity is no longer 738 willing to listen for packets. 740 A receiving entity SHOULD treat a peer as no longer listening after 741 an implementation-defined timeout since the last received Sender 742 Listen item. A RECOMMENDED Sender Listen timeout is three (3) times 743 the associated time duration; this allows a single dropped datagram 744 to not interrupt a continuous sequence. 746 $$udpcl-ext-item //= ( 747 3: time-duration, 748 ) 749 time-duration = uint 751 Figure 7: Sender Listen CDDL 753 Unlike the generic source port requirement in Section 3.2, when 754 repeated Sender Listen are transmitted in a sequence a consistent 755 source address-and-port SHALL be used. 757 The Sender Listen interval SHOULD be no shorter than 1 second and no 758 longer than 60 seconds. 760 An entity SHOULD include a Sender Node ID item along with a Sender 761 Listen item if the conditions of Section 3.5.4 are met. An entity 762 MAY include any other extension type along with a Sender Listen item. 763 An entity SHALL NOT transmit a Sender Listen item before or along 764 with a DTLS Initiate if DTLS is desired for a conversation. 766 This extension is not a neighbor discovery mechanism and does not 767 indicate an entity listening generally on a particular UDP port. 768 Sender Listen applies only to UDP datagrams from the the peer 769 address-and-port. An entity SHALL NOT include a Sender Listen item 770 in a message transmitted to a multicast address. 772 3.5.4. Sender Node ID 774 This extension item indicates the Node ID of the transmitter. For 775 DTLS-secured sessions (see Section 3.7.4) this extension can be used 776 to disambiguate an end-entity certificate which has multiple NODE-ID 777 values. 779 The Sender Node ID value SHALL be an untagged tstr value containing a 780 Node ID. Every Node ID SHALL be a URI consistent with the 781 requirements of [RFC3986] and the URI schemes of the IANA "Bundle 782 Protocol URI Scheme Type" registry [IANA-BUNDLE]. 784 $$udpcl-ext-item //= ( 785 4: nodeid, 786 ) 787 nodeid = tstr 789 Figure 8: Sender Node ID CDDL 791 An entity SHOULD NOT include a Sender Node ID item if a DTLS session 792 has already been established and the presented end-entity certificate 793 contains a single NODE-ID. In this case there is no ambiguity about 794 which Node ID is identified by the certificate. 796 If an entity receives a peer Node ID which is not authenticated (by 797 the procedure of Section 3.7.4) that Node ID SHOULD NOT be used by a 798 BP agent for any discovery or routing functions. Trusting an 799 unauthenticated Node ID can lead to the threat described in 800 Section 5.7. 802 3.6. Explicit Transfers 804 This version of UDPCL supports CL-layer fragmentation of bundles 805 larger than the PMTU would otherwise allow. Policies related to 806 fragmentation at, above, or below the UDPCL layer are defined in 807 Section 2.3. The entire fragmented bundle is referred to as a 808 Transfer and individual fragments of a transfer are encoded as 809 Transfer extension items in accordance with Section 3.5.2. 811 This mechanism also allows a bundle transfer to be transmitted along 812 with additional extension items, which the unframed bundle-in- 813 datagram data does not. This specification does not define any 814 extension items which augment an associated transfer. 816 3.6.1. Bundle Transfer ID 818 Each Transfer item contains a Transfer ID which is used to correlate 819 messages for a single bundle transfer. A Transfer ID does not 820 attempt to address uniqueness of the bundle data itself and has no 821 relation to concepts such as bundle fragmentation. Each invocation 822 of UDPCL by the BP agent, requesting transmission of a bundle 823 (fragmentary or otherwise), can cause the initiation of a single 824 UDPCL transfer. 826 Because UDPCL operation is connectionless, Transfer IDs from each 827 entity SHALL be unique for the operating duration of the entity. In 828 practice, the ID needs only be unique for the longest receiver 829 reassembly time window; but because that information is not part of 830 the protocol there is no way for an transmitting entity to know the 831 reassembly time window of any receiver (see Section 3.6.2). When 832 there are bidirectional bundle transfers between UDPCL entities, an 833 entity SHOULD NOT rely on any relation between Transfer IDs 834 originating from each side of the conversation. 836 Although there is not a strict requirement for Transfer ID initial 837 values or ordering (see Section 5.11), in the absence of any other 838 mechanism for generating Transfer IDs an entity SHALL use the 839 following algorithm: the initial Transfer ID from each entity is 840 zero; subsequent Transfer ID values are incremented from the prior 841 Transfer ID value by one; upon exhaustion of the entire 32-bit 842 Transfer ID space, the subsequent Transfer ID value is zero. 844 3.6.2. Fragmentation and Reassembly 846 The full data content of a transfer SHALL be an unframed (BPv6 or 847 BPv7) bundle as defined in Section 3.4. A receiving entity SHALL 848 discard any reassembled transfer which does not properly contain a 849 bundle. 851 A transmitting entity MAY produce a Transfer with a single fragment 852 (i.e., a Fragment Data size identical to the Total Length). A 853 transmitting entity SHALL NOT produce Transfer fragments with 854 overlapping span. A transmitting entity SHOULD transmit Transfer 855 fragments in order of Fragment Offset; this makes the behavior 856 deterministic. 858 Because of the nature of UDP transport, there is no guaranteed order 859 or timing of received Transfer items. A receiving entity SHALL 860 consider a transport as finished when Fragment Data has been received 861 which fully covers the Total Length of the transfer. 863 A receiving entity SHALL discard any Transfer item containing 864 different CBOR types than defined in this document. A receiving 865 entity SHALL discard any Transfer item containing a fragment with an 866 overlapping span. Because there is no feedback indication at the 867 UDPCL layer, a transmitter has no indication when a transfer is 868 discarded by the receiver. 870 A receiving entity SHOULD discard unfinished transfer state after an 871 implementation-defined timeout since the last received fragment. 872 Entities SHOULD choose a transfer timeout interval no longer than one 873 minute (60 seconds). Discarding an unfinished transfer causes no 874 indication to the transmitting entity, but does indicate this to the 875 BP agent. This timeout is purely receiver-side and represents the 876 maximum allowed time between sequential received datagrams (in any 877 order), which should be short if the datagrams take a similar network 878 path. 880 3.7. UDPCL Security 882 This version of the UDPCL supports establishing a DTLS session within 883 an existing UDP conversation. When DTLS is used within the UDPCL it 884 affects the entire conversation. There is no concept of a plaintext 885 message being sent in a conversation after a DTLS session is 886 established. 888 Once established, the lifetime of a DTLS session SHALL be bound by 889 the DTLS session ticket lifetime or either peer sending a Closure 890 Alert record. 892 Subsequent DTLS session attempts to the same passive entity MAY 893 attempt to use the DTLS session resumption feature. There is no 894 guarantee that the passive entity will accept the request to resume a 895 DTLS session, and the active entity cannot assume any resumption 896 outcome. 898 3.7.1. Entity Identification 900 The UDPCL uses DTLS for certificate exchange in both directions to 901 identify each entity and to allow each entity to authenticate its 902 peer. Each certificate can potentially identify multiple entities 903 and there is no problem using such a certificate as long as the 904 identifiers are sufficient to meet authentication policy (as 905 described in later sections) for the entity which presents it. 907 The types and priorities of identities used by DTLS in UDPCL is the 908 same as those for TLS in TCPCL as defined in Section 4.4.1 of 909 [I-D.ietf-dtn-tcpclv4]. 911 3.7.2. Certificate Profile for UDPCL 913 All end-entity certificates used by a UDPCL entity SHALL conform to 914 the profile defined in Section 4.4.2 of [I-D.ietf-dtn-tcpclv4]. 916 3.7.3. DTLS Handshake 918 The signaling for DTLS Initiation is described in Section 3.5.1. 919 After sending or receiving an Extension Map containing a DTLS 920 Initiation item, an entity SHALL begin the handshake procedure of 921 Section 4.2 of [RFC6347]. By convention, this protocol uses the 922 entity which sent the DTLS Initiation (the active peer) as the 923 "client" role of the DTLS handshake request. 925 Upon receiving an unexpected ClientHello record outside of a DTLS 926 session, an entity SHALL begin the DTLS handshake procedure as if a 927 DTLS Initiation had been received. This allows recovering from a 928 dropped packet containing DTLS Initiation. 930 3.7.4. DTLS Authentication 932 The function and mechanism of DTLS authentication in UDPCL is the 933 same as for TLS in TCPCL as defined in Section 4.4.4 of 934 [I-D.ietf-dtn-tcpclv4], with the exception that Node ID 935 Authentication is based on an optional Sender Node ID extension (see 936 Section 3.5.4) used to disambiguate when an end-entity certificate 937 contains multiple NODE-ID values. 939 3.7.5. Policy Recommendations 941 The policy recommendations given here are are the same as those for 942 TCPCL in Section 4.4.5 of [I-D.ietf-dtn-tcpclv4]. They are restated 943 in this document for clarity. 945 A RECOMMENDED security policy is to enable the use of OCSP checking 946 during DTLS handshake. A RECOMMENDED security policy is that if an 947 Extended Key Usage is present that it needs to contain "id-kp- 948 bundleSecurity" of [IANA-SMI] to be usable with UDPCL security. A 949 RECOMMENDED security policy is to require a validated NODE-ID and to 950 ignore any network-level DNS-ID or IPADDR-ID. 952 This policy relies on and informs the certificate requirements in 953 Section 3.7.2. This policy assumes that a DTN-aware CA (see 954 Section 2.2) will only issue a certificate for a Node ID when it has 955 verified that the private key holder actually controls the DTN node; 956 this is needed to avoid the threat identified in Section 5.7. This 957 policy requires that a certificate contain a NODE-ID and allows the 958 certificate to also contain network-level identifiers. A tailored 959 policy on a more controlled network could relax the requirement on 960 Node ID validation and allow just network-level identifiers to 961 authenticate a peer. 963 3.7.6. Example Secured and Bidirectional Transfers 965 This simple example shows a sequence of pre-transfer setup followed 966 by a set of (unrelated) bundle transfers. All messaging in this 967 example occurs between the same Entity A address-and-port and Entity 968 B address-and-port. 970 The example Entity A has a policy to only send or receive bundles 971 within a DTLS session, so any outgoing bundles to Entity B are queued 972 until the DTLS session is established. Because Entity A is willing 973 to accept transfers on its ephemeral UDP port, the first outgoing 974 message after the DTLS handshake contains the Sender Listen extension 975 (along with a Sender Node ID indicating its identity to Entity B). 977 Entity A Entity B 978 active peer passive peer 980 +-------------------------+ 981 | Initiate DTLS Ext. | -> 982 +-------------------------+ 983 +-------------------------+ +-------------------------+ 984 | DTLS Negotiation | -> <- | DTLS Negotiation | 985 | (as client) | | (as server) | 986 +-------------------------+ +-------------------------+ 988 DNS-ID and IPADDR-ID authentication occurs. 989 Secured UDPCL messaging can begin. 991 +-------------------------+ 992 | Sender Listen Ext. | -> 993 | Sender Node ID Ext. | 994 +-------------------------+ 996 NODE-ID authentication occurs. 997 DTLS session is established, transfers can begin. 999 +-------------------------+ 1000 | Unframed Transfer | -> +-------------------------+ 1001 +-------------------------+ <- | Unframed Transfer | 1002 +-------------------------+ +-------------------------+ 1003 | Unframed Transfer | -> 1004 +-------------------------+ 1006 Figure 9: An example of the flow of protocol messages on a single UDP 1007 conversation between two entities 1009 4. Implementation Status 1011 This section is to be removed before publishing as an RFC. 1013 [NOTE to the RFC Editor: please remove this section before 1014 publication, as well as the reference to [RFC7942], 1015 [github-dtn-demo-agent], and [github-dtn-wireshark].] 1017 This section records the status of known implementations of the 1018 protocol defined by this specification at the time of posting of this 1019 Internet-Draft, and is based on a proposal described in [RFC7942]. 1020 The description of implementations in this section is intended to 1021 assist the IETF in its decision processes in progressing drafts to 1022 RFCs. Please note that the listing of any individual implementation 1023 here does not imply endorsement by the IETF. Furthermore, no effort 1024 has been spent to verify the information presented here that was 1025 supplied by IETF contributors. This is not intended as, and must not 1026 be construed to be, a catalog of available implementations or their 1027 features. Readers are advised to note that other implementations can 1028 exist. 1030 An example implementation of the this draft of UDPCL has been created 1031 as a GitHub project [github-dtn-demo-agent] and is intended to use as 1032 a proof-of-concept and as a possible source of interoperability 1033 testing. This example implementation uses D-Bus as the CL-BP Agent 1034 interface, so it only runs on hosts which provide the Python "dbus" 1035 library. 1037 A wireshark dissector for UDPCL has been created as a GitHub project 1038 [github-dtn-wireshark] and has been kept in-sync with the latest 1039 encoding of this specification. 1041 5. Security Considerations 1043 This section separates security considerations into threat categories 1044 based on guidance of BCP 72 [RFC3552]. 1046 5.1. Threat: Passive Leak of Node Data 1048 When used without DTLS security, the UDPCL can expose the Node ID and 1049 other configuration data to passive eavesdroppers. This can occur 1050 even if no bundle transfers are transmitted. This can be avoided by 1051 always using DTLS, even if authentication is not available (see 1052 Section 5.10). 1054 5.2. Threat: Passive Leak of Bundle Data 1056 UDPCL can be used to provide point-to-point unicast transport 1057 security, but does not provide multicast security, security of data- 1058 at-rest, and does not guarantee end-to-end bundle security. In those 1059 cases the bundle security mechanisms defined in [I-D.ietf-dtn-bpsec] 1060 are to be used instead. 1062 When used without DTLS security, the UDPCL exposes all bundle data to 1063 passive eavesdroppers. This can be avoided by always using DTLS for 1064 unicast messaging, even if authentication is not available (see 1065 Section 5.10). 1067 5.3. Threat: Transport Security Stripping 1069 When security policy allows non-DTLS messaging, UDPCL does not 1070 protect against active network attackers. It is possible for a on- 1071 path attacker to drop or alter packets containing Extension Map and/ 1072 or DTLS handshake records, which will cause the receiver to not 1073 negotiate a DTLS session. This leads to the "SSL Stripping" attack 1074 described in [RFC7457]. 1076 When DTLS is available on an entity, it is strongly encouraged that 1077 the security policy disallow non-DTLS messaging for unicast purposes. 1078 This requires that the DTLS handshake occurs before any other UDPCL 1079 messaging, regardless of the policy-driven parameters of the 1080 handshake and policy-driven handling of the handshake outcome. 1082 One mechanism to mitigate the possibility of DTLS stripping is the 1083 use of DNS-based Authentication of Named Entities (DANE) [RFC6698] 1084 toward the passive peer. This mechanism relies on DNS and is 1085 unidirectional, so it doesn't help with applying policy toward the 1086 active peer, but it can be useful in an environment using 1087 opportunistic security. The configuration and use of DANE are 1088 outside of the scope of this document. 1090 The negotiated use of DTLS is identical behavior to STARTTLS use in 1091 [RFC2595], [RFC4511], and others. 1093 5.4. Threat: Weak DTLS Configurations 1095 Even when using DTLS to secure the UDPCL session, the actual 1096 ciphersuite negotiated between the DTLS peers can be insecure. 1097 Recommendations for ciphersuite use are included in BCP 195 1098 [RFC7525]. It is up to security policies within each UDPCL entity to 1099 ensure that the negotiated DTLS ciphersuite meets transport security 1100 requirements. 1102 5.5. Threat: Untrusted End-Entity Certificate 1104 The profile in Section 3.7.4 uses end-entity certificates chained up 1105 to a trusted root CA. During DTLS handshake, either entity can send 1106 a certificate set which does not contain the full chain, possibly 1107 excluding intermediate or root CAs. In an environment where peers 1108 are known to already contain needed root and intermediate CAs there 1109 is no need to include those CAs, but this has a risk of an entity not 1110 actually having one of the needed CAs. 1112 5.6. Threat: Certificate Validation Vulnerabilities 1114 Even when DTLS itself is operating properly an attacker can attempt 1115 to exploit vulnerabilities within certificate check algorithms or 1116 configuration to establish a secure DTLS session using an invalid 1117 certificate. An invalid certificate exploit could lead to bundle 1118 data leaking and/or denial of service to the Node ID being 1119 impersonated. 1121 There are many reasons, described in [RFC5280] and [RFC6125], why a 1122 certificate can fail to validate, including using the certificate 1123 outside of its valid time interval, using purposes for which it was 1124 not authorized, or using it after it has been revoked by its CA. 1125 Validating a certificate is a complex task and can require network 1126 connectivity outside of the primary UDPCL network path(s) if a 1127 mechanism such as OCSP [RFC6960] is used by the CA. The 1128 configuration and use of particular certificate validation methods 1129 are outside of the scope of this document. 1131 5.7. Threat: BP Node Impersonation 1133 The certificates exchanged by DTLS enable authentication of peer DNS 1134 name and Node ID, but it is possible that a peer either not provide a 1135 valid certificate or that the certificate does not validate either 1136 the DNS-ID/IPADDR-ID or NODE-ID of the peer (see Section 2.2). 1137 Having a CA-validated certificate does not alone guarantee the 1138 identity of the network host or BP node from which the certificate is 1139 provided; additional validation procedures in Section 3.7.3 bind the 1140 DNS-ID/IPADDR-ID or NODE-ID based on the contents of the certificate. 1142 The DNS-ID/IPADDR-ID validation is a weaker form of authentication, 1143 because even if a peer is operating on an authenticated network DNS 1144 name or IP address it can provide an invalid Node ID and cause 1145 bundles to be "leaked" to an invalid node. Especially in DTN 1146 environments, network names and addresses of nodes can be time- 1147 variable so binding a certificate to a Node ID is a more stable 1148 identity. 1150 NODE-ID validation ensures that the peer to which a bundle is 1151 transferred is in fact the node which the BP Agent expects it to be. 1152 In circumstances where certificates can only be issued to DNS names, 1153 Node ID validation is not possible but it could be reasonable to 1154 assume that a trusted host is not going to present an invalid Node 1155 ID. Determining when a DNS-ID/IPADDR-ID authentication can be 1156 trusted to validate a Node ID is also a policy matter outside of the 1157 scope of this document. 1159 One mitigation to arbitrary entities with valid PKIX certificates 1160 impersonating arbitrary Node IDs is the use of the PKIX Extended Key 1161 Usage key purpose "id-kp-bundleSecurity" of [IANA-SMI]. When this 1162 Extended Key Usage is present in the certificate, it represents a 1163 stronger assertion that the private key holder should in fact be 1164 trusted to operate as a DTN Node. 1166 5.8. Threat: Denial of Service 1168 The behaviors described in this section all amount to a potential 1169 denial-of-service to a UDPCL entity. The denial-of-service could be 1170 limited to an individual UDPCL entity, or could affect all entities 1171 on a host or network segment. 1173 An entity can send a large amount of data to a UDPCL entity, 1174 requiring the receiving entity to handle the data. The victim entity 1175 can block UDP packets from network peers which are thought to be 1176 incorrectly behaving within network. 1178 An entity can also send only one fragment of a seemingly valid 1179 transfer and never send the remaining fragments, which will cause 1180 resources on the receiver to be wasted on transfer reassembly state. 1181 The victim entity can either block packets from network peers or 1182 intentionally keep a short unfinished transfer timeout (see 1183 Section 3.6.2). 1185 The keepalive mechanism can be abused to waste throughput within a 1186 network link which would otherwise be usable for bundle 1187 transmissions. 1189 5.9. Mandatory-to-Implement DTLS 1191 Following IETF best current practice, DTLS is mandatory to implement 1192 for all UDPCL implementations but DTLS is optional to use for a any 1193 given transfer. The recommended configuration of Section 3.5.1 is to 1194 always attempt DTLS, but entities are permitted to disable DTLS based 1195 on local configuration. The configuration to enable or disable DTLS 1196 for an entity or a session is outside of the scope of this document. 1197 The configuration to disable DTLS is different from the threat of 1198 DTLS stripping described in Section 5.3. 1200 5.10. Alternate Uses of DTLS 1202 This specification makes use of PKIX certificate validation and 1203 authentication within DTLS. There are alternate uses of DTLS which 1204 are not necessarily incompatible with the security goals of this 1205 specification, but are outside of the scope of this document. The 1206 following subsections give examples of alternate DTLS uses. 1208 5.10.1. DTLS Without Authentication 1210 In environments where PKI is available but there are restrictions on 1211 the issuance of certificates (including the contents of 1212 certificates), it may be possible to make use of DTLS in a way which 1213 authenticates only the passive entity of a UDPCL transfer or which 1214 does not authenticate either entity. Using DTLS in a way which does 1215 not successfully authenticate some claim of both peer entities of a 1216 UDPCL transfer is outside of the scope of this document but does have 1217 similar properties to the opportunistic security model of [RFC7435]. 1219 5.10.2. Non-Certificate DTLS Use 1221 In environments where PKI is unavailable, alternate uses of DTLS 1222 which do not require certificates such as pre-shared key (PSK) 1223 authentication [RFC5489] and the use of raw public keys [RFC7250] are 1224 available and can be used to ensure confidentiality within UDPCL. 1225 Using non-PKI node authentication methods is outside of the scope of 1226 this document. 1228 5.11. Predictability of Transfer IDs 1230 The only requirement on Transfer IDs is that they are unique from the 1231 transmitting peer only. The trivial algorithm of the first transfer 1232 starting at zero and later transfers incrementing by one causes 1233 absolutely predictable Transfer IDs. Even when UDPCL is not DTLS 1234 secured and there is a on-path attacker altering UDPCL messages, 1235 there is no UDPCL feedback mechanism to interrupt or refuse a 1236 transfer so there is no benefit in having unpredictable Transfer IDs. 1238 6. IANA Considerations 1240 Registration procedures referred to in this section are defined in 1241 [RFC8126]. 1243 6.1. Port Number 1245 Within the port registry of [IANA-PORTS], UDP port number 4556 has 1246 been previously assigned as the default port for the UDP convergence 1247 layer in [RFC7122]. This assignment to UDPCL is unchanged, but the 1248 assignment reference is updated to this specification. There is no 1249 UDPCL version indication on-the-wire but this specification is a 1250 superset of [RFC7122] and is fully backward compatible. The related 1251 assignment for DCCP port 4556 (registered by [RFC7122]) is unchanged. 1253 +========================+============================+ 1254 | Parameter | Value | 1255 +========================+============================+ 1256 | Service Name: | dtn-bundle | 1257 +------------------------+----------------------------+ 1258 | Transport Protocol(s): | UDP | 1259 +------------------------+----------------------------+ 1260 | Assignee: | IESG | 1261 +------------------------+----------------------------+ 1262 | Contact: | IESG | 1263 +------------------------+----------------------------+ 1264 | Description: | DTN Bundle UDP CL Protocol | 1265 +------------------------+----------------------------+ 1266 | Reference: | This specification. | 1267 +------------------------+----------------------------+ 1268 | Port Number: | 4556 | 1269 +------------------------+----------------------------+ 1271 Table 2 1273 6.2. UDPCL Extension Types 1275 EDITOR NOTE: sub-registry to-be-created upon publication of this 1276 specification. 1278 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 1279 a sub-registry titled "Bundle Protocol UDP Convergence-Layer 1280 Extension Types" and initialize it with the contents of Table 3. For 1281 positive code points the registration procedure is Specification 1282 Required. Negative code points are reserved for use on private 1283 networks for functions not published to the IANA. 1285 Specifications of new extension types need to define the CBOR item 1286 structure of the extension data as well as the purpose and 1287 relationship of the new extension to existing session/transfer state 1288 within the baseline UDPCL sequencing. Receiving entities will ignore 1289 items with unknown Extension ID, and that behavior needs to be 1290 considered by new extension types. 1292 Expert(s) are encouraged to be biased towards approving registrations 1293 unless they are abusive, frivolous, or actively harmful (not merely 1294 aesthetically displeasing, or architecturally dubious). 1296 +==============+==========================+=====================+ 1297 | Extension ID | Name | References | 1298 +==============+==========================+=====================+ 1299 | negative | Private/Experimental Use | This specification. | 1300 +--------------+--------------------------+---------------------+ 1301 | 0 | Reserved | This specification. | 1302 +--------------+--------------------------+---------------------+ 1303 | 2 | Transfer | Section 3.5.2 of | 1304 | | | this specification. | 1305 +--------------+--------------------------+---------------------+ 1306 | 3 | Sender Listen | Section 3.5.3 of | 1307 | | | this specification. | 1308 +--------------+--------------------------+---------------------+ 1309 | 4 | Sender Node ID | Section 3.5.4 of | 1310 | | | this specification. | 1311 +--------------+--------------------------+---------------------+ 1312 | 5 | DTLS Initiation | Section 3.5.1 of | 1313 | | (STARTTLS) | this specification. | 1314 +--------------+--------------------------+---------------------+ 1315 | 6-65535 | Unassigned | | 1316 +--------------+--------------------------+---------------------+ 1318 Table 3: Extension Type Codes 1320 7. Acknowledgments 1322 TBD 1324 8. References 1326 8.1. Normative References 1328 [IANA-BUNDLE] 1329 IANA, "Bundle Protocol", 1330 . 1332 [IANA-PORTS] 1333 IANA, "Service Name and Transport Protocol Port Number 1334 Registry", . 1337 [IANA-IPv4-MCAST] 1338 IANA, "IPv4 Multicast Address Space Registry", 1339 . 1341 [IANA-IPv6-MCAST] 1342 IANA, "IPv6 Multicast Address Space Registry", 1343 . 1346 [IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers", 1347 . 1349 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1350 DOI 10.17487/RFC0768, August 1980, 1351 . 1353 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1354 Communication Layers", STD 3, RFC 1122, 1355 DOI 10.17487/RFC1122, October 1989, 1356 . 1358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1359 Requirement Levels", BCP 14, RFC 2119, 1360 DOI 10.17487/RFC2119, March 1997, 1361 . 1363 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1364 Resource Identifier (URI): Generic Syntax", STD 66, 1365 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1366 . 1368 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 1369 Specification", RFC 5050, DOI 10.17487/RFC5050, November 1370 2007, . 1372 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1373 Housley, R., and W. Polk, "Internet X.509 Public Key 1374 Infrastructure Certificate and Certificate Revocation List 1375 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1376 . 1378 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1379 Verification of Domain-Based Application Service Identity 1380 within Internet Public Key Infrastructure Using X.509 1381 (PKIX) Certificates in the Context of Transport Layer 1382 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1383 2011, . 1385 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1386 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1387 January 2012, . 1389 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1390 Galperin, S., and C. Adams, "X.509 Internet Public Key 1391 Infrastructure Online Certificate Status Protocol - OCSP", 1392 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1393 . 1395 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1396 "Recommendations for Secure Use of Transport Layer 1397 Security (TLS) and Datagram Transport Layer Security 1398 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1399 2015, . 1401 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1402 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1403 March 2017, . 1405 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1406 Writing an IANA Considerations Section in RFCs", BCP 26, 1407 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1408 . 1410 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1411 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1412 May 2017, . 1414 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1415 Definition Language (CDDL): A Notational Convention to 1416 Express Concise Binary Object Representation (CBOR) and 1417 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1418 June 2019, . 1420 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1421 Representation (CBOR)", STD 94, RFC 8949, 1422 DOI 10.17487/RFC8949, December 2020, 1423 . 1425 [I-D.ietf-dtn-bpbis] 1426 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 1427 Version 7", Work in Progress, Internet-Draft, draft-ietf- 1428 dtn-bpbis-31, 25 January 2021, 1429 . 1431 [I-D.ietf-dtn-tcpclv4] 1432 Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay- 1433 Tolerant Networking TCP Convergence Layer Protocol Version 1434 4", Work in Progress, Internet-Draft, draft-ietf-dtn- 1435 tcpclv4-24, 7 December 2020, 1436 . 1438 8.2. Informative References 1440 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1441 RFC 2595, DOI 10.17487/RFC2595, June 1999, 1442 . 1444 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1445 Text on Security Considerations", BCP 72, RFC 3552, 1446 DOI 10.17487/RFC3552, July 2003, 1447 . 1449 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 1450 Protocol (LDAP): The Protocol", RFC 4511, 1451 DOI 10.17487/RFC4511, June 2006, 1452 . 1454 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 1455 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 1456 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 1457 April 2007, . 1459 [RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for 1460 Transport Layer Security (TLS)", RFC 5489, 1461 DOI 10.17487/RFC5489, March 2009, 1462 . 1464 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1465 of Named Entities (DANE) Transport Layer Security (TLS) 1466 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 1467 2012, . 1469 [RFC7122] Kruse, H., Jero, S., and S. Ostermann, "Datagram 1470 Convergence Layers for the Delay- and Disruption-Tolerant 1471 Networking (DTN) Bundle Protocol and Licklider 1472 Transmission Protocol (LTP)", RFC 7122, 1473 DOI 10.17487/RFC7122, March 2014, 1474 . 1476 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1477 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1478 Transport Layer Security (TLS) and Datagram Transport 1479 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1480 June 2014, . 1482 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1483 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1484 December 2014, . 1486 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1487 Known Attacks on Transport Layer Security (TLS) and 1488 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1489 February 2015, . 1491 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1492 Code: The Implementation Status Section", BCP 205, 1493 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1494 . 1496 [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. 1497 Völker, "Packetization Layer Path MTU Discovery for 1498 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 1499 September 2020, . 1501 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 1502 and F. Gont, "IP Fragmentation Considered Fragile", 1503 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 1504 . 1506 [I-D.ietf-dtn-bpsec] 1507 Birrane, E. and K. McKeever, "Bundle Protocol Security 1508 Specification", Work in Progress, Internet-Draft, draft- 1509 ietf-dtn-bpsec-26, 8 January 2021, 1510 . 1512 [github-dtn-demo-agent] 1513 Sipos, B., "UDPCL Example Implementation", 1514 . 1516 [github-dtn-wireshark] 1517 Sipos, B., "UDPCL Wireshark Dissector", 1518 . 1520 Appendix A. Significant changes from RFC7122 1522 The areas in which changes from [RFC7122] have been made to existing 1523 requirements: 1525 * Made explicit references to UDP- and IP-related RFCs. 1527 * Made more strict Keepalive and Padding requirements. 1529 * Defined UDPCL security and made mandatory-to-implement. 1531 The areas in which extensions from [RFC7122] have been made as new 1532 behaviors are: 1534 * Added BPv7 bundle as a possible UDPCL payload. 1536 * Added Extension Map message type and initial extension types. 1538 * Defined semantics for UDPCL multicast addressing. 1540 Author's Address 1542 Brian Sipos 1543 RKF Engineering Solutions, LLC 1544 7500 Old Georgetown Road 1545 Suite 1275 1546 Bethesda, MD 20814-6198 1547 United States of America 1549 Email: BSipos@rkf-eng.com