idnits 2.17.1 draft-ietf-dtn-tcpclv4-23.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (14 November 2020) is 1259 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: 'PCH' is mentioned on line 672, but not defined == Missing Reference: 'ST' is mentioned on line 794, but not defined == Missing Reference: 'PSI' is mentioned on line 727, but not defined == Missing Reference: 'SI' is mentioned on line 706, but not defined == Missing Reference: 'I1' is mentioned on line 995, but not defined == Missing Reference: 'L1' is mentioned on line 983, but not defined == Missing Reference: 'L2' is mentioned on line 983, but not defined == Missing Reference: 'L3' is mentioned on line 989, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-PORTS' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-BUNDLE' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-31) exists of draft-ietf-dtn-bpbis-27 == Outdated reference: A later version (-27) exists of draft-ietf-dtn-bpsec-23 Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 3 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 Intended status: Standards Track M. Demmer 5 Expires: 18 May 2021 UC Berkeley 6 J. Ott 7 Aalto University 8 S. Perreault 9 14 November 2020 11 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 12 draft-ietf-dtn-tcpclv4-23 14 Abstract 16 This document describes a TCP-based convergence layer (TCPCL) for 17 Delay-Tolerant Networking (DTN). This version of the TCPCL protocol 18 resolves implementation issues in the earlier TCPCL Version 3 of 19 RFC7242 and updates to the Bundle Protocol (BP) contents, encodings, 20 and convergence layer requirements in BP Version 7. Specifically, 21 the TCPCLv4 uses CBOR-encoded BPv7 bundles as its service data unit 22 being transported and provides a reliable transport of such bundles. 23 This version of TCPCL also includes security and extensibility 24 mechanisms. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 18 May 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 62 2.1. Definitions Specific to the TCPCL Protocol . . . . . . . 5 63 3. General Protocol Description . . . . . . . . . . . . . . . . 9 64 3.1. Convergence Layer Services . . . . . . . . . . . . . . . 9 65 3.2. TCPCL Session Overview . . . . . . . . . . . . . . . . . 11 66 3.3. TCPCL States and Transitions . . . . . . . . . . . . . . 13 67 3.4. PKIX Environments and CA Policy . . . . . . . . . . . . . 19 68 3.5. Session Keeping Policies . . . . . . . . . . . . . . . . 20 69 3.6. Transfer Segmentation Policies . . . . . . . . . . . . . 21 70 3.7. Example Message Exchange . . . . . . . . . . . . . . . . 22 71 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 24 72 4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 24 73 4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 25 74 4.3. Contact Validation and Negotiation . . . . . . . . . . . 26 75 4.4. Session Security . . . . . . . . . . . . . . . . . . . . 28 76 4.4.1. Entity Identification . . . . . . . . . . . . . . . . 28 77 4.4.2. TLS Handshake . . . . . . . . . . . . . . . . . . . . 29 78 4.4.3. TLS Authentication . . . . . . . . . . . . . . . . . 31 79 4.4.4. Example TLS Initiation . . . . . . . . . . . . . . . 32 80 4.5. Message Header . . . . . . . . . . . . . . . . . . . . . 34 81 4.6. Session Initialization Message (SESS_INIT) . . . . . . . 35 82 4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 37 83 4.8. Session Extension Items . . . . . . . . . . . . . . . . . 38 84 5. Established Session Operation . . . . . . . . . . . . . . . . 39 85 5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 39 86 5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 39 87 5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 40 88 5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 42 89 5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 43 90 5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 43 91 5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 45 92 5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 47 93 5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 49 94 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 51 95 6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 51 96 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 54 97 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 54 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 54 99 8.1. Threat: Passive Leak of Node Data . . . . . . . . . . . . 55 100 8.2. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 55 101 8.3. Threat: TCPCL Version Downgrade . . . . . . . . . . . . . 55 102 8.4. Threat: Transport Security Stripping . . . . . . . . . . 55 103 8.5. Threat: Weak TLS Configurations . . . . . . . . . . . . . 56 104 8.6. Threat: Untrusted End-Entity Certificate . . . . . . . . 56 105 8.7. Threat: Certificate Validation Vulnerabilities . . . . . 56 106 8.8. Threat: Symmetric Key Limits . . . . . . . . . . . . . . 57 107 8.9. Threat: BP Node Impersonation . . . . . . . . . . . . . . 57 108 8.10. Threat: Denial of Service . . . . . . . . . . . . . . . . 57 109 8.11. Alternate Uses of TLS . . . . . . . . . . . . . . . . . . 58 110 8.11.1. TLS Without Authentication . . . . . . . . . . . . . 59 111 8.11.2. Non-Certificate TLS Use . . . . . . . . . . . . . . 59 112 8.12. Predictability of Transfer IDs . . . . . . . . . . . . . 59 113 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 114 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 60 115 9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 60 116 9.3. Session Extension Types . . . . . . . . . . . . . . . . . 61 117 9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 62 118 9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 63 119 9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 64 120 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 65 121 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 66 122 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 67 123 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 67 124 11.1. Normative References . . . . . . . . . . . . . . . . . . 67 125 11.2. Informative References . . . . . . . . . . . . . . . . . 69 126 Appendix A. Significant changes from RFC7242 . . . . . . . . . . 71 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 129 1. Introduction 131 This document describes the TCP-based convergence-layer protocol for 132 Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to- 133 end architecture providing communications in and/or through highly 134 stressed environments, including those with intermittent 135 connectivity, long and/or variable delays, and high bit error rates. 136 More detailed descriptions of the rationale and capabilities of these 137 networks can be found in "Delay-Tolerant Network Architecture" 138 [RFC4838]. 140 An important goal of the DTN architecture is to accommodate a wide 141 range of networking technologies and environments. The protocol used 142 for DTN communications is the Bundle Protocol Version 7 (BPv7) 143 [I-D.ietf-dtn-bpbis], an application-layer protocol that is used to 144 construct a store-and-forward overlay network. BPv7 requires the 145 services of a "convergence-layer adapter" (CLA) to send and receive 146 bundles using the service of some "native" link, network, or Internet 147 protocol. This document describes one such convergence-layer adapter 148 that uses the well-known Transmission Control Protocol (TCP). This 149 convergence layer is referred to as TCP Convergence Layer Version 4 150 (TCPCLv4). For the remainder of this document, the abbreviation "BP" 151 without the version suffix refers to BPv7. For the remainder of this 152 document, the abbreviation "TCPCL" without the version suffix refers 153 to TCPCLv4. 155 The locations of the TCPCL and the BP in the Internet model protocol 156 stack (described in [RFC1122]) are shown in Figure 1. In particular, 157 when BP is using TCP as its bearer with TCPCL as its convergence 158 layer, both BP and TCPCL reside at the application layer of the 159 Internet model. 161 +-------------------------+ 162 | DTN Application | -\ 163 +-------------------------| | 164 | Bundle Protocol (BP) | -> Application Layer 165 +-------------------------+ | 166 | TCP Conv. Layer (TCPCL) | | 167 +-------------------------+ | 168 | TLS (optional) | -/ 169 +-------------------------+ 170 | TCP | ---> Transport Layer 171 +-------------------------+ 172 | IPv4/IPv6 | ---> Network Layer 173 +-------------------------+ 174 | Link-Layer Protocol | ---> Link Layer 175 +-------------------------+ 177 Figure 1: The Locations of the Bundle Protocol and the TCP 178 Convergence-Layer Protocol above the Internet Protocol Stack 180 1.1. Scope 182 This document describes the format of the protocol data units passed 183 between entities participating in TCPCL communications. This 184 document does not address: 186 * The format of protocol data units of the Bundle Protocol, as those 187 are defined elsewhere in [I-D.ietf-dtn-bpbis]. This includes the 188 concept of bundle fragmentation or bundle encapsulation. The 189 TCPCL transfers bundles as opaque data blocks. 191 * Mechanisms for locating or identifying other bundle entities 192 (peers) within a network or across an internet. The mapping of 193 Node ID to potential convergence layer (CL) protocol and network 194 address is left to implementation and configuration of the BP 195 Agent and its various potential routing strategies. 197 * Logic for routing bundles along a path toward a bundle's endpoint. 198 This CL protocol is involved only in transporting bundles between 199 adjacent entities in a routing sequence. 201 * Policies or mechanisms for issuing Public Key Infrastructure Using 202 X.509 (PKIX) certificates; provisioning, deploying, or accessing 203 certificates and private keys; deploying or accessing certificate 204 revocation lists (CRLs); or configuring security parameters on an 205 individual entity or across a network. 207 * Uses of TLS which are not based on PKIX certificate authentication 208 (see Section 8.11.2) or in which authentication of both entities 209 is not possible (see Section 8.11.1). 211 Any TCPCL implementation requires a BP agent to perform those above 212 listed functions in order to perform end-to-end bundle delivery. 214 2. Requirements Language 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 218 "OPTIONAL" in this document are to be interpreted as described in BCP 219 14 [RFC2119] [RFC8174] when, and only when, they appear in all 220 capitals, as shown here. 222 2.1. Definitions Specific to the TCPCL Protocol 224 This section contains definitions specific to the TCPCL protocol. 226 Network Byte Order: Most significant byte first, a.k.a., big endian. 227 All of the integer encodings in this protocol SHALL be transmitted 228 in network byte order. 230 TCPCL Entity: This is the notional TCPCL application that initiates 231 TCPCL sessions. This design, implementation, configuration, and 232 specific behavior of such an entity is outside of the scope of 233 this document. However, the concept of an entity has utility 234 within the scope of this document as the container and initiator 235 of TCPCL sessions. The relationship between a TCPCL entity and 236 TCPCL sessions is defined as follows: 238 * A TCPCL Entity MAY actively initiate any number of TCPCL 239 Sessions and should do so whenever the entity is the initial 240 transmitter of information to another entity in the network. 242 * A TCPCL Entity MAY support zero or more passive listening 243 elements that listen for connection requests from other TCPCL 244 Entities operating on other entities in the network. 246 * A TCPCL Entity MAY passively initiate any number of TCPCL 247 Sessions from requests received by its passive listening 248 element(s) if the entity uses such elements. 250 These relationships are illustrated in Figure 2. For most TCPCL 251 behavior within a session, the two entities are symmetric and 252 there is no protocol distinction between them. Some specific 253 behavior, particularly during session establishment, distinguishes 254 between the active entity and the passive entity. For the 255 remainder of this document, the term "entity" without the prefix 256 "TCPCL" refers to a TCPCL entity. 258 TCP Connection: The term Connection in this specification 259 exclusively refers to a TCP connection and any and all behaviors, 260 sessions, and other states associated with that TCP connection. 262 TCPCL Session: A TCPCL session (as opposed to a TCP connection) is a 263 TCPCL communication relationship between two TCPCL entities. A 264 TCPCL session operates within a single underlying TCP connection 265 and the lifetime of a TCPCL session is bound to the lifetime of 266 that TCP connection. A TCPCL session is terminated when the TCP 267 connection ends, due either to one or both entities actively 268 closing the TCP connection or due to network errors causing a 269 failure of the TCP connection. Within a single TCPCL session 270 there are two possible transfer streams; one in each direction, 271 with one stream from each entity being the outbound stream and the 272 other being the inbound stream (see Figure 3). From the 273 perspective of a TCPCL session, the two transfer streams do not 274 logically interact with each other. The streams do operate over 275 the same TCP connection and between the same BP agents, so there 276 are logical relationships at those layers (message and bundle 277 interleaving respectively). For the remainder of this document, 278 the term "session" without the prefix "TCPCL" refers to a TCPCL 279 session. 281 Session parameters: These are a set of values used to affect the 282 operation of the TCPCL for a given session. The manner in which 283 these parameters are conveyed to the bundle entity and thereby to 284 the TCPCL is implementation dependent. However, the mechanism by 285 which two entities exchange and negotiate the values to be used 286 for a given session is described in Section 4.3. 288 Transfer Stream: A Transfer stream is a uni-directional user-data 289 path within a TCPCL Session. Transfers sent over a transfer 290 stream are serialized, meaning that one transfer must complete its 291 transmission prior to another transfer being started over the same 292 transfer stream. At the stream layer there is no logical 293 relationship between transfers in that stream; it's only within 294 the BP agent that transfers are fully decoded as bundles. Each 295 uni-directional stream has a single sender entity and a single 296 receiver entity. 298 Transfer: This refers to the procedures and mechanisms for 299 conveyance of an individual bundle from one node to another. Each 300 transfer within TCPCL is identified by a Transfer ID number which 301 is guaranteed to be unique only to a single direction within a 302 single Session. 304 Transfer Segment: A subset of a transfer of user data being 305 communicated over a transfer stream. 307 Idle Session: A TCPCL session is idle while there is no transmission 308 in-progress in either direction. While idle, the only messages 309 being transmitted or received are KEEPALIVE messages. 311 Live Session: A TCPCL session is live while there is a transmission 312 in-progress in either direction. 314 Reason Codes: The TCPCL uses numeric codes to encode specific 315 reasons for individual failure/error message types. 317 The relationship between connections, sessions, and streams is shown 318 in Figure 3. 320 +--------------------------------------------+ 321 | TCPCL Entity | 322 | | +----------------+ 323 | +--------------------------------+ | | |-+ 324 | | Actively Initiated Session #1 +------------->| Other | | 325 | +--------------------------------+ | | TCPCL Entity's | | 326 | ... | | Passive | | 327 | +--------------------------------+ | | Listener | | 328 | | Actively Initiated Session #n +------------->| | | 329 | +--------------------------------+ | +----------------+ | 330 | | +-----------------+ 331 | +---------------------------+ | 332 | +---| +---------------------------+ | +----------------+ 333 | | | | Optional Passive | | | |-+ 334 | | +-| Listener(s) +<-------------+ | | 335 | | +---------------------------+ | | | | 336 | | | | Other | | 337 | | +---------------------------------+ | | TCPCL Entity's | | 338 | +--->| Passively Initiated Session #1 +-------->| Active | | 339 | | +---------------------------------+ | | Initiator(s) | | 340 | | | | | | 341 | | +---------------------------------+ | | | | 342 | +--->| Passively Initiated Session #n +-------->| | | 343 | +---------------------------------+ | +----------------+ | 344 | | +-----------------+ 345 +--------------------------------------------+ 347 Figure 2: The relationships between TCPCL entities 349 +---------------------------+ +---------------------------+ 350 | "Own" TCPCL Session | | "Other" TCPCL Session | 351 | | | | 352 | +----------------------+ | | +----------------------+ | 353 | | TCP Connection | | | | TCP Connection | | 354 | | | | | | | | 355 | | +-----------------+ | | Messages | | +-----------------+ | | 356 | | | Own Inbound | +--------------------+ | Peer Outbound | | | 357 | | | Transfer Stream | | Transfer Stream | | | 358 | | | ----- |<---[Seg]--[Seg]--[Seg]---| ----- | | | 359 | | | RECEIVER |---[Ack]----[Ack]-------->| SENDER | | | 360 | | +-----------------+ +-----------------+ | | 361 | | | | 362 | | +-----------------+ +-----------------+ | | 363 | | | Own Outbound |-------[Seg]---[Seg]----->| Peer Inbound | | | 364 | | | Transfer Stream |<---[Ack]----[Ack]-[Ack]--| Transfer Stream | | | 365 | | | ----- | | ----- | | | 366 | | | SENDER | +--------------------+ | RECEIVER | | | 367 | | +-----------------+ | | | | +-----------------+ | | 368 | +-----------------------+ | | +---------------------+ | 369 +----------------------------+ +--------------------------+ 371 Figure 3: The relationship within a TCPCL Session of its two streams 373 3. General Protocol Description 375 The service of this protocol is the transmission of DTN bundles via 376 the Transmission Control Protocol (TCP). This document specifies the 377 encapsulation of bundles, procedures for TCP setup and teardown, and 378 a set of messages and entity requirements. The general operation of 379 the protocol is as follows. 381 3.1. Convergence Layer Services 383 This version of the TCPCL provides the following services to support 384 the overlaying Bundle Protocol agent. In all cases, this is not an 385 API definition but a logical description of how the CL can interact 386 with the BP agent. Each of these interactions can be associated with 387 any number of additional metadata items as necessary to support the 388 operation of the CL or BP agent. 390 Attempt Session: The TCPCL allows a BP agent to preemptively attempt 391 to establish a TCPCL session with a peer entity. Each session 392 attempt can send a different set of session negotiation parameters 393 as directed by the BP agent. 395 Terminate Session: The TCPCL allows a BP agent to preemptively 396 terminate an established TCPCL session with a peer entity. The 397 terminate request is on a per-session basis. 399 Session State Changed: The TCPCL entity indicates to the BP agent 400 when the session state changes. The top-level session states 401 indicated are: 403 Connecting: A TCP connection is being established. This state 404 only applies to the active entity. 406 Contact Negotiating: A TCP connection has been made (as either 407 active or passive entity) and contact negotiation has begun. 409 Session Negotiating: Contact negotiation has been completed 410 (including possible TLS use) and session negotiation has begun. 412 Established: The session has been fully established and is ready 413 for its first transfer. 415 Ending: The entity sent SESS_TERM message and is in the ending 416 state. 418 Terminated: The session has finished normal termination 419 sequencing. 421 Failed: The session ended without normal termination sequencing. 423 Session Idle Changed: The TCPCL entity indicates to the BP agent 424 when the live/idle sub-state of the session changes. This occurs 425 only when the top-level session state is "Established". The 426 session transitions from Idle to Live at the at the start of a 427 transfer in either transfer stream; the session transitions from 428 Live to Idle at the end of a transfer when the other transfer 429 stream does not have an ongoing transfer. Because TCPCL transmits 430 serially over a TCP connection it suffers from "head of queue 431 blocking," so a transfer in either direction can block an 432 immediate start of a new transfer in the session. 434 Begin Transmission: The principal purpose of the TCPCL is to allow a 435 BP agent to transmit bundle data over an established TCPCL 436 session. Transmission request is on a per-session basis and the 437 CL does not necessarily perform any per-session or inter-session 438 queueing. Any queueing of transmissions is the obligation of the 439 BP agent. 441 Transmission Success: The TCPCL entity indicates to the BP agent 442 when a bundle has been fully transferred to a peer entity. 444 Transmission Intermediate Progress: The TCPCL entity indicates to 445 the BP agent on intermediate progress of transfer to a peer 446 entity. This intermediate progress is at the granularity of each 447 transferred segment. 449 Transmission Failure: The TCPCL entity indicates to the BP agent on 450 certain reasons for bundle transmission failure, notably when the 451 peer entity rejects the bundle or when a TCPCL session ends before 452 transfer success. The TCPCL itself does not have a notion of 453 transfer timeout. 455 Reception Initialized: The TCPCL entity indicates to the receiving 456 BP agent just before any transmission data is sent. This 457 corresponds to reception of the XFER_SEGMENT message with the 458 START flag of 1. 460 Interrupt Reception: The TCPCL entity allows a BP agent to interrupt 461 an individual transfer before it has fully completed (successfully 462 or not). Interruption can occur any time after the reception is 463 initialized. 465 Reception Success: The TCPCL entity indicates to the BP agent when a 466 bundle has been fully transferred from a peer entity. 468 Reception Intermediate Progress: The TCPCL entity indicates to the 469 BP agent on intermediate progress of transfer from the peer 470 entity. This intermediate progress is at the granularity of each 471 transferred segment. Intermediate reception indication allows a 472 BP agent the chance to inspect bundle header contents before the 473 entire bundle is available, and thus supports the "Reception 474 Interruption" capability. 476 Reception Failure: The TCPCL entity indicates to the BP agent on 477 certain reasons for reception failure, notably when the local 478 entity rejects an attempted transfer for some local policy reason 479 or when a TCPCL session ends before transfer success. The TCPCL 480 itself does not have a notion of transfer timeout. 482 3.2. TCPCL Session Overview 484 First, one entity establishes a TCPCL session to the other by 485 initiating a TCP connection in accordance with [RFC0793]. After 486 setup of the TCP connection is complete, an initial Contact Header is 487 exchanged in both directions to establish a shared TCPCL version and 488 negotiate the use of TLS security (as described in Section 4). Once 489 contact negotiation is complete, TCPCL messaging is available and the 490 session negotiation is used to set parameters of the TCPCL session. 491 One of these parameters is a Node ID that each TCPCL Entity is acting 492 as. This is used to assist in routing and forwarding messages by the 493 BP Agent and is part of the authentication capability provided by 494 TLS. 496 Once negotiated, the parameters of a TCPCL session cannot change and 497 if there is a desire by either peer to transfer data under different 498 parameters then a new session must be established. This makes CL 499 logic simpler but relies on the assumption that establishing a TCP 500 connection is lightweight enough that TCP connection overhead is 501 negligible compared to TCPCL data sizes. 503 Once the TCPCL session is established and configured in this way, 504 bundles can be transferred in either direction. Each transfer is 505 performed by segmenting the transfer data into one or more 506 XFER_SEGMENT messages. Multiple bundles can be transmitted 507 consecutively in a single direction on a single TCPCL connection. 508 Segments from different bundles are never interleaved. Bundle 509 interleaving can be accomplished by fragmentation at the BP layer or 510 by establishing multiple TCPCL sessions between the same peers. 511 There is no fundamental limit on the number of TCPCL sessions which a 512 single entity can establish beyond the limit imposed by the number of 513 available (ephemeral) TCP ports of the active entity. 515 A feature of this protocol is for the receiving entity to send 516 acknowledgment (XFER_ACK) messages as bundle data segments arrive. 517 The rationale behind these acknowledgments is to enable the 518 transmitting entity to determine how much of the bundle has been 519 received, so that in case the session is interrupted, it can perform 520 reactive fragmentation to avoid re-sending the already transmitted 521 part of the bundle. In addition, there is no explicit flow control 522 on the TCPCL layer. 524 A TCPCL receiver can interrupt the transmission of a bundle at any 525 point in time by replying with a XFER_REFUSE message, which causes 526 the sender to stop transmission of the associated bundle (if it 527 hasn't already finished transmission). Note: This enables a cross- 528 layer optimization in that it allows a receiver that detects that it 529 already has received a certain bundle to interrupt transmission as 530 early as possible and thus save transmission capacity for other 531 bundles. 533 For sessions that are idle, a KEEPALIVE message is sent at a 534 negotiated interval. This is used to convey entity live-ness 535 information during otherwise message-less time intervals. 537 A SESS_TERM message is used to initiate the ending of a TCPCL session 538 (see Section 6.1). During termination sequencing, in-progress 539 transfers can be completed but no new transfers can be initiated. A 540 SESS_TERM message can also be used to refuse a session setup by a 541 peer (see Section 4.3). Regardless of the reason, session 542 termination is initiated by one of the entities and responded-to by 543 the other as illustrated by Figure 13 and Figure 14. Even when there 544 are no transfers queued or in-progress, the session termination 545 procedure allows each entity to distinguish between a clean end to a 546 session and the TCP connection being closed because of some 547 underlying network issue. 549 Once a session is established, TCPCL is a symmetric protocol between 550 the peers. Both sides can start sending data segments in a session, 551 and one side's bundle transfer does not have to complete before the 552 other side can start sending data segments on its own. Hence, the 553 protocol allows for a bi-directional mode of communication. Note 554 that in the case of concurrent bidirectional transmission, 555 acknowledgment segments MAY be interleaved with data segments. 557 3.3. TCPCL States and Transitions 559 The states of a normal TCPCL session (i.e., without session failures) 560 are indicated in Figure 4. 562 +-------+ 563 | START | 564 +-------+ 565 | 566 TCP Establishment 567 | 568 V 569 +-----------+ +---------------------+ 570 | TCP |----------->| Contact / Session | 571 | Connected | | Negotiation | 572 +-----------+ +---------------------+ 573 | 574 +-----Session Parameters-----+ 575 | Negotiated 576 V 577 +-------------+ +-------------+ 578 | Established |----New Transfer---->| Established | 579 | Session | | Session | 580 | Idle |<---Transfers Done---| Live | 581 +-------------+ +-------------+ 582 | | 583 +------------------------------------+ 584 | 585 V 586 +-------------+ 587 | Established | +-------------+ 588 | Session |----Transfers------>| TCP | 589 | Ending | Done | Terminating | 590 +-------------+ +-------------+ 591 | 592 +----------TCP Close Message----------+ 593 | 594 V 595 +-------+ 596 | END | 597 +-------+ 599 Figure 4: Top-level states of a TCPCL session 601 Notes on Established Session states: 603 Session "Live" means transmitting or receiving over a transfer 604 stream. 606 Session "Idle" means no transmission/reception over a transfer 607 stream. 609 Session "Ending" means no new transfers will be allowed. 611 Contact negotiation involves exchanging a Contact Header (CH) in both 612 directions and deriving a negotiated state from the two headers. The 613 contact negotiation sequencing is performed either as the active or 614 passive entity, and is illustrated in Figure 5 and Figure 6 615 respectively which both share the data validation and negotiation of 616 the Processing of Contact Header "[PCH]" activity of Figure 7 and the 617 "[TCPCLOSE]" activity which indicates TCP connection close. 618 Successful negotiation results in one of the Session Initiation 619 "[SI]" activities being performed. To avoid data loss, a Session 620 Termination "[ST]" exchange allows cleanly finishing transfers before 621 a session is ended. 623 +-------+ 624 | START | 625 +-------+ 626 | 627 TCP Connecting 628 V 629 +-----------+ 630 | TCP | +---------+ 631 | Connected |--Send CH-->| Waiting |--Timeout-->[TCPCLOSE] 632 +-----------+ +---------+ 633 | 634 Received CH 635 V 636 [PCH] 638 Figure 5: Contact Initiation as Active Entity 640 +-----------+ +---------+ 641 | TCP |--Wait for-->| Waiting |--Timeout-->[TCPCLOSE] 642 | Connected | CH +---------+ 643 +-----------+ | 644 Received CH 645 V 646 +-----------------+ 647 | Preparing reply |--Send CH-->[PCH] 648 +-----------------+ 650 Figure 6: Contact Initiation as Passive Entity 651 +-----------+ 652 | Peer CH | 653 | available | 654 +-----------+ 655 | 656 Validate and 657 Negotiate 658 V 659 +------------+ 660 | Negotiated |--Failure-->[TCPCLOSE] 661 +------------+ 662 | | 663 No TLS +----Negotiate---+ [ST] 664 | TLS | ^ 665 V | Failure 666 +-----------+ V | 667 | TCPCL | +---------------+ 668 | Messaging |<--Success--| TLS Handshake | 669 | Available | +---------------+ 670 +-----------+ 672 Figure 7: Processing of Contact Header [PCH] 674 Session negotiation involves exchanging a session initialization 675 (SESS_INIT) message in both directions and deriving a negotiated 676 state from the two messages. The session negotiation sequencing is 677 performed either as the active or passive entity, and is illustrated 678 in Figure 8 and Figure 9 respectively which both share the data 679 validation and negotiation of Figure 10. The validation here 680 includes certificate validation and authentication when TLS is used 681 for the session. 683 +-----------+ 684 | TCPCL | +---------+ 685 | Messaging |--Send SESS_INIT-->| Waiting |--Timeout-->[ST] 686 | Available | +---------+ 687 +-----------+ | 688 Received SESS_INIT 689 | 690 V 691 [PSI] 693 Figure 8: Session Initiation [SI] as Active Entity 695 +-----------+ 696 | TCPCL | +---------+ 697 | Messaging |----Wait for ---->| Waiting |--Timeout-->[ST] 698 | Available | SESS_INIT +---------+ 699 +-----------+ | 700 Received SESS_INIT 701 | 702 +-----------------+ 703 | Preparing reply |--Send SESS_INIT-->[PSI] 704 +-----------------+ 706 Figure 9: Session Initiation [SI] as Passive Entity 708 +----------------+ 709 | Peer SESS_INIT | 710 | available | 711 +----------------+ 712 | 713 Validate and 714 Negotiate 715 V 716 +------------+ 717 | Negotiated |---Failure--->[ST] 718 +------------+ 719 | 720 Success 721 V 722 +--------------+ 723 | Established | 724 | Session Idle | 725 +--------------+ 727 Figure 10: Processing of Session Initiation [PSI] 729 Transfers can occur after a session is established and it's not in 730 the Ending state. Each transfer occurs within a single logical 731 transfer stream between a sender and a receiver, as illustrated in 732 Figure 11 and Figure 12 respectively. 734 +--Send XFER_SEGMENT--+ 735 +--------+ | | 736 | Stream | +-------------+ | 737 | Idle |---Send XFER_SEGMENT-->| In Progress |<------------+ 738 +--------+ +-------------+ 739 | 740 +---------All segments sent-------+ 741 | 742 V 743 +---------+ +--------+ 744 | Waiting |---- Receive Final---->| Stream | 745 | for Ack | XFER_ACK | IDLE | 746 +---------+ +--------+ 748 Figure 11: Transfer sender states 750 Notes on transfer sending: 752 Pipelining of transfers can occur when the sending entity begins a 753 new transfer while in the "Waiting for Ack" state. 755 +-Receive XFER_SEGMENT-+ 756 +--------+ | Send XFER_ACK | 757 | Stream | +-------------+ | 758 | Idle |--Receive XFER_SEGMENT-->| In Progress |<-------------+ 759 +--------+ +-------------+ 760 | 761 +--------Sent Final XFER_ACK--------+ 762 | 763 V 764 +--------+ 765 | Stream | 766 | Idle | 767 +--------+ 769 Figure 12: Transfer receiver states 771 Session termination involves one entity initiating the termination of 772 the session and the other entity acknowledging the termination. For 773 either entity, it is the sending of the SESS_TERM message which 774 transitions the session to the Ending substate. While a session is 775 in the Ending state only in-progress transfers can be completed and 776 no new transfers can be started. 778 +-----------+ +---------+ 779 | Session |--Send SESS_TERM-->| Session | 780 | Live/Idle | | Ending | 781 +-----------+ +---------+ 783 Figure 13: Session Termination [ST] from the Initiator 785 +-----------+ +---------+ 786 | Session |--Send SESS_TERM-->| Session | 787 | Live/Idle | | Ending | 788 +-----------+<------+ +---------+ 789 | | 790 Receive SESS_TERM | 791 | | 792 +-------------+ 794 Figure 14: Session Termination [ST] from the Responder 796 3.4. PKIX Environments and CA Policy 798 This specification gives requirements about how to use PKIX 799 certificates issued by a Certificate Authority (CA), but does not 800 define any mechanisms for how those certificates come to be. The 801 requirements about TCPCL certificate use are broad to support two 802 quite different PKIX environments: 804 DTN-Aware CAs: In the ideal case, the CA(s) issuing certificates for 805 TCPCL entities are aware of the end use of the certificate, have a 806 mechanism for verifying ownership of a Node ID, and are issuing 807 certificates directly for that Node ID. In this environment, the 808 ability to authenticate a peer entity Node ID directly avoids the 809 need to authenticate a network name or address and then implicitly 810 trust Node ID of the peer. The TCPCL authenticates the Node ID 811 whenever possible and this is preferred over lower-level PKIX 812 identifiers. 814 DTN-Ignorant CAs: It is expected that Internet-scale "public" CAs 815 will continue to focus on DNS names as the preferred PKIX 816 identifier. There are large infrastructures already in-place for 817 managing network-level authentication and protocols to manage 818 identity verification in those environments [RFC8555]. The TCPCL 819 allows for this type of environment by authenticating a lower- 820 level identifier for a peer and requiring the entity to trust that 821 the Node ID given by the peer (during session initialization) is 822 valid. This situation not ideal, as it allows vulnerabilities 823 described in Section 8.9, but still provides some amount of mutual 824 authentication to take place for a TCPCL session. 826 Even within a single TCPCL session, each entity may operate within 827 different PKI environments and with different identifier limitations. 828 The requirements related to identifiers in in a PKIX certificate are 829 in Section 4.4.1. 831 It is important for interoperability that a TCPCL entity have its own 832 security policy tailored to accommodate the peers with which it is 833 expected to operate. A strict TLS security policy is appropriate for 834 a private network with a single shared CA. Operation on the Internet 835 (such as inter-site BP gateways) could trade more lax TCPCL security 836 with the use of encrypted bundle encapsulation [I-D.ietf-dtn-bibect] 837 to ensure strong bundle security. 839 3.5. Session Keeping Policies 841 This specification gives requirements about how to initiate, sustain, 842 and terminate a TCPCL session but does not impose any requirements on 843 how sessions need to be managed by a BP agent. It is a network 844 administration matter to determine an appropriate session keeping 845 policy, but guidance given here can be used to steer policy toward 846 performance goals. 848 Persistent Session: This policy preemptively establishes a single 849 session to known entities in the network and keeps the session 850 active using KEEPALIVEs. Benefits of this policy include reducing 851 the total amount of TCP data needing to be exchanged for a set of 852 transfers (assuming KEEPALIVE size is significantly smaller than 853 transfer size), and allowing the session state to indicate peer 854 connectivity. Drawbacks include wasted network resources when a 855 session is mostly idle or when the network connectivity is 856 inconsistent (which requires re-establishing failed sessions), and 857 potential queueing issues when multiple transfers are requested 858 simultaneously. This policy assumes that there is agreement 859 between pairs of entities as to which of the peers will initiate 860 sessions; if there is no such agreement, there is potential for 861 duplicate sessions to be established between peers. 863 Ephemeral Sessions: This policy only establishes a session when an 864 outgoing transfer is needed to be sent. Benefits of this policy 865 include not wasting network resources on sessions which are idle 866 for long periods of time, and avoids queueing issues of a 867 persistent session. Drawbacks include the TCP and TLS overhead of 868 establish a new session for each transfer. This policy assumes 869 that each entity can function in a passive role to listen for 870 session requests from any peer which needs to send a transfer; 871 when that is not the case the Polling behavior below needs to 872 happen. This policy can be augmented to keep the session 873 established as long as any transfers are queued. 875 Active-Only Polling Sessions: When naming and/or addressing of one 876 entity is variable (i.e. dynamically assigned IP address or domain 877 name) or when firewall or routing rules prevent incoming TCP 878 connections, that entity can only function in the active role. In 879 these cases, sessions also need to be established when an incoming 880 transfer is expected from a peer or based on a periodic schedule. 881 This polling behavior causes inefficiencies compared to as-needed 882 ephemeral sessions. 884 Many other policies can be established in a TCPCL network between the 885 two extremes of single persistent sessions and only ephemeral 886 sessions. Different policies can be applied to each peer entity and 887 to each bundle as it needs to be transferred (e.g for quality of 888 service). Additionally, future session extension types can apply 889 further nuance to session policies and policy negotiation. 891 3.6. Transfer Segmentation Policies 893 Each TCPCL session allows a negotiated transfer segmentation policy 894 to be applied in each transfer direction. A receiving entity can set 895 the Segment MRU in its SESS_INIT message to determine the largest 896 acceptable segment size, and a transmitting entity can segment a 897 transfer into any sizes smaller than the receiver's Segment MRU. It 898 is a network administration matter to determine an appropriate 899 segmentation policy for entities operating TCPCL, but guidance given 900 here can be used to steer policy toward performance goals. It is 901 also advised to consider the Segment MRU in relation to chunking/ 902 packetization performed by TLS, TCP, and any intermediate network- 903 layer nodes. 905 Minimum Overhead: For a simple network expected to exchange 906 relatively small bundles, the Segment MRU can be set to be 907 identical to the Transfer MRU which indicates that all transfers 908 can be sent with a single data segment (i.e., no actual 909 segmentation). If the network is closed and all transmitters are 910 known to follow a single-segment transfer policy, then receivers 911 can avoid the necessity of segment reassembly. Because this CL 912 operates over a TCP stream, which suffers from a form of head-of- 913 queue blocking between messages, while one entity is transmitting 914 a single XFER_SEGMENT message it is not able to transmit any 915 XFER_ACK or XFER_REFUSE for any associated received transfers. 917 Predictable Message Sizing: In situations where the maximum message 918 size is desired to be well-controlled, the Segment MRU can be set 919 to the largest acceptable size (the message size less XFER_SEGMENT 920 header size) and transmitters can always segment a transfer into 921 maximum-size chunks no larger than the Segment MRU. This 922 guarantees that any single XFER_SEGMENT will not monopolize the 923 TCP stream for too long, which would prevent outgoing XFER_ACK and 924 XFER_REFUSE associated with received transfers. 926 Dynamic Segmentation: Even after negotiation of a Segment MRU for 927 each receiving entity, the actual transfer segmentation only needs 928 to guarantee than any individual segment is no larger than that 929 MRU. In a situation where TCP throughput is dynamic, the transfer 930 segmentation size can also be dynamic in order to control message 931 transmission duration. 933 Many other policies can be established in a TCPCL network between the 934 two extremes of minimum overhead (large MRU, single-segment) and 935 predictable message sizing (small MRU, highly segmented). Different 936 policies can be applied to each transfer stream to and from any 937 particular entity. Additionally, future session extension and 938 transfer extension types can apply further nuance to transfer 939 policies and policy negotiation. 941 3.7. Example Message Exchange 943 The following figure depicts the protocol exchange for a simple 944 session, showing the session establishment and the transmission of a 945 single bundle split into three data segments (of lengths "L1", "L2", 946 and "L3") from Entity A to Entity B. 948 Note that the sending entity can transmit multiple XFER_SEGMENT 949 messages without waiting for the corresponding XFER_ACK responses. 950 This enables pipelining of messages on a transfer stream. Although 951 this example only demonstrates a single bundle transmission, it is 952 also possible to pipeline multiple XFER_SEGMENT messages for 953 different bundles without necessarily waiting for XFER_ACK messages 954 to be returned for each one. However, interleaving data segments 955 from different bundles is not allowed. 957 No errors or rejections are shown in this example. 959 Entity A Entity B 960 ======== ======== 961 +-------------------------+ 962 | Open TCP Connection | -> +-------------------------+ 963 +-------------------------+ <- | Accept Connection | 964 +-------------------------+ 965 +-------------------------+ 966 | Contact Header | -> +-------------------------+ 967 +-------------------------+ <- | Contact Header | 968 +-------------------------+ 969 +-------------------------+ 970 | SESS_INIT | -> +-------------------------+ 971 +-------------------------+ <- | SESS_INIT | 972 +-------------------------+ 974 +-------------------------+ 975 | XFER_SEGMENT (start) | -> 976 | Transfer ID [I1] | 977 | Length [L1] | 978 | Bundle Data 0..(L1-1) | 979 +-------------------------+ 980 +-------------------------+ +-------------------------+ 981 | XFER_SEGMENT | -> <- | XFER_ACK (start) | 982 | Transfer ID [I1] | | Transfer ID [I1] | 983 | Length [L2] | | Length [L1] | 984 |Bundle Data L1..(L1+L2-1)| +-------------------------+ 985 +-------------------------+ 986 +-------------------------+ +-------------------------+ 987 | XFER_SEGMENT (end) | -> <- | XFER_ACK | 988 | Transfer ID [I1] | | Transfer ID [I1] | 989 | Length [L3] | | Length [L1+L2] | 990 |Bundle Data | +-------------------------+ 991 | (L1+L2)..(L1+L2+L3-1)| 992 +-------------------------+ 993 +-------------------------+ 994 <- | XFER_ACK (end) | 995 | Transfer ID [I1] | 996 | Length [L1+L2+L3] | 997 +-------------------------+ 999 +-------------------------+ 1000 | SESS_TERM | -> +-------------------------+ 1001 +-------------------------+ <- | SESS_TERM | 1002 +-------------------------+ 1003 +-------------------------+ +-------------------------+ 1004 | TCP Close | -> <- | TCP Close | 1005 +-------------------------+ +-------------------------+ 1006 Figure 15: An example of the flow of protocol messages on a 1007 single TCP Session between two entities 1009 4. Session Establishment 1011 For bundle transmissions to occur using the TCPCL, a TCPCL session 1012 MUST first be established between communicating entities. It is up 1013 to the implementation to decide how and when session setup is 1014 triggered. For example, some sessions can be opened proactively and 1015 maintained for as long as is possible given the network conditions, 1016 while other sessions are be opened only when there is a bundle that 1017 is queued for transmission and the routing algorithm selects a 1018 certain next-hop node. 1020 4.1. TCP Connection 1022 To establish a TCPCL session, an entity MUST first establish a TCP 1023 connection with the intended peer entity, typically by using the 1024 services provided by the operating system. Destination port number 1025 4556 has been assigned by IANA as the Registered Port number for the 1026 TCP convergence layer. Other destination port numbers MAY be used 1027 per local configuration. Determining a peer's destination port 1028 number (if different from the registered TCPCL port number) is up to 1029 the implementation. Any source port number MAY be used for TCPCL 1030 sessions. Typically an operating system assigned number in the TCP 1031 Ephemeral range (49152-65535) is used. 1033 If the entity is unable to establish a TCP connection for any reason, 1034 then it is an implementation matter to determine how to handle the 1035 connection failure. An entity MAY decide to re-attempt to establish 1036 the connection. If it does so, it MUST NOT overwhelm its target with 1037 repeated connection attempts. Therefore, the entity MUST NOT retry 1038 the connection setup earlier than some delay time from the last 1039 attempt, and it SHOULD use a (binary) exponential back-off mechanism 1040 to increase this delay in case of repeated failures. The upper limit 1041 on a re-attempt back-off is implementation defined but SHOULD be no 1042 longer than one minute (60 seconds) before signaling to the BP agent 1043 that a connection cannot be made. 1045 Once a TCP connection is established, the active entity SHALL 1046 immediately transmit its Contact Header. Once a TCP connection is 1047 established, the passive entity SHALL wait for the peer's Contact 1048 Header. If the passive entity does not receive a Contact Header 1049 after some implementation-defined time duration after TCP connection 1050 is established, the entity SHALL close the TCP connection. Entities 1051 SHOULD choose a Contact Header reception timeout interval no longer 1052 than one minute (60 seconds). Upon reception of a Contact Header, 1053 the passive entity SHALL transmit its Contact Header. The ordering 1054 of the Contact Header exchange allows the passive entity to avoid 1055 allocating resources to a potential TCPCL session until after a valid 1056 Contact Header has been received from the active entity. This 1057 ordering also allows the passive peer to adapt to alternate TCPCL 1058 protocol versions. 1060 The format of the Contact Header is described in Section 4.2. 1061 Because the TCPCL protocol version in use is part of the initial 1062 Contact Header, entities using TCPCL version 4 can coexist on a 1063 network with entities using earlier TCPCL versions (with some 1064 negotiation needed for interoperation as described in Section 4.3). 1066 Within this specification when an entity is said to "close" a TCP 1067 connection the entity SHALL use the TCP FIN mechanism and not the RST 1068 mechanism. Either mechanism, however, when received will cause a TCP 1069 connection to become closed. 1071 4.2. Contact Header 1073 This section describes the format of the Contact Header and the 1074 meaning of its fields. 1076 If an entity is capable of exchanging messages according to TLS 1.3 1077 [RFC8446] or any successors which are compatible with that TLS 1078 ClientHello, the the CAN_TLS flag within its Contact Header SHALL be 1079 set to 1. This behavior prefers the use of TLS when possible, even 1080 if security policy does not allow or require authentication. This 1081 follows the opportunistic security model of [RFC7435], though an 1082 active attacker could interfere with the exchange in such cases. 1084 Upon receipt of the Contact Header, both entities perform the 1085 validation and negotiation procedures defined in Section 4.3. After 1086 receiving the Contact Header from the other entity, either entity MAY 1087 refuse the session by sending a SESS_TERM message with an appropriate 1088 reason code. 1090 The format for the Contact Header is as follows: 1092 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1093 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 1094 +---------------+---------------+---------------+---------------+ 1095 | magic='dtn!' | 1096 +---------------+---------------+---------------+---------------+ 1097 | Version | Flags | 1098 +---------------+---------------+ 1100 Figure 16: Contact Header Format 1102 See Section 4.3 for details on the use of each of these Contact 1103 Header fields. 1105 The fields of the Contact Header are: 1107 magic: A four-octet field that always contains the octet sequence 1108 0x64 0x74 0x6E 0x21, i.e., the text string "dtn!" in US-ASCII (and 1109 UTF-8). 1111 Version: A one-octet field value containing the value 4 (current 1112 version of the TCPCL). 1114 Flags: A one-octet field of single-bit flags, interpreted according 1115 to the descriptions in Table 1. All reserved header flag bits 1116 SHALL be set to 0 by the sender. All reserved header flag bits 1117 SHALL be ignored by the receiver. 1119 +==========+========+==========================================+ 1120 | Name | Code | Description | 1121 +==========+========+==========================================+ 1122 | CAN_TLS | 0x01 | If bit is set, indicates that the | 1123 | | | sending peer is capable of TLS security. | 1124 +----------+--------+------------------------------------------+ 1125 | Reserved | others | | 1126 +----------+--------+------------------------------------------+ 1128 Table 1: Contact Header Flags 1130 4.3. Contact Validation and Negotiation 1132 Upon reception of the Contact Header, each entity follows the 1133 following procedures to ensure the validity of the TCPCL session and 1134 to negotiate values for the session parameters. 1136 If the magic string is not present or is not valid, the connection 1137 MUST be terminated. The intent of the magic string is to provide 1138 some protection against an inadvertent TCP connection by a different 1139 protocol than the one described in this document. To prevent a flood 1140 of repeated connections from a misconfigured application, a passive 1141 entity MAY deny new TCP connections from a specific peer address for 1142 a period of time after one or more connections fail to provide a 1143 decodable Contact Header. 1145 The first negotiation is on the TCPCL protocol version to use. The 1146 active entity always sends its Contact Header first and waits for a 1147 response from the passive entity. During contact initiation, the 1148 active TCPCL entity SHALL send the highest TCPCL protocol version on 1149 a first session attempt for a TCPCL peer. If the active entity 1150 receives a Contact Header with a lower protocol version than the one 1151 sent earlier on the TCP connection, the TCP connection SHALL be 1152 closed. If the active entity receives a SESS_TERM message with 1153 reason of "Version Mismatch", that entity MAY attempt further TCPCL 1154 sessions with the peer using earlier protocol version numbers in 1155 decreasing order. Managing multi-TCPCL-session state such as this is 1156 an implementation matter. 1158 If the passive entity receives a Contact Header containing a version 1159 that is not a version of the TCPCL that the entity implements, then 1160 the entity SHALL send its Contact Header and immediately terminate 1161 the session with a reason code of "Version mismatch". If the passive 1162 entity receives a Contact Header with a version that is lower than 1163 the latest version of the protocol that the entity implements, the 1164 entity MAY either terminate the session (with a reason code of 1165 "Version mismatch") or adapt its operation to conform to the older 1166 version of the protocol. The decision of version fall-back is an 1167 implementation matter. 1169 The negotiated contact parameters defined by this specification are 1170 described in the following paragraphs. 1172 TCPCL Version: Both Contact Headers of a successful contact 1173 negotiation have identical TCPCL Version numbers as described 1174 above. Only upon response of a Contact Header from the passive 1175 entity is the TCPCL protocol version established and session 1176 negotiation begun. 1178 Enable TLS: Negotiation of the Enable TLS parameter is performed by 1179 taking the logical AND of the two Contact Headers' CAN_TLS flags. 1180 A local security policy is then applied to determine of the 1181 negotiated value of Enable TLS is acceptable. It can be a 1182 reasonable security policy to require or disallow the use of TLS 1183 depending upon the desired network flows. Because this state is 1184 negotiated over an unsecured medium, there is a risk of a TLS 1185 Stripping as described in Section 8. If the Enable TLS state is 1186 unacceptable, the entity SHALL terminate the session with a reason 1187 code of "Contact Failure". Note that this contact failure reason 1188 is different than a failure of TLS handshake or TLS authentication 1189 after an agreed-upon and acceptable Enable TLS state. If the 1190 negotiated Enable TLS value is true and acceptable then TLS 1191 negotiation feature (described in Section 4.4) begins immediately 1192 following the Contact Header exchange. 1194 4.4. Session Security 1196 This version of the TCPCL supports establishing a Transport Layer 1197 Security (TLS) session within an existing TCP connection. When TLS 1198 is used within the TCPCL it affects the entire session. Once TLS is 1199 established, there is no mechanism available to downgrade the TCPCL 1200 session to non-TLS operation. 1202 Once established, the lifetime of a TLS connection SHALL be bound to 1203 the lifetime of the underlying TCP connection. Immediately prior to 1204 actively ending a TLS connection after TCPCL session termination, the 1205 peer which sent the original (non-reply) SESS_TERM message SHOULD 1206 follow the Closure Alert procedure of [RFC8446] to cleanly terminate 1207 the TLS connection. Because each TCPCL message is either fixed- 1208 length or self-indicates its length, the lack of a TLS Closure Alert 1209 will not cause data truncation or corruption. 1211 Subsequent TCPCL session attempts to the same passive entity MAY 1212 attempt use the TLS connection resumption feature. There is no 1213 guarantee that the passive entity will accept the request to resume a 1214 TLS session, and the active entity cannot assume any resumption 1215 outcome. 1217 4.4.1. Entity Identification 1219 The TCPCL uses TLS for certificate exchange in both directions to 1220 identify each entity and to allow each entity to authenticate its 1221 peer. Each certificate can potentially identify multiple entities 1222 and there is no problem using such a certificate as long as the 1223 identifiers are sufficient to meet authentication policy (as 1224 described in later sections) for the entity which presents it. 1226 Because the PKIX environment of each TCPCL entity are likely not 1227 controlled by the certificate end users (see Section 3.4), the TCPCL 1228 defines a prioritized list of what a certificate can identify about a 1229 TCPCL entity: 1231 Node ID: The ideal certificate identity is the Node ID of the entity 1232 using the NODE-ID definition below. When the Node ID is 1233 identified, there is no need for any lower-level identification to 1234 be present (though it can still be present, and if so it is also 1235 validated). 1237 DNS Name: If CA policy forbids a certificate to contain an arbitrary 1238 NODE-ID but allows a DNS-ID to be identified then one or more 1239 stable DNS names can be identified in the certificate. The use of 1240 wildcard DNS-ID is discouraged due to the complex rules for 1241 matching and dependence on implementation support for wildcard 1242 matching (see Section 6.4.3 of [RFC6125]). 1244 Network Address: If no stable DNS name is available but a stable 1245 network address is available and CA policy allows a certificate to 1246 contain a IPADDR-ID (as defined below) then one or more network 1247 addresses can be identified in the certificate. 1249 When only a DNS-ID or IPADDR-ID can be identified by a certificate, 1250 it is implied that an entity which authenticates using that 1251 certificate is trusted to provide a valid Node ID in its SESS_INIT; 1252 the certificate itself does not actually authenticate that Node ID. 1254 The RECOMMENDED security policy of an entity is to validate a NODE-ID 1255 when present, and only require DNS-ID/IPADDR-ID authentication in the 1256 absence of a NODE-ID. 1258 This specification defines a NODE-ID of a certificate as being the 1259 subjectAltName entry of type uniformResourceIdentifier whose value is 1260 a URI consistent with the requirements of [RFC3986] and the URI 1261 schemes of the IANA "Bundle Protocol URI Scheme Type" registry 1262 [IANA-BUNDLE]. This is similar to the URI-ID of [RFC6125] but does 1263 not require any structure to the scheme-specific-part of the URI. 1264 Unless specified otherwise by the definition of the URI scheme being 1265 authenticated, URI matching of a NODE-ID SHALL use the URI comparison 1266 logic of [RFC3986] and scheme-based normalization of those schemes 1267 specified in [I-D.ietf-dtn-bpbis]. A URI scheme can refine this 1268 "exact match" logic with rules about how Node IDs within that scheme 1269 are to be compared with the certificate-authenticated NODE-ID. 1271 This specification defines a IPADDR-ID of a certificate as being the 1272 subjectAltName entry of type iPAddress whose value is encoded 1273 according to [RFC5280]. 1275 4.4.2. TLS Handshake 1277 The use of TLS is negotiated using the Contact Header as described in 1278 Section 4.3. After negotiating an Enable TLS parameter of true, and 1279 before any other TCPCL messages are sent within the session, the 1280 session entities SHALL begin a TLS handshake in accordance with 1281 [RFC8446]. By convention, this protocol uses the entity which 1282 initiated the underlying TCP connection (the active peer) as the 1283 "client" role of the TLS handshake request. 1285 The TLS handshake, if it occurs, is considered to be part of the 1286 contact negotiation before the TCPCL session itself is established. 1287 Specifics about sensitive data exposure are discussed in Section 8. 1289 The parameters within each TLS negotiation are implementation 1290 dependent but any TCPCL entity SHALL follow all recommended practices 1291 of BCP 195 [RFC7525], or any updates or successors that become part 1292 of BCP 195. Within each TLS handshake, the following requirements 1293 apply (using the rough order in which they occur): 1295 Client Hello: When a resolved DNS name was used to establish the TCP 1296 connection, the TLS ClientHello SHOULD include a Server Name 1297 Indication (SNI) in accordance with [RFC6066]. When present, the 1298 "server_name" extension SHALL contain a "HostName" value taken 1299 from the DNS name (of the passive entity) which was resolved. 1300 Note: The 'HostName in the "server_name" extension is the network 1301 name for the passive entity, not the Node ID of that entity. 1303 Server Certificate: The passive entity SHALL supply a certificate 1304 within the TLS handshake to allow authentication of its side of 1305 the session. Unless prohibited by CA policy, the passive entity 1306 certificate SHALL contain a NODE-ID which authenticates the Node 1307 ID of the peer. When assigned a stable DNS name, the passive 1308 entity certificate SHOULD contain a DNS-ID which authenticates 1309 that (fully qualified) name. When assigned a stable network 1310 address, the passive entity certificate MAY contain a IPADDR-ID 1311 which authenticates that address. The passive entity MAY use the 1312 SNI DNS name to choose an appropriate server-side certificate 1313 which authenticates that DNS name. 1315 Certificate Request: During TLS handshake, the passive entity SHALL 1316 request a client-side certificate. 1318 Client Certificate: The active entity SHALL supply a certificate 1319 chain within the TLS handshake to allow authentication of its side 1320 of the session. Unless prohibited by CA policy, the active entity 1321 certificate SHALL contain a NODE-ID which authenticates the Node 1322 ID of the peer. When assigned a stable DNS name, the active 1323 entity certificate SHOULD contain a DNS-ID which authenticates 1324 that (fully qualified) name. When assigned a stable network 1325 address, the active entity certificate MAY contain a IPADDR-ID 1326 which authenticates that address. 1328 All certificates supplied during TLS handshake SHALL conform to 1329 [RFC5280], or any updates or successors to that profile. When a 1330 certificate is supplied during TLS handshake, the full certification 1331 chain SHOULD be included unless security policy indicates that is 1332 unnecessary. 1334 If a TLS handshake cannot negotiate a TLS connection, both entities 1335 of the TCPCL session SHALL close the TCP connection. At this point 1336 the TCPCL session has not yet been established so there is no TCPCL 1337 session to terminate. 1339 After a TLS connection is successfully established, the active entity 1340 SHALL send a SESS_INIT message to begin session negotiation. This 1341 session negotiation and all subsequent messaging are secured. 1343 4.4.3. TLS Authentication 1345 Using PKIX certificates exchanged during the TLS handshake, each of 1346 the entities can authenticate a peer Node ID directly or authenticate 1347 the peer DNS name or network address. The logic for handling 1348 certificates and certificate data is separated into three phases: 1350 1. Validating the certification path from the end-entity certificate 1351 up to a trusted root CA. 1353 2. Authenticating identities from a valid end-entity certificate. 1355 3. Applying security policy to the result of each identity type 1356 authentication. 1358 By using the SNI DNS name (see Section 4.4.2) a single passive entity 1359 can act as a convergence layer for multiple BP agents with distinct 1360 Node IDs. When this "virtual host" behavior is used, the DNS name is 1361 used as the indication of which BP Node the active entity is 1362 attempting to communicate with. A virtual host CL entity can be 1363 authenticated by a certificate containing all of the DNS names and/or 1364 Node IDs being hosted or by several certificates each authenticating 1365 a single DNS name and/or Node ID, using the SNI value from the peer 1366 to select which certificate to use. 1368 For any peer certificate received during TLS handshake, the entity 1369 SHALL perform the certification path validation of [RFC5280] up to 1370 one of the entity's trusted CA certificates. If certificate 1371 validation fails or if security policy disallows a certificate for 1372 any reason, the entity SHALL fail the TLS handshake with a bad 1373 certificate error. Leaving out part of the certification chain can 1374 cause the entity to fail to validate a certificate if the left-out 1375 certificates are unknown to the entity (see Section 8.6). 1377 The result of authenticating a peer identity (i.e., Node ID, DNS 1378 name, or IP address) against one type of certificate claim is one of: 1380 Absent: Indicating that no claims of that type are present in the 1381 certificate and the identity cannot be authenticated. 1383 Success: Indicating that one or more claims of that type are present 1384 and one matches the peer identity value. 1386 Failure: Indicating that one or more claims of that type are present 1387 and none match the peer identity. 1389 Either during or immediately after the TLS handshake if the active 1390 entity resolved a DNS name (of the passive entity) in order to 1391 initiate the TCP connection, the active entity SHALL authenticate 1392 that DNS name using any DNS-ID of the peer certificate. If the DNS 1393 name authentication result is Failure or if the result is Absent and 1394 security policy requires an authenticated DNS name, the entity SHALL 1395 terminate the session (with a reason code of "Contact Failure"). 1397 Either during or immediately after the TLS handshake, each side of 1398 the session SHALL authenticate the IP address of the other side of 1399 the TCP connection using any IPADDR-ID of the peer certificate. If 1400 the address authentication result is Failure or if the result is 1401 Absent and security policy requires an authenticated network address, 1402 the entity SHALL terminate the session (with a reason code of 1403 "Contact Failure"). 1405 Immediately before Session Parameter Negotiation, each side of the 1406 session SHALL authenticate the Node ID of the peer's SESS_INIT 1407 message using any NODE-ID of the peer certificate. If the Node ID 1408 authentication result is Failure or if the result is Absent and 1409 security policy requires an authenticated Node ID, the entity SHALL 1410 terminate the session (with a reason code of "Contact Failure"). 1412 4.4.4. Example TLS Initiation 1414 A summary of a typical TLS use is shown in the sequence in Figure 17 1415 below. In this example the active peer terminates the session but 1416 termination can be initiated from either peer. 1418 Entity A Entity B 1419 active peer passive peer 1421 +-------------------------+ 1422 | Open TCP Connection | -> +-------------------------+ 1423 +-------------------------+ <- | Accept Connection | 1424 +-------------------------+ 1425 +-------------------------+ 1426 | Contact Header | -> +-------------------------+ 1427 +-------------------------+ <- | Contact Header | 1428 +-------------------------+ 1430 +-------------------------+ +-------------------------+ 1431 | TLS Negotiation | -> <- | TLS Negotiation | 1432 | (as client) | | (as server) | 1433 +-------------------------+ +-------------------------+ 1435 DNS-ID and IPADDR-ID authentication occurs. 1436 Secured TCPCL messaging can begin. 1438 +-------------------------+ 1439 | SESS_INIT | -> +-------------------------+ 1440 +-------------------------+ <- | SESS_INIT | 1441 +-------------------------+ 1443 NODE-ID authentication occurs. 1444 Session is established, transfers can begin. 1446 +-------------------------+ 1447 | SESS_TERM | -> +-------------------------+ 1448 +-------------------------+ <- | SESS_TERM | 1449 +-------------------------+ 1450 +-------------------------+ 1451 | TLS Closure Alert | -> +-------------------------+ 1452 +-------------------------+ <- | TLS Closure Alert | 1453 +-------------------------+ 1454 +-------------------------+ +-------------------------+ 1455 | TCP Close | -> <- | TCP Close | 1456 +-------------------------+ +-------------------------+ 1458 Figure 17: A simple visual example of TCPCL TLS Establishment 1459 between two entities 1461 4.5. Message Header 1463 After the initial exchange of a Contact Header and (if TLS is 1464 negotiated to be used) the TLS handshake, all messages transmitted 1465 over the session are identified by a one-octet header with the 1466 following structure: 1468 0 1 2 3 4 5 6 7 1469 +---------------+ 1470 | Message Type | 1471 +---------------+ 1473 Figure 18: Format of the Message Header 1475 The message header fields are as follows: 1477 Message Type: Indicates the type of the message as per Table 2 1478 below. Encoded values are listed in Section 9.5. 1480 +==============+======+=====================================+ 1481 | Name | Code | Description | 1482 +==============+======+=====================================+ 1483 | SESS_INIT | 0x07 | Contains the session parameter | 1484 | | | inputs from one of the entities, as | 1485 | | | described in Section 4.6. | 1486 +--------------+------+-------------------------------------+ 1487 | SESS_TERM | 0x05 | Indicates that one of the entities | 1488 | | | participating in the session wishes | 1489 | | | to cleanly terminate the session, | 1490 | | | as described in Section 6.1. | 1491 +--------------+------+-------------------------------------+ 1492 | XFER_SEGMENT | 0x01 | Indicates the transmission of a | 1493 | | | segment of bundle data, as | 1494 | | | described in Section 5.2.2. | 1495 +--------------+------+-------------------------------------+ 1496 | XFER_ACK | 0x02 | Acknowledges reception of a data | 1497 | | | segment, as described in | 1498 | | | Section 5.2.3. | 1499 +--------------+------+-------------------------------------+ 1500 | XFER_REFUSE | 0x03 | Indicates that the transmission of | 1501 | | | the current bundle SHALL be | 1502 | | | stopped, as described in | 1503 | | | Section 5.2.4. | 1504 +--------------+------+-------------------------------------+ 1505 | KEEPALIVE | 0x04 | Used to keep TCPCL session active, | 1506 | | | as described in Section 5.1.1. | 1507 +--------------+------+-------------------------------------+ 1508 | MSG_REJECT | 0x06 | Contains a TCPCL message rejection, | 1509 | | | as described in Section 5.1.2. | 1510 +--------------+------+-------------------------------------+ 1512 Table 2: TCPCL Message Types 1514 4.6. Session Initialization Message (SESS_INIT) 1516 Before a session is established and ready to transfer bundles, the 1517 session parameters are negotiated between the connected entities. 1518 The SESS_INIT message is used to convey the per-entity parameters 1519 which are used together to negotiate the per-session parameters as 1520 described in Section 4.7. 1522 The format of a SESS_INIT message is as follows in Figure 19. 1524 +-----------------------------+ 1525 | Message Header | 1526 +-----------------------------+ 1527 | Keepalive Interval (U16) | 1528 +-----------------------------+ 1529 | Segment MRU (U64) | 1530 +-----------------------------+ 1531 | Transfer MRU (U64) | 1532 +-----------------------------+ 1533 | Node ID Length (U16) | 1534 +-----------------------------+ 1535 | Node ID Data (variable) | 1536 +-----------------------------+ 1537 | Session Extension | 1538 | Items Length (U32) | 1539 +-----------------------------+ 1540 | Session Extension | 1541 | Items (var.) | 1542 +-----------------------------+ 1544 Figure 19: SESS_INIT Format 1546 The fields of the SESS_INIT message are: 1548 Keepalive Interval: A 16-bit unsigned integer indicating the minimum 1549 interval, in seconds, to negotiate as the Session Keepalive using 1550 the method of Section 4.7. 1552 Segment MRU: A 64-bit unsigned integer indicating the largest 1553 allowable single-segment data payload size to be received in this 1554 session. Any XFER_SEGMENT sent to this peer SHALL have a data 1555 payload no longer than the peer's Segment MRU. The two entities 1556 of a single session MAY have different Segment MRUs, and no 1557 relation between the two is required. 1559 Transfer MRU: A 64-bit unsigned integer indicating the largest 1560 allowable total-bundle data size to be received in this session. 1561 Any bundle transfer sent to this peer SHALL have a Total Bundle 1562 Length payload no longer than the peer's Transfer MRU. This value 1563 can be used to perform proactive bundle fragmentation. The two 1564 entities of a single session MAY have different Transfer MRUs, and 1565 no relation between the two is required. 1567 Node ID Length and Node ID Data: Together these fields represent a 1568 variable-length text string. The Node ID Length is a 16-bit 1569 unsigned integer indicating the number of octets of Node ID Data 1570 to follow. A zero-length Node ID SHALL be used to indicate the 1571 lack of Node ID rather than a truly empty Node ID. This case 1572 allows an entity to avoid exposing Node ID information on an 1573 untrusted network. A non-zero-length Node ID Data SHALL contain 1574 the UTF-8 encoded Node ID of the Entity which sent the SESS_INIT 1575 message. Every Node ID SHALL be a URI consistent with the 1576 requirements of [RFC3986] and the URI schemes of the IANA "Bundle 1577 Protocol URI Scheme Type" registry [IANA-BUNDLE]. The Node ID 1578 itself can be authenticated as described in Section 4.4.3. 1580 Session Extension Length and Session Extension Items: Together these 1581 fields represent protocol extension data not defined by this 1582 specification. The Session Extension Length is the total number 1583 of octets to follow which are used to encode the Session Extension 1584 Item list. The encoding of each Session Extension Item is within 1585 a consistent data container as described in Section 4.8. The full 1586 set of Session Extension Items apply for the duration of the TCPCL 1587 session to follow. The order and multiplicity of these Session 1588 Extension Items is significant, as defined in the associated type 1589 specification(s). If the content of the Session Extension Items 1590 data disagrees with the Session Extension Length (e.g., the last 1591 Item claims to use more octets than are present in the Session 1592 Extension Length), the reception of the SESS_INIT is considered to 1593 have failed. 1595 When the active entity initiates a TCPCL session, it is likely based 1596 on routing information which binds a Node ID to CL parameters. If 1597 the active entity receives a SESS_INIT with different Node ID than 1598 was intended for the TCPCL session, the session MAY be allowed to be 1599 established. If allowed, such a session SHALL be associated with the 1600 Node ID provided in the SESS_INIT message rather than any intended 1601 value. 1603 4.7. Session Parameter Negotiation 1605 An entity calculates the parameters for a TCPCL session by 1606 negotiating the values from its own preferences (conveyed by the 1607 SESS_INIT it sent to the peer) with the preferences of the peer 1608 entity (expressed in the SESS_INIT that it received from the peer). 1609 The negotiated parameters defined by this specification are described 1610 in the following paragraphs. 1612 Transfer MTU and Segment MTU: The maximum transmit unit (MTU) for 1613 whole transfers and individual segments are identical to the 1614 Transfer MRU and Segment MRU, respectively, of the received 1615 SESS_INIT message. A transmitting peer can send individual 1616 segments with any size smaller than the Segment MTU, depending on 1617 local policy, dynamic network conditions, etc. Determining the 1618 size of each transmitted segment is an implementation matter. If 1619 either the Transfer MRU or Segment MRU is unacceptable, the entity 1620 SHALL terminate the session with a reason code of "Contact 1621 Failure". 1623 Session Keepalive: Negotiation of the Session Keepalive parameter is 1624 performed by taking the minimum of the two Keepalive Interval 1625 values from the two SESS_INIT messages. The Session Keepalive 1626 interval is a parameter for the behavior described in 1627 Section 5.1.1. If the Session Keepalive interval is unacceptable, 1628 the entity SHALL terminate the session with a reason code of 1629 "Contact Failure". Note: a negotiated Session Keepalive of zero 1630 indicates that KEEPALIVEs are disabled. 1632 Once this process of parameter negotiation is completed, this 1633 protocol defines no additional mechanism to change the parameters of 1634 an established session; to effect such a change, the TCPCL session 1635 MUST be terminated and a new session established. 1637 4.8. Session Extension Items 1639 Each of the Session Extension Items SHALL be encoded in an identical 1640 Type-Length-Value (TLV) container form as indicated in Figure 20. 1642 The fields of the Session Extension Item are: 1644 Item Flags: A one-octet field containing generic bit flags about the 1645 Item, which are listed in Table 3. All reserved header flag bits 1646 SHALL be set to 0 by the sender. All reserved header flag bits 1647 SHALL be ignored by the receiver. If a TCPCL entity receives a 1648 Session Extension Item with an unknown Item Type and the CRITICAL 1649 flag of 1, the entity SHALL terminate the TCPCL session with 1650 SESS_TERM reason code of "Contact Failure". If the CRITICAL flag 1651 is 0, an entity SHALL skip over and ignore any item with an 1652 unknown Item Type. 1654 Item Type: A 16-bit unsigned integer field containing the type of 1655 the extension item. This specification does not define any 1656 extension types directly, but does create an IANA registry for 1657 such codes (see Section 9.3). 1659 Item Length: A 16-bit unsigned integer field containing the number 1660 of Item Value octets to follow. 1662 Item Value: A variable-length data field which is interpreted 1663 according to the associated Item Type. This specification places 1664 no restrictions on an extension's use of available Item Value 1665 data. Extension specifications SHOULD avoid the use of large data 1666 lengths, as no bundle transfers can begin until the full extension 1667 data is sent. 1669 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1670 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 1671 +---------------+---------------+---------------+---------------+ 1672 | Item Flags | Item Type | Item Length...| 1673 +---------------+---------------+---------------+---------------+ 1674 | length contd. | Item Value... | 1675 +---------------+---------------+---------------+---------------+ 1677 Figure 20: Session Extension Item Format 1679 +==========+========+=============================================+ 1680 | Name | Code | Description | 1681 +==========+========+=============================================+ 1682 | CRITICAL | 0x01 | If bit is set, indicates that the receiving | 1683 | | | peer must handle the extension item. | 1684 +----------+--------+---------------------------------------------+ 1685 | Reserved | others | | 1686 +----------+--------+---------------------------------------------+ 1688 Table 3: Session Extension Item Flags 1690 5. Established Session Operation 1692 This section describes the protocol operation for the duration of an 1693 established session, including the mechanism for transmitting bundles 1694 over the session. 1696 5.1. Upkeep and Status Messages 1698 5.1.1. Session Upkeep (KEEPALIVE) 1700 The protocol includes a provision for transmission of KEEPALIVE 1701 messages over the TCPCL session to help determine if the underlying 1702 TCP connection has been disrupted. 1704 As described in Section 4.3, a negotiated parameter of each session 1705 is the Session Keepalive interval. If the negotiated Session 1706 Keepalive is zero (i.e., one or both contact headers contains a zero 1707 Keepalive Interval), then the keepalive feature is disabled. There 1708 is no logical minimum value for the keepalive interval (within the 1709 minimum imposed by the positive-value encoding), but when used for 1710 many sessions on an open, shared network a short interval could lead 1711 to excessive traffic. For shared network use, entities SHOULD choose 1712 a keepalive interval no shorter than 30 seconds. There is no logical 1713 maximum value for the keepalive interval (within the maximum imposed 1714 by the fixed-size encoding), but an idle TCP connection is liable for 1715 closure by the host operating system if the keepalive time is longer 1716 than tens-of-minutes. Entities SHOULD choose a keepalive interval no 1717 longer than 10 minutes (600 seconds). 1719 Note: The Keepalive Interval SHOULD NOT be chosen too short as TCP 1720 retransmissions MAY occur in case of packet loss. Those will have to 1721 be triggered by a timeout (TCP retransmission timeout (RTO)), which 1722 is dependent on the measured RTT for the TCP connection so that 1723 KEEPALIVE messages can experience noticeable latency. 1725 The format of a KEEPALIVE message is a one-octet message type code of 1726 KEEPALIVE (as described in Table 2) with no additional data. Both 1727 sides SHALL send a KEEPALIVE message whenever the negotiated interval 1728 has elapsed with no transmission of any message (KEEPALIVE or other). 1730 If no message (KEEPALIVE or other) has been received in a session 1731 after some implementation-defined time duration, then the entity 1732 SHALL terminate the session by transmitting a SESS_TERM message (as 1733 described in Section 6.1) with reason code "Idle Timeout". If 1734 configurable, the idle timeout duration SHOULD be no shorter than 1735 twice the keepalive interval. If not configurable, the idle timeout 1736 duration SHOULD be exactly twice the keepalive interval. 1738 5.1.2. Message Rejection (MSG_REJECT) 1740 This message type is not expected to be seen in a well-functioning 1741 session. Its purpose is to aid in troubleshooting bad entity 1742 behavior by allowing the peer to observe why an entity is not 1743 responding as expected to its messages. 1745 If a TCPCL entity receives a message type which is unknown to it 1746 (possibly due to an unhandled protocol version mismatch or a 1747 incorrectly-negotiated session extension which defines a new message 1748 type), the entity SHALL send a MSG_REJECT message with a Reason Code 1749 of "Message Type Unknown" and close the TCP connection. If a TCPCL 1750 entity receives a message type which is known but is inappropriate 1751 for the negotiated session parameters (possibly due to incorrectly- 1752 negotiated session extension), the entity SHALL send a MSG_REJECT 1753 message with a Reason Code of "Message Unsupported". If a TCPCL 1754 entity receives a message which is inappropriate for the current 1755 session state (e.g., a SESS_INIT after the session has already been 1756 established or an XFER_ACK message with an unknown Transfer ID), the 1757 entity SHALL send a MSG_REJECT message with a Reason Code of "Message 1758 Unexpected". 1760 The format of a MSG_REJECT message is as follows in Figure 21. 1762 +-----------------------------+ 1763 | Message Header | 1764 +-----------------------------+ 1765 | Reason Code (U8) | 1766 +-----------------------------+ 1767 | Rejected Message Header | 1768 +-----------------------------+ 1770 Figure 21: Format of MSG_REJECT Messages 1772 The fields of the MSG_REJECT message are: 1774 Reason Code: A one-octet refusal reason code interpreted according 1775 to the descriptions in Table 4. 1777 Rejected Message Header: The Rejected Message Header is a copy of 1778 the Message Header to which the MSG_REJECT message is sent as a 1779 response. 1781 +==============+======+=============================================+ 1782 | Name | Code | Description | 1783 +==============+======+=============================================+ 1784 | Message Type | 0x01 | A message was received with a Message | 1785 | Unknown | | Type code unknown to the TCPCL entity. | 1786 +--------------+------+---------------------------------------------+ 1787 | Message | 0x02 | A message was received but the TCPCL | 1788 | Unsupported | | entity cannot comply with the message | 1789 | | | contents. | 1790 +--------------+------+---------------------------------------------+ 1791 | Message | 0x03 | A message was received while the | 1792 | Unexpected | | session is in a state in which the | 1793 | | | message is not expected. | 1794 +--------------+------+---------------------------------------------+ 1796 Table 4: MSG_REJECT Reason Codes 1798 5.2. Bundle Transfer 1800 All of the messages in this section are directly associated with 1801 transferring a bundle between TCPCL entities. 1803 A single TCPCL transfer results in a bundle (handled by the 1804 convergence layer as opaque data) being exchanged from one entity to 1805 the other. In TCPCL a transfer is accomplished by dividing a single 1806 bundle up into "segments" based on the receiving-side Segment MRU 1807 (see Section 4.2). The choice of the length to use for segments is 1808 an implementation matter, but each segment MUST NOT be larger than 1809 the receiving entity's maximum receive unit (MRU) (see the field 1810 Segment MRU of Section 4.2). The first segment for a bundle is 1811 indicated by the 'START' flag and the last segment is indicated by 1812 the 'END' flag. 1814 A single transfer (and by extension a single segment) SHALL NOT 1815 contain data of more than a single bundle. This requirement is 1816 imposed on the agent using the TCPCL rather than TCPCL itself. 1818 If multiple bundles are transmitted on a single TCPCL connection, 1819 they MUST be transmitted consecutively without interleaving of 1820 segments from multiple bundles. 1822 5.2.1. Bundle Transfer ID 1824 Each of the bundle transfer messages contains a Transfer ID which is 1825 used to correlate messages (from both sides of a transfer) for each 1826 bundle. A Transfer ID does not attempt to address uniqueness of the 1827 bundle data itself and has no relation to concepts such as bundle 1828 fragmentation. Each invocation of TCPCL by the bundle protocol 1829 agent, requesting transmission of a bundle (fragmentary or 1830 otherwise), results in the initiation of a single TCPCL transfer. 1831 Each transfer entails the sending of a sequence of some number of 1832 XFER_SEGMENT and XFER_ACK messages; all are correlated by the same 1833 Transfer ID. The sending entity originates a transfer ID and the 1834 receiving entity uses that same Transfer ID in acknowledgements. 1836 Transfer IDs from each entity SHALL be unique within a single TCPCL 1837 session. Upon exhaustion of the entire 64-bit Transfer ID space, the 1838 sending entity SHALL terminate the session with SESS_TERM reason code 1839 "Resource Exhaustion". For bidirectional bundle transfers, a TCPCL 1840 entity SHOULD NOT rely on any relation between Transfer IDs 1841 originating from each side of the TCPCL session. 1843 Although there is not a strict requirement for Transfer ID initial 1844 values or ordering (see Section 8.12), in the absence of any other 1845 mechanism for generating Transfer IDs an entity SHALL use the 1846 following algorithm: The initial Transfer ID from each entity is zero 1847 and subsequent Transfer ID values are incremented from the prior 1848 Transfer ID value by one. 1850 5.2.2. Data Transmission (XFER_SEGMENT) 1852 Each bundle is transmitted in one or more data segments. The format 1853 of a XFER_SEGMENT message follows in Figure 22. 1855 +------------------------------+ 1856 | Message Header | 1857 +------------------------------+ 1858 | Message Flags (U8) | 1859 +------------------------------+ 1860 | Transfer ID (U64) | 1861 +------------------------------+ 1862 | Transfer Extension | 1863 | Items Length (U32) | 1864 | (only for START segment) | 1865 +------------------------------+ 1866 | Transfer Extension | 1867 | Items (var.) | 1868 | (only for START segment) | 1869 +------------------------------+ 1870 | Data length (U64) | 1871 +------------------------------+ 1872 | Data contents (octet string) | 1873 +------------------------------+ 1875 Figure 22: Format of XFER_SEGMENT Messages 1877 The fields of the XFER_SEGMENT message are: 1879 Message Flags: A one-octet field of single-bit flags, interpreted 1880 according to the descriptions in Table 5. All reserved header 1881 flag bits SHALL be set to 0 by the sender. All reserved header 1882 flag bits SHALL be ignored by the receiver. 1884 Transfer ID: A 64-bit unsigned integer identifying the transfer 1885 being made. 1887 Transfer Extension Length and Transfer Extension Items: Together 1888 these fields represent protocol extension data for this 1889 specification. The Transfer Extension Length and Transfer 1890 Extension Item fields SHALL only be present when the 'START' flag 1891 is set to 1 on the message. The Transfer Extension Length is the 1892 total number of octets to follow which are used to encode the 1893 Transfer Extension Item list. The encoding of each Transfer 1894 Extension Item is within a consistent data container as described 1895 in Section 5.2.5. The full set of transfer extension items apply 1896 only to the associated single transfer. The order and 1897 multiplicity of these transfer extension items is significant, as 1898 defined in the associated type specification(s). If the content 1899 of the Transfer Extension Items data disagrees with the Transfer 1900 Extension Length (e.g., the last Item claims to use more octets 1901 than are present in the Transfer Extension Length), the reception 1902 of the XFER_SEGMENT is considered to have failed. 1904 Data length: A 64-bit unsigned integer indicating the number of 1905 octets in the Data contents to follow. 1907 Data contents: The variable-length data payload of the message. 1909 +==========+========+=======================================+ 1910 | Name | Code | Description | 1911 +==========+========+=======================================+ 1912 | END | 0x01 | If bit is set, indicates that this is | 1913 | | | the last segment of the transfer. | 1914 +----------+--------+---------------------------------------+ 1915 | START | 0x02 | If bit is set, indicates that this is | 1916 | | | the first segment of the transfer. | 1917 +----------+--------+---------------------------------------+ 1918 | Reserved | others | | 1919 +----------+--------+---------------------------------------+ 1921 Table 5: XFER_SEGMENT Flags 1923 The flags portion of the message contains two flag values in the two 1924 low-order bits, denoted 'START' and 'END' in Table 5. The 'START' 1925 flag SHALL be set to 1 when transmitting the first segment of a 1926 transfer. The 'END' flag SHALL be set to 1 when transmitting the 1927 last segment of a transfer. In the case where an entire transfer is 1928 accomplished in a single segment, both the 'START' and 'END' flags 1929 SHALL be set to 1. 1931 Once a transfer of a bundle has commenced, the entity MUST only send 1932 segments containing sequential portions of that bundle until it sends 1933 a segment with the 'END' flag set to 1. No interleaving of multiple 1934 transfers from the same entity is possible within a single TCPCL 1935 session. Simultaneous transfers between two entities MAY be achieved 1936 using multiple TCPCL sessions. 1938 5.2.3. Data Acknowledgments (XFER_ACK) 1940 Although the TCP transport provides reliable transfer of data between 1941 transport peers, the typical BSD sockets interface provides no means 1942 to inform a sending application of when the receiving application has 1943 processed some amount of transmitted data. Thus, after transmitting 1944 some data, the TCPCL needs an additional mechanism to determine 1945 whether the receiving agent has successfully received and fully 1946 processed the segment. To this end, the TCPCL protocol provides 1947 feedback messaging whereby a receiving entity transmits 1948 acknowledgments of reception of data segments. 1950 The format of an XFER_ACK message follows in Figure 23. 1952 +-----------------------------+ 1953 | Message Header | 1954 +-----------------------------+ 1955 | Message Flags (U8) | 1956 +-----------------------------+ 1957 | Transfer ID (U64) | 1958 +-----------------------------+ 1959 | Acknowledged length (U64) | 1960 +-----------------------------+ 1962 Figure 23: Format of XFER_ACK Messages 1964 The fields of the XFER_ACK message are: 1966 Message Flags: A one-octet field of single-bit flags, interpreted 1967 according to the descriptions in Table 5. All reserved header 1968 flag bits SHALL be set to 0 by the sender. All reserved header 1969 flag bits SHALL be ignored by the receiver. 1971 Transfer ID: A 64-bit unsigned integer identifying the transfer 1972 being acknowledged. 1974 Acknowledged length: A 64-bit unsigned integer indicating the total 1975 number of octets in the transfer which are being acknowledged. 1977 A receiving TCPCL entity SHALL send an XFER_ACK message in response 1978 to each received XFER_SEGMENT message after the segment has been 1979 fully processed. The flags portion of the XFER_ACK header SHALL be 1980 set to match the corresponding XFER_SEGMENT message being 1981 acknowledged (including flags not decodable to the entity). The 1982 acknowledged length of each XFER_ACK contains the sum of the data 1983 length fields of all XFER_SEGMENT messages received so far in the 1984 course of the indicated transfer. The sending entity SHOULD transmit 1985 multiple XFER_SEGMENT messages without waiting for the corresponding 1986 XFER_ACK responses. This enables pipelining of messages on a 1987 transfer stream. 1989 For example, suppose the sending entity transmits four segments of 1990 bundle data with lengths 100, 200, 500, and 1000, respectively. 1991 After receiving the first segment, the entity sends an acknowledgment 1992 of length 100. After the second segment is received, the entity 1993 sends an acknowledgment of length 300. The third and fourth 1994 acknowledgments are of length 800 and 1800, respectively. 1996 5.2.4. Transfer Refusal (XFER_REFUSE) 1998 The TCPCL supports a mechanism by which a receiving entity can 1999 indicate to the sender that it does not want to receive the 2000 corresponding bundle. To do so, upon receiving an XFER_SEGMENT 2001 message, the entity MAY transmit a XFER_REFUSE message. As data 2002 segments and acknowledgments can cross on the wire, the bundle that 2003 is being refused SHALL be identified by the Transfer ID of the 2004 refusal. 2006 There is no required relation between the Transfer MRU of a TCPCL 2007 entity (which is supposed to represent a firm limitation of what the 2008 entity will accept) and sending of a XFER_REFUSE message. A 2009 XFER_REFUSE can be used in cases where the agent's bundle storage is 2010 temporarily depleted or somehow constrained. A XFER_REFUSE can also 2011 be used after the bundle header or any bundle data is inspected by an 2012 agent and determined to be unacceptable. 2014 A transfer receiver MAY send an XFER_REFUSE message as soon as it 2015 receives any XFER_SEGMENT message. The transfer sender MUST be 2016 prepared for this and MUST associate the refusal with the correct 2017 bundle via the Transfer ID fields. 2019 The TCPCL itself does not have any required behavior to respond to an 2020 XFER_REFUSE based on its Reason Code; the refusal is passed up as an 2021 indication to the BP agent that the transfer has been refused. If a 2022 transfer refusal has a Reason Code which is not decodable to the BP 2023 agent, the agent SHOULD treat the refusal as having an Unknown 2024 reason. 2026 The format of the XFER_REFUSE message is as follows in Figure 24. 2028 +-----------------------------+ 2029 | Message Header | 2030 +-----------------------------+ 2031 | Reason Code (U8) | 2032 +-----------------------------+ 2033 | Transfer ID (U64) | 2034 +-----------------------------+ 2036 Figure 24: Format of XFER_REFUSE Messages 2038 The fields of the XFER_REFUSE message are: 2040 Reason Code: A one-octet refusal reason code interpreted according 2041 to the descriptions in Table 6. 2043 Transfer ID: A 64-bit unsigned integer identifying the transfer 2044 being refused. 2046 +=============+======+==========================================+ 2047 | Name | Code | Description | 2048 +=============+======+==========================================+ 2049 | Unknown | 0x00 | Reason for refusal is unknown or not | 2050 | | | specified. | 2051 +-------------+------+------------------------------------------+ 2052 | Completed | 0x01 | The receiver already has the complete | 2053 | | | bundle. The sender MAY consider the | 2054 | | | bundle as completely received. | 2055 +-------------+------+------------------------------------------+ 2056 | No | 0x02 | The receiver's resources are exhausted. | 2057 | Resources | | The sender SHOULD apply reactive bundle | 2058 | | | fragmentation before retrying. | 2059 +-------------+------+------------------------------------------+ 2060 | Retransmit | 0x03 | The receiver has encountered a problem | 2061 | | | that requires the bundle to be | 2062 | | | retransmitted in its entirety. | 2063 +-------------+------+------------------------------------------+ 2064 | Not | 0x04 | Some issue with the bundle data or the | 2065 | Acceptable | | transfer extension data was encountered. | 2066 | | | The sender SHOULD NOT retry the same | 2067 | | | bundle with the same extensions. | 2068 +-------------+------+------------------------------------------+ 2069 | Extension | 0x05 | A failure processing the Transfer | 2070 | Failure | | Extension Items has occurred. | 2071 +-------------+------+------------------------------------------+ 2072 | Session | 0x06 | The receiving entity is in the process | 2073 | Terminating | | of terminating the session. The sender | 2074 | | | MAY retry the same bundle at a later | 2075 | | | time in a different session. | 2076 +-------------+------+------------------------------------------+ 2078 Table 6: XFER_REFUSE Reason Codes 2080 The receiver MUST, for each transfer preceding the one to be refused, 2081 have either acknowledged all XFER_SEGMENT messages or refused the 2082 bundle transfer. 2084 The bundle transfer refusal MAY be sent before an entire data segment 2085 is received. If a sender receives a XFER_REFUSE message, the sender 2086 MUST complete the transmission of any partially sent XFER_SEGMENT 2087 message. There is no way to interrupt an individual TCPCL message 2088 partway through sending it. The sender MUST NOT commence 2089 transmission of any further segments of the refused bundle 2090 subsequently. Note, however, that this requirement does not ensure 2091 that an entity will not receive another XFER_SEGMENT for the same 2092 bundle after transmitting a XFER_REFUSE message since messages can 2093 cross on the wire; if this happens, subsequent segments of the bundle 2094 SHALL also be refused with a XFER_REFUSE message. 2096 Note: If a bundle transmission is aborted in this way, the receiver 2097 does not receive a segment with the 'END' flag set to 1 for the 2098 aborted bundle. The beginning of the next bundle is identified by 2099 the 'START' flag set to 1, indicating the start of a new transfer, 2100 and with a distinct Transfer ID value. 2102 5.2.5. Transfer Extension Items 2104 Each of the Transfer Extension Items SHALL be encoded in an identical 2105 Type-Length-Value (TLV) container form as indicated in Figure 25. 2107 The fields of the Transfer Extension Item are: 2109 Item Flags: A one-octet field containing generic bit flags about the 2110 Item, which are listed in Table 7. All reserved header flag bits 2111 SHALL be set to 0 by the sender. All reserved header flag bits 2112 SHALL be ignored by the receiver. If a TCPCL entity receives a 2113 Transfer Extension Item with an unknown Item Type and the CRITICAL 2114 flag is 1, the entity SHALL refuse the transfer with an 2115 XFER_REFUSE reason code of "Extension Failure". If the CRITICAL 2116 flag is 0, an entity SHALL skip over and ignore any item with an 2117 unknown Item Type. 2119 Item Type: A 16-bit unsigned integer field containing the type of 2120 the extension item. This specification creates an IANA registry 2121 for such codes (see Section 9.4). 2123 Item Length: A 16-bit unsigned integer field containing the number 2124 of Item Value octets to follow. 2126 Item Value: A variable-length data field which is interpreted 2127 according to the associated Item Type. This specification places 2128 no restrictions on an extension's use of available Item Value 2129 data. Extension specifications SHOULD avoid the use of large data 2130 lengths, as the associated transfer cannot begin until the full 2131 extension data is sent. 2133 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 2134 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 2135 +---------------+---------------+---------------+---------------+ 2136 | Item Flags | Item Type | Item Length...| 2137 +---------------+---------------+---------------+---------------+ 2138 | length contd. | Item Value... | 2139 +---------------+---------------+---------------+---------------+ 2140 Figure 25: Transfer Extension Item Format 2142 +==========+========+=============================================+ 2143 | Name | Code | Description | 2144 +==========+========+=============================================+ 2145 | CRITICAL | 0x01 | If bit is set, indicates that the receiving | 2146 | | | peer must handle the extension item. | 2147 +----------+--------+---------------------------------------------+ 2148 | Reserved | others | | 2149 +----------+--------+---------------------------------------------+ 2151 Table 7: Transfer Extension Item Flags 2153 5.2.5.1. Transfer Length Extension 2155 The purpose of the Transfer Length extension is to allow entities to 2156 preemptively refuse bundles that would exceed their resources or to 2157 prepare storage on the receiving entity for the upcoming bundle data. 2159 Multiple Transfer Length extension items SHALL NOT occur within the 2160 same transfer. The lack of a Transfer Length extension item in any 2161 transfer SHALL NOT imply anything about the potential length of the 2162 transfer. The Transfer Length extension SHALL be assigned transfer 2163 extension type ID 0x0001. 2165 If a transfer occupies exactly one segment (i.e., both START and END 2166 flags are 1) the Transfer Length extension SHOULD NOT be present. 2167 The extension does not provide any additional information for single- 2168 segment transfers. 2170 The format of the Transfer Length data is as follows in Figure 26. 2172 +----------------------+ 2173 | Total Length (U64) | 2174 +----------------------+ 2176 Figure 26: Format of Transfer Length data 2178 The fields of the Transfer Length extension are: 2180 Total Length: A 64-bit unsigned integer indicating the size of the 2181 data-to-be-transferred. The Total Length field SHALL be treated 2182 as authoritative by the receiver. If, for whatever reason, the 2183 actual total length of bundle data received differs from the value 2184 indicated by the Total Length value, the receiver SHALL treat the 2185 transmitted data as invalid and send an XFER_REFUSE with a Reason 2186 Code of "Not Acceptable". 2188 6. Session Termination 2190 This section describes the procedures for terminating a TCPCL 2191 session. The purpose of terminating a session is to allow transfers 2192 to complete before the TCP connection is closed but not allow any new 2193 transfers to start. A session state change is necessary for this to 2194 happen because transfers can be in-progress in either direction 2195 (transfer stream) within a session. Waiting for a transfer to 2196 complete in one direction does not control or influence the 2197 possibility of a transfer in the other direction. Either peer of a 2198 session can terminate an established session at any time. 2200 6.1. Session Termination Message (SESS_TERM) 2202 To cleanly terminate a session, a SESS_TERM message SHALL be 2203 transmitted by either entity at any point following complete 2204 transmission of any other message. When sent to initiate a 2205 termination, the REPLY flag of a SESS_TERM message SHALL be 0. Upon 2206 receiving a SESS_TERM message after not sending a SESS_TERM message 2207 in the same session, an entity SHALL send an acknowledging SESS_TERM 2208 message. When sent to acknowledge a termination, a SESS_TERM message 2209 SHALL have identical data content from the message being acknowledged 2210 except for the REPLY flag, which is set to 1 to indicate 2211 acknowledgement. 2213 Once a SESS_TERM message is sent the state of that TCPCL session 2214 changes to Ending. While the session is in the Ending state, an 2215 entity MAY finish an in-progress transfer in either direction. While 2216 the session is in the Ending state, an entity SHALL NOT begin any new 2217 outgoing transfer for the remainder of the session. While the 2218 session is in the Ending state, an entity SHALL NOT accept any new 2219 incoming transfer for the remainder of the session. If a new 2220 incoming transfer is attempted while in the Ending state, the 2221 receiving entity SHALL send an XFER_REFUSE with a Reason Code of 2222 "Session Terminating". 2224 There are circumstances where an entity has an urgent need to close a 2225 TCP connection associated with a TCPCL session, without waiting for 2226 transfers to complete but also in a way which doesn't force timeouts 2227 to occur; for example, due to impending shutdown of the underlying 2228 data link layer. Instead of following a clean termination sequence, 2229 after transmitting a SESS_TERM message an entity MAY perform an 2230 unclean termination by immediately closing the associated TCP 2231 connection. When performing an unclean termination, an entity SHOULD 2232 acknowledge all received XFER_SEGMENTs with an XFER_ACK before 2233 closing the TCP connection. Not acknowledging received segments can 2234 result in unnecessary bundle or bundle fragment retransmission. Any 2235 delay between request to close the TCP connection and actual closing 2236 of the connection (a "half-closed" state) MAY be ignored by the TCPCL 2237 entity. If the underlying TCP connection is closed during a 2238 transmission (in either transfer stream), the transfer SHALL be 2239 indicated to the BP agent as failed (see the transmission failure and 2240 reception failure indications of Section 3.1). 2242 The TCPCL itself does not have any required behavior to respond to an 2243 SESS_TERM based on its Reason Code; the termination is passed up as 2244 an indication to the BP agent that the session state has changed. If 2245 a termination has a Reason Code which is not decodable to the BP 2246 agent, the agent SHOULD treat the termination as having an Unknown 2247 reason. 2249 The format of the SESS_TERM message is as follows in Figure 27. 2251 +-----------------------------+ 2252 | Message Header | 2253 +-----------------------------+ 2254 | Message Flags (U8) | 2255 +-----------------------------+ 2256 | Reason Code (U8) | 2257 +-----------------------------+ 2259 Figure 27: Format of SESS_TERM Messages 2261 The fields of the SESS_TERM message are: 2263 Message Flags: A one-octet field of single-bit flags, interpreted 2264 according to the descriptions in Table 8. All reserved header 2265 flag bits SHALL be set to 0 by the sender. All reserved header 2266 flag bits SHALL be ignored by the receiver. 2268 Reason Code: A one-octet refusal reason code interpreted according 2269 to the descriptions in Table 9. 2271 +==========+========+====================================+ 2272 | Name | Code | Description | 2273 +==========+========+====================================+ 2274 | REPLY | 0x01 | If bit is set, indicates that this | 2275 | | | message is an acknowledgement of | 2276 | | | an earlier SESS_TERM message. | 2277 +----------+--------+------------------------------------+ 2278 | Reserved | others | | 2279 +----------+--------+------------------------------------+ 2281 Table 8: SESS_TERM Flags 2283 +==============+======+==========================================+ 2284 | Name | Code | Description | 2285 +==============+======+==========================================+ 2286 | Unknown | 0x00 | A termination reason is not available. | 2287 +--------------+------+------------------------------------------+ 2288 | Idle timeout | 0x01 | The session is being terminated due to | 2289 | | | idleness. | 2290 +--------------+------+------------------------------------------+ 2291 | Version | 0x02 | The entity cannot conform to the | 2292 | mismatch | | specified TCPCL protocol version. | 2293 +--------------+------+------------------------------------------+ 2294 | Busy | 0x03 | The entity is too busy to handle the | 2295 | | | current session. | 2296 +--------------+------+------------------------------------------+ 2297 | Contact | 0x04 | The entity cannot interpret or negotiate | 2298 | Failure | | a Contact Header or SESS_INIT option. | 2299 +--------------+------+------------------------------------------+ 2300 | Resource | 0x05 | The entity has run into some resource | 2301 | Exhaustion | | limit and cannot continue the session. | 2302 +--------------+------+------------------------------------------+ 2304 Table 9: SESS_TERM Reason Codes 2306 The earliest a TCPCL session termination MAY occur is immediately 2307 after transmission of a Contact Header (and prior to any further 2308 message transmit). This can, for example, be used to notify that the 2309 entity is currently not able or willing to communicate. However, an 2310 entity MUST always send the Contact Header to its peer before sending 2311 a SESS_TERM message. 2313 Termination of the TCP connection MAY occur prior to receiving the 2314 Contact header as discussed in Section 4.1. If reception of the 2315 Contact Header itself somehow fails (e.g., an invalid "magic string" 2316 is received), an entity SHALL close the TCP connection without 2317 sending a SESS_TERM message. 2319 If a session is to be terminated before a protocol message has 2320 completed being sent, then the entity MUST NOT transmit the SESS_TERM 2321 message but still SHALL close the TCP connection. Each TCPCL message 2322 is contiguous in the octet stream and has no ability to be cut short 2323 and/or preempted by an other message. This is particularly important 2324 when large segment sizes are being transmitted; either entire 2325 XFER_SEGMENT is sent before a SESS_TERM message or the connection is 2326 simply terminated mid-XFER_SEGMENT. 2328 6.2. Idle Session Shutdown 2330 The protocol includes a provision for clean termination of idle 2331 sessions. Determining the length of time to wait before terminating 2332 idle sessions, if they are to be terminated at all, is an 2333 implementation and configuration matter. 2335 If there is a configured time to terminate idle sessions and if no 2336 TCPCL messages (other than KEEPALIVE messages) has been received for 2337 at least that amount of time, then either entity MAY terminate the 2338 session by transmitting a SESS_TERM message indicating the reason 2339 code of "Idle timeout" (as described in Table 9). 2341 7. Implementation Status 2343 [NOTE to the RFC Editor: please remove this section before 2344 publication, as well as the reference to [RFC7942] and 2345 [github-dtn-bpbis-tcpcl].] 2347 This section records the status of known implementations of the 2348 protocol defined by this specification at the time of posting of this 2349 Internet-Draft, and is based on a proposal described in [RFC7942]. 2350 The description of implementations in this section is intended to 2351 assist the IETF in its decision processes in progressing drafts to 2352 RFCs. Please note that the listing of any individual implementation 2353 here does not imply endorsement by the IETF. Furthermore, no effort 2354 has been spent to verify the information presented here that was 2355 supplied by IETF contributors. This is not intended as, and must not 2356 be construed to be, a catalog of available implementations or their 2357 features. Readers are advised to note that other implementations can 2358 exist. 2360 An example implementation of the this draft of TCPCLv4 has been 2361 created as a GitHub project [github-dtn-bpbis-tcpcl] and is intended 2362 to use as a proof-of-concept and as a possible source of 2363 interoperability testing. This example implementation uses D-Bus as 2364 the CL-BP Agent interface, so it only runs on hosts which provide the 2365 Python "dbus" library. 2367 8. Security Considerations 2369 This section separates security considerations into threat categories 2370 based on guidance of BCP 72 [RFC3552]. 2372 8.1. Threat: Passive Leak of Node Data 2374 When used without TLS security, the TCPCL exposes the Node ID and 2375 other configuration data to passive eavesdroppers. This occurs even 2376 when no transfers occur within a TCPCL session. This can be avoided 2377 by always using TLS, even if authentication is not available (see 2378 Section 8.11). 2380 8.2. Threat: Passive Leak of Bundle Data 2382 TCPCL can be used to provide point-to-point transport security, but 2383 does not provide security of data-at-rest and does not guarantee end- 2384 to-end bundle security. The bundle security mechanisms defined in 2385 [I-D.ietf-dtn-bpsec] are to be used instead. 2387 When used without TLS security, the TCPCL exposes all bundle data to 2388 passive eavesdroppers. This can be avoided by always using TLS, even 2389 if authentication is not available (see Section 8.11). 2391 8.3. Threat: TCPCL Version Downgrade 2393 When a TCPCL entity supports multiple versions of the protocol it is 2394 possible for a malicious or misconfigured peer to use an older 2395 version of TCPCL which does not support transport security. A man- 2396 in-the-middle attacker can also manipulate a Contact Header to 2397 present a lower protocol version than desired. 2399 It is up to security policies within each TCPCL entity to ensure that 2400 the negotiated TCPCL version meets transport security requirements. 2402 8.4. Threat: Transport Security Stripping 2404 When security policy allows non-TLS sessions, TCPCL does not protect 2405 against active network attackers. It is possible for a man-in-the- 2406 middle attacker to set the CAN_TLS flag to 0 on either side of the 2407 Contact Header exchange. This leads to the "SSL Stripping" attack 2408 described in [RFC7457]. 2410 The purpose of the CAN_TLS flag is to allow the use of TCPCL on 2411 entities which simply do not have a TLS implementation available. 2412 When TLS is available on an entity, it is strongly encouraged that 2413 the security policy disallow non-TLS sessions. This requires that 2414 the TLS handshake occurs, regardless of the policy-driven parameters 2415 of the handshake and policy-driven handling of the handshake outcome. 2417 One mechanism to mitigate the possibility of TLS stripping is the use 2418 of DNS-based Authentication of Named Entities (DANE) [RFC6698] for 2419 the passive peer. This mechanism relies on DNS and is 2420 unidirectional, so it doesn't help with applying policy toward the 2421 active peer, but it can be useful in an environment using 2422 opportunistic security. The configuration and use of DANE are are 2423 outside of the scope of this document. 2425 The negotiated use of TLS is identical behavior to STARTTLS use in 2426 [RFC2595] and [RFC4511]. 2428 8.5. Threat: Weak TLS Configurations 2430 Even when using TLS to secure the TCPCL session, the actual 2431 ciphersuite negotiated between the TLS peers can be insecure. 2432 Recommendations for ciphersuite use are included in BCP 195 2433 [RFC7525]. It is up to security policies within each TCPCL entity to 2434 ensure that the negotiated TLS ciphersuite meets transport security 2435 requirements. 2437 8.6. Threat: Untrusted End-Entity Certificate 2439 The profile in Section 4.4.3 uses end-entity certificates chained up 2440 to a trusted root CA. During TLS handshake, either entity can send a 2441 certificate set which does not contain the full chain, possibly 2442 excluding intermediate or root CAs. In an environment where peers 2443 are known to already contain needed root and intermediate CAs there 2444 is no need to include those CAs, but this has a risk of an entity not 2445 actually having one of the needed CAs. 2447 8.7. Threat: Certificate Validation Vulnerabilities 2449 Even when TLS itself is operating properly an attacker can attempt to 2450 exploit vulnerabilities within certificate check algorithms or 2451 configuration to establish a secure TCPCL session using an invalid 2452 certificate. A BP agent treats the peer Node ID within a TCPCL 2453 session as authoritative and an invalid certificate exploit could 2454 lead to bundle data leaking and/or denial of service to the Node ID 2455 being impersonated. There are many reasons, described in [RFC5280], 2456 why a certificate can fail to validate, including using the 2457 certificate outside of its valid time interval, using purposes for 2458 which it was not authorized, or using it after it has been revoked by 2459 its CA. Validating a certificate is a complex task and can require 2460 network connectivity outside of the primary TCPCL network path(s) if 2461 a mechanism such as the Online Certificate Status Protocol (OCSP) 2462 [RFC6960] is used by the CA. The configuration and use of particular 2463 certificate validation methods are outside of the scope of this 2464 document. 2466 8.8. Threat: Symmetric Key Limits 2468 Even with a secure block cipher and securely-established session 2469 keys, there are limits to the amount of plaintext which can be safely 2470 encrypted with a given set of keys as described in [AEAD-LIMITS]. 2471 When permitted by the negotiated TLS version (see [RFC8446]), it is 2472 advisable to take advantage of session key updates to avoid those 2473 limits. 2475 8.9. Threat: BP Node Impersonation 2477 The certificates exchanged by TLS enable authentication of peer DNS 2478 name and Node ID, but it is possible that a peer either not provide a 2479 valid certificate or that the certificate does not validate either 2480 the DNS name or Node ID of the peer (see Section 3.4). Having a CA- 2481 validated certificate does not alone guarantee the identity of the 2482 network host or BP node from which the certificate is provided; 2483 additional validation procedures in Section 4.4.2 bind the DNS name 2484 or Node ID based on the contents of the certificate. 2486 The DNS name validation is a weaker form of authentication, because 2487 even if a peer is operating on an authenticated network DNS name it 2488 can provide an invalid Node ID and cause bundles to be "leaked" to an 2489 invalid node. Especially in DTN environments, network names and 2490 addresses of nodes can be time-variable so binding a certificate to a 2491 Node ID is a more stable identity. 2493 Node ID validation ensures that the peer to which a bundle is 2494 transferred is in fact the node which the BP Agent expects it to be. 2495 It is a reasonable policy to skip DNS name validation if certificates 2496 can be guaranteed to validate the peer's Node ID. In circumstances 2497 where certificates can only be issued to DNS names, Node ID 2498 validation is not possible but it could be reasonable to assume that 2499 a trusted host is not going to present an invalid Node ID. 2500 Determining of when a DNS name authentication can be trusted to 2501 validate a Node ID is also a policy matter outside the scope of this 2502 document. 2504 8.10. Threat: Denial of Service 2506 The behaviors described in this section all amount to a potential 2507 denial-of-service to a TCPCL entity. The denial-of-service could be 2508 limited to an individual TCPCL session, could affect other well- 2509 behaving sessions on an entity, or could affect all sessions on a 2510 host. 2512 A malicious entity can continually establish TCPCL sessions and delay 2513 sending of protocol-required data to trigger timeouts. The victim 2514 entity can block TCP connections from network peers which are thought 2515 to be incorrectly behaving within TCPCL. 2517 An entity can send a large amount of data over a TCPCL session, 2518 requiring the receiving entity to handle the data. The victim entity 2519 can attempt to stop the flood of data by sending an XFER_REFUSE 2520 message, or forcibly terminate the session. 2522 There is the possibility of a "data dribble" attack in which an 2523 entity presents a very small Segment MRU which causes transfers to be 2524 split among an large number of very small segments and causes the 2525 segmentation overhead to overwhelm the actual bundle data segments. 2526 Similarly, an entity can present a very small Transfer MRU which will 2527 cause resources to be wasted on establishment and upkeep of a TCPCL 2528 session over which a bundle could never be transferred. The victim 2529 entity can terminate the session during the negotiation of 2530 Section 4.7 if the MRUs are unacceptable. 2532 The keepalive mechanism can be abused to waste throughput within a 2533 network link which would otherwise be usable for bundle 2534 transmissions. Due to the quantization of the Keepalive Interval 2535 parameter the smallest Session Keepalive is one second, which should 2536 be long enough to not flood the link. The victim entity can 2537 terminate the session during the negotiation of Section 4.7 if the 2538 Keepalive Interval is unacceptable. 2540 Finally, an attacker or a misconfigured entity can cause issues at 2541 the TCP connection which will cause unnecessary TCP retransmissions 2542 or connection resets, effectively denying the use of the overlying 2543 TCPCL session. 2545 8.11. Alternate Uses of TLS 2547 This specification makes use of PKIX certificate validation and 2548 authentication within TLS. There are alternate uses of TLS which are 2549 not necessarily incompatible with the security goals of this 2550 specification, but are outside of the scope of this document. The 2551 following subsections give examples of alternate TLS uses. 2553 8.11.1. TLS Without Authentication 2555 In environments where PKI is available but there are restrictions on 2556 the issuance of certificates (including the contents of 2557 certificates), it may be possible to make use of TLS in a way which 2558 authenticates only the passive entity of a TCPCL session or which 2559 does not authenticate either entity. Using TLS in a way which does 2560 not successfully authenticate some claim of both peer entities of a 2561 TCPCL session is outside of the scope of this document but does have 2562 similar properties to the opportunistic security model of [RFC7435]. 2564 8.11.2. Non-Certificate TLS Use 2566 In environments where PKI is unavailable, alternate uses of TLS which 2567 do not require certificates such as pre-shared key (PSK) 2568 authentication [RFC5489] and the use of raw public keys [RFC7250] are 2569 available and can be used to ensure confidentiality within TCPCL. 2570 Using non-PKI node authentication methods is outside of the scope of 2571 this document. 2573 8.12. Predictability of Transfer IDs 2575 The only requirement on Transfer IDs is that they be unique with each 2576 session from the sending peer only. The trivial algorithm of the 2577 first transfer starting at zero and later transfers incrementing by 2578 one causes absolutely predictable Transfer IDs. Even when a TCPCL 2579 session is not TLS secured and there is a man-in-the-middle attacker 2580 causing denial of service with XFER_REFUSE messages, it is not 2581 possible to preemptively refuse a transfer so there is no benefit in 2582 having unpredictable Transfer IDs within a session. 2584 9. IANA Considerations 2586 Registration procedures referred to in this section are defined in 2587 [RFC8126]. 2589 Some of the registries have been defined as version specific to 2590 TCPCLv4, and imports some or all codepoints from TCPCLv3. This was 2591 done to disambiguate the use of these codepoints between TCPCLv3 and 2592 TCPCLv4 while preserving the semantics of some of the codepoints. 2594 9.1. Port Number 2596 Within the port registry of [IANA-PORTS], TCP port number 4556 has 2597 been previously assigned as the default port for the TCP convergence 2598 layer in [RFC7242]. This assignment is unchanged by TCPCL version 4, 2599 but the assignment reference is updated to this specification. Each 2600 TCPCL entity identifies its TCPCL protocol version in its initial 2601 contact (see Section 9.2), so there is no ambiguity about what 2602 protocol is being used. The related assignments for UDP and DCCP 2603 port 4556 (both registered by [RFC7122]) are unchanged. 2605 +========================+============================+ 2606 | Parameter | Value | 2607 +========================+============================+ 2608 | Service Name: | dtn-bundle | 2609 +------------------------+----------------------------+ 2610 | Transport Protocol(s): | TCP | 2611 +------------------------+----------------------------+ 2612 | Assignee: | IESG | 2613 +------------------------+----------------------------+ 2614 | Contact: | IESG | 2615 +------------------------+----------------------------+ 2616 | Description: | DTN Bundle TCP CL Protocol | 2617 +------------------------+----------------------------+ 2618 | Reference: | This specification. | 2619 +------------------------+----------------------------+ 2620 | Port Number: | 4556 | 2621 +------------------------+----------------------------+ 2623 Table 10 2625 9.2. Protocol Versions 2627 IANA has created, under the "Bundle Protocol" registry [IANA-BUNDLE], 2628 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2629 Numbers". The version number table is updated to include this 2630 specification. The registration procedure is RFC Required. 2632 +=======+=============+=====================+ 2633 | Value | Description | Reference | 2634 +=======+=============+=====================+ 2635 | 0 | Reserved | [RFC7242] | 2636 +-------+-------------+---------------------+ 2637 | 1 | Reserved | [RFC7242] | 2638 +-------+-------------+---------------------+ 2639 | 2 | Reserved | [RFC7242] | 2640 +-------+-------------+---------------------+ 2641 | 3 | TCPCL | [RFC7242] | 2642 +-------+-------------+---------------------+ 2643 | 4 | TCPCLv4 | This specification. | 2644 +-------+-------------+---------------------+ 2645 | 5-255 | Unassigned | | 2646 +-------+-------------+---------------------+ 2648 Table 11 2650 9.3. Session Extension Types 2652 EDITOR NOTE: sub-registry to-be-created upon publication of this 2653 specification. 2655 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 2656 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2657 4 Session Extension Types" and initialize it with the contents of 2658 Table 12. The registration procedure is Expert Review within the 2659 lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are 2660 reserved for use on private networks for functions not published to 2661 the IANA. 2663 Specifications of new session extension types need to define the 2664 encoding of the Item Value data as well as any meaning or restriction 2665 on the number of or order of instances of the type within an 2666 extension item list. Specifications need to define how the extension 2667 functions when no instance of the new extension type is received 2668 during session negotiation. 2670 Expert(s) are encouraged to be biased towards approving registrations 2671 unless they are abusive, frivolous, or actively harmful (not merely 2672 aesthetically displeasing, or architecturally dubious). 2674 +================+==========================+ 2675 | Code | Session Extension Type | 2676 +================+==========================+ 2677 | 0x0000 | Reserved | 2678 +----------------+--------------------------+ 2679 | 0x0001--0x7FFF | Unassigned | 2680 +----------------+--------------------------+ 2681 | 0x8000--0xFFFF | Private/Experimental Use | 2682 +----------------+--------------------------+ 2684 Table 12: Session Extension Type Codes 2686 9.4. Transfer Extension Types 2688 EDITOR NOTE: sub-registry to-be-created upon publication of this 2689 specification. 2691 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 2692 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2693 4 Transfer Extension Types" and initialize it with the contents of 2694 Table 13. The registration procedure is Expert Review within the 2695 lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are 2696 reserved for use on private networks for functions not published to 2697 the IANA. 2699 Specifications of new transfer extension types need to define the 2700 encoding of the Item Value data as well as any meaning or restriction 2701 on the number of or order of instances of the type within an 2702 extension item list. Specifications need to define how the extension 2703 functions when no instance of the new extension type is received in a 2704 transfer. 2706 Expert(s) are encouraged to be biased towards approving registrations 2707 unless they are abusive, frivolous, or actively harmful (not merely 2708 aesthetically displeasing, or architecturally dubious). 2710 +================+===========================+ 2711 | Code | Transfer Extension Type | 2712 +================+===========================+ 2713 | 0x0000 | Reserved | 2714 +----------------+---------------------------+ 2715 | 0x0001 | Transfer Length Extension | 2716 +----------------+---------------------------+ 2717 | 0x0002--0x7FFF | Unassigned | 2718 +----------------+---------------------------+ 2719 | 0x8000--0xFFFF | Private/Experimental Use | 2720 +----------------+---------------------------+ 2722 Table 13: Transfer Extension Type Codes 2724 9.5. Message Types 2726 EDITOR NOTE: sub-registry to-be-created upon publication of this 2727 specification. 2729 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 2730 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2731 4 Message Types" and initialize it with the contents of Table 14. 2732 The registration procedure is RFC Required within the lower range 2733 0x01--0xEF. Values in the range 0xF0--0xFF are reserved for use on 2734 private networks for functions not published to the IANA. 2736 Specifications of new message types need to define the encoding of 2737 the message data as well as the purpose and relationship of the new 2738 message to existing session/transfer state within the baseline 2739 message sequencing. The use of new message types need to be 2740 negotiated between TCPCL entities within a session (using the session 2741 extension mechanism) so that the receiving entity can properly decode 2742 all message types used in the session. 2744 Expert(s) are encouraged to favor new session/transfer extension 2745 types over new message types. TCPCL messages are not self- 2746 delimiting, so care must be taken in introducing new message types. 2747 If an entity receives an unknown message type the only thing that can 2748 be done is to send a MSG_REJECT and close the TCP connection; not 2749 even a clean termination can be done at that point. 2751 +============+==========================+ 2752 | Code | Message Type | 2753 +============+==========================+ 2754 | 0x00 | Reserved | 2755 +------------+--------------------------+ 2756 | 0x01 | XFER_SEGMENT | 2757 +------------+--------------------------+ 2758 | 0x02 | XFER_ACK | 2759 +------------+--------------------------+ 2760 | 0x03 | XFER_REFUSE | 2761 +------------+--------------------------+ 2762 | 0x04 | KEEPALIVE | 2763 +------------+--------------------------+ 2764 | 0x05 | SESS_TERM | 2765 +------------+--------------------------+ 2766 | 0x06 | MSG_REJECT | 2767 +------------+--------------------------+ 2768 | 0x07 | SESS_INIT | 2769 +------------+--------------------------+ 2770 | 0x08--0xEF | Unassigned | 2771 +------------+--------------------------+ 2772 | 0xF0--0xFF | Private/Experimental Use | 2773 +------------+--------------------------+ 2775 Table 14: Message Type Codes 2777 9.6. XFER_REFUSE Reason Codes 2779 EDITOR NOTE: sub-registry to-be-created upon publication of this 2780 specification. 2782 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 2783 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2784 4 XFER_REFUSE Reason Codes" and initialize it with the contents of 2785 Table 15. The registration procedure is Specification Required 2786 within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF 2787 are reserved for use on private networks for functions not published 2788 to the IANA. 2790 Specifications of new XFER_REFUSE reason codes need to define the 2791 meaning of the reason and disambiguate it with pre-existing reasons. 2792 Each refusal reason needs to be usable by the receiving BP Agent to 2793 make retransmission or re-routing decisions. 2795 Expert(s) are encouraged to be biased towards approving registrations 2796 unless they are abusive, frivolous, or actively harmful (not merely 2797 aesthetically displeasing, or architecturally dubious). 2799 +============+==========================+ 2800 | Code | Refusal Reason | 2801 +============+==========================+ 2802 | 0x00 | Unknown | 2803 +------------+--------------------------+ 2804 | 0x01 | Completed | 2805 +------------+--------------------------+ 2806 | 0x02 | No Resources | 2807 +------------+--------------------------+ 2808 | 0x03 | Retransmit | 2809 +------------+--------------------------+ 2810 | 0x04 | Not Acceptable | 2811 +------------+--------------------------+ 2812 | 0x05 | Extension Failure | 2813 +------------+--------------------------+ 2814 | 0x06 | Session Terminating | 2815 +------------+--------------------------+ 2816 | 0x07--0xEF | Unassigned | 2817 +------------+--------------------------+ 2818 | 0xF0--0xFF | Private/Experimental Use | 2819 +------------+--------------------------+ 2821 Table 15: XFER_REFUSE Reason Codes 2823 9.7. SESS_TERM Reason Codes 2825 EDITOR NOTE: sub-registry to-be-created upon publication of this 2826 specification. 2828 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 2829 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2830 4 SESS_TERM Reason Codes" and initialize it with the contents of 2831 Table 16. The registration procedure is Specification Required 2832 within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF 2833 are reserved for use on private networks for functions not published 2834 to the IANA. 2836 Specifications of new SESS_TERM reason codes need to define the 2837 meaning of the reason and disambiguate it with pre-existing reasons. 2838 Each termination reason needs to be usable by the receiving BP Agent 2839 to make re-connection decisions. 2841 Expert(s) are encouraged to be biased towards approving registrations 2842 unless they are abusive, frivolous, or actively harmful (not merely 2843 aesthetically displeasing, or architecturally dubious). 2845 +============+==========================+ 2846 | Code | Termination Reason | 2847 +============+==========================+ 2848 | 0x00 | Unknown | 2849 +------------+--------------------------+ 2850 | 0x01 | Idle timeout | 2851 +------------+--------------------------+ 2852 | 0x02 | Version mismatch | 2853 +------------+--------------------------+ 2854 | 0x03 | Busy | 2855 +------------+--------------------------+ 2856 | 0x04 | Contact Failure | 2857 +------------+--------------------------+ 2858 | 0x05 | Resource Exhaustion | 2859 +------------+--------------------------+ 2860 | 0x06--0xEF | Unassigned | 2861 +------------+--------------------------+ 2862 | 0xF0--0xFF | Private/Experimental Use | 2863 +------------+--------------------------+ 2865 Table 16: SESS_TERM Reason Codes 2867 9.8. MSG_REJECT Reason Codes 2869 EDITOR NOTE: sub-registry to-be-created upon publication of this 2870 specification. 2872 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 2873 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2874 4 MSG_REJECT Reason Codes" and initialize it with the contents of 2875 Table 17. The registration procedure is Specification Required 2876 within the lower range 0x01--0xEF. Values in the range 0xF0--0xFF 2877 are reserved for use on private networks for functions not published 2878 to the IANA. 2880 Specifications of new MSG_REJECT reason codes need to define the 2881 meaning of the reason and disambiguate it with pre-existing reasons. 2882 Each rejection reason needs to be usable by the receiving TCPCL 2883 Entity to make message sequencing and/or session termination 2884 decisions. 2886 Expert(s) are encouraged to be biased towards approving registrations 2887 unless they are abusive, frivolous, or actively harmful (not merely 2888 aesthetically displeasing, or architecturally dubious). 2890 +============+==========================+ 2891 | Code | Rejection Reason | 2892 +============+==========================+ 2893 | 0x00 | reserved | 2894 +------------+--------------------------+ 2895 | 0x01 | Message Type Unknown | 2896 +------------+--------------------------+ 2897 | 0x02 | Message Unsupported | 2898 +------------+--------------------------+ 2899 | 0x03 | Message Unexpected | 2900 +------------+--------------------------+ 2901 | 0x04--0xEF | Unassigned | 2902 +------------+--------------------------+ 2903 | 0xF0--0xFF | Private/Experimental Use | 2904 +------------+--------------------------+ 2906 Table 17: MSG_REJECT Reason Codes 2908 10. Acknowledgments 2910 This specification is based on comments on implementation of 2911 [RFC7242] provided from Scott Burleigh. 2913 11. References 2915 11.1. Normative References 2917 [IANA-PORTS] 2918 IANA, "Service Name and Transport Protocol Port Number 2919 Registry", . 2922 [IANA-BUNDLE] 2923 IANA, "Bundle Protocol", 2924 . 2926 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2927 RFC 793, DOI 10.17487/RFC0793, September 1981, 2928 . 2930 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2931 Communication Layers", STD 3, RFC 1122, 2932 DOI 10.17487/RFC1122, October 1989, 2933 . 2935 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2936 Requirement Levels", BCP 14, RFC 2119, 2937 DOI 10.17487/RFC2119, March 1997, 2938 . 2940 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2941 Resource Identifier (URI): Generic Syntax", STD 66, 2942 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2943 . 2945 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2946 Housley, R., and W. Polk, "Internet X.509 Public Key 2947 Infrastructure Certificate and Certificate Revocation List 2948 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2949 . 2951 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 2952 Extensions: Extension Definitions", RFC 6066, 2953 DOI 10.17487/RFC6066, January 2011, 2954 . 2956 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2957 Verification of Domain-Based Application Service Identity 2958 within Internet Public Key Infrastructure Using X.509 2959 (PKIX) Certificates in the Context of Transport Layer 2960 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2961 2011, . 2963 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2964 "Recommendations for Secure Use of Transport Layer 2965 Security (TLS) and Datagram Transport Layer Security 2966 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2967 2015, . 2969 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2970 Writing an IANA Considerations Section in RFCs", BCP 26, 2971 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2972 . 2974 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2975 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2976 May 2017, . 2978 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2979 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2980 . 2982 [I-D.ietf-dtn-bpbis] 2983 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 2984 Version 7", Work in Progress, Internet-Draft, draft-ietf- 2985 dtn-bpbis-27, 27 October 2020, 2986 . 2988 11.2. Informative References 2990 [AEAD-LIMITS] 2991 Luykx, A. and K. Paterson, "Limits on Authenticated 2992 Encryption Use in TLS", August 2017, 2993 . 2995 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 2996 RFC 2595, DOI 10.17487/RFC2595, June 1999, 2997 . 2999 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 3000 Text on Security Considerations", BCP 72, RFC 3552, 3001 DOI 10.17487/RFC3552, July 2003, 3002 . 3004 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 3005 Protocol (LDAP): The Protocol", RFC 4511, 3006 DOI 10.17487/RFC4511, June 2006, 3007 . 3009 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 3010 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 3011 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 3012 April 2007, . 3014 [RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for 3015 Transport Layer Security (TLS)", RFC 5489, 3016 DOI 10.17487/RFC5489, March 2009, 3017 . 3019 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 3020 of Named Entities (DANE) Transport Layer Security (TLS) 3021 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 3022 2012, . 3024 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 3025 Galperin, S., and C. Adams, "X.509 Internet Public Key 3026 Infrastructure Online Certificate Status Protocol - OCSP", 3027 RFC 6960, DOI 10.17487/RFC6960, June 2013, 3028 . 3030 [RFC7122] Kruse, H., Jero, S., and S. Ostermann, "Datagram 3031 Convergence Layers for the Delay- and Disruption-Tolerant 3032 Networking (DTN) Bundle Protocol and Licklider 3033 Transmission Protocol (LTP)", RFC 7122, 3034 DOI 10.17487/RFC7122, March 2014, 3035 . 3037 [RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant 3038 Networking TCP Convergence-Layer Protocol", RFC 7242, 3039 DOI 10.17487/RFC7242, June 2014, 3040 . 3042 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 3043 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 3044 Transport Layer Security (TLS) and Datagram Transport 3045 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 3046 June 2014, . 3048 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 3049 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 3050 December 2014, . 3052 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 3053 Known Attacks on Transport Layer Security (TLS) and 3054 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 3055 February 2015, . 3057 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 3058 Code: The Implementation Status Section", BCP 205, 3059 RFC 7942, DOI 10.17487/RFC7942, July 2016, 3060 . 3062 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 3063 Kasten, "Automatic Certificate Management Environment 3064 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 3065 . 3067 [I-D.ietf-dtn-bpsec] 3068 Birrane, E. and K. McKeever, "Bundle Protocol Security 3069 Specification", Work in Progress, Internet-Draft, draft- 3070 ietf-dtn-bpsec-23, 25 October 2020, 3071 . 3073 [I-D.ietf-dtn-bibect] 3074 Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in 3075 Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18 3076 February 2020, 3077 . 3079 [github-dtn-bpbis-tcpcl] 3080 Sipos, B., "TCPCL Example Implementation", 3081 . 3083 Appendix A. Significant changes from RFC7242 3085 The areas in which changes from [RFC7242] have been made to existing 3086 headers and messages are: 3088 * Split Contact Header into pre-TLS protocol negotiation and 3089 SESS_INIT parameter negotiation. The Contact Header is now fixed- 3090 length. 3092 * Changed Contact Header content to limit number of negotiated 3093 options. 3095 * Added session option to negotiate maximum segment size (per each 3096 direction). 3098 * Renamed "Endpoint ID" to "Node ID" to conform with BPv7 3099 terminology. 3101 * Added session extension capability. 3103 * Added transfer extension capability. Moved transfer total length 3104 into an extension item. 3106 * Defined new IANA registries for message / type / reason codes to 3107 allow renaming some codes for clarity. 3109 * Segments of all new IANA registries are reserved for private/ 3110 experimental use. 3112 * Expanded Message Header to octet-aligned fields instead of bit- 3113 packing. 3115 * Added a bundle transfer identification number to all bundle- 3116 related messages (XFER_SEGMENT, XFER_ACK, XFER_REFUSE). 3118 * Use flags in XFER_ACK to mirror flags from XFER_SEGMENT. 3120 * Removed all uses of SDNV fields and replaced with fixed-bit-length 3121 (network byte order) fields. 3123 * Renamed SHUTDOWN to SESS_TERM to deconflict term "shutdown" 3124 related to TCP connections. 3126 * Removed the notion of a re-connection delay parameter. 3128 The areas in which extensions from [RFC7242] have been made as new 3129 messages and codes are: 3131 * Added contact negotiation failure SESS_TERM reason code. 3133 * Added MSG_REJECT message to indicate an unknown or unhandled 3134 message was received. 3136 * Added TLS connection security mechanism. 3138 * Added "Not Acceptable", "Extension Failure", and "Session 3139 Terminating" XFER_REFUSE reason codes. 3141 * Added "Resource Exhaustion" SESS_TERM reason code. 3143 Authors' Addresses 3145 Brian Sipos 3146 RKF Engineering Solutions, LLC 3147 7500 Old Georgetown Road 3148 Suite 1275 3149 Bethesda, MD 20814-6198 3150 United States of America 3152 Email: BSipos@rkf-eng.com 3154 Michael Demmer 3155 University of California, Berkeley 3156 Computer Science Division 3157 445 Soda Hall 3158 Berkeley, CA 94720-1776 3159 United States of America 3161 Email: demmer@cs.berkeley.edu 3163 Joerg Ott 3164 Aalto University 3165 Department of Communications and Networking 3166 PO Box 13000 3167 FI-02015 Aalto 3168 Finland 3170 Email: ott@in.tum.de 3171 Simon Perreault 3172 Quebec QC 3173 Canada 3175 Email: simon@per.reau.lt