idnits 2.17.1 draft-ietf-dtn-tcpclv4-15.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 (October 16, 2019) is 1653 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: April 18, 2020 J. Ott 7 Aalto University 8 S. Perreault 9 October 16, 2019 11 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 12 draft-ietf-dtn-tcpclv4-15 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 April 18, 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 . . . . . . . . . . . . . . . 27 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. Within each TLS handshake, the following requirements 1037 apply (using the rough order in which they occur): 1039 Client Hello: When a resolved host name was used to establish the 1040 TCP connection, the TLS ClientHello SHOULD include a Server Name 1041 Indication (SNI) from the active peer in accordance with 1042 [RFC6066]. When present, the SNI SHALL contain the same host name 1043 used to establish the TCP connection. 1045 Server Certificate: The passive peer SHOULD supply a certificate 1046 within the TLS handshake to allow authentication of its side of 1047 the session. When assigned a stable host name or address, the 1048 passive peer certificate SHOULD contain a subjectAltName entry 1049 which authenticates that host name or address. The passive peer 1050 certificate SHOULD contain a subjectAltName entry of type 1051 uniformResourceIdentifier which authenticates the Node ID of the 1052 peer. The passive peer MAY use the SNI host name to choose an 1053 appropriate server-side certificate which authenticates that host 1054 name and corresponding Node ID. 1056 Certificate Request: During TLS handshake, the passive peer SHALL 1057 request a client-side certificate. 1059 Client Certificate: The active peer SHOULD supply a certificate 1060 chain within the TLS handshake to allow authentication of its side 1061 of the session. When assigned a stable host name or address, the 1062 active peer certificate SHOULD contain a subjectAltName entry 1063 which authenticates that host name or address. The active peer 1064 certificate SHOULD contain a subjectAltName entry of type 1065 uniformResourceIdentifier which authenticates the Node ID of the 1066 peer. 1068 All certificates supplied during TLS handshake SHALL conform with the 1069 profile of [RFC5280], or any updates or successors to that profile. 1070 When a certificate is supplied during TLS handshake, the full 1071 certification chain SHOULD be included unless security policy 1072 indicates that is unnecessary. 1074 If a TLS handshake cannot negotiate a TLS session, both entities of 1075 the TCPCL session SHALL close the TCP connection. At this point the 1076 TCPCL session has not yet been established so there is no TCPCL 1077 session to terminate. This also avoids any potential security issues 1078 assoicated with further TCP communication with an untrusted peer. 1080 After a TLS session is successfully established, the active peer 1081 SHALL send a SESS_INIT message to begin session negotiation. This 1082 session negotation and all subsequent messaging are secured. 1084 4.4.2. TLS Authentication 1086 Using X.509 certificates exchanged during the TLS handshake, each of 1087 the entities can attempt to authenticate its peer at the network 1088 layer (host name and address) and at the application layer (BP Node 1089 ID). The Node ID exchanged in the Session Initialization is likely 1090 to be used by the BP agent for making transfer and routing decisions, 1091 so attempting host name validation is optional while attempting Node 1092 ID validation is required. The logic for attempting validation is 1093 separate from the logic for handling the result of validation, which 1094 is based on local security policy. 1096 By using the SNI host name (see Section 4.4.1) a single passive 1097 entity can act as a convergence layer for multiple BP agents with 1098 distinct Node IDs. When this "virtual host" behavior is used, the 1099 host name is used as the indication of which BP Node the passive 1100 entity is attempting to communicate with. A virtual host CL entity 1101 can be authenticated by a certificate containing all of the host 1102 names and/or Node IDs being hosted or by several certificates each 1103 authenticating a single host name and/or Node ID. 1105 Any certificate received during TLS handshake SHALL be validated up 1106 to one or more trusted certificate authority (CA) certificates. If 1107 certificate validation fails or if security policy disallows a 1108 certificate for any reason, the entity SHOULD terminate the session 1109 (with a reason code of "Contact Failure"). 1111 Immediately after the TLS handshake, each side of the TCP connection 1112 SHOULD perform host name validation of its peer in accordance with 1113 [RFC6125] unless it is not needed by security policy. The active 1114 peer SHALL attempt to authenticate the host name (of the passive 1115 peer) used to initiate the TCP connection. The active peer MAY 1116 attempt to authenticate the IP address of the other side of the TCP 1117 connection. The passive peer SHALL attempt to authenticate the IP 1118 address of the other side of the TCP connection. The passive peer 1119 MAY use the IP address to resolve one or more host names of the 1120 active peer and attempt to authenticate those. If host name 1121 validation fails (including failure because the certificate does not 1122 contain any DNS-ID), the entity SHOULD terminate the session (with a 1123 reason code of "Contact Failure") unless security policy allows an 1124 unauthticated host. 1126 Immediately before Session Parameter Negotiation, each side of the 1127 session SHALL perform Node ID validation of its peer as described 1128 below. Node ID validation SHALL succeed if the associated 1129 certificate contains a subjectAltName entry of type 1130 uniformResourceIdentifier whose value matches the Node ID of the 1131 TCPCL entity. Unless specified otherwise by the definition of the 1132 URI scheme being authenticated, URI matching of Node IDs SHALL use 1133 the URI comparison logic of [RFC3986] and scheme-based normalization 1134 of those schemes specified in [I-D.ietf-dtn-bpbis]. This is similar 1135 to the URI-ID of [RFC6125] but does not require any structure to the 1136 scheme-specific-part of the URI. A URI scheme can refine this "exact 1137 match" logic with rules about how Node IDs within that scheme are to 1138 be compared with the certificate-authenticated URI. If Node ID 1139 validation fails (including failure because the certificate does not 1140 contain any subjectAltName URI), the entity SHOULD terminate the 1141 session (with a reason code of "Contact Failure") unless security 1142 policy allows an unauthticated node. 1144 4.4.3. Example TLS Initiation 1146 A summary of a typical TLS use is shown in the sequence in Figure 17 1147 below. 1149 Entity A Entity B 1150 active peer passive peer 1152 +-------------------------+ 1153 | Open TCP Connnection | -> 1154 +-------------------------+ +-------------------------+ 1155 <- | Accept Connection | 1156 +-------------------------+ 1158 +-------------------------+ 1159 | Contact Header | -> 1160 +-------------------------+ +-------------------------+ 1161 <- | Contact Header | 1162 +-------------------------+ 1164 +-------------------------+ +-------------------------+ 1165 | TLS Negotiation | -> <- | TLS Negotiation | 1166 | (as client) | | (as server) | 1167 +-------------------------+ +-------------------------+ 1169 Host name validation occurs. 1170 Secured TCPCL messaging can begin. 1172 +-------------------------+ +-------------------------+ 1173 | SESS_INIT | -> <- | SESS_INIT | 1174 +-------------------------+ +-------------------------+ 1176 Node ID validation occurs. 1177 Session is established, transfers can begin. 1179 +-------------------------+ +-------------------------+ 1180 | SESS_TERM | -> <- | SESS_TERM | 1181 +-------------------------+ +-------------------------+ 1183 Figure 17: A simple visual example of TCPCL TLS Establishment between 1184 two entities 1186 4.5. Message Header 1188 After the initial exchange of a contact header, all messages 1189 transmitted over the session are identified by a one-octet header 1190 with the following structure: 1192 0 1 2 3 4 5 6 7 1193 +---------------+ 1194 | Message Type | 1195 +---------------+ 1197 Figure 18: Format of the Message Header 1199 The message header fields are as follows: 1201 Message Type: Indicates the type of the message as per Table 2 1202 below. Encoded values are listed in Section 9.5. 1204 +--------------+------+---------------------------------------------+ 1205 | Name | Code | Description | 1206 +--------------+------+---------------------------------------------+ 1207 | SESS_INIT | 0x07 | Contains the session parameter inputs from | 1208 | | | one of the entities, as described in | 1209 | | | Section 4.6. | 1210 | | | | 1211 | SESS_TERM | 0x05 | Indicates that one of the entities | 1212 | | | participating in the session wishes to | 1213 | | | cleanly terminate the session, as described | 1214 | | | in Section 6. | 1215 | | | | 1216 | XFER_SEGMENT | 0x01 | Indicates the transmission of a segment of | 1217 | | | bundle data, as described in Section 5.2.2. | 1218 | | | | 1219 | XFER_ACK | 0x02 | Acknowledges reception of a data segment, | 1220 | | | as described in Section 5.2.3. | 1221 | | | | 1222 | XFER_REFUSE | 0x03 | Indicates that the transmission of the | 1223 | | | current bundle SHALL be stopped, as | 1224 | | | described in Section 5.2.4. | 1225 | | | | 1226 | KEEPALIVE | 0x04 | Used to keep TCPCL session active, as | 1227 | | | described in Section 5.1.1. | 1228 | | | | 1229 | MSG_REJECT | 0x06 | Contains a TCPCL message rejection, as | 1230 | | | described in Section 5.1.2. | 1231 +--------------+------+---------------------------------------------+ 1233 Table 2: TCPCL Message Types 1235 4.6. Session Initialization Message (SESS_INIT) 1237 Before a session is established and ready to transfer bundles, the 1238 session parameters are negotiated between the connected entities. 1239 The SESS_INIT message is used to convey the per-entity parameters 1240 which are used together to negotiate the per-session parameters as 1241 described in Section 4.7. 1243 The format of a SESS_INIT message is as follows in Figure 19. 1245 +-----------------------------+ 1246 | Message Header | 1247 +-----------------------------+ 1248 | Keepalive Interval (U16) | 1249 +-----------------------------+ 1250 | Segment MRU (U64) | 1251 +-----------------------------+ 1252 | Transfer MRU (U64) | 1253 +-----------------------------+ 1254 | Node ID Length (U16) | 1255 +-----------------------------+ 1256 | Node ID Data (variable) | 1257 +-----------------------------+ 1258 | Session Extension | 1259 | Items Length (U32) | 1260 +-----------------------------+ 1261 | Session Extension | 1262 | Items (var.) | 1263 +-----------------------------+ 1265 Figure 19: SESS_INIT Format 1267 The fields of the SESS_INIT message are: 1269 Keepalive Interval: A 16-bit unsigned integer indicating the 1270 interval, in seconds, between any subsequent messages being 1271 transmitted by the peer. The peer receiving this contact header 1272 uses this interval to determine how long to wait after any last- 1273 message transmission and a necessary subsequent KEEPALIVE message 1274 transmission. 1276 Segment MRU: A 64-bit unsigned integer indicating the largest 1277 allowable single-segment data payload size to be received in this 1278 session. Any XFER_SEGMENT sent to this peer SHALL have a data 1279 payload no longer than the peer's Segment MRU. The two entities 1280 of a single session MAY have different Segment MRUs, and no 1281 relation between the two is required. 1283 Transfer MRU: A 64-bit unsigned integer indicating the largest 1284 allowable total-bundle data size to be received in this session. 1285 Any bundle transfer sent to this peer SHALL have a Total Bundle 1286 Length payload no longer than the peer's Transfer MRU. This value 1287 can be used to perform proactive bundle fragmentation. The two 1288 entities of a single session MAY have different Transfer MRUs, and 1289 no relation between the two is required. 1291 Node ID Length and Node ID Data: Together these fields represent a 1292 variable-length text string. The Node ID Length is a 16-bit 1293 unsigned integer indicating the number of octets of Node ID Data 1294 to follow. A zero-length Node ID SHALL be used to indicate the 1295 lack of Node ID rather than a truly empty Node ID. This case 1296 allows an entity to avoid exposing Node ID information on an 1297 untrusted network. A non-zero-length Node ID Data SHALL contain 1298 the UTF-8 encoded Node ID of the Entity which sent the SESS_INIT 1299 message. Every Node ID SHALL be a URI consistent with the 1300 requirements of [RFC3986] and the URI schemes of 1301 [I-D.ietf-dtn-bpbis]. The Node ID itself can be authenticated as 1302 described in Section 4.4.2. 1304 Session Extension Length and Session Extension Items: Together these 1305 fields represent protocol extension data not defined by this 1306 specification. The Session Extension Length is the total number 1307 of octets to follow which are used to encode the Session Extension 1308 Item list. The encoding of each Session Extension Item is within 1309 a consistent data container as described in Section 4.8. The full 1310 set of Session Extension Items apply for the duration of the TCPCL 1311 session to follow. The order and mulitplicity of these Session 1312 Extension Items MAY be significant, as defined in the associated 1313 type specification(s). 1315 4.7. Session Parameter Negotiation 1317 An entity calculates the parameters for a TCPCL session by 1318 negotiating the values from its own preferences (conveyed by the 1319 contact header it sent to the peer) with the preferences of the peer 1320 node (expressed in the contact header that it received from the 1321 peer). The negotiated parameters defined by this specification are 1322 described in the following paragraphs. 1324 Transfer MTU and Segment MTU: The maximum transmit unit (MTU) for 1325 whole transfers and individual segments are idententical to the 1326 Transfer MRU and Segment MRU, respectively, of the recevied 1327 contact header. A transmitting peer can send individual segments 1328 with any size smaller than the Segment MTU, depending on local 1329 policy, dynamic network conditions, etc. Determining the size of 1330 each transmitted segment is an implementation matter. 1332 Session Keepalive: Negotiation of the Session Keepalive parameter is 1333 performed by taking the minimum of this two contact headers' 1334 Keepalive Interval. The Session Keepalive interval is a parameter 1335 for the behavior described in Section 5.1.1. 1337 Enable TLS: Negotiation of the Enable TLS parameter is performed by 1338 taking the logical AND of the two contact headers' CAN_TLS flags. 1339 A local security policy is then applied to determine of the 1340 negotated value of Enable TLS is acceptable. It can be a 1341 reasonable security policy to both require or disallow the use of 1342 TLS depending upon the desired network flows. Because this state 1343 is negotiated over an unsecured medium, there is a risk of a TLS 1344 Stripping as described in Section 8. If the Enable TLS state is 1345 unacceptable, the node SHALL terminate the session with a reason 1346 code of "Contact Failure". Note that this contact failure reason 1347 is different than a failure of TLS handshake or TLS authentication 1348 after an agreed-upon and acceptable Enable TLS state. If the 1349 negotiated Enable TLS value is true and acceptable then TLS 1350 negotiation feature (described in Section 4.4) begins immediately 1351 following the contact header exchange. 1353 Once this process of parameter negotiation is completed (which 1354 includes a possible completed TLS handshake of the connection to use 1355 TLS), this protocol defines no additional mechanism to change the 1356 parameters of an established session; to effect such a change, the 1357 TCPCL session MUST be terminated and a new session established. 1359 4.8. Session Extension Items 1361 Each of the Session Extension Items SHALL be encoded in an identical 1362 Type-Length-Value (TLV) container form as indicated in Figure 20. 1364 The fields of the Session Extension Item are: 1366 Flags: A one-octet field containing generic bit flags about the 1367 Item, which are listed in Table 3. All reserved header flag bits 1368 SHALL be set to 0 by the sender. All reserved header flag bits 1369 SHALL be ignored by the receiver. If a TCPCL entity receives a 1370 Session Extension Item with an unknown Item Type and the CRITICAL 1371 flag of 1, the entity SHALL close the TCPCL session with SESS_TERM 1372 reason code of "Contact Failure". If the CRITICAL flag is 0, an 1373 entity SHALL skip over and ignore any item with an unknown Item 1374 Type. 1376 Item Type: A 16-bit unsigned integer field containing the type of 1377 the extension item. This specification does not define any 1378 extension types directly, but does allocate an IANA registry for 1379 such codes (see Section 9.3). 1381 Item Length: A 16-bit unsigned integer field containing the number 1382 of Item Value octets to follow. 1384 Item Value: A variable-length data field which is interpreted 1385 according to the associated Item Type. This specification places 1386 no restrictions on an extension's use of available Item Value 1387 data. Extension specifications SHOULD avoid the use of large data 1388 lengths, as no bundle transfers can begin until the full extension 1389 data is sent. 1391 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1392 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 1393 +---------------+---------------+---------------+---------------+ 1394 | Item Flags | Item Type | Item Length...| 1395 +---------------+---------------+---------------+---------------+ 1396 | length contd. | Item Value... | 1397 +---------------+---------------+---------------+---------------+ 1399 Figure 20: Session Extension Item Format 1401 +----------+--------+-----------------------------------------------+ 1402 | Name | Code | Description | 1403 +----------+--------+-----------------------------------------------+ 1404 | CRITICAL | 0x01 | If bit is set, indicates that the receiving | 1405 | | | peer must handle the extension item. | 1406 | | | | 1407 | Reserved | others | 1408 +----------+--------+-----------------------------------------------+ 1410 Table 3: Session Extension Item Flags 1412 5. Established Session Operation 1414 This section describes the protocol operation for the duration of an 1415 established session, including the mechanism for transmitting bundles 1416 over the session. 1418 5.1. Upkeep and Status Messages 1420 5.1.1. Session Upkeep (KEEPALIVE) 1422 The protocol includes a provision for transmission of KEEPALIVE 1423 messages over the TCPCL session to help determine if the underlying 1424 TCP connection has been disrupted. 1426 As described in Section 4.3, a negotiated parameter of each session 1427 is the Session Keepalive interval. If the negotiated Session 1428 Keepalive is zero (i.e. one or both contact headers contains a zero 1429 Keepalive Interval), then the keepalive feature is disabled. There 1430 is no logical minimum value for the keepalive interval, but when used 1431 for many sessions on an open, shared network a short interval could 1432 lead to excessive traffic. For shared network use, entities SHOULD 1433 choose a keepalive interval no shorter than 30 seconds. There is no 1434 logical maximum value for the keepalive interval, but an idle TCP 1435 connection is liable for closure by the host operating system if the 1436 keepalive time is longer than tens-of-minutes. Entities SHOULD 1437 choose a keepalive interval no longer than 10 minutes (600 seconds). 1439 Note: The Keepalive Interval SHOULD NOT be chosen too short as TCP 1440 retransmissions MAY occur in case of packet loss. Those will have to 1441 be triggered by a timeout (TCP retransmission timeout (RTO)), which 1442 is dependent on the measured RTT for the TCP connection so that 1443 KEEPALIVE messages MAY experience noticeable latency. 1445 The format of a KEEPALIVE message is a one-octet message type code of 1446 KEEPALIVE (as described in Table 2) with no additional data. Both 1447 sides SHALL send a KEEPALIVE message whenever the negotiated interval 1448 has elapsed with no transmission of any message (KEEPALIVE or other). 1450 If no message (KEEPALIVE or other) has been received in a session 1451 after some implementation-defined time duration, then the node SHALL 1452 terminate the session by transmitting a SESS_TERM message (as 1453 described in Section 6.1) with reason code "Idle Timeout". If 1454 configurable, the idle timeout duration SHOULD be no shorter than 1455 twice the keepalive interval. If not configurable, the idle timeout 1456 duration SHOULD be exactly twice the keepalive interval. 1458 5.1.2. Message Rejection (MSG_REJECT) 1460 If a TCPCL node receives a message which is unknown to it (possibly 1461 due to an unhandled protocol mismatch) or is inappropriate for the 1462 current session state (e.g. a KEEPALIVE message received after 1463 contact header negotiation has disabled that feature), there is a 1464 protocol-level message to signal this condition in the form of a 1465 MSG_REJECT reply. 1467 The format of a MSG_REJECT message is as follows in Figure 21. 1469 +-----------------------------+ 1470 | Message Header | 1471 +-----------------------------+ 1472 | Reason Code (U8) | 1473 +-----------------------------+ 1474 | Rejected Message Header | 1475 +-----------------------------+ 1477 Figure 21: Format of MSG_REJECT Messages 1479 The fields of the MSG_REJECT message are: 1481 Reason Code: A one-octet refusal reason code interpreted according 1482 to the descriptions in Table 4. 1484 Rejected Message Header: The Rejected Message Header is a copy of 1485 the Message Header to which the MSG_REJECT message is sent as a 1486 response. 1488 +-------------+------+----------------------------------------------+ 1489 | Name | Code | Description | 1490 +-------------+------+----------------------------------------------+ 1491 | Message | 0x01 | A message was received with a Message Type | 1492 | Type | | code unknown to the TCPCL node. | 1493 | Unknown | | | 1494 | | | | 1495 | Message | 0x02 | A message was received but the TCPCL node | 1496 | Unsupported | | cannot comply with the message contents. | 1497 | | | | 1498 | Message | 0x03 | A message was received while the session is | 1499 | Unexpected | | in a state in which the message is not | 1500 | | | expected. | 1501 +-------------+------+----------------------------------------------+ 1503 Table 4: MSG_REJECT Reason Codes 1505 5.2. Bundle Transfer 1507 All of the messages in this section are directly associated with 1508 transferring a bundle between TCPCL entities. 1510 A single TCPCL transfer results in a bundle (handled by the 1511 convergence layer as opaque data) being exchanged from one node to 1512 the other. In TCPCL a transfer is accomplished by dividing a single 1513 bundle up into "segments" based on the receiving-side Segment MRU 1514 (see Section 4.2). The choice of the length to use for segments is 1515 an implementation matter, but each segment MUST be no larger than the 1516 receiving node's maximum receive unit (MRU) (see the field "Segment 1517 MRU" of Section 4.2). The first segment for a bundle is indicated by 1518 the 'START' flag and the last segment is indicated by the 'END' flag. 1520 A single transfer (and by extension a single segment) SHALL NOT 1521 contain data of more than a single bundle. This requirement is 1522 imposed on the agent using the TCPCL rather than TCPCL itself. 1524 If multiple bundles are transmitted on a single TCPCL connection, 1525 they MUST be transmitted consecutively without interleaving of 1526 segments from multiple bundles. 1528 5.2.1. Bundle Transfer ID 1530 Each of the bundle transfer messages contains a Transfer ID which is 1531 used to correlate messages (from both sides of a transfer) for each 1532 bundle. A Transfer ID does not attempt to address uniqueness of the 1533 bundle data itself and has no relation to concepts such as bundle 1534 fragmentation. Each invocation of TCPCL by the bundle protocol 1535 agent, requesting transmission of a bundle (fragmentary or 1536 otherwise), results in the initiation of a single TCPCL transfer. 1537 Each transfer entails the sending of a sequence of some number of 1538 XFER_SEGMENT and XFER_ACK messages; all are correlated by the same 1539 Transfer ID. 1541 Transfer IDs from each node SHALL be unique within a single TCPCL 1542 session. The initial Transfer ID from each node SHALL have value 1543 zero. Subsequent Transfer ID values SHALL be incremented from the 1544 prior Transfer ID value by one. Upon exhaustion of the entire 64-bit 1545 Transfer ID space, the sending node SHALL terminate the session with 1546 SESS_TERM reason code "Resource Exhaustion". 1548 For bidirectional bundle transfers, a TCPCL node SHOULD NOT rely on 1549 any relation between Transfer IDs originating from each side of the 1550 TCPCL session. 1552 5.2.2. Data Transmission (XFER_SEGMENT) 1554 Each bundle is transmitted in one or more data segments. The format 1555 of a XFER_SEGMENT message follows in Figure 22. 1557 +------------------------------+ 1558 | Message Header | 1559 +------------------------------+ 1560 | Message Flags (U8) | 1561 +------------------------------+ 1562 | Transfer ID (U64) | 1563 +------------------------------+ 1564 | Transfer Extension | 1565 | Items Length (U32) | 1566 | (only for START segment) | 1567 +------------------------------+ 1568 | Transfer Extension | 1569 | Items (var.) | 1570 | (only for START segment) | 1571 +------------------------------+ 1572 | Data length (U64) | 1573 +------------------------------+ 1574 | Data contents (octet string) | 1575 +------------------------------+ 1577 Figure 22: Format of XFER_SEGMENT Messages 1579 The fields of the XFER_SEGMENT message are: 1581 Message Flags: A one-octet field of single-bit flags, interpreted 1582 according to the descriptions in Table 5. All reserved header 1583 flag bits SHALL be set to 0 by the sender. All reserved header 1584 flag bits SHALL be ignored by the receiver. 1586 Transfer ID: A 64-bit unsigned integer identifying the transfer 1587 being made. 1589 Transfer Extension Length and Transfer Extension Items: Together 1590 these fields represent protocol extension data for this 1591 specification. The Transfer Extension Length and Transfer 1592 Extension Item fields SHALL only be present when the 'START' flag 1593 is set to 1 on the message. The Transfer Extension Length is the 1594 total number of octets to follow which are used to encode the 1595 Transfer Extension Item list. The encoding of each Transfer 1596 Extension Item is within a consistent data container as described 1597 in Section 5.2.5. The full set of transfer extension items apply 1598 only to the assoicated single transfer. The order and 1599 mulitplicity of these transfer extension items MAY be significant, 1600 as defined in the associated type specification(s). 1602 Data length: A 64-bit unsigned integer indicating the number of 1603 octets in the Data contents to follow. 1605 Data contents: The variable-length data payload of the message. 1607 +----------+--------+-----------------------------------------------+ 1608 | Name | Code | Description | 1609 +----------+--------+-----------------------------------------------+ 1610 | END | 0x01 | If bit is set, indicates that this is the | 1611 | | | last segment of the transfer. | 1612 | | | | 1613 | START | 0x02 | If bit is set, indicates that this is the | 1614 | | | first segment of the transfer. | 1615 | | | | 1616 | Reserved | others | 1617 +----------+--------+-----------------------------------------------+ 1619 Table 5: XFER_SEGMENT Flags 1621 The flags portion of the message contains two optional values in the 1622 two low-order bits, denoted 'START' and 'END' in Table 5. The 1623 'START' flag SHALL be set to 1 when transmitting the first segment of 1624 a transfer. The 'END' flag SHALL be set to 1 when transmitting the 1625 last segment of a transfer. In the case where an entire transfer is 1626 accomplished in a single segment, both the 'START' and 'END' flags 1627 SHALL be set to 1. 1629 Once a transfer of a bundle has commenced, the node MUST only send 1630 segments containing sequential portions of that bundle until it sends 1631 a segment with the 'END' flag set to 1. No interleaving of multiple 1632 transfers from the same node is possible within a single TCPCL 1633 session. Simultaneous transfers between two entities MAY be achieved 1634 using multiple TCPCL sessions. 1636 5.2.3. Data Acknowledgments (XFER_ACK) 1638 Although the TCP transport provides reliable transfer of data between 1639 transport peers, the typical BSD sockets interface provides no means 1640 to inform a sending application of when the receiving application has 1641 processed some amount of transmitted data. Thus, after transmitting 1642 some data, the TCPCL needs an additional mechanism to determine 1643 whether the receiving agent has successfully received the segment. 1644 To this end, the TCPCL protocol provides feedback messaging whereby a 1645 receiving node transmits acknowledgments of reception of data 1646 segments. 1648 The format of an XFER_ACK message follows in Figure 23. 1650 +-----------------------------+ 1651 | Message Header | 1652 +-----------------------------+ 1653 | Message Flags (U8) | 1654 +-----------------------------+ 1655 | Transfer ID (U64) | 1656 +-----------------------------+ 1657 | Acknowledged length (U64) | 1658 +-----------------------------+ 1660 Figure 23: Format of XFER_ACK Messages 1662 The fields of the XFER_ACK message are: 1664 Message Flags: A one-octet field of single-bit flags, interpreted 1665 according to the descriptions in Table 5. All reserved header 1666 flag bits SHALL be set to 0 by the sender. All reserved header 1667 flag bits SHALL be ignored by the receiver. 1669 Transfer ID: A 64-bit unsigned integer identifying the transfer 1670 being acknowledged. 1672 Acknowledged length: A 64-bit unsigned integer indicating the total 1673 number of octets in the transfer which are being acknowledged. 1675 A receiving TCPCL node SHALL send an XFER_ACK message in response to 1676 each received XFER_SEGMENT message. The flags portion of the 1677 XFER_ACK header SHALL be set to match the corresponding DATA_SEGMENT 1678 message being acknowledged. The acknowledged length of each XFER_ACK 1679 contains the sum of the data length fields of all XFER_SEGMENT 1680 messages received so far in the course of the indicated transfer. 1681 The sending node SHOULD transmit multiple XFER_SEGMENT messages 1682 without waiting for the corresponding XFER_ACK responses. This 1683 enables pipelining of messages on a transfer stream. 1685 For example, suppose the sending node transmits four segments of 1686 bundle data with lengths 100, 200, 500, and 1000, respectively. 1687 After receiving the first segment, the node sends an acknowledgment 1688 of length 100. After the second segment is received, the node sends 1689 an acknowledgment of length 300. The third and fourth 1690 acknowledgments are of length 800 and 1800, respectively. 1692 5.2.4. Transfer Refusal (XFER_REFUSE) 1694 The TCPCL supports a mechanism by which a receiving node can indicate 1695 to the sender that it does not want to receive the corresponding 1696 bundle. To do so, upon receiving an XFER_SEGMENT message, the node 1697 MAY transmit a XFER_REFUSE message. As data segments and 1698 acknowledgments MAY cross on the wire, the bundle that is being 1699 refused SHALL be identified by the Transfer ID of the refusal. 1701 There is no required relation between the Transfer MRU of a TCPCL 1702 node (which is supposed to represent a firm limitation of what the 1703 node will accept) and sending of a XFER_REFUSE message. A 1704 XFER_REFUSE can be used in cases where the agent's bundle storage is 1705 temporarily depleted or somehow constrained. A XFER_REFUSE can also 1706 be used after the bundle header or any bundle data is inspected by an 1707 agent and determined to be unacceptable. 1709 A receiver MAY send an XFER_REFUSE message as soon as it receives any 1710 XFER_SEGMENT message. The sender MUST be prepared for this and MUST 1711 associate the refusal with the correct bundle via the Transfer ID 1712 fields. 1714 The format of the XFER_REFUSE message is as follows in Figure 24. 1716 +-----------------------------+ 1717 | Message Header | 1718 +-----------------------------+ 1719 | Reason Code (U8) | 1720 +-----------------------------+ 1721 | Transfer ID (U64) | 1722 +-----------------------------+ 1724 Figure 24: Format of XFER_REFUSE Messages 1726 The fields of the XFER_REFUSE message are: 1728 Reason Code: A one-octet refusal reason code interpreted according 1729 to the descriptions in Table 6. 1731 Transfer ID: A 64-bit unsigned integer identifying the transfer 1732 being refused. 1734 +------------+------+-----------------------------------------------+ 1735 | Name | Code | Description | 1736 +------------+------+-----------------------------------------------+ 1737 | Unknown | 0x00 | Reason for refusal is unknown or not | 1738 | | | specified. | 1739 | | | | 1740 | Extension | 0x01 | A failure processing the Transfer Extension | 1741 | Failure | | Items ha occurred. | 1742 | | | | 1743 | Completed | 0x02 | The receiver already has the complete bundle. | 1744 | | | The sender MAY consider the bundle as | 1745 | | | completely received. | 1746 | | | | 1747 | No | 0x03 | The receiver's resources are exhausted. The | 1748 | Resources | | sender SHOULD apply reactive bundle | 1749 | | | fragmentation before retrying. | 1750 | | | | 1751 | Retransmit | 0x04 | The receiver has encountered a problem that | 1752 | | | requires the bundle to be retransmitted in | 1753 | | | its entirety. | 1754 +------------+------+-----------------------------------------------+ 1756 Table 6: XFER_REFUSE Reason Codes 1758 The receiver MUST, for each transfer preceding the one to be refused, 1759 have either acknowledged all XFER_SEGMENTs or refused the bundle 1760 transfer. 1762 The bundle transfer refusal MAY be sent before an entire data segment 1763 is received. If a sender receives a XFER_REFUSE message, the sender 1764 MUST complete the transmission of any partially sent XFER_SEGMENT 1765 message. There is no way to interrupt an individual TCPCL message 1766 partway through sending it. The sender MUST NOT commence 1767 transmission of any further segments of the refused bundle 1768 subsequently. Note, however, that this requirement does not ensure 1769 that an entity will not receive another XFER_SEGMENT for the same 1770 bundle after transmitting a XFER_REFUSE message since messages MAY 1771 cross on the wire; if this happens, subsequent segments of the bundle 1772 SHALL also be refused with a XFER_REFUSE message. 1774 Note: If a bundle transmission is aborted in this way, the receiver 1775 MAY not receive a segment with the 'END' flag set to 1 for the 1776 aborted bundle. The beginning of the next bundle is identified by 1777 the 'START' flag set to 1, indicating the start of a new transfer, 1778 and with a distinct Transfer ID value. 1780 5.2.5. Transfer Extension Items 1782 Each of the Transfer Extension Items SHALL be encoded in an identical 1783 Type-Length-Value (TLV) container form as indicated in Figure 25. 1785 The fields of the Transfer Extension Item are: 1787 Flags: A one-octet field containing generic bit flags about the 1788 Item, which are listed in Table 7. All reserved header flag bits 1789 SHALL be set to 0 by the sender. All reserved header flag bits 1790 SHALL be ignored by the receiver. If a TCPCL node receives a 1791 Transfer Extension Item with an unknown Item Type and the CRITICAL 1792 flag is 1, the node SHALL refuse the transfer with an XFER_REFUSE 1793 reason code of "Extension Failure". If the CRITICAL flag is 0, an 1794 entity SHALL skip over and ignore any item with an unknown Item 1795 Type. 1797 Item Type: A 16-bit unsigned integer field containing the type of 1798 the extension item. This specification allocates an IANA registry 1799 for such codes (see Section 9.4). 1801 Item Length: A 16-bit unsigned integer field containing the number 1802 of Item Value octets to follow. 1804 Item Value: A variable-length data field which is interpreted 1805 according to the associated Item Type. This specification places 1806 no restrictions on an extension's use of available Item Value 1807 data. Extension specifications SHOULD avoid the use of large data 1808 lengths, as the associated transfer cannot begin until the full 1809 extension data is sent. 1811 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1812 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 1813 +---------------+---------------+---------------+---------------+ 1814 | Item Flags | Item Type | Item Length...| 1815 +---------------+---------------+---------------+---------------+ 1816 | length contd. | Item Value... | 1817 +---------------+---------------+---------------+---------------+ 1819 Figure 25: Transfer Extension Item Format 1821 +----------+--------+-----------------------------------------------+ 1822 | Name | Code | Description | 1823 +----------+--------+-----------------------------------------------+ 1824 | CRITICAL | 0x01 | If bit is set, indicates that the receiving | 1825 | | | peer must handle the extension item. | 1826 | | | | 1827 | Reserved | others | 1828 +----------+--------+-----------------------------------------------+ 1830 Table 7: Transfer Extension Item Flags 1832 5.2.5.1. Transfer Length Extension 1834 The purpose of the Transfer Length extension is to allow entities to 1835 preemptively refuse bundles that would exceed their resources or to 1836 prepare storage on the receiving node for the upcoming bundle data. 1838 Multiple Transfer Length extension items SHALL NOT occur within the 1839 same transfer. The lack of a Transfer Length extension item in any 1840 transfer SHALL NOT imply anything about the potential length of the 1841 transfer. The Transfer Length extension SHALL be assigned transfer 1842 extension type ID 0x0001. 1844 If a transfer occupies exactly one segment (i.e. both START and END 1845 flags are 1) the Transfer Length extension SHOULD NOT be present. 1846 The extension does not provide any additional information for single- 1847 segment transfers. 1849 The format of the Transfer Length data is as follows in Figure 26. 1851 +----------------------+ 1852 | Total Length (U64) | 1853 +----------------------+ 1855 Figure 26: Format of Transfer Length data 1857 The fields of the Transfer Length extension are: 1859 Total Length: A 64-bit unsigned integer indicating the size of the 1860 data-to-be-transferred. The Total Length field SHALL be treated 1861 as authoritative by the receiver. If, for whatever reason, the 1862 actual total length of bundle data received differs from the value 1863 indicated by the Total Length value, the receiver SHALL treat the 1864 transmitted data as invalid. 1866 6. Session Termination 1868 This section describes the procedures for ending a TCPCL session. 1870 6.1. Session Termination Message (SESS_TERM) 1872 To cleanly shut down a session, a SESS_TERM message SHALL be 1873 transmitted by either node at any point following complete 1874 transmission of any other message. When sent to initiate a 1875 termination, the REPLY flag of a SESS_TERM message SHALL be 0. Upon 1876 receiving a SESS_TERM message after not sending a SESS_TERM message 1877 in the same session, an entity SHALL send an acknowledging SESS_TERM 1878 message. When sent to acknowledge a termination, a SESS_TERM message 1879 SHALL have identical data content from the message being acknowledged 1880 except for the REPLY flag, which is set to 1 to indicate 1881 acknowledgement. 1883 After sending a SESS_TERM message, an entity MAY continue a possible 1884 in-progress transfer in either direction. After sending a SESS_TERM 1885 message, an entity SHALL NOT begin any new outgoing transfer for the 1886 remainder of the session. After receving a SESS_TERM message, an 1887 entity SHALL NOT accept any new incoming transfer for the remainder 1888 of the session. 1890 Instead of following a clean shutdown sequence, after transmitting a 1891 SESS_TERM message an entity MAY immediately close the associated TCP 1892 connection. When performing an unclean shutdown, a receiving node 1893 SHOULD acknowledge all received data segments before closing the TCP 1894 connection. Not acknowledging received segments can result in 1895 unnecessary retransmission. When performing an unclean shutodwn, a 1896 transmitting node SHALL treat either sending or receiving a SESS_TERM 1897 message (i.e. before the final acknowledgment) as a failure of the 1898 transfer. Any delay between request to close the TCP connection and 1899 actual closing of the connection (a "half-closed" state) MAY be 1900 ignored by the TCPCL node. 1902 The format of the SESS_TERM message is as follows in Figure 27. 1904 +-----------------------------+ 1905 | Message Header | 1906 +-----------------------------+ 1907 | Message Flags (U8) | 1908 +-----------------------------+ 1909 | Reason Code (U8) | 1910 +-----------------------------+ 1912 Figure 27: Format of SESS_TERM Messages 1914 The fields of the SESS_TERM message are: 1916 Message Flags: A one-octet field of single-bit flags, interpreted 1917 according to the descriptions in Table 8. All reserved header 1918 flag bits SHALL be set to 0 by the sender. All reserved header 1919 flag bits SHALL be ignored by the receiver. 1921 Reason Code: A one-octet refusal reason code interpreted according 1922 to the descriptions in Table 9. 1924 +----------+--------+-----------------------------------------------+ 1925 | Name | Code | Description | 1926 +----------+--------+-----------------------------------------------+ 1927 | REPLY | 0x01 | If bit is set, indicates that this message is | 1928 | | | an acknowledgement of an earlier SESS_TERM | 1929 | | | message. | 1930 | | | | 1931 | Reserved | others | 1932 +----------+--------+-----------------------------------------------+ 1934 Table 8: SESS_TERM Flags 1936 +--------------+------+---------------------------------------------+ 1937 | Name | Code | Description | 1938 +--------------+------+---------------------------------------------+ 1939 | Unknown | 0x00 | A termination reason is not available. | 1940 | | | | 1941 | Idle timeout | 0x01 | The session is being closed due to | 1942 | | | idleness. | 1943 | | | | 1944 | Version | 0x02 | The node cannot conform to the specified | 1945 | mismatch | | TCPCL protocol version. | 1946 | | | | 1947 | Busy | 0x03 | The node is too busy to handle the current | 1948 | | | session. | 1949 | | | | 1950 | Contact | 0x04 | The node cannot interpret or negotiate | 1951 | Failure | | contact header option. | 1952 | | | | 1953 | Resource | 0x05 | The node has run into some resource limit | 1954 | Exhaustion | | and cannot continue the session. | 1955 +--------------+------+---------------------------------------------+ 1957 Table 9: SESS_TERM Reason Codes 1959 A session shutdown MAY occur immediately after transmission of a 1960 contact header (and prior to any further message transmit). This 1961 MAY, for example, be used to notify that the node is currently not 1962 able or willing to communicate. However, an entity MUST always send 1963 the contact header to its peer before sending a SESS_TERM message. 1965 If reception of the contact header itself somehow fails (e.g. an 1966 invalid "magic string" is recevied), an entity SHALL close the TCP 1967 connection without sending a SESS_TERM message. If the content of 1968 the Session Extension Items data disagrees with the Session Extension 1969 Length (i.e. the last Item claims to use more octets than are present 1970 in the Session Extension Length), the reception of the contact header 1971 is considered to have failed. 1973 If a session is to be terminated before a protocol message has 1974 completed being sent, then the node MUST NOT transmit the SESS_TERM 1975 message but still SHALL close the TCP connection. Each TCPCL message 1976 is contiguous in the octet stream and has no ability to be cut short 1977 and/or preempted by an other message. This is particularly important 1978 when large segment sizes are being transmitted; either entire 1979 XFER_SEGMENT is sent before a SESS_TERM message or the connection is 1980 simply terminated mid-XFER_SEGMENT. 1982 6.2. Idle Session Shutdown 1984 The protocol includes a provision for clean shutdown of idle 1985 sessions. Determining the length of time to wait before ending idle 1986 sessions, if they are to be closed at all, is an implementation and 1987 configuration matter. 1989 If there is a configured time to close idle links and if no TCPCL 1990 messages (other than KEEPALIVE messages) has been received for at 1991 least that amount of time, then either node MAY terminate the session 1992 by transmitting a SESS_TERM message indicating the reason code of 1993 "Idle timeout" (as described in Table 9). 1995 7. Implementation Status 1997 [NOTE to the RFC Editor: please remove this section before 1998 publication, as well as the reference to [RFC7942] and 1999 [github-dtn-bpbis-tcpcl].] 2001 This section records the status of known implementations of the 2002 protocol defined by this specification at the time of posting of this 2003 Internet-Draft, and is based on a proposal described in [RFC7942]. 2004 The description of implementations in this section is intended to 2005 assist the IETF in its decision processes in progressing drafts to 2006 RFCs. Please note that the listing of any individual implementation 2007 here does not imply endorsement by the IETF. Furthermore, no effort 2008 has been spent to verify the information presented here that was 2009 supplied by IETF contributors. This is not intended as, and must not 2010 be construed to be, a catalog of available implementations or their 2011 features. Readers are advised to note that other implementations can 2012 exist. 2014 An example implementation of the this draft of TCPCLv4 has been 2015 created as a GitHub project [github-dtn-bpbis-tcpcl] and is intented 2016 to use as a proof-of-concept and as a possible source of 2017 interoperability testing. This example implementation uses D-Bus as 2018 the CL-BP Agent interface, so it only runs on hosts which provide the 2019 Python "dbus" library. 2021 8. Security Considerations 2023 TCPCL can be used to provide point-to-point transport security, but 2024 does not provide security of data-at-rest and does not guarantee end- 2025 to-end bundle security. The bundle security mechanisms defined in 2026 [I-D.ietf-dtn-bpsec] are to be used instead. 2028 When negotating whether to use TLS security as part of the contact 2029 header exchange, it is possible for a man-in-the-middle attacker to 2030 set the CAN_TLS flag to 0 on either side of the exchange. This leads 2031 to the "SSL Stripping" attack described in [RFC7457]. If TLS is 2032 desired for use on any TCPCL network, it is strongly encouraged that 2033 the security policy disallow use of TCPCL when "Enable TLS" is 2034 negotiated to false. This requires that the TLS handshake occurs, 2035 regardless of the policy-driven parameters of the handshake and 2036 policy-driven handling of the handshake outcome. 2038 Even when using TLS to secure the TCPCL session, the actual 2039 ciphersuite negotiated between the TLS peers MAY be insecure. TLS 2040 can be used to perform authentication without data confidentiality, 2041 for example. It is up to security policies within each TCPCL node to 2042 ensure that the negotiated TLS ciphersuite meets transport security 2043 requirements. This is identical behavior to STARTTLS use in 2044 [RFC2595]. 2046 The certificates exchanged by TLS enable authentication of peer host 2047 name and Node ID, but it is possible that a peer either not provide a 2048 valid certificate or that the certificate does not validate either 2049 the host name or Node ID of the peer. Having a CA-validated 2050 certificate does not alone guarantee the identity of the network host 2051 or BP node from which the certificate is provided; additional 2052 validation procedures bind the host name or node ID based on the 2053 contents of the certificate. The host name validation is a weaker 2054 form of authentication, because even if a peer is operating on an 2055 authenticated network host name it can provide an invalid Node ID and 2056 cause bundles to be "leaked" to an invalid node. Especially in DTN 2057 environments, network names and addresses of nodes can be time- 2058 variable so binding a certificate to a Node ID is a more stable 2059 identity. Node ID validation ensures that the peer to which a bundle 2060 is transferred is in fact the node which the BP Agent expects it to 2061 be. It is a reasonable policy to skip host name validation if 2062 certificates can be guaranteed to validate the peer's Node ID. In 2063 circumstances where certificates can only be issued to network host 2064 names, Node ID validation is not possible but it could be reasonable 2065 to assume that a trusted host is not going to present an invalid Node 2066 ID. Trusting an authenticated host name can be feasable on a network 2067 secured by a private CA but is not advisable on the Internet when 2068 using a variety of public CAs. 2070 Another consideration for this protocol relates to denial-of-service 2071 attacks. An entity MAY send a large amount of data over a TCPCL 2072 session, requiring the receiving entity to handle the data, attempt 2073 to stop the flood of data by sending a XFER_REFUSE message, or 2074 forcibly terminate the session. This burden could cause denial of 2075 service on other, well-behaving sessions. There is also nothing to 2076 prevent a malicious entity from continually establishing sessions and 2077 repeatedly trying to send copious amounts of bundle data. A 2078 listening entity MAY take countermeasures such as ignoring TCP SYN 2079 messages, closing TCP connections as soon as they are established, 2080 waiting before sending the contact header, sending a SESS_TERM 2081 message quickly or with a delay, etc. 2083 9. IANA Considerations 2085 Registration procedures referred to in this section are defined in 2086 [RFC8126]. 2088 Some of the registries have been defined as version specific to 2089 TCPCLv4, and imports some or all codepoints from TCPCLv3. This was 2090 done to disambiguate the use of these codepoints between TCPCLv3 and 2091 TCPCLv4 while preserving the semantics of some of the codepoints. 2093 9.1. Port Number 2095 Port number 4556 has been previously assigned as the default port for 2096 the TCP convergence layer in [RFC7242]. This assignment is unchanged 2097 by protocol version 4. Each TCPCL entity identifies its TCPCL 2098 protocol version in its initial contact (see Section 9.2), so there 2099 is no ambiguity about what protocol is being used. 2101 +------------------------+-------------------------------------+ 2102 | Parameter | Value | 2103 +------------------------+-------------------------------------+ 2104 | Service Name: | dtn-bundle | 2105 | | | 2106 | Transport Protocol(s): | TCP | 2107 | | | 2108 | Assignee: | Simon Perreault | 2109 | | | 2110 | Contact: | Simon Perreault | 2111 | | | 2112 | Description: | DTN Bundle TCP CL Protocol | 2113 | | | 2114 | Reference: | [RFC7242] | 2115 | | | 2116 | Port Number: | 4556 | 2117 +------------------------+-------------------------------------+ 2119 9.2. Protocol Versions 2121 IANA has created, under the "Bundle Protocol" registry, a sub- 2122 registry titled "Bundle Protocol TCP Convergence-Layer Version 2123 Numbers" and initialize it with the following table. The 2124 registration procedure is RFC Required. 2126 +-------+-------------+---------------------+ 2127 | Value | Description | Reference | 2128 +-------+-------------+---------------------+ 2129 | 0 | Reserved | [RFC7242] | 2130 | | | | 2131 | 1 | Reserved | [RFC7242] | 2132 | | | | 2133 | 2 | Reserved | [RFC7242] | 2134 | | | | 2135 | 3 | TCPCL | [RFC7242] | 2136 | | | | 2137 | 4 | TCPCLv4 | This specification. | 2138 | | | | 2139 | 5-255 | Unassigned | 2140 +-------+-------------+---------------------+ 2142 9.3. Session Extension Types 2144 EDITOR NOTE: sub-registry to-be-created upon publication of this 2145 specification. 2147 IANA will create, under the "Bundle Protocol" registry, a sub- 2148 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 2149 Session Extension Types" and initialize it with the contents of 2150 Table 10. The registration procedure is Expert Review within the 2151 lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are 2152 reserved for use on private networks for functions not published to 2153 the IANA. 2155 Specifications of new session extension types need to define the 2156 encoding of the Item Value data as well as any meaning or restriction 2157 on the number of or order of instances of the type within an 2158 extension item list. Specifications need to define how the extension 2159 functions when no instance of the new extension type is received 2160 during session negotiation. 2162 Expert(s) are encouraged to be biased towards approving registrations 2163 unless they are abusive, frivolous, or actively harmful (not merely 2164 aesthetically displeasing, or architecturally dubious). 2166 +----------------+--------------------------+ 2167 | Code | Session Extension Type | 2168 +----------------+--------------------------+ 2169 | 0x0000 | Reserved | 2170 | | | 2171 | 0x0001--0x7FFF | Unassigned | 2172 | | | 2173 | 0x8000--0xFFFF | Private/Experimental Use | 2174 +----------------+--------------------------+ 2176 Table 10: Session Extension Type Codes 2178 9.4. Transfer Extension Types 2180 EDITOR NOTE: sub-registry to-be-created upon publication of this 2181 specification. 2183 IANA will create, under the "Bundle Protocol" registry, a sub- 2184 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 2185 Transfer Extension Types" and initialize it with the contents of 2186 Table 11. The registration procedure is Expert Review within the 2187 lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are 2188 reserved for use on private networks for functions not published to 2189 the IANA. 2191 Specifications of new transfer extension types need to define the 2192 encoding of the Item Value data as well as any meaning or restriction 2193 on the number of or order of instances of the type within an 2194 extension item list. Specifications need to define how the extension 2195 functions when no instance of the new extension type is received in a 2196 transfer. 2198 Expert(s) are encouraged to be biased towards approving registrations 2199 unless they are abusive, frivolous, or actively harmful (not merely 2200 aesthetically displeasing, or architecturally dubious). 2202 +----------------+---------------------------+ 2203 | Code | Transfer Extension Type | 2204 +----------------+---------------------------+ 2205 | 0x0000 | Reserved | 2206 | | | 2207 | 0x0001 | Transfer Length Extension | 2208 | | | 2209 | 0x0002--0x7FFF | Unassigned | 2210 | | | 2211 | 0x8000--0xFFFF | Private/Experimental Use | 2212 +----------------+---------------------------+ 2214 Table 11: Transfer Extension Type Codes 2216 9.5. Message Types 2218 EDITOR NOTE: sub-registry to-be-created upon publication of this 2219 specification. 2221 IANA will create, under the "Bundle Protocol" registry, a sub- 2222 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 2223 Message Types" and initialize it with the contents of Table 12. The 2224 registration procedure is RFC Required within the lower range 0x01-- 2225 0xEF. Values in the range 0xF0--0xFF are reserved for use on private 2226 networks for functions not published to the IANA. 2228 Specifications of new message types need to define the encoding of 2229 the message data as well as the purpose and relationship of the new 2230 message to existing session/transfer state within the baseline 2231 message sequencing. The use of new message types need to be 2232 negotiated between TCPCL entities within a session (using the session 2233 extension mechanism) so that the receving entity can properly decode 2234 all message types used in the session. 2236 Expert(s) are encouraged to favor new session/transfer extension 2237 types over new message types. TCPCL messages are not self- 2238 delimiting, so care must be taken in introducing new message types. 2239 If an entity receives an unknown message type the only thing that can 2240 be done is to send a MSG_REJECT and close the TCP connection; not 2241 even a clean termination can be done at that point. 2243 +------------+--------------------------+ 2244 | Code | Message Type | 2245 +------------+--------------------------+ 2246 | 0x00 | Reserved | 2247 | | | 2248 | 0x01 | XFER_SEGMENT | 2249 | | | 2250 | 0x02 | XFER_ACK | 2251 | | | 2252 | 0x03 | XFER_REFUSE | 2253 | | | 2254 | 0x04 | KEEPALIVE | 2255 | | | 2256 | 0x05 | SESS_TERM | 2257 | | | 2258 | 0x06 | MSG_REJECT | 2259 | | | 2260 | 0x07 | SESS_INIT | 2261 | | | 2262 | 0x08--0xEF | Unassigned | 2263 | | | 2264 | 0xF0--0xFF | Private/Experimental Use | 2265 +------------+--------------------------+ 2267 Table 12: Message Type Codes 2269 9.6. XFER_REFUSE Reason Codes 2271 EDITOR NOTE: sub-registry to-be-created upon publication of this 2272 specification. 2274 IANA will create, under the "Bundle Protocol" registry, a sub- 2275 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 2276 XFER_REFUSE Reason Codes" and initialize it with the contents of 2277 Table 13. The registration procedure is Specification Required 2278 within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF 2279 are reserved for use on private networks for functions not published 2280 to the IANA. 2282 Specifications of new XFER_REFUSE reason codes need to define the 2283 meaning of the reason and disambiguate it with pre-exisiting reasons. 2284 Each refusal reason needs to be usable by the receving BP Agent to 2285 make retransmission or re-routing decisions. 2287 Expert(s) are encouraged to be biased towards approving registrations 2288 unless they are abusive, frivolous, or actively harmful (not merely 2289 aesthetically displeasing, or architecturally dubious). 2291 +------------+--------------------------+ 2292 | Code | Refusal Reason | 2293 +------------+--------------------------+ 2294 | 0x00 | Unknown | 2295 | | | 2296 | 0x01 | Extension Failure | 2297 | | | 2298 | 0x02 | Completed | 2299 | | | 2300 | 0x03 | No Resources | 2301 | | | 2302 | 0x04 | Retransmit | 2303 | | | 2304 | 0x05--0xEF | Unassigned | 2305 | | | 2306 | 0xF0--0xFF | Private/Experimental Use | 2307 +------------+--------------------------+ 2309 Table 13: XFER_REFUSE Reason Codes 2311 9.7. SESS_TERM Reason Codes 2313 EDITOR NOTE: sub-registry to-be-created upon publication of this 2314 specification. 2316 IANA will create, under the "Bundle Protocol" registry, a sub- 2317 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 2318 SESS_TERM Reason Codes" and initialize it with the contents of 2319 Table 14. The registration procedure is Specification Required 2320 within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF 2321 are reserved for use on private networks for functions not published 2322 to the IANA. 2324 Specifications of new SESS_TERM reason codes need to define the 2325 meaning of the reason and disambiguate it with pre-exisiting reasons. 2326 Each termination reason needs to be usable by the receving BP Agent 2327 to make re-connection decisions. 2329 Expert(s) are encouraged to be biased towards approving registrations 2330 unless they are abusive, frivolous, or actively harmful (not merely 2331 aesthetically displeasing, or architecturally dubious). 2333 +------------+--------------------------+ 2334 | Code | Termination Reason | 2335 +------------+--------------------------+ 2336 | 0x00 | Unknown | 2337 | | | 2338 | 0x01 | Idle timeout | 2339 | | | 2340 | 0x02 | Version mismatch | 2341 | | | 2342 | 0x03 | Busy | 2343 | | | 2344 | 0x04 | Contact Failure | 2345 | | | 2346 | 0x05 | Resource Exhaustion | 2347 | | | 2348 | 0x06--0xEF | Unassigned | 2349 | | | 2350 | 0xF0--0xFF | Private/Experimental Use | 2351 +------------+--------------------------+ 2353 Table 14: SESS_TERM Reason Codes 2355 9.8. MSG_REJECT Reason Codes 2357 EDITOR NOTE: sub-registry to-be-created upon publication of this 2358 specification. 2360 IANA will create, under the "Bundle Protocol" registry, a sub- 2361 registry titled "Bundle Protocol TCP Convergence-Layer Version 4 2362 MSG_REJECT Reason Codes" and initialize it with the contents of 2363 Table 15. The registration procedure is Specification Required 2364 within the lower range 0x01--0xEF. Values in the range 0xF0--0xFF 2365 are reserved for use on private networks for functions not published 2366 to the IANA. 2368 Specifications of new MSG_REJECT reason codes need to define the 2369 meaning of the reason and disambiguate it with pre-exisiting reasons. 2370 Each rejection reason needs to be usable by the receving TCPCL Entity 2371 to make message sequencing and/or session termination decisions. 2373 Expert(s) are encouraged to be biased towards approving registrations 2374 unless they are abusive, frivolous, or actively harmful (not merely 2375 aesthetically displeasing, or architecturally dubious). 2377 +------------+--------------------------+ 2378 | Code | Rejection Reason | 2379 +------------+--------------------------+ 2380 | 0x00 | reserved | 2381 | | | 2382 | 0x01 | Message Type Unknown | 2383 | | | 2384 | 0x02 | Message Unsupported | 2385 | | | 2386 | 0x03 | Message Unexpected | 2387 | | | 2388 | 0x04--0xEF | Unassigned | 2389 | | | 2390 | 0xF0--0xFF | Private/Experimental Use | 2391 +------------+--------------------------+ 2393 Table 15: MSG_REJECT Reason Codes 2395 10. Acknowledgments 2397 This specification is based on comments on implementation of 2398 [RFC7242] provided from Scott Burleigh. 2400 11. References 2402 11.1. Normative References 2404 [I-D.ietf-dtn-bpbis] 2405 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 2406 Version 7", draft-ietf-dtn-bpbis-14 (work in progress), 2407 August 2019. 2409 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2410 RFC 793, DOI 10.17487/RFC0793, September 1981, 2411 . 2413 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2414 Communication Layers", STD 3, RFC 1122, 2415 DOI 10.17487/RFC1122, October 1989, 2416 . 2418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2419 Requirement Levels", BCP 14, RFC 2119, 2420 DOI 10.17487/RFC2119, March 1997, 2421 . 2423 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2424 Resource Identifier (URI): Generic Syntax", STD 66, 2425 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2426 . 2428 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2429 (TLS) Protocol Version 1.2", RFC 5246, 2430 DOI 10.17487/RFC5246, August 2008, 2431 . 2433 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2434 Housley, R., and W. Polk, "Internet X.509 Public Key 2435 Infrastructure Certificate and Certificate Revocation List 2436 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2437 . 2439 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 2440 Extensions: Extension Definitions", RFC 6066, 2441 DOI 10.17487/RFC6066, January 2011, 2442 . 2444 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2445 Verification of Domain-Based Application Service Identity 2446 within Internet Public Key Infrastructure Using X.509 2447 (PKIX) Certificates in the Context of Transport Layer 2448 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2449 2011, . 2451 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2452 "Recommendations for Secure Use of Transport Layer 2453 Security (TLS) and Datagram Transport Layer Security 2454 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2455 2015, . 2457 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2458 Writing an IANA Considerations Section in RFCs", BCP 26, 2459 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2460 . 2462 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2463 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2464 May 2017, . 2466 11.2. Informative References 2468 [github-dtn-bpbis-tcpcl] 2469 Sipos, B., "TCPCL Example Implementation", 2470 . 2473 [I-D.ietf-dtn-bpsec] 2474 Birrane, E. and K. McKeever, "Bundle Protocol Security 2475 Specification", draft-ietf-dtn-bpsec-12 (work in 2476 progress), September 2019. 2478 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 2479 RFC 2595, DOI 10.17487/RFC2595, June 1999, 2480 . 2482 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 2483 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 2484 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 2485 April 2007, . 2487 [RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant 2488 Networking TCP Convergence-Layer Protocol", RFC 7242, 2489 DOI 10.17487/RFC7242, June 2014, 2490 . 2492 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 2493 Known Attacks on Transport Layer Security (TLS) and 2494 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 2495 February 2015, . 2497 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2498 Code: The Implementation Status Section", BCP 205, 2499 RFC 7942, DOI 10.17487/RFC7942, July 2016, 2500 . 2502 Appendix A. Significant changes from RFC7242 2504 The areas in which changes from [RFC7242] have been made to existing 2505 headers and messages are: 2507 o Split contact header into pre-TLS protocol negotiation and 2508 SESS_INIT parameter negotiation. The contact header is now fixed- 2509 length. 2511 o Changed contact header content to limit number of negotiated 2512 options. 2514 o Added session option to negotiate maximum segment size (per each 2515 direction). 2517 o Renamed "Endpoint ID" to "Node ID" to conform with BPv7 2518 terminology. 2520 o Added session extension capability. 2522 o Added transfer extension capability. Moved transfer total length 2523 into an extension item. 2525 o Defined new IANA registries for message / type / reason codes to 2526 allow renaming some codes for clarity. 2528 o Segments of all new IANA registries are reserved for private/ 2529 experimental use. 2531 o Expanded Message Header to octet-aligned fields instead of bit- 2532 packing. 2534 o Added a bundle transfer identification number to all bundle- 2535 related messages (XFER_SEGMENT, XFER_ACK, XFER_REFUSE). 2537 o Use flags in XFER_ACK to mirror flags from XFER_SEGMENT. 2539 o Removed all uses of SDNV fields and replaced with fixed-bit-length 2540 fields. 2542 o Renamed SHUTDOWN to SESS_TERM to deconflict term "shutdown" 2543 related to TCP connections. 2545 o Removed the notion of a re-connection delay parameter. 2547 The areas in which extensions from [RFC7242] have been made as new 2548 messages and codes are: 2550 o Added contact negotiation failure SESS_TERM reason code. 2552 o Added MSG_REJECT message to indicate an unknown or unhandled 2553 message was received. 2555 o Added TLS session security mechanism. 2557 o Added Resource Exhaustion SESS_TERM reason code. 2559 Authors' Addresses 2560 Brian Sipos 2561 RKF Engineering Solutions, LLC 2562 7500 Old Georgetown Road 2563 Suite 1275 2564 Bethesda, MD 20814-6198 2565 United States of America 2567 Email: BSipos@rkf-eng.com 2569 Michael Demmer 2570 University of California, Berkeley 2571 Computer Science Division 2572 445 Soda Hall 2573 Berkeley, CA 94720-1776 2574 United States of America 2576 Email: demmer@cs.berkeley.edu 2578 Joerg Ott 2579 Aalto University 2580 Department of Communications and Networking 2581 PO Box 13000 2582 Aalto 02015 2583 Finland 2585 Email: ott@in.tum.de 2587 Simon Perreault 2588 Quebec, QC 2589 Canada 2591 Email: simon@per.reau.lt