idnits 2.17.1 draft-ietf-dtn-tcpclv4-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC7242, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Note: The Keepalive Interval SHOULD not be chosen too short as TCP retransmissions MAY occur in case of packet loss. Those will have to be triggered by a timeout (TCP retransmission timeout (RTO)), which is dependent on the measured RTT for the TCP connection so that KEEPALIVE messages MAY experience noticeable latency. -- The document date (December 10, 2017) is 2321 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I1' is mentioned on line 350, but not defined == Missing Reference: 'L1' is mentioned on line 338, but not defined == Missing Reference: 'L2' is mentioned on line 338, but not defined == Missing Reference: 'L3' is mentioned on line 344, but not defined == Outdated reference: A later version (-31) exists of draft-ietf-dtn-bpbis-10 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Experimental RFC: RFC 5050 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-27) exists of draft-ietf-dtn-bpsec-06 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 2 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 Obsoletes: 7242 (if approved) M. Demmer 5 Intended status: Standards Track UC Berkeley 6 Expires: June 13, 2018 J. Ott 7 Aalto University 8 S. Perreault 9 December 10, 2017 11 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 12 draft-ietf-dtn-tcpclv4-04 14 Abstract 16 This document describes a revised protocol for the TCP-based 17 convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The 18 protocol revision is based on implementation issues in the original 19 TCPCL Version 3 and updates to the Bundle Protocol contents, 20 encodings, and convergence layer requirements in Bundle Protocol 21 Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 bundles 22 as its service data unit being transported and provides a reliable 23 transport of such bundles. Several new IANA registries are defined 24 for TCPCLv4 which define some behaviors inherited from TCPCLv3 but 25 with updated encodings and/or semantics. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 13, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Definitions Specific to the TCPCL Protocol . . . . . . . 4 64 3. General Protocol Description . . . . . . . . . . . . . . . . 5 65 3.1. TCPCL Session Overview . . . . . . . . . . . . . . . . . 6 66 3.2. Example Message Exchange . . . . . . . . . . . . . . . . 7 67 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 8 68 4.1. Contact Header . . . . . . . . . . . . . . . . . . . . . 10 69 4.1.1. Header Extension Items . . . . . . . . . . . . . . . 12 70 4.2. Validation and Parameter Negotiation . . . . . . . . . . 13 71 4.3. Session Security . . . . . . . . . . . . . . . . . . . . 14 72 4.3.1. TLS Handshake Result . . . . . . . . . . . . . . . . 15 73 4.3.2. Example TLS Initiation . . . . . . . . . . . . . . . 15 74 5. Established Session Operation . . . . . . . . . . . . . . . . 16 75 5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . 16 76 5.2. Upkeep and Status Messages . . . . . . . . . . . . . . . 17 77 5.2.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 17 78 5.2.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 18 79 5.3. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 19 80 5.3.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 19 81 5.3.2. Transfer Initialization (XFER_INIT) . . . . . . . . . 20 82 5.3.3. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 21 83 5.3.4. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 22 84 5.3.5. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 23 85 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 25 86 6.1. Shutdown Message (SHUTDOWN) . . . . . . . . . . . . . . . 25 87 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 28 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 90 8.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 30 91 8.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 30 92 8.3. Header Extension Types . . . . . . . . . . . . . . . . . 31 93 8.4. Message Types . . . . . . . . . . . . . . . . . . . . . . 31 94 8.5. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 32 95 8.6. SHUTDOWN Reason Codes . . . . . . . . . . . . . . . . . . 33 96 8.7. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 34 98 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 100 10.1. Normative References . . . . . . . . . . . . . . . . . . 34 101 10.2. Informative References . . . . . . . . . . . . . . . . . 35 102 Appendix A. Significant changes from RFC7242 . . . . . . . . . . 36 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 105 1. Introduction 107 This document describes the TCP-based convergence-layer protocol for 108 Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to- 109 end architecture providing communications in and/or through highly 110 stressed environments, including those with intermittent 111 connectivity, long and/or variable delays, and high bit error rates. 112 More detailed descriptions of the rationale and capabilities of these 113 networks can be found in "Delay-Tolerant Network Architecture" 114 [RFC4838]. 116 An important goal of the DTN architecture is to accommodate a wide 117 range of networking technologies and environments. The protocol used 118 for DTN communications is the revised Bundle Protocol (BP) 119 [I-D.ietf-dtn-bpbis], an application-layer protocol that is used to 120 construct a store-and- forward overlay network. As described in the 121 Bundle Protocol specification [I-D.ietf-dtn-bpbis], it requires the 122 services of a "convergence- layer adapter" (CLA) to send and receive 123 bundles using the service of some "native" link, network, or Internet 124 protocol. This document describes one such convergence-layer adapter 125 that uses the well-known Transmission Control Protocol (TCP). This 126 convergence layer is referred to as TCPCL. 128 The locations of the TCPCL and the BP in the Internet model protocol 129 stack (described in [RFC1122]) are shown in Figure 1. In particular, 130 when BP is using TCP as its bearer with TCPCL as its convergence 131 layer, both BP and TCPCL reside at the application layer of the 132 Internet model. 134 +-------------------------+ 135 | DTN Application | -\ 136 +-------------------------| | 137 | Bundle Protocol (BP) | -> Application Layer 138 +-------------------------+ | 139 | TCP Conv. Layer (TCPCL) | | 140 +-------------------------+ | 141 | TLS (optional) | -/ 142 +-------------------------+ 143 | TCP | ---> Transport Layer 144 +-------------------------+ 145 | IPv4/IPv6 | ---> Network Layer 146 +-------------------------+ 147 | Link-Layer Protocol | ---> Link Layer 148 +-------------------------+ 150 Figure 1: The Locations of the Bundle Protocol and the TCP 151 Convergence-Layer Protocol above the Internet Protocol Stack 153 This document describes the format of the protocol data units passed 154 between entities participating in TCPCL communications. This 155 document does not address: 157 o The format of protocol data units of the Bundle Protocol, as those 158 are defined elsewhere in [RFC5050] and [I-D.ietf-dtn-bpbis]. This 159 includes the concept of bundle fragmentation or bundle 160 encapsulation. The TCPCL transfers bundles as opaque data blocks. 162 o Mechanisms for locating or identifying other bundle nodes within 163 an internet. 165 2. Requirements Language 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in [RFC2119]. 171 2.1. Definitions Specific to the TCPCL Protocol 173 This section contains definitions that are interpreted to be specific 174 to the operation of the TCPCL protocol, as described below. 176 TCPCL Node: A TCPCL node refers to either side of an negotiating or 177 in-service TCPCL Session. For most TCPCL behavior, the two nodes 178 are symmetric and there is no protocol distinction between them. 179 Some specific behavior, particularly during negotiation, 180 distinguishes between the connecting node and the connected-to 181 node. For the remainder of this document, the term "node" without 182 the prefix "TCPCL" refers to a TCPCL node. 184 TCP Connection: A TCP connection refers to a transport connection 185 using TCP as the transport protocol. 187 TCPCL Session: A TCPCL session (as opposed to a TCP connection) is a 188 TCPCL communication relationship between two bundle nodes. The 189 lifetime of a TCPCL session is bound to the lifetime of an 190 underlying TCP connection. Therefore, a TCPCL session is 191 initiated after a bundle node establishes a TCP connection to for 192 the purposes of bundle communication. A TCPCL session is 193 terminated when the TCP connection ends, due either to one or both 194 nodes actively terminating the TCP connection or due to network 195 errors causing a failure of the TCP connection. For the remainder 196 of this document, the term "session" without the prefix "TCPCL" 197 refers to a TCPCL session. 199 Session parameters: The session parameters are a set of values used 200 to affect the operation of the TCPCL for a given session. The 201 manner in which these parameters are conveyed to the bundle node 202 and thereby to the TCPCL is implementation dependent. However, 203 the mechanism by which two bundle nodes exchange and negotiate the 204 values to be used for a given session is described in Section 4.2. 206 Transfer: Transfer refers to the procedures and mechanisms 207 (described below) for conveyance of an individual bundle from one 208 node to another. Each transfer within TCPCLv4 is identified by a 209 Transfer ID number which is unique only to a single direction 210 within a single Session. 212 Reason Codes: The TCPCL uses numeric codes to encode specific 213 reasons for individual failure/error message types. This limits 214 the expressiveness of TCPCL error encodings, but simplifies the 215 encoding of errors and allows an application policy to attempt 216 recovery from expected 'failure' modes (e.g. if a Session cannot 217 be established with USE_TLS disabled because of a Contact Failure 218 shutdown, a re-attempt can be made with USE_TLS enabled). 220 3. General Protocol Description 222 The service of this protocol is the transmission of DTN bundles via 223 the Transmission Control Protocol (TCP). This document specifies the 224 encapsulation of bundles, procedures for TCP setup and teardown, and 225 a set of messages and node requirements. The general operation of 226 the protocol is as follows. 228 3.1. TCPCL Session Overview 230 First, one node establishes a TCPCL session to the other by 231 initiating a TCP connection in accordance with [RFC0793]. After 232 setup of the TCP connection is complete, an initial contact header is 233 exchanged in both directions to set parameters of the TCPCL session 234 and exchange a singleton endpoint identifier for each node (not the 235 singleton Endpoint Identifier (EID) of any application running on the 236 node) to denote the bundle-layer identity of each DTN node. This is 237 used to assist in routing and forwarding messages (e.g. to prevent 238 loops). 240 Once the TCPCL session is established and configured in this way, 241 bundles can be transferred in either direction. Each transfer is 242 performed by an initialization (XFER_INIT) message followed by one or 243 more logical segments of data within an XFER_SEGMENT message. The 244 choice of the length to use for segments is an implementation matter, 245 but each segment must be no larger than the receiving node's maximum 246 receive unit (MRU) (see the field "Segment MRU" of Section 4.1). The 247 first segment for a bundle MUST set the 'START' flag, and the last 248 one MUST set the 'end' flag in the XFER_SEGMENT message flags. 250 If multiple bundles are transmitted on a single TCPCL connection, 251 they MUST be transmitted consecutively. Interleaving data segments 252 from different bundles is not allowed. Bundle interleaving can be 253 accomplished by fragmentation at the BP layer or by establishing 254 multiple TCPCL sessions. 256 A feature of this protocol is for the receiving node to send 257 acknowledgments as bundle data segments arrive (XFER_ACK). The 258 rationale behind these acknowledgments is to enable the sender node 259 to determine how much of the bundle has been received, so that in 260 case the session is interrupted, it can perform reactive 261 fragmentation to avoid re-sending the already transmitted part of the 262 bundle. For each data segment that is received, the receiving node 263 sends an XFER_ACK message containing the cumulative length of the 264 bundle that has been received. The sending node MAY transmit 265 multiple XFER_SEGMENT messages without necessarily waiting for the 266 corresponding XFER_ACK responses. This enables pipelining of 267 messages on a channel. In addition, there is no explicit flow 268 control on the TCPCL layer. 270 Another feature is that a receiver MAY interrupt the transmission of 271 a bundle at any point in time by replying with a XFER_REFUSE message, 272 which causes the sender to stop transmission of the current bundle, 273 after completing transmission of a partially sent data segment. 274 Note: This enables a cross-layer optimization in that it allows a 275 receiver that detects that it already has received a certain bundle 276 to interrupt transmission as early as possible and thus save 277 transmission capacity for other bundles. 279 For sessions that are idle, a KEEPALIVE message is sent at a 280 negotiated interval. This is used to convey node liveness 281 information. 283 Finally, before sessions close, a SHUTDOWN message is sent to the 284 session peer. A SHUTDOWN message MAY also be used to refuse a 285 session setup by a peer (see Section 4.2). After sending a SHUTDOWN 286 message, the sender of the message MAY send further acknowledgments 287 (XFER_ACK or XFER_REFUSE) but no further data messages (XFER_INIT or 288 XFER_SEGMENT). After receving a SHUTDOWN message and when no 289 transfers are in-progress (i.e. have unacknowledged segemnts) 291 There are specific messages for sending and receiving operations (in 292 addition to session setup/teardown). TCPCL is symmetric, i.e., both 293 sides can start sending data segments in a session, and one side's 294 bundle transfer does not have to complete before the other side can 295 start sending data segments on its own. Hence, the protocol allows 296 for a bi-directional mode of communication. Note that in the case of 297 concurrent bidirectional transmission, acknowledgment segments MAY be 298 interleaved with data segments. 300 3.2. Example Message Exchange 302 The following figure depicts the protocol exchange for a simple 303 session, showing the session establishment and the transmission of a 304 single bundle split into three data segments (of lengths "L1", "L2", 305 and "L3") from Node A to Node B. 307 Note that the sending node MAY transmit multiple XFER_SEGMENT 308 messages without necessarily waiting for the corresponding XFER_ACK 309 responses. This enables pipelining of messages on a channel. 310 Although this example only demonstrates a single bundle transmission, 311 it is also possible to pipeline multiple XFER_SEGMENT messages for 312 different bundles without necessarily waiting for XFER_ACK messages 313 to be returned for each one. However, interleaving data segments 314 from different bundles is not allowed. 316 No errors or rejections are shown in this example. 318 Node A Node B 319 ====== ====== 320 +-------------------------+ +-------------------------+ 321 | Contact Header | -> <- | Contact Header | 322 +-------------------------+ +-------------------------+ 324 +-------------------------+ 325 | XFER_INIT | -> 326 | Transfer ID [I1] | 327 | Total Length [L1] | 328 +-------------------------+ 329 +-------------------------+ 330 | XFER_SEGMENT (start) | -> 331 | Transfer ID [I1] | 332 | Length [L1] | 333 | Bundle Data 0..(L1-1) | 334 +-------------------------+ 335 +-------------------------+ +-------------------------+ 336 | XFER_SEGMENT | -> <- | XFER_ACK (start) | 337 | Transfer ID [I1] | | Transfer ID [I1] | 338 | Length [L2] | | Length [L1] | 339 |Bundle Data L1..(L1+L2-1)| +-------------------------+ 340 +-------------------------+ 341 +-------------------------+ +-------------------------+ 342 | XFER_SEGMENT (end) | -> <- | XFER_ACK | 343 | Transfer ID [I1] | | Transfer ID [I1] | 344 | Length [L3] | | Length [L1+L2] | 345 |Bundle Data | +-------------------------+ 346 | (L1+L2)..(L1+L2+L3-1)| 347 +-------------------------+ 348 +-------------------------+ 349 <- | XFER_ACK (end) | 350 | Transfer ID [I1] | 351 | Length [L1+L2+L3] | 352 +-------------------------+ 354 +-------------------------+ +-------------------------+ 355 | SHUTDOWN | -> <- | SHUTDOWN | 356 +-------------------------+ +-------------------------+ 358 Figure 2: An Example of the Flow of Protocol Messages on a Single TCP 359 Session between Two Nodes (A and B) 361 4. Session Establishment 363 For bundle transmissions to occur using the TCPCL, a TCPCL session 364 MUST first be established between communicating nodes. It is up to 365 the implementation to decide how and when session setup is triggered. 367 For example, some sessions MAY be opened proactively and maintained 368 for as long as is possible given the network conditions, while other 369 sessions MAY be opened only when there is a bundle that is queued for 370 transmission and the routing algorithm selects a certain next-hop 371 node. 373 To establish a TCPCL session, a node MUST first establish a TCP 374 connection with the intended peer node, typically by using the 375 services provided by the operating system. Destination port number 376 4556 has been assigned by IANA as the Registered Port number for the 377 TCP convergence layer. Other destination port numbers MAY be used 378 per local configuration. Determining a peer's destination port 379 number (if different from the registered TCPCL port number) is up to 380 the implementation. Any source port number MAY be used for TCPCL 381 sessions. Typically an operating system assigned number in the TCP 382 Ephemeral range (49152--65535) is used. 384 If the node is unable to establish a TCP connection for any reason, 385 then it is an implementation matter to determine how to handle the 386 connection failure. A node MAY decide to re-attempt to establish the 387 connection. If it does so, it MUST NOT overwhelm its target with 388 repeated connection attempts. Therefore, the node MUST retry the 389 connection setup only after some delay (a 1-second minimum is 390 RECOMMENDED), and it SHOULD use a (binary) exponential backoff 391 mechanism to increase this delay in case of repeated failures. In 392 case a SHUTDOWN message specifying a reconnection delay is received, 393 that delay is used as the initial delay. The default initial delay 394 SHOULD be at least 1 second but SHOULD be configurable since it will 395 be application and network type dependent. 397 The node MAY declare failure after one or more connection attempts 398 and MAY attempt to find an alternate route for bundle data. Such 399 decisions are up to the higher layer (i.e., the BP). 401 Once a TCP connection is established, each node MUST immediately 402 transmit a contact header over the TCP connection. The format of the 403 contact header is described in Section 4.1. 405 Upon receipt of the contact header, both nodes perform the validation 406 and negotiation procedures defined in Section 4.2 408 After receiving the contact header from the other node, either node 409 MAY also refuse the session by sending a SHUTDOWN message. If 410 session setup is refused, a reason MUST be included in the SHUTDOWN 411 message. 413 4.1. Contact Header 415 Once a TCP connection is established, both parties exchange a contact 416 header. This section describes the format of the contact header and 417 the meaning of its fields. 419 The format for the Contact Header is as follows: 421 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 422 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 423 +---------------+---------------+---------------+---------------+ 424 | magic='dtn!' | 425 +---------------+---------------+---------------+---------------+ 426 | Version | Flags | Keepalive Interval | 427 +---------------+---------------+---------------+---------------+ 428 | Segment MRU... | 429 +---------------+---------------+---------------+---------------+ 430 | contd. | 431 +---------------+---------------+---------------+---------------+ 432 | Transfer MRU... | 433 +---------------+---------------+---------------+---------------+ 434 | contd. | 435 +---------------+---------------+---------------+---------------+ 436 | EID Length | EID Data... | 437 +---------------+---------------+---------------+---------------+ 438 | EID Data contd. | 439 +---------------+---------------+---------------+---------------+ 440 | Header Extension Length... | 441 +---------------+---------------+---------------+---------------+ 442 | contd. | 443 +---------------+---------------+---------------+---------------+ 444 | Header Extension Items... | 445 +---------------+---------------+---------------+---------------+ 447 Figure 3: Contact Header Format 449 See Section 4.2 for details on the use of each of these contact 450 header fields. The fields of the contact header are: 452 magic: A four-octet field that always contains the octet sequence 453 0x64 0x74 0x6e 0x21, i.e., the text string "dtn!" in US-ASCII (and 454 UTF-8). 456 Version: A one-octet field value containing the value 4 (current 457 version of the protocol). 459 Flags: A one-octet field of single-bit flags, interpreted according 460 to the descriptions in Table 1. 462 Keepalive Interval: A 16-bit unsigned integer indicating the longest 463 allowable interval, in seconds, between any message being received 464 in this session and a subsequent KEEPALIVE message being received. 466 Segment MRU: A 64-bit unsigned integer indicating the largest 467 allowable single-segment data payload size to be received in this 468 session. Any XFER_SEGMENT sent to this peer SHALL have a data 469 payload no longer than the peer's Segment MRU. The two nodes of a 470 single session MAY have different Segment MRUs, and no relation 471 between the two is required. 473 Transfer MRU: A 64-bit unsigned integer indicating the largest 474 allowable total-bundle data size to be received in this session. 475 Any bundle transfer sent to this peer SHALL have a Total bundle 476 data payload no longer than the peer's Transfer MRU. This value 477 can be used to perform proactive bundle fragmentation. The two 478 nodes of a single session MAY have different Transfer MRUs, and no 479 relation between the two is required. 481 EID Length and EID Data: Together these fields represent a variable- 482 length text string. The EID Length is a 16-bit unsigned integer 483 indicating the number of octets of EID Data to follow. A zero EID 484 Length SHALL be used to indicate the lack of EID rather than a 485 truly empty EID. This case allows an node to avoid exposing EID 486 information on an untrusted network. A non-zero-length EID Data 487 SHALL contain the UTF-8 encoded EID of some singleton endpoint in 488 which the sending node is a member, in the canonical format of 489 :. This EID encoding is 490 consistent with [I-D.ietf-dtn-bpbis]. 492 Header Extension Length Header Extension Items: Together these 493 fields represent protocol extension data not defined by this 494 specification. The Header Extension Length is the total number of 495 octets to follow which are used to encode the Header Extension 496 Item list. The encoding of each Header Extension Item is 497 identical form as described in Section 4.1.1. 499 +----------+--------+-----------------------------------------------+ 500 | Name | Code | Description | 501 +----------+--------+-----------------------------------------------+ 502 | CAN_TLS | 0x01 | If bit is set, indicates that the sending | 503 | | | peer is capable of TLS security. | 504 | | | | 505 | Reserved | others | 506 +----------+--------+-----------------------------------------------+ 508 Table 1: Contact Header Flags 510 4.1.1. Header Extension Items 512 Each of the Header Extension items SHALL be encoded in an identical 513 Type-Length-Value (TLV) container form as indicated in Figure 4. The 514 fields of the header extension item are: 516 Flags: A one-octet field containing generic bit flags about the 517 item, which are listed in Table 2. If a TCPCL node receives an 518 extension item with an unknown Item Type and the CRITICAL flag 519 set, the node SHALL close the TCPCL session with SHUTDOWN reason 520 code of "Contact Failure". If the CRITICAL flag is not set, an 521 node SHALL skip over and ignore any item with an unkonwn Item 522 Type. 524 Item Type: A 16-bit unsigned integer field containing the type of 525 the extension item. This specification does not define any 526 extension types directly, but does allocate an IANA registry for 527 such codes (see Section 8.3). 529 Item Length: A 32-bit unsigned integer field containing the number 530 of Item Value octets to follow. 532 Item Value: A variable-length data field which is interpreted 533 according to the associated Item Type. This specification places 534 no restrictions on an extensions use of available Item Value data. 535 Extension specification SHOULD avoid the use of large data 536 exchanges within the TCPCLv4 contact header as no bundle transfers 537 can begin until the a full contact exchange and negotiation has 538 been completed. 540 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 541 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 542 +---------------+---------------+---------------+---------------+ 543 | Item Flags | Item Type | Item Length...| 544 +---------------+---------------+---------------+---------------+ 545 | length contd. | Item Value... | 546 +---------------+---------------+---------------+---------------+ 547 | value contd. | 548 +---------------+---------------+---------------+---------------+ 550 Figure 4: Header Extention Item Format 552 +----------+--------+-----------------------------------------------+ 553 | Name | Code | Description | 554 +----------+--------+-----------------------------------------------+ 555 | CRITICAL | 0x01 | If bit is set, indicates that the receiving | 556 | | | peer must handle the extension item. | 557 | | | | 558 | Reserved | others | 559 +----------+--------+-----------------------------------------------+ 561 Table 2: Header Extension Item Flags 563 4.2. Validation and Parameter Negotiation 565 Upon reception of the contact header, each node follows the following 566 procedures to ensure the validity of the TCPCL session and to 567 negotiate values for the session parameters. 569 If the magic string is not present or is not valid, the connection 570 MUST be terminated. The intent of the magic string is to provide 571 some protection against an inadvertent TCP connection by a different 572 protocol than the one described in this document. To prevent a flood 573 of repeated connections from a misconfigured application, a node MAY 574 elect to hold an invalid connection open and idle for some time 575 before closing it. 577 A connecting TCPCL node SHALL send the highest TCPCL protocol version 578 on a first session attempt for a TCPCL peer. If a connecting node 579 receives a SHUTDOWN message with reason of "Version Mismatch", that 580 node MAY attempt further TCPCL sessions with the peer using earlier 581 protocol version numbers in decreasing order. Managing multi-TCPCL- 582 session state such as this is an implementation matter. 584 If a node receives a contact header containing a version that is 585 greater than the current version of the protocol that the node 586 implements, then the node SHALL shutdown the session with a reason 587 code of "Version mismatch". If a node receives a contact header with 588 a version that is lower than the version of the protocol that the 589 node implements, the node MAY either terminate the session (with a 590 reason code of "Version mismatch"). Otherwise, the node MAY adapt 591 its operation to conform to the older version of the protocol. The 592 decision of version fall-back is an implementation matter. 594 A node calculates the parameters for a TCPCL session by negotiating 595 the values from its own preferences (conveyed by the contact header 596 it sent to the peer) with the preferences of the peer node (expressed 597 in the contact header that it received from the peer). The 598 negotatiated parameters defined by this specification are described 599 in the following paragraphs. 601 Session Keepalive: Negotiation of the Session Keepalive parameter is 602 performed by taking the minimum of this two contact headers' 603 Keepalive Interval. If the negotiated Session Keepalive is zero 604 (i.e. one or both contact headers contains a zero Keepalive 605 Interval), then the keepalive feature (described in Section 5.2.1) 606 is disabled. There is no logical minimum value for the keepalive 607 interval, but when used for many sessions on an open, shared 608 network a short interval could lead to excessive traffic. For 609 shared network use, nodes SHOULD choose a keepalive interval no 610 shorter than 30 seconds. There is no logical maximum value for 611 the keepalive interval, but an idle TCP connection is liable for 612 closure by the host operating system if the keepalive time is 613 longer than tens-of-minutes. Nodes SHOULD choose a keepalive 614 interval no longer than 10 minutes (600 seconds). 616 Enable TLS: Negotiation of the Enable TLS parameter is performed by 617 taking the logical AND of the two contact headers' CAN_TLS flags. 618 If the negotiated Enable TLS value is true then TLS negotiation 619 feature (described in Section 4.3) begins immediately following 620 the contact header exchange. The security policy on either node 621 MAY forbid the establishment of a TCPCL session for any Enable TLS 622 result (or for any combination of local or peer CAN_TLS flag), in 623 which case the node SHALL shutdown the session with a reason code 624 of "Contact Failure". For example, one node may disallow TCPCL 625 sessions without TLS, while a second node may disallow sessions 626 with TLS. Also note that this Contact Failure (of the header 627 negotiation) is different than a TLS Failure (after an agreed-upon 628 Enable TLS state). 630 Once this process of parameter negotiation is completed (which 631 includes a possible completed TLS handshakede of the connection to 632 use TLS), this protocol defines no additional mechanism to change the 633 parameters of an established session; to effect such a change, the 634 TCPCL session MUST be terminated and a new session established. 636 4.3. Session Security 638 This version of the TCPCL supports establishing a Transport Layer 639 Security (TLS) session within an existing TCP connection. Negotation 640 of whether or not to initiate TLS within a TCPCL session is part of 641 the contact header as described in Section 4.2. The TLS handshake, 642 if it occurs, is considered to be part of the contact negotiation 643 before the TCPCL session itself is established. Specifics about 644 sensitive data exposure are discussed in Section 7. 646 When TLS is used within the TCPCL it affects the entire session. By 647 convention, this protocol uses the node which initiated the 648 underlying TCP connection as the "client" role of the TLS handshake 649 request. Once a TLS session is established within TCPCL, there is no 650 mechanism provided to end the TLS session and downgrade the session. 651 If a non-TLS session is desired after a TLS session is started then 652 the entire TCPCL session MUST be shutdown first. 654 After negotiating an Enable TLS parameter of true, and before any 655 other TCPCL messages are sent within the session, the session nodes 656 SHALL begin a TLS handshake in accordance with [RFC5246]. The 657 parameters within each TLS negotation are implementation dependent 658 but any TCPCL node SHOULD follow all recommended best practices of 659 [RFC7525]. 661 4.3.1. TLS Handshake Result 663 If a TLS handshake cannot negotiate a TLS session, both nodes of the 664 TCPCL session SHALL cause a TCPCL shutdown with reason "TLS Failure". 666 After a TLS session is successfuly established, both TCPCL nodes 667 SHALL re-exchange TCPCL Contact Header messages. Any information 668 cached from the prior Contact Header exchange SHALL be discarded. 669 This re-exchange avoids man-in-the-middle attack in identical fashion 670 to [RFC2595]. Each re-exchange header CAN_TLS flag SHALL be 671 identical to the original header CAN_TLS flag from the same node. 672 The CAN_TLS logic (TLS negotiation) SHALL NOT apply during header re- 673 exchange. This reinforces the fact that there is no TLS downgrade 674 mechanism. 676 4.3.2. Example TLS Initiation 678 A summary of a typical CAN_TLS usage is shown in the sequence in 679 Figure 5 below. 681 Node A Node B 682 ====== ====== 684 +-------------------------+ 685 | Open TCP Connnection | -> 686 +-------------------------+ +-------------------------+ 687 <- | Accept Connection | 688 +-------------------------+ 690 +-------------------------+ +-------------------------+ 691 | Contact Header | -> <- | Contact Header | 692 +-------------------------+ +-------------------------+ 694 +-------------------------+ +-------------------------+ 695 | TLS Negotiation | -> <- | TLS Negotiation | 696 | (as client) | | (as server) | 697 +-------------------------+ +-------------------------+ 699 +-------------------------+ +-------------------------+ 700 | Contact Header | -> <- | Contact Header | 701 +-------------------------+ +-------------------------+ 703 ... secured TCPCL messaging ... 705 +-------------------------+ +-------------------------+ 706 | SHUTDOWN | -> <- | SHUTDOWN | 707 +-------------------------+ +-------------------------+ 709 Figure 5: A simple visual example of TCPCL TLS Establishment between 710 two nodes 712 5. Established Session Operation 714 This section describes the protocol operation for the duration of an 715 established session, including the mechanism for transmitting bundles 716 over the session. 718 5.1. Message Type Codes 720 After the initial exchange of a contact header, all messages 721 transmitted over the session are identified by a one-octet header 722 with the following structure: 724 0 1 2 3 4 5 6 7 725 +---------------+ 726 | Message Type | 727 +---------------+ 729 Figure 6: Format of the Message Header 731 The message header fields are as follows: 733 Message Type: Indicates the type of the message as per Table 3 734 below. Encoded values are listed in Section 8.4. 736 +--------------+----------------------------------------------------+ 737 | Type | Description | 738 +--------------+----------------------------------------------------+ 739 | XFER_INIT | Contains the length (in octets) of the next | 740 | | transfer, as described in Section 5.3.2. | 741 | | | 742 | XFER_SEGMENT | Indicates the transmission of a segment of bundle | 743 | | data, as described in Section 5.3.3. | 744 | | | 745 | XFER_ACK | Acknowledges reception of a data segment, as | 746 | | described in Section 5.3.4. | 747 | | | 748 | XFER_REFUSE | Indicates that the transmission of the current | 749 | | bundle SHALL be stopped, as described in Section | 750 | | 5.3.5. | 751 | | | 752 | KEEPALIVE | Used to keep TCPCL session active, as described in | 753 | | Section 5.2.1. | 754 | | | 755 | SHUTDOWN | Indicates that one of the nodes participating in | 756 | | the session wishes to cleanly terminate the | 757 | | session, as described in Section 6. | 758 | | | 759 | MSG_REJECT | Contains a TCPCL message rejection, as described | 760 | | in Section 5.2.2. | 761 +--------------+----------------------------------------------------+ 763 Table 3: TCPCL Message Types 765 5.2. Upkeep and Status Messages 767 5.2.1. Session Upkeep (KEEPALIVE) 769 The protocol includes a provision for transmission of KEEPALIVE 770 messages over the TCPCL session to help determine if the underlying 771 TCP connection has been disrupted. 773 As described in Section 4.1, one of the parameters in the contact 774 header is the Keepalive Interval. Both sides populate this field 775 with their requested intervals (in seconds) between KEEPALIVE 776 messages. 778 The format of a KEEPALIVE message is a one-octet message type code of 779 KEEPALIVE (as described in Table 3) with no additional data. Both 780 sides SHOULD send a KEEPALIVE message whenever the negotiated 781 interval has elapsed with no transmission of any message (KEEPALIVE 782 or other). 784 If no message (KEEPALIVE or other) has been received for at least 785 twice the Keepalive Interval, then either party MAY terminate the 786 session by transmitting a one-octet SHUTDOWN message (as described in 787 Section 6.1, with reason code "Idle Timeout") and by closing the 788 session. 790 Note: The Keepalive Interval SHOULD not be chosen too short as TCP 791 retransmissions MAY occur in case of packet loss. Those will have to 792 be triggered by a timeout (TCP retransmission timeout (RTO)), which 793 is dependent on the measured RTT for the TCP connection so that 794 KEEPALIVE messages MAY experience noticeable latency. 796 5.2.2. Message Rejection (MSG_REJECT) 798 If a TCPCL node receives a message which is unknown to it (possibly 799 due to an unhandled protocol mismatch) or is inappropriate for the 800 current session state (e.g. a KEEPALIVE message received after 801 contact header negotation has disabled that feature), there is a 802 protocol-level message to signal this condition in the form of a 803 MSG_REJECT reply. 805 The format of a MSG_REJECT message follows: 807 +-----------------------------+ 808 | Message Header | 809 +-----------------------------+ 810 | Reason Code (U8) | 811 +-----------------------------+ 812 | Rejected Message Header | 813 +-----------------------------+ 815 Figure 7: Format of MSG_REJECT Messages 817 The fields of the MSG_REJECT message are: 819 Reason Code: A one-octet refusal reason code interpreted according 820 to the descriptions in Table 4. 822 Rejected Message Header: The Rejected Message Header is a copy of 823 the Message Header to which the MSG_REJECT message is sent as a 824 response. 826 +-------------+------+----------------------------------------------+ 827 | Name | Code | Description | 828 +-------------+------+----------------------------------------------+ 829 | Message | 0x01 | A message was received with a Message Type | 830 | Type | | code unknown to the TCPCL node. | 831 | Unknown | | | 832 | | | | 833 | Message | 0x02 | A message was received but the TCPCL node | 834 | Unsupported | | cannot comply with the message contents. | 835 | | | | 836 | Message | 0x03 | A message was received while the session is | 837 | Unexpected | | in a state in which the message is not | 838 | | | expected. | 839 +-------------+------+----------------------------------------------+ 841 Table 4: MSG_REJECT Reason Codes 843 5.3. Bundle Transfer 845 All of the message in this section are directly associated with 846 transfering a bundle between TCPCL nodes. 848 A single TCPCL transfer results in a bundle (handled by the 849 convergence layer as opaque data) being exchanged from one node to 850 the other. In TCPCL a transfer is accomplished by dividing a single 851 bundle up into "segments" based on the receiving-side Segment MRU 852 (see Section 4.1). 854 A single transfer (and by extension a single segment) SHALL NOT 855 contain data of more than a single bundle. This requirement is 856 imposed on the agent using the TCPCL rather than TCPCL itself. 858 5.3.1. Bundle Transfer ID 860 Each of the bundle transfer messages contains a Transfer ID number 861 which is used to correlate messages originating from sender and 862 receiver of a bundle. A Transfer ID does not attempt to address 863 uniqueness of the bundle data itself and has no relation to concepts 864 such as bundle fragmentation. Each invocation of TCPCL by the bundle 865 protocol agent, requesting transmission of a bundle (fragmentary or 866 otherwise), results in the initiation of a single TCPCL transfer. 867 Each transfer entails the sending of a XFER_INIT message and some 868 number of XFER_SEGMENT and XFER_ACK messages; all are correlated by 869 the same Transfer ID. 871 Transfer IDs from each node SHALL be unique within a single TCPCL 872 session. The initial Transfer ID from each node SHALL have value 873 zero. Subsequent Transfer ID values SHALL be incremented from the 874 prior Transfer ID value by one. Upon exhaustion of the entire 64-bit 875 Transfer ID space, the sending node SHALL terminate the session with 876 SHUTDOWN reason code "Resource Exhaustion". 878 For bidirectional bundle transfers, a TCPCL node SHOULD NOT rely on 879 any relation between Transfer IDs originating from each side of the 880 TCPCL session. 882 5.3.2. Transfer Initialization (XFER_INIT) 884 The XFER_INIT message contains the total length, in octets, of the 885 bundle data in the associated transfer. The total length is 886 formatted as a 64-bit unsigned integer. 888 The purpose of the XFER_INIT message is to allow nodes to 889 preemptively refuse bundles that would exceed their resources or to 890 prepare storage on the receiving node for the upcoming bundle data. 891 See Section 5.3.5 for details on when refusal based on XFER_INIT 892 content is acceptable. 894 The Total Bundle Length field within a XFER_INIT message SHALL be 895 treated as authoritative by the receiver. If, for whatever reason, 896 the actual total length of bundle data received differs from the 897 value indicated by the XFER_INIT message, the receiver SHOULD treat 898 the transmitted data as invalid. 900 The format of the XFER_INIT message is as follows: 902 +-----------------------------+ 903 | Message Header | 904 +-----------------------------+ 905 | Transfer ID (U64) | 906 +-----------------------------+ 907 | Total bundle length (U64) | 908 +-----------------------------+ 910 Figure 8: Format of XFER_INIT Messages 912 The fields of the XFER_INIT message are: 914 Transfer ID: A 64-bit unsigned integer identifying the transfer 915 about to begin. 917 Total bundle length: A 64-bit unsigned integer indicating the size 918 of the data-to-be-transferred. 920 An XFER_INIT message SHALL be sent immediately before transmission of 921 any XFER_SEGMENT messages for each Transfer ID. XFER_INIT messages 922 MUST NOT be sent unless the next XFER_SEGMENT message has the 'START' 923 bit set to "1" (i.e., just before the start of a new transfer). 925 A receiver MAY send a BUNDLE_REFUSE message as soon as it receives a 926 XFER_INIT message without waiting for the next XFER_SEGMENT message. 927 The sender MUST be prepared for this and MUST associate the refusal 928 with the correct bundle via the Transfer ID fields. 930 5.3.3. Data Transmission (XFER_SEGMENT) 932 Each bundle is transmitted in one or more data segments. The format 933 of a XFER_SEGMENT message follows in Figure 9. 935 +------------------------------+ 936 | Message Header | 937 +------------------------------+ 938 | Message Flags (U8) | 939 +------------------------------+ 940 | Transfer ID (U64) | 941 +------------------------------+ 942 | Data length (U64) | 943 +------------------------------+ 944 | Data contents (octet string) | 945 +------------------------------+ 947 Figure 9: Format of XFER_SEGMENT Messages 949 The fields of the XFER_SEGMENT message are: 951 Message Flags: A one-octet field of single-bit flags, interpreted 952 according to the descriptions in Table 5. 954 Transfer ID: A 64-bit unsigned integer identifying the transfer 955 being made. 957 Data length: A 64-bit unsigned integer indicating the number of 958 octets in the Data contents to follow. 960 Data contents: The variable-length data payload of the message. 962 +----------+--------+-----------------------------------------------+ 963 | Name | Code | Description | 964 +----------+--------+-----------------------------------------------+ 965 | END | 0x01 | If bit is set, indicates that this is the | 966 | | | last segment of the transfer. | 967 | | | | 968 | START | 0x02 | If bit is set, indicates that this is the | 969 | | | first segment of the transfer. | 970 | | | | 971 | Reserved | others | 972 +----------+--------+-----------------------------------------------+ 974 Table 5: XFER_SEGMENT Flags 976 The flags portion of the message contains two optional values in the 977 two low-order bits, denoted 'START' and 'END' in Table 5. The 978 'START' bit MUST be set to one if it precedes the transmission of the 979 first segment of a transfer. The 'END' bit MUST be set to one when 980 transmitting the last segment of a transfer. In the case where an 981 entire transfer is accomplished in a single segment, both the 'START' 982 and 'END' bits MUST be set to one. 984 Once a transfer of a bundle has commenced, the node MUST only send 985 segments containing sequential portions of that bundle until it sends 986 a segment with the 'END' bit set. No interleaving of multiple 987 transfers from the same node is possible within a single TCPCL 988 session. Simultaneous transfers between two nodes MAY be achieved 989 using multiple TCPCL sessions. 991 5.3.4. Data Acknowledgments (XFER_ACK) 993 Although the TCP transport provides reliable transfer of data between 994 transport peers, the typical BSD sockets interface provides no means 995 to inform a sending application of when the receiving application has 996 processed some amount of transmitted data. Thus, after transmitting 997 some data, a Bundle Protocol agent needs an additional mechanism to 998 determine whether the receiving agent has successfully received the 999 segment. To this end, the TCPCL protocol provides feedback messaging 1000 whereby a receiving node transmits acknowledgments of reception of 1001 data segments. 1003 The format of an XFER_ACK message follows in Figure 10. 1005 +-----------------------------+ 1006 | Message Header | 1007 +-----------------------------+ 1008 | Message Flags (U8) | 1009 +-----------------------------+ 1010 | Transfer ID (U64) | 1011 +-----------------------------+ 1012 | Acknowledged length (U64) | 1013 +-----------------------------+ 1015 Figure 10: Format of XFER_ACK Messages 1017 The fields of the XFER_ACK message are: 1019 Message Flags: A one-octet field of single-bit flags, interpreted 1020 according to the descriptions in Table 5. 1022 Transfer ID: A 64-bit unsigned integer identifying the transfer 1023 being acknowledged. 1025 Acknowledged length: A 64-bit unsigned integer indicating the total 1026 number of octets in the transfer which are being acknowledged. 1028 A receiving TCPCL endpoing SHALL send an XFER_ACK message in response 1029 to each received XFER_SEGMENT message. The flags portion of the 1030 XFER_ACK header SHALL be set to match the corresponding DATA_SEGMENT 1031 message being acknowledged. The acknowledged length of each XFER_ACK 1032 contains the sum of the data length fields of all XFER_SEGMENT 1033 messages received so far in the course of the indicated transfer. 1035 For example, suppose the sending node transmits four segments of 1036 bundle data with lengths 100, 200, 500, and 1000, respectively. 1037 After receiving the first segment, the node sends an acknowledgment 1038 of length 100. After the second segment is received, the node sends 1039 an acknowledgment of length 300. The third and fourth 1040 acknowledgments are of length 800 and 1800, respectively. 1042 5.3.5. Transfer Refusal (XFER_REFUSE) 1044 The TCPCL supports an mechanism by which a receiving node can 1045 indicate to the sender that it does not want to receive the 1046 corresponding bundle. To do so, upon receiving a XFER_INIT or 1047 XFER_SEGMENT message, the node MAY transmit a XFER_REFUSE message. 1048 As data segments and acknowledgments MAY cross on the wire, the 1049 bundle that is being refused SHALL be identified by the Transfer ID 1050 of the refusal. 1052 There is no required relation between the Transfer MRU of a TCPCL 1053 node (which is supposed to represent a firm limitation of what the 1054 node will accept) and sending of a XFER_REFUSE message. A 1055 XFER_REFUSE can be used in cases where the agent's bundle storage is 1056 temporarily depleted or somehow constrained. A XFER_REFUSE can also 1057 be used after the bundle header or any bundle data is inspected by an 1058 agent and determined to be unacceptable. 1060 The format of the XFER_REFUSE message is as follows: 1062 +-----------------------------+ 1063 | Message Header | 1064 +-----------------------------+ 1065 | Reason Code (U8) | 1066 +-----------------------------+ 1067 | Transfer ID (U64) | 1068 +-----------------------------+ 1070 Figure 11: Format of XFER_REFUSE Messages 1072 The fields of the XFER_REFUSE message are: 1074 Reason Code: A one-octet refusal reason code interpreted according 1075 to the descriptions in Table 6. 1077 Transfer ID: A 64-bit unsigned integer identifying the transfer 1078 being refused. 1080 +------------+------------------------------------------------------+ 1081 | Name | Semantics | 1082 +------------+------------------------------------------------------+ 1083 | Unknown | Reason for refusal is unknown or not specified. | 1084 | | | 1085 | Completed | The receiver already has the complete bundle. The | 1086 | | sender MAY consider the bundle as completely | 1087 | | received. | 1088 | | | 1089 | No | The receiver's resources are exhausted. The sender | 1090 | Resources | SHOULD apply reactive bundle fragmentation before | 1091 | | retrying. | 1092 | | | 1093 | Retransmit | The receiver has encountered a problem that requires | 1094 | | the bundle to be retransmitted in its entirety. | 1095 +------------+------------------------------------------------------+ 1097 Table 6: XFER_REFUSE Reason Codes 1099 The receiver MUST, for each transfer preceding the one to be refused, 1100 have either acknowledged all XFER_SEGMENTs or refused the bundle 1101 transfer. 1103 The bundle transfer refusal MAY be sent before an entire data segment 1104 is received. If a sender receives a XFER_REFUSE message, the sender 1105 MUST complete the transmission of any partially sent XFER_SEGMENT 1106 message. There is no way to interrupt an individual TCPCL message 1107 partway through sending it. The sender MUST NOT commence 1108 transmission of any further segments of the refused bundle 1109 subsequently. Note, however, that this requirement does not ensure 1110 that a node will not receive another XFER_SEGMENT for the same bundle 1111 after transmitting a XFER_REFUSE message since messages MAY cross on 1112 the wire; if this happens, subsequent segments of the bundle SHOULD 1113 also be refused with a XFER_REFUSE message. 1115 Note: If a bundle transmission is aborted in this way, the receiver 1116 MAY not receive a segment with the 'END' flag set to '1' for the 1117 aborted bundle. The beginning of the next bundle is identified by 1118 the 'START' bit set to '1', indicating the start of a new transfer, 1119 and with a distinct Transfer ID value. 1121 6. Session Termination 1123 This section describes the procedures for ending a TCPCL session. 1125 6.1. Shutdown Message (SHUTDOWN) 1127 To cleanly shut down a session, a SHUTDOWN message MUST be 1128 transmitted by either node at any point following complete 1129 transmission of any other message. A receiving node SHOULD 1130 acknowledge all received data segments before sending a SHUTDOWN 1131 message to end the session. A transmitting node SHALL treat a 1132 SHUTDOWN message received mid-transfer (i.e. before the final 1133 acknowledgement) as a failure of the transfer. 1135 After transmitting a SHUTDOWN message, an node MAY immediately close 1136 the associated TCP connection. Once the SHUTDOWN message is sent, 1137 any further received data on the TCP connection SHOULD be ignored. 1138 Any delay between request to terminate the TCP connection and actual 1139 closing of the connection (a "half-closed" state) MAY be ignored by 1140 the TCPCL node. 1142 The format of the SHUTDOWN message is as follows: 1144 +-----------------------------------+ 1145 | Message Header | 1146 +-----------------------------------+ 1147 | Message Flags (U8) | 1148 +-----------------------------------+ 1149 | Reason Code (optional U8) | 1150 +-----------------------------------+ 1151 | Reconnection Delay (optional U16) | 1152 +-----------------------------------+ 1154 Figure 12: Format of SHUTDOWN Messages 1156 The fields of the SHUTDOWN message are: 1158 Message Flags: A one-octet field of single-bit flags, interpreted 1159 according to the descriptions in Table 7. 1161 Reason Code: A one-octet refusal reason code interpreted according 1162 to the descriptions in Table 8. The Reason Code is present or 1163 absent as indicated by one of the flags. 1165 Reconnection Delay: A 16-bit unsigned integer indicating the desired 1166 delay until further TCPCL sessions to the sending node. The 1167 Reconnection Delay is present or absent as indicated by one of the 1168 flags. 1170 +----------+--------+-----------------------------------------------+ 1171 | Name | Code | Description | 1172 +----------+--------+-----------------------------------------------+ 1173 | D | 0x01 | If bit is set, indicates that a Reconnection | 1174 | | | Delay field is present. | 1175 | | | | 1176 | R | 0x02 | If bit is set, indicates that a Reason Code | 1177 | | | field is present. | 1178 | | | | 1179 | Reserved | others | 1180 +----------+--------+-----------------------------------------------+ 1182 Table 7: SHUTDOWN Flags 1184 It is possible for a node to convey additional information regarding 1185 the reason for session termination. To do so, the node MUST set the 1186 'R' bit in the message flags and transmit a one-octet reason code 1187 immediately following the message header. The specified values of 1188 the reason code are: 1190 +---------------+---------------------------------------------------+ 1191 | Name | Description | 1192 +---------------+---------------------------------------------------+ 1193 | Idle timeout | The session is being closed due to idleness. | 1194 | | | 1195 | Version | The node cannot conform to the specified TCPCL | 1196 | mismatch | protocol version. | 1197 | | | 1198 | Busy | The node is too busy to handle the current | 1199 | | session. | 1200 | | | 1201 | Contact | The node cannot interpret or negotiate contact | 1202 | Failure | header option. | 1203 | | | 1204 | TLS Failure | The node failed to negotiate TLS session and | 1205 | | cannot continue the session. | 1206 | | | 1207 | Resource | The node has run into some resoure limit and | 1208 | Exhaustion | cannot continue the session. | 1209 +---------------+---------------------------------------------------+ 1211 Table 8: SHUTDOWN Reason Codes 1213 It is also possible to convey a requested reconnection delay to 1214 indicate how long the other node MUST wait before attempting session 1215 re-establishment. To do so, the node sets the 'D' bit in the message 1216 flags and then transmits an 16-bit unsigned integer specifying the 1217 requested delay, in seconds, following the message header (and 1218 optionally, the SHUTDOWN reason code). The value 0 SHALL be 1219 interpreted as an infinite delay, i.e., that the connecting node MUST 1220 NOT re-establish the session. In contrast, if the node does not wish 1221 to request a delay, it SHOULD omit the reconnection delay field (and 1222 set the 'D' bit to zero). 1224 A session shutdown MAY occur immediately after TCP connection 1225 establishment or reception of a contact header (and prior to any 1226 further data exchange). This MAY, for example, be used to notify 1227 that the node is currently not able or willing to communicate. 1228 However, a node MUST always send the contact header to its peer 1229 before sending a SHUTDOWN message. 1231 If either node terminates a session prematurely in this manner, it 1232 SHOULD send a SHUTDOWN message and MUST indicate a reason code unless 1233 the incoming connection did not include the magic string. If the 1234 magic string was not present, a node SHOULD close the TCP connection 1235 without sending a SHUTDOWN message. If a node does not want its peer 1236 to reopen a connection immediately, it SHOULD set the 'D' bit in the 1237 flags and include a reconnection delay to indicate when the peer is 1238 allowed to attempt another session setup. 1240 If a session is to be terminated before a protocol message has 1241 completed being sent, then the node MUST NOT transmit the SHUTDOWN 1242 message but still SHOULD close the TCP connection. Each TCPCL 1243 message is contiguous in the octet stream and has no ability to be 1244 cut short and/or preempted by an other message. This is particularly 1245 important when large segment sizes are being transmitted; either 1246 entire XFER_SEGMENT is sent before a SHUTDOWN message or the 1247 connection is simply termiated mid-XFER_SEGMENT. 1249 6.2. Idle Session Shutdown 1251 The protocol includes a provision for clean shutdown of idle 1252 sessions. Determining the length of time to wait before closing idle 1253 sessions, if they are to be closed at all, is an implementation and 1254 configuration matter. 1256 If there is a configured time to close idle links and if no bundle 1257 data (other than KEEPALIVE messages) has been received for at least 1258 that amount of time, then either node MAY terminate the session by 1259 transmitting a SHUTDOWN message indicating the reason code of 'Idle 1260 timeout' (as described in Table 8). 1262 7. Security Considerations 1264 One security consideration for this protocol relates to the fact that 1265 nodes present their endpoint identifier as part of the contact header 1266 exchange. It would be possible for a node to fake this value and 1267 present the identity of a singleton endpoint in which the node is not 1268 a member, essentially masquerading as another DTN node. If this 1269 identifier is used outside of a TLS-secured session or without 1270 further verification as a means to determine which bundles are 1271 transmitted over the session, then the node that has falsified its 1272 identity would be able to obtain bundles that it otherwise would not 1273 have. Therefore, a node SHALL NOT use the EID value of an unsecured 1274 contact header to derive a peer node's identity unless it can 1275 corroborate it via other means. When TCPCL session security is 1276 mandatory, an endpoint SHALL transmit initial unsecured contact 1277 header values indicated in Table 9 in order. These values avoid 1278 unnecessarily leaking endpoing parameters and will be ignored when 1279 secure contact header re-exchange occurs. 1281 +--------------------+---------------------------------------------+ 1282 | Parameter | Value | 1283 +--------------------+---------------------------------------------+ 1284 | Flags | The USE_TLS flag is set. | 1285 | | | 1286 | Keepalive Interval | Zero, indicating no keepalive. | 1287 | | | 1288 | Segment MRU | Zero, indicating all segments are refused. | 1289 | | | 1290 | Transfer MRU | Zero, indicating all transfers are refused. | 1291 | | | 1292 | EID | Empty, indating lack of EID. | 1293 +--------------------+---------------------------------------------+ 1295 Table 9: Recommended Unsecured Contact Header 1297 TCPCL can be used to provide point-to-point transport security, but 1298 does not provide security of data-at-rest and does not guarantee end- 1299 to-end bundle security. The mechanisms defined in [RFC6257] and 1300 [I-D.ietf-dtn-bpsec] are to be used instead. 1302 Even when using TLS to secure the TCPCL session, the actual 1303 ciphersuite negotiated between the TLS peers MAY be insecure. TLS 1304 can be used to perform authentication without data confidentiality, 1305 for example. It is up to security policies within each TCPCL node to 1306 ensure that the negotiated TLS ciphersuite meets transport security 1307 requirements. This is identical behavior to STARTTLS use in 1308 [RFC2595]. 1310 Another consideration for this protocol relates to denial-of-service 1311 attacks. A node MAY send a large amount of data over a TCPCL 1312 session, requiring the receiving node to handle the data, attempt to 1313 stop the flood of data by sending a XFER_REFUSE message, or forcibly 1314 terminate the session. This burden could cause denial of service on 1315 other, well-behaving sessions. There is also nothing to prevent a 1316 malicious node from continually establishing sessions and repeatedly 1317 trying to send copious amounts of bundle data. A listening node MAY 1318 take countermeasures such as ignoring TCP SYN messages, closing TCP 1319 connections as soon as they are established, waiting before sending 1320 the contact header, sending a SHUTDOWN message quickly or with a 1321 delay, etc. 1323 8. IANA Considerations 1325 In this section, registration procedures are as defined in [RFC5226]. 1327 Some of the registries below are created new for TCPCLv4 but share 1328 code values with TCPCLv3. This was done to disambiguate the use of 1329 these values between TCPCLv3 and TCPCLv4 while preserving the 1330 semantics of some values. 1332 8.1. Port Number 1334 Port number 4556 has been previously assigned as the default port for 1335 the TCP convergence layer in [RFC7242]. This assignment is unchanged 1336 by protocol version 4. Each TCPCL node identifies its TCPCL protocol 1337 version in its initial contact (see Section 8.2), so there is no 1338 ambiguity about what protocol is being used. 1340 +------------------------+-------------------------------------+ 1341 | Parameter | Value | 1342 +------------------------+-------------------------------------+ 1343 | Service Name: | dtn-bundle | 1344 | | | 1345 | Transport Protocol(s): | TCP | 1346 | | | 1347 | Assignee: | Simon Perreault | 1348 | | | 1349 | Contact: | Simon Perreault | 1350 | | | 1351 | Description: | DTN Bundle TCP CL Protocol | 1352 | | | 1353 | Reference: | [RFC7242] | 1354 | | | 1355 | Port Number: | 4556 | 1356 +------------------------+-------------------------------------+ 1358 8.2. Protocol Versions 1360 IANA has created, under the "Bundle Protocol" registry, a sub- 1361 registry titled "Bundle Protocol TCP Convergence-Layer Version 1362 Numbers" and initialized it with the following table. The 1363 registration procedure is RFC Required. 1365 +-------+-------------+---------------------+ 1366 | Value | Description | Reference | 1367 +-------+-------------+---------------------+ 1368 | 0 | Reserved | [RFC7242] | 1369 | | | | 1370 | 1 | Reserved | [RFC7242] | 1371 | | | | 1372 | 2 | Reserved | [RFC7242] | 1373 | | | | 1374 | 3 | TCPCL | [RFC7242] | 1375 | | | | 1376 | 4 | TCPCLbis | This specification. | 1377 | | | | 1378 | 5-255 | Unassigned | 1379 +-------+-------------+---------------------+ 1381 8.3. Header Extension Types 1383 EDITOR NOTE: sub-registry to-be-created upon publication of this 1384 specification. 1386 IANA will create, under the "Bundle Protocol" registry, a sub- 1387 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 1388 Header Extension Types" and initialized it with the contents of 1389 Table 10. The registration procedure is RFC Required within the 1390 lower range 0x0001--0x3fff. Values in the range 0x8000--0xffff are 1391 reserved for use on private networks for functions not published to 1392 the IANA. 1394 +----------------+--------------------------+ 1395 | Code | Message Type | 1396 +----------------+--------------------------+ 1397 | 0x0000 | Reserved | 1398 | | | 1399 | 0x0001--0x3fff | Unassigned | 1400 | | | 1401 | 0x8000--0xffff | Private/Experimental Use | 1402 +----------------+--------------------------+ 1404 Table 10: Header Extension Type Codes 1406 8.4. Message Types 1408 EDITOR NOTE: sub-registry to-be-created upon publication of this 1409 specification. 1411 IANA will create, under the "Bundle Protocol" registry, a sub- 1412 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 1413 Message Types" and initialized it with the contents of Table 11. The 1414 registration procedure is RFC Required. 1416 +-----------+--------------+ 1417 | Code | Message Type | 1418 +-----------+--------------+ 1419 | 0x00 | Reserved | 1420 | | | 1421 | 0x01 | XFER_SEGMENT | 1422 | | | 1423 | 0x02 | XFER_ACK | 1424 | | | 1425 | 0x03 | XFER_REFUSE | 1426 | | | 1427 | 0x04 | KEEPALIVE | 1428 | | | 1429 | 0x05 | SHUTDOWN | 1430 | | | 1431 | 0x06 | XFER_INIT | 1432 | | | 1433 | 0x07 | MSG_REJECT | 1434 | | | 1435 | 0x08--0xf | Unassigned | 1436 +-----------+--------------+ 1438 Table 11: Message Type Codes 1440 8.5. XFER_REFUSE Reason Codes 1442 EDITOR NOTE: sub-registry to-be-created upon publication of this 1443 specification. 1445 IANA will create, under the "Bundle Protocol" registry, a sub- 1446 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 1447 XFER_REFUSE Reason Codes" and initialized it with the contents of 1448 Table 12. The registration procedure is RFC Required. 1450 +----------+---------------------------+ 1451 | Code | Refusal Reason | 1452 +----------+---------------------------+ 1453 | 0x0 | Unknown | 1454 | | | 1455 | 0x1 | Completed | 1456 | | | 1457 | 0x2 | No Resources | 1458 | | | 1459 | 0x3 | Retransmit | 1460 | | | 1461 | 0x4--0x7 | Unassigned | 1462 | | | 1463 | 0x8--0xf | Reserved for future usage | 1464 +----------+---------------------------+ 1466 Table 12: XFER_REFUSE Reason Codes 1468 8.6. SHUTDOWN Reason Codes 1470 EDITOR NOTE: sub-registry to-be-created upon publication of this 1471 specification. 1473 IANA will create, under the "Bundle Protocol" registry, a sub- 1474 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 1475 SHUTDOWN Reason Codes" and initialized it with the contents of 1476 Table 13. The registration procedure is RFC Required. 1478 +------------+------------------+ 1479 | Code | Shutdown Reason | 1480 +------------+------------------+ 1481 | 0x00 | Idle timeout | 1482 | | | 1483 | 0x01 | Version mismatch | 1484 | | | 1485 | 0x02 | Busy | 1486 | | | 1487 | 0x03 | Contact Failure | 1488 | | | 1489 | 0x04 | TLS failure | 1490 | | | 1491 | 0x05--0xFF | Unassigned | 1492 +------------+------------------+ 1494 Table 13: SHUTDOWN Reason Codes 1496 8.7. MSG_REJECT Reason Codes 1498 EDITOR NOTE: sub-registry to-be-created upon publication of this 1499 specification. 1501 IANA will create, under the "Bundle Protocol" registry, a sub- 1502 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 1503 MSG_REJECT Reason Codes" and initialized it with the contents of 1504 Table 14. The registration procedure is RFC Required. 1506 +-----------+----------------------+ 1507 | Code | Rejection Reason | 1508 +-----------+----------------------+ 1509 | 0x00 | reserved | 1510 | | | 1511 | 0x01 | Message Type Unknown | 1512 | | | 1513 | 0x02 | Message Unsupported | 1514 | | | 1515 | 0x03 | Message Unexpected | 1516 | | | 1517 | 0x04-0xFF | Unassigned | 1518 +-----------+----------------------+ 1520 Table 14: REJECT Reason Codes 1522 9. Acknowledgments 1524 This memo is based on comments on implementation of [RFC7242] 1525 provided from Scott Burleigh. 1527 10. References 1529 10.1. Normative References 1531 [I-D.ietf-dtn-bpbis] 1532 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 1533 Version 7", draft-ietf-dtn-bpbis-10 (work in progress), 1534 November 2017. 1536 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1537 RFC 793, DOI 10.17487/RFC0793, September 1981, 1538 . 1540 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1541 Communication Layers", STD 3, RFC 1122, 1542 DOI 10.17487/RFC1122, October 1989, 1543 . 1545 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1546 Requirement Levels", BCP 14, RFC 2119, 1547 DOI 10.17487/RFC2119, March 1997, 1548 . 1550 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 1551 Specification", RFC 5050, DOI 10.17487/RFC5050, November 1552 2007, . 1554 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1555 IANA Considerations Section in RFCs", RFC 5226, 1556 DOI 10.17487/RFC5226, May 2008, 1557 . 1559 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1560 (TLS) Protocol Version 1.2", RFC 5246, 1561 DOI 10.17487/RFC5246, August 2008, 1562 . 1564 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1565 "Recommendations for Secure Use of Transport Layer 1566 Security (TLS) and Datagram Transport Layer Security 1567 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1568 2015, . 1570 10.2. Informative References 1572 [I-D.ietf-dtn-bpsec] 1573 Birrane, E. and K. McKeever, "Bundle Protocol Security 1574 Specification", draft-ietf-dtn-bpsec-06 (work in 1575 progress), October 2017. 1577 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1578 RFC 2595, DOI 10.17487/RFC2595, June 1999, 1579 . 1581 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 1582 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 1583 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 1584 April 2007, . 1586 [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, 1587 "Bundle Security Protocol Specification", RFC 6257, 1588 DOI 10.17487/RFC6257, May 2011, 1589 . 1591 [RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant 1592 Networking TCP Convergence-Layer Protocol", RFC 7242, 1593 DOI 10.17487/RFC7242, June 2014, 1594 . 1596 Appendix A. Significant changes from RFC7242 1598 The areas in which changes from [RFC7242] have been made to existing 1599 headers and messages are: 1601 o Changed contact header content to limit number of negotiated 1602 options. 1604 o Added contact option to negotiate maximum segment size (per each 1605 direction). 1607 o Added contact header extension capability. 1609 o Defined new IANA registries for message / type / reason codes to 1610 allow renaming some codes for clarity. 1612 o Expanded Message Header to octet-aligned fields instead of bit- 1613 packing. 1615 o Added a bundle transfer identification number to all bundle- 1616 related messages (XFER_INIT, XFER_SEGMENT, XFER_ACK, XFER_REFUSE). 1618 o Use flags in XFER_ACK to mirror flags from XFER_SEGMENT. 1620 o Removed all uses of SDNV fields and replaced with fixed-bit-length 1621 fields. 1623 The areas in which extensions from [RFC7242] have been made as new 1624 messages and codes are: 1626 o Added contact negotation failure SHUTDOWN reason code. 1628 o Added MSG_REJECT message to indicate an unknown or unhandled 1629 message was received. 1631 o Added TLS session security mechanism. 1633 o Added TLS failure SHUTDOWN reason code. 1635 Authors' Addresses 1637 Brian Sipos 1638 RKF Engineering Solutions, LLC 1639 7500 Old Georgetown Road 1640 Suite 1275 1641 Bethesda, MD 20814-6198 1642 US 1644 Email: BSipos@rkf-eng.com 1646 Michael Demmer 1647 University of California, Berkeley 1648 Computer Science Division 1649 445 Soda Hall 1650 Berkeley, CA 94720-1776 1651 US 1653 Email: demmer@cs.berkeley.edu 1655 Joerg Ott 1656 Aalto University 1657 Department of Communications and Networking 1658 PO Box 13000 1659 Aalto 02015 1660 Finland 1662 Email: jo@netlab.tkk.fi 1664 Simon Perreault 1665 Quebec, QC 1666 Canada 1668 Email: simon@per.reau.lt