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