idnits 2.17.1 draft-ietf-dtn-tcpclv4-13.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 directly say this. It does mention RFC7242 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 20, 2019) is 1711 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: 'SESSTERM' is mentioned on line 753, but not defined == Missing Reference: 'PCH' is mentioned on line 631, but not defined == Missing Reference: 'PSI' is mentioned on line 686, but not defined == Missing Reference: 'SI' is mentioned on line 665, but not defined == Missing Reference: 'I1' is mentioned on line 854, but not defined == Missing Reference: 'L1' is mentioned on line 842, but not defined == Missing Reference: 'L2' is mentioned on line 842, but not defined == Missing Reference: 'L3' is mentioned on line 848, but not defined == Outdated reference: A later version (-31) exists of draft-ietf-dtn-bpbis-14 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-27) exists of draft-ietf-dtn-bpsec-10 Summary: 4 errors (**), 0 flaws (~~), 12 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: February 21, 2020 J. Ott 7 Aalto University 8 S. Perreault 9 August 20, 2019 11 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 12 draft-ietf-dtn-tcpclv4-13 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 of RFC7242 and updates to the Bundle Protocol 20 contents, encodings, and convergence layer requirements in Bundle 21 Protocol Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 22 bundles as its service data unit being transported and provides a 23 reliable transport of such bundles. Several new IANA registries are 24 defined for TCPCLv4 which define some behaviors inherited from 25 TCPCLv3 but 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 February 21, 2020. 44 Copyright Notice 46 Copyright (c) 2019 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 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 64 2.1. Definitions Specific to the TCPCL Protocol . . . . . . . 5 65 3. General Protocol Description . . . . . . . . . . . . . . . . 8 66 3.1. Convergence Layer Services . . . . . . . . . . . . . . . 8 67 3.2. TCPCL Session Overview . . . . . . . . . . . . . . . . . 10 68 3.3. TCPCL States and Transitions . . . . . . . . . . . . . . 12 69 3.4. Transfer Segmentation Policies . . . . . . . . . . . . . 18 70 3.5. Example Message Exchange . . . . . . . . . . . . . . . . 19 71 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 21 72 4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 21 73 4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 22 74 4.3. Contact Validation and Negotiation . . . . . . . . . . . 23 75 4.4. Session Security . . . . . . . . . . . . . . . . . . . . 24 76 4.4.1. TLS Handshake . . . . . . . . . . . . . . . . . . . . 24 77 4.4.2. TLS Authentication . . . . . . . . . . . . . . . . . 25 78 4.4.3. Example TLS Initiation . . . . . . . . . . . . . . . 26 79 4.5. Message Header . . . . . . . . . . . . . . . . . . . . . 27 80 4.6. Session Initialization Message (SESS_INIT) . . . . . . . 28 81 4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 30 82 4.8. Session Extension Items . . . . . . . . . . . . . . . . . 31 83 5. Established Session Operation . . . . . . . . . . . . . . . . 32 84 5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 32 85 5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 32 86 5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 33 87 5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 34 88 5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 35 89 5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 35 90 5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 37 91 5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 38 92 5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 41 93 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 43 94 6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 43 95 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 45 96 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 45 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 46 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 99 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 47 100 9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 48 101 9.3. Session Extension Types . . . . . . . . . . . . . . . . . 48 102 9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 49 103 9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 50 104 9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 50 105 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 51 106 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 52 107 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 108 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 109 11.1. Normative References . . . . . . . . . . . . . . . . . . 53 110 11.2. Informative References . . . . . . . . . . . . . . . . . 54 111 Appendix A. Significant changes from RFC7242 . . . . . . . . . . 55 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 114 1. Introduction 116 This document describes the TCP-based convergence-layer protocol for 117 Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to- 118 end architecture providing communications in and/or through highly 119 stressed environments, including those with intermittent 120 connectivity, long and/or variable delays, and high bit error rates. 121 More detailed descriptions of the rationale and capabilities of these 122 networks can be found in "Delay-Tolerant Network Architecture" 123 [RFC4838]. 125 An important goal of the DTN architecture is to accommodate a wide 126 range of networking technologies and environments. The protocol used 127 for DTN communications is the Bundle Protocol Version 7 (BPv7) 128 [I-D.ietf-dtn-bpbis], an application-layer protocol that is used to 129 construct a store-and-forward overlay network. BPv7 requires the 130 services of a "convergence-layer adapter" (CLA) to send and receive 131 bundles using the service of some "native" link, network, or Internet 132 protocol. This document describes one such convergence-layer adapter 133 that uses the well-known Transmission Control Protocol (TCP). This 134 convergence layer is referred to as TCP Convergence Layer Version 4 135 (TCPCLv4). For the remainder of this document, the abbreviation "BP" 136 without the version suffix refers to BPv7. For the remainder of this 137 document, the abbreviation "TCPCL" without the version suffix refers 138 to TCPCLv4. 140 The locations of the TCPCL and the BP in the Internet model protocol 141 stack (described in [RFC1122]) are shown in Figure 1. In particular, 142 when BP is using TCP as its bearer with TCPCL as its convergence 143 layer, both BP and TCPCL reside at the application layer of the 144 Internet model. 146 +-------------------------+ 147 | DTN Application | -\ 148 +-------------------------| | 149 | Bundle Protocol (BP) | -> Application Layer 150 +-------------------------+ | 151 | TCP Conv. Layer (TCPCL) | | 152 +-------------------------+ | 153 | TLS (optional) | -/ 154 +-------------------------+ 155 | TCP | ---> Transport Layer 156 +-------------------------+ 157 | IPv4/IPv6 | ---> Network Layer 158 +-------------------------+ 159 | Link-Layer Protocol | ---> Link Layer 160 +-------------------------+ 162 Figure 1: The Locations of the Bundle Protocol and the TCP 163 Convergence-Layer Protocol above the Internet Protocol Stack 165 1.1. Scope 167 This document describes the format of the protocol data units passed 168 between entities participating in TCPCL communications. This 169 document does not address: 171 o The format of protocol data units of the Bundle Protocol, as those 172 are defined elsewhere in [I-D.ietf-dtn-bpbis]. This includes the 173 concept of bundle fragmentation or bundle encapsulation. The 174 TCPCL transfers bundles as opaque data blocks. 176 o Mechanisms for locating or identifying other bundle entities 177 (peers) within a network or across an internet. The mapping of 178 Node ID to potential CL protocol and network address is left to 179 implementation and configuration of the BP Agent and its various 180 potential routing strategies. 182 o Logic for routing bundles along a path toward a bundle's endpoint. 183 This CL protocol is involved only in transporting bundles between 184 adjacent nodes in a routing sequence. 186 o Policies or mechanisms for assigning X.509 certificates, 187 provisioning or deploying certificates and private keys, or 188 configuring security parameters on an individual BP node or across 189 a network. 191 Any TCPCL implementation requires a BP agent to perform those above 192 listed functions in order to perform end-to-end bundle delivery. 194 2. Requirements Language 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 198 "OPTIONAL" in this document are to be interpreted as described in BCP 199 14 [RFC2119] [RFC8174] when, and only when, they appear in all 200 capitals, as shown here. 202 2.1. Definitions Specific to the TCPCL Protocol 204 This section contains definitions specific to the TCPCL protocol. 206 TCPCL Entity: This is the notional TCPCL application that initiates 207 TCPCL sessions. This design, implementation, configuration, and 208 specific behavior of such an entity is outside of the scope of 209 this document. However, the concept of an entity has utility 210 within the scope of this document as the container and initiator 211 of TCPCL sessions. The relationship between a TCPCL entity and 212 TCPCL sessions is defined as follows: 214 A TCPCL Entity MAY actively initiate any number of TCPCL 215 Sessions and should do so whenever the entity is the initial 216 transmitter of information to another entity in the network. 218 A TCPCL Entity MAY support zero or more passive listening 219 elements that listen for connection requests from other TCPCL 220 Entities operating on other entitys in the network. 222 A TCPCL Entity MAY passivley initiate any number of TCPCL 223 Sessions from requests received by its passive listening 224 element(s) if the entity uses such elements. 226 These relationships are illustrated in Figure 2. For most TCPCL 227 behavior within a session, the two entities are symmetric and 228 there is no protocol distinction between them. Some specific 229 behavior, particularly during session establishment, distinguishes 230 between the active entity and the passive entity. For the 231 remainder of this document, the term "entity" without the prefix 232 "TCPCL" refers to a TCPCL entity. 234 TCP Connection: The term Connection in this specification 235 exclusively refers to a TCP connection and any and all behaviors, 236 sessions, and other states association with that TCP connection. 238 TCPCL Session: A TCPCL session (as opposed to a TCP connection) is a 239 TCPCL communication relationship between two TCPCL entities. 240 Within a single TCPCL session there are two possible transfer 241 streams; one in each direction, with one stream from each entity 242 being the outbound stream and the other being the inbound stream. 243 The lifetime of a TCPCL session is bound to the lifetime of an 244 underlying TCP connection. A TCPCL session is terminated when the 245 TCP connection ends, due either to one or both entities actively 246 terminating the TCP connection or due to network errors causing a 247 failure of the TCP connection. For the remainder of this 248 document, the term "session" without the prefix "TCPCL" refers to 249 a TCPCL session. 251 Session parameters: These are a set of values used to affect the 252 operation of the TCPCL for a given session. The manner in which 253 these parameters are conveyed to the bundle entity and thereby to 254 the TCPCL is implementation dependent. However, the mechanism by 255 which two entities exchange and negotiate the values to be used 256 for a given session is described in Section 4.3. 258 Transfer Stream: A Transfer stream is a uni-directional user-data 259 path within a TCPCL Session. Messages sent over a transfer stream 260 are serialized, meaning that one set of user data must complete 261 its transmission prior to another set of user data being 262 transmitted over the same transfer stream. Each uni-directional 263 stream has a single sender entity and a single receiver entity. 265 Transfer: This refers to the procedures and mechanisms for 266 conveyance of an individual bundle from one node to another. Each 267 transfer within TCPCL is identified by a Transfer ID number which 268 is unique only to a single direction within a single Session. 270 Transfer Segment: A subset of a transfer of user data being 271 communicated over a trasnfer stream. 273 Idle Session: A TCPCL session is idle while the only messages being 274 transmitted or received are KEEPALIVE messages. 276 Live Session: A TCPCL session is live while any messages are being 277 transmitted or received. 279 Reason Codes: The TCPCL uses numeric codes to encode specific 280 reasons for individual failure/error message types. 282 The relationship between connections, sessions, and streams is shown 283 in Figure 3. 285 +--------------------------------------------+ 286 | TCPCL Entity | 287 | | +----------------+ 288 | +--------------------------------+ | | |-+ 289 | | Actively Inititated Session #1 +------------->| Other | | 290 | +--------------------------------+ | | TCPCL Entity's | | 291 | ... | | Passive | | 292 | +--------------------------------+ | | Listener | | 293 | | Actively Inititated Session #n +------------->| | | 294 | +--------------------------------+ | +----------------+ | 295 | | +-----------------+ 296 | +---------------------------+ | 297 | +---| +---------------------------+ | +----------------+ 298 | | | | Optional Passive | | | |-+ 299 | | +-| Listener(s) +<-------------+ | | 300 | | +---------------------------+ | | | | 301 | | | | Other | | 302 | | +---------------------------------+ | | TCPCL Entity's | | 303 | +--->| Passively Inititated Session #1 +-------->| Active | | 304 | | +---------------------------------+ | | Initiator(s) | | 305 | | | | | | 306 | | +---------------------------------+ | | | | 307 | +--->| Passively Inititated Session #n +-------->| | | 308 | +---------------------------------+ | +----------------+ | 309 | | +-----------------+ 310 +--------------------------------------------+ 312 Figure 2: The relationships between TCPCL entities 314 +----------------------------+ +--------------------------+ 315 | TCPCL Session | | TCPCL "Other" Session | 316 | | | | 317 | +-----------------------+ | | +---------------------+ | 318 | | TCP Connection | | | | TCP Connection | | 319 | | | | | | | | 320 | | +-------------------+ | | | | +-----------------+ | | 321 | | | Optional Inbound | | | | | | Peer Outbound | | | 322 | | | Transfer Stream |<-[Seg]--[Seg]--[Seg]-| | Transfer Stream | | | 323 | | | ----- | | | | | | ----- | | | 324 | | | RECEIVER | | | | | | SENDER | | | 325 | | +-------------------+ | | | | +-----------------+ | | 326 | | | | | | | | 327 | | +-------------------+ | | | | +-----------------+ | | 328 | | | Optional Outbound | | | | | | Peer Inbound | | | 329 | | | Transfer Stream |------[Seg]---[Seg]---->| Transfer Stream | | | 330 | | | ----- | | | | | | ----- | | | 331 | | | SENDER | | | | | | RECEIVER | | | 332 | | +-------------------+ | | | | +-----------------+ | | 333 | +-----------------------+ | | +---------------------+ | 334 +----------------------------+ +--------------------------+ 336 Figure 3: The relationship within a TCPCL Session of its two streams 338 3. General Protocol Description 340 The service of this protocol is the transmission of DTN bundles via 341 the Transmission Control Protocol (TCP). This document specifies the 342 encapsulation of bundles, procedures for TCP setup and teardown, and 343 a set of messages and node requirements. The general operation of 344 the protocol is as follows. 346 3.1. Convergence Layer Services 348 This version of the TCPCL provides the following services to support 349 the overlaying Bundle Protocol agent. In all cases, this is not an 350 API defintion but a logical description of how the CL can interact 351 with the BP agent. Each of these interactions can be associated with 352 any number of additional metadata items as necessary to support the 353 operation of the CL or BP agent. 355 Attempt Session: The TCPCL allows a BP agent to pre-emptively 356 attempt to establish a TCPCL session with a peer entity. Each 357 session attempt can send a different set of session negotiation 358 parameters as directed by the BP agent. 360 Terminate Session: The TCPCL allows a BP agent to pre-emptively 361 terminate an established TCPCL session with a peer entity. The 362 terminate request is on a per-session basis. 364 Session State Changed: The TCPCL supports indication when the 365 session state changes. The top-level session states indicated 366 are: 368 Connecting: A TCP connection is being established. This state 369 only applies to the active entity. 371 Contact Negotating: A TCP connection has been made (as either 372 active or passive entity) and contact negotiation has begun. 374 Session Negotiating: Contact negotation has been completed 375 (including possible TLS use) and session negotiation has begun. 377 Established: The session has been fully established and is ready 378 for its first transfer. 380 Ending: The entity received a SESS_TERM message and is in the 381 ending state. 383 Terminated: The session has finished normal termination 384 sequencing. 386 Failed: The session ended without normal termination sequencing. 388 Session Idle Changed: The TCPCL supports indication when the live/ 389 idle sub-state of the session changes. This occurs only when the 390 top-level session state is "Established". The session transitions 391 from Idle to Live at the at the start of a transfer in either 392 transfer stream; the session transitions from Live to Idle at the 393 end of a transfer when the other transfer stream does not have an 394 ongoing transfer. Because TCPCL transmits serially over a TCP 395 connection, it suffers from "head of queue blocking" this 396 indication provides information about when a session is available 397 for immediate transfer start. 399 Begin Transmission: The principal purpose of the TCPCL is to allow a 400 BP agent to transmit bundle data over an established TCPCL 401 session. Transmission request is on a per-session basis, the CL 402 does not necessarily perform any per-session or inter-session 403 queueing. Any queueing of transmissions is the obligation of the 404 BP agent. 406 Transmission Success: The TCPCL supports positive indication when a 407 bundle has been fully transferred to a peer entity. 409 Transmission Intermediate Progress: The TCPCL supports positive 410 indication of intermediate progress of transferr to a peer entity. 411 This intermediate progress is at the granularity of each 412 transferred segment. 414 Transmission Failure: The TCPCL supports positive indication of 415 certain reasons for bundle transmission failure, notably when the 416 peer entity rejects the bundle or when a TCPCL session ends before 417 transferr success. The TCPCL itself does not have a notion of 418 transfer timeout. 420 Reception Initialized: The TCPCL supports indication to the reciver 421 just before any transmssion data is sent. This corresponds to 422 reception of the XFER_SEGMENT message with the START flag set. 424 Interrupt Reception: The TCPCL allows a BP agent to interrupt an 425 individual transfer before it has fully completed (successfully or 426 not). Interruption can occur any time after the reception is 427 initialized. 429 Reception Success: The TCPCL supports positive indication when a 430 bundle has been fully transferred from a peer entity. 432 Reception Intermediate Progress: The TCPCL supports positive 433 indication of intermediate progress of transfer from the peer 434 entity. This intermediate progress is at the granularity of each 435 transferred segment. Intermediate reception indication allows a 436 BP agent the chance to inspect bundle header contents before the 437 entire bundle is available, and thus supports the "Reception 438 Interruption" capability. 440 Reception Failure: The TCPCL supports positive indication of certain 441 reasons for reception failure, notably when the local entity 442 rejects an attempted transfer for some local policy reason or when 443 a TCPCL session ends before transfer success. The TCPCL itself 444 does not have a notion of transfer timeout. 446 3.2. TCPCL Session Overview 448 First, one node establishes a TCPCL session to the other by 449 initiating a TCP connection in accordance with [RFC0793]. After 450 setup of the TCP connection is complete, an initial contact header is 451 exchanged in both directions to establish a shared TCPCL version and 452 possibly initiate TLS security. Once contact negotiation is 453 complete, TCPCL messaging is available and the session negotiation is 454 used to set parameters of the TCPCL session. One of these parameters 455 is a Node ID of each TCPCL Entity. This is used to assist in routing 456 and forwarding messages by the BP Agent and is part of the 457 authentication capability provided by TLS. 459 Once negotiated, the parameters of a TCPCL session cannot change and 460 if there is a desire by either peer to transfer data under different 461 parameters then a new session must be established. This makes CL 462 logic simpler but relies on the assumption that establishing a TCP 463 connection is lightweight enough that TCP connection overhead is 464 negligable compared to TCPCL data sizes. 466 Once the TCPCL session is established and configured in this way, 467 bundles can be transferred in either direction. Each transfer is 468 performed by an sequence of logical segments of data within 469 XFER_SEGMENT messages. Multiple bundles can be transmitted 470 consecutively in a single direction on a single TCPCL connection. 471 Segments from different bundles are never interleaved. Bundle 472 interleaving can be accomplished by fragmentation at the BP layer or 473 by establishing multiple TCPCL sessions between the same peers. 474 There is no fundamental limit on the number of TCPCL sessions which a 475 single node can establish beyond the limit imposed by the number of 476 available (ephemeral) TCP ports of the passive peer. 478 A feature of this protocol is for the receiving node to send 479 acknowledgment (XFER_ACK) messages as bundle data segments arrive. 480 The rationale behind these acknowledgments is to enable the sender 481 node to determine how much of the bundle has been received, so that 482 in case the session is interrupted, it can perform reactive 483 fragmentation to avoid re-sending the already transmitted part of the 484 bundle. In addition, there is no explicit flow control on the TCPCL 485 layer. 487 A TCPCL receiver can interrupt the transmission of a bundle at any 488 point in time by replying with a XFER_REFUSE message, which causes 489 the sender to stop transmission of the associated bundle (if it 490 hasn't already finished transmission) Note: This enables a cross- 491 layer optimization in that it allows a receiver that detects that it 492 already has received a certain bundle to interrupt transmission as 493 early as possible and thus save transmission capacity for other 494 bundles. 496 For sessions that are idle, a KEEPALIVE message is sent at a 497 negotiated interval. This is used to convey node live-ness 498 information during otherwise message-less time intervals. 500 A SESS_TERM message is used to start the ending of a TCPCL session 501 (see Section 6.1). During shutdown sequencing, in-progress transfers 502 can be completed but no new transfers can be initiated. A SESS_TERM 503 message can also be used to refuse a session setup by a peer (see 504 Section 4.3). It is an implementation matter to determine whether or 505 not to close a TCPCL session while there are no transfers queued or 506 in-progress. 508 Once a session is established, TCPCL is a symmetric protocol between 509 the peers. Both sides can start sending data segments in a session, 510 and one side's bundle transfer does not have to complete before the 511 other side can start sending data segments on its own. Hence, the 512 protocol allows for a bi-directional mode of communication. Note 513 that in the case of concurrent bidirectional transmission, 514 acknowledgment segments MAY be interleaved with data segments. 516 3.3. TCPCL States and Transitions 518 The states of a nominal TCPCL session (i.e. without session failures) 519 are indicated in Figure 4. 521 +-------+ 522 | START | 523 +-------+ 524 | 525 TCP Establishment 526 | 527 V 528 +-----------+ +---------------------+ 529 | TCP |----------->| Contact / Session | 530 | Connected | | Negotiation | 531 +-----------+ +---------------------+ 532 | 533 +-----Session Parameters-----+ 534 | Negotiated 535 V 536 +-------------+ +-------------+ 537 | Established |----New Transfer---->| Established | 538 | Session | | Session | 539 | Idle |<---Transfers Done---| Live | 540 +-------------+ +-------------+ 541 | | 542 +------------------------------------+ 543 | 544 [SESSTERM] Exchange 545 | 546 V 547 +-------------+ 548 | Established | +-------------+ 549 | Session |----Transfers------>| TCP | 550 | Ending | Done | Terminating | 551 +-------------+ +-------------+ 552 | 553 +----------TCP Close Message----------+ 554 | 555 V 556 +-------+ 557 | END | 558 +-------+ 560 Figure 4: Top-level states of a TCPCL session 562 Notes on Established Session states: 564 Session "Live" means transmitting or reeiving over a transfer 565 stream. 567 Session "Idle" means no transmission/reception over a transfer 568 stream. 570 Session "Ending" means no new transfers will be allowed. 572 Contact negotation involves exchanging a Contact Header (CH) in both 573 directions and deriving a negotiated state from the two headers. The 574 contact negotiation sequencing is performed either as the active or 575 passive peer, and is illustrated in Figure 5 and Figure 6 576 respectively which both share the data validation and analyze final 577 states of the "[PCH]" activity of Figure 7 and the "[TCPCLOSE]" 578 activity which indicates TCP connection close. Successful 579 negotiation results in one of the Session Initiation "[SI]" 580 activities being performed. 582 +-------+ 583 | START | 584 +-------+ 585 | 586 TCP Connecting 587 V 588 +-----------+ 589 | TCP | +---------+ 590 | Connected |--Send CH-->| Waiting |--Timeout-->[TCPCLOSE] 591 +-----------+ +---------+ 592 | 593 Recevied CH 594 V 595 [PCH] 597 Figure 5: Contact Initiation as Active peer 599 +-----------+ +---------+ 600 | TCP |--Wait for-->| Waiting |--Timeout-->[TCPCLOSE] 601 | Connected | CH +---------+ 602 +-----------+ | 603 Received CH 604 V 605 +-----------------+ 606 | Preparing reply |--Send CH-->[PSI] 607 +-----------------+ 609 Figure 6: Contact Initiation as Passive peer 611 +-----------+ 612 | Peer CH | 613 | available | 614 +-----------+ 615 | 616 Validate and 617 Negotiate 618 V 619 +------------+ 620 | Negotiated |----Failure---->[TCPCLOSE] 621 +------------+ ^ 622 | | | 623 No TLS +----Negotiate---+ | 624 V TLS | Failure 625 +-----------+ V | 626 | TCPCL | +---------------+ 627 | Messaging |<--Success--| TLS Finished | 628 | Available | +---------------+ 629 +-----------+ 631 Figure 7: Processing of Contact Header [PCH] 633 Session negotation involves exchanging a session initialization 634 (SESS_INIT) message in both directions and deriving a negotiated 635 state from the two messages. The session negotiation sequencing is 636 performed either as the active or passive peer, and is illustrated in 637 Figure 8 and Figure 9 respectively which both share the data 638 validation and analyze final states of Figure 10. The validation 639 here includes certificate validation and authentication when TLS is 640 used for the session. 642 +-----------+ 643 | TCPCL | +---------+ 644 | Messaging |--Send SESS_INIT-->| Waiting |--Timeout-->[SESSTERM] 645 | Available | +---------+ 646 +-----------+ | 647 Recevied SESS_INIT 648 | 649 V 650 [PSI] 652 Figure 8: Session Initiation [SI] as Active peer 654 +-----------+ 655 | TCPCL | +---------+ 656 | Messaging |----Wait for ---->| Waiting |--Timeout-->[SESSTERM] 657 | Available | SESS_INIT +---------+ 658 +-----------+ | 659 Recevied SESS_INIT 660 | 661 +-----------------+ 662 | Preparing reply |--Send SESS_INIT-->[PSI] 663 +-----------------+ 665 Figure 9: Session Initiation [SI] as Passive peer 667 +----------------+ 668 | Peer SESS_INIT | 669 | available | 670 +----------------+ 671 | 672 Validate and 673 Negotiate 674 V 675 +------------+ 676 | Negotiated |---Failure--->[SESSTERM] 677 +------------+ 678 | 679 Success 680 V 681 +--------------+ 682 | Established | 683 | Session Idle | 684 +--------------+ 686 Figure 10: Processing of Session Initiation [PSI] 688 Transfers can occur after a session is established and it's not in 689 the ending state. Each transfer occurs within a single logical 690 transfer stream between a sender and a receiver, as illustrated in 691 Figure 11 and Figure 12 respectively. 693 +--Send XFER_SEGMENT--+ 694 +--------+ | | 695 | Stream | +-------------+ | 696 | Idle |---Send XFER_SEGMENT-->| In Progress |<------------+ 697 +--------+ +-------------+ 698 | 699 +---------All segments sent-------+ 700 | 701 V 702 +---------+ +--------+ 703 | Waiting |---- Receive Final---->| Stream | 704 | for Ack | XFER_ACK | IDLE | 705 +---------+ +--------+ 707 Figure 11: Transfer sender states 709 Notes on transfer sending: 711 Pipelining of transfers can occur when the sending entity begins a 712 new transfer while in the "Waiting for Ack" state. 714 +-Receive XFER_SEGMENT-+ 715 +--------+ | Send XFER_ACK | 716 | Stream | +-------------+ | 717 | Idle |--Receive XFER_SEGMENT-->| In Progress |<-------------+ 718 +--------+ +-------------+ 719 | 720 +--------Sent Final XFER_ACK--------+ 721 | 722 V 723 +--------+ 724 | Stream | 725 | Idle | 726 +--------+ 728 Figure 12: Transfer receiver states 730 Session termination involves one entity initiating the termination of 731 the session and the other entity acknowledging the termination. For 732 either entity, it is the sending of the SESS_TERM message which 733 transitions the session to the ending substate. While a session is 734 being terminated only in-progress transfers can be completed and no 735 new transfers can be started. 737 +-----------+ +---------+ 738 | Session |--Send SESS_TERM-->| Session | 739 | Live/Idle | | Ending | 740 +-----------+ +---------+ 742 Figure 13: Session Termination [SESSTERM] from the Initiator 744 +-----------+ +---------+ 745 | Session |--Send SESS_TERM-->| Session | 746 | Live/Idle | | Ending | 747 +-----------+<------+ +---------+ 748 | | 749 Receive SESS_TERM | 750 | | 751 +-------------+ 753 Figure 14: Session Termination [SESSTERM] from the Responder 755 3.4. Transfer Segmentation Policies 757 Each TCPCL session allows a negotiated transfer segmentation polcy to 758 be applied in each transfer direction. A receiving node can set the 759 Segment MRU in its contact header to determine the largest acceptable 760 segment size, and a transmitting node can segment a transfer into any 761 sizes smaller than the receiver's Segment MRU. It is a network 762 administration matter to determine an appropriate segmentation policy 763 for entities operating TCPCL, but guidance given here can be used to 764 steer policy toward performance goals. It is also advised to 765 consider the Segment MRU in relation to chunking/packetization 766 performed by TLS, TCP, and any intermediate network-layer nodes. 768 Minimum Overhead: For a simple network expected to exchange 769 relatively small bundles, the Segment MRU can be set to be 770 identical to the Transfer MRU which indicates that all transfers 771 can be sent with a single data segment (i.e. no actual 772 segmentation). If the network is closed and all transmitters are 773 known to follow a single-segment transfer policy, then receivers 774 can avoid the necessity of segment reassembly. Because this CL 775 operates over a TCP stream, which suffers from a form of head-of- 776 queue blocking between messages, while one node is transmitting a 777 single XFER_SEGMENT message it is not able to transmit any 778 XFER_ACK or XFER_REFUSE for any associated received transfers. 780 Predictable Message Sizing: In situations where the maximum message 781 size is desired to be well-controlled, the Segment MRU can be set 782 to the largest acceptable size (the message size less XFER_SEGMENT 783 header size) and transmitters can always segment a transfer into 784 maximum-size chunks no larger than the Segment MRU. This 785 guarantees that any single XFER_SEGMENT will not monopolize the 786 TCP stream for too long, which would prevent outgoing XFER_ACK and 787 XFER_REFUSE associated with received transfers. 789 Dynamic Segmentation: Even after negotiation of a Segment MRU for 790 each receiving node, the actual transfer segmentation only needs 791 to guarantee than any individual segment is no larger than that 792 MRU. In a situation where network "goodput" is dynamic, the 793 transfer segmentation size can also be dynamic in order to control 794 message transmission duration. 796 Many other policies can be established in a TCPCL network between the 797 two extremes of minimum overhead (large MRU, single-segment) and 798 predictable message sizing (small MRU, highly segmented). Different 799 policies can be applied to each transfer stream to and from from any 800 particular node. Additionally, future header and transfer extension 801 types can apply further nuance to transfer policies and policy 802 negotiation. 804 3.5. Example Message Exchange 806 The following figure depicts the protocol exchange for a simple 807 session, showing the session establishment and the transmission of a 808 single bundle split into three data segments (of lengths "L1", "L2", 809 and "L3") from Entity A to Entity B. 811 Note that the sending node can transmit multiple XFER_SEGMENT 812 messages without waiting for the corresponding XFER_ACK responses. 813 This enables pipelining of messages on a transfer stream. Although 814 this example only demonstrates a single bundle transmission, it is 815 also possible to pipeline multiple XFER_SEGMENT messages for 816 different bundles without necessarily waiting for XFER_ACK messages 817 to be returned for each one. However, interleaving data segments 818 from different bundles is not allowed. 820 No errors or rejections are shown in this example. 822 Entity A Entity B 823 ======== ======== 824 +-------------------------+ 825 | Contact Header | -> +-------------------------+ 826 +-------------------------+ <- | Contact Header | 827 +-------------------------+ 828 +-------------------------+ 829 | SESS_INIT | -> +-------------------------+ 830 +-------------------------+ <- | SESS_INIT | 831 +-------------------------+ 833 +-------------------------+ 834 | XFER_SEGMENT (start) | -> 835 | Transfer ID [I1] | 836 | Length [L1] | 837 | Bundle Data 0..(L1-1) | 838 +-------------------------+ 839 +-------------------------+ +-------------------------+ 840 | XFER_SEGMENT | -> <- | XFER_ACK (start) | 841 | Transfer ID [I1] | | Transfer ID [I1] | 842 | Length [L2] | | Length [L1] | 843 |Bundle Data L1..(L1+L2-1)| +-------------------------+ 844 +-------------------------+ 845 +-------------------------+ +-------------------------+ 846 | XFER_SEGMENT (end) | -> <- | XFER_ACK | 847 | Transfer ID [I1] | | Transfer ID [I1] | 848 | Length [L3] | | Length [L1+L2] | 849 |Bundle Data | +-------------------------+ 850 | (L1+L2)..(L1+L2+L3-1)| 851 +-------------------------+ 852 +-------------------------+ 853 <- | XFER_ACK (end) | 854 | Transfer ID [I1] | 855 | Length [L1+L2+L3] | 856 +-------------------------+ 858 +-------------------------+ 859 | SESS_TERM | -> +-------------------------+ 860 +-------------------------+ <- | SESS_TERM | 861 +-------------------------+ 863 Figure 15: An example of the flow of protocol messages on a single 864 TCP Session between two entities 866 4. Session Establishment 868 For bundle transmissions to occur using the TCPCL, a TCPCL session 869 MUST first be established between communicating entities. It is up 870 to the implementation to decide how and when session setup is 871 triggered. For example, some sessions MAY be opened proactively and 872 maintained for as long as is possible given the network conditions, 873 while other sessions MAY be opened only when there is a bundle that 874 is queued for transmission and the routing algorithm selects a 875 certain next-hop node. 877 4.1. TCP Connection 879 To establish a TCPCL session, an entity MUST first establish a TCP 880 connection with the intended peer entity, typically by using the 881 services provided by the operating system. Destination port number 882 4556 has been assigned by IANA as the Registered Port number for the 883 TCP convergence layer. Other destination port numbers MAY be used 884 per local configuration. Determining a peer's destination port 885 number (if different from the registered TCPCL port number) is up to 886 the implementation. Any source port number MAY be used for TCPCL 887 sessions. Typically an operating system assigned number in the TCP 888 Ephemeral range (49152-65535) is used. 890 If the entity is unable to establish a TCP connection for any reason, 891 then it is an implementation matter to determine how to handle the 892 connection failure. An entity MAY decide to re-attempt to establish 893 the connection. If it does so, it MUST NOT overwhelm its target with 894 repeated connection attempts. Therefore, the entity MUST retry the 895 connection setup no earlier than some delay time from the last 896 attempt, and it SHOULD use a (binary) exponential back-off mechanism 897 to increase this delay in case of repeated failures. The upper limit 898 on a re-attempt back-off is implementation defined but SHOULD be no 899 longer than one minute before signaling to the BP agent that a 900 connection cannot be made. 902 Once a TCP connection is established, each entity MUST immediately 903 transmit a contact header over the TCP connection. The format of the 904 contact header is described in Section 4.2. Because the TCPCL 905 protocol version in use is part of the initial contact header, nodes 906 using TCPCL version 4 can coexist on a network with nodes using 907 earlier TCPCL versions (with some negotiation needed for 908 interoperation as described in Section 4.3). 910 4.2. Contact Header 912 Once a TCP connection is established, both parties exchange a contact 913 header. This section describes the format of the contact header and 914 the meaning of its fields. 916 Upon receipt of the contact header, both entities perform the 917 validation and negotiation procedures defined in Section 4.3. After 918 receiving the contact header from the other entity, either entity MAY 919 refuse the session by sending a SESS_TERM message with an appropriate 920 reason code. 922 The format for the Contact Header is as follows: 924 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 925 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 926 +---------------+---------------+---------------+---------------+ 927 | magic='dtn!' | 928 +---------------+---------------+---------------+---------------+ 929 | Version | Flags | 930 +---------------+---------------+ 932 Figure 16: Contact Header Format 934 See Section 4.3 for details on the use of each of these contact 935 header fields. 937 The fields of the contact header are: 939 magic: A four-octet field that always contains the octet sequence 940 0x64 0x74 0x6E 0x21, i.e., the text string "dtn!" in US-ASCII (and 941 UTF-8). 943 Version: A one-octet field value containing the value 4 (current 944 version of the TCPCL). 946 Flags: A one-octet field of single-bit flags, interpreted according 947 to the descriptions in Table 1. All reserved header flag bits 948 SHALL be not set by the sender. All reserved header flag bits 949 SHALL be ignored by the receiver. 951 +----------+--------+-----------------------------------------------+ 952 | Name | Code | Description | 953 +----------+--------+-----------------------------------------------+ 954 | CAN_TLS | 0x01 | If bit is set, indicates that the sending | 955 | | | peer is capable of TLS security. | 956 | | | | 957 | Reserved | others | 958 +----------+--------+-----------------------------------------------+ 960 Table 1: Contact Header Flags 962 4.3. Contact Validation and Negotiation 964 Upon reception of the contact header, each node follows the following 965 procedures to ensure the validity of the TCPCL session and to 966 negotiate values for the session parameters. 968 If the magic string is not present or is not valid, the connection 969 MUST be terminated. The intent of the magic string is to provide 970 some protection against an inadvertent TCP connection by a different 971 protocol than the one described in this document. To prevent a flood 972 of repeated connections from a misconfigured application, an entity 973 MAY elect to hold an invalid connection open and idle for some time 974 before ending it. 976 The first negotiation is on the TCPCL protocol version to use. The 977 active node always sends its Contact Header first and waits for a 978 response from the passive node. The active node can repeatedly 979 attempt different protocol versions in descending order until the 980 passive node accepts one with a corresponding Contact Header reply. 981 Only upon response of a Contact Header from the passive node is the 982 TCPCL protocol version established and parameter negotiation begun. 984 During contact initiation, the active TCPCL node SHALL send the 985 highest TCPCL protocol version on a first session attempt for a TCPCL 986 peer. If the active node receives a Contact Header with a different 987 protocol version than the one sent earlier on the TCP connection, the 988 TCP connection SHALL be terminated. If the active node receives a 989 SESS_TERM message with reason of "Version Mismatch", that node MAY 990 attempt further TCPCL sessions with the peer using earlier protocol 991 version numbers in decreasing order. Managing multi-TCPCL-session 992 state such as this is an implementation matter. 994 If the passive node receives a contact header containing a version 995 that is greater than the current version of the TCPCL that the node 996 implements, then the node SHALL shutdown the session with a reason 997 code of "Version mismatch". If the passive node receives a contact 998 header with a version that is lower than the version of the protocol 999 that the node implements, the node MAY either terminate the session 1000 (with a reason code of "Version mismatch") or the node MAY adapt its 1001 operation to conform to the older version of the protocol. The 1002 decision of version fall-back is an implementation matter. 1004 4.4. Session Security 1006 This version of the TCPCL supports establishing a Transport Layer 1007 Security (TLS) session within an existing TCP connection. When TLS 1008 is used within the TCPCL it affects the entire session. Once 1009 established, there is no mechanism available to downgrade a TCPCL 1010 session to non-TLS operation. If this is desired, the entire TCPCL 1011 session MUST be terminated and a new non-TLS-negotiated session 1012 established. 1014 4.4.1. TLS Handshake 1016 The use of TLS is negotated using the Contact Header as described in 1017 Section 4.3. After negotiating an Enable TLS parameter of true, and 1018 before any other TCPCL messages are sent within the session, the 1019 session entities SHALL begin a TLS handshake in accordance with TLS 1020 1.2 [RFC5246] or any successors that are compatible with TLS 1.2. By 1021 convention, this protocol uses the node which initiated the 1022 underlying TCP connection as the "client" role of the TLS handshake 1023 request. 1025 The TLS handshake, if it occurs, is considered to be part of the 1026 contact negotiation before the TCPCL session itself is established. 1027 Specifics about sensitive data exposure are discussed in Section 8. 1029 The parameters within each TLS negotiation are implementation 1030 dependent but any TCPCL node SHALL follow all recommended practices 1031 of BCP 195 [RFC7525], or any updates or successors that become part 1032 of BCP 195. The TLS handshake SHOULD include a Server Name 1033 Indication from the active peer. The TLS handshake SHALL request a 1034 client-side certificate to allow authentication of the active peer. 1035 The passive peer SHOULD supply a certificate within the TLS handshake 1036 to allow authentication of its side of the session. The active peer 1037 SHOULD supply a certificate within the TLS handshake to allow 1038 authentication of its side of the session. All certificates supplied 1039 during TLS handshake SHALL conform with the profile of [RFC5280]. 1040 When a certificate is supplied during TLS handshake, the full 1041 certification chain SHOULD be included unless security policy 1042 indicates that is unnecessary. 1044 If a TLS handshake cannot negotiate a TLS session, both entities of 1045 the TCPCL session SHALL close the TCP connection. At this point the 1046 TCPCL session has not yet been established so there is no TCPCL 1047 session to terminate. This also avoids any potential security issues 1048 assoicated with further TCP communication with an untrusted peer. 1050 After a TLS session is successfully established, the active peer 1051 SHALL send a SESS_INIT message to begin session negotiation. This 1052 session negotation and all subsequent messaging are secured. 1054 4.4.2. TLS Authentication 1056 Using X.509 certificates exchanged during the TLS handshake, each of 1057 the entities can attempt to authenticate its peer at the network 1058 layer (host name and address) and at the application layer (BP Node 1059 ID). The Node ID exchanged in the Session Initialization is likely 1060 to be used by the BP agent for making transfer and routing decisions, 1061 so attempting host name validation is optional while attempting Node 1062 ID validation is required. The logic for attempting validation is 1063 separate from the logic for handling the result of validation, which 1064 is based on local security policy. 1066 Any certificate received during TLS handshake SHALL be validated up 1067 to one or more trusted certificate authority (CA) certificates. If 1068 certificate validation fails or if security policy disallows a 1069 certificate for any reason, the entity SHOULD terminate the session 1070 (with a reason code of "Contact Failure"). 1072 Immediately after the TLS handshake, each side of the TCP connection 1073 SHOULD perform host name validation of its peer in accordance with 1074 [RFC6125] unless it is not needed by security policy. The active 1075 peer SHALL attempt to authenticate the host name (of the passive 1076 peer) used to initiate the TCP connection. The active peer MAY 1077 attempt to authenticate the IP address of the other side of the TCP 1078 connection. The passive peer SHALL attempt to authenticate the IP 1079 address of the other side of the TCP connection. The passive peer 1080 MAY use the IP address to resolve one or more host names of the 1081 active peer and attempt to authenticate those. If host name 1082 validation fails (including failure because the certificate does not 1083 contain any DNS-ID), the entity SHOULD terminate the session (with a 1084 reason code of "Contact Failure") unless security policy allows an 1085 unauthticated host. 1087 Immediately before Session Parameter Negotiation, each side of the 1088 session SHALL perform Node ID validation of its peer as described 1089 below. Node ID validation SHALL succeed if the associated 1090 certificate contains a subjectAltName entry of type 1091 uniformResourceIdentifier whose value matches the Node ID of the 1092 TCPCL entity. URI matching of Node IDs SHALL use the URI comparison 1093 logic of [RFC3986] and scheme-based normalization of those schemes 1094 specified in [I-D.ietf-dtn-bpbis]. This is similar to the URI-ID of 1096 [RFC6125] but does not require any structure to the scheme-specific- 1097 part of the URI. If Node ID validation fails (including failure 1098 because the certificate does not contain any subjectAltName URI), the 1099 entity SHOULD terminate the session (with a reason code of "Contact 1100 Failure") unless security policy allows an unauthticated node. 1102 4.4.3. Example TLS Initiation 1104 A summary of a typical TLS use is shown in the sequence in Figure 17 1105 below. 1107 Entity A Entity B 1108 active peer passive peer 1110 +-------------------------+ 1111 | Open TCP Connnection | -> 1112 +-------------------------+ +-------------------------+ 1113 <- | Accept Connection | 1114 +-------------------------+ 1116 +-------------------------+ 1117 | Contact Header | -> 1118 +-------------------------+ +-------------------------+ 1119 <- | Contact Header | 1120 +-------------------------+ 1122 +-------------------------+ +-------------------------+ 1123 | TLS Negotiation | -> <- | TLS Negotiation | 1124 | (as client) | | (as server) | 1125 +-------------------------+ +-------------------------+ 1127 Host name validation occurs. 1128 Secured TCPCL messaging can begin. 1130 +-------------------------+ +-------------------------+ 1131 | SESS_INIT | -> <- | SESS_INIT | 1132 +-------------------------+ +-------------------------+ 1134 Node ID validation occurs. 1135 Session is established, transfers can begin. 1137 +-------------------------+ +-------------------------+ 1138 | SESS_TERM | -> <- | SESS_TERM | 1139 +-------------------------+ +-------------------------+ 1141 Figure 17: A simple visual example of TCPCL TLS Establishment between 1142 two entities 1144 4.5. Message Header 1146 After the initial exchange of a contact header, all messages 1147 transmitted over the session are identified by a one-octet header 1148 with the following structure: 1150 0 1 2 3 4 5 6 7 1151 +---------------+ 1152 | Message Type | 1153 +---------------+ 1155 Figure 18: Format of the Message Header 1157 The message header fields are as follows: 1159 Message Type: Indicates the type of the message as per Table 2 1160 below. Encoded values are listed in Section 9.5. 1162 +--------------+------+---------------------------------------------+ 1163 | Name | Code | Description | 1164 +--------------+------+---------------------------------------------+ 1165 | SESS_INIT | 0x07 | Contains the session parameter inputs from | 1166 | | | one of the entities, as described in | 1167 | | | Section 4.6. | 1168 | | | | 1169 | SESS_TERM | 0x05 | Indicates that one of the entities | 1170 | | | participating in the session wishes to | 1171 | | | cleanly terminate the session, as described | 1172 | | | in Section 6. | 1173 | | | | 1174 | XFER_SEGMENT | 0x01 | Indicates the transmission of a segment of | 1175 | | | bundle data, as described in Section 5.2.2. | 1176 | | | | 1177 | XFER_ACK | 0x02 | Acknowledges reception of a data segment, | 1178 | | | as described in Section 5.2.3. | 1179 | | | | 1180 | XFER_REFUSE | 0x03 | Indicates that the transmission of the | 1181 | | | current bundle SHALL be stopped, as | 1182 | | | described in Section 5.2.4. | 1183 | | | | 1184 | KEEPALIVE | 0x04 | Used to keep TCPCL session active, as | 1185 | | | described in Section 5.1.1. | 1186 | | | | 1187 | MSG_REJECT | 0x06 | Contains a TCPCL message rejection, as | 1188 | | | described in Section 5.1.2. | 1189 +--------------+------+---------------------------------------------+ 1191 Table 2: TCPCL Message Types 1193 4.6. Session Initialization Message (SESS_INIT) 1195 Before a session is established and ready to transfer bundles, the 1196 session parameters are negotiated between the connected entities. 1197 The SESS_INIT message is used to convey the per-entity parameters 1198 which are used together to negotiate the per-session parameters as 1199 described in Section 4.7. 1201 The format of a SESS_INIT message is as follows in Figure 19. 1203 +-----------------------------+ 1204 | Message Header | 1205 +-----------------------------+ 1206 | Keepalive Interval (U16) | 1207 +-----------------------------+ 1208 | Segment MRU (U64) | 1209 +-----------------------------+ 1210 | Transfer MRU (U64) | 1211 +-----------------------------+ 1212 | EID Length (U16) | 1213 +-----------------------------+ 1214 | EID Data (variable) | 1215 +-----------------------------+ 1216 | Session Extension | 1217 | Items Length (U32) | 1218 +-----------------------------+ 1219 | Session Extension | 1220 | Items (var.) | 1221 +-----------------------------+ 1223 Figure 19: SESS_INIT Format 1225 The fields of the SESS_INIT message are: 1227 Keepalive Interval: A 16-bit unsigned integer indicating the 1228 interval, in seconds, between any subsequent messages being 1229 transmitted by the peer. The peer receiving this contact header 1230 uses this interval to determine how long to wait after any last- 1231 message transmission and a necessary subsequent KEEPALIVE message 1232 transmission. 1234 Segment MRU: A 64-bit unsigned integer indicating the largest 1235 allowable single-segment data payload size to be received in this 1236 session. Any XFER_SEGMENT sent to this peer SHALL have a data 1237 payload no longer than the peer's Segment MRU. The two entities 1238 of a single session MAY have different Segment MRUs, and no 1239 relation between the two is required. 1241 Transfer MRU: A 64-bit unsigned integer indicating the largest 1242 allowable total-bundle data size to be received in this session. 1243 Any bundle transfer sent to this peer SHALL have a Total Bundle 1244 Length payload no longer than the peer's Transfer MRU. This value 1245 can be used to perform proactive bundle fragmentation. The two 1246 entities of a single session MAY have different Transfer MRUs, and 1247 no relation between the two is required. 1249 Node ID Length and Node ID Data: Together these fields represent a 1250 variable-length text string. The Node ID Length is a 16-bit 1251 unsigned integer indicating the number of octets of Node ID Data 1252 to follow. A zero-length Node ID SHALL be used to indicate the 1253 lack of Node ID rather than a truly empty Node ID. This case 1254 allows an entity to avoid exposing Node ID information on an 1255 untrusted network. A non-zero-length Node ID Data SHALL contain 1256 the UTF-8 encoded Node ID of the Entity which sent the SESS_INIT 1257 message. Every Node ID SHALL be a URI consistent with the 1258 requirements of [RFC3986] and the URI schemes of 1259 [I-D.ietf-dtn-bpbis]. The Node ID itself can be authenticated as 1260 described in Section 4.4.2. 1262 Session Extension Length and Session Extension Items: Together these 1263 fields represent protocol extension data not defined by this 1264 specification. The Session Extension Length is the total number 1265 of octets to follow which are used to encode the Session Extension 1266 Item list. The encoding of each Session Extension Item is within 1267 a consistent data container as described in Section 4.8. The full 1268 set of Session Extension Items apply for the duration of the TCPCL 1269 session to follow. The order and mulitplicity of these Session 1270 Extension Items MAY be significant, as defined in the associated 1271 type specification(s). 1273 4.7. Session Parameter Negotiation 1275 An entity calculates the parameters for a TCPCL session by 1276 negotiating the values from its own preferences (conveyed by the 1277 contact header it sent to the peer) with the preferences of the peer 1278 node (expressed in the contact header that it received from the 1279 peer). The negotiated parameters defined by this specification are 1280 described in the following paragraphs. 1282 Transfer MTU and Segment MTU: The maximum transmit unit (MTU) for 1283 whole transfers and individual segments are idententical to the 1284 Transfer MRU and Segment MRU, respectively, of the recevied 1285 contact header. A transmitting peer can send individual segments 1286 with any size smaller than the Segment MTU, depending on local 1287 policy, dynamic network conditions, etc. Determining the size of 1288 each transmitted segment is an implementation matter. 1290 Session Keepalive: Negotiation of the Session Keepalive parameter is 1291 performed by taking the minimum of this two contact headers' 1292 Keepalive Interval. The Session Keepalive interval is a parameter 1293 for the behavior described in Section 5.1.1. 1295 Enable TLS: Negotiation of the Enable TLS parameter is performed by 1296 taking the logical AND of the two contact headers' CAN_TLS flags. 1297 A local security policy is then applied to determine of the 1298 negotated value of Enable TLS is acceptable. It can be a 1299 reasonable security policy to both require or disallow the use of 1300 TLS depending upon the desired network flows. Because this state 1301 is negotiated over an unsecured medium, there is a risk of a TLS 1302 Stripping as described in Section 8. If the Enable TLS state is 1303 unacceptable, the node SHALL terminate the session with a reason 1304 code of "Contact Failure". Note that this contact failure reason 1305 is different than a failure of TLS handshake or TLS authentication 1306 after an agreed-upon and acceptable Enable TLS state. If the 1307 negotiated Enable TLS value is true and acceptable then TLS 1308 negotiation feature (described in Section 4.4) begins immediately 1309 following the contact header exchange. 1311 Once this process of parameter negotiation is completed (which 1312 includes a possible completed TLS handshake of the connection to use 1313 TLS), this protocol defines no additional mechanism to change the 1314 parameters of an established session; to effect such a change, the 1315 TCPCL session MUST be terminated and a new session established. 1317 4.8. Session Extension Items 1319 Each of the Session Extension Items SHALL be encoded in an identical 1320 Type-Length-Value (TLV) container form as indicated in Figure 20. 1322 The fields of the Session Extension Item are: 1324 Flags: A one-octet field containing generic bit flags about the 1325 Item, which are listed in Table 3. All reserved header flag bits 1326 SHALL be not set by the sender. All reserved header flag bits 1327 SHALL be ignored by the receiver. If a TCPCL entity receives a 1328 Session Extension Item with an unknown Item Type and the CRITICAL 1329 flag set, the entity SHALL close the TCPCL session with SESS_TERM 1330 reason code of "Contact Failure". If the CRITICAL flag is not 1331 set, an entity SHALL skip over and ignore any item with an unknown 1332 Item Type. 1334 Item Type: A 16-bit unsigned integer field containing the type of 1335 the extension item. This specification does not define any 1336 extension types directly, but does allocate an IANA registry for 1337 such codes (see Section 9.3). 1339 Item Length: A 16-bit unsigned integer field containing the number 1340 of Item Value octets to follow. 1342 Item Value: A variable-length data field which is interpreted 1343 according to the associated Item Type. This specification places 1344 no restrictions on an extension's use of available Item Value 1345 data. Extension specifications SHOULD avoid the use of large data 1346 lengths, as no bundle transfers can begin until the full extension 1347 data is sent. 1349 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1350 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 1351 +---------------+---------------+---------------+---------------+ 1352 | Item Flags | Item Type | Item Length...| 1353 +---------------+---------------+---------------+---------------+ 1354 | length contd. | Item Value... | 1355 +---------------+---------------+---------------+---------------+ 1357 Figure 20: Session Extension Item Format 1359 +----------+--------+-----------------------------------------------+ 1360 | Name | Code | Description | 1361 +----------+--------+-----------------------------------------------+ 1362 | CRITICAL | 0x01 | If bit is set, indicates that the receiving | 1363 | | | peer must handle the extension item. | 1364 | | | | 1365 | Reserved | others | 1366 +----------+--------+-----------------------------------------------+ 1368 Table 3: Session Extension Item Flags 1370 5. Established Session Operation 1372 This section describes the protocol operation for the duration of an 1373 established session, including the mechanism for transmitting bundles 1374 over the session. 1376 5.1. Upkeep and Status Messages 1378 5.1.1. Session Upkeep (KEEPALIVE) 1380 The protocol includes a provision for transmission of KEEPALIVE 1381 messages over the TCPCL session to help determine if the underlying 1382 TCP connection has been disrupted. 1384 As described in Section 4.3, a negotiated parameter of each session 1385 is the Session Keepalive interval. If the negotiated Session 1386 Keepalive is zero (i.e. one or both contact headers contains a zero 1387 Keepalive Interval), then the keepalive feature is disabled. There 1388 is no logical minimum value for the keepalive interval, but when used 1389 for many sessions on an open, shared network a short interval could 1390 lead to excessive traffic. For shared network use, entities SHOULD 1391 choose a keepalive interval no shorter than 30 seconds. There is no 1392 logical maximum value for the keepalive interval, but an idle TCP 1393 connection is liable for closure by the host operating system if the 1394 keepalive time is longer than tens-of-minutes. Entities SHOULD 1395 choose a keepalive interval no longer than 10 minutes (600 seconds). 1397 Note: The Keepalive Interval SHOULD NOT be chosen too short as TCP 1398 retransmissions MAY occur in case of packet loss. Those will have to 1399 be triggered by a timeout (TCP retransmission timeout (RTO)), which 1400 is dependent on the measured RTT for the TCP connection so that 1401 KEEPALIVE messages MAY experience noticeable latency. 1403 The format of a KEEPALIVE message is a one-octet message type code of 1404 KEEPALIVE (as described in Table 2) with no additional data. Both 1405 sides SHALL send a KEEPALIVE message whenever the negotiated interval 1406 has elapsed with no transmission of any message (KEEPALIVE or other). 1408 If no message (KEEPALIVE or other) has been received in a session 1409 after some implementation-defined time duration, then the node SHALL 1410 terminate the session by transmitting a SESS_TERM message (as 1411 described in Section 6.1) with reason code "Idle Timeout". If 1412 configurable, the idle timeout duration SHOULD be no shorter than 1413 twice the keepalive interval. If not configurable, the idle timeout 1414 duration SHOULD be exactly twice the keepalive interval. 1416 5.1.2. Message Rejection (MSG_REJECT) 1418 If a TCPCL node receives a message which is unknown to it (possibly 1419 due to an unhandled protocol mismatch) or is inappropriate for the 1420 current session state (e.g. a KEEPALIVE message received after 1421 contact header negotiation has disabled that feature), there is a 1422 protocol-level message to signal this condition in the form of a 1423 MSG_REJECT reply. 1425 The format of a MSG_REJECT message is as follows in Figure 21. 1427 +-----------------------------+ 1428 | Message Header | 1429 +-----------------------------+ 1430 | Reason Code (U8) | 1431 +-----------------------------+ 1432 | Rejected Message Header | 1433 +-----------------------------+ 1435 Figure 21: Format of MSG_REJECT Messages 1437 The fields of the MSG_REJECT message are: 1439 Reason Code: A one-octet refusal reason code interpreted according 1440 to the descriptions in Table 4. 1442 Rejected Message Header: The Rejected Message Header is a copy of 1443 the Message Header to which the MSG_REJECT message is sent as a 1444 response. 1446 +-------------+------+----------------------------------------------+ 1447 | Name | Code | Description | 1448 +-------------+------+----------------------------------------------+ 1449 | Message | 0x01 | A message was received with a Message Type | 1450 | Type | | code unknown to the TCPCL node. | 1451 | Unknown | | | 1452 | | | | 1453 | Message | 0x02 | A message was received but the TCPCL node | 1454 | Unsupported | | cannot comply with the message contents. | 1455 | | | | 1456 | Message | 0x03 | A message was received while the session is | 1457 | Unexpected | | in a state in which the message is not | 1458 | | | expected. | 1459 +-------------+------+----------------------------------------------+ 1461 Table 4: MSG_REJECT Reason Codes 1463 5.2. Bundle Transfer 1465 All of the messages in this section are directly associated with 1466 transferring a bundle between TCPCL entities. 1468 A single TCPCL transfer results in a bundle (handled by the 1469 convergence layer as opaque data) being exchanged from one node to 1470 the other. In TCPCL a transfer is accomplished by dividing a single 1471 bundle up into "segments" based on the receiving-side Segment MRU 1472 (see Section 4.2). The choice of the length to use for segments is 1473 an implementation matter, but each segment MUST be no larger than the 1474 receiving node's maximum receive unit (MRU) (see the field "Segment 1475 MRU" of Section 4.2). The first segment for a bundle MUST set the 1476 'START' flag, and the last one MUST set the 'end' flag in the 1477 XFER_SEGMENT message flags. 1479 A single transfer (and by extension a single segment) SHALL NOT 1480 contain data of more than a single bundle. This requirement is 1481 imposed on the agent using the TCPCL rather than TCPCL itself. 1483 If multiple bundles are transmitted on a single TCPCL connection, 1484 they MUST be transmitted consecutively without interleaving of 1485 segments from multiple bundles. 1487 5.2.1. Bundle Transfer ID 1489 Each of the bundle transfer messages contains a Transfer ID which is 1490 used to correlate messages (from both sides of a transfer) for each 1491 bundle. A Transfer ID does not attempt to address uniqueness of the 1492 bundle data itself and has no relation to concepts such as bundle 1493 fragmentation. Each invocation of TCPCL by the bundle protocol 1494 agent, requesting transmission of a bundle (fragmentary or 1495 otherwise), results in the initiation of a single TCPCL transfer. 1496 Each transfer entails the sending of a sequence of some number of 1497 XFER_SEGMENT and XFER_ACK messages; all are correlated by the same 1498 Transfer ID. 1500 Transfer IDs from each node SHALL be unique within a single TCPCL 1501 session. The initial Transfer ID from each node SHALL have value 1502 zero. Subsequent Transfer ID values SHALL be incremented from the 1503 prior Transfer ID value by one. Upon exhaustion of the entire 64-bit 1504 Transfer ID space, the sending node SHALL terminate the session with 1505 SESS_TERM reason code "Resource Exhaustion". 1507 For bidirectional bundle transfers, a TCPCL node SHOULD NOT rely on 1508 any relation between Transfer IDs originating from each side of the 1509 TCPCL session. 1511 5.2.2. Data Transmission (XFER_SEGMENT) 1513 Each bundle is transmitted in one or more data segments. The format 1514 of a XFER_SEGMENT message follows in Figure 22. 1516 +------------------------------+ 1517 | Message Header | 1518 +------------------------------+ 1519 | Message Flags (U8) | 1520 +------------------------------+ 1521 | Transfer ID (U64) | 1522 +------------------------------+ 1523 | Transfer Extension | 1524 | Items Length (U32) | 1525 | (only for START segment) | 1526 +------------------------------+ 1527 | Transfer Extension | 1528 | Items (var.) | 1529 | (only for START segment) | 1530 +------------------------------+ 1531 | Data length (U64) | 1532 +------------------------------+ 1533 | Data contents (octet string) | 1534 +------------------------------+ 1536 Figure 22: Format of XFER_SEGMENT Messages 1538 The fields of the XFER_SEGMENT message are: 1540 Message Flags: A one-octet field of single-bit flags, interpreted 1541 according to the descriptions in Table 5. All reserved header 1542 flag bits SHALL be not set by the sender. All reserved header 1543 flag bits SHALL be ignored by the receiver. 1545 Transfer ID: A 64-bit unsigned integer identifying the transfer 1546 being made. 1548 Transfer Extension Length and Transfer Extension Items: Together 1549 these fields represent protocol extension data for this 1550 specification. The Transfer Extension Length and Transfer 1551 Extension Item fields SHALL only be present when the 'START' flag 1552 is set on the message. The Transfer Extension Length is the total 1553 number of octets to follow which are used to encode the Transfer 1554 Extension Item list. The encoding of each Transfer Extension Item 1555 is within a consistent data container as described in 1556 Section 5.2.5. The full set of transfer extension items apply 1557 only to the assoicated single transfer. The order and 1558 mulitplicity of these transfer extension items MAY be significant, 1559 as defined in the associated type specification(s). 1561 Data length: A 64-bit unsigned integer indicating the number of 1562 octets in the Data contents to follow. 1564 Data contents: The variable-length data payload of the message. 1566 +----------+--------+-----------------------------------------------+ 1567 | Name | Code | Description | 1568 +----------+--------+-----------------------------------------------+ 1569 | END | 0x01 | If bit is set, indicates that this is the | 1570 | | | last segment of the transfer. | 1571 | | | | 1572 | START | 0x02 | If bit is set, indicates that this is the | 1573 | | | first segment of the transfer. | 1574 | | | | 1575 | Reserved | others | 1576 +----------+--------+-----------------------------------------------+ 1578 Table 5: XFER_SEGMENT Flags 1580 The flags portion of the message contains two optional values in the 1581 two low-order bits, denoted 'START' and 'END' in Table 5. The 1582 'START' bit MUST be set to one if it precedes the transmission of the 1583 first segment of a transfer. The 'END' bit MUST be set to one when 1584 transmitting the last segment of a transfer. In the case where an 1585 entire transfer is accomplished in a single segment, both the 'START' 1586 and 'END' bits MUST be set to one. 1588 Once a transfer of a bundle has commenced, the node MUST only send 1589 segments containing sequential portions of that bundle until it sends 1590 a segment with the 'END' bit set. No interleaving of multiple 1591 transfers from the same node is possible within a single TCPCL 1592 session. Simultaneous transfers between two entities MAY be achieved 1593 using multiple TCPCL sessions. 1595 5.2.3. Data Acknowledgments (XFER_ACK) 1597 Although the TCP transport provides reliable transfer of data between 1598 transport peers, the typical BSD sockets interface provides no means 1599 to inform a sending application of when the receiving application has 1600 processed some amount of transmitted data. Thus, after transmitting 1601 some data, the TCPCL needs an additional mechanism to determine 1602 whether the receiving agent has successfully received the segment. 1603 To this end, the TCPCL protocol provides feedback messaging whereby a 1604 receiving node transmits acknowledgments of reception of data 1605 segments. 1607 The format of an XFER_ACK message follows in Figure 23. 1609 +-----------------------------+ 1610 | Message Header | 1611 +-----------------------------+ 1612 | Message Flags (U8) | 1613 +-----------------------------+ 1614 | Transfer ID (U64) | 1615 +-----------------------------+ 1616 | Acknowledged length (U64) | 1617 +-----------------------------+ 1619 Figure 23: Format of XFER_ACK Messages 1621 The fields of the XFER_ACK message are: 1623 Message Flags: A one-octet field of single-bit flags, interpreted 1624 according to the descriptions in Table 5. All reserved header 1625 flag bits SHALL be not set by the sender. All reserved header 1626 flag bits SHALL be ignored by the receiver. 1628 Transfer ID: A 64-bit unsigned integer identifying the transfer 1629 being acknowledged. 1631 Acknowledged length: A 64-bit unsigned integer indicating the total 1632 number of octets in the transfer which are being acknowledged. 1634 A receiving TCPCL node SHALL send an XFER_ACK message in response to 1635 each received XFER_SEGMENT message. The flags portion of the 1636 XFER_ACK header SHALL be set to match the corresponding DATA_SEGMENT 1637 message being acknowledged. The acknowledged length of each XFER_ACK 1638 contains the sum of the data length fields of all XFER_SEGMENT 1639 messages received so far in the course of the indicated transfer. 1640 The sending node SHOULD transmit multiple XFER_SEGMENT messages 1641 without waiting for the corresponding XFER_ACK responses. This 1642 enables pipelining of messages on a transfer stream. 1644 For example, suppose the sending node transmits four segments of 1645 bundle data with lengths 100, 200, 500, and 1000, respectively. 1646 After receiving the first segment, the node sends an acknowledgment 1647 of length 100. After the second segment is received, the node sends 1648 an acknowledgment of length 300. The third and fourth 1649 acknowledgments are of length 800 and 1800, respectively. 1651 5.2.4. Transfer Refusal (XFER_REFUSE) 1653 The TCPCL supports a mechanism by which a receiving node can indicate 1654 to the sender that it does not want to receive the corresponding 1655 bundle. To do so, upon receiving an XFER_SEGMENT message, the node 1656 MAY transmit a XFER_REFUSE message. As data segments and 1657 acknowledgments MAY cross on the wire, the bundle that is being 1658 refused SHALL be identified by the Transfer ID of the refusal. 1660 There is no required relation between the Transfer MRU of a TCPCL 1661 node (which is supposed to represent a firm limitation of what the 1662 node will accept) and sending of a XFER_REFUSE message. A 1663 XFER_REFUSE can be used in cases where the agent's bundle storage is 1664 temporarily depleted or somehow constrained. A XFER_REFUSE can also 1665 be used after the bundle header or any bundle data is inspected by an 1666 agent and determined to be unacceptable. 1668 A receiver MAY send an XFER_REFUSE message as soon as it receives any 1669 XFER_SEGMENT message. The sender MUST be prepared for this and MUST 1670 associate the refusal with the correct bundle via the Transfer ID 1671 fields. 1673 The format of the XFER_REFUSE message is as follows in Figure 24. 1675 +-----------------------------+ 1676 | Message Header | 1677 +-----------------------------+ 1678 | Reason Code (U8) | 1679 +-----------------------------+ 1680 | Transfer ID (U64) | 1681 +-----------------------------+ 1683 Figure 24: Format of XFER_REFUSE Messages 1685 The fields of the XFER_REFUSE message are: 1687 Reason Code: A one-octet refusal reason code interpreted according 1688 to the descriptions in Table 6. 1690 Transfer ID: A 64-bit unsigned integer identifying the transfer 1691 being refused. 1693 +------------+------+-----------------------------------------------+ 1694 | Name | Code | Description | 1695 +------------+------+-----------------------------------------------+ 1696 | Unknown | 0x00 | Reason for refusal is unknown or not | 1697 | | | specified. | 1698 | | | | 1699 | Extension | 0x01 | A failure processing the Transfer Extension | 1700 | Failure | | Items ha occurred. | 1701 | | | | 1702 | Completed | 0x02 | The receiver already has the complete bundle. | 1703 | | | The sender MAY consider the bundle as | 1704 | | | completely received. | 1705 | | | | 1706 | No | 0x03 | The receiver's resources are exhausted. The | 1707 | Resources | | sender SHOULD apply reactive bundle | 1708 | | | fragmentation before retrying. | 1709 | | | | 1710 | Retransmit | 0x04 | The receiver has encountered a problem that | 1711 | | | requires the bundle to be retransmitted in | 1712 | | | its entirety. | 1713 +------------+------+-----------------------------------------------+ 1715 Table 6: XFER_REFUSE Reason Codes 1717 The receiver MUST, for each transfer preceding the one to be refused, 1718 have either acknowledged all XFER_SEGMENTs or refused the bundle 1719 transfer. 1721 The bundle transfer refusal MAY be sent before an entire data segment 1722 is received. If a sender receives a XFER_REFUSE message, the sender 1723 MUST complete the transmission of any partially sent XFER_SEGMENT 1724 message. There is no way to interrupt an individual TCPCL message 1725 partway through sending it. The sender MUST NOT commence 1726 transmission of any further segments of the refused bundle 1727 subsequently. Note, however, that this requirement does not ensure 1728 that an entity will not receive another XFER_SEGMENT for the same 1729 bundle after transmitting a XFER_REFUSE message since messages MAY 1730 cross on the wire; if this happens, subsequent segments of the bundle 1731 SHALL also be refused with a XFER_REFUSE message. 1733 Note: If a bundle transmission is aborted in this way, the receiver 1734 MAY not receive a segment with the 'END' flag set to '1' for the 1735 aborted bundle. The beginning of the next bundle is identified by 1736 the 'START' bit set to '1', indicating the start of a new transfer, 1737 and with a distinct Transfer ID value. 1739 5.2.5. Transfer Extension Items 1741 Each of the Transfer Extension Items SHALL be encoded in an identical 1742 Type-Length-Value (TLV) container form as indicated in Figure 25. 1744 The fields of the Transfer Extension Item are: 1746 Flags: A one-octet field containing generic bit flags about the 1747 Item, which are listed in Table 7. All reserved header flag bits 1748 SHALL be not set by the sender. All reserved header flag bits 1749 SHALL be ignored by the receiver. If a TCPCL node receives a 1750 Transfer Extension Item with an unknown Item Type and the CRITICAL 1751 flag set, the node SHALL refuse the transfer with an XFER_REFUSE 1752 reason code of "Extension Failure". If the CRITICAL flag is not 1753 set, an entity SHALL skip over and ignore any item with an unknown 1754 Item Type. 1756 Item Type: A 16-bit unsigned integer field containing the type of 1757 the extension item. This specification allocates an IANA registry 1758 for such codes (see Section 9.4). 1760 Item Length: A 16-bit unsigned integer field containing the number 1761 of Item Value octets to follow. 1763 Item Value: A variable-length data field which is interpreted 1764 according to the associated Item Type. This specification places 1765 no restrictions on an extension's use of available Item Value 1766 data. Extension specifications SHOULD avoid the use of large data 1767 lengths, as the associated transfer cannot begin until the full 1768 extension data is sent. 1770 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1771 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 1772 +---------------+---------------+---------------+---------------+ 1773 | Item Flags | Item Type | Item Length...| 1774 +---------------+---------------+---------------+---------------+ 1775 | length contd. | Item Value... | 1776 +---------------+---------------+---------------+---------------+ 1778 Figure 25: Transfer Extension Item Format 1780 +----------+--------+-----------------------------------------------+ 1781 | Name | Code | Description | 1782 +----------+--------+-----------------------------------------------+ 1783 | CRITICAL | 0x01 | If bit is set, indicates that the receiving | 1784 | | | peer must handle the extension item. | 1785 | | | | 1786 | Reserved | others | 1787 +----------+--------+-----------------------------------------------+ 1789 Table 7: Transfer Extension Item Flags 1791 5.2.5.1. Transfer Length Extension 1793 The purpose of the Transfer Length extension is to allow entities to 1794 preemptively refuse bundles that would exceed their resources or to 1795 prepare storage on the receiving node for the upcoming bundle data. 1797 Multiple Transfer Length extension items SHALL NOT occur within the 1798 same transfer. The lack of a Transfer Length extension item in any 1799 transfer SHALL NOT imply anything about the potential length of the 1800 transfer. The Transfer Length extension SHALL be assigned transfer 1801 extension type ID 0x0001. 1803 If a transfer occupies exactly one segment (i.e. both START and END 1804 bits are set) the Transfer Length extension SHOULD NOT be present. 1805 The extension does not provide any additional information for single- 1806 segment transfers. 1808 The format of the Transfer Length data is as follows in Figure 26. 1810 +----------------------+ 1811 | Total Length (U64) | 1812 +----------------------+ 1814 Figure 26: Format of Transfer Length data 1816 The fields of the Transfer Length extension are: 1818 Total Length: A 64-bit unsigned integer indicating the size of the 1819 data-to-be-transferred. The Total Length field SHALL be treated 1820 as authoritative by the receiver. If, for whatever reason, the 1821 actual total length of bundle data received differs from the value 1822 indicated by the Total Length value, the receiver SHALL treat the 1823 transmitted data as invalid. 1825 6. Session Termination 1827 This section describes the procedures for ending a TCPCL session. 1829 6.1. Session Termination Message (SESS_TERM) 1831 To cleanly shut down a session, a SESS_TERM message SHALL be 1832 transmitted by either node at any point following complete 1833 transmission of any other message. When sent to initiate a 1834 termination, the REPLY bit of a SESS_TERM message SHALL NOT be set. 1835 Upon receiving a SESS_TERM message after not sending a SESS_TERM 1836 message in the same session, an entity SHALL send an acknowledging 1837 SESS_TERM message. When sent to acknowledge a termination, a 1838 SESS_TERM message SHALL have identical data content from the message 1839 being acknowledged except for the REPLY bit, which is set to indicate 1840 acknowledgement. 1842 After sending a SESS_TERM message, an entity MAY continue a possible 1843 in-progress transfer in either direction. After sending a SESS_TERM 1844 message, an entity SHALL NOT begin any new outgoing transfer for the 1845 remainder of the session. After receving a SESS_TERM message, an 1846 entity SHALL NOT accept any new incoming transfer for the remainder 1847 of the session. 1849 Instead of following a clean shutdown sequence, after transmitting a 1850 SESS_TERM message an entity MAY immediately close the associated TCP 1851 connection. When performing an unclean shutdown, a receiving node 1852 SHOULD acknowledge all received data segments before closing the TCP 1853 connection. Not acknowledging received segments can result in 1854 unnecessary retransmission. When performing an unclean shutodwn, a 1855 transmitting node SHALL treat either sending or receiving a SESS_TERM 1856 message (i.e. before the final acknowledgment) as a failure of the 1857 transfer. Any delay between request to terminate the TCP connection 1858 and actual closing of the connection (a "half-closed" state) MAY be 1859 ignored by the TCPCL node. 1861 The format of the SESS_TERM message is as follows in Figure 27. 1863 +-----------------------------+ 1864 | Message Header | 1865 +-----------------------------+ 1866 | Message Flags (U8) | 1867 +-----------------------------+ 1868 | Reason Code (U8) | 1869 +-----------------------------+ 1871 Figure 27: Format of SESS_TERM Messages 1873 The fields of the SESS_TERM message are: 1875 Message Flags: A one-octet field of single-bit flags, interpreted 1876 according to the descriptions in Table 8. All reserved header 1877 flag bits SHALL be not set by the sender. All reserved header 1878 flag bits SHALL be ignored by the receiver. 1880 Reason Code: A one-octet refusal reason code interpreted according 1881 to the descriptions in Table 9. 1883 +----------+--------+-----------------------------------------------+ 1884 | Name | Code | Description | 1885 +----------+--------+-----------------------------------------------+ 1886 | REPLY | 0x01 | If bit is set, indicates that this message is | 1887 | | | an acknowledgement of an earlier SESS_TERM | 1888 | | | message. | 1889 | | | | 1890 | Reserved | others | 1891 +----------+--------+-----------------------------------------------+ 1893 Table 8: SESS_TERM Flags 1895 +--------------+------+---------------------------------------------+ 1896 | Name | Code | Description | 1897 +--------------+------+---------------------------------------------+ 1898 | Unknown | 0x00 | A termination reason is not available. | 1899 | | | | 1900 | Idle timeout | 0x01 | The session is being closed due to | 1901 | | | idleness. | 1902 | | | | 1903 | Version | 0x02 | The node cannot conform to the specified | 1904 | mismatch | | TCPCL protocol version. | 1905 | | | | 1906 | Busy | 0x03 | The node is too busy to handle the current | 1907 | | | session. | 1908 | | | | 1909 | Contact | 0x04 | The node cannot interpret or negotiate | 1910 | Failure | | contact header option. | 1911 | | | | 1912 | Resource | 0x05 | The node has run into some resource limit | 1913 | Exhaustion | | and cannot continue the session. | 1914 +--------------+------+---------------------------------------------+ 1916 Table 9: SESS_TERM Reason Codes 1918 A session shutdown MAY occur immediately after transmission of a 1919 contact header (and prior to any further message transmit). This 1920 MAY, for example, be used to notify that the node is currently not 1921 able or willing to communicate. However, an entity MUST always send 1922 the contact header to its peer before sending a SESS_TERM message. 1924 If reception of the contact header itself somehow fails (e.g. an 1925 invalid "magic string" is recevied), an entity SHALL close the TCP 1926 connection without sending a SESS_TERM message. If the content of 1927 the Session Extension Items data disagrees with the Session Extension 1928 Length (i.e. the last Item claims to use more octets than are present 1929 in the Session Extension Length), the reception of the contact header 1930 is considered to have failed. 1932 If a session is to be terminated before a protocol message has 1933 completed being sent, then the node MUST NOT transmit the SESS_TERM 1934 message but still SHALL close the TCP connection. Each TCPCL message 1935 is contiguous in the octet stream and has no ability to be cut short 1936 and/or preempted by an other message. This is particularly important 1937 when large segment sizes are being transmitted; either entire 1938 XFER_SEGMENT is sent before a SESS_TERM message or the connection is 1939 simply terminated mid-XFER_SEGMENT. 1941 6.2. Idle Session Shutdown 1943 The protocol includes a provision for clean shutdown of idle 1944 sessions. Determining the length of time to wait before ending idle 1945 sessions, if they are to be closed at all, is an implementation and 1946 configuration matter. 1948 If there is a configured time to close idle links and if no TCPCL 1949 messages (other than KEEPALIVE messages) has been received for at 1950 least that amount of time, then either node MAY terminate the session 1951 by transmitting a SESS_TERM message indicating the reason code of 1952 "Idle timeout" (as described in Table 9). 1954 7. Implementation Status 1956 [NOTE to the RFC Editor: please remove this section before 1957 publication, as well as the reference to [RFC7942] and 1958 [github-dtn-bpbis-tcpcl].] 1960 This section records the status of known implementations of the 1961 protocol defined by this specification at the time of posting of this 1962 Internet-Draft, and is based on a proposal described in [RFC7942]. 1963 The description of implementations in this section is intended to 1964 assist the IETF in its decision processes in progressing drafts to 1965 RFCs. Please note that the listing of any individual implementation 1966 here does not imply endorsement by the IETF. Furthermore, no effort 1967 has been spent to verify the information presented here that was 1968 supplied by IETF contributors. This is not intended as, and must not 1969 be construed to be, a catalog of available implementations or their 1970 features. Readers are advised to note that other implementations can 1971 exist. 1973 An example implementation of the this draft of TCPCLv4 has been 1974 created as a GitHub project [github-dtn-bpbis-tcpcl] and is intented 1975 to use as a proof-of-concept and as a possible source of 1976 interoperability testing. This example implementation uses D-Bus as 1977 the CL-BP Agent interface, so it only runs on hosts which provide the 1978 Python "dbus" library. 1980 8. Security Considerations 1982 TCPCL can be used to provide point-to-point transport security, but 1983 does not provide security of data-at-rest and does not guarantee end- 1984 to-end bundle security. The bundle security mechanisms defined in 1985 [I-D.ietf-dtn-bpsec] are to be used instead. 1987 When negotating whether to use TLS security as part of the contact 1988 header exchange, it is possible for a man-in-the-middle attacker to 1989 unset the CAN_TLS flag on either side of the exchange. This leads to 1990 the "SSL Stripping" attack described in [RFC7457]. If TLS is desired 1991 for use on any TCPCL network, it is strongly encouraged that the 1992 security policy disallow use of TCPCL when "Enable TLS" is negotiated 1993 to false. This requires that the TLS handshake occurs, regardless of 1994 the policy-driven parameters of the handshake and policy-driven 1995 handling of the handshake outcome. 1997 Even when using TLS to secure the TCPCL session, the actual 1998 ciphersuite negotiated between the TLS peers MAY be insecure. TLS 1999 can be used to perform authentication without data confidentiality, 2000 for example. It is up to security policies within each TCPCL node to 2001 ensure that the negotiated TLS ciphersuite meets transport security 2002 requirements. This is identical behavior to STARTTLS use in 2003 [RFC2595]. 2005 The certificates exchanged by TLS enable authentication of peer host 2006 name and Node ID, but it is possible that a peer either not provide a 2007 valid certificate or that the certificate does not validate either 2008 the host name or Node ID of the peer. Having a CA-validated 2009 certificate does not alone guarantee the identity of the network host 2010 or BP node from which the certificate is provided; additional 2011 validation procedures bind the host name or node ID based on the 2012 contents of the certificate. The host name validation is a weaker 2013 form of authentication, because even if a peer is operating on an 2014 authenticated network host name it can provide an invalid Node ID and 2015 cause bundles to be "leaked" to an invalid node. Especially in DTN 2016 environments, network names and addresses of nodes can be time- 2017 variable so binding a certificate to a Node ID is a more stable 2018 identity. Node ID validation ensures that the peer to which a bundle 2019 is transferred is in fact the node which the BP Agent expects it to 2020 be. It is a reasonable policy to skip host name validation if 2021 certificates can be guaranteed to validate the peer's Node ID. In 2022 circumstances where certificates can only be issued to network host 2023 names, Node ID validation is not possible but it could be reasonable 2024 to assume that a trusted host is not going to present an invalid Node 2025 ID. Trusting an authenticated host name can be feasable on a network 2026 secured by a private CA but is not advisable on the Internet when 2027 using a variety of public CAs. 2029 Another consideration for this protocol relates to denial-of-service 2030 attacks. An entity MAY send a large amount of data over a TCPCL 2031 session, requiring the receiving entity to handle the data, attempt 2032 to stop the flood of data by sending a XFER_REFUSE message, or 2033 forcibly terminate the session. This burden could cause denial of 2034 service on other, well-behaving sessions. There is also nothing to 2035 prevent a malicious entity from continually establishing sessions and 2036 repeatedly trying to send copious amounts of bundle data. A 2037 listening entity MAY take countermeasures such as ignoring TCP SYN 2038 messages, closing TCP connections as soon as they are established, 2039 waiting before sending the contact header, sending a SESS_TERM 2040 message quickly or with a delay, etc. 2042 9. IANA Considerations 2044 Registration procedures referred to in this section are defined in 2045 [RFC8126]. 2047 Some of the registries have been defined as version specific to 2048 TCPCLv4, and imports some or all codepoints from TCPCLv3. This was 2049 done to disambiguate the use of these codepoints between TCPCLv3 and 2050 TCPCLv4 while preserving the semantics of some of the codepoints. 2052 9.1. Port Number 2054 Port number 4556 has been previously assigned as the default port for 2055 the TCP convergence layer in [RFC7242]. This assignment is unchanged 2056 by protocol version 4. Each TCPCL entity identifies its TCPCL 2057 protocol version in its initial contact (see Section 9.2), so there 2058 is no ambiguity about what protocol is being used. 2060 +------------------------+-------------------------------------+ 2061 | Parameter | Value | 2062 +------------------------+-------------------------------------+ 2063 | Service Name: | dtn-bundle | 2064 | | | 2065 | Transport Protocol(s): | TCP | 2066 | | | 2067 | Assignee: | Simon Perreault | 2068 | | | 2069 | Contact: | Simon Perreault | 2070 | | | 2071 | Description: | DTN Bundle TCP CL Protocol | 2072 | | | 2073 | Reference: | [RFC7242] | 2074 | | | 2075 | Port Number: | 4556 | 2076 +------------------------+-------------------------------------+ 2078 9.2. Protocol Versions 2080 IANA has created, under the "Bundle Protocol" registry, a sub- 2081 registry titled "Bundle Protocol TCP Convergence-Layer Version 2082 Numbers" and initialize it with the following table. The 2083 registration procedure is RFC Required. 2085 +-------+-------------+---------------------+ 2086 | Value | Description | Reference | 2087 +-------+-------------+---------------------+ 2088 | 0 | Reserved | [RFC7242] | 2089 | | | | 2090 | 1 | Reserved | [RFC7242] | 2091 | | | | 2092 | 2 | Reserved | [RFC7242] | 2093 | | | | 2094 | 3 | TCPCL | [RFC7242] | 2095 | | | | 2096 | 4 | TCPCLv4 | This specification. | 2097 | | | | 2098 | 5-255 | Unassigned | 2099 +-------+-------------+---------------------+ 2101 9.3. Session Extension Types 2103 EDITOR NOTE: sub-registry to-be-created upon publication of this 2104 specification. 2106 IANA will create, under the "Bundle Protocol" registry, a sub- 2107 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 2108 Session Extension Types" and initialize it with the contents of 2109 Table 10. The registration procedure is Expert Review within the 2110 lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are 2111 reserved for use on private networks for functions not published to 2112 the IANA. 2114 +----------------+--------------------------+ 2115 | Code | Session Extension Type | 2116 +----------------+--------------------------+ 2117 | 0x0000 | Reserved | 2118 | | | 2119 | 0x0001--0x7FFF | Unassigned | 2120 | | | 2121 | 0x8000--0xFFFF | Private/Experimental Use | 2122 +----------------+--------------------------+ 2124 Table 10: Session Extension Type Codes 2126 9.4. Transfer Extension Types 2128 EDITOR NOTE: sub-registry to-be-created upon publication of this 2129 specification. 2131 IANA will create, under the "Bundle Protocol" registry, a sub- 2132 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 2133 Transfer Extension Types" and initialize it with the contents of 2134 Table 11. The registration procedure is Expert Review within the 2135 lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are 2136 reserved for use on private networks for functions not published to 2137 the IANA. 2139 +----------------+---------------------------+ 2140 | Code | Transfer Extension Type | 2141 +----------------+---------------------------+ 2142 | 0x0000 | Reserved | 2143 | | | 2144 | 0x0001 | Transfer Length Extension | 2145 | | | 2146 | 0x0002--0x7FFF | Unassigned | 2147 | | | 2148 | 0x8000--0xFFFF | Private/Experimental Use | 2149 +----------------+---------------------------+ 2151 Table 11: Transfer Extension Type Codes 2153 9.5. Message Types 2155 EDITOR NOTE: sub-registry to-be-created upon publication of this 2156 specification. 2158 IANA will create, under the "Bundle Protocol" registry, a sub- 2159 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 2160 Message Types" and initialize it with the contents of Table 12. The 2161 registration procedure is RFC Required within the lower range 0x01-- 2162 0xEF. Values in the range 0xF0--0xFF are reserved for use on private 2163 networks for functions not published to the IANA. 2165 +------------+--------------------------+ 2166 | Code | Message Type | 2167 +------------+--------------------------+ 2168 | 0x00 | Reserved | 2169 | | | 2170 | 0x01 | XFER_SEGMENT | 2171 | | | 2172 | 0x02 | XFER_ACK | 2173 | | | 2174 | 0x03 | XFER_REFUSE | 2175 | | | 2176 | 0x04 | KEEPALIVE | 2177 | | | 2178 | 0x05 | SESS_TERM | 2179 | | | 2180 | 0x06 | MSG_REJECT | 2181 | | | 2182 | 0x07 | SESS_INIT | 2183 | | | 2184 | 0x08--0xEF | Unassigned | 2185 | | | 2186 | 0xF0--0xFF | Private/Experimental Use | 2187 +------------+--------------------------+ 2189 Table 12: Message Type Codes 2191 9.6. XFER_REFUSE Reason Codes 2193 EDITOR NOTE: sub-registry to-be-created upon publication of this 2194 specification. 2196 IANA will create, under the "Bundle Protocol" registry, a sub- 2197 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 2198 XFER_REFUSE Reason Codes" and initialize it with the contents of 2199 Table 13. The registration procedure is Specification Required 2200 within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF 2201 are reserved for use on private networks for functions not published 2202 to the IANA. 2204 +------------+--------------------------+ 2205 | Code | Refusal Reason | 2206 +------------+--------------------------+ 2207 | 0x00 | Unknown | 2208 | | | 2209 | 0x01 | Extension Failure | 2210 | | | 2211 | 0x02 | Completed | 2212 | | | 2213 | 0x03 | No Resources | 2214 | | | 2215 | 0x04 | Retransmit | 2216 | | | 2217 | 0x05--0xEF | Unassigned | 2218 | | | 2219 | 0xF0--0xFF | Private/Experimental Use | 2220 +------------+--------------------------+ 2222 Table 13: XFER_REFUSE Reason Codes 2224 9.7. SESS_TERM Reason Codes 2226 EDITOR NOTE: sub-registry to-be-created upon publication of this 2227 specification. 2229 IANA will create, under the "Bundle Protocol" registry, a sub- 2230 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 2231 SESS_TERM Reason Codes" and initialize it with the contents of 2232 Table 14. The registration procedure is Specification Required 2233 within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF 2234 are reserved for use on private networks for functions not published 2235 to the IANA. 2237 +------------+--------------------------+ 2238 | Code | Termination Reason | 2239 +------------+--------------------------+ 2240 | 0x00 | Unknown | 2241 | | | 2242 | 0x01 | Idle timeout | 2243 | | | 2244 | 0x02 | Version mismatch | 2245 | | | 2246 | 0x03 | Busy | 2247 | | | 2248 | 0x04 | Contact Failure | 2249 | | | 2250 | 0x05 | Resource Exhaustion | 2251 | | | 2252 | 0x06--0xEF | Unassigned | 2253 | | | 2254 | 0xF0--0xFF | Private/Experimental Use | 2255 +------------+--------------------------+ 2257 Table 14: SESS_TERM Reason Codes 2259 9.8. MSG_REJECT Reason Codes 2261 EDITOR NOTE: sub-registry to-be-created upon publication of this 2262 specification. 2264 IANA will create, under the "Bundle Protocol" registry, a sub- 2265 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 2266 MSG_REJECT Reason Codes" and initialize it with the contents of 2267 Table 15. The registration procedure is Specification Required 2268 within the lower range 0x01--0xEF. Values in the range 0xF0--0xFF 2269 are reserved for use on private networks for functions not published 2270 to the IANA. 2272 +------------+--------------------------+ 2273 | Code | Rejection Reason | 2274 +------------+--------------------------+ 2275 | 0x00 | reserved | 2276 | | | 2277 | 0x01 | Message Type Unknown | 2278 | | | 2279 | 0x02 | Message Unsupported | 2280 | | | 2281 | 0x03 | Message Unexpected | 2282 | | | 2283 | 0x04--0xEF | Unassigned | 2284 | | | 2285 | 0xF0--0xFF | Private/Experimental Use | 2286 +------------+--------------------------+ 2288 Table 15: MSG_REJECT Reason Codes 2290 10. Acknowledgments 2292 This specification is based on comments on implementation of 2293 [RFC7242] provided from Scott Burleigh. 2295 11. References 2297 11.1. Normative References 2299 [I-D.ietf-dtn-bpbis] 2300 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 2301 Version 7", draft-ietf-dtn-bpbis-14 (work in progress), 2302 August 2019. 2304 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2305 RFC 793, DOI 10.17487/RFC0793, September 1981, 2306 . 2308 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2309 Communication Layers", STD 3, RFC 1122, 2310 DOI 10.17487/RFC1122, October 1989, 2311 . 2313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2314 Requirement Levels", BCP 14, RFC 2119, 2315 DOI 10.17487/RFC2119, March 1997, 2316 . 2318 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2319 Resource Identifier (URI): Generic Syntax", STD 66, 2320 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2321 . 2323 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2324 (TLS) Protocol Version 1.2", RFC 5246, 2325 DOI 10.17487/RFC5246, August 2008, 2326 . 2328 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2329 Housley, R., and W. Polk, "Internet X.509 Public Key 2330 Infrastructure Certificate and Certificate Revocation List 2331 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2332 . 2334 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2335 Verification of Domain-Based Application Service Identity 2336 within Internet Public Key Infrastructure Using X.509 2337 (PKIX) Certificates in the Context of Transport Layer 2338 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2339 2011, . 2341 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2342 "Recommendations for Secure Use of Transport Layer 2343 Security (TLS) and Datagram Transport Layer Security 2344 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2345 2015, . 2347 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2348 Writing an IANA Considerations Section in RFCs", BCP 26, 2349 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2350 . 2352 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2353 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2354 May 2017, . 2356 11.2. Informative References 2358 [github-dtn-bpbis-tcpcl] 2359 Sipos, B., "TCPCL Example Implementation", 2360 . 2363 [I-D.ietf-dtn-bpsec] 2364 Birrane, E. and K. McKeever, "Bundle Protocol Security 2365 Specification", draft-ietf-dtn-bpsec-10 (work in 2366 progress), April 2019. 2368 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 2369 RFC 2595, DOI 10.17487/RFC2595, June 1999, 2370 . 2372 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 2373 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 2374 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 2375 April 2007, . 2377 [RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant 2378 Networking TCP Convergence-Layer Protocol", RFC 7242, 2379 DOI 10.17487/RFC7242, June 2014, 2380 . 2382 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 2383 Known Attacks on Transport Layer Security (TLS) and 2384 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 2385 February 2015, . 2387 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2388 Code: The Implementation Status Section", BCP 205, 2389 RFC 7942, DOI 10.17487/RFC7942, July 2016, 2390 . 2392 Appendix A. Significant changes from RFC7242 2394 The areas in which changes from [RFC7242] have been made to existing 2395 headers and messages are: 2397 o Split contact header into pre-TLS protocol negotiation and 2398 SESS_INIT parameter negotiation. The contact header is now fixed- 2399 length. 2401 o Changed contact header content to limit number of negotiated 2402 options. 2404 o Added session option to negotiate maximum segment size (per each 2405 direction). 2407 o Renamed "Endpoint ID" to "Node ID" to conform with BPv7 2408 terminology. 2410 o Added session extension capability. 2412 o Added transfer extension capability. Moved transfer total length 2413 into an extension item. 2415 o Defined new IANA registries for message / type / reason codes to 2416 allow renaming some codes for clarity. 2418 o Segments of all new IANA registries are reserved for private/ 2419 experimental use. 2421 o Expanded Message Header to octet-aligned fields instead of bit- 2422 packing. 2424 o Added a bundle transfer identification number to all bundle- 2425 related messages (XFER_SEGMENT, XFER_ACK, XFER_REFUSE). 2427 o Use flags in XFER_ACK to mirror flags from XFER_SEGMENT. 2429 o Removed all uses of SDNV fields and replaced with fixed-bit-length 2430 fields. 2432 o Renamed SHUTDOWN to SESS_TERM to deconflict term "shutdown" 2433 related to TCP connections. 2435 o Removed the notion of a re-connection delay parameter. 2437 The areas in which extensions from [RFC7242] have been made as new 2438 messages and codes are: 2440 o Added contact negotiation failure SESS_TERM reason code. 2442 o Added MSG_REJECT message to indicate an unknown or unhandled 2443 message was received. 2445 o Added TLS session security mechanism. 2447 o Added Resource Exhaustion SESS_TERM reason code. 2449 Authors' Addresses 2451 Brian Sipos 2452 RKF Engineering Solutions, LLC 2453 7500 Old Georgetown Road 2454 Suite 1275 2455 Bethesda, MD 20814-6198 2456 United States of America 2458 Email: BSipos@rkf-eng.com 2459 Michael Demmer 2460 University of California, Berkeley 2461 Computer Science Division 2462 445 Soda Hall 2463 Berkeley, CA 94720-1776 2464 United States of America 2466 Email: demmer@cs.berkeley.edu 2468 Joerg Ott 2469 Aalto University 2470 Department of Communications and Networking 2471 PO Box 13000 2472 Aalto 02015 2473 Finland 2475 Email: ott@in.tum.de 2477 Simon Perreault 2478 Quebec, QC 2479 Canada 2481 Email: simon@per.reau.lt