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