idnits 2.17.1 draft-ietf-dtn-tcpclv4-05.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 14, 2017) is 2318 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 359, but not defined == Missing Reference: 'L1' is mentioned on line 347, but not defined == Missing Reference: 'L2' is mentioned on line 347, but not defined == Missing Reference: 'L3' is mentioned on line 353, 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 17, 2018 J. Ott 7 Aalto University 8 S. Perreault 9 December 14, 2017 11 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 12 draft-ietf-dtn-tcpclv4-05 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 17, 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 . . . . . . . . . . . . . . . . 6 65 3.1. TCPCL Session Overview . . . . . . . . . . . . . . . . . 6 66 3.2. Example Message Exchange . . . . . . . . . . . . . . . . 7 67 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . 15 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 Idle Session: A TCPCL session is idle while the only messages being 213 transmitted or received are KEEPALIVE messages. 215 Lively Session: A TCPCL session is lively while any messages are 216 being transmitted or received. 218 Reason Codes: The TCPCL uses numeric codes to encode specific 219 reasons for individual failure/error message types. This limits 220 the expressiveness of TCPCL error encodings, but simplifies the 221 encoding of errors and allows an application policy to attempt 222 recovery from expected 'failure' modes (e.g. if a Session cannot 223 be established with USE_TLS disabled because of a Contact Failure 224 shutdown, a re-attempt can be made with USE_TLS enabled). 226 3. General Protocol Description 228 The service of this protocol is the transmission of DTN bundles via 229 the Transmission Control Protocol (TCP). This document specifies the 230 encapsulation of bundles, procedures for TCP setup and teardown, and 231 a set of messages and node requirements. The general operation of 232 the protocol is as follows. 234 3.1. TCPCL Session Overview 236 First, one node establishes a TCPCL session to the other by 237 initiating a TCP connection in accordance with [RFC0793]. After 238 setup of the TCP connection is complete, an initial contact header is 239 exchanged in both directions to set parameters of the TCPCL session 240 and exchange a singleton endpoint identifier for each node (not the 241 singleton Endpoint Identifier (EID) of any application running on the 242 node) to denote the bundle-layer identity of each DTN node. This is 243 used to assist in routing and forwarding messages (e.g. to prevent 244 loops). 246 Once the TCPCL session is established and configured in this way, 247 bundles can be transferred in either direction. Each transfer is 248 performed by an initialization (XFER_INIT) message followed by one or 249 more logical segments of data within an XFER_SEGMENT message. The 250 choice of the length to use for segments is an implementation matter, 251 but each segment must be no larger than the receiving node's maximum 252 receive unit (MRU) (see the field "Segment MRU" of Section 4.1). The 253 first segment for a bundle MUST set the 'START' flag, and the last 254 one MUST set the 'end' flag in the XFER_SEGMENT message flags. 256 If multiple bundles are transmitted on a single TCPCL connection, 257 they MUST be transmitted consecutively. Interleaving data segments 258 from different bundles is not allowed. Bundle interleaving can be 259 accomplished by fragmentation at the BP layer or by establishing 260 multiple TCPCL sessions. 262 A feature of this protocol is for the receiving node to send 263 acknowledgments as bundle data segments arrive (XFER_ACK). The 264 rationale behind these acknowledgments is to enable the sender node 265 to determine how much of the bundle has been received, so that in 266 case the session is interrupted, it can perform reactive 267 fragmentation to avoid re-sending the already transmitted part of the 268 bundle. For each data segment that is received, the receiving node 269 sends an XFER_ACK message containing the cumulative length of the 270 bundle that has been received. The sending node MAY transmit 271 multiple XFER_SEGMENT messages without necessarily waiting for the 272 corresponding XFER_ACK responses. This enables pipelining of 273 messages on a channel. In addition, there is no explicit flow 274 control on the TCPCL layer. 276 Another feature is that a receiver MAY interrupt the transmission of 277 a bundle at any point in time by replying with a XFER_REFUSE message, 278 which causes the sender to stop transmission of the current bundle, 279 after completing transmission of a partially sent data segment. 280 Note: This enables a cross-layer optimization in that it allows a 281 receiver that detects that it already has received a certain bundle 282 to interrupt transmission as early as possible and thus save 283 transmission capacity for other bundles. 285 For sessions that are idle, a KEEPALIVE message is sent at a 286 negotiated interval. This is used to convey node liveliqness 287 information during otherwise message-less time intervals. 289 Finally, before sessions close, a SHUTDOWN message is sent to the 290 session peer (see Section 6.1). After sending a SHUTDOWN message, 291 the peer can not initiate any further transfers and the session 292 enters a closing-down phase. After receiving a SHUTDOWN message and 293 when no transfers are in-progress (i.e. have pending or 294 unacknowledged segments), the receiving peer can close the session 295 without chance of lost transfers. A SHUTDOWN message can also be 296 used to refuse a session setup by a peer (see Section 4.2). It is an 297 implementation matter to determine whether or not to close a TCPCL 298 session while there are no transfers queued or in-progress. 300 There are specific messages for sending and receiving operations (in 301 addition to session setup/teardown). TCPCL is symmetric, i.e., both 302 sides can start sending data segments in a session, and one side's 303 bundle transfer does not have to complete before the other side can 304 start sending data segments on its own. Hence, the protocol allows 305 for a bi-directional mode of communication. Note that in the case of 306 concurrent bidirectional transmission, acknowledgment segments MAY be 307 interleaved with data segments. 309 3.2. Example Message Exchange 311 The following figure depicts the protocol exchange for a simple 312 session, showing the session establishment and the transmission of a 313 single bundle split into three data segments (of lengths "L1", "L2", 314 and "L3") from Node A to Node B. 316 Note that the sending node MAY transmit multiple XFER_SEGMENT 317 messages without necessarily waiting for the corresponding XFER_ACK 318 responses. This enables pipelining of messages on a channel. 319 Although this example only demonstrates a single bundle transmission, 320 it is also possible to pipeline multiple XFER_SEGMENT messages for 321 different bundles without necessarily waiting for XFER_ACK messages 322 to be returned for each one. However, interleaving data segments 323 from different bundles is not allowed. 325 No errors or rejections are shown in this example. 327 Node A Node B 328 ====== ====== 329 +-------------------------+ +-------------------------+ 330 | Contact Header | -> <- | Contact Header | 331 +-------------------------+ +-------------------------+ 333 +-------------------------+ 334 | XFER_INIT | -> 335 | Transfer ID [I1] | 336 | Total Length [L1] | 337 +-------------------------+ 338 +-------------------------+ 339 | XFER_SEGMENT (start) | -> 340 | Transfer ID [I1] | 341 | Length [L1] | 342 | Bundle Data 0..(L1-1) | 343 +-------------------------+ 344 +-------------------------+ +-------------------------+ 345 | XFER_SEGMENT | -> <- | XFER_ACK (start) | 346 | Transfer ID [I1] | | Transfer ID [I1] | 347 | Length [L2] | | Length [L1] | 348 |Bundle Data L1..(L1+L2-1)| +-------------------------+ 349 +-------------------------+ 350 +-------------------------+ +-------------------------+ 351 | XFER_SEGMENT (end) | -> <- | XFER_ACK | 352 | Transfer ID [I1] | | Transfer ID [I1] | 353 | Length [L3] | | Length [L1+L2] | 354 |Bundle Data | +-------------------------+ 355 | (L1+L2)..(L1+L2+L3-1)| 356 +-------------------------+ 357 +-------------------------+ 358 <- | XFER_ACK (end) | 359 | Transfer ID [I1] | 360 | Length [L1+L2+L3] | 361 +-------------------------+ 363 +-------------------------+ +-------------------------+ 364 | SHUTDOWN | -> <- | SHUTDOWN | 365 +-------------------------+ +-------------------------+ 367 Figure 2: An Example of the Flow of Protocol Messages on a Single TCP 368 Session between Two Nodes (A and B) 370 4. Session Establishment 372 For bundle transmissions to occur using the TCPCL, a TCPCL session 373 MUST first be established between communicating nodes. It is up to 374 the implementation to decide how and when session setup is triggered. 375 For example, some sessions MAY be opened proactively and maintained 376 for as long as is possible given the network conditions, while other 377 sessions MAY be opened only when there is a bundle that is queued for 378 transmission and the routing algorithm selects a certain next-hop 379 node. 381 To establish a TCPCL session, a node MUST first establish a TCP 382 connection with the intended peer node, typically by using the 383 services provided by the operating system. Destination port number 384 4556 has been assigned by IANA as the Registered Port number for the 385 TCP convergence layer. Other destination port numbers MAY be used 386 per local configuration. Determining a peer's destination port 387 number (if different from the registered TCPCL port number) is up to 388 the implementation. Any source port number MAY be used for TCPCL 389 sessions. Typically an operating system assigned number in the TCP 390 Ephemeral range (49152--65535) is used. 392 If the node is unable to establish a TCP connection for any reason, 393 then it is an implementation matter to determine how to handle the 394 connection failure. A node MAY decide to re-attempt to establish the 395 connection. If it does so, it MUST NOT overwhelm its target with 396 repeated connection attempts. Therefore, the node MUST retry the 397 connection setup only after some delay (a 1-second minimum is 398 RECOMMENDED), and it SHOULD use a (binary) exponential backoff 399 mechanism to increase this delay in case of repeated failures. In 400 case a SHUTDOWN message specifying a reconnection delay is received, 401 that delay is used as the initial delay. The default initial delay 402 SHOULD be at least 1 second but SHOULD be configurable since it will 403 be application and network type dependent. 405 The node MAY declare failure after one or more connection attempts 406 and MAY attempt to find an alternate route for bundle data. Such 407 decisions are up to the higher layer (i.e., the BP). 409 Once a TCP connection is established, each node MUST immediately 410 transmit a contact header over the TCP connection. The format of the 411 contact header is described in Section 4.1. 413 Upon receipt of the contact header, both nodes perform the validation 414 and negotiation procedures defined in Section 4.2 416 After receiving the contact header from the other node, either node 417 MAY also refuse the session by sending a SHUTDOWN message. If 418 session setup is refused, a reason MUST be included in the SHUTDOWN 419 message. 421 4.1. Contact Header 423 Once a TCP connection is established, both parties exchange a contact 424 header. This section describes the format of the contact header and 425 the meaning of its fields. 427 The format for the Contact Header is as follows: 429 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 430 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 431 +---------------+---------------+---------------+---------------+ 432 | magic='dtn!' | 433 +---------------+---------------+---------------+---------------+ 434 | Version | Flags | Keepalive Interval | 435 +---------------+---------------+---------------+---------------+ 436 | Segment MRU... | 437 +---------------+---------------+---------------+---------------+ 438 | contd. | 439 +---------------+---------------+---------------+---------------+ 440 | Transfer MRU... | 441 +---------------+---------------+---------------+---------------+ 442 | contd. | 443 +---------------+---------------+---------------+---------------+ 444 | EID Length | EID Data... | 445 +---------------+---------------+---------------+---------------+ 446 | EID Data contd. | 447 +---------------+---------------+---------------+---------------+ 448 | Header Extension Length... | 449 +---------------+---------------+---------------+---------------+ 450 | contd. | 451 +---------------+---------------+---------------+---------------+ 452 | Header Extension Items... | 453 +---------------+---------------+---------------+---------------+ 455 Figure 3: Contact Header Format 457 See Section 4.2 for details on the use of each of these contact 458 header fields. The fields of the contact header are: 460 magic: A four-octet field that always contains the octet sequence 461 0x64 0x74 0x6e 0x21, i.e., the text string "dtn!" in US-ASCII (and 462 UTF-8). 464 Version: A one-octet field value containing the value 4 (current 465 version of the protocol). 467 Flags: A one-octet field of single-bit flags, interpreted according 468 to the descriptions in Table 1. 470 Keepalive Interval: A 16-bit unsigned integer indicating the 471 interval, in seconds, between any subsequent messages being 472 transmitted by the peer. The peer receiving this contact header 473 uses this interval to determine how long to wait after any last- 474 message transmission and a necessary subsequent KEEPALIVE message 475 transmission. 477 Segment MRU: A 64-bit unsigned integer indicating the largest 478 allowable single-segment data payload size to be received in this 479 session. Any XFER_SEGMENT sent to this peer SHALL have a data 480 payload no longer than the peer's Segment MRU. The two nodes of a 481 single session MAY have different Segment MRUs, and no relation 482 between the two is required. 484 Transfer MRU: A 64-bit unsigned integer indicating the largest 485 allowable total-bundle data size to be received in this session. 486 Any bundle transfer sent to this peer SHALL have a Total bundle 487 data payload no longer than the peer's Transfer MRU. This value 488 can be used to perform proactive bundle fragmentation. The two 489 nodes of a single session MAY have different Transfer MRUs, and no 490 relation between the two is required. 492 EID Length and EID Data: Together these fields represent a variable- 493 length text string. The EID Length is a 16-bit unsigned integer 494 indicating the number of octets of EID Data to follow. A zero EID 495 Length SHALL be used to indicate the lack of EID rather than a 496 truly empty EID. This case allows an node to avoid exposing EID 497 information on an untrusted network. A non-zero-length EID Data 498 SHALL contain the UTF-8 encoded EID of some singleton endpoint in 499 which the sending node is a member, in the canonical format of 500 :. This EID encoding is 501 consistent with [I-D.ietf-dtn-bpbis]. 503 Header Extension Length Header Extension Items: Together these 504 fields represent protocol extension data not defined by this 505 specification. The Header Extension Length is the total number of 506 octets to follow which are used to encode the Header Extension 507 Item list. The encoding of each Header Extension Item is 508 identical form as described in Section 4.1.1. 510 +----------+--------+-----------------------------------------------+ 511 | Name | Code | Description | 512 +----------+--------+-----------------------------------------------+ 513 | CAN_TLS | 0x01 | If bit is set, indicates that the sending | 514 | | | peer is capable of TLS security. | 515 | | | | 516 | Reserved | others | 517 +----------+--------+-----------------------------------------------+ 519 Table 1: Contact Header Flags 521 4.1.1. Header Extension Items 523 Each of the Header Extension items SHALL be encoded in an identical 524 Type-Length-Value (TLV) container form as indicated in Figure 4. The 525 fields of the header extension item are: 527 Flags: A one-octet field containing generic bit flags about the 528 item, which are listed in Table 2. If a TCPCL node receives an 529 extension item with an unknown Item Type and the CRITICAL flag 530 set, the node SHALL close the TCPCL session with SHUTDOWN reason 531 code of "Contact Failure". If the CRITICAL flag is not set, an 532 node SHALL skip over and ignore any item with an unknown Item 533 Type. 535 Item Type: A 16-bit unsigned integer field containing the type of 536 the extension item. This specification does not define any 537 extension types directly, but does allocate an IANA registry for 538 such codes (see Section 8.3). 540 Item Length: A 32-bit unsigned integer field containing the number 541 of Item Value octets to follow. 543 Item Value: A variable-length data field which is interpreted 544 according to the associated Item Type. This specification places 545 no restrictions on an extensions use of available Item Value data. 546 Extension specification SHOULD avoid the use of large data 547 exchanges within the TCPCLv4 contact header as no bundle transfers 548 can begin until the a full contact exchange and negotiation has 549 been completed. 551 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 552 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 553 +---------------+---------------+---------------+---------------+ 554 | Item Flags | Item Type | Item Length...| 555 +---------------+---------------+---------------+---------------+ 556 | length contd. | Item Value... | 557 +---------------+---------------+---------------+---------------+ 558 | value contd. | 559 +---------------+---------------+---------------+---------------+ 561 Figure 4: Header Extention Item Format 563 +----------+--------+-----------------------------------------------+ 564 | Name | Code | Description | 565 +----------+--------+-----------------------------------------------+ 566 | CRITICAL | 0x01 | If bit is set, indicates that the receiving | 567 | | | peer must handle the extension item. | 568 | | | | 569 | Reserved | others | 570 +----------+--------+-----------------------------------------------+ 572 Table 2: Header Extension Item Flags 574 4.2. Validation and Parameter Negotiation 576 Upon reception of the contact header, each node follows the following 577 procedures to ensure the validity of the TCPCL session and to 578 negotiate values for the session parameters. 580 If the magic string is not present or is not valid, the connection 581 MUST be terminated. The intent of the magic string is to provide 582 some protection against an inadvertent TCP connection by a different 583 protocol than the one described in this document. To prevent a flood 584 of repeated connections from a misconfigured application, a node MAY 585 elect to hold an invalid connection open and idle for some time 586 before closing it. 588 A connecting TCPCL node SHALL send the highest TCPCL protocol version 589 on a first session attempt for a TCPCL peer. If a connecting node 590 receives a SHUTDOWN message with reason of "Version Mismatch", that 591 node MAY attempt further TCPCL sessions with the peer using earlier 592 protocol version numbers in decreasing order. Managing multi-TCPCL- 593 session state such as this is an implementation matter. 595 If a node receives a contact header containing a version that is 596 greater than the current version of the protocol that the node 597 implements, then the node SHALL shutdown the session with a reason 598 code of "Version mismatch". If a node receives a contact header with 599 a version that is lower than the version of the protocol that the 600 node implements, the node MAY either terminate the session (with a 601 reason code of "Version mismatch"). Otherwise, the node MAY adapt 602 its operation to conform to the older version of the protocol. The 603 decision of version fall-back is an implementation matter. 605 A node calculates the parameters for a TCPCL session by negotiating 606 the values from its own preferences (conveyed by the contact header 607 it sent to the peer) with the preferences of the peer node (expressed 608 in the contact header that it received from the peer). The 609 negotiated parameters defined by this specification are described in 610 the following paragraphs. 612 Session Keepalive: Negotiation of the Session Keepalive parameter is 613 performed by taking the minimum of this two contact headers' 614 Keepalive Interval. If the negotiated Session Keepalive is zero 615 (i.e. one or both contact headers contains a zero Keepalive 616 Interval), then the keepalive feature (described in Section 5.2.1) 617 is disabled. There is no logical minimum value for the keepalive 618 interval, but when used for many sessions on an open, shared 619 network a short interval could lead to excessive traffic. For 620 shared network use, nodes SHOULD choose a keepalive interval no 621 shorter than 30 seconds. There is no logical maximum value for 622 the keepalive interval, but an idle TCP connection is liable for 623 closure by the host operating system if the keepalive time is 624 longer than tens-of-minutes. Nodes SHOULD choose a keepalive 625 interval no longer than 10 minutes (600 seconds). 627 Enable TLS: Negotiation of the Enable TLS parameter is performed by 628 taking the logical AND of the two contact headers' CAN_TLS flags. 629 If the negotiated Enable TLS value is true then TLS negotiation 630 feature (described in Section 4.3) begins immediately following 631 the contact header exchange. The security policy on either node 632 MAY forbid the establishment of a TCPCL session for any Enable TLS 633 result (or for any combination of local or peer CAN_TLS flag), in 634 which case the node SHALL shutdown the session with a reason code 635 of "Contact Failure". For example, one node may disallow TCPCL 636 sessions without TLS, while a second node may disallow sessions 637 with TLS. Also note that this Contact Failure (of the header 638 negotiation) is different than a TLS Failure (after an agreed-upon 639 Enable TLS state). 641 Once this process of parameter negotiation is completed (which 642 includes a possible completed TLS handshake of the connection to use 643 TLS), this protocol defines no additional mechanism to change the 644 parameters of an established session; to effect such a change, the 645 TCPCL session MUST be terminated and a new session established. 647 4.3. Session Security 649 This version of the TCPCL supports establishing a Transport Layer 650 Security (TLS) session within an existing TCP connection. 651 Negotiation of whether or not to initiate TLS within a TCPCL session 652 is part of the contact header as described in Section 4.2. The TLS 653 handshake, if it occurs, is considered to be part of the contact 654 negotiation before the TCPCL session itself is established. 655 Specifics about sensitive data exposure are discussed in Section 7. 657 When TLS is used within the TCPCL it affects the entire session. By 658 convention, this protocol uses the node which initiated the 659 underlying TCP connection as the "client" role of the TLS handshake 660 request. Once a TLS session is established within TCPCL, there is no 661 mechanism provided to end the TLS session and downgrade the session. 662 If a non-TLS session is desired after a TLS session is started then 663 the entire TCPCL session MUST be shutdown first. 665 After negotiating an Enable TLS parameter of true, and before any 666 other TCPCL messages are sent within the session, the session nodes 667 SHALL begin a TLS handshake in accordance with [RFC5246]. The 668 parameters within each TLS nqion are implementation dependent but any 669 TCPCL node SHOULD follow all recommended best practices of [RFC7525]. 671 4.3.1. TLS Handshake Result 673 If a TLS handshake cannot negotiate a TLS session, both nodes of the 674 TCPCL session SHALL cause a TCPCL shutdown with reason "TLS Failure". 676 After a TLS session is successfully established, both TCPCL nodes 677 SHALL re-exchange TCPCL Contact Header messages. Any information 678 cached from the prior Contact Header exchange SHALL be discarded. 679 This re-exchange avoids man-in-the-middle attack in identical fashion 680 to [RFC2595]. Each re-exchange header CAN_TLS flag SHALL be 681 identical to the original header CAN_TLS flag from the same node. 682 The CAN_TLS logic (TLS negotiation) SHALL NOT apply during header re- 683 exchange. This reinforces the fact that there is no TLS downgrade 684 mechanism. 686 4.3.2. Example TLS Initiation 688 A summary of a typical CAN_TLS usage is shown in the sequence in 689 Figure 5 below. 691 Node A Node B 692 ====== ====== 694 +-------------------------+ 695 | Open TCP Connnection | -> 696 +-------------------------+ +-------------------------+ 697 <- | Accept Connection | 698 +-------------------------+ 700 +-------------------------+ +-------------------------+ 701 | Contact Header | -> <- | Contact Header | 702 +-------------------------+ +-------------------------+ 704 +-------------------------+ +-------------------------+ 705 | TLS Negotiation | -> <- | TLS Negotiation | 706 | (as client) | | (as server) | 707 +-------------------------+ +-------------------------+ 709 +-------------------------+ +-------------------------+ 710 | Contact Header | -> <- | Contact Header | 711 +-------------------------+ +-------------------------+ 713 ... secured TCPCL messaging ... 715 +-------------------------+ +-------------------------+ 716 | SHUTDOWN | -> <- | SHUTDOWN | 717 +-------------------------+ +-------------------------+ 719 Figure 5: A simple visual example of TCPCL TLS Establishment between 720 two nodes 722 5. Established Session Operation 724 This section describes the protocol operation for the duration of an 725 established session, including the mechanism for transmitting bundles 726 over the session. 728 5.1. Message Type Codes 730 After the initial exchange of a contact header, all messages 731 transmitted over the session are identified by a one-octet header 732 with the following structure: 734 0 1 2 3 4 5 6 7 735 +---------------+ 736 | Message Type | 737 +---------------+ 739 Figure 6: Format of the Message Header 741 The message header fields are as follows: 743 Message Type: Indicates the type of the message as per Table 3 744 below. Encoded values are listed in Section 8.4. 746 +--------------+----------------------------------------------------+ 747 | Type | Description | 748 +--------------+----------------------------------------------------+ 749 | XFER_INIT | Contains the length (in octets) of the next | 750 | | transfer, as described in Section 5.3.2. | 751 | | | 752 | XFER_SEGMENT | Indicates the transmission of a segment of bundle | 753 | | data, as described in Section 5.3.3. | 754 | | | 755 | XFER_ACK | Acknowledges reception of a data segment, as | 756 | | described in Section 5.3.4. | 757 | | | 758 | XFER_REFUSE | Indicates that the transmission of the current | 759 | | bundle SHALL be stopped, as described in Section | 760 | | 5.3.5. | 761 | | | 762 | KEEPALIVE | Used to keep TCPCL session active, as described in | 763 | | Section 5.2.1. | 764 | | | 765 | SHUTDOWN | Indicates that one of the nodes participating in | 766 | | the session wishes to cleanly terminate the | 767 | | session, as described in Section 6. | 768 | | | 769 | MSG_REJECT | Contains a TCPCL message rejection, as described | 770 | | in Section 5.2.2. | 771 +--------------+----------------------------------------------------+ 773 Table 3: TCPCL Message Types 775 5.2. Upkeep and Status Messages 777 5.2.1. Session Upkeep (KEEPALIVE) 779 The protocol includes a provision for transmission of KEEPALIVE 780 messages over the TCPCL session to help determine if the underlying 781 TCP connection has been disrupted. 783 As described in Section 4.1, one of the parameters in the contact 784 header is the Keepalive Interval. Both sides populate this field 785 with their requested intervals (in seconds) between KEEPALIVE 786 messages. 788 The format of a KEEPALIVE message is a one-octet message type code of 789 KEEPALIVE (as described in Table 3) with no additional data. Both 790 sides SHOULD send a KEEPALIVE message whenever the negotiated 791 interval has elapsed with no transmission of any message (KEEPALIVE 792 or other). 794 If no message (KEEPALIVE or other) has been received for at least 795 twice the Keepalive Interval, then either party MAY terminate the 796 session by transmitting a one-octet SHUTDOWN message (as described in 797 Section 6.1) with reason code "Idle Timeout", and by closing the 798 session. 800 Note: The Keepalive Interval SHOULD not be chosen too short as TCP 801 retransmissions MAY occur in case of packet loss. Those will have to 802 be triggered by a timeout (TCP retransmission timeout (RTO)), which 803 is dependent on the measured RTT for the TCP connection so that 804 KEEPALIVE messages MAY experience noticeable latency. 806 5.2.2. Message Rejection (MSG_REJECT) 808 If a TCPCL node receives a message which is unknown to it (possibly 809 due to an unhandled protocol mismatch) or is inappropriate for the 810 current session state (e.g. a KEEPALIVE message received after 811 contact header negotiation has disabled that feature), there is a 812 protocol-level message to signal this condition in the form of a 813 MSG_REJECT reply. 815 The format of a MSG_REJECT message follows: 817 +-----------------------------+ 818 | Message Header | 819 +-----------------------------+ 820 | Reason Code (U8) | 821 +-----------------------------+ 822 | Rejected Message Header | 823 +-----------------------------+ 825 Figure 7: Format of MSG_REJECT Messages 827 The fields of the MSG_REJECT message are: 829 Reason Code: A one-octet refusal reason code interpreted according 830 to the descriptions in Table 4. 832 Rejected Message Header: The Rejected Message Header is a copy of 833 the Message Header to which the MSG_REJECT message is sent as a 834 response. 836 +-------------+------+----------------------------------------------+ 837 | Name | Code | Description | 838 +-------------+------+----------------------------------------------+ 839 | Message | 0x01 | A message was received with a Message Type | 840 | Type | | code unknown to the TCPCL node. | 841 | Unknown | | | 842 | | | | 843 | Message | 0x02 | A message was received but the TCPCL node | 844 | Unsupported | | cannot comply with the message contents. | 845 | | | | 846 | Message | 0x03 | A message was received while the session is | 847 | Unexpected | | in a state in which the message is not | 848 | | | expected. | 849 +-------------+------+----------------------------------------------+ 851 Table 4: MSG_REJECT Reason Codes 853 5.3. Bundle Transfer 855 All of the message in this section are directly associated with 856 transferring a bundle between TCPCL nodes. 858 A single TCPCL transfer results in a bundle (handled by the 859 convergence layer as opaque data) being exchanged from one node to 860 the other. In TCPCL a transfer is accomplished by dividing a single 861 bundle up into "segments" based on the receiving-side Segment MRU 862 (see Section 4.1). 864 A single transfer (and by extension a single segment) SHALL NOT 865 contain data of more than a single bundle. This requirement is 866 imposed on the agent using the TCPCL rather than TCPCL itself. 868 5.3.1. Bundle Transfer ID 870 Each of the bundle transfer messages contains a Transfer ID number 871 which is used to correlate messages originating from sender and 872 receiver of a bundle. A Transfer ID does not attempt to address 873 uniqueness of the bundle data itself and has no relation to concepts 874 such as bundle fragmentation. Each invocation of TCPCL by the bundle 875 protocol agent, requesting transmission of a bundle (fragmentary or 876 otherwise), results in the initiation of a single TCPCL transfer. 877 Each transfer entails the sending of a XFER_INIT message and some 878 number of XFER_SEGMENT and XFER_ACK messages; all are correlated by 879 the same Transfer ID. 881 Transfer IDs from each node SHALL be unique within a single TCPCL 882 session. The initial Transfer ID from each node SHALL have value 883 zero. Subsequent Transfer ID values SHALL be incremented from the 884 prior Transfer ID value by one. Upon exhaustion of the entire 64-bit 885 Transfer ID space, the sending node SHALL terminate the session with 886 SHUTDOWN reason code "Resource Exhaustion". 888 For bidirectional bundle transfers, a TCPCL node SHOULD NOT rely on 889 any relation between Transfer IDs originating from each side of the 890 TCPCL session. 892 5.3.2. Transfer Initialization (XFER_INIT) 894 The XFER_INIT message contains the total length, in octets, of the 895 bundle data in the associated transfer. The total length is 896 formatted as a 64-bit unsigned integer. 898 The purpose of the XFER_INIT message is to allow nodes to 899 preemptively refuse bundles that would exceed their resources or to 900 prepare storage on the receiving node for the upcoming bundle data. 901 See Section 5.3.5 for details on when refusal based on XFER_INIT 902 content is acceptable. 904 The Total Bundle Length field within a XFER_INIT message SHALL be 905 treated as authoritative by the receiver. If, for whatever reason, 906 the actual total length of bundle data received differs from the 907 value indicated by the XFER_INIT message, the receiver SHOULD treat 908 the transmitted data as invalid. 910 The format of the XFER_INIT message is as follows: 912 +-----------------------------+ 913 | Message Header | 914 +-----------------------------+ 915 | Transfer ID (U64) | 916 +-----------------------------+ 917 | Total bundle length (U64) | 918 +-----------------------------+ 920 Figure 8: Format of XFER_INIT Messages 922 The fields of the XFER_INIT message are: 924 Transfer ID: A 64-bit unsigned integer identifying the transfer 925 about to begin. 927 Total bundle length: A 64-bit unsigned integer indicating the size 928 of the data-to-be-transferred. 930 An XFER_INIT message SHALL be sent immediately before transmission of 931 any XFER_SEGMENT messages for each Transfer ID. XFER_INIT messages 932 MUST NOT be sent unless the next XFER_SEGMENT message has the 'START' 933 bit set to "1" (i.e., just before the start of a new transfer). 935 A receiver MAY send a BUNDLE_REFUSE message as soon as it receives a 936 XFER_INIT message without waiting for the next XFER_SEGMENT message. 937 The sender MUST be prepared for this and MUST associate the refusal 938 with the correct bundle via the Transfer ID fields. 940 5.3.3. Data Transmission (XFER_SEGMENT) 942 Each bundle is transmitted in one or more data segments. The format 943 of a XFER_SEGMENT message follows in Figure 9. 945 +------------------------------+ 946 | Message Header | 947 +------------------------------+ 948 | Message Flags (U8) | 949 +------------------------------+ 950 | Transfer ID (U64) | 951 +------------------------------+ 952 | Data length (U64) | 953 +------------------------------+ 954 | Data contents (octet string) | 955 +------------------------------+ 957 Figure 9: Format of XFER_SEGMENT Messages 959 The fields of the XFER_SEGMENT message are: 961 Message Flags: A one-octet field of single-bit flags, interpreted 962 according to the descriptions in Table 5. 964 Transfer ID: A 64-bit unsigned integer identifying the transfer 965 being made. 967 Data length: A 64-bit unsigned integer indicating the number of 968 octets in the Data contents to follow. 970 Data contents: The variable-length data payload of the message. 972 +----------+--------+-----------------------------------------------+ 973 | Name | Code | Description | 974 +----------+--------+-----------------------------------------------+ 975 | END | 0x01 | If bit is set, indicates that this is the | 976 | | | last segment of the transfer. | 977 | | | | 978 | START | 0x02 | If bit is set, indicates that this is the | 979 | | | first segment of the transfer. | 980 | | | | 981 | Reserved | others | 982 +----------+--------+-----------------------------------------------+ 984 Table 5: XFER_SEGMENT Flags 986 The flags portion of the message contains two optional values in the 987 two low-order bits, denoted 'START' and 'END' in Table 5. The 988 'START' bit MUST be set to one if it precedes the transmission of the 989 first segment of a transfer. The 'END' bit MUST be set to one when 990 transmitting the last segment of a transfer. In the case where an 991 entire transfer is accomplished in a single segment, both the 'START' 992 and 'END' bits MUST be set to one. 994 Once a transfer of a bundle has commenced, the node MUST only send 995 segments containing sequential portions of that bundle until it sends 996 a segment with the 'END' bit set. No interleaving of multiple 997 transfers from the same node is possible within a single TCPCL 998 session. Simultaneous transfers between two nodes MAY be achieved 999 using multiple TCPCL sessions. 1001 5.3.4. Data Acknowledgments (XFER_ACK) 1003 Although the TCP transport provides reliable transfer of data between 1004 transport peers, the typical BSD sockets interface provides no means 1005 to inform a sending application of when the receiving application has 1006 processed some amount of transmitted data. Thus, after transmitting 1007 some data, a Bundle Protocol agent needs an additional mechanism to 1008 determine whether the receiving agent has successfully received the 1009 segment. To this end, the TCPCL protocol provides feedback messaging 1010 whereby a receiving node transmits acknowledgments of reception of 1011 data segments. 1013 The format of an XFER_ACK message follows in Figure 10. 1015 +-----------------------------+ 1016 | Message Header | 1017 +-----------------------------+ 1018 | Message Flags (U8) | 1019 +-----------------------------+ 1020 | Transfer ID (U64) | 1021 +-----------------------------+ 1022 | Acknowledged length (U64) | 1023 +-----------------------------+ 1025 Figure 10: Format of XFER_ACK Messages 1027 The fields of the XFER_ACK message are: 1029 Message Flags: A one-octet field of single-bit flags, interpreted 1030 according to the descriptions in Table 5. 1032 Transfer ID: A 64-bit unsigned integer identifying the transfer 1033 being acknowledged. 1035 Acknowledged length: A 64-bit unsigned integer indicating the total 1036 number of octets in the transfer which are being acknowledged. 1038 A receiving TCPCL endpoing SHALL send an XFER_ACK message in response 1039 to each received XFER_SEGMENT message. The flags portion of the 1040 XFER_ACK header SHALL be set to match the corresponding DATA_SEGMENT 1041 message being acknowledged. The acknowledged length of each XFER_ACK 1042 contains the sum of the data length fields of all XFER_SEGMENT 1043 messages received so far in the course of the indicated transfer. 1045 For example, suppose the sending node transmits four segments of 1046 bundle data with lengths 100, 200, 500, and 1000, respectively. 1047 After receiving the first segment, the node sends an acknowledgment 1048 of length 100. After the second segment is received, the node sends 1049 an acknowledgment of length 300. The third and fourth 1050 acknowledgments are of length 800 and 1800, respectively. 1052 5.3.5. Transfer Refusal (XFER_REFUSE) 1054 The TCPCL supports an mechanism by which a receiving node can 1055 indicate to the sender that it does not want to receive the 1056 corresponding bundle. To do so, upon receiving a XFER_INIT or 1057 XFER_SEGMENT message, the node MAY transmit a XFER_REFUSE message. 1058 As data segments and acknowledgments MAY cross on the wire, the 1059 bundle that is being refused SHALL be identified by the Transfer ID 1060 of the refusal. 1062 There is no required relation between the Transfer MRU of a TCPCL 1063 node (which is supposed to represent a firm limitation of what the 1064 node will accept) and sending of a XFER_REFUSE message. A 1065 XFER_REFUSE can be used in cases where the agent's bundle storage is 1066 temporarily depleted or somehow constrained. A XFER_REFUSE can also 1067 be used after the bundle header or any bundle data is inspected by an 1068 agent and determined to be unacceptable. 1070 The format of the XFER_REFUSE message is as follows: 1072 +-----------------------------+ 1073 | Message Header | 1074 +-----------------------------+ 1075 | Reason Code (U8) | 1076 +-----------------------------+ 1077 | Transfer ID (U64) | 1078 +-----------------------------+ 1080 Figure 11: Format of XFER_REFUSE Messages 1082 The fields of the XFER_REFUSE message are: 1084 Reason Code: A one-octet refusal reason code interpreted according 1085 to the descriptions in Table 6. 1087 Transfer ID: A 64-bit unsigned integer identifying the transfer 1088 being refused. 1090 +------------+------------------------------------------------------+ 1091 | Name | Semantics | 1092 +------------+------------------------------------------------------+ 1093 | Unknown | Reason for refusal is unknown or not specified. | 1094 | | | 1095 | Completed | The receiver already has the complete bundle. The | 1096 | | sender MAY consider the bundle as completely | 1097 | | received. | 1098 | | | 1099 | No | The receiver's resources are exhausted. The sender | 1100 | Resources | SHOULD apply reactive bundle fragmentation before | 1101 | | retrying. | 1102 | | | 1103 | Retransmit | The receiver has encountered a problem that requires | 1104 | | the bundle to be retransmitted in its entirety. | 1105 +------------+------------------------------------------------------+ 1107 Table 6: XFER_REFUSE Reason Codes 1109 The receiver MUST, for each transfer preceding the one to be refused, 1110 have either acknowledged all XFER_SEGMENTs or refused the bundle 1111 transfer. 1113 The bundle transfer refusal MAY be sent before an entire data segment 1114 is received. If a sender receives a XFER_REFUSE message, the sender 1115 MUST complete the transmission of any partially sent XFER_SEGMENT 1116 message. There is no way to interrupt an individual TCPCL message 1117 partway through sending it. The sender MUST NOT commence 1118 transmission of any further segments of the refused bundle 1119 subsequently. Note, however, that this requirement does not ensure 1120 that a node will not receive another XFER_SEGMENT for the same bundle 1121 after transmitting a XFER_REFUSE message since messages MAY cross on 1122 the wire; if this happens, subsequent segments of the bundle SHOULD 1123 also be refused with a XFER_REFUSE message. 1125 Note: If a bundle transmission is aborted in this way, the receiver 1126 MAY not receive a segment with the 'END' flag set to '1' for the 1127 aborted bundle. The beginning of the next bundle is identified by 1128 the 'START' bit set to '1', indicating the start of a new transfer, 1129 and with a distinct Transfer ID value. 1131 6. Session Termination 1133 This section describes the procedures for ending a TCPCL session. 1135 6.1. Shutdown Message (SHUTDOWN) 1137 To cleanly shut down a session, a SHUTDOWN message MUST be 1138 transmitted by either node at any point following complete 1139 transmission of any other message. After sending a SHUTDOWN message, 1140 the sender of the message MAY send further acknowledgments (XFER_ACK 1141 or XFER_REFUSE) but no further data messages (XFER_INIT or 1142 XFER_SEGMENT). A receiving node SHOULD acknowledge all received data 1143 segments before sending a SHUTDOWN message to end the session. A 1144 transmitting node SHALL treat a SHUTDOWN message received mid- 1145 transfer (i.e. before the final acknowledgment) as a failure of the 1146 transfer. 1148 After transmitting a SHUTDOWN message, an node MAY immediately close 1149 the associated TCP connection. Once the SHUTDOWN message is sent, 1150 any further received data on the TCP connection SHOULD be ignored. 1151 Any delay between request to terminate the TCP connection and actual 1152 closing of the connection (a "half-closed" state) MAY be ignored by 1153 the TCPCL node. 1155 The format of the SHUTDOWN message is as follows: 1157 +-----------------------------------+ 1158 | Message Header | 1159 +-----------------------------------+ 1160 | Message Flags (U8) | 1161 +-----------------------------------+ 1162 | Reason Code (optional U8) | 1163 +-----------------------------------+ 1164 | Reconnection Delay (optional U16) | 1165 +-----------------------------------+ 1167 Figure 12: Format of SHUTDOWN Messages 1169 The fields of the SHUTDOWN message are: 1171 Message Flags: A one-octet field of single-bit flags, interpreted 1172 according to the descriptions in Table 7. 1174 Reason Code: A one-octet refusal reason code interpreted according 1175 to the descriptions in Table 8. The Reason Code is present or 1176 absent as indicated by one of the flags. 1178 Reconnection Delay: A 16-bit unsigned integer indicating the desired 1179 delay until further TCPCL sessions to the sending node. The 1180 Reconnection Delay is present or absent as indicated by one of the 1181 flags. 1183 +----------+--------+-----------------------------------------------+ 1184 | Name | Code | Description | 1185 +----------+--------+-----------------------------------------------+ 1186 | D | 0x01 | If bit is set, indicates that a Reconnection | 1187 | | | Delay field is present. | 1188 | | | | 1189 | R | 0x02 | If bit is set, indicates that a Reason Code | 1190 | | | field is present. | 1191 | | | | 1192 | Reserved | others | 1193 +----------+--------+-----------------------------------------------+ 1195 Table 7: SHUTDOWN Flags 1197 It is possible for a node to convey additional information regarding 1198 the reason for session termination. To do so, the node MUST set the 1199 'R' bit in the message flags and transmit a one-octet reason code 1200 immediately following the message header. The specified values of 1201 the reason code are: 1203 +---------------+---------------------------------------------------+ 1204 | Name | Description | 1205 +---------------+---------------------------------------------------+ 1206 | Idle timeout | The session is being closed due to idleness. | 1207 | | | 1208 | Version | The node cannot conform to the specified TCPCL | 1209 | mismatch | protocol version. | 1210 | | | 1211 | Busy | The node is too busy to handle the current | 1212 | | session. | 1213 | | | 1214 | Contact | The node cannot interpret or negotiate contact | 1215 | Failure | header option. | 1216 | | | 1217 | TLS Failure | The node failed to negotiate TLS session and | 1218 | | cannot continue the session. | 1219 | | | 1220 | Resource | The node has run into some resource limit and | 1221 | Exhaustion | cannot continue the session. | 1222 +---------------+---------------------------------------------------+ 1224 Table 8: SHUTDOWN Reason Codes 1226 It is also possible to convey a requested reconnection delay to 1227 indicate how long the other node MUST wait before attempting session 1228 re-establishment. To do so, the node sets the 'D' bit in the message 1229 flags and then transmits an 16-bit unsigned integer specifying the 1230 requested delay, in seconds, following the message header (and 1231 optionally, the SHUTDOWN reason code). The value 0 SHALL be 1232 interpreted as an infinite delay, i.e., that the connecting node MUST 1233 NOT re-establish the session. In contrast, if the node does not wish 1234 to request a delay, it SHOULD omit the reconnection delay field (and 1235 set the 'D' bit to zero). 1237 A session shutdown MAY occur immediately after TCP connection 1238 establishment or reception of a contact header (and prior to any 1239 further data exchange). This MAY, for example, be used to notify 1240 that the node is currently not able or willing to communicate. 1241 However, a node MUST always send the contact header to its peer 1242 before sending a SHUTDOWN message. 1244 If either node terminates a session prematurely in this manner, it 1245 SHOULD send a SHUTDOWN message and MUST indicate a reason code unless 1246 the incoming connection did not include the magic string. If the 1247 magic string was not present, a node SHOULD close the TCP connection 1248 without sending a SHUTDOWN message. If a node does not want its peer 1249 to reopen a connection immediately, it SHOULD set the 'D' bit in the 1250 flags and include a reconnection delay to indicate when the peer is 1251 allowed to attempt another session setup. 1253 If a session is to be terminated before a protocol message has 1254 completed being sent, then the node MUST NOT transmit the SHUTDOWN 1255 message but still SHOULD close the TCP connection. Each TCPCL 1256 message is contiguous in the octet stream and has no ability to be 1257 cut short and/or preempted by an other message. This is particularly 1258 important when large segment sizes are being transmitted; either 1259 entire XFER_SEGMENT is sent before a SHUTDOWN message or the 1260 connection is simply terminated mid-XFER_SEGMENT. 1262 6.2. Idle Session Shutdown 1264 The protocol includes a provision for clean shutdown of idle 1265 sessions. Determining the length of time to wait before closing idle 1266 sessions, if they are to be closed at all, is an implementation and 1267 configuration matter. 1269 If there is a configured time to close idle links and if no TCPCL 1270 messages (other than KEEPALIVE messages) has been received for at 1271 least that amount of time, then either node MAY terminate the session 1272 by transmitting a SHUTDOWN message indicating the reason code of 1273 'Idle timeout' (as described in Table 8). 1275 7. Security Considerations 1277 One security consideration for this protocol relates to the fact that 1278 nodes present their endpoint identifier as part of the contact header 1279 exchange. It would be possible for a node to fake this value and 1280 present the identity of a singleton endpoint in which the node is not 1281 a member, essentially masquerading as another DTN node. If this 1282 identifier is used outside of a TLS-secured session or without 1283 further verification as a means to determine which bundles are 1284 transmitted over the session, then the node that has falsified its 1285 identity would be able to obtain bundles that it otherwise would not 1286 have. Therefore, a node SHALL NOT use the EID value of an unsecured 1287 contact header to derive a peer node's identity unless it can 1288 corroborate it via other means. When TCPCL session security mandated 1289 by a TCPCL peer, that peer SHALL transmit initial unsecured contact 1290 header values indicated in Table 9 in order. These values avoid 1291 unnecessarily leaking endpoing parameters and will be ignored when 1292 secure contact header re-exchange occurs. 1294 +--------------------+---------------------------------------------+ 1295 | Parameter | Value | 1296 +--------------------+---------------------------------------------+ 1297 | Flags | The USE_TLS flag is set. | 1298 | | | 1299 | Keepalive Interval | Zero, indicating no keepalive. | 1300 | | | 1301 | Segment MRU | Zero, indicating all segments are refused. | 1302 | | | 1303 | Transfer MRU | Zero, indicating all transfers are refused. | 1304 | | | 1305 | EID | Empty, indicating lack of EID. | 1306 +--------------------+---------------------------------------------+ 1308 Table 9: Recommended Unsecured Contact Header 1310 TCPCL can be used to provide point-to-point transport security, but 1311 does not provide security of data-at-rest and does not guarantee end- 1312 to-end bundle security. The mechanisms defined in [RFC6257] and 1313 [I-D.ietf-dtn-bpsec] are to be used instead. 1315 Even when using TLS to secure the TCPCL session, the actual 1316 ciphersuite negotiated between the TLS peers MAY be insecure. TLS 1317 can be used to perform authentication without data confidentiality, 1318 for example. It is up to security policies within each TCPCL node to 1319 ensure that the negotiated TLS ciphersuite meets transport security 1320 requirements. This is identical behavior to STARTTLS use in 1321 [RFC2595]. 1323 Another consideration for this protocol relates to denial-of-service 1324 attacks. A node MAY send a large amount of data over a TCPCL 1325 session, requiring the receiving node to handle the data, attempt to 1326 stop the flood of data by sending a XFER_REFUSE message, or forcibly 1327 terminate the session. This burden could cause denial of service on 1328 other, well-behaving sessions. There is also nothing to prevent a 1329 malicious node from continually establishing sessions and repeatedly 1330 trying to send copious amounts of bundle data. A listening node MAY 1331 take countermeasures such as ignoring TCP SYN messages, closing TCP 1332 connections as soon as they are established, waiting before sending 1333 the contact header, sending a SHUTDOWN message quickly or with a 1334 delay, etc. 1336 8. IANA Considerations 1338 In this section, registration procedures are as defined in [RFC5226]. 1340 Some of the registries below are created new for TCPCLv4 but share 1341 code values with TCPCLv3. This was done to disambiguate the use of 1342 these values between TCPCLv3 and TCPCLv4 while preserving the 1343 semantics of some values. 1345 8.1. Port Number 1347 Port number 4556 has been previously assigned as the default port for 1348 the TCP convergence layer in [RFC7242]. This assignment is unchanged 1349 by protocol version 4. Each TCPCL node identifies its TCPCL protocol 1350 version in its initial contact (see Section 8.2), so there is no 1351 ambiguity about what protocol is being used. 1353 +------------------------+-------------------------------------+ 1354 | Parameter | Value | 1355 +------------------------+-------------------------------------+ 1356 | Service Name: | dtn-bundle | 1357 | | | 1358 | Transport Protocol(s): | TCP | 1359 | | | 1360 | Assignee: | Simon Perreault | 1361 | | | 1362 | Contact: | Simon Perreault | 1363 | | | 1364 | Description: | DTN Bundle TCP CL Protocol | 1365 | | | 1366 | Reference: | [RFC7242] | 1367 | | | 1368 | Port Number: | 4556 | 1369 +------------------------+-------------------------------------+ 1371 8.2. Protocol Versions 1373 IANA has created, under the "Bundle Protocol" registry, a sub- 1374 registry titled "Bundle Protocol TCP Convergence-Layer Version 1375 Numbers" and initialized it with the following table. The 1376 registration procedure is RFC Required. 1378 +-------+-------------+---------------------+ 1379 | Value | Description | Reference | 1380 +-------+-------------+---------------------+ 1381 | 0 | Reserved | [RFC7242] | 1382 | | | | 1383 | 1 | Reserved | [RFC7242] | 1384 | | | | 1385 | 2 | Reserved | [RFC7242] | 1386 | | | | 1387 | 3 | TCPCL | [RFC7242] | 1388 | | | | 1389 | 4 | TCPCLbis | This specification. | 1390 | | | | 1391 | 5-255 | Unassigned | 1392 +-------+-------------+---------------------+ 1394 8.3. Header Extension Types 1396 EDITOR NOTE: sub-registry to-be-created upon publication of this 1397 specification. 1399 IANA will create, under the "Bundle Protocol" registry, a sub- 1400 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 1401 Header Extension Types" and initialized it with the contents of 1402 Table 10. The registration procedure is RFC Required within the 1403 lower range 0x0001--0x3fff. Values in the range 0x8000--0xffff are 1404 reserved for use on private networks for functions not published to 1405 the IANA. 1407 +----------------+--------------------------+ 1408 | Code | Message Type | 1409 +----------------+--------------------------+ 1410 | 0x0000 | Reserved | 1411 | | | 1412 | 0x0001--0x3fff | Unassigned | 1413 | | | 1414 | 0x8000--0xffff | Private/Experimental Use | 1415 +----------------+--------------------------+ 1417 Table 10: Header Extension Type Codes 1419 8.4. Message Types 1421 EDITOR NOTE: sub-registry to-be-created upon publication of this 1422 specification. 1424 IANA will create, under the "Bundle Protocol" registry, a sub- 1425 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 1426 Message Types" and initialized it with the contents of Table 11. The 1427 registration procedure is RFC Required. 1429 +-----------+--------------+ 1430 | Code | Message Type | 1431 +-----------+--------------+ 1432 | 0x00 | Reserved | 1433 | | | 1434 | 0x01 | XFER_SEGMENT | 1435 | | | 1436 | 0x02 | XFER_ACK | 1437 | | | 1438 | 0x03 | XFER_REFUSE | 1439 | | | 1440 | 0x04 | KEEPALIVE | 1441 | | | 1442 | 0x05 | SHUTDOWN | 1443 | | | 1444 | 0x06 | XFER_INIT | 1445 | | | 1446 | 0x07 | MSG_REJECT | 1447 | | | 1448 | 0x08--0xf | Unassigned | 1449 +-----------+--------------+ 1451 Table 11: Message Type Codes 1453 8.5. XFER_REFUSE Reason Codes 1455 EDITOR NOTE: sub-registry to-be-created upon publication of this 1456 specification. 1458 IANA will create, under the "Bundle Protocol" registry, a sub- 1459 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 1460 XFER_REFUSE Reason Codes" and initialized it with the contents of 1461 Table 12. The registration procedure is RFC Required. 1463 +----------+---------------------------+ 1464 | Code | Refusal Reason | 1465 +----------+---------------------------+ 1466 | 0x0 | Unknown | 1467 | | | 1468 | 0x1 | Completed | 1469 | | | 1470 | 0x2 | No Resources | 1471 | | | 1472 | 0x3 | Retransmit | 1473 | | | 1474 | 0x4--0x7 | Unassigned | 1475 | | | 1476 | 0x8--0xf | Reserved for future usage | 1477 +----------+---------------------------+ 1479 Table 12: XFER_REFUSE Reason Codes 1481 8.6. SHUTDOWN Reason Codes 1483 EDITOR NOTE: sub-registry to-be-created upon publication of this 1484 specification. 1486 IANA will create, under the "Bundle Protocol" registry, a sub- 1487 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 1488 SHUTDOWN Reason Codes" and initialized it with the contents of 1489 Table 13. The registration procedure is RFC Required. 1491 +------------+------------------+ 1492 | Code | Shutdown Reason | 1493 +------------+------------------+ 1494 | 0x00 | Idle timeout | 1495 | | | 1496 | 0x01 | Version mismatch | 1497 | | | 1498 | 0x02 | Busy | 1499 | | | 1500 | 0x03 | Contact Failure | 1501 | | | 1502 | 0x04 | TLS failure | 1503 | | | 1504 | 0x05--0xFF | Unassigned | 1505 +------------+------------------+ 1507 Table 13: SHUTDOWN Reason Codes 1509 8.7. MSG_REJECT Reason Codes 1511 EDITOR NOTE: sub-registry to-be-created upon publication of this 1512 specification. 1514 IANA will create, under the "Bundle Protocol" registry, a sub- 1515 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 1516 MSG_REJECT Reason Codes" and initialized it with the contents of 1517 Table 14. The registration procedure is RFC Required. 1519 +-----------+----------------------+ 1520 | Code | Rejection Reason | 1521 +-----------+----------------------+ 1522 | 0x00 | reserved | 1523 | | | 1524 | 0x01 | Message Type Unknown | 1525 | | | 1526 | 0x02 | Message Unsupported | 1527 | | | 1528 | 0x03 | Message Unexpected | 1529 | | | 1530 | 0x04-0xFF | Unassigned | 1531 +-----------+----------------------+ 1533 Table 14: REJECT Reason Codes 1535 9. Acknowledgments 1537 This memo is based on comments on implementation of [RFC7242] 1538 provided from Scott Burleigh. 1540 10. References 1542 10.1. Normative References 1544 [I-D.ietf-dtn-bpbis] 1545 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 1546 Version 7", draft-ietf-dtn-bpbis-10 (work in progress), 1547 November 2017. 1549 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1550 RFC 793, DOI 10.17487/RFC0793, September 1981, 1551 . 1553 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1554 Communication Layers", STD 3, RFC 1122, 1555 DOI 10.17487/RFC1122, October 1989, 1556 . 1558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1559 Requirement Levels", BCP 14, RFC 2119, 1560 DOI 10.17487/RFC2119, March 1997, 1561 . 1563 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 1564 Specification", RFC 5050, DOI 10.17487/RFC5050, November 1565 2007, . 1567 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1568 IANA Considerations Section in RFCs", RFC 5226, 1569 DOI 10.17487/RFC5226, May 2008, 1570 . 1572 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1573 (TLS) Protocol Version 1.2", RFC 5246, 1574 DOI 10.17487/RFC5246, August 2008, 1575 . 1577 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1578 "Recommendations for Secure Use of Transport Layer 1579 Security (TLS) and Datagram Transport Layer Security 1580 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1581 2015, . 1583 10.2. Informative References 1585 [I-D.ietf-dtn-bpsec] 1586 Birrane, E. and K. McKeever, "Bundle Protocol Security 1587 Specification", draft-ietf-dtn-bpsec-06 (work in 1588 progress), October 2017. 1590 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1591 RFC 2595, DOI 10.17487/RFC2595, June 1999, 1592 . 1594 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 1595 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 1596 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 1597 April 2007, . 1599 [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, 1600 "Bundle Security Protocol Specification", RFC 6257, 1601 DOI 10.17487/RFC6257, May 2011, 1602 . 1604 [RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant 1605 Networking TCP Convergence-Layer Protocol", RFC 7242, 1606 DOI 10.17487/RFC7242, June 2014, 1607 . 1609 Appendix A. Significant changes from RFC7242 1611 The areas in which changes from [RFC7242] have been made to existing 1612 headers and messages are: 1614 o Changed contact header content to limit number of negotiated 1615 options. 1617 o Added contact option to negotiate maximum segment size (per each 1618 direction). 1620 o Added contact header extension capability. 1622 o Defined new IANA registries for message / type / reason codes to 1623 allow renaming some codes for clarity. 1625 o Expanded Message Header to octet-aligned fields instead of bit- 1626 packing. 1628 o Added a bundle transfer identification number to all bundle- 1629 related messages (XFER_INIT, XFER_SEGMENT, XFER_ACK, XFER_REFUSE). 1631 o Use flags in XFER_ACK to mirror flags from XFER_SEGMENT. 1633 o Removed all uses of SDNV fields and replaced with fixed-bit-length 1634 fields. 1636 The areas in which extensions from [RFC7242] have been made as new 1637 messages and codes are: 1639 o Added contact negotiation failure SHUTDOWN reason code. 1641 o Added MSG_REJECT message to indicate an unknown or unhandled 1642 message was received. 1644 o Added TLS session security mechanism. 1646 o Added TLS failure SHUTDOWN reason code. 1648 Authors' Addresses 1650 Brian Sipos 1651 RKF Engineering Solutions, LLC 1652 7500 Old Georgetown Road 1653 Suite 1275 1654 Bethesda, MD 20814-6198 1655 US 1657 Email: BSipos@rkf-eng.com 1659 Michael Demmer 1660 University of California, Berkeley 1661 Computer Science Division 1662 445 Soda Hall 1663 Berkeley, CA 94720-1776 1664 US 1666 Email: demmer@cs.berkeley.edu 1668 Joerg Ott 1669 Aalto University 1670 Department of Communications and Networking 1671 PO Box 13000 1672 Aalto 02015 1673 Finland 1675 Email: jo@netlab.tkk.fi 1677 Simon Perreault 1678 Quebec, QC 1679 Canada 1681 Email: simon@per.reau.lt