idnits 2.17.1 draft-ietf-dtn-tcpclv4-14.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 date (September 19, 2019) is 1652 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 757, but not defined == Missing Reference: 'PCH' is mentioned on line 635, but not defined == Missing Reference: 'PSI' is mentioned on line 690, but not defined == Missing Reference: 'SI' is mentioned on line 669, but not defined == Missing Reference: 'I1' is mentioned on line 858, but not defined == Missing Reference: 'L1' is mentioned on line 846, but not defined == Missing Reference: 'L2' is mentioned on line 846, but not defined == Missing Reference: 'L3' is mentioned on line 852, 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-12 Summary: 4 errors (**), 0 flaws (~~), 11 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: March 22, 2020 J. Ott 7 Aalto University 8 S. Perreault 9 September 19, 2019 11 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 12 draft-ietf-dtn-tcpclv4-14 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 March 22, 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 . . . . . . . . . . . . . . . . 51 105 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 52 106 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 53 107 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 108 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 109 11.1. Normative References . . . . . . . . . . . . . . . . . . 54 110 11.2. Informative References . . . . . . . . . . . . . . . . . 55 111 Appendix A. Significant changes from RFC7242 . . . . . . . . . . 56 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 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", "SHALL NOT", 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 closing 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 of 1. 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). Regardless of the reason, session termination is 505 initiated by one of the entities and responded-to by the other as 506 illustrated by Figure 13 and Figure 14. Even when there are no 507 transfers queued or in-progress, the session termination procedure 508 allows each entity to distinguish between a clean end to a session 509 and the TCP connection being closed because of some underlying 510 network issue. 512 Once a session is established, TCPCL is a symmetric protocol between 513 the peers. Both sides can start sending data segments in a session, 514 and one side's bundle transfer does not have to complete before the 515 other side can start sending data segments on its own. Hence, the 516 protocol allows for a bi-directional mode of communication. Note 517 that in the case of concurrent bidirectional transmission, 518 acknowledgment segments MAY be interleaved with data segments. 520 3.3. TCPCL States and Transitions 522 The states of a nominal TCPCL session (i.e. without session failures) 523 are indicated in Figure 4. 525 +-------+ 526 | START | 527 +-------+ 528 | 529 TCP Establishment 530 | 531 V 532 +-----------+ +---------------------+ 533 | TCP |----------->| Contact / Session | 534 | Connected | | Negotiation | 535 +-----------+ +---------------------+ 536 | 537 +-----Session Parameters-----+ 538 | Negotiated 539 V 540 +-------------+ +-------------+ 541 | Established |----New Transfer---->| Established | 542 | Session | | Session | 543 | Idle |<---Transfers Done---| Live | 544 +-------------+ +-------------+ 545 | | 546 +------------------------------------+ 547 | 548 [SESSTERM] Exchange 549 | 550 V 551 +-------------+ 552 | Established | +-------------+ 553 | Session |----Transfers------>| TCP | 554 | Ending | Done | Terminating | 555 +-------------+ +-------------+ 556 | 557 +----------TCP Close Message----------+ 558 | 559 V 560 +-------+ 561 | END | 562 +-------+ 564 Figure 4: Top-level states of a TCPCL session 566 Notes on Established Session states: 568 Session "Live" means transmitting or reeiving over a transfer 569 stream. 571 Session "Idle" means no transmission/reception over a transfer 572 stream. 574 Session "Ending" means no new transfers will be allowed. 576 Contact negotation involves exchanging a Contact Header (CH) in both 577 directions and deriving a negotiated state from the two headers. The 578 contact negotiation sequencing is performed either as the active or 579 passive peer, and is illustrated in Figure 5 and Figure 6 580 respectively which both share the data validation and analyze final 581 states of the "[PCH]" activity of Figure 7 and the "[TCPCLOSE]" 582 activity which indicates TCP connection close. Successful 583 negotiation results in one of the Session Initiation "[SI]" 584 activities being performed. 586 +-------+ 587 | START | 588 +-------+ 589 | 590 TCP Connecting 591 V 592 +-----------+ 593 | TCP | +---------+ 594 | Connected |--Send CH-->| Waiting |--Timeout-->[TCPCLOSE] 595 +-----------+ +---------+ 596 | 597 Recevied CH 598 V 599 [PCH] 601 Figure 5: Contact Initiation as Active peer 603 +-----------+ +---------+ 604 | TCP |--Wait for-->| Waiting |--Timeout-->[TCPCLOSE] 605 | Connected | CH +---------+ 606 +-----------+ | 607 Received CH 608 V 609 +-----------------+ 610 | Preparing reply |--Send CH-->[PSI] 611 +-----------------+ 613 Figure 6: Contact Initiation as Passive peer 615 +-----------+ 616 | Peer CH | 617 | available | 618 +-----------+ 619 | 620 Validate and 621 Negotiate 622 V 623 +------------+ 624 | Negotiated |----Failure---->[TCPCLOSE] 625 +------------+ ^ 626 | | | 627 No TLS +----Negotiate---+ | 628 V TLS | Failure 629 +-----------+ V | 630 | TCPCL | +---------------+ 631 | Messaging |<--Success--| TLS Finished | 632 | Available | +---------------+ 633 +-----------+ 635 Figure 7: Processing of Contact Header [PCH] 637 Session negotation involves exchanging a session initialization 638 (SESS_INIT) message in both directions and deriving a negotiated 639 state from the two messages. The session negotiation sequencing is 640 performed either as the active or passive peer, and is illustrated in 641 Figure 8 and Figure 9 respectively which both share the data 642 validation and analyze final states of Figure 10. The validation 643 here includes certificate validation and authentication when TLS is 644 used for the session. 646 +-----------+ 647 | TCPCL | +---------+ 648 | Messaging |--Send SESS_INIT-->| Waiting |--Timeout-->[SESSTERM] 649 | Available | +---------+ 650 +-----------+ | 651 Recevied SESS_INIT 652 | 653 V 654 [PSI] 656 Figure 8: Session Initiation [SI] as Active peer 658 +-----------+ 659 | TCPCL | +---------+ 660 | Messaging |----Wait for ---->| Waiting |--Timeout-->[SESSTERM] 661 | Available | SESS_INIT +---------+ 662 +-----------+ | 663 Recevied SESS_INIT 664 | 665 +-----------------+ 666 | Preparing reply |--Send SESS_INIT-->[PSI] 667 +-----------------+ 669 Figure 9: Session Initiation [SI] as Passive peer 671 +----------------+ 672 | Peer SESS_INIT | 673 | available | 674 +----------------+ 675 | 676 Validate and 677 Negotiate 678 V 679 +------------+ 680 | Negotiated |---Failure--->[SESSTERM] 681 +------------+ 682 | 683 Success 684 V 685 +--------------+ 686 | Established | 687 | Session Idle | 688 +--------------+ 690 Figure 10: Processing of Session Initiation [PSI] 692 Transfers can occur after a session is established and it's not in 693 the ending state. Each transfer occurs within a single logical 694 transfer stream between a sender and a receiver, as illustrated in 695 Figure 11 and Figure 12 respectively. 697 +--Send XFER_SEGMENT--+ 698 +--------+ | | 699 | Stream | +-------------+ | 700 | Idle |---Send XFER_SEGMENT-->| In Progress |<------------+ 701 +--------+ +-------------+ 702 | 703 +---------All segments sent-------+ 704 | 705 V 706 +---------+ +--------+ 707 | Waiting |---- Receive Final---->| Stream | 708 | for Ack | XFER_ACK | IDLE | 709 +---------+ +--------+ 711 Figure 11: Transfer sender states 713 Notes on transfer sending: 715 Pipelining of transfers can occur when the sending entity begins a 716 new transfer while in the "Waiting for Ack" state. 718 +-Receive XFER_SEGMENT-+ 719 +--------+ | Send XFER_ACK | 720 | Stream | +-------------+ | 721 | Idle |--Receive XFER_SEGMENT-->| In Progress |<-------------+ 722 +--------+ +-------------+ 723 | 724 +--------Sent Final XFER_ACK--------+ 725 | 726 V 727 +--------+ 728 | Stream | 729 | Idle | 730 +--------+ 732 Figure 12: Transfer receiver states 734 Session termination involves one entity initiating the termination of 735 the session and the other entity acknowledging the termination. For 736 either entity, it is the sending of the SESS_TERM message which 737 transitions the session to the ending substate. While a session is 738 being terminated only in-progress transfers can be completed and no 739 new transfers can be started. 741 +-----------+ +---------+ 742 | Session |--Send SESS_TERM-->| Session | 743 | Live/Idle | | Ending | 744 +-----------+ +---------+ 746 Figure 13: Session Termination [SESSTERM] from the Initiator 748 +-----------+ +---------+ 749 | Session |--Send SESS_TERM-->| Session | 750 | Live/Idle | | Ending | 751 +-----------+<------+ +---------+ 752 | | 753 Receive SESS_TERM | 754 | | 755 +-------------+ 757 Figure 14: Session Termination [SESSTERM] from the Responder 759 3.4. Transfer Segmentation Policies 761 Each TCPCL session allows a negotiated transfer segmentation polcy to 762 be applied in each transfer direction. A receiving node can set the 763 Segment MRU in its contact header to determine the largest acceptable 764 segment size, and a transmitting node can segment a transfer into any 765 sizes smaller than the receiver's Segment MRU. It is a network 766 administration matter to determine an appropriate segmentation policy 767 for entities operating TCPCL, but guidance given here can be used to 768 steer policy toward performance goals. It is also advised to 769 consider the Segment MRU in relation to chunking/packetization 770 performed by TLS, TCP, and any intermediate network-layer nodes. 772 Minimum Overhead: For a simple network expected to exchange 773 relatively small bundles, the Segment MRU can be set to be 774 identical to the Transfer MRU which indicates that all transfers 775 can be sent with a single data segment (i.e. no actual 776 segmentation). If the network is closed and all transmitters are 777 known to follow a single-segment transfer policy, then receivers 778 can avoid the necessity of segment reassembly. Because this CL 779 operates over a TCP stream, which suffers from a form of head-of- 780 queue blocking between messages, while one node is transmitting a 781 single XFER_SEGMENT message it is not able to transmit any 782 XFER_ACK or XFER_REFUSE for any associated received transfers. 784 Predictable Message Sizing: In situations where the maximum message 785 size is desired to be well-controlled, the Segment MRU can be set 786 to the largest acceptable size (the message size less XFER_SEGMENT 787 header size) and transmitters can always segment a transfer into 788 maximum-size chunks no larger than the Segment MRU. This 789 guarantees that any single XFER_SEGMENT will not monopolize the 790 TCP stream for too long, which would prevent outgoing XFER_ACK and 791 XFER_REFUSE associated with received transfers. 793 Dynamic Segmentation: Even after negotiation of a Segment MRU for 794 each receiving node, the actual transfer segmentation only needs 795 to guarantee than any individual segment is no larger than that 796 MRU. In a situation where network "goodput" is dynamic, the 797 transfer segmentation size can also be dynamic in order to control 798 message transmission duration. 800 Many other policies can be established in a TCPCL network between the 801 two extremes of minimum overhead (large MRU, single-segment) and 802 predictable message sizing (small MRU, highly segmented). Different 803 policies can be applied to each transfer stream to and from from any 804 particular node. Additionally, future header and transfer extension 805 types can apply further nuance to transfer policies and policy 806 negotiation. 808 3.5. Example Message Exchange 810 The following figure depicts the protocol exchange for a simple 811 session, showing the session establishment and the transmission of a 812 single bundle split into three data segments (of lengths "L1", "L2", 813 and "L3") from Entity A to Entity B. 815 Note that the sending node can transmit multiple XFER_SEGMENT 816 messages without waiting for the corresponding XFER_ACK responses. 817 This enables pipelining of messages on a transfer stream. Although 818 this example only demonstrates a single bundle transmission, it is 819 also possible to pipeline multiple XFER_SEGMENT messages for 820 different bundles without necessarily waiting for XFER_ACK messages 821 to be returned for each one. However, interleaving data segments 822 from different bundles is not allowed. 824 No errors or rejections are shown in this example. 826 Entity A Entity B 827 ======== ======== 828 +-------------------------+ 829 | Contact Header | -> +-------------------------+ 830 +-------------------------+ <- | Contact Header | 831 +-------------------------+ 832 +-------------------------+ 833 | SESS_INIT | -> +-------------------------+ 834 +-------------------------+ <- | SESS_INIT | 835 +-------------------------+ 837 +-------------------------+ 838 | XFER_SEGMENT (start) | -> 839 | Transfer ID [I1] | 840 | Length [L1] | 841 | Bundle Data 0..(L1-1) | 842 +-------------------------+ 843 +-------------------------+ +-------------------------+ 844 | XFER_SEGMENT | -> <- | XFER_ACK (start) | 845 | Transfer ID [I1] | | Transfer ID [I1] | 846 | Length [L2] | | Length [L1] | 847 |Bundle Data L1..(L1+L2-1)| +-------------------------+ 848 +-------------------------+ 849 +-------------------------+ +-------------------------+ 850 | XFER_SEGMENT (end) | -> <- | XFER_ACK | 851 | Transfer ID [I1] | | Transfer ID [I1] | 852 | Length [L3] | | Length [L1+L2] | 853 |Bundle Data | +-------------------------+ 854 | (L1+L2)..(L1+L2+L3-1)| 855 +-------------------------+ 856 +-------------------------+ 857 <- | XFER_ACK (end) | 858 | Transfer ID [I1] | 859 | Length [L1+L2+L3] | 860 +-------------------------+ 862 +-------------------------+ 863 | SESS_TERM | -> +-------------------------+ 864 +-------------------------+ <- | SESS_TERM | 865 +-------------------------+ 867 Figure 15: An example of the flow of protocol messages on a single 868 TCP Session between two entities 870 4. Session Establishment 872 For bundle transmissions to occur using the TCPCL, a TCPCL session 873 MUST first be established between communicating entities. It is up 874 to the implementation to decide how and when session setup is 875 triggered. For example, some sessions MAY be opened proactively and 876 maintained for as long as is possible given the network conditions, 877 while other sessions MAY be opened only when there is a bundle that 878 is queued for transmission and the routing algorithm selects a 879 certain next-hop node. 881 4.1. TCP Connection 883 To establish a TCPCL session, an entity MUST first establish a TCP 884 connection with the intended peer entity, typically by using the 885 services provided by the operating system. Destination port number 886 4556 has been assigned by IANA as the Registered Port number for the 887 TCP convergence layer. Other destination port numbers MAY be used 888 per local configuration. Determining a peer's destination port 889 number (if different from the registered TCPCL port number) is up to 890 the implementation. Any source port number MAY be used for TCPCL 891 sessions. Typically an operating system assigned number in the TCP 892 Ephemeral range (49152-65535) is used. 894 If the entity is unable to establish a TCP connection for any reason, 895 then it is an implementation matter to determine how to handle the 896 connection failure. An entity MAY decide to re-attempt to establish 897 the connection. If it does so, it MUST NOT overwhelm its target with 898 repeated connection attempts. Therefore, the entity MUST retry the 899 connection setup no earlier than some delay time from the last 900 attempt, and it SHOULD use a (binary) exponential back-off mechanism 901 to increase this delay in case of repeated failures. The upper limit 902 on a re-attempt back-off is implementation defined but SHOULD be no 903 longer than one minute before signaling to the BP agent that a 904 connection cannot be made. 906 Once a TCP connection is established, each entity MUST immediately 907 transmit a contact header over the TCP connection. The format of the 908 contact header is described in Section 4.2. Because the TCPCL 909 protocol version in use is part of the initial contact header, nodes 910 using TCPCL version 4 can coexist on a network with nodes using 911 earlier TCPCL versions (with some negotiation needed for 912 interoperation as described in Section 4.3). 914 4.2. Contact Header 916 Once a TCP connection is established, both parties exchange a contact 917 header. This section describes the format of the contact header and 918 the meaning of its fields. 920 Upon receipt of the contact header, both entities perform the 921 validation and negotiation procedures defined in Section 4.3. After 922 receiving the contact header from the other entity, either entity MAY 923 refuse the session by sending a SESS_TERM message with an appropriate 924 reason code. 926 The format for the Contact Header is as follows: 928 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 929 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 930 +---------------+---------------+---------------+---------------+ 931 | magic='dtn!' | 932 +---------------+---------------+---------------+---------------+ 933 | Version | Flags | 934 +---------------+---------------+ 936 Figure 16: Contact Header Format 938 See Section 4.3 for details on the use of each of these contact 939 header fields. 941 The fields of the contact header are: 943 magic: A four-octet field that always contains the octet sequence 944 0x64 0x74 0x6E 0x21, i.e., the text string "dtn!" in US-ASCII (and 945 UTF-8). 947 Version: A one-octet field value containing the value 4 (current 948 version of the TCPCL). 950 Flags: A one-octet field of single-bit flags, interpreted according 951 to the descriptions in Table 1. All reserved header flag bits 952 SHALL be set to 0 by the sender. All reserved header flag bits 953 SHALL be ignored by the receiver. 955 +----------+--------+-----------------------------------------------+ 956 | Name | Code | Description | 957 +----------+--------+-----------------------------------------------+ 958 | CAN_TLS | 0x01 | If bit is set, indicates that the sending | 959 | | | peer is capable of TLS security. | 960 | | | | 961 | Reserved | others | 962 +----------+--------+-----------------------------------------------+ 964 Table 1: Contact Header Flags 966 4.3. Contact Validation and Negotiation 968 Upon reception of the contact header, each node follows the following 969 procedures to ensure the validity of the TCPCL session and to 970 negotiate values for the session parameters. 972 If the magic string is not present or is not valid, the connection 973 MUST be terminated. The intent of the magic string is to provide 974 some protection against an inadvertent TCP connection by a different 975 protocol than the one described in this document. To prevent a flood 976 of repeated connections from a misconfigured application, an entity 977 MAY elect to hold an invalid connection open and idle for some time 978 before ending it. 980 The first negotiation is on the TCPCL protocol version to use. The 981 active node always sends its Contact Header first and waits for a 982 response from the passive node. The active node can repeatedly 983 attempt different protocol versions in descending order until the 984 passive node accepts one with a corresponding Contact Header reply. 985 Only upon response of a Contact Header from the passive node is the 986 TCPCL protocol version established and parameter negotiation begun. 988 During contact initiation, the active TCPCL node SHALL send the 989 highest TCPCL protocol version on a first session attempt for a TCPCL 990 peer. If the active node receives a Contact Header with a different 991 protocol version than the one sent earlier on the TCP connection, the 992 TCP connection SHALL be closed. If the active node receives a 993 SESS_TERM message with reason of "Version Mismatch", that node MAY 994 attempt further TCPCL sessions with the peer using earlier protocol 995 version numbers in decreasing order. Managing multi-TCPCL-session 996 state such as this is an implementation matter. 998 If the passive node receives a contact header containing a version 999 that is greater than the current version of the TCPCL that the node 1000 implements, then the node SHALL shutdown the session with a reason 1001 code of "Version mismatch". If the passive node receives a contact 1002 header with a version that is lower than the version of the protocol 1003 that the node implements, the node MAY either terminate the session 1004 (with a reason code of "Version mismatch") or the node MAY adapt its 1005 operation to conform to the older version of the protocol. The 1006 decision of version fall-back is an implementation matter. 1008 4.4. Session Security 1010 This version of the TCPCL supports establishing a Transport Layer 1011 Security (TLS) session within an existing TCP connection. When TLS 1012 is used within the TCPCL it affects the entire session. Once 1013 established, there is no mechanism available to downgrade a TCPCL 1014 session to non-TLS operation. If this is desired, the entire TCPCL 1015 session MUST be terminated and a new non-TLS-negotiated session 1016 established. 1018 4.4.1. TLS Handshake 1020 The use of TLS is negotated using the Contact Header as described in 1021 Section 4.3. After negotiating an Enable TLS parameter of true, and 1022 before any other TCPCL messages are sent within the session, the 1023 session entities SHALL begin a TLS handshake in accordance with TLS 1024 1.2 [RFC5246] or any successors that are compatible with TLS 1.2. By 1025 convention, this protocol uses the node which initiated the 1026 underlying TCP connection as the "client" role of the TLS handshake 1027 request. 1029 The TLS handshake, if it occurs, is considered to be part of the 1030 contact negotiation before the TCPCL session itself is established. 1031 Specifics about sensitive data exposure are discussed in Section 8. 1033 The parameters within each TLS negotiation are implementation 1034 dependent but any TCPCL node SHALL follow all recommended practices 1035 of BCP 195 [RFC7525], or any updates or successors that become part 1036 of BCP 195. When possible, the TLS handshake SHOULD include a Server 1037 Name Indication (SNI) from the active peer in accordance with 1038 [RFC6066]. The SNI SHALL contain the same host name used to 1039 establish the TCP connection. The passive peer MAY use the SNI host 1040 name to choose an appropriate server-side certificate. The TLS 1041 handshake SHALL request a client-side certificate to allow 1042 authentication of the active peer. The passive peer SHOULD supply a 1043 certificate within the TLS handshake to allow authentication of its 1044 side of the session. The active peer SHOULD supply a certificate 1045 within the TLS handshake to allow authentication of its side of the 1046 session. All certificates supplied during TLS handshake SHALL 1047 conform with the profile of [RFC5280], or any updates or successors 1048 to that profile. When a certificate is supplied during TLS 1049 handshake, the full certification chain SHOULD be included unless 1050 security policy indicates that is unnecessary. 1052 If a TLS handshake cannot negotiate a TLS session, both entities of 1053 the TCPCL session SHALL close the TCP connection. At this point the 1054 TCPCL session has not yet been established so there is no TCPCL 1055 session to terminate. This also avoids any potential security issues 1056 assoicated with further TCP communication with an untrusted peer. 1058 After a TLS session is successfully established, the active peer 1059 SHALL send a SESS_INIT message to begin session negotiation. This 1060 session negotation and all subsequent messaging are secured. 1062 4.4.2. TLS Authentication 1064 Using X.509 certificates exchanged during the TLS handshake, each of 1065 the entities can attempt to authenticate its peer at the network 1066 layer (host name and address) and at the application layer (BP Node 1067 ID). The Node ID exchanged in the Session Initialization is likely 1068 to be used by the BP agent for making transfer and routing decisions, 1069 so attempting host name validation is optional while attempting Node 1070 ID validation is required. The logic for attempting validation is 1071 separate from the logic for handling the result of validation, which 1072 is based on local security policy. 1074 Any certificate received during TLS handshake SHALL be validated up 1075 to one or more trusted certificate authority (CA) certificates. If 1076 certificate validation fails or if security policy disallows a 1077 certificate for any reason, the entity SHOULD terminate the session 1078 (with a reason code of "Contact Failure"). 1080 Immediately after the TLS handshake, each side of the TCP connection 1081 SHOULD perform host name validation of its peer in accordance with 1082 [RFC6125] unless it is not needed by security policy. The active 1083 peer SHALL attempt to authenticate the host name (of the passive 1084 peer) used to initiate the TCP connection. The active peer MAY 1085 attempt to authenticate the IP address of the other side of the TCP 1086 connection. The passive peer SHALL attempt to authenticate the IP 1087 address of the other side of the TCP connection. The passive peer 1088 MAY use the IP address to resolve one or more host names of the 1089 active peer and attempt to authenticate those. If host name 1090 validation fails (including failure because the certificate does not 1091 contain any DNS-ID), the entity SHOULD terminate the session (with a 1092 reason code of "Contact Failure") unless security policy allows an 1093 unauthticated host. 1095 Immediately before Session Parameter Negotiation, each side of the 1096 session SHALL perform Node ID validation of its peer as described 1097 below. Node ID validation SHALL succeed if the associated 1098 certificate contains a subjectAltName entry of type 1099 uniformResourceIdentifier whose value matches the Node ID of the 1100 TCPCL entity. Unless specified otherwise by the definition of the 1101 URI scheme being authenticated, URI matching of Node IDs SHALL use 1102 the URI comparison logic of [RFC3986] and scheme-based normalization 1103 of those schemes specified in [I-D.ietf-dtn-bpbis]. This is similar 1104 to the URI-ID of [RFC6125] but does not require any structure to the 1105 scheme-specific-part of the URI. A URI scheme can refine this "exact 1106 match" logic with rules about how Node IDs within that scheme are to 1107 be compared with the certificate-authenticated URI. If Node ID 1108 validation fails (including failure because the certificate does not 1109 contain any subjectAltName URI), the entity SHOULD terminate the 1110 session (with a reason code of "Contact Failure") unless security 1111 policy allows an unauthticated node. 1113 4.4.3. Example TLS Initiation 1115 A summary of a typical TLS use is shown in the sequence in Figure 17 1116 below. 1118 Entity A Entity B 1119 active peer passive peer 1121 +-------------------------+ 1122 | Open TCP Connnection | -> 1123 +-------------------------+ +-------------------------+ 1124 <- | Accept Connection | 1125 +-------------------------+ 1127 +-------------------------+ 1128 | Contact Header | -> 1129 +-------------------------+ +-------------------------+ 1130 <- | Contact Header | 1131 +-------------------------+ 1133 +-------------------------+ +-------------------------+ 1134 | TLS Negotiation | -> <- | TLS Negotiation | 1135 | (as client) | | (as server) | 1136 +-------------------------+ +-------------------------+ 1138 Host name validation occurs. 1139 Secured TCPCL messaging can begin. 1141 +-------------------------+ +-------------------------+ 1142 | SESS_INIT | -> <- | SESS_INIT | 1143 +-------------------------+ +-------------------------+ 1145 Node ID validation occurs. 1146 Session is established, transfers can begin. 1148 +-------------------------+ +-------------------------+ 1149 | SESS_TERM | -> <- | SESS_TERM | 1150 +-------------------------+ +-------------------------+ 1152 Figure 17: A simple visual example of TCPCL TLS Establishment between 1153 two entities 1155 4.5. Message Header 1157 After the initial exchange of a contact header, all messages 1158 transmitted over the session are identified by a one-octet header 1159 with the following structure: 1161 0 1 2 3 4 5 6 7 1162 +---------------+ 1163 | Message Type | 1164 +---------------+ 1166 Figure 18: Format of the Message Header 1168 The message header fields are as follows: 1170 Message Type: Indicates the type of the message as per Table 2 1171 below. Encoded values are listed in Section 9.5. 1173 +--------------+------+---------------------------------------------+ 1174 | Name | Code | Description | 1175 +--------------+------+---------------------------------------------+ 1176 | SESS_INIT | 0x07 | Contains the session parameter inputs from | 1177 | | | one of the entities, as described in | 1178 | | | Section 4.6. | 1179 | | | | 1180 | SESS_TERM | 0x05 | Indicates that one of the entities | 1181 | | | participating in the session wishes to | 1182 | | | cleanly terminate the session, as described | 1183 | | | in Section 6. | 1184 | | | | 1185 | XFER_SEGMENT | 0x01 | Indicates the transmission of a segment of | 1186 | | | bundle data, as described in Section 5.2.2. | 1187 | | | | 1188 | XFER_ACK | 0x02 | Acknowledges reception of a data segment, | 1189 | | | as described in Section 5.2.3. | 1190 | | | | 1191 | XFER_REFUSE | 0x03 | Indicates that the transmission of the | 1192 | | | current bundle SHALL be stopped, as | 1193 | | | described in Section 5.2.4. | 1194 | | | | 1195 | KEEPALIVE | 0x04 | Used to keep TCPCL session active, as | 1196 | | | described in Section 5.1.1. | 1197 | | | | 1198 | MSG_REJECT | 0x06 | Contains a TCPCL message rejection, as | 1199 | | | described in Section 5.1.2. | 1200 +--------------+------+---------------------------------------------+ 1202 Table 2: TCPCL Message Types 1204 4.6. Session Initialization Message (SESS_INIT) 1206 Before a session is established and ready to transfer bundles, the 1207 session parameters are negotiated between the connected entities. 1208 The SESS_INIT message is used to convey the per-entity parameters 1209 which are used together to negotiate the per-session parameters as 1210 described in Section 4.7. 1212 The format of a SESS_INIT message is as follows in Figure 19. 1214 +-----------------------------+ 1215 | Message Header | 1216 +-----------------------------+ 1217 | Keepalive Interval (U16) | 1218 +-----------------------------+ 1219 | Segment MRU (U64) | 1220 +-----------------------------+ 1221 | Transfer MRU (U64) | 1222 +-----------------------------+ 1223 | Node ID Length (U16) | 1224 +-----------------------------+ 1225 | Node ID Data (variable) | 1226 +-----------------------------+ 1227 | Session Extension | 1228 | Items Length (U32) | 1229 +-----------------------------+ 1230 | Session Extension | 1231 | Items (var.) | 1232 +-----------------------------+ 1234 Figure 19: SESS_INIT Format 1236 The fields of the SESS_INIT message are: 1238 Keepalive Interval: A 16-bit unsigned integer indicating the 1239 interval, in seconds, between any subsequent messages being 1240 transmitted by the peer. The peer receiving this contact header 1241 uses this interval to determine how long to wait after any last- 1242 message transmission and a necessary subsequent KEEPALIVE message 1243 transmission. 1245 Segment MRU: A 64-bit unsigned integer indicating the largest 1246 allowable single-segment data payload size to be received in this 1247 session. Any XFER_SEGMENT sent to this peer SHALL have a data 1248 payload no longer than the peer's Segment MRU. The two entities 1249 of a single session MAY have different Segment MRUs, and no 1250 relation between the two is required. 1252 Transfer MRU: A 64-bit unsigned integer indicating the largest 1253 allowable total-bundle data size to be received in this session. 1254 Any bundle transfer sent to this peer SHALL have a Total Bundle 1255 Length payload no longer than the peer's Transfer MRU. This value 1256 can be used to perform proactive bundle fragmentation. The two 1257 entities of a single session MAY have different Transfer MRUs, and 1258 no relation between the two is required. 1260 Node ID Length and Node ID Data: Together these fields represent a 1261 variable-length text string. The Node ID Length is a 16-bit 1262 unsigned integer indicating the number of octets of Node ID Data 1263 to follow. A zero-length Node ID SHALL be used to indicate the 1264 lack of Node ID rather than a truly empty Node ID. This case 1265 allows an entity to avoid exposing Node ID information on an 1266 untrusted network. A non-zero-length Node ID Data SHALL contain 1267 the UTF-8 encoded Node ID of the Entity which sent the SESS_INIT 1268 message. Every Node ID SHALL be a URI consistent with the 1269 requirements of [RFC3986] and the URI schemes of 1270 [I-D.ietf-dtn-bpbis]. The Node ID itself can be authenticated as 1271 described in Section 4.4.2. 1273 Session Extension Length and Session Extension Items: Together these 1274 fields represent protocol extension data not defined by this 1275 specification. The Session Extension Length is the total number 1276 of octets to follow which are used to encode the Session Extension 1277 Item list. The encoding of each Session Extension Item is within 1278 a consistent data container as described in Section 4.8. The full 1279 set of Session Extension Items apply for the duration of the TCPCL 1280 session to follow. The order and mulitplicity of these Session 1281 Extension Items MAY be significant, as defined in the associated 1282 type specification(s). 1284 4.7. Session Parameter Negotiation 1286 An entity calculates the parameters for a TCPCL session by 1287 negotiating the values from its own preferences (conveyed by the 1288 contact header it sent to the peer) with the preferences of the peer 1289 node (expressed in the contact header that it received from the 1290 peer). The negotiated parameters defined by this specification are 1291 described in the following paragraphs. 1293 Transfer MTU and Segment MTU: The maximum transmit unit (MTU) for 1294 whole transfers and individual segments are idententical to the 1295 Transfer MRU and Segment MRU, respectively, of the recevied 1296 contact header. A transmitting peer can send individual segments 1297 with any size smaller than the Segment MTU, depending on local 1298 policy, dynamic network conditions, etc. Determining the size of 1299 each transmitted segment is an implementation matter. 1301 Session Keepalive: Negotiation of the Session Keepalive parameter is 1302 performed by taking the minimum of this two contact headers' 1303 Keepalive Interval. The Session Keepalive interval is a parameter 1304 for the behavior described in Section 5.1.1. 1306 Enable TLS: Negotiation of the Enable TLS parameter is performed by 1307 taking the logical AND of the two contact headers' CAN_TLS flags. 1308 A local security policy is then applied to determine of the 1309 negotated value of Enable TLS is acceptable. It can be a 1310 reasonable security policy to both require or disallow the use of 1311 TLS depending upon the desired network flows. Because this state 1312 is negotiated over an unsecured medium, there is a risk of a TLS 1313 Stripping as described in Section 8. If the Enable TLS state is 1314 unacceptable, the node SHALL terminate the session with a reason 1315 code of "Contact Failure". Note that this contact failure reason 1316 is different than a failure of TLS handshake or TLS authentication 1317 after an agreed-upon and acceptable Enable TLS state. If the 1318 negotiated Enable TLS value is true and acceptable then TLS 1319 negotiation feature (described in Section 4.4) begins immediately 1320 following the contact header exchange. 1322 Once this process of parameter negotiation is completed (which 1323 includes a possible completed TLS handshake of the connection to use 1324 TLS), this protocol defines no additional mechanism to change the 1325 parameters of an established session; to effect such a change, the 1326 TCPCL session MUST be terminated and a new session established. 1328 4.8. Session Extension Items 1330 Each of the Session Extension Items SHALL be encoded in an identical 1331 Type-Length-Value (TLV) container form as indicated in Figure 20. 1333 The fields of the Session Extension Item are: 1335 Flags: A one-octet field containing generic bit flags about the 1336 Item, which are listed in Table 3. All reserved header flag bits 1337 SHALL be set to 0 by the sender. All reserved header flag bits 1338 SHALL be ignored by the receiver. If a TCPCL entity receives a 1339 Session Extension Item with an unknown Item Type and the CRITICAL 1340 flag of 1, the entity SHALL close the TCPCL session with SESS_TERM 1341 reason code of "Contact Failure". If the CRITICAL flag is 0, an 1342 entity SHALL skip over and ignore any item with an unknown Item 1343 Type. 1345 Item Type: A 16-bit unsigned integer field containing the type of 1346 the extension item. This specification does not define any 1347 extension types directly, but does allocate an IANA registry for 1348 such codes (see Section 9.3). 1350 Item Length: A 16-bit unsigned integer field containing the number 1351 of Item Value octets to follow. 1353 Item Value: A variable-length data field which is interpreted 1354 according to the associated Item Type. This specification places 1355 no restrictions on an extension's use of available Item Value 1356 data. Extension specifications SHOULD avoid the use of large data 1357 lengths, as no bundle transfers can begin until the full extension 1358 data is sent. 1360 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1361 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 1362 +---------------+---------------+---------------+---------------+ 1363 | Item Flags | Item Type | Item Length...| 1364 +---------------+---------------+---------------+---------------+ 1365 | length contd. | Item Value... | 1366 +---------------+---------------+---------------+---------------+ 1368 Figure 20: Session Extension Item Format 1370 +----------+--------+-----------------------------------------------+ 1371 | Name | Code | Description | 1372 +----------+--------+-----------------------------------------------+ 1373 | CRITICAL | 0x01 | If bit is set, indicates that the receiving | 1374 | | | peer must handle the extension item. | 1375 | | | | 1376 | Reserved | others | 1377 +----------+--------+-----------------------------------------------+ 1379 Table 3: Session Extension Item Flags 1381 5. Established Session Operation 1383 This section describes the protocol operation for the duration of an 1384 established session, including the mechanism for transmitting bundles 1385 over the session. 1387 5.1. Upkeep and Status Messages 1389 5.1.1. Session Upkeep (KEEPALIVE) 1391 The protocol includes a provision for transmission of KEEPALIVE 1392 messages over the TCPCL session to help determine if the underlying 1393 TCP connection has been disrupted. 1395 As described in Section 4.3, a negotiated parameter of each session 1396 is the Session Keepalive interval. If the negotiated Session 1397 Keepalive is zero (i.e. one or both contact headers contains a zero 1398 Keepalive Interval), then the keepalive feature is disabled. There 1399 is no logical minimum value for the keepalive interval, but when used 1400 for many sessions on an open, shared network a short interval could 1401 lead to excessive traffic. For shared network use, entities SHOULD 1402 choose a keepalive interval no shorter than 30 seconds. There is no 1403 logical maximum value for the keepalive interval, but an idle TCP 1404 connection is liable for closure by the host operating system if the 1405 keepalive time is longer than tens-of-minutes. Entities SHOULD 1406 choose a keepalive interval no longer than 10 minutes (600 seconds). 1408 Note: The Keepalive Interval SHOULD NOT be chosen too short as TCP 1409 retransmissions MAY occur in case of packet loss. Those will have to 1410 be triggered by a timeout (TCP retransmission timeout (RTO)), which 1411 is dependent on the measured RTT for the TCP connection so that 1412 KEEPALIVE messages MAY experience noticeable latency. 1414 The format of a KEEPALIVE message is a one-octet message type code of 1415 KEEPALIVE (as described in Table 2) with no additional data. Both 1416 sides SHALL send a KEEPALIVE message whenever the negotiated interval 1417 has elapsed with no transmission of any message (KEEPALIVE or other). 1419 If no message (KEEPALIVE or other) has been received in a session 1420 after some implementation-defined time duration, then the node SHALL 1421 terminate the session by transmitting a SESS_TERM message (as 1422 described in Section 6.1) with reason code "Idle Timeout". If 1423 configurable, the idle timeout duration SHOULD be no shorter than 1424 twice the keepalive interval. If not configurable, the idle timeout 1425 duration SHOULD be exactly twice the keepalive interval. 1427 5.1.2. Message Rejection (MSG_REJECT) 1429 If a TCPCL node receives a message which is unknown to it (possibly 1430 due to an unhandled protocol mismatch) or is inappropriate for the 1431 current session state (e.g. a KEEPALIVE message received after 1432 contact header negotiation has disabled that feature), there is a 1433 protocol-level message to signal this condition in the form of a 1434 MSG_REJECT reply. 1436 The format of a MSG_REJECT message is as follows in Figure 21. 1438 +-----------------------------+ 1439 | Message Header | 1440 +-----------------------------+ 1441 | Reason Code (U8) | 1442 +-----------------------------+ 1443 | Rejected Message Header | 1444 +-----------------------------+ 1446 Figure 21: Format of MSG_REJECT Messages 1448 The fields of the MSG_REJECT message are: 1450 Reason Code: A one-octet refusal reason code interpreted according 1451 to the descriptions in Table 4. 1453 Rejected Message Header: The Rejected Message Header is a copy of 1454 the Message Header to which the MSG_REJECT message is sent as a 1455 response. 1457 +-------------+------+----------------------------------------------+ 1458 | Name | Code | Description | 1459 +-------------+------+----------------------------------------------+ 1460 | Message | 0x01 | A message was received with a Message Type | 1461 | Type | | code unknown to the TCPCL node. | 1462 | Unknown | | | 1463 | | | | 1464 | Message | 0x02 | A message was received but the TCPCL node | 1465 | Unsupported | | cannot comply with the message contents. | 1466 | | | | 1467 | Message | 0x03 | A message was received while the session is | 1468 | Unexpected | | in a state in which the message is not | 1469 | | | expected. | 1470 +-------------+------+----------------------------------------------+ 1472 Table 4: MSG_REJECT Reason Codes 1474 5.2. Bundle Transfer 1476 All of the messages in this section are directly associated with 1477 transferring a bundle between TCPCL entities. 1479 A single TCPCL transfer results in a bundle (handled by the 1480 convergence layer as opaque data) being exchanged from one node to 1481 the other. In TCPCL a transfer is accomplished by dividing a single 1482 bundle up into "segments" based on the receiving-side Segment MRU 1483 (see Section 4.2). The choice of the length to use for segments is 1484 an implementation matter, but each segment MUST be no larger than the 1485 receiving node's maximum receive unit (MRU) (see the field "Segment 1486 MRU" of Section 4.2). The first segment for a bundle is indicated by 1487 the 'START' flag and the last segment is indicated by the 'END' flag. 1489 A single transfer (and by extension a single segment) SHALL NOT 1490 contain data of more than a single bundle. This requirement is 1491 imposed on the agent using the TCPCL rather than TCPCL itself. 1493 If multiple bundles are transmitted on a single TCPCL connection, 1494 they MUST be transmitted consecutively without interleaving of 1495 segments from multiple bundles. 1497 5.2.1. Bundle Transfer ID 1499 Each of the bundle transfer messages contains a Transfer ID which is 1500 used to correlate messages (from both sides of a transfer) for each 1501 bundle. A Transfer ID does not attempt to address uniqueness of the 1502 bundle data itself and has no relation to concepts such as bundle 1503 fragmentation. Each invocation of TCPCL by the bundle protocol 1504 agent, requesting transmission of a bundle (fragmentary or 1505 otherwise), results in the initiation of a single TCPCL transfer. 1506 Each transfer entails the sending of a sequence of some number of 1507 XFER_SEGMENT and XFER_ACK messages; all are correlated by the same 1508 Transfer ID. 1510 Transfer IDs from each node SHALL be unique within a single TCPCL 1511 session. The initial Transfer ID from each node SHALL have value 1512 zero. Subsequent Transfer ID values SHALL be incremented from the 1513 prior Transfer ID value by one. Upon exhaustion of the entire 64-bit 1514 Transfer ID space, the sending node SHALL terminate the session with 1515 SESS_TERM reason code "Resource Exhaustion". 1517 For bidirectional bundle transfers, a TCPCL node SHOULD NOT rely on 1518 any relation between Transfer IDs originating from each side of the 1519 TCPCL session. 1521 5.2.2. Data Transmission (XFER_SEGMENT) 1523 Each bundle is transmitted in one or more data segments. The format 1524 of a XFER_SEGMENT message follows in Figure 22. 1526 +------------------------------+ 1527 | Message Header | 1528 +------------------------------+ 1529 | Message Flags (U8) | 1530 +------------------------------+ 1531 | Transfer ID (U64) | 1532 +------------------------------+ 1533 | Transfer Extension | 1534 | Items Length (U32) | 1535 | (only for START segment) | 1536 +------------------------------+ 1537 | Transfer Extension | 1538 | Items (var.) | 1539 | (only for START segment) | 1540 +------------------------------+ 1541 | Data length (U64) | 1542 +------------------------------+ 1543 | Data contents (octet string) | 1544 +------------------------------+ 1546 Figure 22: Format of XFER_SEGMENT Messages 1548 The fields of the XFER_SEGMENT message are: 1550 Message Flags: A one-octet field of single-bit flags, interpreted 1551 according to the descriptions in Table 5. All reserved header 1552 flag bits SHALL be set to 0 by the sender. All reserved header 1553 flag bits SHALL be ignored by the receiver. 1555 Transfer ID: A 64-bit unsigned integer identifying the transfer 1556 being made. 1558 Transfer Extension Length and Transfer Extension Items: Together 1559 these fields represent protocol extension data for this 1560 specification. The Transfer Extension Length and Transfer 1561 Extension Item fields SHALL only be present when the 'START' flag 1562 is set to 1 on the message. The Transfer Extension Length is the 1563 total number of octets to follow which are used to encode the 1564 Transfer Extension Item list. The encoding of each Transfer 1565 Extension Item is within a consistent data container as described 1566 in Section 5.2.5. The full set of transfer extension items apply 1567 only to the assoicated single transfer. The order and 1568 mulitplicity of these transfer extension items MAY be significant, 1569 as defined in the associated type specification(s). 1571 Data length: A 64-bit unsigned integer indicating the number of 1572 octets in the Data contents to follow. 1574 Data contents: The variable-length data payload of the message. 1576 +----------+--------+-----------------------------------------------+ 1577 | Name | Code | Description | 1578 +----------+--------+-----------------------------------------------+ 1579 | END | 0x01 | If bit is set, indicates that this is the | 1580 | | | last segment of the transfer. | 1581 | | | | 1582 | START | 0x02 | If bit is set, indicates that this is the | 1583 | | | first segment of the transfer. | 1584 | | | | 1585 | Reserved | others | 1586 +----------+--------+-----------------------------------------------+ 1588 Table 5: XFER_SEGMENT Flags 1590 The flags portion of the message contains two optional values in the 1591 two low-order bits, denoted 'START' and 'END' in Table 5. The 1592 'START' flag SHALL be set to 1 when transmitting the first segment of 1593 a transfer. The 'END' flag SHALL be set to 1 when transmitting the 1594 last segment of a transfer. In the case where an entire transfer is 1595 accomplished in a single segment, both the 'START' and 'END' flags 1596 SHALL be set to 1. 1598 Once a transfer of a bundle has commenced, the node MUST only send 1599 segments containing sequential portions of that bundle until it sends 1600 a segment with the 'END' flag set to 1. No interleaving of multiple 1601 transfers from the same node is possible within a single TCPCL 1602 session. Simultaneous transfers between two entities MAY be achieved 1603 using multiple TCPCL sessions. 1605 5.2.3. Data Acknowledgments (XFER_ACK) 1607 Although the TCP transport provides reliable transfer of data between 1608 transport peers, the typical BSD sockets interface provides no means 1609 to inform a sending application of when the receiving application has 1610 processed some amount of transmitted data. Thus, after transmitting 1611 some data, the TCPCL needs an additional mechanism to determine 1612 whether the receiving agent has successfully received the segment. 1613 To this end, the TCPCL protocol provides feedback messaging whereby a 1614 receiving node transmits acknowledgments of reception of data 1615 segments. 1617 The format of an XFER_ACK message follows in Figure 23. 1619 +-----------------------------+ 1620 | Message Header | 1621 +-----------------------------+ 1622 | Message Flags (U8) | 1623 +-----------------------------+ 1624 | Transfer ID (U64) | 1625 +-----------------------------+ 1626 | Acknowledged length (U64) | 1627 +-----------------------------+ 1629 Figure 23: Format of XFER_ACK Messages 1631 The fields of the XFER_ACK message are: 1633 Message Flags: A one-octet field of single-bit flags, interpreted 1634 according to the descriptions in Table 5. All reserved header 1635 flag bits SHALL be set to 0 by the sender. All reserved header 1636 flag bits SHALL be ignored by the receiver. 1638 Transfer ID: A 64-bit unsigned integer identifying the transfer 1639 being acknowledged. 1641 Acknowledged length: A 64-bit unsigned integer indicating the total 1642 number of octets in the transfer which are being acknowledged. 1644 A receiving TCPCL node SHALL send an XFER_ACK message in response to 1645 each received XFER_SEGMENT message. The flags portion of the 1646 XFER_ACK header SHALL be set to match the corresponding DATA_SEGMENT 1647 message being acknowledged. The acknowledged length of each XFER_ACK 1648 contains the sum of the data length fields of all XFER_SEGMENT 1649 messages received so far in the course of the indicated transfer. 1650 The sending node SHOULD transmit multiple XFER_SEGMENT messages 1651 without waiting for the corresponding XFER_ACK responses. This 1652 enables pipelining of messages on a transfer stream. 1654 For example, suppose the sending node transmits four segments of 1655 bundle data with lengths 100, 200, 500, and 1000, respectively. 1656 After receiving the first segment, the node sends an acknowledgment 1657 of length 100. After the second segment is received, the node sends 1658 an acknowledgment of length 300. The third and fourth 1659 acknowledgments are of length 800 and 1800, respectively. 1661 5.2.4. Transfer Refusal (XFER_REFUSE) 1663 The TCPCL supports a mechanism by which a receiving node can indicate 1664 to the sender that it does not want to receive the corresponding 1665 bundle. To do so, upon receiving an XFER_SEGMENT message, the node 1666 MAY transmit a XFER_REFUSE message. As data segments and 1667 acknowledgments MAY cross on the wire, the bundle that is being 1668 refused SHALL be identified by the Transfer ID of the refusal. 1670 There is no required relation between the Transfer MRU of a TCPCL 1671 node (which is supposed to represent a firm limitation of what the 1672 node will accept) and sending of a XFER_REFUSE message. A 1673 XFER_REFUSE can be used in cases where the agent's bundle storage is 1674 temporarily depleted or somehow constrained. A XFER_REFUSE can also 1675 be used after the bundle header or any bundle data is inspected by an 1676 agent and determined to be unacceptable. 1678 A receiver MAY send an XFER_REFUSE message as soon as it receives any 1679 XFER_SEGMENT message. The sender MUST be prepared for this and MUST 1680 associate the refusal with the correct bundle via the Transfer ID 1681 fields. 1683 The format of the XFER_REFUSE message is as follows in Figure 24. 1685 +-----------------------------+ 1686 | Message Header | 1687 +-----------------------------+ 1688 | Reason Code (U8) | 1689 +-----------------------------+ 1690 | Transfer ID (U64) | 1691 +-----------------------------+ 1693 Figure 24: Format of XFER_REFUSE Messages 1695 The fields of the XFER_REFUSE message are: 1697 Reason Code: A one-octet refusal reason code interpreted according 1698 to the descriptions in Table 6. 1700 Transfer ID: A 64-bit unsigned integer identifying the transfer 1701 being refused. 1703 +------------+------+-----------------------------------------------+ 1704 | Name | Code | Description | 1705 +------------+------+-----------------------------------------------+ 1706 | Unknown | 0x00 | Reason for refusal is unknown or not | 1707 | | | specified. | 1708 | | | | 1709 | Extension | 0x01 | A failure processing the Transfer Extension | 1710 | Failure | | Items ha occurred. | 1711 | | | | 1712 | Completed | 0x02 | The receiver already has the complete bundle. | 1713 | | | The sender MAY consider the bundle as | 1714 | | | completely received. | 1715 | | | | 1716 | No | 0x03 | The receiver's resources are exhausted. The | 1717 | Resources | | sender SHOULD apply reactive bundle | 1718 | | | fragmentation before retrying. | 1719 | | | | 1720 | Retransmit | 0x04 | The receiver has encountered a problem that | 1721 | | | requires the bundle to be retransmitted in | 1722 | | | its entirety. | 1723 +------------+------+-----------------------------------------------+ 1725 Table 6: XFER_REFUSE Reason Codes 1727 The receiver MUST, for each transfer preceding the one to be refused, 1728 have either acknowledged all XFER_SEGMENTs or refused the bundle 1729 transfer. 1731 The bundle transfer refusal MAY be sent before an entire data segment 1732 is received. If a sender receives a XFER_REFUSE message, the sender 1733 MUST complete the transmission of any partially sent XFER_SEGMENT 1734 message. There is no way to interrupt an individual TCPCL message 1735 partway through sending it. The sender MUST NOT commence 1736 transmission of any further segments of the refused bundle 1737 subsequently. Note, however, that this requirement does not ensure 1738 that an entity will not receive another XFER_SEGMENT for the same 1739 bundle after transmitting a XFER_REFUSE message since messages MAY 1740 cross on the wire; if this happens, subsequent segments of the bundle 1741 SHALL also be refused with a XFER_REFUSE message. 1743 Note: If a bundle transmission is aborted in this way, the receiver 1744 MAY not receive a segment with the 'END' flag set to 1 for the 1745 aborted bundle. The beginning of the next bundle is identified by 1746 the 'START' flag set to 1, indicating the start of a new transfer, 1747 and with a distinct Transfer ID value. 1749 5.2.5. Transfer Extension Items 1751 Each of the Transfer Extension Items SHALL be encoded in an identical 1752 Type-Length-Value (TLV) container form as indicated in Figure 25. 1754 The fields of the Transfer Extension Item are: 1756 Flags: A one-octet field containing generic bit flags about the 1757 Item, which are listed in Table 7. All reserved header flag bits 1758 SHALL be set to 0 by the sender. All reserved header flag bits 1759 SHALL be ignored by the receiver. If a TCPCL node receives a 1760 Transfer Extension Item with an unknown Item Type and the CRITICAL 1761 flag is 1, the node SHALL refuse the transfer with an XFER_REFUSE 1762 reason code of "Extension Failure". If the CRITICAL flag is 0, an 1763 entity SHALL skip over and ignore any item with an unknown Item 1764 Type. 1766 Item Type: A 16-bit unsigned integer field containing the type of 1767 the extension item. This specification allocates an IANA registry 1768 for such codes (see Section 9.4). 1770 Item Length: A 16-bit unsigned integer field containing the number 1771 of Item Value octets to follow. 1773 Item Value: A variable-length data field which is interpreted 1774 according to the associated Item Type. This specification places 1775 no restrictions on an extension's use of available Item Value 1776 data. Extension specifications SHOULD avoid the use of large data 1777 lengths, as the associated transfer cannot begin until the full 1778 extension data is sent. 1780 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1781 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 1782 +---------------+---------------+---------------+---------------+ 1783 | Item Flags | Item Type | Item Length...| 1784 +---------------+---------------+---------------+---------------+ 1785 | length contd. | Item Value... | 1786 +---------------+---------------+---------------+---------------+ 1788 Figure 25: Transfer Extension Item Format 1790 +----------+--------+-----------------------------------------------+ 1791 | Name | Code | Description | 1792 +----------+--------+-----------------------------------------------+ 1793 | CRITICAL | 0x01 | If bit is set, indicates that the receiving | 1794 | | | peer must handle the extension item. | 1795 | | | | 1796 | Reserved | others | 1797 +----------+--------+-----------------------------------------------+ 1799 Table 7: Transfer Extension Item Flags 1801 5.2.5.1. Transfer Length Extension 1803 The purpose of the Transfer Length extension is to allow entities to 1804 preemptively refuse bundles that would exceed their resources or to 1805 prepare storage on the receiving node for the upcoming bundle data. 1807 Multiple Transfer Length extension items SHALL NOT occur within the 1808 same transfer. The lack of a Transfer Length extension item in any 1809 transfer SHALL NOT imply anything about the potential length of the 1810 transfer. The Transfer Length extension SHALL be assigned transfer 1811 extension type ID 0x0001. 1813 If a transfer occupies exactly one segment (i.e. both START and END 1814 flags are 1) the Transfer Length extension SHOULD NOT be present. 1815 The extension does not provide any additional information for single- 1816 segment transfers. 1818 The format of the Transfer Length data is as follows in Figure 26. 1820 +----------------------+ 1821 | Total Length (U64) | 1822 +----------------------+ 1824 Figure 26: Format of Transfer Length data 1826 The fields of the Transfer Length extension are: 1828 Total Length: A 64-bit unsigned integer indicating the size of the 1829 data-to-be-transferred. The Total Length field SHALL be treated 1830 as authoritative by the receiver. If, for whatever reason, the 1831 actual total length of bundle data received differs from the value 1832 indicated by the Total Length value, the receiver SHALL treat the 1833 transmitted data as invalid. 1835 6. Session Termination 1837 This section describes the procedures for ending a TCPCL session. 1839 6.1. Session Termination Message (SESS_TERM) 1841 To cleanly shut down a session, a SESS_TERM message SHALL be 1842 transmitted by either node at any point following complete 1843 transmission of any other message. When sent to initiate a 1844 termination, the REPLY flag of a SESS_TERM message SHALL be 0. Upon 1845 receiving a SESS_TERM message after not sending a SESS_TERM message 1846 in the same session, an entity SHALL send an acknowledging SESS_TERM 1847 message. When sent to acknowledge a termination, a SESS_TERM message 1848 SHALL have identical data content from the message being acknowledged 1849 except for the REPLY flag, which is set to 1 to indicate 1850 acknowledgement. 1852 After sending a SESS_TERM message, an entity MAY continue a possible 1853 in-progress transfer in either direction. After sending a SESS_TERM 1854 message, an entity SHALL NOT begin any new outgoing transfer for the 1855 remainder of the session. After receving a SESS_TERM message, an 1856 entity SHALL NOT accept any new incoming transfer for the remainder 1857 of the session. 1859 Instead of following a clean shutdown sequence, after transmitting a 1860 SESS_TERM message an entity MAY immediately close the associated TCP 1861 connection. When performing an unclean shutdown, a receiving node 1862 SHOULD acknowledge all received data segments before closing the TCP 1863 connection. Not acknowledging received segments can result in 1864 unnecessary retransmission. When performing an unclean shutodwn, a 1865 transmitting node SHALL treat either sending or receiving a SESS_TERM 1866 message (i.e. before the final acknowledgment) as a failure of the 1867 transfer. Any delay between request to close the TCP connection and 1868 actual closing of the connection (a "half-closed" state) MAY be 1869 ignored by the TCPCL node. 1871 The format of the SESS_TERM message is as follows in Figure 27. 1873 +-----------------------------+ 1874 | Message Header | 1875 +-----------------------------+ 1876 | Message Flags (U8) | 1877 +-----------------------------+ 1878 | Reason Code (U8) | 1879 +-----------------------------+ 1881 Figure 27: Format of SESS_TERM Messages 1883 The fields of the SESS_TERM message are: 1885 Message Flags: A one-octet field of single-bit flags, interpreted 1886 according to the descriptions in Table 8. All reserved header 1887 flag bits SHALL be set to 0 by the sender. All reserved header 1888 flag bits SHALL be ignored by the receiver. 1890 Reason Code: A one-octet refusal reason code interpreted according 1891 to the descriptions in Table 9. 1893 +----------+--------+-----------------------------------------------+ 1894 | Name | Code | Description | 1895 +----------+--------+-----------------------------------------------+ 1896 | REPLY | 0x01 | If bit is set, indicates that this message is | 1897 | | | an acknowledgement of an earlier SESS_TERM | 1898 | | | message. | 1899 | | | | 1900 | Reserved | others | 1901 +----------+--------+-----------------------------------------------+ 1903 Table 8: SESS_TERM Flags 1905 +--------------+------+---------------------------------------------+ 1906 | Name | Code | Description | 1907 +--------------+------+---------------------------------------------+ 1908 | Unknown | 0x00 | A termination reason is not available. | 1909 | | | | 1910 | Idle timeout | 0x01 | The session is being closed due to | 1911 | | | idleness. | 1912 | | | | 1913 | Version | 0x02 | The node cannot conform to the specified | 1914 | mismatch | | TCPCL protocol version. | 1915 | | | | 1916 | Busy | 0x03 | The node is too busy to handle the current | 1917 | | | session. | 1918 | | | | 1919 | Contact | 0x04 | The node cannot interpret or negotiate | 1920 | Failure | | contact header option. | 1921 | | | | 1922 | Resource | 0x05 | The node has run into some resource limit | 1923 | Exhaustion | | and cannot continue the session. | 1924 +--------------+------+---------------------------------------------+ 1926 Table 9: SESS_TERM Reason Codes 1928 A session shutdown MAY occur immediately after transmission of a 1929 contact header (and prior to any further message transmit). This 1930 MAY, for example, be used to notify that the node is currently not 1931 able or willing to communicate. However, an entity MUST always send 1932 the contact header to its peer before sending a SESS_TERM message. 1934 If reception of the contact header itself somehow fails (e.g. an 1935 invalid "magic string" is recevied), an entity SHALL close the TCP 1936 connection without sending a SESS_TERM message. If the content of 1937 the Session Extension Items data disagrees with the Session Extension 1938 Length (i.e. the last Item claims to use more octets than are present 1939 in the Session Extension Length), the reception of the contact header 1940 is considered to have failed. 1942 If a session is to be terminated before a protocol message has 1943 completed being sent, then the node MUST NOT transmit the SESS_TERM 1944 message but still SHALL close the TCP connection. Each TCPCL message 1945 is contiguous in the octet stream and has no ability to be cut short 1946 and/or preempted by an other message. This is particularly important 1947 when large segment sizes are being transmitted; either entire 1948 XFER_SEGMENT is sent before a SESS_TERM message or the connection is 1949 simply terminated mid-XFER_SEGMENT. 1951 6.2. Idle Session Shutdown 1953 The protocol includes a provision for clean shutdown of idle 1954 sessions. Determining the length of time to wait before ending idle 1955 sessions, if they are to be closed at all, is an implementation and 1956 configuration matter. 1958 If there is a configured time to close idle links and if no TCPCL 1959 messages (other than KEEPALIVE messages) has been received for at 1960 least that amount of time, then either node MAY terminate the session 1961 by transmitting a SESS_TERM message indicating the reason code of 1962 "Idle timeout" (as described in Table 9). 1964 7. Implementation Status 1966 [NOTE to the RFC Editor: please remove this section before 1967 publication, as well as the reference to [RFC7942] and 1968 [github-dtn-bpbis-tcpcl].] 1970 This section records the status of known implementations of the 1971 protocol defined by this specification at the time of posting of this 1972 Internet-Draft, and is based on a proposal described in [RFC7942]. 1973 The description of implementations in this section is intended to 1974 assist the IETF in its decision processes in progressing drafts to 1975 RFCs. Please note that the listing of any individual implementation 1976 here does not imply endorsement by the IETF. Furthermore, no effort 1977 has been spent to verify the information presented here that was 1978 supplied by IETF contributors. This is not intended as, and must not 1979 be construed to be, a catalog of available implementations or their 1980 features. Readers are advised to note that other implementations can 1981 exist. 1983 An example implementation of the this draft of TCPCLv4 has been 1984 created as a GitHub project [github-dtn-bpbis-tcpcl] and is intented 1985 to use as a proof-of-concept and as a possible source of 1986 interoperability testing. This example implementation uses D-Bus as 1987 the CL-BP Agent interface, so it only runs on hosts which provide the 1988 Python "dbus" library. 1990 8. Security Considerations 1992 TCPCL can be used to provide point-to-point transport security, but 1993 does not provide security of data-at-rest and does not guarantee end- 1994 to-end bundle security. The bundle security mechanisms defined in 1995 [I-D.ietf-dtn-bpsec] are to be used instead. 1997 When negotating whether to use TLS security as part of the contact 1998 header exchange, it is possible for a man-in-the-middle attacker to 1999 set the CAN_TLS flag to 0 on either side of the exchange. This leads 2000 to the "SSL Stripping" attack described in [RFC7457]. If TLS is 2001 desired for use on any TCPCL network, it is strongly encouraged that 2002 the security policy disallow use of TCPCL when "Enable TLS" is 2003 negotiated to false. This requires that the TLS handshake occurs, 2004 regardless of the policy-driven parameters of the handshake and 2005 policy-driven handling of the handshake outcome. 2007 Even when using TLS to secure the TCPCL session, the actual 2008 ciphersuite negotiated between the TLS peers MAY be insecure. TLS 2009 can be used to perform authentication without data confidentiality, 2010 for example. It is up to security policies within each TCPCL node to 2011 ensure that the negotiated TLS ciphersuite meets transport security 2012 requirements. This is identical behavior to STARTTLS use in 2013 [RFC2595]. 2015 The certificates exchanged by TLS enable authentication of peer host 2016 name and Node ID, but it is possible that a peer either not provide a 2017 valid certificate or that the certificate does not validate either 2018 the host name or Node ID of the peer. Having a CA-validated 2019 certificate does not alone guarantee the identity of the network host 2020 or BP node from which the certificate is provided; additional 2021 validation procedures bind the host name or node ID based on the 2022 contents of the certificate. The host name validation is a weaker 2023 form of authentication, because even if a peer is operating on an 2024 authenticated network host name it can provide an invalid Node ID and 2025 cause bundles to be "leaked" to an invalid node. Especially in DTN 2026 environments, network names and addresses of nodes can be time- 2027 variable so binding a certificate to a Node ID is a more stable 2028 identity. Node ID validation ensures that the peer to which a bundle 2029 is transferred is in fact the node which the BP Agent expects it to 2030 be. It is a reasonable policy to skip host name validation if 2031 certificates can be guaranteed to validate the peer's Node ID. In 2032 circumstances where certificates can only be issued to network host 2033 names, Node ID validation is not possible but it could be reasonable 2034 to assume that a trusted host is not going to present an invalid Node 2035 ID. Trusting an authenticated host name can be feasable on a network 2036 secured by a private CA but is not advisable on the Internet when 2037 using a variety of public CAs. 2039 Another consideration for this protocol relates to denial-of-service 2040 attacks. An entity MAY send a large amount of data over a TCPCL 2041 session, requiring the receiving entity to handle the data, attempt 2042 to stop the flood of data by sending a XFER_REFUSE message, or 2043 forcibly terminate the session. This burden could cause denial of 2044 service on other, well-behaving sessions. There is also nothing to 2045 prevent a malicious entity from continually establishing sessions and 2046 repeatedly trying to send copious amounts of bundle data. A 2047 listening entity MAY take countermeasures such as ignoring TCP SYN 2048 messages, closing TCP connections as soon as they are established, 2049 waiting before sending the contact header, sending a SESS_TERM 2050 message quickly or with a delay, etc. 2052 9. IANA Considerations 2054 Registration procedures referred to in this section are defined in 2055 [RFC8126]. 2057 Some of the registries have been defined as version specific to 2058 TCPCLv4, and imports some or all codepoints from TCPCLv3. This was 2059 done to disambiguate the use of these codepoints between TCPCLv3 and 2060 TCPCLv4 while preserving the semantics of some of the codepoints. 2062 9.1. Port Number 2064 Port number 4556 has been previously assigned as the default port for 2065 the TCP convergence layer in [RFC7242]. This assignment is unchanged 2066 by protocol version 4. Each TCPCL entity identifies its TCPCL 2067 protocol version in its initial contact (see Section 9.2), so there 2068 is no ambiguity about what protocol is being used. 2070 +------------------------+-------------------------------------+ 2071 | Parameter | Value | 2072 +------------------------+-------------------------------------+ 2073 | Service Name: | dtn-bundle | 2074 | | | 2075 | Transport Protocol(s): | TCP | 2076 | | | 2077 | Assignee: | Simon Perreault | 2078 | | | 2079 | Contact: | Simon Perreault | 2080 | | | 2081 | Description: | DTN Bundle TCP CL Protocol | 2082 | | | 2083 | Reference: | [RFC7242] | 2084 | | | 2085 | Port Number: | 4556 | 2086 +------------------------+-------------------------------------+ 2088 9.2. Protocol Versions 2090 IANA has created, under the "Bundle Protocol" registry, a sub- 2091 registry titled "Bundle Protocol TCP Convergence-Layer Version 2092 Numbers" and initialize it with the following table. The 2093 registration procedure is RFC Required. 2095 +-------+-------------+---------------------+ 2096 | Value | Description | Reference | 2097 +-------+-------------+---------------------+ 2098 | 0 | Reserved | [RFC7242] | 2099 | | | | 2100 | 1 | Reserved | [RFC7242] | 2101 | | | | 2102 | 2 | Reserved | [RFC7242] | 2103 | | | | 2104 | 3 | TCPCL | [RFC7242] | 2105 | | | | 2106 | 4 | TCPCLv4 | This specification. | 2107 | | | | 2108 | 5-255 | Unassigned | 2109 +-------+-------------+---------------------+ 2111 9.3. Session Extension Types 2113 EDITOR NOTE: sub-registry to-be-created upon publication of this 2114 specification. 2116 IANA will create, under the "Bundle Protocol" registry, a sub- 2117 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 2118 Session Extension Types" and initialize it with the contents of 2119 Table 10. The registration procedure is Expert Review within the 2120 lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are 2121 reserved for use on private networks for functions not published to 2122 the IANA. 2124 Specifications of new session extension types need to define the 2125 encoding of the Item Value data as well as any meaning or restriction 2126 on the number of or order of instances of the type within an 2127 extension item list. Specifications need to define how the extension 2128 functions when no instance of the new extension type is received 2129 during session negotiation. 2131 Expert(s) are encouraged to be biased towards approving registrations 2132 unless they are abusive, frivolous, or actively harmful (not merely 2133 aesthetically displeasing, or architecturally dubious). 2135 +----------------+--------------------------+ 2136 | Code | Session Extension Type | 2137 +----------------+--------------------------+ 2138 | 0x0000 | Reserved | 2139 | | | 2140 | 0x0001--0x7FFF | Unassigned | 2141 | | | 2142 | 0x8000--0xFFFF | Private/Experimental Use | 2143 +----------------+--------------------------+ 2145 Table 10: Session Extension Type Codes 2147 9.4. Transfer Extension Types 2149 EDITOR NOTE: sub-registry to-be-created upon publication of this 2150 specification. 2152 IANA will create, under the "Bundle Protocol" registry, a sub- 2153 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 2154 Transfer Extension Types" and initialize it with the contents of 2155 Table 11. The registration procedure is Expert Review within the 2156 lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are 2157 reserved for use on private networks for functions not published to 2158 the IANA. 2160 Specifications of new transfer extension types need to define the 2161 encoding of the Item Value data as well as any meaning or restriction 2162 on the number of or order of instances of the type within an 2163 extension item list. Specifications need to define how the extension 2164 functions when no instance of the new extension type is received in a 2165 transfer. 2167 Expert(s) are encouraged to be biased towards approving registrations 2168 unless they are abusive, frivolous, or actively harmful (not merely 2169 aesthetically displeasing, or architecturally dubious). 2171 +----------------+---------------------------+ 2172 | Code | Transfer Extension Type | 2173 +----------------+---------------------------+ 2174 | 0x0000 | Reserved | 2175 | | | 2176 | 0x0001 | Transfer Length Extension | 2177 | | | 2178 | 0x0002--0x7FFF | Unassigned | 2179 | | | 2180 | 0x8000--0xFFFF | Private/Experimental Use | 2181 +----------------+---------------------------+ 2183 Table 11: Transfer Extension Type Codes 2185 9.5. Message Types 2187 EDITOR NOTE: sub-registry to-be-created upon publication of this 2188 specification. 2190 IANA will create, under the "Bundle Protocol" registry, a sub- 2191 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 2192 Message Types" and initialize it with the contents of Table 12. The 2193 registration procedure is RFC Required within the lower range 0x01-- 2194 0xEF. Values in the range 0xF0--0xFF are reserved for use on private 2195 networks for functions not published to the IANA. 2197 Specifications of new message types need to define the encoding of 2198 the message data as well as the purpose and relationship of the new 2199 message to existing session/transfer state within the baseline 2200 message sequencing. 2202 Expert(s) are encouraged to favor new session/transfer extension 2203 types over new message types. TCPCL messages are not self- 2204 delimiting, so care must be taken in introducing new message types. 2205 If an entity receives an unknown message type the only thing that can 2206 be done is to send a MSG_REJECT and close the TCP connection; not 2207 even a clean termination can be done at that point. 2209 +------------+--------------------------+ 2210 | Code | Message Type | 2211 +------------+--------------------------+ 2212 | 0x00 | Reserved | 2213 | | | 2214 | 0x01 | XFER_SEGMENT | 2215 | | | 2216 | 0x02 | XFER_ACK | 2217 | | | 2218 | 0x03 | XFER_REFUSE | 2219 | | | 2220 | 0x04 | KEEPALIVE | 2221 | | | 2222 | 0x05 | SESS_TERM | 2223 | | | 2224 | 0x06 | MSG_REJECT | 2225 | | | 2226 | 0x07 | SESS_INIT | 2227 | | | 2228 | 0x08--0xEF | Unassigned | 2229 | | | 2230 | 0xF0--0xFF | Private/Experimental Use | 2231 +------------+--------------------------+ 2233 Table 12: Message Type Codes 2235 9.6. XFER_REFUSE Reason Codes 2237 EDITOR NOTE: sub-registry to-be-created upon publication of this 2238 specification. 2240 IANA will create, under the "Bundle Protocol" registry, a sub- 2241 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 2242 XFER_REFUSE Reason Codes" and initialize it with the contents of 2243 Table 13. The registration procedure is Specification Required 2244 within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF 2245 are reserved for use on private networks for functions not published 2246 to the IANA. 2248 Specifications of new XFER_REFUSE reason codes need to define the 2249 meaning of the reason and disambiguate it with pre-exisiting reasons. 2250 Each refusal reason needs to be usable by the receving BP Agent to 2251 make retransmission or re-routing decisions. 2253 Expert(s) are encouraged to be biased towards approving registrations 2254 unless they are abusive, frivolous, or actively harmful (not merely 2255 aesthetically displeasing, or architecturally dubious). 2257 +------------+--------------------------+ 2258 | Code | Refusal Reason | 2259 +------------+--------------------------+ 2260 | 0x00 | Unknown | 2261 | | | 2262 | 0x01 | Extension Failure | 2263 | | | 2264 | 0x02 | Completed | 2265 | | | 2266 | 0x03 | No Resources | 2267 | | | 2268 | 0x04 | Retransmit | 2269 | | | 2270 | 0x05--0xEF | Unassigned | 2271 | | | 2272 | 0xF0--0xFF | Private/Experimental Use | 2273 +------------+--------------------------+ 2275 Table 13: XFER_REFUSE Reason Codes 2277 9.7. SESS_TERM Reason Codes 2279 EDITOR NOTE: sub-registry to-be-created upon publication of this 2280 specification. 2282 IANA will create, under the "Bundle Protocol" registry, a sub- 2283 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 2284 SESS_TERM Reason Codes" and initialize it with the contents of 2285 Table 14. The registration procedure is Specification Required 2286 within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF 2287 are reserved for use on private networks for functions not published 2288 to the IANA. 2290 Specifications of new SESS_TERM reason codes need to define the 2291 meaning of the reason and disambiguate it with pre-exisiting reasons. 2292 Each termination reason needs to be usable by the receving BP Agent 2293 to make re-connection decisions. 2295 Expert(s) are encouraged to be biased towards approving registrations 2296 unless they are abusive, frivolous, or actively harmful (not merely 2297 aesthetically displeasing, or architecturally dubious). 2299 +------------+--------------------------+ 2300 | Code | Termination Reason | 2301 +------------+--------------------------+ 2302 | 0x00 | Unknown | 2303 | | | 2304 | 0x01 | Idle timeout | 2305 | | | 2306 | 0x02 | Version mismatch | 2307 | | | 2308 | 0x03 | Busy | 2309 | | | 2310 | 0x04 | Contact Failure | 2311 | | | 2312 | 0x05 | Resource Exhaustion | 2313 | | | 2314 | 0x06--0xEF | Unassigned | 2315 | | | 2316 | 0xF0--0xFF | Private/Experimental Use | 2317 +------------+--------------------------+ 2319 Table 14: SESS_TERM Reason Codes 2321 9.8. MSG_REJECT Reason Codes 2323 EDITOR NOTE: sub-registry to-be-created upon publication of this 2324 specification. 2326 IANA will create, under the "Bundle Protocol" registry, a sub- 2327 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 2328 MSG_REJECT Reason Codes" and initialize it with the contents of 2329 Table 15. The registration procedure is Specification Required 2330 within the lower range 0x01--0xEF. Values in the range 0xF0--0xFF 2331 are reserved for use on private networks for functions not published 2332 to the IANA. 2334 Specifications of new MSG_REJECT reason codes need to define the 2335 meaning of the reason and disambiguate it with pre-exisiting reasons. 2336 Each rejection reason needs to be usable by the receving TCPCL Entity 2337 to make message sequencing and/or session termination decisions. 2339 Expert(s) are encouraged to be biased towards approving registrations 2340 unless they are abusive, frivolous, or actively harmful (not merely 2341 aesthetically displeasing, or architecturally dubious). 2343 +------------+--------------------------+ 2344 | Code | Rejection Reason | 2345 +------------+--------------------------+ 2346 | 0x00 | reserved | 2347 | | | 2348 | 0x01 | Message Type Unknown | 2349 | | | 2350 | 0x02 | Message Unsupported | 2351 | | | 2352 | 0x03 | Message Unexpected | 2353 | | | 2354 | 0x04--0xEF | Unassigned | 2355 | | | 2356 | 0xF0--0xFF | Private/Experimental Use | 2357 +------------+--------------------------+ 2359 Table 15: MSG_REJECT Reason Codes 2361 10. Acknowledgments 2363 This specification is based on comments on implementation of 2364 [RFC7242] provided from Scott Burleigh. 2366 11. References 2368 11.1. Normative References 2370 [I-D.ietf-dtn-bpbis] 2371 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 2372 Version 7", draft-ietf-dtn-bpbis-14 (work in progress), 2373 August 2019. 2375 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2376 RFC 793, DOI 10.17487/RFC0793, September 1981, 2377 . 2379 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2380 Communication Layers", STD 3, RFC 1122, 2381 DOI 10.17487/RFC1122, October 1989, 2382 . 2384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2385 Requirement Levels", BCP 14, RFC 2119, 2386 DOI 10.17487/RFC2119, March 1997, 2387 . 2389 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2390 Resource Identifier (URI): Generic Syntax", STD 66, 2391 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2392 . 2394 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2395 (TLS) Protocol Version 1.2", RFC 5246, 2396 DOI 10.17487/RFC5246, August 2008, 2397 . 2399 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2400 Housley, R., and W. Polk, "Internet X.509 Public Key 2401 Infrastructure Certificate and Certificate Revocation List 2402 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2403 . 2405 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 2406 Extensions: Extension Definitions", RFC 6066, 2407 DOI 10.17487/RFC6066, January 2011, 2408 . 2410 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2411 Verification of Domain-Based Application Service Identity 2412 within Internet Public Key Infrastructure Using X.509 2413 (PKIX) Certificates in the Context of Transport Layer 2414 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2415 2011, . 2417 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2418 "Recommendations for Secure Use of Transport Layer 2419 Security (TLS) and Datagram Transport Layer Security 2420 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2421 2015, . 2423 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2424 Writing an IANA Considerations Section in RFCs", BCP 26, 2425 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2426 . 2428 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2429 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2430 May 2017, . 2432 11.2. Informative References 2434 [github-dtn-bpbis-tcpcl] 2435 Sipos, B., "TCPCL Example Implementation", 2436 . 2439 [I-D.ietf-dtn-bpsec] 2440 Birrane, E. and K. McKeever, "Bundle Protocol Security 2441 Specification", draft-ietf-dtn-bpsec-12 (work in 2442 progress), September 2019. 2444 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 2445 RFC 2595, DOI 10.17487/RFC2595, June 1999, 2446 . 2448 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 2449 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 2450 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 2451 April 2007, . 2453 [RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant 2454 Networking TCP Convergence-Layer Protocol", RFC 7242, 2455 DOI 10.17487/RFC7242, June 2014, 2456 . 2458 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 2459 Known Attacks on Transport Layer Security (TLS) and 2460 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 2461 February 2015, . 2463 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2464 Code: The Implementation Status Section", BCP 205, 2465 RFC 7942, DOI 10.17487/RFC7942, July 2016, 2466 . 2468 Appendix A. Significant changes from RFC7242 2470 The areas in which changes from [RFC7242] have been made to existing 2471 headers and messages are: 2473 o Split contact header into pre-TLS protocol negotiation and 2474 SESS_INIT parameter negotiation. The contact header is now fixed- 2475 length. 2477 o Changed contact header content to limit number of negotiated 2478 options. 2480 o Added session option to negotiate maximum segment size (per each 2481 direction). 2483 o Renamed "Endpoint ID" to "Node ID" to conform with BPv7 2484 terminology. 2486 o Added session extension capability. 2488 o Added transfer extension capability. Moved transfer total length 2489 into an extension item. 2491 o Defined new IANA registries for message / type / reason codes to 2492 allow renaming some codes for clarity. 2494 o Segments of all new IANA registries are reserved for private/ 2495 experimental use. 2497 o Expanded Message Header to octet-aligned fields instead of bit- 2498 packing. 2500 o Added a bundle transfer identification number to all bundle- 2501 related messages (XFER_SEGMENT, XFER_ACK, XFER_REFUSE). 2503 o Use flags in XFER_ACK to mirror flags from XFER_SEGMENT. 2505 o Removed all uses of SDNV fields and replaced with fixed-bit-length 2506 fields. 2508 o Renamed SHUTDOWN to SESS_TERM to deconflict term "shutdown" 2509 related to TCP connections. 2511 o Removed the notion of a re-connection delay parameter. 2513 The areas in which extensions from [RFC7242] have been made as new 2514 messages and codes are: 2516 o Added contact negotiation failure SESS_TERM reason code. 2518 o Added MSG_REJECT message to indicate an unknown or unhandled 2519 message was received. 2521 o Added TLS session security mechanism. 2523 o Added Resource Exhaustion SESS_TERM reason code. 2525 Authors' Addresses 2526 Brian Sipos 2527 RKF Engineering Solutions, LLC 2528 7500 Old Georgetown Road 2529 Suite 1275 2530 Bethesda, MD 20814-6198 2531 United States of America 2533 Email: BSipos@rkf-eng.com 2535 Michael Demmer 2536 University of California, Berkeley 2537 Computer Science Division 2538 445 Soda Hall 2539 Berkeley, CA 94720-1776 2540 United States of America 2542 Email: demmer@cs.berkeley.edu 2544 Joerg Ott 2545 Aalto University 2546 Department of Communications and Networking 2547 PO Box 13000 2548 Aalto 02015 2549 Finland 2551 Email: ott@in.tum.de 2553 Simon Perreault 2554 Quebec, QC 2555 Canada 2557 Email: simon@per.reau.lt