idnits 2.17.1 draft-ietf-dtn-tcpclv4-25.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 (1 February 2021) is 1181 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 682, but not defined == Missing Reference: 'ST' is mentioned on line 804, but not defined == Missing Reference: 'PSI' is mentioned on line 737, but not defined == Missing Reference: 'SI' is mentioned on line 716, but not defined == Missing Reference: 'I1' is mentioned on line 1020, but not defined == Missing Reference: 'L1' is mentioned on line 1008, but not defined == Missing Reference: 'L2' is mentioned on line 1008, but not defined == Missing Reference: 'L3' is mentioned on line 1014, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-BUNDLE' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-PORTS' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-SMI' ** 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-30 == Outdated reference: A later version (-27) exists of draft-ietf-dtn-bpsec-26 Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 4 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: 5 August 2021 UC Berkeley 6 J. Ott 7 Aalto University 8 S. Perreault 9 1 February 2021 11 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 12 draft-ietf-dtn-tcpclv4-25 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 5 August 2021. 43 Copyright Notice 45 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . 12 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. Certificate Profile for TCPCL . . . . . . . . . . . . 29 78 4.4.3. TLS Handshake . . . . . . . . . . . . . . . . . . . . 31 79 4.4.4. TLS Authentication . . . . . . . . . . . . . . . . . 32 80 4.4.5. Policy Recommendations . . . . . . . . . . . . . . . 33 81 4.4.6. Example TLS Initiation . . . . . . . . . . . . . . . 34 82 4.5. Message Header . . . . . . . . . . . . . . . . . . . . . 36 83 4.6. Session Initialization Message (SESS_INIT) . . . . . . . 37 84 4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 39 85 4.8. Session Extension Items . . . . . . . . . . . . . . . . . 40 86 5. Established Session Operation . . . . . . . . . . . . . . . . 41 87 5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 41 88 5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 41 89 5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 42 90 5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 44 91 5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 45 92 5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 45 93 5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 47 94 5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 49 95 5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 51 97 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 53 98 6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 53 99 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 56 100 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 56 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 57 102 8.1. Threat: Passive Leak of Node Data . . . . . . . . . . . . 57 103 8.2. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 57 104 8.3. Threat: TCPCL Version Downgrade . . . . . . . . . . . . . 57 105 8.4. Threat: Transport Security Stripping . . . . . . . . . . 57 106 8.5. Threat: Weak TLS Configurations . . . . . . . . . . . . . 58 107 8.6. Threat: Untrusted End-Entity Certificate . . . . . . . . 58 108 8.7. Threat: Certificate Validation Vulnerabilities . . . . . 58 109 8.8. Threat: Symmetric Key Limits . . . . . . . . . . . . . . 59 110 8.9. Threat: BP Node Impersonation . . . . . . . . . . . . . . 59 111 8.10. Threat: Denial of Service . . . . . . . . . . . . . . . . 60 112 8.11. Mandatory-to-Implement TLS . . . . . . . . . . . . . . . 61 113 8.12. Alternate Uses of TLS . . . . . . . . . . . . . . . . . . 61 114 8.12.1. TLS Without Authentication . . . . . . . . . . . . . 61 115 8.12.2. Non-Certificate TLS Use . . . . . . . . . . . . . . 61 116 8.13. Predictability of Transfer IDs . . . . . . . . . . . . . 62 117 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 118 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 62 119 9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 63 120 9.3. Session Extension Types . . . . . . . . . . . . . . . . . 64 121 9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 64 122 9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 65 123 9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 66 124 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 67 125 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 68 126 9.9. Object Identifier for PKIX Extended Key Usage . . . . . . 69 127 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69 128 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 70 129 11.1. Normative References . . . . . . . . . . . . . . . . . . 70 130 11.2. Informative References . . . . . . . . . . . . . . . . . 71 131 Appendix A. Significant changes from RFC7242 . . . . . . . . . . 74 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75 134 1. Introduction 136 This document describes the TCP-based convergence-layer protocol for 137 Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to- 138 end architecture providing communications in and/or through highly 139 stressed environments, including those with intermittent 140 connectivity, long and/or variable delays, and high bit error rates. 141 More detailed descriptions of the rationale and capabilities of these 142 networks can be found in "Delay-Tolerant Network Architecture" 143 [RFC4838]. 145 An important goal of the DTN architecture is to accommodate a wide 146 range of networking technologies and environments. The protocol used 147 for DTN communications is the Bundle Protocol Version 7 (BPv7) 148 [I-D.ietf-dtn-bpbis], an application-layer protocol that is used to 149 construct a store-and-forward overlay network. BPv7 requires the 150 services of a "convergence-layer adapter" (CLA) to send and receive 151 bundles using the service of some "native" link, network, or Internet 152 protocol. This document describes one such convergence-layer adapter 153 that uses the well-known Transmission Control Protocol (TCP). This 154 convergence layer is referred to as TCP Convergence Layer Version 4 155 (TCPCLv4). For the remainder of this document, the abbreviation "BP" 156 without the version suffix refers to BPv7. For the remainder of this 157 document, the abbreviation "TCPCL" without the version suffix refers 158 to TCPCLv4. 160 The locations of the TCPCL and the BP in the Internet model protocol 161 stack (described in [RFC1122]) are shown in Figure 1. In particular, 162 when BP is using TCP as its bearer with TCPCL as its convergence 163 layer, both BP and TCPCL reside at the application layer of the 164 Internet model. 166 +-------------------------+ 167 | DTN Application | -\ 168 +-------------------------| | 169 | Bundle Protocol (BP) | -> Application Layer 170 +-------------------------+ | 171 | TCP Conv. Layer (TCPCL) | | 172 +-------------------------+ | 173 | TLS (optional) | -/ 174 +-------------------------+ 175 | TCP | ---> Transport Layer 176 +-------------------------+ 177 | IPv4/IPv6 | ---> Network Layer 178 +-------------------------+ 179 | Link-Layer Protocol | ---> Link Layer 180 +-------------------------+ 182 Figure 1: The Locations of the Bundle Protocol and the TCP 183 Convergence-Layer Protocol above the Internet Protocol Stack 185 1.1. Scope 187 This document describes the format of the protocol data units passed 188 between entities participating in TCPCL communications. This 189 document does not address: 191 * The format of protocol data units of the Bundle Protocol, as those 192 are defined elsewhere in [I-D.ietf-dtn-bpbis]. This includes the 193 concept of bundle fragmentation or bundle encapsulation. The 194 TCPCL transfers bundles as opaque data blocks. 196 * Mechanisms for locating or identifying other bundle entities 197 (peers) within a network or across an internet. The mapping of 198 Node ID to potential convergence layer (CL) protocol and network 199 address is left to implementation and configuration of the BP 200 Agent and its various potential routing strategies. The mapping 201 of DNS name and/or address to a choice of end-entity certificate 202 to authenticate a node to its peers. 204 * Logic for routing bundles along a path toward a bundle's endpoint. 205 This CL protocol is involved only in transporting bundles between 206 adjacent entities in a routing sequence. 208 * Policies or mechanisms for issuing Public Key Infrastructure Using 209 X.509 (PKIX) certificates; provisioning, deploying, or accessing 210 certificates and private keys; deploying or accessing certificate 211 revocation lists (CRLs); or configuring security parameters on an 212 individual entity or across a network. 214 * Uses of TLS which are not based on PKIX certificate authentication 215 (see Section 8.12.2) or in which authentication of both entities 216 is not possible (see Section 8.12.1). 218 Any TCPCL implementation requires a BP agent to perform those above 219 listed functions in order to perform end-to-end bundle delivery. 221 2. Requirements Language 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 225 "OPTIONAL" in this document are to be interpreted as described in BCP 226 14 [RFC2119] [RFC8174] when, and only when, they appear in all 227 capitals, as shown here. 229 2.1. Definitions Specific to the TCPCL Protocol 231 This section contains definitions specific to the TCPCL protocol. 233 Network Byte Order: Most significant byte first, a.k.a., big endian. 234 All of the integer encodings in this protocol SHALL be transmitted 235 in network byte order. 237 TCPCL Entity: This is the notional TCPCL application that initiates 238 TCPCL sessions. This design, implementation, configuration, and 239 specific behavior of such an entity is outside of the scope of 240 this document. However, the concept of an entity has utility 241 within the scope of this document as the container and initiator 242 of TCPCL sessions. The relationship between a TCPCL entity and 243 TCPCL sessions is defined as follows: 245 * A TCPCL Entity MAY actively initiate any number of TCPCL 246 Sessions and should do so whenever the entity is the initial 247 transmitter of information to another entity in the network. 249 * A TCPCL Entity MAY support zero or more passive listening 250 elements that listen for connection requests from other TCPCL 251 Entities operating on other entities in the network. 253 * A TCPCL Entity MAY passively initiate any number of TCPCL 254 Sessions from requests received by its passive listening 255 element(s) if the entity uses such elements. 257 These relationships are illustrated in Figure 2. For most TCPCL 258 behavior within a session, the two entities are symmetric and 259 there is no protocol distinction between them. Some specific 260 behavior, particularly during session establishment, distinguishes 261 between the active entity and the passive entity. For the 262 remainder of this document, the term "entity" without the prefix 263 "TCPCL" refers to a TCPCL entity. 265 TCP Connection: The term Connection in this specification 266 exclusively refers to a TCP connection and any and all behaviors, 267 sessions, and other states associated with that TCP connection. 269 TCPCL Session: A TCPCL session (as opposed to a TCP connection) is a 270 TCPCL communication relationship between two TCPCL entities. A 271 TCPCL session operates within a single underlying TCP connection 272 and the lifetime of a TCPCL session is bound to the lifetime of 273 that TCP connection. A TCPCL session is terminated when the TCP 274 connection ends, due either to one or both entities actively 275 closing the TCP connection or due to network errors causing a 276 failure of the TCP connection. Within a single TCPCL session 277 there are two possible transfer streams; one in each direction, 278 with one stream from each entity being the outbound stream and the 279 other being the inbound stream (see Figure 3). From the 280 perspective of a TCPCL session, the two transfer streams do not 281 logically interact with each other. The streams do operate over 282 the same TCP connection and between the same BP agents, so there 283 are logical relationships at those layers (message and bundle 284 interleaving respectively). For the remainder of this document, 285 the term "session" without the prefix "TCPCL" refers to a TCPCL 286 session. 288 Session parameters: These are a set of values used to affect the 289 operation of the TCPCL for a given session. The manner in which 290 these parameters are conveyed to the bundle entity and thereby to 291 the TCPCL is implementation dependent. However, the mechanism by 292 which two entities exchange and negotiate the values to be used 293 for a given session is described in Section 4.3. 295 Transfer Stream: A Transfer stream is a uni-directional user-data 296 path within a TCPCL Session. Transfers sent over a transfer 297 stream are serialized, meaning that one transfer must complete its 298 transmission prior to another transfer being started over the same 299 transfer stream. At the stream layer there is no logical 300 relationship between transfers in that stream; it's only within 301 the BP agent that transfers are fully decoded as bundles. Each 302 uni-directional stream has a single sender entity and a single 303 receiver entity. 305 Transfer: This refers to the procedures and mechanisms for 306 conveyance of an individual bundle from one node to another. Each 307 transfer within TCPCL is identified by a Transfer ID number which 308 is guaranteed to be unique only to a single direction within a 309 single Session. 311 Transfer Segment: A subset of a transfer of user data being 312 communicated over a transfer stream. 314 Idle Session: A TCPCL session is idle while there is no transmission 315 in-progress in either direction. While idle, the only messages 316 being transmitted or received are KEEPALIVE messages. 318 Live Session: A TCPCL session is live while there is a transmission 319 in-progress in either direction. 321 Reason Codes: The TCPCL uses numeric codes to encode specific 322 reasons for individual failure/error message types. 324 The relationship between connections, sessions, and streams is shown 325 in Figure 3. 327 +--------------------------------------------+ 328 | TCPCL Entity | 329 | | +----------------+ 330 | +--------------------------------+ | | |-+ 331 | | Actively Initiated Session #1 +------------->| Other | | 332 | +--------------------------------+ | | TCPCL Entity's | | 333 | ... | | Passive | | 334 | +--------------------------------+ | | Listener | | 335 | | Actively Initiated Session #n +------------->| | | 336 | +--------------------------------+ | +----------------+ | 337 | | +-----------------+ 338 | +---------------------------+ | 339 | +---| +---------------------------+ | +----------------+ 340 | | | | Optional Passive | | | |-+ 341 | | +-| Listener(s) +<-------------+ | | 342 | | +---------------------------+ | | | | 343 | | | | Other | | 344 | | +---------------------------------+ | | TCPCL Entity's | | 345 | +--->| Passively Initiated Session #1 +-------->| Active | | 346 | | +---------------------------------+ | | Initiator(s) | | 347 | | | | | | 348 | | +---------------------------------+ | | | | 349 | +--->| Passively Initiated Session #n +-------->| | | 350 | +---------------------------------+ | +----------------+ | 351 | | +-----------------+ 352 +--------------------------------------------+ 354 Figure 2: The relationships between TCPCL entities 356 +---------------------------+ +---------------------------+ 357 | "Own" TCPCL Session | | "Other" TCPCL Session | 358 | | | | 359 | +----------------------+ | | +----------------------+ | 360 | | TCP Connection | | | | TCP Connection | | 361 | | | | | | | | 362 | | +-----------------+ | | Messages | | +-----------------+ | | 363 | | | Own Inbound | +--------------------+ | Peer Outbound | | | 364 | | | Transfer Stream | | Transfer Stream | | | 365 | | | ----- |<---[Seg]--[Seg]--[Seg]---| ----- | | | 366 | | | RECEIVER |---[Ack]----[Ack]-------->| SENDER | | | 367 | | +-----------------+ +-----------------+ | | 368 | | | | 369 | | +-----------------+ +-----------------+ | | 370 | | | Own Outbound |-------[Seg]---[Seg]----->| Peer Inbound | | | 371 | | | Transfer Stream |<---[Ack]----[Ack]-[Ack]--| Transfer Stream | | | 372 | | | ----- | | ----- | | | 373 | | | SENDER | +--------------------+ | RECEIVER | | | 374 | | +-----------------+ | | | | +-----------------+ | | 375 | +-----------------------+ | | +---------------------+ | 376 +----------------------------+ +--------------------------+ 378 Figure 3: The relationship within a TCPCL Session of its two streams 380 3. General Protocol Description 382 The service of this protocol is the transmission of DTN bundles via 383 the Transmission Control Protocol (TCP). This document specifies the 384 encapsulation of bundles, procedures for TCP setup and teardown, and 385 a set of messages and entity requirements. The general operation of 386 the protocol is as follows. 388 3.1. Convergence Layer Services 390 This version of the TCPCL provides the following services to support 391 the overlaying Bundle Protocol agent. In all cases, this is not an 392 API definition but a logical description of how the CL can interact 393 with the BP agent. Each of these interactions can be associated with 394 any number of additional metadata items as necessary to support the 395 operation of the CL or BP agent. 397 Attempt Session: The TCPCL allows a BP agent to preemptively attempt 398 to establish a TCPCL session with a peer entity. Each session 399 attempt can send a different set of session negotiation parameters 400 as directed by the BP agent. 402 Terminate Session: The TCPCL allows a BP agent to preemptively 403 terminate an established TCPCL session with a peer entity. The 404 terminate request is on a per-session basis. 406 Session State Changed: The TCPCL entity indicates to the BP agent 407 when the session state changes. The top-level session states 408 indicated are: 410 Connecting: A TCP connection is being established. This state 411 only applies to the active entity. 413 Contact Negotiating: A TCP connection has been made (as either 414 active or passive entity) and contact negotiation has begun. 416 Session Negotiating: Contact negotiation has been completed 417 (including possible TLS use) and session negotiation has begun. 419 Established: The session has been fully established and is ready 420 for its first transfer. When the session is established, the 421 peer Node ID (along with indication of whether or not it was 422 authenticated) and the negotiated session parameters (see 423 Section 4.7) are also communicated to the BP agent. 425 Ending: The entity sent SESS_TERM message and is in the ending 426 state. 428 Terminated: The session has finished normal termination 429 sequencing. 431 Failed: The session ended without normal termination sequencing. 433 Session Idle Changed: The TCPCL entity indicates to the BP agent 434 when the live/idle sub-state of the session changes. This occurs 435 only when the top-level session state is "Established". The 436 session transitions from Idle to Live at the at the start of a 437 transfer in either transfer stream; the session transitions from 438 Live to Idle at the end of a transfer when the other transfer 439 stream does not have an ongoing transfer. Because TCPCL transmits 440 serially over a TCP connection it suffers from "head of queue 441 blocking," so a transfer in either direction can block an 442 immediate start of a new transfer in the session. 444 Begin Transmission: The principal purpose of the TCPCL is to allow a 445 BP agent to transmit bundle data over an established TCPCL 446 session. Transmission request is on a per-session basis and the 447 CL does not necessarily perform any per-session or inter-session 448 queueing. Any queueing of transmissions is the obligation of the 449 BP agent. 451 Transmission Success: The TCPCL entity indicates to the BP agent 452 when a bundle has been fully transferred to a peer entity. 454 Transmission Intermediate Progress: The TCPCL entity indicates to 455 the BP agent on intermediate progress of transfer to a peer 456 entity. This intermediate progress is at the granularity of each 457 transferred segment. 459 Transmission Failure: The TCPCL entity indicates to the BP agent on 460 certain reasons for bundle transmission failure, notably when the 461 peer entity rejects the bundle or when a TCPCL session ends before 462 transfer success. The TCPCL itself does not have a notion of 463 transfer timeout. 465 Reception Initialized: The TCPCL entity indicates to the receiving 466 BP agent just before any transmission data is sent. This 467 corresponds to reception of the XFER_SEGMENT message with the 468 START flag of 1. 470 Interrupt Reception: The TCPCL entity allows a BP agent to interrupt 471 an individual transfer before it has fully completed (successfully 472 or not). Interruption can occur any time after the reception is 473 initialized. 475 Reception Success: The TCPCL entity indicates to the BP agent when a 476 bundle has been fully transferred from a peer entity. 478 Reception Intermediate Progress: The TCPCL entity indicates to the 479 BP agent on intermediate progress of transfer from the peer 480 entity. This intermediate progress is at the granularity of each 481 transferred segment. Intermediate reception indication allows a 482 BP agent the chance to inspect bundle header contents before the 483 entire bundle is available, and thus supports the "Reception 484 Interruption" capability. 486 Reception Failure: The TCPCL entity indicates to the BP agent on 487 certain reasons for reception failure, notably when the local 488 entity rejects an attempted transfer for some local policy reason 489 or when a TCPCL session ends before transfer success. The TCPCL 490 itself does not have a notion of transfer timeout. 492 3.2. TCPCL Session Overview 494 First, one entity establishes a TCPCL session to the other by 495 initiating a TCP connection in accordance with [RFC0793]. After 496 setup of the TCP connection is complete, an initial Contact Header is 497 exchanged in both directions to establish a shared TCPCL version and 498 negotiate the use of TLS security (as described in Section 4). Once 499 contact negotiation is complete, TCPCL messaging is available and the 500 session negotiation is used to set parameters of the TCPCL session. 501 One of these parameters is a Node ID that each TCPCL Entity is acting 502 as. This is used to assist in routing and forwarding messages by the 503 BP Agent and is part of the authentication capability provided by 504 TLS. 506 Once negotiated, the parameters of a TCPCL session cannot change and 507 if there is a desire by either peer to transfer data under different 508 parameters then a new session must be established. This makes CL 509 logic simpler but relies on the assumption that establishing a TCP 510 connection is lightweight enough that TCP connection overhead is 511 negligible compared to TCPCL data sizes. 513 Once the TCPCL session is established and configured in this way, 514 bundles can be transferred in either direction. Each transfer is 515 performed by segmenting the transfer data into one or more 516 XFER_SEGMENT messages. Multiple bundles can be transmitted 517 consecutively in a single direction on a single TCPCL connection. 518 Segments from different bundles are never interleaved. Bundle 519 interleaving can be accomplished by fragmentation at the BP layer or 520 by establishing multiple TCPCL sessions between the same peers. 521 There is no fundamental limit on the number of TCPCL sessions which a 522 single entity can establish beyond the limit imposed by the number of 523 available (ephemeral) TCP ports of the active entity. 525 A feature of this protocol is for the receiving entity to send 526 acknowledgment (XFER_ACK) messages as bundle data segments arrive. 527 The rationale behind these acknowledgments is to enable the 528 transmitting entity to determine how much of the bundle has been 529 received, so that in case the session is interrupted, it can perform 530 reactive fragmentation to avoid re-sending the already transmitted 531 part of the bundle. In addition, there is no explicit flow control 532 on the TCPCL layer. 534 A TCPCL receiver can interrupt the transmission of a bundle at any 535 point in time by replying with a XFER_REFUSE message, which causes 536 the sender to stop transmission of the associated bundle (if it 537 hasn't already finished transmission). Note: This enables a cross- 538 layer optimization in that it allows a receiver that detects that it 539 already has received a certain bundle to interrupt transmission as 540 early as possible and thus save transmission capacity for other 541 bundles. 543 For sessions that are idle, a KEEPALIVE message is sent at a 544 negotiated interval. This is used to convey entity live-ness 545 information during otherwise message-less time intervals. 547 A SESS_TERM message is used to initiate the ending of a TCPCL session 548 (see Section 6.1). During termination sequencing, in-progress 549 transfers can be completed but no new transfers can be initiated. A 550 SESS_TERM message can also be used to refuse a session setup by a 551 peer (see Section 4.3). Regardless of the reason, session 552 termination is initiated by one of the entities and responded-to by 553 the other as illustrated by Figure 13 and Figure 14. Even when there 554 are no transfers queued or in-progress, the session termination 555 procedure allows each entity to distinguish between a clean end to a 556 session and the TCP connection being closed because of some 557 underlying network issue. 559 Once a session is established, TCPCL is a symmetric protocol between 560 the peers. Both sides can start sending data segments in a session, 561 and one side's bundle transfer does not have to complete before the 562 other side can start sending data segments on its own. Hence, the 563 protocol allows for a bi-directional mode of communication. Note 564 that in the case of concurrent bidirectional transmission, 565 acknowledgment segments MAY be interleaved with data segments. 567 3.3. TCPCL States and Transitions 569 The states of a normal TCPCL session (i.e., without session failures) 570 are indicated in Figure 4. 572 +-------+ 573 | START | 574 +-------+ 575 | 576 TCP Establishment 577 | 578 V 579 +-----------+ +---------------------+ 580 | TCP |----------->| Contact / Session | 581 | Connected | | Negotiation | 582 +-----------+ +---------------------+ 583 | 584 +-----Session Parameters-----+ 585 | Negotiated 586 V 587 +-------------+ +-------------+ 588 | Established |----New Transfer---->| Established | 589 | Session | | Session | 590 | Idle |<---Transfers Done---| Live | 591 +-------------+ +-------------+ 592 | | 593 +------------------------------------+ 594 | 595 V 596 +-------------+ 597 | Established | +-------------+ 598 | Session |----Transfers------>| TCP | 599 | Ending | Done | Terminating | 600 +-------------+ +-------------+ 601 | 602 +----------TCP Close Message----------+ 603 | 604 V 605 +-------+ 606 | END | 607 +-------+ 609 Figure 4: Top-level states of a TCPCL session 611 Notes on Established Session states: 613 Session "Live" means transmitting or receiving over a transfer 614 stream. 616 Session "Idle" means no transmission/reception over a transfer 617 stream. 619 Session "Ending" means no new transfers will be allowed. 621 Contact negotiation involves exchanging a Contact Header (CH) in both 622 directions and deriving a negotiated state from the two headers. The 623 contact negotiation sequencing is performed either as the active or 624 passive entity, and is illustrated in Figure 5 and Figure 6 625 respectively which both share the data validation and negotiation of 626 the Processing of Contact Header "[PCH]" activity of Figure 7 and the 627 "[TCPCLOSE]" activity which indicates TCP connection close. 628 Successful negotiation results in one of the Session Initiation 629 "[SI]" activities being performed. To avoid data loss, a Session 630 Termination "[ST]" exchange allows cleanly finishing transfers before 631 a session is ended. 633 +-------+ 634 | START | 635 +-------+ 636 | 637 TCP Connecting 638 V 639 +-----------+ 640 | TCP | +---------+ 641 | Connected |--Send CH-->| Waiting |--Timeout-->[TCPCLOSE] 642 +-----------+ +---------+ 643 | 644 Received CH 645 V 646 [PCH] 648 Figure 5: Contact Initiation as Active Entity 650 +-----------+ +---------+ 651 | TCP |--Wait for-->| Waiting |--Timeout-->[TCPCLOSE] 652 | Connected | CH +---------+ 653 +-----------+ | 654 Received CH 655 V 656 +-----------------+ 657 | Preparing reply |--Send CH-->[PCH] 658 +-----------------+ 660 Figure 6: Contact Initiation as Passive Entity 661 +-----------+ 662 | Peer CH | 663 | available | 664 +-----------+ 665 | 666 Validate and 667 Negotiate 668 V 669 +------------+ 670 | Negotiated |--Failure-->[TCPCLOSE] 671 +------------+ 672 | | 673 No TLS +----Negotiate---+ [ST] 674 | TLS | ^ 675 V | Failure 676 +-----------+ V | 677 | TCPCL | +---------------+ 678 | Messaging |<--Success--| TLS Handshake | 679 | Available | +---------------+ 680 +-----------+ 682 Figure 7: Processing of Contact Header [PCH] 684 Session negotiation involves exchanging a session initialization 685 (SESS_INIT) message in both directions and deriving a negotiated 686 state from the two messages. The session negotiation sequencing is 687 performed either as the active or passive entity, and is illustrated 688 in Figure 8 and Figure 9 respectively which both share the data 689 validation and negotiation of Figure 10. The validation here 690 includes certificate validation and authentication when TLS is used 691 for the session. 693 +-----------+ 694 | TCPCL | +---------+ 695 | Messaging |--Send SESS_INIT-->| Waiting |--Timeout-->[ST] 696 | Available | +---------+ 697 +-----------+ | 698 Received SESS_INIT 699 | 700 V 701 [PSI] 703 Figure 8: Session Initiation [SI] as Active Entity 705 +-----------+ 706 | TCPCL | +---------+ 707 | Messaging |----Wait for ---->| Waiting |--Timeout-->[ST] 708 | Available | SESS_INIT +---------+ 709 +-----------+ | 710 Received SESS_INIT 711 | 712 +-----------------+ 713 | Preparing reply |--Send SESS_INIT-->[PSI] 714 +-----------------+ 716 Figure 9: Session Initiation [SI] as Passive Entity 718 +----------------+ 719 | Peer SESS_INIT | 720 | available | 721 +----------------+ 722 | 723 Validate and 724 Negotiate 725 V 726 +------------+ 727 | Negotiated |---Failure--->[ST] 728 +------------+ 729 | 730 Success 731 V 732 +--------------+ 733 | Established | 734 | Session Idle | 735 +--------------+ 737 Figure 10: Processing of Session Initiation [PSI] 739 Transfers can occur after a session is established and it's not in 740 the Ending state. Each transfer occurs within a single logical 741 transfer stream between a sender and a receiver, as illustrated in 742 Figure 11 and Figure 12 respectively. 744 +--Send XFER_SEGMENT--+ 745 +--------+ | | 746 | Stream | +-------------+ | 747 | Idle |---Send XFER_SEGMENT-->| In Progress |<------------+ 748 +--------+ +-------------+ 749 | 750 +---------All segments sent-------+ 751 | 752 V 753 +---------+ +--------+ 754 | Waiting |---- Receive Final---->| Stream | 755 | for Ack | XFER_ACK | IDLE | 756 +---------+ +--------+ 758 Figure 11: Transfer sender states 760 Notes on transfer sending: 762 Pipelining of transfers can occur when the sending entity begins a 763 new transfer while in the "Waiting for Ack" state. 765 +-Receive XFER_SEGMENT-+ 766 +--------+ | Send XFER_ACK | 767 | Stream | +-------------+ | 768 | Idle |--Receive XFER_SEGMENT-->| In Progress |<-------------+ 769 +--------+ +-------------+ 770 | 771 +--------Sent Final XFER_ACK--------+ 772 | 773 V 774 +--------+ 775 | Stream | 776 | Idle | 777 +--------+ 779 Figure 12: Transfer receiver states 781 Session termination involves one entity initiating the termination of 782 the session and the other entity acknowledging the termination. For 783 either entity, it is the sending of the SESS_TERM message which 784 transitions the session to the Ending substate. While a session is 785 in the Ending state only in-progress transfers can be completed and 786 no new transfers can be started. 788 +-----------+ +---------+ 789 | Session |--Send SESS_TERM-->| Session | 790 | Live/Idle | | Ending | 791 +-----------+ +---------+ 793 Figure 13: Session Termination [ST] from the Initiator 795 +-----------+ +---------+ 796 | Session |--Send SESS_TERM-->| Session | 797 | Live/Idle | | Ending | 798 +-----------+<------+ +---------+ 799 | | 800 Receive SESS_TERM | 801 | | 802 +-------------+ 804 Figure 14: Session Termination [ST] from the Responder 806 3.4. PKIX Environments and CA Policy 808 This specification gives requirements about how to use PKIX 809 certificates issued by a Certificate Authority (CA), but does not 810 define any mechanisms for how those certificates come to be. The 811 requirements about TCPCL certificate use are broad to support two 812 quite different PKIX environments: 814 DTN-Aware CAs: In the ideal case, the CA(s) issuing certificates for 815 TCPCL entities are aware of the end use of the certificate, have a 816 mechanism for verifying ownership of a Node ID, and are issuing 817 certificates directly for that Node ID. In this environment, the 818 ability to authenticate a peer entity Node ID directly avoids the 819 need to authenticate a network name or address and then implicitly 820 trust Node ID of the peer. The TCPCL authenticates the Node ID 821 whenever possible and this is preferred over lower-level PKIX 822 identities. 824 DTN-Ignorant CAs: It is expected that Internet-scale "public" CAs 825 will continue to focus on DNS names as the preferred PKIX 826 identifier. There are large infrastructures already in-place for 827 managing network-level authentication and protocols to manage 828 identity verification in those environments [RFC8555]. The TCPCL 829 allows for this type of environment by authenticating a lower- 830 level identifier for a peer and requiring the entity to trust that 831 the Node ID given by the peer (during session initialization) is 832 valid. This situation is not ideal, as it allows vulnerabilities 833 described in Section 8.9, but still provides some amount of mutual 834 authentication to take place for a TCPCL session. 836 Even within a single TCPCL session, each entity may operate within 837 different PKI environments and with different identifier limitations. 838 The requirements related to identifiers in in a PKIX certificate are 839 in Section 4.4.1. 841 It is important for interoperability that a TCPCL entity have its own 842 security policy tailored to accommodate the peers with which it is 843 expected to operate. Some security policy recommendations are given 844 in Section 4.4.5 but these are meant as a starting point for 845 tailoring. A strict TLS security policy is appropriate for a private 846 network with a single shared CA. Operation on the Internet (such as 847 inter-site BP gateways) could trade more lax TCPCL security with the 848 use of encrypted bundle encapsulation [I-D.ietf-dtn-bibect] to ensure 849 strong bundle security. 851 By using the Server Name Indication (SNI) DNS name (see 852 Section 4.4.3) a single passive entity can act as a convergence layer 853 for multiple BP agents with distinct Node IDs. When this "virtual 854 host" behavior is used, the DNS name is used as the indication of 855 which BP Node the active entity is attempting to communicate with. A 856 virtual host CL entity can be authenticated by a certificate 857 containing all of the DNS names and/or Node IDs being hosted or by 858 several certificates each authenticating a single DNS name and/or 859 Node ID, using the SNI value from the peer to select which 860 certificate to use. The logic for mapping an SNI DNS name to an end- 861 entity certificate is an implementation matter, and can involve 862 correlating DNS name with Node ID or other certificate attributes. 864 3.5. Session Keeping Policies 866 This specification gives requirements about how to initiate, sustain, 867 and terminate a TCPCL session but does not impose any requirements on 868 how sessions need to be managed by a BP agent. It is a network 869 administration matter to determine an appropriate session keeping 870 policy, but guidance given here can be used to steer policy toward 871 performance goals. 873 Persistent Session: This policy preemptively establishes a single 874 session to known entities in the network and keeps the session 875 active using KEEPALIVEs. Benefits of this policy include reducing 876 the total amount of TCP data needing to be exchanged for a set of 877 transfers (assuming KEEPALIVE size is significantly smaller than 878 transfer size), and allowing the session state to indicate peer 879 connectivity. Drawbacks include wasted network resources when a 880 session is mostly idle or when the network connectivity is 881 inconsistent (which requires re-establishing failed sessions), and 882 potential queueing issues when multiple transfers are requested 883 simultaneously. This policy assumes that there is agreement 884 between pairs of entities as to which of the peers will initiate 885 sessions; if there is no such agreement, there is potential for 886 duplicate sessions to be established between peers. 888 Ephemeral Sessions: This policy only establishes a session when an 889 outgoing transfer is needed to be sent. Benefits of this policy 890 include not wasting network resources on sessions which are idle 891 for long periods of time, and avoids queueing issues of a 892 persistent session. Drawbacks include the TCP and TLS overhead of 893 establish a new session for each transfer. This policy assumes 894 that each entity can function in a passive role to listen for 895 session requests from any peer which needs to send a transfer; 896 when that is not the case the Polling behavior below needs to 897 happen. This policy can be augmented to keep the session 898 established as long as any transfers are queued. 900 Active-Only Polling Sessions: When naming and/or addressing of one 901 entity is variable (i.e. dynamically assigned IP address or domain 902 name) or when firewall or routing rules prevent incoming TCP 903 connections, that entity can only function in the active role. In 904 these cases, sessions also need to be established when an incoming 905 transfer is expected from a peer or based on a periodic schedule. 906 This polling behavior causes inefficiencies compared to as-needed 907 ephemeral sessions. 909 Many other policies can be established in a TCPCL network between the 910 two extremes of single persistent sessions and only ephemeral 911 sessions. Different policies can be applied to each peer entity and 912 to each bundle as it needs to be transferred (e.g for quality of 913 service). Additionally, future session extension types can apply 914 further nuance to session policies and policy negotiation. 916 3.6. Transfer Segmentation Policies 918 Each TCPCL session allows a negotiated transfer segmentation policy 919 to be applied in each transfer direction. A receiving entity can set 920 the Segment MRU in its SESS_INIT message to determine the largest 921 acceptable segment size, and a transmitting entity can segment a 922 transfer into any sizes smaller than the receiver's Segment MRU. It 923 is a network administration matter to determine an appropriate 924 segmentation policy for entities operating TCPCL, but guidance given 925 here can be used to steer policy toward performance goals. It is 926 also advised to consider the Segment MRU in relation to chunking/ 927 packetization performed by TLS, TCP, and any intermediate network- 928 layer nodes. 930 Minimum Overhead: For a simple network expected to exchange 931 relatively small bundles, the Segment MRU can be set to be 932 identical to the Transfer MRU which indicates that all transfers 933 can be sent with a single data segment (i.e., no actual 934 segmentation). If the network is closed and all transmitters are 935 known to follow a single-segment transfer policy, then receivers 936 can avoid the necessity of segment reassembly. Because this CL 937 operates over a TCP stream, which suffers from a form of head-of- 938 queue blocking between messages, while one entity is transmitting 939 a single XFER_SEGMENT message it is not able to transmit any 940 XFER_ACK or XFER_REFUSE for any associated received transfers. 942 Predictable Message Sizing: In situations where the maximum message 943 size is desired to be well-controlled, the Segment MRU can be set 944 to the largest acceptable size (the message size less XFER_SEGMENT 945 header size) and transmitters can always segment a transfer into 946 maximum-size chunks no larger than the Segment MRU. This 947 guarantees that any single XFER_SEGMENT will not monopolize the 948 TCP stream for too long, which would prevent outgoing XFER_ACK and 949 XFER_REFUSE associated with received transfers. 951 Dynamic Segmentation: Even after negotiation of a Segment MRU for 952 each receiving entity, the actual transfer segmentation only needs 953 to guarantee than any individual segment is no larger than that 954 MRU. In a situation where TCP throughput is dynamic, the transfer 955 segmentation size can also be dynamic in order to control message 956 transmission duration. 958 Many other policies can be established in a TCPCL network between the 959 two extremes of minimum overhead (large MRU, single-segment) and 960 predictable message sizing (small MRU, highly segmented). Different 961 policies can be applied to each transfer stream to and from any 962 particular entity. Additionally, future session extension and 963 transfer extension types can apply further nuance to transfer 964 policies and policy negotiation. 966 3.7. Example Message Exchange 968 The following figure depicts the protocol exchange for a simple 969 session, showing the session establishment and the transmission of a 970 single bundle split into three data segments (of lengths "L1", "L2", 971 and "L3") from Entity A to Entity B. 973 Note that the sending entity can transmit multiple XFER_SEGMENT 974 messages without waiting for the corresponding XFER_ACK responses. 975 This enables pipelining of messages on a transfer stream. Although 976 this example only demonstrates a single bundle transmission, it is 977 also possible to pipeline multiple XFER_SEGMENT messages for 978 different bundles without necessarily waiting for XFER_ACK messages 979 to be returned for each one. However, interleaving data segments 980 from different bundles is not allowed. 982 No errors or rejections are shown in this example. 984 Entity A Entity B 985 ======== ======== 986 +-------------------------+ 987 | Open TCP Connection | -> +-------------------------+ 988 +-------------------------+ <- | Accept Connection | 989 +-------------------------+ 990 +-------------------------+ 991 | Contact Header | -> +-------------------------+ 992 +-------------------------+ <- | Contact Header | 993 +-------------------------+ 994 +-------------------------+ 995 | SESS_INIT | -> +-------------------------+ 996 +-------------------------+ <- | SESS_INIT | 997 +-------------------------+ 999 +-------------------------+ 1000 | XFER_SEGMENT (start) | -> 1001 | Transfer ID [I1] | 1002 | Length [L1] | 1003 | Bundle Data 0..(L1-1) | 1004 +-------------------------+ 1005 +-------------------------+ +-------------------------+ 1006 | XFER_SEGMENT | -> <- | XFER_ACK (start) | 1007 | Transfer ID [I1] | | Transfer ID [I1] | 1008 | Length [L2] | | Length [L1] | 1009 |Bundle Data L1..(L1+L2-1)| +-------------------------+ 1010 +-------------------------+ 1011 +-------------------------+ +-------------------------+ 1012 | XFER_SEGMENT (end) | -> <- | XFER_ACK | 1013 | Transfer ID [I1] | | Transfer ID [I1] | 1014 | Length [L3] | | Length [L1+L2] | 1015 |Bundle Data | +-------------------------+ 1016 | (L1+L2)..(L1+L2+L3-1)| 1017 +-------------------------+ 1018 +-------------------------+ 1019 <- | XFER_ACK (end) | 1020 | Transfer ID [I1] | 1021 | Length [L1+L2+L3] | 1022 +-------------------------+ 1024 +-------------------------+ 1025 | SESS_TERM | -> +-------------------------+ 1026 +-------------------------+ <- | SESS_TERM | 1027 +-------------------------+ 1028 +-------------------------+ +-------------------------+ 1029 | TCP Close | -> <- | TCP Close | 1030 +-------------------------+ +-------------------------+ 1031 Figure 15: An example of the flow of protocol messages on a 1032 single TCP Session between two entities 1034 4. Session Establishment 1036 For bundle transmissions to occur using the TCPCL, a TCPCL session 1037 MUST first be established between communicating entities. It is up 1038 to the implementation to decide how and when session setup is 1039 triggered. For example, some sessions can be opened proactively and 1040 maintained for as long as is possible given the network conditions, 1041 while other sessions are be opened only when there is a bundle that 1042 is queued for transmission and the routing algorithm selects a 1043 certain next-hop node. 1045 4.1. TCP Connection 1047 To establish a TCPCL session, an entity MUST first establish a TCP 1048 connection with the intended peer entity, typically by using the 1049 services provided by the operating system. Destination port number 1050 4556 has been assigned by IANA as the Registered Port number for the 1051 TCP convergence layer. Other destination port numbers MAY be used 1052 per local configuration. Determining a peer's destination port 1053 number (if different from the registered TCPCL port number) is up to 1054 the implementation. Any source port number MAY be used for TCPCL 1055 sessions. Typically an operating system assigned number in the TCP 1056 Ephemeral range (49152-65535) is used. 1058 If the entity is unable to establish a TCP connection for any reason, 1059 then it is an implementation matter to determine how to handle the 1060 connection failure. An entity MAY decide to re-attempt to establish 1061 the connection. If it does so, it MUST NOT overwhelm its target with 1062 repeated connection attempts. Therefore, the entity MUST NOT retry 1063 the connection setup earlier than some delay time from the last 1064 attempt, and it SHOULD use a (binary) exponential back-off mechanism 1065 to increase this delay in case of repeated failures. The upper limit 1066 on a re-attempt back-off is implementation defined but SHOULD be no 1067 longer than one minute (60 seconds) before signaling to the BP agent 1068 that a connection cannot be made. 1070 Once a TCP connection is established, the active entity SHALL 1071 immediately transmit its Contact Header. Once a TCP connection is 1072 established, the passive entity SHALL wait for the peer's Contact 1073 Header. If the passive entity does not receive a Contact Header 1074 after some implementation-defined time duration after TCP connection 1075 is established, the entity SHALL close the TCP connection. Entities 1076 SHOULD choose a Contact Header reception timeout interval no longer 1077 than one minute (60 seconds). Upon reception of a Contact Header, 1078 the passive entity SHALL transmit its Contact Header. The ordering 1079 of the Contact Header exchange allows the passive entity to avoid 1080 allocating resources to a potential TCPCL session until after a valid 1081 Contact Header has been received from the active entity. This 1082 ordering also allows the passive peer to adapt to alternate TCPCL 1083 protocol versions. 1085 The format of the Contact Header is described in Section 4.2. 1086 Because the TCPCL protocol version in use is part of the initial 1087 Contact Header, entities using TCPCL version 4 can coexist on a 1088 network with entities using earlier TCPCL versions (with some 1089 negotiation needed for interoperation as described in Section 4.3). 1091 Within this specification when an entity is said to "close" a TCP 1092 connection the entity SHALL use the TCP FIN mechanism and not the RST 1093 mechanism. Either mechanism, however, when received will cause a TCP 1094 connection to become closed. 1096 4.2. Contact Header 1098 This section describes the format of the Contact Header and the 1099 meaning of its fields. 1101 If the entity is configured to enable exchanging messages according 1102 to TLS 1.3 [RFC8446] or any successors which are compatible with that 1103 TLS ClientHello, the the CAN_TLS flag within its Contact Header SHALL 1104 be set to 1. The RECOMMENDED policy is to enable TLS for all 1105 sessions, even if security policy does not allow or require 1106 authentication. This follows the opportunistic security model of 1107 [RFC7435], though an active attacker could interfere with the 1108 exchange in such cases (see Section 8.4). 1110 Upon receipt of the Contact Header, both entities perform the 1111 validation and negotiation procedures defined in Section 4.3. After 1112 receiving the Contact Header from the other entity, either entity MAY 1113 refuse the session by sending a SESS_TERM message with an appropriate 1114 reason code. 1116 The format for the Contact Header is as follows: 1118 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1119 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 1120 +---------------+---------------+---------------+---------------+ 1121 | magic='dtn!' | 1122 +---------------+---------------+---------------+---------------+ 1123 | Version | Flags | 1124 +---------------+---------------+ 1126 Figure 16: Contact Header Format 1128 See Section 4.3 for details on the use of each of these Contact 1129 Header fields. 1131 The fields of the Contact Header are: 1133 magic: A four-octet field that always contains the octet sequence 1134 0x64 0x74 0x6E 0x21, i.e., the text string "dtn!" in US-ASCII (and 1135 UTF-8). 1137 Version: A one-octet field value containing the value 4 (current 1138 version of the TCPCL). 1140 Flags: A one-octet field of single-bit flags, interpreted according 1141 to the descriptions in Table 1. All reserved header flag bits 1142 SHALL be set to 0 by the sender. All reserved header flag bits 1143 SHALL be ignored by the receiver. 1145 +==========+========+========================================+ 1146 | Name | Code | Description | 1147 +==========+========+========================================+ 1148 | CAN_TLS | 0x01 | If bit is set, indicates that the | 1149 | | | sending peer has enabled TLS security. | 1150 +----------+--------+----------------------------------------+ 1151 | Reserved | others | | 1152 +----------+--------+----------------------------------------+ 1154 Table 1: Contact Header Flags 1156 4.3. Contact Validation and Negotiation 1158 Upon reception of the Contact Header, each entity follows the 1159 following procedures to ensure the validity of the TCPCL session and 1160 to negotiate values for the session parameters. 1162 If the magic string is not present or is not valid, the connection 1163 MUST be terminated. The intent of the magic string is to provide 1164 some protection against an inadvertent TCP connection by a different 1165 protocol than the one described in this document. To prevent a flood 1166 of repeated connections from a misconfigured application, a passive 1167 entity MAY deny new TCP connections from a specific peer address for 1168 a period of time after one or more connections fail to provide a 1169 decodable Contact Header. 1171 The first negotiation is on the TCPCL protocol version to use. The 1172 active entity always sends its Contact Header first and waits for a 1173 response from the passive entity. During contact initiation, the 1174 active TCPCL entity SHALL send the highest TCPCL protocol version on 1175 a first session attempt for a TCPCL peer. If the active entity 1176 receives a Contact Header with a lower protocol version than the one 1177 sent earlier on the TCP connection, the TCP connection SHALL be 1178 closed. If the active entity receives a SESS_TERM message with 1179 reason of "Version Mismatch", that entity MAY attempt further TCPCL 1180 sessions with the peer using earlier protocol version numbers in 1181 decreasing order. Managing multi-TCPCL-session state such as this is 1182 an implementation matter. 1184 If the passive entity receives a Contact Header containing a version 1185 that is not a version of the TCPCL that the entity implements, then 1186 the entity SHALL send its Contact Header and immediately terminate 1187 the session with a reason code of "Version mismatch". If the passive 1188 entity receives a Contact Header with a version that is lower than 1189 the latest version of the protocol that the entity implements, the 1190 entity MAY either terminate the session (with a reason code of 1191 "Version mismatch") or adapt its operation to conform to the older 1192 version of the protocol. The decision of version fall-back is an 1193 implementation matter. 1195 The negotiated contact parameters defined by this specification are 1196 described in the following paragraphs. 1198 TCPCL Version: Both Contact Headers of a successful contact 1199 negotiation have identical TCPCL Version numbers as described 1200 above. Only upon response of a Contact Header from the passive 1201 entity is the TCPCL protocol version established and session 1202 negotiation begun. 1204 Enable TLS: Negotiation of the Enable TLS parameter is performed by 1205 taking the logical AND of the two Contact Headers' CAN_TLS flags. 1206 A local security policy is then applied to determine of the 1207 negotiated value of Enable TLS is acceptable. It can be a 1208 reasonable security policy to require or disallow the use of TLS 1209 depending upon the desired network flows. The RECOMMENDED policy 1210 is to require TLS for all sessions, even if security policy does 1211 not allow or require authentication. Because this state is 1212 negotiated over an unsecured medium, there is a risk of a TLS 1213 Stripping as described in Section 8.4. 1215 If the Enable TLS state is unacceptable, the entity SHALL 1216 terminate the session with a reason code of "Contact Failure". 1217 Note that this contact failure reason is different than a failure 1218 of TLS handshake or TLS authentication after an agreed-upon and 1219 acceptable Enable TLS state. If the negotiated Enable TLS value 1220 is true and acceptable then TLS negotiation feature (described in 1221 Section 4.4) begins immediately following the Contact Header 1222 exchange. 1224 4.4. Session Security 1226 This version of the TCPCL supports establishing a Transport Layer 1227 Security (TLS) session within an existing TCP connection. When TLS 1228 is used within the TCPCL it affects the entire session. Once TLS is 1229 established, there is no mechanism available to downgrade the TCPCL 1230 session to non-TLS operation. 1232 Once established, the lifetime of a TLS connection SHALL be bound to 1233 the lifetime of the underlying TCP connection. Immediately prior to 1234 actively ending a TLS connection after TCPCL session termination, the 1235 peer which sent the original (non-reply) SESS_TERM message SHOULD 1236 follow the Closure Alert procedure of [RFC8446] to cleanly terminate 1237 the TLS connection. Because each TCPCL message is either fixed- 1238 length or self-indicates its length, the lack of a TLS Closure Alert 1239 will not cause data truncation or corruption. 1241 Subsequent TCPCL session attempts to the same passive entity MAY 1242 attempt to use the TLS session resumption feature. There is no 1243 guarantee that the passive entity will accept the request to resume a 1244 TLS session, and the active entity cannot assume any resumption 1245 outcome. 1247 4.4.1. Entity Identification 1249 The TCPCL uses TLS for certificate exchange in both directions to 1250 identify each entity and to allow each entity to authenticate its 1251 peer. Each certificate can potentially identify multiple entities 1252 and there is no problem using such a certificate as long as the 1253 identifiers are sufficient to meet authentication policy (as 1254 described in later sections) for the entity which presents it. 1256 Because the PKIX environment of each TCPCL entity are likely not 1257 controlled by the certificate end users (see Section 3.4), the TCPCL 1258 defines a prioritized list of what a certificate can identify about a 1259 TCPCL entity: 1261 Node ID: The ideal certificate identity is the Node ID of the entity 1262 using the NODE-ID definition below. When the Node ID is 1263 identified, there is no need for any lower-level identification to 1264 be present (though it can still be present, and if so it is also 1265 validated). 1267 DNS Name: If CA policy forbids a certificate to contain an arbitrary 1268 NODE-ID but allows a DNS-ID to be identified then one or more 1269 stable DNS names can be identified in the certificate. The use of 1270 wildcard DNS-ID is discouraged due to the complex rules for 1271 matching and dependence on implementation support for wildcard 1272 matching (see Section 6.4.3 of [RFC6125]). 1274 Network Address: If no stable DNS name is available but a stable 1275 network address is available and CA policy allows a certificate to 1276 contain a IPADDR-ID (as defined below) then one or more network 1277 addresses can be identified in the certificate. 1279 This specification defines a NODE-ID of a certificate as being the 1280 subjectAltName entry of type uniformResourceIdentifier whose value is 1281 a URI consistent with the requirements of [RFC3986] and the URI 1282 schemes of the IANA "Bundle Protocol URI Scheme Type" registry 1283 [IANA-BUNDLE]. This is similar to the URI-ID of [RFC6125] but does 1284 not require any structure to the scheme-specific-part of the URI. 1285 Unless specified otherwise by the definition of the URI scheme being 1286 authenticated, URI matching of a NODE-ID SHALL use the URI comparison 1287 logic of [RFC3986] and scheme-based normalization of those schemes 1288 specified in [I-D.ietf-dtn-bpbis]. A URI scheme can refine this 1289 "exact match" logic with rules about how Node IDs within that scheme 1290 are to be compared with the certificate-authenticated NODE-ID. 1292 This specification defines a IPADDR-ID of a certificate as being the 1293 subjectAltName entry of type iPAddress whose value is encoded 1294 according to [RFC5280]. 1296 4.4.2. Certificate Profile for TCPCL 1298 All end-entity certificates used by a TCPCL entity SHALL conform to 1299 [RFC5280], or any updates or successors to that profile. When an 1300 end-entity certificate is supplied, the full certification chain 1301 SHOULD be included unless security policy indicates that is 1302 unnecessary. An entity SHOULD omit the root CA certificate (the last 1303 item of the chain) when sending a certification chain, as the 1304 recipient already has the root CA to anchor its validation. 1306 The TCPCL requires Version 3 certificates due to the extensions used 1307 by this profile. TCPCL entities SHALL reject as invalid Version 1 1308 and Version 2 end-entity certificates. 1310 TCPCL entities SHALL accept certificates that contain an empty 1311 Subject field or contain a Subject without a Common Name. Identity 1312 information in end-entity certificates is contained entirely in the 1313 subjectAltName extension as defined in Section 4.4.1 and below. 1315 All end-entity and CA certificates used for TCPCL SHOULD contain both 1316 a Subject Key Identifier and an Authority Key Identifier extension in 1317 accordance with [RFC5280]. TCPCL entities SHOULD NOT rely on either 1318 a Subject Key Identifier and an Authority Key Identifier being 1319 present in any received certificate. Including key identifiers 1320 simplifies the work of an entity needing to assemble a certification 1321 chain. 1323 Unless prohibited by CA policy, a TCPCL end-entity certificate SHALL 1324 contain a NODE-ID which authenticates the Node ID of the peer. When 1325 assigned one or more stable DNS names, a TCPCL end-entity certificate 1326 SHOULD contain DNS-ID which authenticates those (fully qualified) 1327 names. When assigned one or more stable network addresses, a TCPCL 1328 end-entity certificate MAY contain IPADDR-ID which authenticates 1329 those addresses. 1331 This document defines a PKIX Extended Key Usage key purpose "id-kp- 1332 bundleSecurity" in Section 9.9 which can be used to restrict a 1333 certificate's use. The "id-kp-bundleSecurity" purpose can be 1334 combined with other purposes in the same certificate. When allowed 1335 by CA policy, a BPSec end-entity certificate SHOULD contain a PKIX 1336 Extended Key Usage extension in accordance with Section 4.2.1.12 of 1337 [RFC5280]. When the PKIX Extended Key Usage extension is present, it 1338 SHOULD contain a key purpose "id-kp-bundleSecurity" as defined in 1339 Section 9.9. Although not specifically required by TCPCL, some 1340 networks or TLS implementations assume the use of "id-kp-clientAuth" 1341 and "id-kp-serverAuth" are needed for, respectively, the client-side 1342 and server-side of TLS authentication. For interoperability, a TCPCL 1343 end-entity certificate MAY contain an Extended Key Usage with both 1344 "id-kp-clientAuth" and "id-kp-serverAuth" values. 1346 When allowed by CA policy, a TCPCL end-entity certificate SHOULD 1347 contain a PKIX Key Usage extension in accordance with Section 4.2.1.3 1348 of [RFC5280]. The PKIX Key Usage bit which is consistent with TCPCL 1349 security using TLS 1.3 is digitalSignature. The specific algorithms 1350 used during the TLS handshake will determine which of those key uses 1351 are exercised. Earlier versions of TCPCL can mandate use of the bits 1352 keyEncipherment or keyAgreement. 1354 When allowed by CA policy, a TCPCL end-entity certificate SHOULD 1355 contain an Online Certificate Status Protocol (OCSP) URI within an 1356 Authority Information Access extension in accordance with 1357 Section 4.2.2.1 of [RFC5280]. 1359 4.4.3. TLS Handshake 1361 The use of TLS is negotiated using the Contact Header as described in 1362 Section 4.3. After negotiating an Enable TLS parameter of true, and 1363 before any other TCPCL messages are sent within the session, the 1364 session entities SHALL begin a TLS handshake in accordance with 1365 [RFC8446]. By convention, this protocol uses the entity which 1366 initiated the underlying TCP connection (the active peer) as the 1367 "client" role of the TLS handshake request. 1369 The TLS handshake, if it occurs, is considered to be part of the 1370 contact negotiation before the TCPCL session itself is established. 1371 Specifics about sensitive data exposure are discussed in Section 8. 1373 The parameters within each TLS negotiation are implementation 1374 dependent but any TCPCL entity SHALL follow all recommended practices 1375 of BCP 195 [RFC7525], or any updates or successors that become part 1376 of BCP 195. Within each TLS handshake, the following requirements 1377 apply (using the rough order in which they occur): 1379 Client Hello: When a resolved DNS name was used to establish the TCP 1380 connection, the TLS ClientHello SHOULD include a "server_name" 1381 extension in accordance with [RFC6066]. When present, the 1382 "server_name" extension SHALL contain a "HostName" value taken 1383 from the DNS name (of the passive entity) which was resolved. 1384 Note: The "HostName" in the "server_name" extension is the network 1385 name for the passive entity, not the Node ID of that entity. 1387 Server Certificate: The passive entity SHALL supply a certificate 1388 within the TLS handshake to allow authentication of its side of 1389 the session. The supplied end-entity certificate SHALL conform to 1390 the profile of Section 4.4.2. The passive entity MAY use the SNI 1391 DNS name to choose an appropriate server-side certificate which 1392 authenticates that DNS name. 1394 Certificate Request: During TLS handshake, the passive entity SHALL 1395 request a client-side certificate. 1397 Client Certificate: The active entity SHALL supply a certificate 1398 chain within the TLS handshake to allow authentication of its side 1399 of the session. The supplied end-entity certificate SHALL conform 1400 to the profile of Section 4.4.2. 1402 If a TLS handshake cannot negotiate a TLS connection, both entities 1403 of the TCPCL session SHALL close the TCP connection. At this point 1404 the TCPCL session has not yet been established so there is no TCPCL 1405 session to terminate. 1407 After a TLS connection is successfully established, the active entity 1408 SHALL send a SESS_INIT message to begin session negotiation. This 1409 session negotiation and all subsequent messaging are secured. 1411 4.4.4. TLS Authentication 1413 Using PKIX certificates exchanged during the TLS handshake, each of 1414 the entities can authenticate a peer Node ID directly or authenticate 1415 the peer DNS name or network address. The logic for handling 1416 certificates and certificate data is separated into the following 1417 phases: 1419 1. Validating the certification path from the end-entity certificate 1420 up to a trusted root CA. 1422 2. Validating the Extended Key Usage (EKU) and other properties of 1423 the end-entity certificate. 1425 3. Authenticating identities from a valid end-entity certificate. 1427 4. Applying security policy to the result of each identity type 1428 authentication. 1430 The result of validating a peer identity (see Section 4.4.1) against 1431 one or more type of certificate claim is one of the following: 1433 Absent: Indicating that no such claims are present in the 1434 certificate and the identity cannot be authenticated. 1436 Success: Indicating that one or more such claims are present and at 1437 least one matches the peer identity value. 1439 Failure: Indicating that one or more such claims are present and 1440 none match the peer identity. 1442 4.4.4.1. Certificate Path and Purpose Validation 1444 For any peer end-entity certificate received during TLS handshake, 1445 the entity SHALL perform the certification path validation of 1446 [RFC5280] up to one of the entity's trusted CA certificates. If 1447 enabled by local policy, the entity SHALL perform an OCSP check of 1448 each certificate providing OCSP authority information in accordance 1449 with [RFC6960]. If certificate validation fails or if security 1450 policy disallows a certificate for any reason, the entity SHALL fail 1451 the TLS handshake with a "bad_certificate" alert. Leaving out part 1452 of the certification chain can cause the entity to fail to validate a 1453 certificate if the left-out certificates are unknown to the entity 1454 (see Section 8.6). 1456 For the end-entity peer certificate received during TLS handshake, 1457 the entity SHALL apply security policy to the Key Usage extension (if 1458 present) and Extended Key Usage extension (if present) in accordance 1459 with Section 4.2.1.12 of [RFC5280] and the profile in Section 4.4.2. 1461 4.4.4.2. Network-Level Authentication 1463 Either during or immediately after the TLS handshake, if required by 1464 security policy each entity SHALL validate the following certificate 1465 identifiers together in accordance with Section 6 of [RFC6125]: 1467 * If the active entity resolved a DNS name (of the passive entity) 1468 in order to initiate the TCP connection that DNS name SHALL be 1469 used as a DNS-ID reference identifier. 1471 * The IP address of the other side of the TCP connection SHALL be 1472 used as an IPADDR-ID reference identifier. 1474 If the network-level identifiers authentication result is Failure or 1475 if the result is Absent and security policy requires an authenticated 1476 network-level identifier, the entity SHALL terminate the session 1477 (with a reason code of "Contact Failure"). 1479 4.4.4.3. Node ID Authentication 1481 Immediately before Session Parameter Negotiation, if required by 1482 security policy each entity SHALL validate the certificate NODE-ID in 1483 accordance with Section 6 of [RFC6125] using the Node ID of the 1484 peer's SESS_INIT message as the NODE-ID reference identifier. If the 1485 NODE-ID validation result is Failure or if the result is Absent and 1486 security policy requires an authenticated Node ID, the entity SHALL 1487 terminate the session (with a reason code of "Contact Failure"). 1489 4.4.5. Policy Recommendations 1491 A RECOMMENDED security policy is to enable the use of OCSP checking 1492 during TLS handshake. A RECOMMENDED security policy is that if an 1493 Extended Key Usage is present that it needs to contain "id-kp- 1494 bundleSecurity" (of Section 4.4.4.1) to be usable with TCPCL 1495 security. A RECOMMENDED security policy is to require a validated 1496 Node ID (of Section 4.4.4.3) and to ignore any network-level 1497 identifier (of Section 4.4.4.2). 1499 This policy relies on and informs the certificate requirements in 1500 Section 4.4.3. This policy assumes that a DTN-aware CA (see 1501 Section 3.4) will only issue a certificate for a Node ID when it has 1502 verified that the private key holder actually controls the DTN node; 1503 this is needed to avoid the threat identified in Section 8.9. This 1504 policy requires that a certificate contain a NODE-ID and allows the 1505 certificate to also contain network-level identifiers. A tailored 1506 policy on a more controlled network could relax the requirement on 1507 Node ID validation and allow just network-level identifiers to 1508 authenticate a peer. 1510 4.4.6. Example TLS Initiation 1512 A summary of a typical TLS use is shown in the sequence in Figure 17 1513 below. In this example the active peer terminates the session but 1514 termination can be initiated from either peer. 1516 Entity A Entity B 1517 active peer passive peer 1519 +-------------------------+ 1520 | Open TCP Connection | -> +-------------------------+ 1521 +-------------------------+ <- | Accept Connection | 1522 +-------------------------+ 1523 +-------------------------+ 1524 | Contact Header | -> +-------------------------+ 1525 +-------------------------+ <- | Contact Header | 1526 +-------------------------+ 1528 +-------------------------+ +-------------------------+ 1529 | TLS Negotiation | -> <- | TLS Negotiation | 1530 | (as client) | | (as server) | 1531 +-------------------------+ +-------------------------+ 1533 DNS-ID and IPADDR-ID authentication occurs. 1534 Secured TCPCL messaging can begin. 1536 +-------------------------+ 1537 | SESS_INIT | -> +-------------------------+ 1538 +-------------------------+ <- | SESS_INIT | 1539 +-------------------------+ 1541 NODE-ID authentication occurs. 1542 Session is established, transfers can begin. 1544 +-------------------------+ 1545 | SESS_TERM | -> +-------------------------+ 1546 +-------------------------+ <- | SESS_TERM | 1547 +-------------------------+ 1548 +-------------------------+ 1549 | TLS Closure Alert | -> +-------------------------+ 1550 +-------------------------+ <- | TLS Closure Alert | 1551 +-------------------------+ 1552 +-------------------------+ +-------------------------+ 1553 | TCP Close | -> <- | TCP Close | 1554 +-------------------------+ +-------------------------+ 1556 Figure 17: A simple visual example of TCPCL TLS Establishment 1557 between two entities 1559 4.5. Message Header 1561 After the initial exchange of a Contact Header and (if TLS is 1562 negotiated to be used) the TLS handshake, all messages transmitted 1563 over the session are identified by a one-octet header with the 1564 following structure: 1566 0 1 2 3 4 5 6 7 1567 +---------------+ 1568 | Message Type | 1569 +---------------+ 1571 Figure 18: Format of the Message Header 1573 The message header fields are as follows: 1575 Message Type: Indicates the type of the message as per Table 2 1576 below. Encoded values are listed in Section 9.5. 1578 +==============+======+=====================================+ 1579 | Name | Code | Description | 1580 +==============+======+=====================================+ 1581 | SESS_INIT | 0x07 | Contains the session parameter | 1582 | | | inputs from one of the entities, as | 1583 | | | described in Section 4.6. | 1584 +--------------+------+-------------------------------------+ 1585 | SESS_TERM | 0x05 | Indicates that one of the entities | 1586 | | | participating in the session wishes | 1587 | | | to cleanly terminate the session, | 1588 | | | as described in Section 6.1. | 1589 +--------------+------+-------------------------------------+ 1590 | XFER_SEGMENT | 0x01 | Indicates the transmission of a | 1591 | | | segment of bundle data, as | 1592 | | | described in Section 5.2.2. | 1593 +--------------+------+-------------------------------------+ 1594 | XFER_ACK | 0x02 | Acknowledges reception of a data | 1595 | | | segment, as described in | 1596 | | | Section 5.2.3. | 1597 +--------------+------+-------------------------------------+ 1598 | XFER_REFUSE | 0x03 | Indicates that the transmission of | 1599 | | | the current bundle SHALL be | 1600 | | | stopped, as described in | 1601 | | | Section 5.2.4. | 1602 +--------------+------+-------------------------------------+ 1603 | KEEPALIVE | 0x04 | Used to keep TCPCL session active, | 1604 | | | as described in Section 5.1.1. | 1605 +--------------+------+-------------------------------------+ 1606 | MSG_REJECT | 0x06 | Contains a TCPCL message rejection, | 1607 | | | as described in Section 5.1.2. | 1608 +--------------+------+-------------------------------------+ 1610 Table 2: TCPCL Message Types 1612 4.6. Session Initialization Message (SESS_INIT) 1614 Before a session is established and ready to transfer bundles, the 1615 session parameters are negotiated between the connected entities. 1616 The SESS_INIT message is used to convey the per-entity parameters 1617 which are used together to negotiate the per-session parameters as 1618 described in Section 4.7. 1620 The format of a SESS_INIT message is as follows in Figure 19. 1622 +-----------------------------+ 1623 | Message Header | 1624 +-----------------------------+ 1625 | Keepalive Interval (U16) | 1626 +-----------------------------+ 1627 | Segment MRU (U64) | 1628 +-----------------------------+ 1629 | Transfer MRU (U64) | 1630 +-----------------------------+ 1631 | Node ID Length (U16) | 1632 +-----------------------------+ 1633 | Node ID Data (variable) | 1634 +-----------------------------+ 1635 | Session Extension | 1636 | Items Length (U32) | 1637 +-----------------------------+ 1638 | Session Extension | 1639 | Items (var.) | 1640 +-----------------------------+ 1642 Figure 19: SESS_INIT Format 1644 The fields of the SESS_INIT message are: 1646 Keepalive Interval: A 16-bit unsigned integer indicating the minimum 1647 interval, in seconds, to negotiate as the Session Keepalive using 1648 the method of Section 4.7. 1650 Segment MRU: A 64-bit unsigned integer indicating the largest 1651 allowable single-segment data payload size to be received in this 1652 session. Any XFER_SEGMENT sent to this peer SHALL have a data 1653 payload no longer than the peer's Segment MRU. The two entities 1654 of a single session MAY have different Segment MRUs, and no 1655 relation between the two is required. 1657 Transfer MRU: A 64-bit unsigned integer indicating the largest 1658 allowable total-bundle data size to be received in this session. 1659 Any bundle transfer sent to this peer SHALL have a Total Bundle 1660 Length payload no longer than the peer's Transfer MRU. This value 1661 can be used to perform proactive bundle fragmentation. The two 1662 entities of a single session MAY have different Transfer MRUs, and 1663 no relation between the two is required. 1665 Node ID Length and Node ID Data: Together these fields represent a 1666 variable-length text string. The Node ID Length is a 16-bit 1667 unsigned integer indicating the number of octets of Node ID Data 1668 to follow. A zero-length Node ID SHALL be used to indicate the 1669 lack of Node ID rather than a truly empty Node ID. This case 1670 allows an entity to avoid exposing Node ID information on an 1671 untrusted network. A non-zero-length Node ID Data SHALL contain 1672 the UTF-8 encoded Node ID of the Entity which sent the SESS_INIT 1673 message. Every Node ID SHALL be a URI consistent with the 1674 requirements of [RFC3986] and the URI schemes of the IANA "Bundle 1675 Protocol URI Scheme Type" registry [IANA-BUNDLE]. The Node ID 1676 itself can be authenticated as described in Section 4.4.4. 1678 Session Extension Length and Session Extension Items: Together these 1679 fields represent protocol extension data not defined by this 1680 specification. The Session Extension Length is the total number 1681 of octets to follow which are used to encode the Session Extension 1682 Item list. The encoding of each Session Extension Item is within 1683 a consistent data container as described in Section 4.8. The full 1684 set of Session Extension Items apply for the duration of the TCPCL 1685 session to follow. The order and multiplicity of these Session 1686 Extension Items is significant, as defined in the associated type 1687 specification(s). If the content of the Session Extension Items 1688 data disagrees with the Session Extension Length (e.g., the last 1689 Item claims to use more octets than are present in the Session 1690 Extension Length), the reception of the SESS_INIT is considered to 1691 have failed. 1693 If an entity receives a peer Node ID which is not authenticated (by 1694 the procedure of Section 4.4.4.3) that Node ID SHOULD NOT be used by 1695 a BP agent for any discovery or routing functions. Trusting an 1696 unauthenticated Node ID can lead to the threat described in 1697 Section 8.9. 1699 When the active entity initiates a TCPCL session, it is likely based 1700 on routing information which binds a Node ID to CL parameters used to 1701 initiate the session. If the active entity receives a SESS_INIT with 1702 different Node ID than was intended for the TCPCL session, the 1703 session MAY be allowed to be established. If allowed, such a session 1704 SHALL be associated with the Node ID provided in the SESS_INIT 1705 message rather than any intended value. 1707 4.7. Session Parameter Negotiation 1709 An entity calculates the parameters for a TCPCL session by 1710 negotiating the values from its own preferences (conveyed by the 1711 SESS_INIT it sent to the peer) with the preferences of the peer 1712 entity (expressed in the SESS_INIT that it received from the peer). 1713 The negotiated parameters defined by this specification are described 1714 in the following paragraphs. 1716 Transfer MTU and Segment MTU: The maximum transmit unit (MTU) for 1717 whole transfers and individual segments are identical to the 1718 Transfer MRU and Segment MRU, respectively, of the received 1719 SESS_INIT message. A transmitting peer can send individual 1720 segments with any size smaller than the Segment MTU, depending on 1721 local policy, dynamic network conditions, etc. Determining the 1722 size of each transmitted segment is an implementation matter. If 1723 either the Transfer MRU or Segment MRU is unacceptable, the entity 1724 SHALL terminate the session with a reason code of "Contact 1725 Failure". 1727 Session Keepalive: Negotiation of the Session Keepalive parameter is 1728 performed by taking the minimum of the two Keepalive Interval 1729 values from the two SESS_INIT messages. The Session Keepalive 1730 interval is a parameter for the behavior described in 1731 Section 5.1.1. If the Session Keepalive interval is unacceptable, 1732 the entity SHALL terminate the session with a reason code of 1733 "Contact Failure". Note: a negotiated Session Keepalive of zero 1734 indicates that KEEPALIVEs are disabled. 1736 Once this process of parameter negotiation is completed, this 1737 protocol defines no additional mechanism to change the parameters of 1738 an established session; to effect such a change, the TCPCL session 1739 MUST be terminated and a new session established. 1741 4.8. Session Extension Items 1743 Each of the Session Extension Items SHALL be encoded in an identical 1744 Type-Length-Value (TLV) container form as indicated in Figure 20. 1746 The fields of the Session Extension Item are: 1748 Item Flags: A one-octet field containing generic bit flags about the 1749 Item, which are listed in Table 3. All reserved header flag bits 1750 SHALL be set to 0 by the sender. All reserved header flag bits 1751 SHALL be ignored by the receiver. If a TCPCL entity receives a 1752 Session Extension Item with an unknown Item Type and the CRITICAL 1753 flag of 1, the entity SHALL terminate the TCPCL session with 1754 SESS_TERM reason code of "Contact Failure". If the CRITICAL flag 1755 is 0, an entity SHALL skip over and ignore any item with an 1756 unknown Item Type. 1758 Item Type: A 16-bit unsigned integer field containing the type of 1759 the extension item. This specification does not define any 1760 extension types directly, but does create an IANA registry for 1761 such codes (see Section 9.3). 1763 Item Length: A 16-bit unsigned integer field containing the number 1764 of Item Value octets to follow. 1766 Item Value: A variable-length data field which is interpreted 1767 according to the associated Item Type. This specification places 1768 no restrictions on an extension's use of available Item Value 1769 data. Extension specifications SHOULD avoid the use of large data 1770 lengths, as no bundle transfers can begin until the full extension 1771 data is sent. 1773 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1774 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 1775 +---------------+---------------+---------------+---------------+ 1776 | Item Flags | Item Type | Item Length...| 1777 +---------------+---------------+---------------+---------------+ 1778 | length contd. | Item Value... | 1779 +---------------+---------------+---------------+---------------+ 1781 Figure 20: Session Extension Item Format 1783 +==========+========+=============================================+ 1784 | Name | Code | Description | 1785 +==========+========+=============================================+ 1786 | CRITICAL | 0x01 | If bit is set, indicates that the receiving | 1787 | | | peer must handle the extension item. | 1788 +----------+--------+---------------------------------------------+ 1789 | Reserved | others | | 1790 +----------+--------+---------------------------------------------+ 1792 Table 3: Session Extension Item Flags 1794 5. Established Session Operation 1796 This section describes the protocol operation for the duration of an 1797 established session, including the mechanism for transmitting bundles 1798 over the session. 1800 5.1. Upkeep and Status Messages 1802 5.1.1. Session Upkeep (KEEPALIVE) 1804 The protocol includes a provision for transmission of KEEPALIVE 1805 messages over the TCPCL session to help determine if the underlying 1806 TCP connection has been disrupted. 1808 As described in Section 4.3, a negotiated parameter of each session 1809 is the Session Keepalive interval. If the negotiated Session 1810 Keepalive is zero (i.e., one or both SESS_INIT messages contains a 1811 zero Keepalive Interval), then the keepalive feature is disabled. 1812 There is no logical minimum value for the keepalive interval (within 1813 the minimum imposed by the positive-value encoding), but when used 1814 for many sessions on an open, shared network a short interval could 1815 lead to excessive traffic. For shared network use, entities SHOULD 1816 choose a keepalive interval no shorter than 30 seconds. There is no 1817 logical maximum value for the keepalive interval (within the maximum 1818 imposed by the fixed-size encoding), but an idle TCP connection is 1819 liable for closure by the host operating system if the keepalive time 1820 is longer than tens-of-minutes. Entities SHOULD choose a keepalive 1821 interval no longer than 10 minutes (600 seconds). 1823 Note: The Keepalive Interval SHOULD NOT be chosen too short as TCP 1824 retransmissions MAY occur in case of packet loss. Those will have to 1825 be triggered by a timeout (TCP retransmission timeout (RTO)), which 1826 is dependent on the measured RTT for the TCP connection so that 1827 KEEPALIVE messages can experience noticeable latency. 1829 The format of a KEEPALIVE message is a one-octet message type code of 1830 KEEPALIVE (as described in Table 2) with no additional data. Both 1831 sides SHALL send a KEEPALIVE message whenever the negotiated interval 1832 has elapsed with no transmission of any message (KEEPALIVE or other). 1834 If no message (KEEPALIVE or other) has been received in a session 1835 after some implementation-defined time duration, then the entity 1836 SHALL terminate the session by transmitting a SESS_TERM message (as 1837 described in Section 6.1) with reason code "Idle Timeout". If 1838 configurable, the idle timeout duration SHOULD be no shorter than 1839 twice the keepalive interval. If not configurable, the idle timeout 1840 duration SHOULD be exactly twice the keepalive interval. 1842 5.1.2. Message Rejection (MSG_REJECT) 1844 This message type is not expected to be seen in a well-functioning 1845 session. Its purpose is to aid in troubleshooting bad entity 1846 behavior by allowing the peer to observe why an entity is not 1847 responding as expected to its messages. 1849 If a TCPCL entity receives a message type which is unknown to it 1850 (possibly due to an unhandled protocol version mismatch or a 1851 incorrectly-negotiated session extension which defines a new message 1852 type), the entity SHALL send a MSG_REJECT message with a Reason Code 1853 of "Message Type Unknown" and close the TCP connection. If a TCPCL 1854 entity receives a message type which is known but is inappropriate 1855 for the negotiated session parameters (possibly due to incorrectly- 1856 negotiated session extension), the entity SHALL send a MSG_REJECT 1857 message with a Reason Code of "Message Unsupported". If a TCPCL 1858 entity receives a message which is inappropriate for the current 1859 session state (e.g., a SESS_INIT after the session has already been 1860 established or an XFER_ACK message with an unknown Transfer ID), the 1861 entity SHALL send a MSG_REJECT message with a Reason Code of "Message 1862 Unexpected". 1864 The format of a MSG_REJECT message is as follows in Figure 21. 1866 +-----------------------------+ 1867 | Message Header | 1868 +-----------------------------+ 1869 | Reason Code (U8) | 1870 +-----------------------------+ 1871 | Rejected Message Header | 1872 +-----------------------------+ 1874 Figure 21: Format of MSG_REJECT Messages 1876 The fields of the MSG_REJECT message are: 1878 Reason Code: A one-octet refusal reason code interpreted according 1879 to the descriptions in Table 4. 1881 Rejected Message Header: The Rejected Message Header is a copy of 1882 the Message Header to which the MSG_REJECT message is sent as a 1883 response. 1885 +==============+======+=============================================+ 1886 | Name | Code | Description | 1887 +==============+======+=============================================+ 1888 | Message Type | 0x01 | A message was received with a Message | 1889 | Unknown | | Type code unknown to the TCPCL entity. | 1890 +--------------+------+---------------------------------------------+ 1891 | Message | 0x02 | A message was received but the TCPCL | 1892 | Unsupported | | entity cannot comply with the message | 1893 | | | contents. | 1894 +--------------+------+---------------------------------------------+ 1895 | Message | 0x03 | A message was received while the | 1896 | Unexpected | | session is in a state in which the | 1897 | | | message is not expected. | 1898 +--------------+------+---------------------------------------------+ 1900 Table 4: MSG_REJECT Reason Codes 1902 5.2. Bundle Transfer 1904 All of the messages in this section are directly associated with 1905 transferring a bundle between TCPCL entities. 1907 A single TCPCL transfer results in a bundle (handled by the 1908 convergence layer as opaque data) being exchanged from one entity to 1909 the other. In TCPCL a transfer is accomplished by dividing a single 1910 bundle up into "segments" based on the receiving-side Segment MRU 1911 (see Section 4.2). The choice of the length to use for segments is 1912 an implementation matter, but each segment MUST NOT be larger than 1913 the receiving entity's maximum receive unit (MRU) (see the field 1914 Segment MRU of Section 4.2). The first segment for a bundle is 1915 indicated by the 'START' flag and the last segment is indicated by 1916 the 'END' flag. 1918 A single transfer (and by extension a single segment) SHALL NOT 1919 contain data of more than a single bundle. This requirement is 1920 imposed on the agent using the TCPCL rather than TCPCL itself. 1922 If multiple bundles are transmitted on a single TCPCL connection, 1923 they MUST be transmitted consecutively without interleaving of 1924 segments from multiple bundles. 1926 5.2.1. Bundle Transfer ID 1928 Each of the bundle transfer messages contains a Transfer ID which is 1929 used to correlate messages (from both sides of a transfer) for each 1930 bundle. A Transfer ID does not attempt to address uniqueness of the 1931 bundle data itself and has no relation to concepts such as bundle 1932 fragmentation. Each invocation of TCPCL by the bundle protocol 1933 agent, requesting transmission of a bundle (fragmentary or 1934 otherwise), results in the initiation of a single TCPCL transfer. 1935 Each transfer entails the sending of a sequence of some number of 1936 XFER_SEGMENT and XFER_ACK messages; all are correlated by the same 1937 Transfer ID. The sending entity originates a transfer ID and the 1938 receiving entity uses that same Transfer ID in acknowledgements. 1940 Transfer IDs from each entity SHALL be unique within a single TCPCL 1941 session. Upon exhaustion of the entire 64-bit Transfer ID space, the 1942 sending entity SHALL terminate the session with SESS_TERM reason code 1943 "Resource Exhaustion". For bidirectional bundle transfers, a TCPCL 1944 entity SHOULD NOT rely on any relation between Transfer IDs 1945 originating from each side of the TCPCL session. 1947 Although there is not a strict requirement for Transfer ID initial 1948 values or ordering (see Section 8.13), in the absence of any other 1949 mechanism for generating Transfer IDs an entity SHALL use the 1950 following algorithm: The initial Transfer ID from each entity is zero 1951 and subsequent Transfer ID values are incremented from the prior 1952 Transfer ID value by one. 1954 5.2.2. Data Transmission (XFER_SEGMENT) 1956 Each bundle is transmitted in one or more data segments. The format 1957 of a XFER_SEGMENT message follows in Figure 22. 1959 +------------------------------+ 1960 | Message Header | 1961 +------------------------------+ 1962 | Message Flags (U8) | 1963 +------------------------------+ 1964 | Transfer ID (U64) | 1965 +------------------------------+ 1966 | Transfer Extension | 1967 | Items Length (U32) | 1968 | (only for START segment) | 1969 +------------------------------+ 1970 | Transfer Extension | 1971 | Items (var.) | 1972 | (only for START segment) | 1973 +------------------------------+ 1974 | Data length (U64) | 1975 +------------------------------+ 1976 | Data contents (octet string) | 1977 +------------------------------+ 1979 Figure 22: Format of XFER_SEGMENT Messages 1981 The fields of the XFER_SEGMENT message are: 1983 Message Flags: A one-octet field of single-bit flags, interpreted 1984 according to the descriptions in Table 5. All reserved header 1985 flag bits SHALL be set to 0 by the sender. All reserved header 1986 flag bits SHALL be ignored by the receiver. 1988 Transfer ID: A 64-bit unsigned integer identifying the transfer 1989 being made. 1991 Transfer Extension Length and Transfer Extension Items: Together 1992 these fields represent protocol extension data for this 1993 specification. The Transfer Extension Length and Transfer 1994 Extension Item fields SHALL only be present when the 'START' flag 1995 is set to 1 on the message. The Transfer Extension Length is the 1996 total number of octets to follow which are used to encode the 1997 Transfer Extension Item list. The encoding of each Transfer 1998 Extension Item is within a consistent data container as described 1999 in Section 5.2.5. The full set of transfer extension items apply 2000 only to the associated single transfer. The order and 2001 multiplicity of these transfer extension items is significant, as 2002 defined in the associated type specification(s). If the content 2003 of the Transfer Extension Items data disagrees with the Transfer 2004 Extension Length (e.g., the last Item claims to use more octets 2005 than are present in the Transfer Extension Length), the reception 2006 of the XFER_SEGMENT is considered to have failed. 2008 Data length: A 64-bit unsigned integer indicating the number of 2009 octets in the Data contents to follow. 2011 Data contents: The variable-length data payload of the message. 2013 +==========+========+=======================================+ 2014 | Name | Code | Description | 2015 +==========+========+=======================================+ 2016 | END | 0x01 | If bit is set, indicates that this is | 2017 | | | the last segment of the transfer. | 2018 +----------+--------+---------------------------------------+ 2019 | START | 0x02 | If bit is set, indicates that this is | 2020 | | | the first segment of the transfer. | 2021 +----------+--------+---------------------------------------+ 2022 | Reserved | others | | 2023 +----------+--------+---------------------------------------+ 2025 Table 5: XFER_SEGMENT Flags 2027 The flags portion of the message contains two flag values in the two 2028 low-order bits, denoted 'START' and 'END' in Table 5. The 'START' 2029 flag SHALL be set to 1 when transmitting the first segment of a 2030 transfer. The 'END' flag SHALL be set to 1 when transmitting the 2031 last segment of a transfer. In the case where an entire transfer is 2032 accomplished in a single segment, both the 'START' and 'END' flags 2033 SHALL be set to 1. 2035 Once a transfer of a bundle has commenced, the entity MUST only send 2036 segments containing sequential portions of that bundle until it sends 2037 a segment with the 'END' flag set to 1. No interleaving of multiple 2038 transfers from the same entity is possible within a single TCPCL 2039 session. Simultaneous transfers between two entities MAY be achieved 2040 using multiple TCPCL sessions. 2042 5.2.3. Data Acknowledgments (XFER_ACK) 2044 Although the TCP transport provides reliable transfer of data between 2045 transport peers, the typical BSD sockets interface provides no means 2046 to inform a sending application of when the receiving application has 2047 processed some amount of transmitted data. Thus, after transmitting 2048 some data, the TCPCL needs an additional mechanism to determine 2049 whether the receiving agent has successfully received and fully 2050 processed the segment. To this end, the TCPCL protocol provides 2051 feedback messaging whereby a receiving entity transmits 2052 acknowledgments of reception of data segments. 2054 The format of an XFER_ACK message follows in Figure 23. 2056 +-----------------------------+ 2057 | Message Header | 2058 +-----------------------------+ 2059 | Message Flags (U8) | 2060 +-----------------------------+ 2061 | Transfer ID (U64) | 2062 +-----------------------------+ 2063 | Acknowledged length (U64) | 2064 +-----------------------------+ 2066 Figure 23: Format of XFER_ACK Messages 2068 The fields of the XFER_ACK message are: 2070 Message Flags: A one-octet field of single-bit flags, interpreted 2071 according to the descriptions in Table 5. All reserved header 2072 flag bits SHALL be set to 0 by the sender. All reserved header 2073 flag bits SHALL be ignored by the receiver. 2075 Transfer ID: A 64-bit unsigned integer identifying the transfer 2076 being acknowledged. 2078 Acknowledged length: A 64-bit unsigned integer indicating the total 2079 number of octets in the transfer which are being acknowledged. 2081 A receiving TCPCL entity SHALL send an XFER_ACK message in response 2082 to each received XFER_SEGMENT message after the segment has been 2083 fully processed. The flags portion of the XFER_ACK header SHALL be 2084 set to match the corresponding XFER_SEGMENT message being 2085 acknowledged (including flags not decodable to the entity). The 2086 acknowledged length of each XFER_ACK contains the sum of the data 2087 length fields of all XFER_SEGMENT messages received so far in the 2088 course of the indicated transfer. The sending entity SHOULD transmit 2089 multiple XFER_SEGMENT messages without waiting for the corresponding 2090 XFER_ACK responses. This enables pipelining of messages on a 2091 transfer stream. 2093 For example, suppose the sending entity transmits four segments of 2094 bundle data with lengths 100, 200, 500, and 1000, respectively. 2095 After receiving the first segment, the entity sends an acknowledgment 2096 of length 100. After the second segment is received, the entity 2097 sends an acknowledgment of length 300. The third and fourth 2098 acknowledgments are of length 800 and 1800, respectively. 2100 5.2.4. Transfer Refusal (XFER_REFUSE) 2102 The TCPCL supports a mechanism by which a receiving entity can 2103 indicate to the sender that it does not want to receive the 2104 corresponding bundle. To do so, upon receiving an XFER_SEGMENT 2105 message, the entity MAY transmit a XFER_REFUSE message. As data 2106 segments and acknowledgments can cross on the wire, the bundle that 2107 is being refused SHALL be identified by the Transfer ID of the 2108 refusal. 2110 There is no required relation between the Transfer MRU of a TCPCL 2111 entity (which is supposed to represent a firm limitation of what the 2112 entity will accept) and sending of a XFER_REFUSE message. A 2113 XFER_REFUSE can be used in cases where the agent's bundle storage is 2114 temporarily depleted or somehow constrained. A XFER_REFUSE can also 2115 be used after the bundle header or any bundle data is inspected by an 2116 agent and determined to be unacceptable. 2118 A transfer receiver MAY send an XFER_REFUSE message as soon as it 2119 receives any XFER_SEGMENT message. The transfer sender MUST be 2120 prepared for this and MUST associate the refusal with the correct 2121 bundle via the Transfer ID fields. 2123 The TCPCL itself does not have any required behavior to respond to an 2124 XFER_REFUSE based on its Reason Code; the refusal is passed up as an 2125 indication to the BP agent that the transfer has been refused. If a 2126 transfer refusal has a Reason Code which is not decodable to the BP 2127 agent, the agent SHOULD treat the refusal as having an Unknown 2128 reason. 2130 The format of the XFER_REFUSE message is as follows in Figure 24. 2132 +-----------------------------+ 2133 | Message Header | 2134 +-----------------------------+ 2135 | Reason Code (U8) | 2136 +-----------------------------+ 2137 | Transfer ID (U64) | 2138 +-----------------------------+ 2140 Figure 24: Format of XFER_REFUSE Messages 2142 The fields of the XFER_REFUSE message are: 2144 Reason Code: A one-octet refusal reason code interpreted according 2145 to the descriptions in Table 6. 2147 Transfer ID: A 64-bit unsigned integer identifying the transfer 2148 being refused. 2150 +=============+======+==========================================+ 2151 | Name | Code | Description | 2152 +=============+======+==========================================+ 2153 | Unknown | 0x00 | Reason for refusal is unknown or not | 2154 | | | specified. | 2155 +-------------+------+------------------------------------------+ 2156 | Completed | 0x01 | The receiver already has the complete | 2157 | | | bundle. The sender MAY consider the | 2158 | | | bundle as completely received. | 2159 +-------------+------+------------------------------------------+ 2160 | No | 0x02 | The receiver's resources are exhausted. | 2161 | Resources | | The sender SHOULD apply reactive bundle | 2162 | | | fragmentation before retrying. | 2163 +-------------+------+------------------------------------------+ 2164 | Retransmit | 0x03 | The receiver has encountered a problem | 2165 | | | that requires the bundle to be | 2166 | | | retransmitted in its entirety. | 2167 +-------------+------+------------------------------------------+ 2168 | Not | 0x04 | Some issue with the bundle data or the | 2169 | Acceptable | | transfer extension data was encountered. | 2170 | | | The sender SHOULD NOT retry the same | 2171 | | | bundle with the same extensions. | 2172 +-------------+------+------------------------------------------+ 2173 | Extension | 0x05 | A failure processing the Transfer | 2174 | Failure | | Extension Items has occurred. | 2175 +-------------+------+------------------------------------------+ 2176 | Session | 0x06 | The receiving entity is in the process | 2177 | Terminating | | of terminating the session. The sender | 2178 | | | MAY retry the same bundle at a later | 2179 | | | time in a different session. | 2180 +-------------+------+------------------------------------------+ 2182 Table 6: XFER_REFUSE Reason Codes 2184 The receiver MUST, for each transfer preceding the one to be refused, 2185 have either acknowledged all XFER_SEGMENT messages or refused the 2186 bundle transfer. 2188 The bundle transfer refusal MAY be sent before an entire data segment 2189 is received. If a sender receives a XFER_REFUSE message, the sender 2190 MUST complete the transmission of any partially sent XFER_SEGMENT 2191 message. There is no way to interrupt an individual TCPCL message 2192 partway through sending it. The sender MUST NOT commence 2193 transmission of any further segments of the refused bundle 2194 subsequently. Note, however, that this requirement does not ensure 2195 that an entity will not receive another XFER_SEGMENT for the same 2196 bundle after transmitting a XFER_REFUSE message since messages can 2197 cross on the wire; if this happens, subsequent segments of the bundle 2198 SHALL also be refused with a XFER_REFUSE message. 2200 Note: If a bundle transmission is aborted in this way, the receiver 2201 does not receive a segment with the 'END' flag set to 1 for the 2202 aborted bundle. The beginning of the next bundle is identified by 2203 the 'START' flag set to 1, indicating the start of a new transfer, 2204 and with a distinct Transfer ID value. 2206 5.2.5. Transfer Extension Items 2208 Each of the Transfer Extension Items SHALL be encoded in an identical 2209 Type-Length-Value (TLV) container form as indicated in Figure 25. 2211 The fields of the Transfer Extension Item are: 2213 Item Flags: A one-octet field containing generic bit flags about the 2214 Item, which are listed in Table 7. All reserved header flag bits 2215 SHALL be set to 0 by the sender. All reserved header flag bits 2216 SHALL be ignored by the receiver. If a TCPCL entity receives a 2217 Transfer Extension Item with an unknown Item Type and the CRITICAL 2218 flag is 1, the entity SHALL refuse the transfer with an 2219 XFER_REFUSE reason code of "Extension Failure". If the CRITICAL 2220 flag is 0, an entity SHALL skip over and ignore any item with an 2221 unknown Item Type. 2223 Item Type: A 16-bit unsigned integer field containing the type of 2224 the extension item. This specification creates an IANA registry 2225 for such codes (see Section 9.4). 2227 Item Length: A 16-bit unsigned integer field containing the number 2228 of Item Value octets to follow. 2230 Item Value: A variable-length data field which is interpreted 2231 according to the associated Item Type. This specification places 2232 no restrictions on an extension's use of available Item Value 2233 data. Extension specifications SHOULD avoid the use of large data 2234 lengths, as the associated transfer cannot begin until the full 2235 extension data is sent. 2237 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 2238 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 2239 +---------------+---------------+---------------+---------------+ 2240 | Item Flags | Item Type | Item Length...| 2241 +---------------+---------------+---------------+---------------+ 2242 | length contd. | Item Value... | 2243 +---------------+---------------+---------------+---------------+ 2244 Figure 25: Transfer Extension Item Format 2246 +==========+========+=============================================+ 2247 | Name | Code | Description | 2248 +==========+========+=============================================+ 2249 | CRITICAL | 0x01 | If bit is set, indicates that the receiving | 2250 | | | peer must handle the extension item. | 2251 +----------+--------+---------------------------------------------+ 2252 | Reserved | others | | 2253 +----------+--------+---------------------------------------------+ 2255 Table 7: Transfer Extension Item Flags 2257 5.2.5.1. Transfer Length Extension 2259 The purpose of the Transfer Length extension is to allow entities to 2260 preemptively refuse bundles that would exceed their resources or to 2261 prepare storage on the receiving entity for the upcoming bundle data. 2263 Multiple Transfer Length extension items SHALL NOT occur within the 2264 same transfer. The lack of a Transfer Length extension item in any 2265 transfer SHALL NOT imply anything about the potential length of the 2266 transfer. The Transfer Length extension SHALL be assigned transfer 2267 extension type ID 0x0001. 2269 If a transfer occupies exactly one segment (i.e., both START and END 2270 flags are 1) the Transfer Length extension SHOULD NOT be present. 2271 The extension does not provide any additional information for single- 2272 segment transfers. 2274 The format of the Transfer Length data is as follows in Figure 26. 2276 +----------------------+ 2277 | Total Length (U64) | 2278 +----------------------+ 2280 Figure 26: Format of Transfer Length data 2282 The fields of the Transfer Length extension are: 2284 Total Length: A 64-bit unsigned integer indicating the size of the 2285 data-to-be-transferred. The Total Length field SHALL be treated 2286 as authoritative by the receiver. If, for whatever reason, the 2287 actual total length of bundle data received differs from the value 2288 indicated by the Total Length value, the receiver SHALL treat the 2289 transmitted data as invalid and send an XFER_REFUSE with a Reason 2290 Code of "Not Acceptable". 2292 6. Session Termination 2294 This section describes the procedures for terminating a TCPCL 2295 session. The purpose of terminating a session is to allow transfers 2296 to complete before the TCP connection is closed but not allow any new 2297 transfers to start. A session state change is necessary for this to 2298 happen because transfers can be in-progress in either direction 2299 (transfer stream) within a session. Waiting for a transfer to 2300 complete in one direction does not control or influence the 2301 possibility of a transfer in the other direction. Either peer of a 2302 session can terminate an established session at any time. 2304 6.1. Session Termination Message (SESS_TERM) 2306 To cleanly terminate a session, a SESS_TERM message SHALL be 2307 transmitted by either entity at any point following complete 2308 transmission of any other message. When sent to initiate a 2309 termination, the REPLY flag of a SESS_TERM message SHALL be 0. Upon 2310 receiving a SESS_TERM message after not sending a SESS_TERM message 2311 in the same session, an entity SHALL send an acknowledging SESS_TERM 2312 message. When sent to acknowledge a termination, a SESS_TERM message 2313 SHALL have identical data content from the message being acknowledged 2314 except for the REPLY flag, which is set to 1 to indicate 2315 acknowledgement. 2317 Once a SESS_TERM message is sent the state of that TCPCL session 2318 changes to Ending. While the session is in the Ending state, an 2319 entity MAY finish an in-progress transfer in either direction. While 2320 the session is in the Ending state, an entity SHALL NOT begin any new 2321 outgoing transfer for the remainder of the session. While the 2322 session is in the Ending state, an entity SHALL NOT accept any new 2323 incoming transfer for the remainder of the session. If a new 2324 incoming transfer is attempted while in the Ending state, the 2325 receiving entity SHALL send an XFER_REFUSE with a Reason Code of 2326 "Session Terminating". 2328 There are circumstances where an entity has an urgent need to close a 2329 TCP connection associated with a TCPCL session, without waiting for 2330 transfers to complete but also in a way which doesn't force timeouts 2331 to occur; for example, due to impending shutdown of the underlying 2332 data link layer. Instead of following a clean termination sequence, 2333 after transmitting a SESS_TERM message an entity MAY perform an 2334 unclean termination by immediately closing the associated TCP 2335 connection. When performing an unclean termination, an entity SHOULD 2336 acknowledge all received XFER_SEGMENTs with an XFER_ACK before 2337 closing the TCP connection. Not acknowledging received segments can 2338 result in unnecessary bundle or bundle fragment retransmission. Any 2339 delay between request to close the TCP connection and actual closing 2340 of the connection (a "half-closed" state) MAY be ignored by the TCPCL 2341 entity. If the underlying TCP connection is closed during a 2342 transmission (in either transfer stream), the transfer SHALL be 2343 indicated to the BP agent as failed (see the transmission failure and 2344 reception failure indications of Section 3.1). 2346 The TCPCL itself does not have any required behavior to respond to an 2347 SESS_TERM based on its Reason Code; the termination is passed up as 2348 an indication to the BP agent that the session state has changed. If 2349 a termination has a Reason Code which is not decodable to the BP 2350 agent, the agent SHOULD treat the termination as having an Unknown 2351 reason. 2353 The format of the SESS_TERM message is as follows in Figure 27. 2355 +-----------------------------+ 2356 | Message Header | 2357 +-----------------------------+ 2358 | Message Flags (U8) | 2359 +-----------------------------+ 2360 | Reason Code (U8) | 2361 +-----------------------------+ 2363 Figure 27: Format of SESS_TERM Messages 2365 The fields of the SESS_TERM message are: 2367 Message Flags: A one-octet field of single-bit flags, interpreted 2368 according to the descriptions in Table 8. All reserved header 2369 flag bits SHALL be set to 0 by the sender. All reserved header 2370 flag bits SHALL be ignored by the receiver. 2372 Reason Code: A one-octet refusal reason code interpreted according 2373 to the descriptions in Table 9. 2375 +==========+========+====================================+ 2376 | Name | Code | Description | 2377 +==========+========+====================================+ 2378 | REPLY | 0x01 | If bit is set, indicates that this | 2379 | | | message is an acknowledgement of | 2380 | | | an earlier SESS_TERM message. | 2381 +----------+--------+------------------------------------+ 2382 | Reserved | others | | 2383 +----------+--------+------------------------------------+ 2385 Table 8: SESS_TERM Flags 2387 +==============+======+==========================================+ 2388 | Name | Code | Description | 2389 +==============+======+==========================================+ 2390 | Unknown | 0x00 | A termination reason is not available. | 2391 +--------------+------+------------------------------------------+ 2392 | Idle timeout | 0x01 | The session is being terminated due to | 2393 | | | idleness. | 2394 +--------------+------+------------------------------------------+ 2395 | Version | 0x02 | The entity cannot conform to the | 2396 | mismatch | | specified TCPCL protocol version. | 2397 +--------------+------+------------------------------------------+ 2398 | Busy | 0x03 | The entity is too busy to handle the | 2399 | | | current session. | 2400 +--------------+------+------------------------------------------+ 2401 | Contact | 0x04 | The entity cannot interpret or negotiate | 2402 | Failure | | a Contact Header or SESS_INIT option. | 2403 +--------------+------+------------------------------------------+ 2404 | Resource | 0x05 | The entity has run into some resource | 2405 | Exhaustion | | limit and cannot continue the session. | 2406 +--------------+------+------------------------------------------+ 2408 Table 9: SESS_TERM Reason Codes 2410 The earliest a TCPCL session termination MAY occur is immediately 2411 after transmission of a Contact Header (and prior to any further 2412 message transmit). This can, for example, be used to notify that the 2413 entity is currently not able or willing to communicate. However, an 2414 entity MUST always send the Contact Header to its peer before sending 2415 a SESS_TERM message. 2417 Termination of the TCP connection MAY occur prior to receiving the 2418 Contact header as discussed in Section 4.1. If reception of the 2419 Contact Header itself somehow fails (e.g., an invalid "magic string" 2420 is received), an entity SHALL close the TCP connection without 2421 sending a SESS_TERM message. 2423 If a session is to be terminated before a protocol message has 2424 completed being sent, then the entity MUST NOT transmit the SESS_TERM 2425 message but still SHALL close the TCP connection. Each TCPCL message 2426 is contiguous in the octet stream and has no ability to be cut short 2427 and/or preempted by an other message. This is particularly important 2428 when large segment sizes are being transmitted; either entire 2429 XFER_SEGMENT is sent before a SESS_TERM message or the connection is 2430 simply terminated mid-XFER_SEGMENT. 2432 6.2. Idle Session Shutdown 2434 The protocol includes a provision for clean termination of idle 2435 sessions. Determining the length of time to wait before terminating 2436 idle sessions, if they are to be terminated at all, is an 2437 implementation and configuration matter. 2439 If there is a configured time to terminate idle sessions and if no 2440 TCPCL messages (other than KEEPALIVE messages) has been received for 2441 at least that amount of time, then either entity MAY terminate the 2442 session by transmitting a SESS_TERM message indicating the reason 2443 code of "Idle timeout" (as described in Table 9). 2445 7. Implementation Status 2447 This section is to be removed before publishing as an RFC. 2449 [NOTE to the RFC Editor: please remove this section before 2450 publication, as well as the reference to [RFC7942], 2451 [github-dtn-demo-agent], and [github-dtn-wireshark].] 2453 This section records the status of known implementations of the 2454 protocol defined by this specification at the time of posting of this 2455 Internet-Draft, and is based on a proposal described in [RFC7942]. 2456 The description of implementations in this section is intended to 2457 assist the IETF in its decision processes in progressing drafts to 2458 RFCs. Please note that the listing of any individual implementation 2459 here does not imply endorsement by the IETF. Furthermore, no effort 2460 has been spent to verify the information presented here that was 2461 supplied by IETF contributors. This is not intended as, and must not 2462 be construed to be, a catalog of available implementations or their 2463 features. Readers are advised to note that other implementations can 2464 exist. 2466 An example implementation of the this draft of TCPCLv4 has been 2467 created as a GitHub project [github-dtn-demo-agent] and is intended 2468 to use as a proof-of-concept and as a possible source of 2469 interoperability testing. This example implementation uses D-Bus as 2470 the CL-BP Agent interface, so it only runs on hosts which provide the 2471 Python "dbus" library. 2473 A wireshark dissector for TCPCLv4 has been created as a GitHub 2474 project [github-dtn-wireshark] and has been kept in-sync with the 2475 latest encoding of this specification. 2477 8. Security Considerations 2479 This section separates security considerations into threat categories 2480 based on guidance of BCP 72 [RFC3552]. 2482 8.1. Threat: Passive Leak of Node Data 2484 When used without TLS security, the TCPCL exposes the Node ID and 2485 other configuration data to passive eavesdroppers. This occurs even 2486 when no transfers occur within a TCPCL session. This can be avoided 2487 by always using TLS, even if authentication is not available (see 2488 Section 8.12). 2490 8.2. Threat: Passive Leak of Bundle Data 2492 TCPCL can be used to provide point-to-point transport security, but 2493 does not provide security of data-at-rest and does not guarantee end- 2494 to-end bundle security. The bundle security mechanisms defined in 2495 [I-D.ietf-dtn-bpsec] are to be used instead. 2497 When used without TLS security, the TCPCL exposes all bundle data to 2498 passive eavesdroppers. This can be avoided by always using TLS, even 2499 if authentication is not available (see Section 8.12). 2501 8.3. Threat: TCPCL Version Downgrade 2503 When a TCPCL entity supports multiple versions of the protocol it is 2504 possible for a malicious or misconfigured peer to use an older 2505 version of TCPCL which does not support transport security. A on- 2506 path attacker can also manipulate a Contact Header to present a lower 2507 protocol version than desired. 2509 It is up to security policies within each TCPCL entity to ensure that 2510 the negotiated TCPCL version meets transport security requirements. 2512 8.4. Threat: Transport Security Stripping 2514 When security policy allows non-TLS sessions, TCPCL does not protect 2515 against active network attackers. It is possible for a on-path 2516 attacker to set the CAN_TLS flag to 0 on either side of the Contact 2517 Header exchange, which will cause the negotiation of Section 4.3 to 2518 disable TLS. This leads to the "SSL Stripping" attack described in 2519 [RFC7457]. 2521 The purpose of the CAN_TLS flag is to allow the use of TCPCL on 2522 entities which simply do not have a TLS implementation available. 2523 When TLS is available on an entity, it is strongly encouraged that 2524 the security policy disallow non-TLS sessions. This requires that 2525 the TLS handshake occurs, regardless of the policy-driven parameters 2526 of the handshake and policy-driven handling of the handshake outcome. 2528 One mechanism to mitigate the possibility of TLS stripping is the use 2529 of DNS-based Authentication of Named Entities (DANE) [RFC6698] toward 2530 the passive peer. This mechanism relies on DNS and is 2531 unidirectional, so it doesn't help with applying policy toward the 2532 active peer, but it can be useful in an environment using 2533 opportunistic security. The configuration and use of DANE are 2534 outside of the scope of this document. 2536 The negotiated use of TLS is identical behavior to STARTTLS use in 2537 [RFC2595], [RFC4511], and others. 2539 8.5. Threat: Weak TLS Configurations 2541 Even when using TLS to secure the TCPCL session, the actual 2542 ciphersuite negotiated between the TLS peers can be insecure. 2543 Recommendations for ciphersuite use are included in BCP 195 2544 [RFC7525]. It is up to security policies within each TCPCL entity to 2545 ensure that the negotiated TLS ciphersuite meets transport security 2546 requirements. 2548 8.6. Threat: Untrusted End-Entity Certificate 2550 The profile in Section 4.4.4 uses end-entity certificates chained up 2551 to a trusted root CA. During TLS handshake, either entity can send a 2552 certificate set which does not contain the full chain, possibly 2553 excluding intermediate or root CAs. In an environment where peers 2554 are known to already contain needed root and intermediate CAs there 2555 is no need to include those CAs, but this has a risk of an entity not 2556 actually having one of the needed CAs. 2558 8.7. Threat: Certificate Validation Vulnerabilities 2560 Even when TLS itself is operating properly an attacker can attempt to 2561 exploit vulnerabilities within certificate check algorithms or 2562 configuration to establish a secure TCPCL session using an invalid 2563 certificate. A BP agent treats the peer Node ID within a TCPCL 2564 session as authoritative and an invalid certificate exploit could 2565 lead to bundle data leaking and/or denial of service to the Node ID 2566 being impersonated. 2568 There are many reasons, described in [RFC5280] and [RFC6125], why a 2569 certificate can fail to validate, including using the certificate 2570 outside of its valid time interval, using purposes for which it was 2571 not authorized, or using it after it has been revoked by its CA. 2572 Validating a certificate is a complex task and can require network 2573 connectivity outside of the primary TCPCL network path(s) if a 2574 mechanism such as OCSP [RFC6960] is used by the CA. The 2575 configuration and use of particular certificate validation methods 2576 are outside of the scope of this document. 2578 8.8. Threat: Symmetric Key Limits 2580 Even with a secure block cipher and securely-established session 2581 keys, there are limits to the amount of plaintext which can be safely 2582 encrypted with a given set of keys as described in [AEAD-LIMITS]. 2583 When permitted by the negotiated TLS version (see [RFC8446]), it is 2584 advisable to take advantage of session key updates to avoid those 2585 limits. 2587 8.9. Threat: BP Node Impersonation 2589 The certificates exchanged by TLS enable authentication of peer DNS 2590 name and Node ID, but it is possible that a peer either not provide a 2591 valid certificate or that the certificate does not validate either 2592 the DNS-ID/IPADDR-ID or NODE-ID of the peer (see Section 3.4). 2593 Having a CA-validated certificate does not alone guarantee the 2594 identity of the network host or BP node from which the certificate is 2595 provided; additional validation procedures in Section 4.4.3 bind the 2596 DNS-ID/IPADDR-ID or NODE-ID based on the contents of the certificate. 2598 The DNS-ID/IPADDR-ID validation is a weaker form of authentication, 2599 because even if a peer is operating on an authenticated network DNS 2600 name or IP address it can provide an invalid Node ID and cause 2601 bundles to be "leaked" to an invalid node. Especially in DTN 2602 environments, network names and addresses of nodes can be time- 2603 variable so binding a certificate to a Node ID is a more stable 2604 identity. 2606 NODE-ID validation ensures that the peer to which a bundle is 2607 transferred is in fact the node which the BP Agent expects it to be. 2608 In circumstances where certificates can only be issued to DNS names, 2609 Node ID validation is not possible but it could be reasonable to 2610 assume that a trusted host is not going to present an invalid Node 2611 ID. Determining when a DNS-ID/IPADDR-ID authentication can be 2612 trusted to validate a Node ID is also a policy matter outside of the 2613 scope of this document. 2615 One mitigation to arbitrary entities with valid PKIX certificates 2616 impersonating arbitrary Node IDs is the use of the PKIX Extended Key 2617 Usage key purpose "id-kp-bundleSecurity" in Section 9.9. When this 2618 Extended Key Usage is present in the certificate, it represents a 2619 stronger assertion that the private key holder should in fact be 2620 trusted to operate as a DTN Node. 2622 8.10. Threat: Denial of Service 2624 The behaviors described in this section all amount to a potential 2625 denial-of-service to a TCPCL entity. The denial-of-service could be 2626 limited to an individual TCPCL session, could affect other well- 2627 behaving sessions on an entity, or could affect all sessions on a 2628 host. 2630 A malicious entity can continually establish TCPCL sessions and delay 2631 sending of protocol-required data to trigger timeouts. The victim 2632 entity can block TCP connections from network peers which are thought 2633 to be incorrectly behaving within TCPCL. 2635 An entity can send a large amount of data over a TCPCL session, 2636 requiring the receiving entity to handle the data. The victim entity 2637 can attempt to stop the flood of data by sending an XFER_REFUSE 2638 message, or forcibly terminate the session. 2640 There is the possibility of a "data dribble" attack in which an 2641 entity presents a very small Segment MRU which causes transfers to be 2642 split among an large number of very small segments and causes the 2643 segmentation overhead to overwhelm the actual bundle data segments. 2644 Similarly, an entity can present a very small Transfer MRU which will 2645 cause resources to be wasted on establishment and upkeep of a TCPCL 2646 session over which a bundle could never be transferred. The victim 2647 entity can terminate the session during the negotiation of 2648 Section 4.7 if the MRUs are unacceptable. 2650 The keepalive mechanism can be abused to waste throughput within a 2651 network link which would otherwise be usable for bundle 2652 transmissions. Due to the quantization of the Keepalive Interval 2653 parameter the smallest Session Keepalive is one second, which should 2654 be long enough to not flood the link. The victim entity can 2655 terminate the session during the negotiation of Section 4.7 if the 2656 Keepalive Interval is unacceptable. 2658 Finally, an attacker or a misconfigured entity can cause issues at 2659 the TCP connection which will cause unnecessary TCP retransmissions 2660 or connection resets, effectively denying the use of the overlying 2661 TCPCL session. 2663 8.11. Mandatory-to-Implement TLS 2665 Following IETF best current practice, TLS is mandatory to implement 2666 for all TCPCL implementations but TLS is optional to use for a given 2667 TCPCL session. The recommended configuration of Section 4.2 is to 2668 always enable TLS, but entities are permitted to disable TLS based on 2669 local configuration. The configuration to enable or disable TLS for 2670 an entity or a session is outside of the scope of this document. The 2671 configuration to disable TLS is different from the threat of TLS 2672 stripping described in Section 8.4. 2674 8.12. Alternate Uses of TLS 2676 This specification makes use of PKIX certificate validation and 2677 authentication within TLS. There are alternate uses of TLS which are 2678 not necessarily incompatible with the security goals of this 2679 specification, but are outside of the scope of this document. The 2680 following subsections give examples of alternate TLS uses. 2682 8.12.1. TLS Without Authentication 2684 In environments where PKI is available but there are restrictions on 2685 the issuance of certificates (including the contents of 2686 certificates), it may be possible to make use of TLS in a way which 2687 authenticates only the passive entity of a TCPCL session or which 2688 does not authenticate either entity. Using TLS in a way which does 2689 not successfully authenticate some claim of both peer entities of a 2690 TCPCL session is outside of the scope of this document but does have 2691 similar properties to the opportunistic security model of [RFC7435]. 2693 8.12.2. Non-Certificate TLS Use 2695 In environments where PKI is unavailable, alternate uses of TLS which 2696 do not require certificates such as pre-shared key (PSK) 2697 authentication [RFC5489] and the use of raw public keys [RFC7250] are 2698 available and can be used to ensure confidentiality within TCPCL. 2699 Using non-PKI node authentication methods is outside of the scope of 2700 this document. 2702 8.13. Predictability of Transfer IDs 2704 The only requirement on Transfer IDs is that they be unique with each 2705 session from the sending peer only. The trivial algorithm of the 2706 first transfer starting at zero and later transfers incrementing by 2707 one causes absolutely predictable Transfer IDs. Even when a TCPCL 2708 session is not TLS secured and there is a on-path attacker causing 2709 denial of service with XFER_REFUSE messages, it is not possible to 2710 preemptively refuse a transfer so there is no benefit in having 2711 unpredictable Transfer IDs within a session. 2713 9. IANA Considerations 2715 Registration procedures referred to in this section are defined in 2716 [RFC8126]. 2718 Some of the registries have been defined as version specific to 2719 TCPCLv4, and imports some or all codepoints from TCPCLv3. This was 2720 done to disambiguate the use of these codepoints between TCPCLv3 and 2721 TCPCLv4 while preserving the semantics of some of the codepoints. 2723 9.1. Port Number 2725 Within the port registry of [IANA-PORTS], TCP port number 4556 has 2726 been previously assigned as the default port for the TCP convergence 2727 layer in [RFC7242]. This assignment is unchanged by TCPCL version 4, 2728 but the assignment reference is updated to this specification. Each 2729 TCPCL entity identifies its TCPCL protocol version in its initial 2730 contact (see Section 9.2), so there is no ambiguity about what 2731 protocol is being used. The related assignments for UDP and DCCP 2732 port 4556 (both registered by [RFC7122]) are unchanged. 2734 +========================+============================+ 2735 | Parameter | Value | 2736 +========================+============================+ 2737 | Service Name: | dtn-bundle | 2738 +------------------------+----------------------------+ 2739 | Transport Protocol(s): | TCP | 2740 +------------------------+----------------------------+ 2741 | Assignee: | IESG | 2742 +------------------------+----------------------------+ 2743 | Contact: | IESG | 2744 +------------------------+----------------------------+ 2745 | Description: | DTN Bundle TCP CL Protocol | 2746 +------------------------+----------------------------+ 2747 | Reference: | This specification. | 2748 +------------------------+----------------------------+ 2749 | Port Number: | 4556 | 2750 +------------------------+----------------------------+ 2752 Table 10 2754 9.2. Protocol Versions 2756 IANA has created, under the "Bundle Protocol" registry [IANA-BUNDLE], 2757 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2758 Numbers". The version number table is updated to include this 2759 specification. The registration procedure is RFC Required. 2761 +=======+=============+=====================+ 2762 | Value | Description | Reference | 2763 +=======+=============+=====================+ 2764 | 0 | Reserved | [RFC7242] | 2765 +-------+-------------+---------------------+ 2766 | 1 | Reserved | [RFC7242] | 2767 +-------+-------------+---------------------+ 2768 | 2 | Reserved | [RFC7242] | 2769 +-------+-------------+---------------------+ 2770 | 3 | TCPCL | [RFC7242] | 2771 +-------+-------------+---------------------+ 2772 | 4 | TCPCLv4 | This specification. | 2773 +-------+-------------+---------------------+ 2774 | 5-255 | Unassigned | | 2775 +-------+-------------+---------------------+ 2777 Table 11 2779 9.3. Session Extension Types 2781 EDITOR NOTE: sub-registry to-be-created upon publication of this 2782 specification. 2784 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 2785 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2786 4 Session Extension Types" and initialize it with the contents of 2787 Table 12. The registration procedure is Expert Review within the 2788 lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are 2789 reserved for use on private networks for functions not published to 2790 the IANA. 2792 Specifications of new session extension types need to define the 2793 encoding of the Item Value data as well as any meaning or restriction 2794 on the number of or order of instances of the type within an 2795 extension item list. Specifications need to define how the extension 2796 functions when no instance of the new extension type is received 2797 during session negotiation. 2799 Expert(s) are encouraged to be biased towards approving registrations 2800 unless they are abusive, frivolous, or actively harmful (not merely 2801 aesthetically displeasing, or architecturally dubious). 2803 +================+==========================+ 2804 | Code | Session Extension Type | 2805 +================+==========================+ 2806 | 0x0000 | Reserved | 2807 +----------------+--------------------------+ 2808 | 0x0001--0x7FFF | Unassigned | 2809 +----------------+--------------------------+ 2810 | 0x8000--0xFFFF | Private/Experimental Use | 2811 +----------------+--------------------------+ 2813 Table 12: Session Extension Type Codes 2815 9.4. Transfer Extension Types 2817 EDITOR NOTE: sub-registry to-be-created upon publication of this 2818 specification. 2820 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 2821 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2822 4 Transfer Extension Types" and initialize it with the contents of 2823 Table 13. The registration procedure is Expert Review within the 2824 lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are 2825 reserved for use on private networks for functions not published to 2826 the IANA. 2828 Specifications of new transfer extension types need to define the 2829 encoding of the Item Value data as well as any meaning or restriction 2830 on the number of or order of instances of the type within an 2831 extension item list. Specifications need to define how the extension 2832 functions when no instance of the new extension type is received in a 2833 transfer. 2835 Expert(s) are encouraged to be biased towards approving registrations 2836 unless they are abusive, frivolous, or actively harmful (not merely 2837 aesthetically displeasing, or architecturally dubious). 2839 +================+===========================+ 2840 | Code | Transfer Extension Type | 2841 +================+===========================+ 2842 | 0x0000 | Reserved | 2843 +----------------+---------------------------+ 2844 | 0x0001 | Transfer Length Extension | 2845 +----------------+---------------------------+ 2846 | 0x0002--0x7FFF | Unassigned | 2847 +----------------+---------------------------+ 2848 | 0x8000--0xFFFF | Private/Experimental Use | 2849 +----------------+---------------------------+ 2851 Table 13: Transfer Extension Type Codes 2853 9.5. Message Types 2855 EDITOR NOTE: sub-registry to-be-created upon publication of this 2856 specification. 2858 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 2859 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2860 4 Message Types" and initialize it with the contents of Table 14. 2861 The registration procedure is RFC Required within the lower range 2862 0x01--0xEF. Values in the range 0xF0--0xFF are reserved for use on 2863 private networks for functions not published to the IANA. 2865 Specifications of new message types need to define the encoding of 2866 the message data as well as the purpose and relationship of the new 2867 message to existing session/transfer state within the baseline 2868 message sequencing. The use of new message types need to be 2869 negotiated between TCPCL entities within a session (using the session 2870 extension mechanism) so that the receiving entity can properly decode 2871 all message types used in the session. 2873 Expert(s) are encouraged to favor new session/transfer extension 2874 types over new message types. TCPCL messages are not self- 2875 delimiting, so care must be taken in introducing new message types. 2877 If an entity receives an unknown message type the only thing that can 2878 be done is to send a MSG_REJECT and close the TCP connection; not 2879 even a clean termination can be done at that point. 2881 +============+==========================+ 2882 | Code | Message Type | 2883 +============+==========================+ 2884 | 0x00 | Reserved | 2885 +------------+--------------------------+ 2886 | 0x01 | XFER_SEGMENT | 2887 +------------+--------------------------+ 2888 | 0x02 | XFER_ACK | 2889 +------------+--------------------------+ 2890 | 0x03 | XFER_REFUSE | 2891 +------------+--------------------------+ 2892 | 0x04 | KEEPALIVE | 2893 +------------+--------------------------+ 2894 | 0x05 | SESS_TERM | 2895 +------------+--------------------------+ 2896 | 0x06 | MSG_REJECT | 2897 +------------+--------------------------+ 2898 | 0x07 | SESS_INIT | 2899 +------------+--------------------------+ 2900 | 0x08--0xEF | Unassigned | 2901 +------------+--------------------------+ 2902 | 0xF0--0xFF | Private/Experimental Use | 2903 +------------+--------------------------+ 2905 Table 14: Message Type Codes 2907 9.6. XFER_REFUSE Reason Codes 2909 EDITOR NOTE: sub-registry to-be-created upon publication of this 2910 specification. 2912 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 2913 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2914 4 XFER_REFUSE Reason Codes" and initialize it with the contents of 2915 Table 15. The registration procedure is Specification Required 2916 within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF 2917 are reserved for use on private networks for functions not published 2918 to the IANA. 2920 Specifications of new XFER_REFUSE reason codes need to define the 2921 meaning of the reason and disambiguate it with pre-existing reasons. 2922 Each refusal reason needs to be usable by the receiving BP Agent to 2923 make retransmission or re-routing decisions. 2925 Expert(s) are encouraged to be biased towards approving registrations 2926 unless they are abusive, frivolous, or actively harmful (not merely 2927 aesthetically displeasing, or architecturally dubious). 2929 +============+==========================+ 2930 | Code | Refusal Reason | 2931 +============+==========================+ 2932 | 0x00 | Unknown | 2933 +------------+--------------------------+ 2934 | 0x01 | Completed | 2935 +------------+--------------------------+ 2936 | 0x02 | No Resources | 2937 +------------+--------------------------+ 2938 | 0x03 | Retransmit | 2939 +------------+--------------------------+ 2940 | 0x04 | Not Acceptable | 2941 +------------+--------------------------+ 2942 | 0x05 | Extension Failure | 2943 +------------+--------------------------+ 2944 | 0x06 | Session Terminating | 2945 +------------+--------------------------+ 2946 | 0x07--0xEF | Unassigned | 2947 +------------+--------------------------+ 2948 | 0xF0--0xFF | Private/Experimental Use | 2949 +------------+--------------------------+ 2951 Table 15: XFER_REFUSE Reason Codes 2953 9.7. SESS_TERM Reason Codes 2955 EDITOR NOTE: sub-registry to-be-created upon publication of this 2956 specification. 2958 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 2959 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2960 4 SESS_TERM Reason Codes" and initialize it with the contents of 2961 Table 16. The registration procedure is Specification Required 2962 within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF 2963 are reserved for use on private networks for functions not published 2964 to the IANA. 2966 Specifications of new SESS_TERM reason codes need to define the 2967 meaning of the reason and disambiguate it with pre-existing reasons. 2968 Each termination reason needs to be usable by the receiving BP Agent 2969 to make re-connection decisions. 2971 Expert(s) are encouraged to be biased towards approving registrations 2972 unless they are abusive, frivolous, or actively harmful (not merely 2973 aesthetically displeasing, or architecturally dubious). 2975 +============+==========================+ 2976 | Code | Termination Reason | 2977 +============+==========================+ 2978 | 0x00 | Unknown | 2979 +------------+--------------------------+ 2980 | 0x01 | Idle timeout | 2981 +------------+--------------------------+ 2982 | 0x02 | Version mismatch | 2983 +------------+--------------------------+ 2984 | 0x03 | Busy | 2985 +------------+--------------------------+ 2986 | 0x04 | Contact Failure | 2987 +------------+--------------------------+ 2988 | 0x05 | Resource Exhaustion | 2989 +------------+--------------------------+ 2990 | 0x06--0xEF | Unassigned | 2991 +------------+--------------------------+ 2992 | 0xF0--0xFF | Private/Experimental Use | 2993 +------------+--------------------------+ 2995 Table 16: SESS_TERM Reason Codes 2997 9.8. MSG_REJECT Reason Codes 2999 EDITOR NOTE: sub-registry to-be-created upon publication of this 3000 specification. 3002 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 3003 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 3004 4 MSG_REJECT Reason Codes" and initialize it with the contents of 3005 Table 17. The registration procedure is Specification Required 3006 within the lower range 0x01--0xEF. Values in the range 0xF0--0xFF 3007 are reserved for use on private networks for functions not published 3008 to the IANA. 3010 Specifications of new MSG_REJECT reason codes need to define the 3011 meaning of the reason and disambiguate it with pre-existing reasons. 3012 Each rejection reason needs to be usable by the receiving TCPCL 3013 Entity to make message sequencing and/or session termination 3014 decisions. 3016 Expert(s) are encouraged to be biased towards approving registrations 3017 unless they are abusive, frivolous, or actively harmful (not merely 3018 aesthetically displeasing, or architecturally dubious). 3020 +============+==========================+ 3021 | Code | Rejection Reason | 3022 +============+==========================+ 3023 | 0x00 | reserved | 3024 +------------+--------------------------+ 3025 | 0x01 | Message Type Unknown | 3026 +------------+--------------------------+ 3027 | 0x02 | Message Unsupported | 3028 +------------+--------------------------+ 3029 | 0x03 | Message Unexpected | 3030 +------------+--------------------------+ 3031 | 0x04--0xEF | Unassigned | 3032 +------------+--------------------------+ 3033 | 0xF0--0xFF | Private/Experimental Use | 3034 +------------+--------------------------+ 3036 Table 17: MSG_REJECT Reason Codes 3038 9.9. Object Identifier for PKIX Extended Key Usage 3040 IANA has created, under the "Structure of Management Information 3041 (SMI) Numbers" registry [IANA-SMI], a sub-registry titled "SMI 3042 Security for PKIX Extended Key Purpose". The extended key purpose 3043 table is updated to include a purpose "id-kp-bundleSecurity" for 3044 identifying DTN endpoints as in the following table. 3046 +=========+======================+=====================+ 3047 | Decimal | Description | References | 3048 +=========+======================+=====================+ 3049 | KP-TBD | id-kp-bundleSecurity | This specification. | 3050 +---------+----------------------+---------------------+ 3052 Table 18 3054 This also corresponds with the following SMI, in ASN.1 syntax of 3055 [X.680], for that key purpose: 3057 3058 id-kp-bundleSecurity OBJECT IDENTIFIER ::= { 3059 iso(1) identified-organization(3) dod(6) internet(1) 3060 security(5) mechanisms(5) pkix(7) kp(3) KP-TBD } 3061 3063 10. Acknowledgments 3065 This specification is based on comments on implementation of 3066 [RFC7242] provided from Scott Burleigh. 3068 11. References 3070 11.1. Normative References 3072 [IANA-BUNDLE] 3073 IANA, "Bundle Protocol", 3074 . 3076 [IANA-PORTS] 3077 IANA, "Service Name and Transport Protocol Port Number 3078 Registry", . 3081 [IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers", 3082 . 3084 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 3085 RFC 793, DOI 10.17487/RFC0793, September 1981, 3086 . 3088 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 3089 Communication Layers", STD 3, RFC 1122, 3090 DOI 10.17487/RFC1122, October 1989, 3091 . 3093 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3094 Requirement Levels", BCP 14, RFC 2119, 3095 DOI 10.17487/RFC2119, March 1997, 3096 . 3098 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3099 Resource Identifier (URI): Generic Syntax", STD 66, 3100 RFC 3986, DOI 10.17487/RFC3986, January 2005, 3101 . 3103 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3104 Housley, R., and W. Polk, "Internet X.509 Public Key 3105 Infrastructure Certificate and Certificate Revocation List 3106 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3107 . 3109 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 3110 Extensions: Extension Definitions", RFC 6066, 3111 DOI 10.17487/RFC6066, January 2011, 3112 . 3114 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 3115 Verification of Domain-Based Application Service Identity 3116 within Internet Public Key Infrastructure Using X.509 3117 (PKIX) Certificates in the Context of Transport Layer 3118 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 3119 2011, . 3121 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 3122 Galperin, S., and C. Adams, "X.509 Internet Public Key 3123 Infrastructure Online Certificate Status Protocol - OCSP", 3124 RFC 6960, DOI 10.17487/RFC6960, June 2013, 3125 . 3127 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 3128 "Recommendations for Secure Use of Transport Layer 3129 Security (TLS) and Datagram Transport Layer Security 3130 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 3131 2015, . 3133 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3134 Writing an IANA Considerations Section in RFCs", BCP 26, 3135 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3136 . 3138 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3139 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3140 May 2017, . 3142 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3143 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3144 . 3146 [I-D.ietf-dtn-bpbis] 3147 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 3148 Version 7", Work in Progress, Internet-Draft, draft-ietf- 3149 dtn-bpbis-30, 10 December 2020, 3150 . 3152 [X.680] ITU-T, "Information technology -- Abstract Syntax Notation 3153 One (ASN.1): Specification of basic notation", ITU-T 3154 Recommendation X.680, ISO/IEC 8824-1:2015, August 2015, 3155 . 3157 11.2. Informative References 3159 [AEAD-LIMITS] 3160 Luykx, A. and K. Paterson, "Limits on Authenticated 3161 Encryption Use in TLS", August 2017, 3162 . 3164 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 3165 RFC 2595, DOI 10.17487/RFC2595, June 1999, 3166 . 3168 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 3169 Text on Security Considerations", BCP 72, RFC 3552, 3170 DOI 10.17487/RFC3552, July 2003, 3171 . 3173 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 3174 Protocol (LDAP): The Protocol", RFC 4511, 3175 DOI 10.17487/RFC4511, June 2006, 3176 . 3178 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 3179 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 3180 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 3181 April 2007, . 3183 [RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for 3184 Transport Layer Security (TLS)", RFC 5489, 3185 DOI 10.17487/RFC5489, March 2009, 3186 . 3188 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 3189 of Named Entities (DANE) Transport Layer Security (TLS) 3190 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 3191 2012, . 3193 [RFC7122] Kruse, H., Jero, S., and S. Ostermann, "Datagram 3194 Convergence Layers for the Delay- and Disruption-Tolerant 3195 Networking (DTN) Bundle Protocol and Licklider 3196 Transmission Protocol (LTP)", RFC 7122, 3197 DOI 10.17487/RFC7122, March 2014, 3198 . 3200 [RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant 3201 Networking TCP Convergence-Layer Protocol", RFC 7242, 3202 DOI 10.17487/RFC7242, June 2014, 3203 . 3205 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 3206 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 3207 Transport Layer Security (TLS) and Datagram Transport 3208 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 3209 June 2014, . 3211 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 3212 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 3213 December 2014, . 3215 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 3216 Known Attacks on Transport Layer Security (TLS) and 3217 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 3218 February 2015, . 3220 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 3221 Code: The Implementation Status Section", BCP 205, 3222 RFC 7942, DOI 10.17487/RFC7942, July 2016, 3223 . 3225 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 3226 Kasten, "Automatic Certificate Management Environment 3227 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 3228 . 3230 [I-D.ietf-dtn-bpsec] 3231 Birrane, E. and K. McKeever, "Bundle Protocol Security 3232 Specification", Work in Progress, Internet-Draft, draft- 3233 ietf-dtn-bpsec-26, 8 January 2021, 3234 . 3236 [I-D.ietf-dtn-bibect] 3237 Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in 3238 Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18 3239 February 2020, 3240 . 3242 [github-dtn-demo-agent] 3243 Sipos, B., "TCPCL Example Implementation", 3244 . 3246 [github-dtn-wireshark] 3247 Sipos, B., "TCPCL Wireshark Dissector", 3248 . 3250 Appendix A. Significant changes from RFC7242 3252 The areas in which changes from [RFC7242] have been made to existing 3253 headers and messages are: 3255 * Split Contact Header into pre-TLS protocol negotiation and 3256 SESS_INIT parameter negotiation. The Contact Header is now fixed- 3257 length. 3259 * Changed Contact Header content to limit number of negotiated 3260 options. 3262 * Added session option to negotiate maximum segment size (per each 3263 direction). 3265 * Renamed "Endpoint ID" to "Node ID" to conform with BPv7 3266 terminology. 3268 * Added session extension capability. 3270 * Added transfer extension capability. Moved transfer total length 3271 into an extension item. 3273 * Defined new IANA registries for message / type / reason codes to 3274 allow renaming some codes for clarity. 3276 * Segments of all new IANA registries are reserved for private/ 3277 experimental use. 3279 * Expanded Message Header to octet-aligned fields instead of bit- 3280 packing. 3282 * Added a bundle transfer identification number to all bundle- 3283 related messages (XFER_SEGMENT, XFER_ACK, XFER_REFUSE). 3285 * Use flags in XFER_ACK to mirror flags from XFER_SEGMENT. 3287 * Removed all uses of SDNV fields and replaced with fixed-bit-length 3288 (network byte order) fields. 3290 * Renamed SHUTDOWN to SESS_TERM to deconflict term "shutdown" 3291 related to TCP connections. 3293 * Removed the notion of a re-connection delay parameter. 3295 The areas in which extensions from [RFC7242] have been made as new 3296 messages and codes are: 3298 * Added contact negotiation failure SESS_TERM reason code. 3300 * Added MSG_REJECT message to indicate an unknown or unhandled 3301 message was received. 3303 * Added TLS connection security mechanism. 3305 * Added "Not Acceptable", "Extension Failure", and "Session 3306 Terminating" XFER_REFUSE reason codes. 3308 * Added "Resource Exhaustion" SESS_TERM reason code. 3310 Authors' Addresses 3312 Brian Sipos 3313 RKF Engineering Solutions, LLC 3314 7500 Old Georgetown Road 3315 Suite 1275 3316 Bethesda, MD 20814-6198 3317 United States of America 3319 Email: BSipos@rkf-eng.com 3321 Michael Demmer 3322 University of California, Berkeley 3323 Computer Science Division 3324 445 Soda Hall 3325 Berkeley, CA 94720-1776 3326 United States of America 3328 Email: demmer@cs.berkeley.edu 3330 Joerg Ott 3331 Aalto University 3332 Department of Communications and Networking 3333 PO Box 13000 3334 FI-02015 Aalto 3335 Finland 3337 Email: ott@in.tum.de 3339 Simon Perreault 3340 Quebec QC 3341 Canada 3342 Email: simon@per.reau.lt