idnits 2.17.1 draft-sipos-dtn-tcpclv4-02.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 abstract seems to contain references ([I-D.ietf-dtn-bpbis], [RFC7242]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. 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 'SHALL not' in this paragraph: The order of items within the Option list SHALL not be significant. Each option type SHALL be present no more than one time in a Contact Header. Each option type SHALL be considered to have a default value if not present in a contact header. The option type defines how the particular Value Data is encoded and interpreted. If a TCPCL peer receives an Option Type which is unknown to it, the peer may send a SHUTDOWN and terminate the connection. Otherwise, the peer SHALL ignore the option and continue contact header processing. -- The document date (August 1, 2016) is 2822 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'DTNIMPL' is mentioned on line 162, but not defined == Missing Reference: 'L1' is mentioned on line 322, but not defined == Missing Reference: 'L2' is mentioned on line 322, but not defined == Missing Reference: 'L3' is mentioned on line 327, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-31) exists of draft-ietf-dtn-bpbis-04 == Outdated reference: A later version (-27) exists of draft-ietf-dtn-bpsec-02 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). 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: RFC7242 (if approved) M. Demmer 5 Intended status: Experimental UC Berkeley 6 Expires: February 2, 2017 J. Ott 7 Aalto University 8 S. Perreault 9 August 1, 2016 11 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 12 draft-sipos-dtn-tcpclv4-02 14 Abstract 16 This document describes a revised protocol for the TCP-based 17 convergence layer for Delay-Tolerant Networking (DTN). The protocol 18 revision is based on implementation issues in the original [RFC7242] 19 and updates to the Bundle Protocol contents, encodings, and 20 convergence layer requirements in [I-D.ietf-dtn-bpbis]. The majority 21 of this specification is unchanged from TCPCL version 3. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 2, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Definitions Specific to the TCPCL Protocol . . . . . . . 5 60 3. General Protocol Description . . . . . . . . . . . . . . . . 5 61 3.1. Bidirectional Use of TCP Connection . . . . . . . . . . . 7 62 3.2. Example Message Exchange . . . . . . . . . . . . . . . . 7 63 4. Connection Establishment . . . . . . . . . . . . . . . . . . 8 64 4.1. Contact Header . . . . . . . . . . . . . . . . . . . . . 9 65 4.1.1. Connection Option Encoding . . . . . . . . . . . . . 10 66 4.2. Validation and Parameter Negotiation . . . . . . . . . . 11 67 5. Established Connection Operation . . . . . . . . . . . . . . 14 68 5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . 14 69 5.2. Upkeep and Status Messages . . . . . . . . . . . . . . . 15 70 5.2.1. Connection Upkeep (KEEPALIVE) . . . . . . . . . . . . 15 71 5.2.2. Message Rejection (REJECT) . . . . . . . . . . . . . 16 72 5.3. Connection Security . . . . . . . . . . . . . . . . . . . 17 73 5.3.1. Requester Role . . . . . . . . . . . . . . . . . . . 17 74 5.3.2. Responder Role . . . . . . . . . . . . . . . . . . . 18 75 5.3.3. TLS Handshake Result . . . . . . . . . . . . . . . . 18 76 5.3.4. Example TLS Initiation . . . . . . . . . . . . . . . 18 77 5.4. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 19 78 5.4.1. Bundle Data Transmission (DATA_SEGMENT) . . . . . . . 20 79 5.4.2. Bundle Acknowledgments (ACK_SEGMENT) . . . . . . . . 21 80 5.4.3. Bundle Refusal (REFUSE_BUNDLE) . . . . . . . . . . . 22 81 5.4.4. Bundle Length (LENGTH) . . . . . . . . . . . . . . . 24 82 6. Connection Termination . . . . . . . . . . . . . . . . . . . 24 83 6.1. Shutdown Message (SHUTDOWN) . . . . . . . . . . . . . . . 25 84 6.2. Idle Connection Shutdown . . . . . . . . . . . . . . . . 27 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 87 8.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 28 88 8.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 29 89 8.3. Message Types . . . . . . . . . . . . . . . . . . . . . . 29 90 8.4. Connection Option Types . . . . . . . . . . . . . . . . . 30 91 8.5. REFUSE_BUNDLE Reason Codes . . . . . . . . . . . . . . . 31 92 8.6. SHUTDOWN Reason Codes . . . . . . . . . . . . . . . . . . 32 93 8.7. REJECT Reason Codes . . . . . . . . . . . . . . . . . . . 32 94 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 33 97 10.2. Informative References . . . . . . . . . . . . . . . . . 34 98 Appendix A. Significant changes from RFC7242 . . . . . . . . . . 34 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 101 1. Introduction 103 This document describes the TCP-based convergence-layer protocol for 104 Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to- 105 end architecture providing communications in and/or through highly 106 stressed environments, including those with intermittent 107 connectivity, long and/or variable delays, and high bit error rates. 108 More detailed descriptions of the rationale and capabilities of these 109 networks can be found in "Delay-Tolerant Network Architecture" 110 [RFC4838]. 112 An important goal of the DTN architecture is to accommodate a wide 113 range of networking technologies and environments. The protocol used 114 for DTN communications is the revsided Bundle Protocol (BP) 115 [I-D.ietf-dtn-bpbis], an application-layer protocol that is used to 116 construct a store-and- forward overlay network. As described in the 117 Bundle Protocol specification [I-D.ietf-dtn-bpbis], it requires the 118 services of a "convergence- layer adapter" (CLA) to send and receive 119 bundles using the service of some "native" link, network, or Internet 120 protocol. This document describes one such convergence-layer adapter 121 that uses the well-known Transmission Control Protocol (TCP). This 122 convergence layer is referred to as TCPCL. 124 The locations of the TCPCL and the BP in the Internet model protocol 125 stack are shown in Figure 1. In particular, when BP is using TCP as 126 its bearer with TCPCL as its convergence layer, both BP and TCPCL 127 reside at the application layer of the Internet model. 129 +-------------------------+ 130 | DTN Application | -\ 131 +-------------------------| | 132 | Bundle Protocol (BP) | -> Application Layer 133 +-------------------------+ | 134 | TCP Conv. Layer (TCPCL) | -/ 135 +-------------------------+ 136 | TCP | ---> Transport Layer 137 +-------------------------+ 138 | IP | ---> Network Layer 139 +-------------------------+ 140 | Link-Layer Protocol | ---> Link Layer 141 +-------------------------+ 142 | Physical Medium | ---> Physical Layer 143 +-------------------------+ 145 Figure 1: The Locations of the Bundle Protocol and the TCP 146 Convergence-Layer Protocol above the Internet Protocol Stack 148 This document describes the format of the protocol data units passed 149 between entities participating in TCPCL communications. This 150 document does not address: 152 o The format of protocol data units of the Bundle Protocol, as those 153 are defined elsewhere in [RFC5050] and [I-D.ietf-dtn-bpbis]. 155 o Mechanisms for locating or identifying other bundle nodes within 156 an internet. 158 Note that this document describes version 3 of the protocol. 159 Versions 0, 1, and 2 were never specified in an Internet-Draft, RFC, 160 or any other public document. These prior versions of the protocol 161 were, however, implemented in the DTN reference implementation 162 [DTNIMPL] in prior releases; hence, the current version number 163 reflects the existence of those prior versions. 165 This is an experimental protocol produced within the IRTF's Delay- 166 Tolerant Networking Research Group (DTNRG). It represents the 167 consensus of all active contributors to this group. If this protocol 168 is used on the Internet, IETF standard protocols for security and 169 congestion control should be used. 171 2. Requirements Language 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 2.1. Definitions Specific to the TCPCL Protocol 179 This section contains definitions that are interpreted to be specific 180 to the operation of the TCPCL protocol, as described below. 182 TCP Connection: A TCP connection refers to a transport connection 183 using TCP as the transport protocol. 185 TCPCL Connection: A TCPCL connection (as opposed to a TCP 186 connection) is a TCPCL communication relationship between two 187 bundle nodes. The lifetime of a TCPCL connection is bound to the 188 lifetime of an underlying TCP connection. Therefore, a TCPCL 189 connection is initiated when a bundle node initiates a TCP 190 connection to be established for the purposes of bundle 191 communication. A TCPCL connection is terminated when the TCP 192 connection ends, due either to one or both nodes actively 193 terminating the TCP connection or due to network errors causing a 194 failure of the TCP connection. For the remainder of this 195 document, the term "connection" without the prefix "TCPCL" refer 196 to a TCPCL connection. 198 Connection parameters: The connection parameters are a set of values 199 used to affect the operation of the TCPCL for a given connection. 200 The manner in which these parameters are conveyed to the bundle 201 node and thereby to the TCPCL is implementation dependent. 202 However, the mechanism by which two bundle nodes exchange and 203 negotiate the values to be used for a given session is described 204 in Section 4.2. 206 Transmission: Transmission refers to the procedures and mechanisms 207 (described below) for conveyance of a bundle from one node to 208 another. 210 3. General Protocol Description 212 The service of this protocol is the transmission of DTN bundles over 213 TCP. This document specifies the encapsulation of bundles, 214 procedures for TCP setup and teardown, and a set of messages and node 215 requirements. The general operation of the protocol is as follows. 217 First, one node establishes a TCPCL connection to the other by 218 initiating a TCP connection. After setup of the TCP connection is 219 complete, an initial contact header is exchanged in both directions 220 to set parameters of the TCPCL connection and exchange a singleton 221 endpoint identifier for each node (not the singleton Endpoint 222 Identifier (EID) of any application running on the node) to denote 223 the bundle-layer identity of each DTN node. This is used to assist 224 in routing and forwarding messages, e.g., to prevent loops. 226 Once the TCPCL connection is established and configured in this way, 227 bundles can be transmitted in either direction. Each bundle is 228 transmitted in one or more logical segments of formatted bundle data. 229 Each logical data segment consists of a DATA_SEGMENT message header, 230 a Self-Delimiting Numeric Value (SDNV) as defined in [RFC6256] 231 containing the length of the segment, and finally the byte range of 232 the bundle data. The choice of the length to use for segments is an 233 implementation matter. The first segment for a bundle must set the 234 'start' flag, and the last one must set the 'end' flag in the 235 DATA_SEGMENT message header. 237 If multiple bundles are transmitted on a single TCPCL connection, 238 they MUST be transmitted consecutively. Interleaving data segments 239 from different bundles is not allowed. Bundle interleaving can be 240 accomplished by fragmentation at the BP layer. 242 An optional feature of the protocol is for the receiving node to send 243 acknowledgments as bundle data segments arrive (ACK_SEGMENT). The 244 rationale behind these acknowledgments is to enable the sender node 245 to determine how much of the bundle has been received, so that in 246 case the connection is interrupted, it can perform reactive 247 fragmentation to avoid re-sending the already transmitted part of the 248 bundle. 250 When acknowledgments are enabled, then for each data segment that is 251 received, the receiving node sends an ACK_SEGMENT code followed by an 252 SDNV containing the cumulative length of the bundle that has been 253 received. The sending node may transmit multiple DATA_SEGMENT 254 messages without necessarily waiting for the corresponding 255 ACK_SEGMENT responses. This enables pipelining of messages on a 256 channel. In addition, there is no explicit flow control on the TCPCL 257 layer. 259 Another optional feature is that a receiver may interrupt the 260 transmission of a bundle at any point in time by replying with a 261 REFUSE_BUNDLE message, which causes the sender to stop transmission 262 of the current bundle, after completing transmission of a partially 263 sent data segment. Note: This enables a cross-layer optimization in 264 that it allows a receiver that detects that it already has received a 265 certain bundle to interrupt transmission as early as possible and 266 thus save transmission capacity for other bundles. 268 For connections that are idle, a KEEPALIVE message may optionally be 269 sent at a negotiated interval. This is used to convey liveness 270 information. 272 Finally, before connections close, a SHUTDOWN message is sent on the 273 channel. After sending a SHUTDOWN message, the sender of this 274 message may send further acknowledgments (ACK_SEGMENT or 275 REFUSE_BUNDLE) but no further data messages (DATA_SEGMENT). A 276 SHUTDOWN message may also be used to refuse a connection setup by a 277 peer. 279 3.1. Bidirectional Use of TCP Connection 281 There are specific messages for sending and receiving operations (in 282 addition to connection setup/teardown). TCPCL is symmetric, i.e., 283 both sides can start sending data segments in a connection, and one 284 side's bundle transfer does not have to complete before the other 285 side can start sending data segments on its own. Hence, the protocol 286 allows for a bi-directional mode of communication. 288 Note that in the case of concurrent bidirectional transmission, 289 acknowledgment segments may be interleaved with data segments. 291 3.2. Example Message Exchange 293 The following figure visually depicts the protocol exchange for a 294 simple session, showing the connection establishment and the 295 transmission of a single bundle split into three data segments (of 296 lengths L1, L2, and L3) from Node A to Node B. 298 Note that the sending node may transmit multiple DATA_SEGMENT 299 messages without necessarily waiting for the corresponding 300 ACK_SEGMENT responses. This enables pipelining of messages on a 301 channel. Although this example only demonstrates a single bundle 302 transmission, it is also possible to pipeline multiple DATA_SEGMENT 303 messages for different bundles without necessarily waiting for 304 ACK_SEGMENT messages to be returned for each one. However, 305 interleaving data segments from different bundles is not allowed. 307 No errors or rejections are shown in this example. 309 Node A Node B 310 ====== ====== 311 +-------------------------+ +-------------------------+ 312 | Contact Header | -> <- | Contact Header | 313 +-------------------------+ +-------------------------+ 315 +-------------------------+ 316 | DATA_SEGMENT (start) | -> 317 | SDNV length [L1] | -> 318 | Bundle Data 0..(L1-1) | -> 319 +-------------------------+ 320 +-------------------------+ +-------------------------+ 321 | DATA_SEGMENT | -> <- | ACK_SEGMENT | 322 | SDNV length [L2] | -> <- | SDNV length [L1] | 323 |Bundle Data L1..(L1+L2-1)| -> +-------------------------+ 324 +-------------------------+ 325 +-------------------------+ +-------------------------+ 326 | DATA_SEGMENT (end) | -> <- | ACK_SEGMENT | 327 | SDNV length [L3] | -> <- | SDNV length [L1+L2] | 328 |Bundle Data | -> +-------------------------+ 329 | (L1+L2)..(L1+L2+L3-1)| 330 +-------------------------+ 331 +-------------------------+ 332 <- | ACK_SEGMENT | 333 <- | SDNV length [L1+L2+L3] | 334 +-------------------------+ 336 +-------------------------+ +-------------------------+ 337 | SHUTDOWN | -> <- | SHUTDOWN | 338 +-------------------------+ +-------------------------+ 340 Figure 2: A Simple Visual Example of the Flow of Protocol Messages on 341 a Single TCP Session between Two Nodes (A and B) 343 4. Connection Establishment 345 For bundle transmissions to occur using the TCPCL, a TCPCL connection 346 must first be established between communicating nodes. It is up to 347 the implementation to decide how and when connection setup is 348 triggered. For example, some connections may be opened proactively 349 and maintained for as long as is possible given the network 351 conditions, while other connections may be opened only when there is 352 a bundle that is queued for transmission and the routing algorithm 353 selects a certain next-hop node. 355 To establish a TCPCL connection, a node must first establish a TCP 356 connection with the intended peer node, typically by using the 357 services provided by the operating system. Port number 4556 has been 358 assigned by IANA as the well-known port number for the TCP 359 convergence layer. Other port numbers MAY be used per local 360 configuration. Determining a peer's port number (if different from 361 the well-known TCPCL port) is up to the implementation. 363 If the node is unable to establish a TCP connection for any reason, 364 then it is an implementation matter to determine how to handle the 365 connection failure. A node MAY decide to re-attempt to establish the 366 connection. If it does so, it MUST NOT overwhelm its target with 367 repeated connection attempts. Therefore, the node MUST retry the 368 connection setup only after some delay (a 1-second minimum is 369 RECOMMENDED), and it SHOULD use a (binary) exponential backoff 370 mechanism to increase this delay in case of repeated failures. In 371 case a SHUTDOWN message specifying a reconnection delay is received, 372 that delay is used as the initial delay. The default initial delay 373 SHOULD be at least 1 second but SHOULD be configurable since it will 374 be application and network type dependent. 376 The node MAY declare failure after one or more connection attempts 377 and MAY attempt to find an alternate route for bundle data. Such 378 decisions are up to the higher layer (i.e., the BP). 380 Once a TCP connection is established, each node MUST immediately 381 transmit a contact header over the TCP connection. The format of the 382 contact header is described in Section 4.1. 384 Upon receipt of the contact header, both nodes perform the validation 385 and negotiation procedures defined in Section 4.2 387 After receiving the contact header from the other node, either node 388 MAY also refuse the connection by sending a SHUTDOWN message. If 389 connection setup is refused, a reason MUST be included in the 390 SHUTDOWN message. 392 4.1. Contact Header 394 Once a TCP connection is established, both parties exchange a contact 395 header. This section describes the format of the contact header and 396 the meaning of its fields. 398 The format for the Contact Header is as follows: 400 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 401 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 402 +---------------+---------------+---------------+---------------+ 403 | magic='dtn!' | 404 +---------------+---------------+---------------+---------------+ 405 | version | Option count (SDNV) | 406 +---------------+---------------+---------------+---------------+ 407 | Options list (sequence of TLV) | 408 +---------------+---------------+---------------+---------------+ 410 Figure 3: Contact Header Format 412 The fields of the contact header are: 414 magic: A four-byte field that always contains the byte sequence 0x64 415 0x74 0x6e 0x21, i.e., the text string "dtn!" in US-ASCII (and UTF- 416 8). 418 version: A one-byte field value containing the value 4 (current 419 version of the protocol). 421 Option count: A SDNV-encoded count of connection options to follow. 423 Option list: A sequence of type-length-value (TLV) encoded 424 connection options as shown in Figure 4 and described in 425 Section 4.1.1 427 Each option within a contact header represents the configuration of 428 the peer which has sent the contact header. The manner in which 429 options are configured and chosen for the various parameters in the 430 contact header is implementation dependent. 432 4.1.1. Connection Option Encoding 434 Each of the contact header Options SHALL be encoded as a sequence of 435 TLV data as shown in Figure 4. 437 Option Type: An SDNV-encoded field which SHALL determine the 438 encoding and interpretation of the option value. 440 Value Length: An SDNV-encoded field which SHALL define the length 441 (in octets) of the Value Data to follow. The Value Length does 442 not include the length of the Option Type or Value Length fields 443 themselves. 445 Value Data: The encoded type-dependent data of the option. 447 The order of items within the Option list SHALL not be significant. 448 Each option type SHALL be present no more than one time in a Contact 449 Header. Each option type SHALL be considered to have a default value 450 if not present in a contact header. The option type defines how the 451 particular Value Data is encoded and interpreted. If a TCPCL peer 452 receives an Option Type which is unknown to it, the peer may send a 453 SHUTDOWN and terminate the connection. Otherwise, the peer SHALL 454 ignore the option and continue contact header processing. 456 +-----------------------+ 457 | Option Type (SDNV) | 458 +-----------------------+ 459 | Value Length (SDNV) | 460 +-----------------------+ 461 | Value Data (variable) | 462 +-----------------------+ 464 Figure 4: Connection Option Format 466 4.2. Validation and Parameter Negotiation 468 Upon reception of the contact header, each node follows the following 469 procedures to ensure the validity of the TCPCL connection and to 470 negotiate values for the connection parameters. 472 If the magic string is not present or is not valid, the connection 473 MUST be terminated. The intent of the magic string is to provide 474 some protection against an inadvertent TCP connection by a different 475 protocol than the one described in this document. To prevent a flood 476 of repeated connections from a misconfigured application, a node MAY 477 elect to hold an invalid connection open and idle for some time 478 before closing it. 480 If a node receives a contact header containing a version that is 481 greater than the current version of the protocol that the node 482 implements, then the node SHALL terminate the connection. If a node 483 receives a contact header with a version that is lower than the 484 version of the protocol that the node implements, the node may either 485 terminate the connection due to the version mismatch or may adapt its 486 operation to conform to the older version of the protocol. This 487 decision is an implementation matter. 489 A node calculates the parameters for a TCPCL connection by 490 negotiating the values from its own preferences (conveyed by the 491 contact header it sent to the peer) with the preferences of the peer 492 node (expressed in the contact header that it received from the 493 peer). 495 The negotatiated parameters defined by this specification are listed 496 in Table 1 and described in the following paragraphs. 498 +--------------+------+---------------------------------------------+ 499 | Type | Code | Description | 500 +--------------+------+---------------------------------------------+ 501 | Handle | 0x1 | Determine how peer handles LENGTH messages. | 502 | LENGTH | | | 503 | | | | 504 | Acknowledge | 0x2 | Determine how peer handles acknowledgment | 505 | Intermediate | | of non-final bundle segments. | 506 | | | | 507 | Acknowledge | 0x3 | Determine how peer handles acknowledgement | 508 | Bundle | | of final bundle segments and bundle | 509 | | | refusal. | 510 | | | | 511 | Keepalive | 0x4 | The maximum keepalive interval of the peer. | 512 | | | | 513 | Peer EID | 0x5 | The Endpoint ID of the peer. | 514 | | | | 515 | BP Versions | 0x6 | The set of BP versions supported by the | 516 | | | peer. | 517 | | | | 518 | Segment MRU | 0x7 | The largest segment length supported by the | 519 | | | peer. | 520 | | | | 521 | Handle TLS | 0x8 | Determine how peer handles STARTTLS | 522 | | | messages. | 523 +--------------+------+---------------------------------------------+ 525 Table 1: Connection Option Types 527 Handle LENGTH: This parameter is a value enumerated by Table 2 and 528 encoded as a single octet. The value determines whether LENGTH 529 messages (as described in Section 5.4.4) are handled by this peer. 531 If the value is IGNORE then the LENGTH message SHOULD NOT be sent 532 to this peer. If the value is ALLOW then the LENGTH message 533 SHOULD be sent to this peer. If the value is REQUIRE then the 534 LENGTH message SHALL be sent to this peer. The default Handle 535 LENGTH value is ALLOW. 537 Acknowledge Intermediate: This parameter is a value enumerated by 538 Table 2 and encoded as a single octet. The value determines how 539 any non-final ACK_SEGMENT (i.e. one with its E flag not set as 540 described in Section 5.4.2) is handled by this peer. 542 If the value is IGNORE then any non-final ACK_SEGMENT message 543 SHOULD NOT be sent to this peer. If the value is ALLOW then any 544 non-final ACK_SEGMENT message SHOULD be sent to this peer. If the 545 value is REQUIRE then any non-final ACK_SEGMENT message SHALL be 546 sent to this peer. The default Acknowledge Intermediate value is 547 ALLOW. 549 Acknowledge Bundle: This parameter is a value enumerated by Table 2 550 and encoded as a single octet. The value determines how any final 551 ACK_SEGMENT (i.e. one with its E flag set as described in 552 Section 5.4.2) is handled by this peer. This value also 553 determines how any REFUSE_BUNDLE message is handled by this peer. 555 If the value is IGNORE then any final ACK_SEGMENT or REFUSE_BUNDLE 556 message SHOULD NOT be sent to this peer. If the value is ALLOW 557 then any final ACK_SEGMENT or REFUSE_BUNDLE message SHOULD be sent 558 to this peer. If the value is REQUIRE then any final ACK_SEGMENT 559 or REFUSE_BUNDLE message SHALL be sent to this peer. The default 560 Acknowledge Bundle value is ALLOW. 562 Keepalive: This parameter is encoded as a two-octet unsigned integer 563 in network byte order (U16). The value is the maximum keepalive 564 time interval (in seconds) for this peer. The negotiated 565 keepalive interval is set to the minimum value from both contact 566 headers. If one or both contact headers contains the value zero, 567 then the keepalive feature (described in Section 5.2.1) is 568 disabled. The default Keepalive value is zero. 570 Peer EID: This parameter is a byte string containing the UTF-8 571 encoded EID of some singleton endpoint in which the sending node 572 is a member, in the canonical format of :. The default Peer EID value is the empty string. 575 BP Versions: This parameter is a sequence of bytes, each containing 576 an individual Bundle Protocol version number supported by this 577 peer. The set of supported BP versions of the connection is the 578 intersection of the BP versions indicated by both of the contact 579 headers. 581 If interoperating with a TCPCL Version 3 node, a TCPCL Version 4 582 node MAY assume that the TCPCL Version 3 node supports exactly one 583 BP Version: 0x06 of [RFC5050]. If there is no common supported BP 584 version then the connection SHOULD be shutdown with reason 585 "Contact Failure", as no possible bundle exchange can occur. 586 Otherwise, the default BP Versions value is the single version 4 587 (this specification). 589 Segment MRU: This parameter is an SDNV-encoded integer. The value 590 indicates the maximum Data Length within of DATA_SEGMENT which 591 this peer will accept, or zero if there is no maximum length. Any 592 DATA_SEGMENT send to this peer SHALL have a data payload no longer 593 than this peer's maximum length. The default Segment MRU value is 594 zero. 596 +---------+------+--------------------------------------------------+ 597 | Name | Code | Description | 598 +---------+------+--------------------------------------------------+ 599 | IGNORE | 0x01 | The peer sending this option will ignore any | 600 | | | such messages. | 601 | | | | 602 | ALLOW | 0x02 | The peer sending this option will process any | 603 | | | such messages and act upon the data. | 604 | | | | 605 | REQUIRE | 0x03 | The peer sending this option will refuse to | 606 | | | operate without such messages. | 607 +---------+------+--------------------------------------------------+ 609 Table 2: Receiver Handle Enumeration 611 Once this process of parameter negotiation is completed, the protocol 612 defines no additional mechanism to change the parameters of an 613 established connection; to effect such a change, the connection MUST 614 be terminated and a new connection established. 616 5. Established Connection Operation 618 This section describes the protocol operation for the duration of an 619 established connection, including the mechanisms for transmitting 620 bundles over the connection. 622 5.1. Message Type Codes 624 After the initial exchange of a contact header, all messages 625 transmitted over the connection are identified by a one-byte header 626 with the following structure: 628 0 1 2 3 4 5 6 7 629 +-+-+-+-+-+-+-+-+ 630 | type | flags | 631 +-+-+-+-+-+-+-+-+ 633 Figure 5: Format of the One-Byte Message Header 635 type: Indicates the type of the message as per Table 3 below. 637 flags: Optional flags defined based on message type. 639 The types and values for the message type code are as follows. 641 +---------------+------+--------------------------------------------+ 642 | Type | Code | Description | 643 +---------------+------+--------------------------------------------+ 644 | DATA_SEGMENT | 0x1 | Indicates the transmission of a segment of | 645 | | | bundle data, as described in Section | 646 | | | 5.4.1. | 647 | | | | 648 | ACK_SEGMENT | 0x2 | Acknowledges reception of a data segment, | 649 | | | as described in Section 5.4.2. | 650 | | | | 651 | REFUSE_BUNDLE | 0x3 | Indicates that the transmission of the | 652 | | | current bundle SHALL be stopped, as | 653 | | | described in Section 5.4.3. | 654 | | | | 655 | KEEPALIVE | 0x4 | KEEPALIVE message for the connection, as | 656 | | | described in Section 5.2.1. | 657 | | | | 658 | SHUTDOWN | 0x5 | Indicates that one of the nodes | 659 | | | participating in the connection wishes to | 660 | | | cleanly terminate the connection, as | 661 | | | described in Section 6. | 662 | | | | 663 | LENGTH | 0x6 | Contains the length (in bytes) of the next | 664 | | | bundle, as described in Section 5.4.4. | 665 +---------------+------+--------------------------------------------+ 667 Table 3: TCPCL Message Types 669 5.2. Upkeep and Status Messages 671 5.2.1. Connection Upkeep (KEEPALIVE) 673 The protocol includes a provision for transmission of KEEPALIVE 674 messages over the TCP connection to help determine if the connection 675 has been disrupted. 677 As described in Section 4.1, one of the parameters in the contact 678 header is the keepalive_interval. Both sides populate this field 679 with their requested intervals (in seconds) between KEEPALIVE 680 messages. 682 The format of a KEEPALIVE message is a one-byte message type code of 683 KEEPALIVE (as described in Table 2) with no additional data. Both 684 sides SHOULD send a KEEPALIVE message whenever the negotiated 685 interval has elapsed with no transmission of any message (KEEPALIVE 686 or other). 688 If no message (KEEPALIVE or other) has been received for at least 689 twice the keepalive_interval, then either party MAY terminate the 690 session by transmitting a one-byte SHUTDOWN message (as described in 691 Table 2) and by closing the TCP connection. 693 Note: The keepalive_interval should not be chosen too short as TCP 694 retransmissions may occur in case of packet loss. Those will have to 695 be triggered by a timeout (TCP retransmission timeout (RTO)), which 696 is dependent on the measured RTT for the TCP connection so that 697 KEEPALIVE messages may experience noticeable latency. 699 5.2.2. Message Rejection (REJECT) 701 If a TCPCL endpoint receives a message which is uknown to it 702 (possibly due to an unhandled protocol mismatch) or is inappropriate 703 for the current connection state (e.g. a KEEPALIVE or LENGTH message 704 received after feature negotation has disabled those features), there 705 is a protocol-level message to signal this condition in the form of a 706 REJECT reply. 708 The format of a REJECT message follows: 710 +-----------------------------+ 711 | Message Header | 712 +-----------------------------+ 713 | Rejected Message Header | 714 +-----------------------------+ 715 | Reason Code (byte) | 716 +-----------------------------+ 718 Figure 6: Format of REJECT Messages 720 The Rejected Message Header is a copy of the Message Header to which 721 the REJECT message is sent as a response. The REJECT Reason Code 722 indicates why the REJECT itself was sent. The specified values of 723 the reason code are: 725 +-------------+------+----------------------------------------------+ 726 | Name | Code | Description | 727 +-------------+------+----------------------------------------------+ 728 | Message | 0x01 | A message was received with a Message Type | 729 | Type | | code unknown to the TCPCL endpoint. | 730 | Unknown | | | 731 | | | | 732 | Message | 0x02 | A message was received but the TCPCL | 733 | Unsupported | | endpoint cannot comply with the message | 734 | | | contents. | 735 | | | | 736 | Message | 0x03 | A message was received while the connection | 737 | Unexpected | | is in a state in which the message is not | 738 | | | expected. | 739 +-------------+------+----------------------------------------------+ 741 Table 4: REJECT Reason Codes 743 5.3. Connection Security 745 This version of the TCPCL supports establishing a connection-level 746 Transport Layer Security (TLS) session within an existing TCPCL 747 connection. 749 When TLS is used within the TCPCL it affects the entire connection, 750 and it can technically be initiated by either endpoint of the 751 connection. By convention, this protocol uses the endpoint which 752 initiated the underlying TCP connection as the initiator of the TLS 753 session request. Once a TLS session is established within TCPCL, 754 there is no mechanism provided to end the TLS session and downgrade 755 the connection. If a non-TLS connection is desired after a TLS 756 session is started then the entire TCPCL connection MUST be shutdown 757 first. 759 5.3.1. Requester Role 761 A STARTTLS message SHOULD be sent by the TCP client immediately after 762 reception of the TCPCL Contact Header from the server. Upon sending 763 a STARTTLS message, the requester SHALL enter a waiting state. 765 While in the waiting state, upon reception of a confirmation STARTTLS 766 message the requestor SHALL begin a TLS handshake in accordance with 767 [RFC5246]. While in the waiting state, the recepiton of any message 768 other than a STARTTLS reply MAY cause a connection shutdown depending 769 upon security policy of the endpoint. 771 5.3.2. Responder Role 773 Upon reception of a STARTTLS message while not already within a TLS 774 session and while not acting as a TLS requester and if the endpoint 775 supports TLS connections, a STARTTLS message SHALL be sent in 776 response. If an endpoint receives a STARTTLS message but cannot 777 support a TLS connection (for any reason) then a REJECT message SHALL 778 be sent in response containing a Reason Code of "Message Unsupported. 779 Upon reception of a STARTTLS message while already within a TLS 780 session, a REJECT message SHOULD be sent in response containing a 781 Reason Code of "Message Unexpected". Upon sending a response 782 STARTTLS message the responder SHALL begin a TLS handshake in 783 accordance with [RFC5246]. 785 5.3.3. TLS Handshake Result 787 If a TLS handshake cannot negotiate a TLS session, either endpoint of 788 the TCPCL connection SHOULD cause a TCPCL shutdown with reason "TLS 789 negotiation failed". After a TLS handshake failure, if the 790 connection is not shutdown then either endpoint MAY request a new TLS 791 handshake. Unless the TLS parameters change between two sequential 792 handshakes, the subsequent handshake is likely to fail just as the 793 earlier one. 795 After a TLS session is successfuly established, both TCPCL endpoints 796 SHALL re-exchange TCPCL Contact Header messages. Any information 797 cached from the prior Contact Header exchange SHALL be discarded. 798 This re-exchange avoids man-in-the-middle attack in identical fashon 799 to [RFC2595]. 801 5.3.4. Example TLS Initiation 803 A summary of a typical STARTTLS usage is shown in the sequence below 804 where the client/requester role is represented by the prefix "C" and 805 the server/responder role is represented by the prefix "S". 806 Unordered or "simultaneous" actions are shown as "C/S". 808 Node A Node B 809 ====== ====== 811 +-------------------------+ 812 | Open TCP Connnection | -> 813 +-------------------------+ +-------------------------+ 814 <- | Accept Connection | 815 +-------------------------+ 817 +-------------------------+ +-------------------------+ 818 | Contact Header | -> <- | Contact Header | 819 +-------------------------+ +-------------------------+ 821 ... plaintext TCPCL messaging ... 823 +-------------------------+ 824 | STARTTLS | -> 825 +-------------------------+ +-------------------------+ 826 <- | STARTTLS | 827 +-------------------------+ 829 +-------------------------+ +-------------------------+ 830 | TLS Negotiation | -> <- | TLS Negotiation | 831 +-------------------------+ +-------------------------+ 833 +-------------------------+ +-------------------------+ 834 | Contact Header | -> <- | Contact Header | 835 +-------------------------+ +-------------------------+ 837 ... secured TCPCL messaging ... 839 +-------------------------+ +-------------------------+ 840 | SHUTDOWN | -> <- | SHUTDOWN | 841 +-------------------------+ +-------------------------+ 843 Figure 7: A simple visual example of TCPCL TLS Establishment between 844 two nodes 846 5.4. Bundle Transfer 848 All of the message in this section are directly associated with 849 tranfering a bundle between TCPCL endpoints. Each of the messages 850 contains a Bundle ID number which is used to correlate messages 851 originating from sender and receiver of a bundle. The Bundle ID 852 provides a similar behaivior to a datagram sequence number, but there 853 are no requirements on Bundle ID ordering or reuse. 855 Bundle IDs SHOULD be unique within a limited scope dependant upon 856 implementation needs. Sequential bundle transfers SHALL NOT use the 857 same Bundle ID. Bundle ID numbers MAY be reused after a window of 858 either count or time. Bundle ID reuse SHOULD take into account 859 unacknowledged bundle segments if acknowledgement is used within a 860 connection. For example, Bundle IDs in the range 1--50 inclusive can 861 be used for sequential bundle transmissions in ascending order before 862 recycling back to 1. This allows discrimination between 50 adjacent 863 bundle transfers. 865 A TCPCL endpoint SHALL support Bundle IDs at least between 0 and 2^14 866 (two-bytes encoded). A TCPCL endpoint MAY support larger Bundle IDs 867 depending upon implementation needs. For bidirectional bundle 868 transfers, a TCPCL endpoint SHOULD NOT rely on any relation between 869 Bundle IDs originating from each side of the TCPCL connection. Upon 870 reception of a Bundle ID not able to be handled by an endpoint, a 871 REFUSE_BUNDLE message SHOULD be sent in response. 873 5.4.1. Bundle Data Transmission (DATA_SEGMENT) 875 Each bundle is transmitted in one or more data segments. The format 876 of a DATA_SEGMENT message follows in Figure 8 and its use of header 877 flags is shown in Figure 9. 879 +-----------------------------+ 880 | Message Header | 881 +-----------------------------+ 882 | Bundle ID (SDNV) | 883 +-----------------------------+ 884 | Data length (SDNV) | 885 +-----------------------------+ 886 | Data contents (byte string) | 887 +-----------------------------+ 889 Figure 8: Format of DATA_SEGMENT Messages 891 4 5 6 7 892 +-+-+-+-+ 893 |0|0|S|E| 894 +-+-+-+-+ 896 Figure 9: Format of DATA_SEGMENT Header flags 898 The type portion of the message header contains the value 0x1. 900 The flags portion of the message header byte contains two optional 901 values in the two low-order bits, denoted 'S' and 'E' above. The 'S' 902 bit MUST be set to one if it precedes the transmission of the first 903 segment of a new bundle. The 'E' bit MUST be set to one when 904 transmitting the last segment of a bundle. 906 Following the message header, the length field is an SDNV containing 907 the number of bytes of bundle data that are transmitted in this 908 segment. Following this length is the actual data contents. 910 Determining the size of the segment is an implementation matter. In 911 particular, a node may, based on local policy or configuration, only 912 ever transmit bundle data in a single segment, in which case both the 913 'S' and 'E' bits MUST be set to one. 915 In the Bundle Protocol specification [RFC5050], a single bundle 916 comprises a primary bundle block, a payload block, and zero or more 917 additional bundle blocks. The relationship between the protocol 918 blocks and the convergence-layer segments is an implementation- 919 specific decision. In particular, a segment MAY contain more than 920 one protocol block; alternatively, a single protocol block (such as 921 the payload) MAY be split into multiple segments. 923 However, a single segment MUST NOT contain data of more than a single 924 bundle. 926 Once a transmission of a bundle has commenced, the node MUST only 927 send segments containing sequential portions of that bundle until it 928 sends a segment with the 'E' bit set. 930 5.4.2. Bundle Acknowledgments (ACK_SEGMENT) 932 Although the TCP transport provides reliable transfer of data between 933 transport peers, the typical BSD sockets interface provides no means 934 to inform a sending application of when the receiving application has 935 processed some amount of transmitted data. Thus, after transmitting 936 some data, a Bundle Protocol agent needs an additional mechanism to 937 determine whether the receiving agent has successfully received the 938 segment. 940 To this end, the TCPCL protocol offers an optional feature whereby a 941 receiving node transmits acknowledgments of reception of data 942 segments. This feature is enabled if, and only if, during the 943 exchange of contact headers, both parties set the flag to indicate 944 that intermediate or final acknowledgments are enabled (see 945 Section 4.1). 947 The format of an ACK_SEGMENT message follows in Figure 10 and its use 948 of header flags is the same as for DATA_SEGMENT (shown in Figure 9). 949 The flags of an ACK_SEGMENT message SHALL be identical to the flags 950 of the DATA_SEGMENT message for which it is a reply. 952 +-----------------------------+ 953 | Message Header | 954 +-----------------------------+ 955 | Bundle ID (SDNV) | 956 +-----------------------------+ 957 | Acknowledged length (SDNV) | 958 +-----------------------------+ 960 Figure 10: Format of ACK_SEGMENT Messages 962 To transmit an acknowledgment, a node first transmits a message 963 header with the ACK_SEGMENT type code and all flags set to zero, then 964 transmits an SDNV containing the cumulative length in bytes of the 965 received segment(s) of the current bundle. The length MUST fall on a 966 segment boundary. That is, only full segments can be acknowledged. 968 For example, suppose the sending node transmits four segments of 969 bundle data with lengths 100, 200, 500, and 1000, respectively. 970 After receiving the first segment, the node sends an acknowledgment 971 of length 100. After the second segment is received, the node sends 972 an acknowledgment of length 300. The third and fourth 973 acknowledgments are of length 800 and 1800, respectively. 975 5.4.3. Bundle Refusal (REFUSE_BUNDLE) 977 As bundles may be large, the TCPCL supports an optional mechanisms by 978 which a receiving node may indicate to the sender that it does not 979 want to receive the corresponding bundle. 981 To do so, upon receiving a LENGTH or DATA_SEGMENT message, the node 982 MAY transmit a REFUSE_BUNDLE message. As data segments and 983 acknowledgments may cross on the wire, the bundle that is being 984 refused SHALL be identified by the Bundle ID of the refusal. 986 The format of the message is as follows: 988 +-----------------------------+ 989 | Message Header | 990 +-----------------------------+ 991 | Bundle ID (SDNV) | 992 +-----------------------------+ 994 Figure 11: Format of REFUSE_BUNDLE Messages 995 4 5 6 7 996 +-+-+-+-+ 997 | RCode | 998 +-+-+-+-+ 1000 Figure 12: Format of REFUSE_BUNDLE Header flags 1002 The RCode field, which stands for "reason code", contains a value 1003 indicating why the bundle was refused. The following table contains 1004 semantics for some values. Other values may be registered with IANA, 1005 as defined in Section 8. 1007 +------------+-------+----------------------------------------------+ 1008 | Name | RCode | Semantics | 1009 +------------+-------+----------------------------------------------+ 1010 | Unknown | 0x0 | Reason for refusal is unknown or not | 1011 | | | specified. | 1012 | | | | 1013 | Completed | 0x1 | The receiver now has the complete bundle. | 1014 | | | The sender MAY now consider the bundle as | 1015 | | | completely received. | 1016 | | | | 1017 | No | 0x2 | The receiver's resources are exhausted. The | 1018 | Resources | | sender SHOULD apply reactive bundle | 1019 | | | fragmentation before retrying. | 1020 | | | | 1021 | Retransmit | 0x3 | The receiver has encountered a problem that | 1022 | | | requires the bundle to be retransmitted in | 1023 | | | its entirety. | 1024 +------------+-------+----------------------------------------------+ 1026 Table 5: REFUSE_BUNDLE Reason Codes 1028 The receiver MUST, for each bundle preceding the one to be refused, 1029 have either acknowledged all DATA_SEGMENTs or refused the bundle. 1030 This allows the sender to identify the bundles accepted and refused 1031 by means of a simple FIFO list of segments and acknowledgments. 1033 The bundle refusal MAY be sent before the entire data segment is 1034 received. If a sender receives a REFUSE_BUNDLE message, the sender 1035 MUST complete the transmission of any partially sent DATA_SEGMENT 1036 message (so that the receiver stays in sync). The sender MUST NOT 1037 commence transmission of any further segments of the refused bundle 1038 subsequently. Note, however, that this requirement does not ensure 1039 that a node will not receive another DATA_SEGMENT for the same bundle 1040 after transmitting a REFUSE_BUNDLE message since messages may cross 1041 on the wire; if this happens, subsequent segments of the bundle 1042 SHOULD also be refused with a REFUSE_BUNDLE message. 1044 Note: If a bundle transmission is aborted in this way, the receiver 1045 may not receive a segment with the 'E' flag set to '1' for the 1046 aborted bundle. The beginning of the next bundle is identified by 1047 the 'S' bit set to '1', indicating the start of a new bundle. 1049 5.4.4. Bundle Length (LENGTH) 1051 The LENGTH message contains the total length, in bytes, of the next 1052 bundle, formatted as an SDNV. Its purpose is to allow nodes to 1053 preemptively refuse bundles that would exceed their resources. It is 1054 an optimization. 1056 The format of the LENGTH message is as follows: 1058 +-----------------------------+ 1059 | Message Header | 1060 +-----------------------------+ 1061 | Bundle ID (SDNV) | 1062 +-----------------------------+ 1063 | Total bundle length (SDNV) | 1064 +-----------------------------+ 1066 Figure 13: Format of LENGTH Messages 1068 LENGTH messages MUST NOT be sent unless the corresponding flag bit is 1069 set in the contact header. If the flag bit is set, LENGTH messages 1070 MAY be sent at the sender's discretion. LENGTH messages MUST NOT be 1071 sent unless the next DATA_SEGMENT message has the 'S' bit set to "1" 1072 (i.e., just before the start of a new bundle). 1074 A receiver MAY send a BUNDLE_REFUSE message as soon as it receives a 1075 LENGTH message without waiting for the next DATA_SEGMENT message. 1076 The sender MUST be prepared for this and MUST associate the refusal 1077 with the right bundle. 1079 Upon reception of a LENGTH message when either LENGTH has not been 1080 negotiated or not immediately before the start of a starting 1081 DATA_SEGMENT the reciever MAY send a REJECT message with a Reason 1082 Code of "Message Unexpected". 1084 6. Connection Termination 1086 This section describes the procedures for ending a TCPCL connection. 1088 6.1. Shutdown Message (SHUTDOWN) 1090 To cleanly shut down a connection, a SHUTDOWN message MUST be 1091 transmitted by either node at any point following complete 1092 transmission of any other message. In case acknowledgments have been 1093 negotiated, a node SHOULD acknowledge all received data segments 1094 first and then shut down the connection. 1096 The format of the SHUTDOWN message is as follows: 1098 +-----------------------------------+ 1099 | Message Header | 1100 +-----------------------------------+ 1101 | Reason Code (optional byte) | 1102 +-----------------------------------+ 1103 | Reconnection Delay (optional U16) | 1104 +-----------------------------------+ 1106 Figure 14: Format of SHUTDOWN Messages 1108 4 5 6 7 1109 +-+-+-+-+ 1110 |0|0|R|D| 1111 +-+-+-+-+ 1113 Figure 15: Format of SHUTDOWN Header flags 1115 It is possible for a node to convey additional information regarding 1116 the reason for connection termination. To do so, the node MUST set 1117 the 'R' bit in the message header flags and transmit a one-byte 1118 reason code immediately following the message header. The specified 1119 values of the reason code are: 1121 +------------+------+-----------------------------------------------+ 1122 | Name | Code | Description | 1123 +------------+------+-----------------------------------------------+ 1124 | Idle | 0x00 | The connection is being closed due to | 1125 | timeout | | idleness. | 1126 | | | | 1127 | Version | 0x01 | The node cannot conform to the specified | 1128 | mismatch | | TCPCL protocol version. | 1129 | | | | 1130 | Busy | 0x02 | The node is too busy to handle the current | 1131 | | | connection. | 1132 | | | | 1133 | Contact | 0x03 | The node cannot interpret or negotiate | 1134 | Failure | | contact header option. | 1135 | | | | 1136 | TLS | 0x04 | The node failed to negotiate TLS session and | 1137 | failure | | cannot continue the connection. | 1138 +------------+------+-----------------------------------------------+ 1140 Table 6: SHUTDOWN Reason Codes 1142 It is also possible to convey a requested reconnection delay to 1143 indicate how long the other node must wait before attempting 1144 connection re-establishment. To do so, the node sets the 'D' bit in 1146 the message header flags and then transmits an SDNV specifying the 1147 requested delay, in seconds, following the message header (and 1148 optionally, the SHUTDOWN reason code). The value 0 SHALL be 1149 interpreted as an infinite delay, i.e., that the connecting node MUST 1150 NOT re-establish the connection. In contrast, if the node does not 1151 wish to request a delay, it SHOULD omit the reconnection delay field 1152 (and set the 'D' bit to zero). Note that in the figure above, the 1153 reconnection delay SDNV is represented as a two-byte field for 1154 convenience. 1156 A connection shutdown MAY occur immediately after TCP connection 1157 establishment or reception of a contact header (and prior to any 1158 further data exchange). This may, for example, be used to notify 1159 that the node is currently not able or willing to communicate. 1160 However, a node MUST always send the contact header to its peer 1161 before sending a SHUTDOWN message. 1163 If either node terminates a connection prematurely in this manner, it 1164 SHOULD send a SHUTDOWN message and MUST indicate a reason code unless 1165 the incoming connection did not include the magic string. If a node 1166 does not want its peer to reopen the connection immediately, it 1167 SHOULD set the 'D' bit in the flags and include a reconnection delay 1168 to indicate when the peer is allowed to attempt another connection 1169 setup. 1171 If a connection is to be terminated before another protocol message 1172 has completed, then the node MUST NOT transmit the SHUTDOWN message 1173 but still SHOULD close the TCP connection. In particular, if the 1174 connection is to be closed (for whatever reason) while a node is in 1175 the process of transmitting a bundle data segment, the receiving node 1176 is still expecting segment data and might erroneously interpret the 1177 SHUTDOWN message to be part of the data segment. 1179 6.2. Idle Connection Shutdown 1181 The protocol includes a provision for clean shutdown of idle TCP 1182 connections. Determining the length of time to wait before closing 1183 idle connections, if they are to be closed at all, is an 1184 implementation and configuration matter. 1186 If there is a configured time to close idle links and if no bundle 1187 data (other than KEEPALIVE messages) has been received for at least 1188 that amount of time, then either node MAY terminate the connection by 1189 transmitting a SHUTDOWN message indicating the reason code of 'Idle 1190 timeout' (as described in Table 4). After receiving a SHUTDOWN 1191 message in response, both sides may close the TCP connection. 1193 7. Security Considerations 1195 One security consideration for this protocol relates to the fact that 1196 nodes present their endpoint identifier as part of the connection 1197 header exchange. It would be possible for a node to fake this value 1198 and present the identity of a singleton endpoint in which the node is 1199 not a member, essentially masquerading as another DTN node. If this 1200 identifier is used outside of a TLS-secured session or without 1201 further verification as a means to determine which bundles are 1202 transmitted over the connection, then the node that has falsified its 1203 identity may be able to obtain bundles that it should not have. 1204 Therefore, a node SHALL NOT use the endpoint identifier conveyed in 1205 the TCPCL connection message to derive a peer node's identity unless 1206 it can corroborate it via other means. 1208 These concerns may be mitigated through the use of the Bundle 1209 Security Protocol [RFC6257]. In particular, the Bundle 1210 Authentication Block defines mechanism for secure exchange of bundles 1211 between DTN nodes. Thus, an implementation could delay trusting the 1212 presented endpoint identifier until the node can securely validate 1213 that its peer is in fact the only member of the given singleton 1214 endpoint. 1216 TCPCL can be used to provide point-to-point transport security, but 1217 does not provide security of data-at-rest and does not guarantee end- 1218 to-end bundle security. The mechanisms defined in [RFC6257] and 1219 [I-D.ietf-dtn-bpsec] are to be used instead. 1221 Even when using TLS to secure the TCPCL connection, the actual 1222 ciphersuite negotiated between the TLS peers may be insecure. TLS 1223 can be used to perform authentication without data confidentiality, 1224 for example. It is up to security policies within each TCPCL node to 1225 ensure that the negotiated TLS ciphersuite meets transport security 1226 requirements. This is identical behavior to STARTTLS use in 1227 [RFC2595]. 1229 Another consideration for this protocol relates to denial-of-service 1230 attacks. A node may send a large amount of data over a TCP 1231 connection, requiring the receiving node to handle the data, attempt 1232 to stop the flood of data by sending a REFUSE_BUNDLE message, or 1233 forcibly terminate the connection. This burden could cause denial of 1234 service on other, well-behaving connections. There is also nothing 1235 to prevent a malicious node from continually establishing connections 1236 and repeatedly trying to send copious amounts of bundle data. A 1237 listening node MAY take countermeasures such as ignoring TCP SYN 1238 messages, closing TCP connections as soon as they are established, 1239 waiting before sending the contact header, sending a SHUTDOWN message 1240 quickly or with a delay, etc. 1242 8. IANA Considerations 1244 In this section, registration procedures are as defined in [RFC5226] 1246 8.1. Port Number 1248 Port number 4556 has been previously assigned as the default port for 1249 the TCP convergence layer in [RFC7242]. This assignment is unchanged 1250 by protocol version 4. 1252 +------------------------+-------------------------------------+ 1253 | Parameter | Value | 1254 +------------------------+-------------------------------------+ 1255 | Service Name: | dtn-bundle | 1256 | | | 1257 | Transport Protocol(s): | TCP | 1258 | | | 1259 | Assignee: | Simon Perreault | 1260 | | | 1261 | Contact: | Simon Perreault | 1262 | | | 1263 | Description: | DTN Bundle TCP CL Protocol | 1264 | | | 1265 | Reference: | [RFC7242] | 1266 | | | 1267 | Port Number: | 4556 | 1268 +------------------------+-------------------------------------+ 1270 8.2. Protocol Versions 1272 IANA has created, under the "Bundle Protocol" registry, a sub- 1273 registry titled "Bundle Protocol TCP Convergence-Layer Version 1274 Numbers" and initialized it with the following table. The 1275 registration procedure is RFC Required. 1277 +-------+-------------+---------------------+ 1278 | Value | Description | Reference | 1279 +-------+-------------+---------------------+ 1280 | 0 | Reserved | [RFC7242] | 1281 | | | | 1282 | 1 | Reserved | [RFC7242] | 1283 | | | | 1284 | 2 | Reserved | [RFC7242] | 1285 | | | | 1286 | 3 | TCPCL | [RFC7242] | 1287 | | | | 1288 | 4 | TCPCLbis | This specification. | 1289 | | | | 1290 | 5-255 | Unassigned | 1291 +-------+-------------+---------------------+ 1293 8.3. Message Types 1295 IANA has created, under the "Bundle Protocol" registry, a sub- 1296 registry titled "Bundle Protocol TCP Convergence-Layer Message Types" 1297 and initialized it with the contents below. The registration 1298 procedure is RFC Required. 1300 +----------+---------------+ 1301 | Code | Message Type | 1302 +----------+---------------+ 1303 | 0x0 | Reserved | 1304 | | | 1305 | 0x1 | DATA_SEGMENT | 1306 | | | 1307 | 0x2 | ACK_SEGMENT | 1308 | | | 1309 | 0x3 | REFUSE_BUNDLE | 1310 | | | 1311 | 0x4 | KEEPALIVE | 1312 | | | 1313 | 0x5 | SHUTDOWN | 1314 | | | 1315 | 0x6 | LENGTH | 1316 | | | 1317 | 0x7 | REJECT | 1318 | | | 1319 | 0x8 | STARTTLS | 1320 | | | 1321 | 0x9--0xf | Unassigned | 1322 +----------+---------------+ 1324 Message Type Codes 1326 8.4. Connection Option Types 1328 IANA will createe, under the "Bundle Protocol" registry, a sub- 1329 registry titled "Bundle Protocol TCP Convergence-Layer Option Types" 1330 and initialize it with the contents below. The registration 1331 procedure is RFC Required for values less than 2^14 (16384). Values 1332 greater than or equal to 2^14 (16384) are to be used for experimental 1333 option types. 1335 +-------------+--------------------------+ 1336 | Code | Option Type | 1337 +-------------+--------------------------+ 1338 | 0x0 | Reserved | 1339 | | | 1340 | 0x1 | Handle LENGTH | 1341 | | | 1342 | 0x2 | Acknowledge Intermediate | 1343 | | | 1344 | 0x3 | Acknowledge Bundle | 1345 | | | 1346 | 0x4 | Keepalive | 1347 | | | 1348 | 0x5 | Peer EID | 1349 | | | 1350 | 0x6 | BP Versions | 1351 | | | 1352 | 0x7 | Segment MRU | 1353 | | | 1354 | 0x8 | Handle TLS | 1355 | | | 1356 | 0x9--0x3ffe | Unassigned | 1357 | | | 1358 | 0x3fff-- | Experimental | 1359 +-------------+--------------------------+ 1361 Message Type Codes 1363 8.5. REFUSE_BUNDLE Reason Codes 1365 IANA has created, under the "Bundle Protocol" registry, a sub- 1366 registry titled "Bundle Protocol TCP Convergence-Layer REFUSE_BUNDLE 1367 Reason Codes" and initialized it with the contents of Table 3. The 1368 registration procedure is RFC Required. 1370 +----------+---------------------------+ 1371 | Code | Refusal Reason | 1372 +----------+---------------------------+ 1373 | 0x0 | Unknown | 1374 | | | 1375 | 0x1 | Completed | 1376 | | | 1377 | 0x2 | No Resources | 1378 | | | 1379 | 0x3 | Retransmit | 1380 | | | 1381 | 0x4--0x7 | Unassigned | 1382 | | | 1383 | 0x8--0xf | Reserved for future usage | 1384 +----------+---------------------------+ 1386 REFUSE_BUNDLE Reason Codes 1388 8.6. SHUTDOWN Reason Codes 1390 IANA has created, under the "Bundle Protocol" registry, a sub- 1391 registry titled "Bundle Protocol TCP Convergence-Layer SHUTDOWN 1392 Reason Codes" and initialized it with the contents of Table 4. The 1393 registration procedure is RFC Required. 1395 +------------+------------------+ 1396 | Code | Shutdown Reason | 1397 +------------+------------------+ 1398 | 0x00 | Idle timeout | 1399 | | | 1400 | 0x01 | Version mismatch | 1401 | | | 1402 | 0x02 | Busy | 1403 | | | 1404 | 0x03 | Contact Failure | 1405 | | | 1406 | 0x04 | TLS failure | 1407 | | | 1408 | 0x05--0xFF | Unassigned | 1409 +------------+------------------+ 1411 SHUTDOWN Reason Codes 1413 8.7. REJECT Reason Codes 1415 EDITOR NOTE: sub-registry to-be-created upon publication of this 1416 specification. 1418 IANA will create, under the "Bundle Protocol" registry, a sub- 1419 registry titled "Bundle Protocol TCP Convergence-Layer REJECT Reason 1420 Codes" and initialized it with the contents of Table 4. The 1421 registration procedure is RFC Required. 1423 +-----------+----------------------+ 1424 | Code | Rejection Reason | 1425 +-----------+----------------------+ 1426 | 0x00 | reserved | 1427 | | | 1428 | 0x01 | Message Type Unknown | 1429 | | | 1430 | 0x02 | Message Unsupported | 1431 | | | 1432 | 0x03 | Message Unexpected | 1433 | | | 1434 | 0x04-0xFF | Unassigned | 1435 +-----------+----------------------+ 1437 REJECT Reason Codes 1439 9. Acknowledgments 1441 This memo is based on comments on implementation of [RFC7242] 1442 provided from Scott Burleigh. 1444 10. References 1446 10.1. Normative References 1448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1449 Requirement Levels", BCP 14, RFC 2119, 1450 DOI 10.17487/RFC2119, March 1997, 1451 . 1453 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 1454 Specification", RFC 5050, DOI 10.17487/RFC5050, November 1455 2007, . 1457 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1458 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1459 DOI 10.17487/RFC5226, May 2008, 1460 . 1462 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1463 (TLS) Protocol Version 1.2", RFC 5246, 1464 DOI 10.17487/RFC5246, August 2008, 1465 . 1467 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 1468 Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 1469 2011, . 1471 [I-D.ietf-dtn-bpbis] 1472 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol", 1473 draft-ietf-dtn-bpbis-04 (work in progress), July 2016. 1475 [refs.IANA-BP] 1476 IANA, "Bundle Protocol registry", May 2016. 1478 10.2. Informative References 1480 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1481 RFC 2595, DOI 10.17487/RFC2595, June 1999, 1482 . 1484 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 1485 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 1486 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 1487 April 2007, . 1489 [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, 1490 "Bundle Security Protocol Specification", RFC 6257, 1491 DOI 10.17487/RFC6257, May 2011, 1492 . 1494 [RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant 1495 Networking TCP Convergence-Layer Protocol", RFC 7242, 1496 DOI 10.17487/RFC7242, June 2014, 1497 . 1499 [I-D.ietf-dtn-bpsec] 1500 Birrane, E. and K. McKeever, "Bundle Protocol Security 1501 Specification", draft-ietf-dtn-bpsec-02 (work in 1502 progress), July 2016. 1504 Appendix A. Significant changes from RFC7242 1506 The areas in which changes from [RFC7242] have been made to existing 1507 messages are: 1509 o Added a bundle identification number to all bundle-related 1510 messages (LENGTH, DATA_SEGMENT, ACK_SEGMENT, REFUSE_BUNDLE). 1512 o Added bundle protocol version negotation to contact header. 1514 o Use flags in ACK_SEGMENT to mirror flags from DATA_SEGMENT. 1516 The areas in which extensions from [RFC7242] have been made as new 1517 messages and codes are: 1519 o Changed contact header negotation from single-octet bit flags to 1520 extensible TLV-encoded options. 1522 o Added contact option to negotiate maximum segment size (per each 1523 direction). 1525 o Added contact option to negotiate acceptable Bundle Protoocl 1526 versions. 1528 o Added REJECT message to indicate an unknown or unhandled message 1529 was received. 1531 o Added STARTTLS message and connection security mechanism. 1533 o Added TLS failure SHUTDOWN reason code. 1535 Authors' Addresses 1537 Brian Sipos 1538 RKF Engineering Solutions, LLC 1539 1229 19th Street NW 1540 Wasington, DC 20036 1541 US 1543 Email: BSipos@rkf-eng.com 1545 Michael Demmer 1546 University of California, Berkeley 1547 Computer Science Division 1548 445 Soda Hall 1549 Berkeley, CA 94720-1776 1550 US 1552 Email: demmer@cs.berkeley.edu 1554 Joerg Ott 1555 Aalto University 1556 Department of Communications and Networking 1557 PO Box 13000 1558 Aalto 02015 1559 Finland 1561 Email: jo@netlab.tkk.fi 1562 Simon Perreault 1563 Quebec, QC 1564 Canada 1566 Email: simon@per.reau.lt