idnits 2.17.1 draft-ietf-dtn-tcpclv4-20.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 (May 13, 2020) is 1444 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 671, but not defined == Missing Reference: 'PSI' is mentioned on line 726, but not defined == Missing Reference: 'SI' is mentioned on line 705, but not defined == Missing Reference: 'ST' is mentioned on line 793, but not defined == Missing Reference: 'I1' is mentioned on line 900, but not defined == Missing Reference: 'L1' is mentioned on line 888, but not defined == Missing Reference: 'L2' is mentioned on line 888, but not defined == Missing Reference: 'L3' is mentioned on line 894, but not defined == Outdated reference: A later version (-31) exists of draft-ietf-dtn-bpbis-24 -- 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-22 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: November 14, 2020 UC Berkeley 6 J. Ott 7 Aalto University 8 S. Perreault 9 May 13, 2020 11 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 12 draft-ietf-dtn-tcpclv4-20 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 November 14, 2020. 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. Transfer Segmentation Policies . . . . . . . . . . . . . 19 69 3.5. Example Message Exchange . . . . . . . . . . . . . . . . 20 70 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 21 71 4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 22 72 4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 23 73 4.3. Contact Validation and Negotiation . . . . . . . . . . . 24 74 4.4. Session Security . . . . . . . . . . . . . . . . . . . . 25 75 4.4.1. Entity Identification . . . . . . . . . . . . . . . . 26 76 4.4.2. TLS Handshake . . . . . . . . . . . . . . . . . . . . 27 77 4.4.3. TLS Authentication . . . . . . . . . . . . . . . . . 28 78 4.4.4. Example TLS Initiation . . . . . . . . . . . . . . . 30 79 4.5. Message Header . . . . . . . . . . . . . . . . . . . . . 31 80 4.6. Session Initialization Message (SESS_INIT) . . . . . . . 32 81 4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 34 82 4.8. Session Extension Items . . . . . . . . . . . . . . . . . 35 83 5. Established Session Operation . . . . . . . . . . . . . . . . 36 84 5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 36 85 5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 36 86 5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 37 87 5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 38 88 5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 39 89 5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 39 90 5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 41 91 5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 42 92 5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 45 93 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 47 94 6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 47 95 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 50 97 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 50 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 50 99 8.1. Threat: Passive Leak of Node Data . . . . . . . . . . . . 51 100 8.2. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 51 101 8.3. Threat: TCPCL Version Downgrade . . . . . . . . . . . . . 51 102 8.4. Threat: Transport Security Stripping . . . . . . . . . . 51 103 8.5. Threat: Weak TLS Configurations . . . . . . . . . . . . . 52 104 8.6. Threat: Certificate Validation Vulnerabilities . . . . . 52 105 8.7. Threat: Symmetric Key Limits . . . . . . . . . . . . . . 52 106 8.8. Threat: BP Node Impersonation . . . . . . . . . . . . . . 52 107 8.9. Threat: Denial of Service . . . . . . . . . . . . . . . . 53 108 8.10. Alternate Uses of TLS . . . . . . . . . . . . . . . . . . 54 109 8.10.1. TLS Without Authentication . . . . . . . . . . . . . 54 110 8.10.2. Non-Certificate TLS Use . . . . . . . . . . . . . . 54 111 8.11. Predictability of Transfer IDs . . . . . . . . . . . . . 54 112 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 113 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 55 114 9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 55 115 9.3. Session Extension Types . . . . . . . . . . . . . . . . . 56 116 9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 57 117 9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 58 118 9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 59 119 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 60 120 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 61 121 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 62 122 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 62 123 11.1. Normative References . . . . . . . . . . . . . . . . . . 62 124 11.2. Informative References . . . . . . . . . . . . . . . . . 64 125 Appendix A. Significant changes from RFC7242 . . . . . . . . . . 65 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 128 1. Introduction 130 This document describes the TCP-based convergence-layer protocol for 131 Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to- 132 end architecture providing communications in and/or through highly 133 stressed environments, including those with intermittent 134 connectivity, long and/or variable delays, and high bit error rates. 135 More detailed descriptions of the rationale and capabilities of these 136 networks can be found in "Delay-Tolerant Network Architecture" 137 [RFC4838]. 139 An important goal of the DTN architecture is to accommodate a wide 140 range of networking technologies and environments. The protocol used 141 for DTN communications is the Bundle Protocol Version 7 (BPv7) 142 [I-D.ietf-dtn-bpbis], an application-layer protocol that is used to 143 construct a store-and-forward overlay network. BPv7 requires the 144 services of a "convergence-layer adapter" (CLA) to send and receive 145 bundles using the service of some "native" link, network, or Internet 146 protocol. This document describes one such convergence-layer adapter 147 that uses the well-known Transmission Control Protocol (TCP). This 148 convergence layer is referred to as TCP Convergence Layer Version 4 149 (TCPCLv4). For the remainder of this document, the abbreviation "BP" 150 without the version suffix refers to BPv7. For the remainder of this 151 document, the abbreviation "TCPCL" without the version suffix refers 152 to TCPCLv4. 154 The locations of the TCPCL and the BP in the Internet model protocol 155 stack (described in [RFC1122]) are shown in Figure 1. In particular, 156 when BP is using TCP as its bearer with TCPCL as its convergence 157 layer, both BP and TCPCL reside at the application layer of the 158 Internet model. 160 +-------------------------+ 161 | DTN Application | -\ 162 +-------------------------| | 163 | Bundle Protocol (BP) | -> Application Layer 164 +-------------------------+ | 165 | TCP Conv. Layer (TCPCL) | | 166 +-------------------------+ | 167 | TLS (optional) | -/ 168 +-------------------------+ 169 | TCP | ---> Transport Layer 170 +-------------------------+ 171 | IPv4/IPv6 | ---> Network Layer 172 +-------------------------+ 173 | Link-Layer Protocol | ---> Link Layer 174 +-------------------------+ 176 Figure 1: The Locations of the Bundle Protocol and the TCP 177 Convergence-Layer Protocol above the Internet Protocol Stack 179 1.1. Scope 181 This document describes the format of the protocol data units passed 182 between entities participating in TCPCL communications. This 183 document does not address: 185 o The format of protocol data units of the Bundle Protocol, as those 186 are defined elsewhere in [I-D.ietf-dtn-bpbis]. This includes the 187 concept of bundle fragmentation or bundle encapsulation. The 188 TCPCL transfers bundles as opaque data blocks. 190 o Mechanisms for locating or identifying other bundle entities 191 (peers) within a network or across an internet. The mapping of 192 Node ID to potential convergence layer (CL) protocol and network 193 address is left to implementation and configuration of the BP 194 Agent and its various potential routing strategies. 196 o Logic for routing bundles along a path toward a bundle's endpoint. 197 This CL protocol is involved only in transporting bundles between 198 adjacent nodes in a routing sequence. 200 o Policies or mechanisms for creating X.509 certificates; 201 provisioning, deploying, or accessing certificates and private 202 keys; deploying or accessing certificate revocation lists (CRLs); 203 or configuring security parameters on an individual entity or 204 across a network. 206 o Uses of TLS which are not based on X.509 certificate 207 authentication (see Section 8.10.2) or in which authentication of 208 both entities is not possible (see Section 8.10.1). 210 Any TCPCL implementation requires a BP agent to perform those above 211 listed functions in order to perform end-to-end bundle delivery. 213 2. Requirements Language 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 217 "OPTIONAL" in this document are to be interpreted as described in BCP 218 14 [RFC2119] [RFC8174] when, and only when, they appear in all 219 capitals, as shown here. 221 2.1. Definitions Specific to the TCPCL Protocol 223 This section contains definitions specific to the TCPCL protocol. 225 Network Byte Order: Most significant byte first, a.k.a., big endian. 226 All of the integer encodings in this protocol SHALL be transmitted 227 in network byte order. 229 TCPCL Entity: This is the notional TCPCL application that initiates 230 TCPCL sessions. This design, implementation, configuration, and 231 specific behavior of such an entity is outside of the scope of 232 this document. However, the concept of an entity has utility 233 within the scope of this document as the container and initiator 234 of TCPCL sessions. The relationship between a TCPCL entity and 235 TCPCL sessions is defined as follows: 237 * A TCPCL Entity MAY actively initiate any number of TCPCL 238 Sessions and should do so whenever the entity is the initial 239 transmitter of information to another entity in the network. 241 * A TCPCL Entity MAY support zero or more passive listening 242 elements that listen for connection requests from other TCPCL 243 Entities operating on other entities in the network. 245 * A TCPCL Entity MAY passively initiate any number of TCPCL 246 Sessions from requests received by its passive listening 247 element(s) if the entity uses such elements. 249 These relationships are illustrated in Figure 2. For most TCPCL 250 behavior within a session, the two entities are symmetric and 251 there is no protocol distinction between them. Some specific 252 behavior, particularly during session establishment, distinguishes 253 between the active entity and the passive entity. For the 254 remainder of this document, the term "entity" without the prefix 255 "TCPCL" refers to a TCPCL entity. 257 TCP Connection: The term Connection in this specification 258 exclusively refers to a TCP connection and any and all behaviors, 259 sessions, and other states associated with that TCP connection. 261 TCPCL Session: A TCPCL session (as opposed to a TCP connection) is a 262 TCPCL communication relationship between two TCPCL entities. A 263 TCPCL session operates within a single underlying TCP connection 264 and the lifetime of a TCPCL session is bound to the lifetime of 265 that TCP connection. A TCPCL session is terminated when the TCP 266 connection ends, due either to one or both entities actively 267 closing the TCP connection or due to network errors causing a 268 failure of the TCP connection. Within a single TCPCL session 269 there are two possible transfer streams; one in each direction, 270 with one stream from each entity being the outbound stream and the 271 other being the inbound stream (see Figure 3). From the 272 perspective of a TCPCL session, the two transfer streams do not 273 logically interact with each other. The streams do operate over 274 the same TCP connection and between the same BP agents, so there 275 are logical relationships at those layers (message and bundle 276 interleaving respectively). For the remainder of this document, 277 the term "session" without the prefix "TCPCL" refers to a TCPCL 278 session. 280 Session parameters: These are a set of values used to affect the 281 operation of the TCPCL for a given session. The manner in which 282 these parameters are conveyed to the bundle entity and thereby to 283 the TCPCL is implementation dependent. However, the mechanism by 284 which two entities exchange and negotiate the values to be used 285 for a given session is described in Section 4.3. 287 Transfer Stream: A Transfer stream is a uni-directional user-data 288 path within a TCPCL Session. Transfers sent over a transfer 289 stream are serialized, meaning that one transfer must complete its 290 transmission prior to another transfer being started over the same 291 transfer stream. At the stream layer there is no logical 292 relationship between transfers in that stream; it's only within 293 the BP agent that transfers are fully decoded as bundles. Each 294 uni-directional stream has a single sender entity and a single 295 receiver entity. 297 Transfer: This refers to the procedures and mechanisms for 298 conveyance of an individual bundle from one node to another. Each 299 transfer within TCPCL is identified by a Transfer ID number which 300 is guaranteed to be unique only to a single direction within a 301 single Session. 303 Transfer Segment: A subset of a transfer of user data being 304 communicated over a transfer stream. 306 Idle Session: A TCPCL session is idle while there is no transmission 307 in-progress in either direction. While idle, the only messages 308 being transmitted or received are KEEPALIVE messages. 310 Live Session: A TCPCL session is live while there is a transmission 311 in-progress in either direction. 313 Reason Codes: The TCPCL uses numeric codes to encode specific 314 reasons for individual failure/error message types. 316 The relationship between connections, sessions, and streams is shown 317 in Figure 3. 319 +--------------------------------------------+ 320 | TCPCL Entity | 321 | | +----------------+ 322 | +--------------------------------+ | | |-+ 323 | | Actively Initiated Session #1 +------------->| Other | | 324 | +--------------------------------+ | | TCPCL Entity's | | 325 | ... | | Passive | | 326 | +--------------------------------+ | | Listener | | 327 | | Actively Initiated Session #n +------------->| | | 328 | +--------------------------------+ | +----------------+ | 329 | | +-----------------+ 330 | +---------------------------+ | 331 | +---| +---------------------------+ | +----------------+ 332 | | | | Optional Passive | | | |-+ 333 | | +-| Listener(s) +<-------------+ | | 334 | | +---------------------------+ | | | | 335 | | | | Other | | 336 | | +---------------------------------+ | | TCPCL Entity's | | 337 | +--->| Passively Initiated Session #1 +-------->| Active | | 338 | | +---------------------------------+ | | Initiator(s) | | 339 | | | | | | 340 | | +---------------------------------+ | | | | 341 | +--->| Passively Initiated Session #n +-------->| | | 342 | +---------------------------------+ | +----------------+ | 343 | | +-----------------+ 344 +--------------------------------------------+ 346 Figure 2: The relationships between TCPCL entities 348 +---------------------------+ +---------------------------+ 349 | "Own" TCPCL Session | | "Other" TCPCL Session | 350 | | | | 351 | +----------------------+ | | +----------------------+ | 352 | | TCP Connection | | | | TCP Connection | | 353 | | | | | | | | 354 | | +-----------------+ | | Messages | | +-----------------+ | | 355 | | | Own Inbound | +--------------------+ | Peer Outbound | | | 356 | | | Transfer Stream | | Transfer Stream | | | 357 | | | ----- |<---[Seg]--[Seg]--[Seg]---| ----- | | | 358 | | | RECEIVER |---[Ack]----[Ack]-------->| SENDER | | | 359 | | +-----------------+ +-----------------+ | | 360 | | | | 361 | | +-----------------+ +-----------------+ | | 362 | | | Own Outbound |-------[Seg]---[Seg]----->| Peer Inbound | | | 363 | | | Transfer Stream |<---[Ack]----[Ack]-[Ack]--| Transfer Stream | | | 364 | | | ----- | | ----- | | | 365 | | | SENDER | +--------------------+ | RECEIVER | | | 366 | | +-----------------+ | | | | +-----------------+ | | 367 | +-----------------------+ | | +---------------------+ | 368 +----------------------------+ +--------------------------+ 370 Figure 3: The relationship within a TCPCL Session of its two streams 372 3. General Protocol Description 374 The service of this protocol is the transmission of DTN bundles via 375 the Transmission Control Protocol (TCP). This document specifies the 376 encapsulation of bundles, procedures for TCP setup and teardown, and 377 a set of messages and node requirements. The general operation of 378 the protocol is as follows. 380 3.1. Convergence Layer Services 382 This version of the TCPCL provides the following services to support 383 the overlaying Bundle Protocol agent. In all cases, this is not an 384 API definition but a logical description of how the CL can interact 385 with the BP agent. Each of these interactions can be associated with 386 any number of additional metadata items as necessary to support the 387 operation of the CL or BP agent. 389 Attempt Session: The TCPCL allows a BP agent to preemptively attempt 390 to establish a TCPCL session with a peer entity. Each session 391 attempt can send a different set of session negotiation parameters 392 as directed by the BP agent. 394 Terminate Session: The TCPCL allows a BP agent to preemptively 395 terminate an established TCPCL session with a peer entity. The 396 terminate request is on a per-session basis. 398 Session State Changed: The TCPCL entity indicates to the BP agent 399 when the session state changes. The top-level session states 400 indicated are: 402 Connecting: A TCP connection is being established. This state 403 only applies to the active entity. 405 Contact Negotiating: A TCP connection has been made (as either 406 active or passive entity) and contact negotiation has begun. 408 Session Negotiating: Contact negotiation has been completed 409 (including possible TLS use) and session negotiation has begun. 411 Established: The session has been fully established and is ready 412 for its first transfer. 414 Ending: The entity sent SESS_TERM message and is in the ending 415 state. 417 Terminated: The session has finished normal termination 418 sequencing. 420 Failed: The session ended without normal termination sequencing. 422 Session Idle Changed: The TCPCL entity indicates to the BP agent 423 when the live/idle sub-state of the session changes. This occurs 424 only when the top-level session state is "Established". The 425 session transitions from Idle to Live at the at the start of a 426 transfer in either transfer stream; the session transitions from 427 Live to Idle at the end of a transfer when the other transfer 428 stream does not have an ongoing transfer. Because TCPCL transmits 429 serially over a TCP connection it suffers from "head of queue 430 blocking," so a transfer in either direction can block an 431 immediate start of a new transfer in the session. 433 Begin Transmission: The principal purpose of the TCPCL is to allow a 434 BP agent to transmit bundle data over an established TCPCL 435 session. Transmission request is on a per-session basis and the 436 CL does not necessarily perform any per-session or inter-session 437 queueing. Any queueing of transmissions is the obligation of the 438 BP agent. 440 Transmission Success: The TCPCL entity indicates to the BP agent 441 when a bundle has been fully transferred to a peer entity. 443 Transmission Intermediate Progress: The TCPCL entity indicates to 444 the BP agent on intermediate progress of transfer to a peer 445 entity. This intermediate progress is at the granularity of each 446 transferred segment. 448 Transmission Failure: The TCPCL entity indicates to the BP agent on 449 certain reasons for bundle transmission failure, notably when the 450 peer entity rejects the bundle or when a TCPCL session ends before 451 transfer success. The TCPCL itself does not have a notion of 452 transfer timeout. 454 Reception Initialized: The TCPCL entity indicates to the receiving 455 BP agent just before any transmission data is sent. This 456 corresponds to reception of the XFER_SEGMENT message with the 457 START flag of 1. 459 Interrupt Reception: The TCPCL entity allows a BP agent to interrupt 460 an individual transfer before it has fully completed (successfully 461 or not). Interruption can occur any time after the reception is 462 initialized. 464 Reception Success: The TCPCL entity indicates to the BP agent when a 465 bundle has been fully transferred from a peer entity. 467 Reception Intermediate Progress: The TCPCL entity indicates to the 468 BP agent on intermediate progress of transfer from the peer 469 entity. This intermediate progress is at the granularity of each 470 transferred segment. Intermediate reception indication allows a 471 BP agent the chance to inspect bundle header contents before the 472 entire bundle is available, and thus supports the "Reception 473 Interruption" capability. 475 Reception Failure: The TCPCL entity indicates to the BP agent on 476 certain reasons for reception failure, notably when the local 477 entity rejects an attempted transfer for some local policy reason 478 or when a TCPCL session ends before transfer success. The TCPCL 479 itself does not have a notion of transfer timeout. 481 3.2. TCPCL Session Overview 483 First, one node establishes a TCPCL session to the other by 484 initiating a TCP connection in accordance with [RFC0793]. After 485 setup of the TCP connection is complete, an initial Contact Header is 486 exchanged in both directions to establish a shared TCPCL version and 487 negotiate the use of TLS security (as described in Section 4). Once 488 contact negotiation is complete, TCPCL messaging is available and the 489 session negotiation is used to set parameters of the TCPCL session. 490 One of these parameters is a Node ID that each TCPCL Entity is acting 491 as. This is used to assist in routing and forwarding messages by the 492 BP Agent and is part of the authentication capability provided by 493 TLS. 495 Once negotiated, the parameters of a TCPCL session cannot change and 496 if there is a desire by either peer to transfer data under different 497 parameters then a new session must be established. This makes CL 498 logic simpler but relies on the assumption that establishing a TCP 499 connection is lightweight enough that TCP connection overhead is 500 negligible compared to TCPCL data sizes. 502 Once the TCPCL session is established and configured in this way, 503 bundles can be transferred in either direction. Each transfer is 504 performed by segmenting the transfer data into one or more 505 XFER_SEGMENT messages. Multiple bundles can be transmitted 506 consecutively in a single direction on a single TCPCL connection. 507 Segments from different bundles are never interleaved. Bundle 508 interleaving can be accomplished by fragmentation at the BP layer or 509 by establishing multiple TCPCL sessions between the same peers. 510 There is no fundamental limit on the number of TCPCL sessions which a 511 single node can establish beyond the limit imposed by the number of 512 available (ephemeral) TCP ports of the active entity. 514 A feature of this protocol is for the receiving node to send 515 acknowledgment (XFER_ACK) messages as bundle data segments arrive. 516 The rationale behind these acknowledgments is to enable the sender 517 node to determine how much of the bundle has been received, so that 518 in case the session is interrupted, it can perform reactive 519 fragmentation to avoid re-sending the already transmitted part of the 520 bundle. In addition, there is no explicit flow control on the TCPCL 521 layer. 523 A TCPCL receiver can interrupt the transmission of a bundle at any 524 point in time by replying with a XFER_REFUSE message, which causes 525 the sender to stop transmission of the associated bundle (if it 526 hasn't already finished transmission) Note: This enables a cross- 527 layer optimization in that it allows a receiver that detects that it 528 already has received a certain bundle to interrupt transmission as 529 early as possible and thus save transmission capacity for other 530 bundles. 532 For sessions that are idle, a KEEPALIVE message is sent at a 533 negotiated interval. This is used to convey node live-ness 534 information during otherwise message-less time intervals. 536 A SESS_TERM message is used to initiate the ending of a TCPCL session 537 (see Section 6.1). During termination sequencing, in-progress 538 transfers can be completed but no new transfers can be initiated. A 539 SESS_TERM message can also be used to refuse a session setup by a 540 peer (see Section 4.3). Regardless of the reason, session 541 termination is initiated by one of the entities and responded-to by 542 the other as illustrated by Figure 13 and Figure 14. Even when there 543 are no transfers queued or in-progress, the session termination 544 procedure allows each entity to distinguish between a clean end to a 545 session and the TCP connection being closed because of some 546 underlying network issue. 548 Once a session is established, TCPCL is a symmetric protocol between 549 the peers. Both sides can start sending data segments in a session, 550 and one side's bundle transfer does not have to complete before the 551 other side can start sending data segments on its own. Hence, the 552 protocol allows for a bi-directional mode of communication. Note 553 that in the case of concurrent bidirectional transmission, 554 acknowledgment segments MAY be interleaved with data segments. 556 3.3. TCPCL States and Transitions 558 The states of a normal TCPCL session (i.e., without session failures) 559 are indicated in Figure 4. 561 +-------+ 562 | START | 563 +-------+ 564 | 565 TCP Establishment 566 | 567 V 568 +-----------+ +---------------------+ 569 | TCP |----------->| Contact / Session | 570 | Connected | | Negotiation | 571 +-----------+ +---------------------+ 572 | 573 +-----Session Parameters-----+ 574 | Negotiated 575 V 576 +-------------+ +-------------+ 577 | Established |----New Transfer---->| Established | 578 | Session | | Session | 579 | Idle |<---Transfers Done---| Live | 580 +-------------+ +-------------+ 581 | | 582 +------------------------------------+ 583 | 584 V 585 +-------------+ 586 | Established | +-------------+ 587 | Session |----Transfers------>| TCP | 588 | Ending | Done | Terminating | 589 +-------------+ +-------------+ 590 | 591 +----------TCP Close Message----------+ 592 | 593 V 594 +-------+ 595 | END | 596 +-------+ 598 Figure 4: Top-level states of a TCPCL session 600 Notes on Established Session states: 602 Session "Live" means transmitting or receiving over a transfer 603 stream. 605 Session "Idle" means no transmission/reception over a transfer 606 stream. 608 Session "Ending" means no new transfers will be allowed. 610 Contact negotiation involves exchanging a Contact Header (CH) in both 611 directions and deriving a negotiated state from the two headers. The 612 contact negotiation sequencing is performed either as the active or 613 passive entity, and is illustrated in Figure 5 and Figure 6 614 respectively which both share the data validation and negotiation of 615 the Processing of Contact Header "[PCH]" activity of Figure 7 and the 616 "[TCPCLOSE]" activity which indicates TCP connection close. 617 Successful negotiation results in one of the Session Initiation 618 "[SI]" activities being performed. To avoid data loss, a Session 619 Termination "[ST]" exchange allows cleanly finishing transfers before 620 a session is ended. 622 +-------+ 623 | START | 624 +-------+ 625 | 626 TCP Connecting 627 V 628 +-----------+ 629 | TCP | +---------+ 630 | Connected |--Send CH-->| Waiting |--Timeout-->[TCPCLOSE] 631 +-----------+ +---------+ 632 | 633 Received CH 634 V 635 [PCH] 637 Figure 5: Contact Initiation as Active Entity 639 +-----------+ +---------+ 640 | TCP |--Wait for-->| Waiting |--Timeout-->[TCPCLOSE] 641 | Connected | CH +---------+ 642 +-----------+ | 643 Received CH 644 V 645 +-----------------+ 646 | Preparing reply |--Send CH-->[PCH] 647 +-----------------+ 649 Figure 6: Contact Initiation as Passive Entity 651 +-----------+ 652 | Peer CH | 653 | available | 654 +-----------+ 655 | 656 Validate and 657 Negotiate 658 V 659 +------------+ 660 | Negotiated |----Failure---->[TCPCLOSE] 661 +------------+ ^ 662 | | | 663 No TLS +----Negotiate---+ | 664 V TLS | Failure 665 +-----------+ V | 666 | TCPCL | +---------------+ 667 | Messaging |<--Success--| TLS Finished | 668 | Available | +---------------+ 669 +-----------+ 671 Figure 7: Processing of Contact Header [PCH] 673 Session negotiation involves exchanging a session initialization 674 (SESS_INIT) message in both directions and deriving a negotiated 675 state from the two messages. The session negotiation sequencing is 676 performed either as the active or passive entity, and is illustrated 677 in Figure 8 and Figure 9 respectively which both share the data 678 validation and negotiation of Figure 10. The validation here 679 includes certificate validation and authentication when TLS is used 680 for the session. 682 +-----------+ 683 | TCPCL | +---------+ 684 | Messaging |--Send SESS_INIT-->| Waiting |--Timeout-->[ST] 685 | Available | +---------+ 686 +-----------+ | 687 Received SESS_INIT 688 | 689 V 690 [PSI] 692 Figure 8: Session Initiation [SI] as Active Entity 694 +-----------+ 695 | TCPCL | +---------+ 696 | Messaging |----Wait for ---->| Waiting |--Timeout-->[ST] 697 | Available | SESS_INIT +---------+ 698 +-----------+ | 699 Received SESS_INIT 700 | 701 +-----------------+ 702 | Preparing reply |--Send SESS_INIT-->[PSI] 703 +-----------------+ 705 Figure 9: Session Initiation [SI] as Passive Entity 707 +----------------+ 708 | Peer SESS_INIT | 709 | available | 710 +----------------+ 711 | 712 Validate and 713 Negotiate 714 V 715 +------------+ 716 | Negotiated |---Failure--->[ST] 717 +------------+ 718 | 719 Success 720 V 721 +--------------+ 722 | Established | 723 | Session Idle | 724 +--------------+ 726 Figure 10: Processing of Session Initiation [PSI] 728 Transfers can occur after a session is established and it's not in 729 the Ending state. Each transfer occurs within a single logical 730 transfer stream between a sender and a receiver, as illustrated in 731 Figure 11 and Figure 12 respectively. 733 +--Send XFER_SEGMENT--+ 734 +--------+ | | 735 | Stream | +-------------+ | 736 | Idle |---Send XFER_SEGMENT-->| In Progress |<------------+ 737 +--------+ +-------------+ 738 | 739 +---------All segments sent-------+ 740 | 741 V 742 +---------+ +--------+ 743 | Waiting |---- Receive Final---->| Stream | 744 | for Ack | XFER_ACK | IDLE | 745 +---------+ +--------+ 747 Figure 11: Transfer sender states 749 Notes on transfer sending: 751 Pipelining of transfers can occur when the sending entity begins a 752 new transfer while in the "Waiting for Ack" state. 754 +-Receive XFER_SEGMENT-+ 755 +--------+ | Send XFER_ACK | 756 | Stream | +-------------+ | 757 | Idle |--Receive XFER_SEGMENT-->| In Progress |<-------------+ 758 +--------+ +-------------+ 759 | 760 +--------Sent Final XFER_ACK--------+ 761 | 762 V 763 +--------+ 764 | Stream | 765 | Idle | 766 +--------+ 768 Figure 12: Transfer receiver states 770 Session termination involves one entity initiating the termination of 771 the session and the other entity acknowledging the termination. For 772 either entity, it is the sending of the SESS_TERM message which 773 transitions the session to the Ending substate. While a session is 774 in the Ending state only in-progress transfers can be completed and 775 no new transfers can be started. 777 +-----------+ +---------+ 778 | Session |--Send SESS_TERM-->| Session | 779 | Live/Idle | | Ending | 780 +-----------+ +---------+ 782 Figure 13: Session Termination [ST] from the Initiator 784 +-----------+ +---------+ 785 | Session |--Send SESS_TERM-->| Session | 786 | Live/Idle | | Ending | 787 +-----------+<------+ +---------+ 788 | | 789 Receive SESS_TERM | 790 | | 791 +-------------+ 793 Figure 14: Session Termination [ST] from the Responder 795 3.4. Transfer Segmentation Policies 797 Each TCPCL session allows a negotiated transfer segmentation polcy to 798 be applied in each transfer direction. A receiving node can set the 799 Segment MRU in its SESS_INIT message to determine the largest 800 acceptable segment size, and a transmitting node can segment a 801 transfer into any sizes smaller than the receiver's Segment MRU. It 802 is a network administration matter to determine an appropriate 803 segmentation policy for entities operating TCPCL, but guidance given 804 here can be used to steer policy toward performance goals. It is 805 also advised to consider the Segment MRU in relation to chunking/ 806 packetization performed by TLS, TCP, and any intermediate network- 807 layer nodes. 809 Minimum Overhead: For a simple network expected to exchange 810 relatively small bundles, the Segment MRU can be set to be 811 identical to the Transfer MRU which indicates that all transfers 812 can be sent with a single data segment (i.e., no actual 813 segmentation). If the network is closed and all transmitters are 814 known to follow a single-segment transfer policy, then receivers 815 can avoid the necessity of segment reassembly. Because this CL 816 operates over a TCP stream, which suffers from a form of head-of- 817 queue blocking between messages, while one node is transmitting a 818 single XFER_SEGMENT message it is not able to transmit any 819 XFER_ACK or XFER_REFUSE for any associated received transfers. 821 Predictable Message Sizing: In situations where the maximum message 822 size is desired to be well-controlled, the Segment MRU can be set 823 to the largest acceptable size (the message size less XFER_SEGMENT 824 header size) and transmitters can always segment a transfer into 825 maximum-size chunks no larger than the Segment MRU. This 826 guarantees that any single XFER_SEGMENT will not monopolize the 827 TCP stream for too long, which would prevent outgoing XFER_ACK and 828 XFER_REFUSE associated with received transfers. 830 Dynamic Segmentation: Even after negotiation of a Segment MRU for 831 each receiving node, the actual transfer segmentation only needs 832 to guarantee than any individual segment is no larger than that 833 MRU. In a situation where TCP throughput is dynamic, the transfer 834 segmentation size can also be dynamic in order to control message 835 transmission duration. 837 Many other policies can be established in a TCPCL network between the 838 two extremes of minimum overhead (large MRU, single-segment) and 839 predictable message sizing (small MRU, highly segmented). Different 840 policies can be applied to each transfer stream to and from any 841 particular node. Additionally, future header and transfer extension 842 types can apply further nuance to transfer policies and policy 843 negotiation. 845 3.5. Example Message Exchange 847 The following figure depicts the protocol exchange for a simple 848 session, showing the session establishment and the transmission of a 849 single bundle split into three data segments (of lengths "L1", "L2", 850 and "L3") from Entity A to Entity B. 852 Note that the sending node can transmit multiple XFER_SEGMENT 853 messages without waiting for the corresponding XFER_ACK responses. 854 This enables pipelining of messages on a transfer stream. Although 855 this example only demonstrates a single bundle transmission, it is 856 also possible to pipeline multiple XFER_SEGMENT messages for 857 different bundles without necessarily waiting for XFER_ACK messages 858 to be returned for each one. However, interleaving data segments 859 from different bundles is not allowed. 861 No errors or rejections are shown in this example. 863 Entity A Entity B 864 ======== ======== 865 +-------------------------+ 866 | Open TCP Connection | -> +-------------------------+ 867 +-------------------------+ <- | Accept Connection | 868 +-------------------------+ 869 +-------------------------+ 870 | Contact Header | -> +-------------------------+ 871 +-------------------------+ <- | Contact Header | 872 +-------------------------+ 874 +-------------------------+ 875 | SESS_INIT | -> +-------------------------+ 876 +-------------------------+ <- | SESS_INIT | 877 +-------------------------+ 879 +-------------------------+ 880 | XFER_SEGMENT (start) | -> 881 | Transfer ID [I1] | 882 | Length [L1] | 883 | Bundle Data 0..(L1-1) | 884 +-------------------------+ 885 +-------------------------+ +-------------------------+ 886 | XFER_SEGMENT | -> <- | XFER_ACK (start) | 887 | Transfer ID [I1] | | Transfer ID [I1] | 888 | Length [L2] | | Length [L1] | 889 |Bundle Data L1..(L1+L2-1)| +-------------------------+ 890 +-------------------------+ 891 +-------------------------+ +-------------------------+ 892 | XFER_SEGMENT (end) | -> <- | XFER_ACK | 893 | Transfer ID [I1] | | Transfer ID [I1] | 894 | Length [L3] | | Length [L1+L2] | 895 |Bundle Data | +-------------------------+ 896 | (L1+L2)..(L1+L2+L3-1)| 897 +-------------------------+ 898 +-------------------------+ 899 <- | XFER_ACK (end) | 900 | Transfer ID [I1] | 901 | Length [L1+L2+L3] | 902 +-------------------------+ 904 +-------------------------+ 905 | SESS_TERM | -> +-------------------------+ 906 +-------------------------+ <- | SESS_TERM | 907 +-------------------------+ 908 +-------------------------+ +-------------------------+ 909 | TCP Close | -> <- | TCP Close | 910 +-------------------------+ +-------------------------+ 912 Figure 15: An example of the flow of protocol messages on a single 913 TCP Session between two entities 915 4. Session Establishment 917 For bundle transmissions to occur using the TCPCL, a TCPCL session 918 MUST first be established between communicating entities. It is up 919 to the implementation to decide how and when session setup is 920 triggered. For example, some sessions can be opened proactively and 921 maintained for as long as is possible given the network conditions, 922 while other sessions are be opened only when there is a bundle that 923 is queued for transmission and the routing algorithm selects a 924 certain next-hop node. 926 4.1. TCP Connection 928 To establish a TCPCL session, an entity MUST first establish a TCP 929 connection with the intended peer entity, typically by using the 930 services provided by the operating system. Destination port number 931 4556 has been assigned by IANA as the Registered Port number for the 932 TCP convergence layer. Other destination port numbers MAY be used 933 per local configuration. Determining a peer's destination port 934 number (if different from the registered TCPCL port number) is up to 935 the implementation. Any source port number MAY be used for TCPCL 936 sessions. Typically an operating system assigned number in the TCP 937 Ephemeral range (49152-65535) is used. 939 If the entity is unable to establish a TCP connection for any reason, 940 then it is an implementation matter to determine how to handle the 941 connection failure. An entity MAY decide to re-attempt to establish 942 the connection. If it does so, it MUST NOT overwhelm its target with 943 repeated connection attempts. Therefore, the entity MUST NOT retry 944 the connection setup earlier than some delay time from the last 945 attempt, and it SHOULD use a (binary) exponential back-off mechanism 946 to increase this delay in case of repeated failures. The upper limit 947 on a re-attempt back-off is implementation defined but SHOULD be no 948 longer than one minute (60 seconds) before signaling to the BP agent 949 that a connection cannot be made. 951 Once a TCP connection is established, the active entity SHALL 952 immediately transmit its Contact Header. Once a TCP connection is 953 established, the passive entity SHALL wait for the peer's Contact 954 Header. If the passive entity does not receive a Contact Header 955 after some implementation-defined time duration after TCP connection 956 is established, the entity SHALL close the TCP connection. Entities 957 SHOULD choose a Contact Header reception timeout interval no longer 958 than 10 minutes (600 seconds). Upon reception of a Contact Header, 959 the passive entity SHALL transmit its Contact Header. The ordering 960 of the Contact Header exchange allows the passive entity to avoid 961 allocating resources to a potential TCPCL session until after a valid 962 Contact Header has been received from the active entity. This 963 ordering also allows the passive peer to adapt to alternate TCPCL 964 protocol versions. 966 The format of the Contact Header is described in Section 4.2. 967 Because the TCPCL protocol version in use is part of the initial 968 Contact Header, nodes using TCPCL version 4 can coexist on a network 969 with nodes using earlier TCPCL versions (with some negotiation needed 970 for interoperation as described in Section 4.3). 972 4.2. Contact Header 974 This section describes the format of the Contact Header and the 975 meaning of its fields. 977 If an entity is capable of exchanging messages according to TLS 1.3 978 [RFC8446] or any successors which are compatible with that TLS 979 ClientHello, the the CAN_TLS flag within its Contact Header SHALL be 980 set to 1. This behavior prefers the use of TLS when possible, even 981 if security policy does not allow or require authentication. This 982 follows the opportunistic security model of [RFC7435]. 984 Upon receipt of the Contact Header, both entities perform the 985 validation and negotiation procedures defined in Section 4.3. After 986 receiving the Contact Header from the other entity, either entity MAY 987 refuse the session by sending a SESS_TERM message with an appropriate 988 reason code. 990 The format for the Contact Header is as follows: 992 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 993 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 994 +---------------+---------------+---------------+---------------+ 995 | magic='dtn!' | 996 +---------------+---------------+---------------+---------------+ 997 | Version | Flags | 998 +---------------+---------------+ 1000 Figure 16: Contact Header Format 1002 See Section 4.3 for details on the use of each of these Contact 1003 Header fields. 1005 The fields of the Contact Header are: 1007 magic: A four-octet field that always contains the octet sequence 1008 0x64 0x74 0x6E 0x21, i.e., the text string "dtn!" in US-ASCII (and 1009 UTF-8). 1011 Version: A one-octet field value containing the value 4 (current 1012 version of the TCPCL). 1014 Flags: A one-octet field of single-bit flags, interpreted according 1015 to the descriptions in Table 1. All reserved header flag bits 1016 SHALL be set to 0 by the sender. All reserved header flag bits 1017 SHALL be ignored by the receiver. 1019 +----------+--------+-----------------------------------------------+ 1020 | Name | Code | Description | 1021 +----------+--------+-----------------------------------------------+ 1022 | CAN_TLS | 0x01 | If bit is set, indicates that the sending | 1023 | | | peer is capable of TLS security. | 1024 | | | | 1025 | Reserved | others | 1026 +----------+--------+-----------------------------------------------+ 1028 Table 1: Contact Header Flags 1030 4.3. Contact Validation and Negotiation 1032 Upon reception of the Contact Header, each node follows the following 1033 procedures to ensure the validity of the TCPCL session and to 1034 negotiate values for the session parameters. 1036 If the magic string is not present or is not valid, the connection 1037 MUST be terminated. The intent of the magic string is to provide 1038 some protection against an inadvertent TCP connection by a different 1039 protocol than the one described in this document. To prevent a flood 1040 of repeated connections from a misconfigured application, a passive 1041 entity MAY deny new TCP connections from a specific peer address for 1042 a period of time after one or more connections fail to provide a 1043 decodable Contact Header. 1045 The first negotiation is on the TCPCL protocol version to use. The 1046 active entity always sends its Contact Header first and waits for a 1047 response from the passive entity. During contact initiation, the 1048 active TCPCL node SHALL send the highest TCPCL protocol version on a 1049 first session attempt for a TCPCL peer. If the active entity 1050 receives a Contact Header with a lower protocol version than the one 1051 sent earlier on the TCP connection, the TCP connection SHALL be 1052 closed. If the active entity receives a SESS_TERM message with 1053 reason of "Version Mismatch", that node MAY attempt further TCPCL 1054 sessions with the peer using earlier protocol version numbers in 1055 decreasing order. Managing multi-TCPCL-session state such as this is 1056 an implementation matter. 1058 If the passive entity receives a Contact Header containing a version 1059 that is not a version of the TCPCL that the entity implements, then 1060 the entity SHALL send its Contact Header and immediately terminate 1061 the session with a reason code of "Version mismatch". If the passive 1062 entity receives a Contact Header with a version that is lower than 1063 the latest version of the protocol that the entity implements, the 1064 entity MAY either terminate the session (with a reason code of 1065 "Version mismatch") or adapt its operation to conform to the older 1066 version of the protocol. The decision of version fall-back is an 1067 implementation matter. 1069 The negotiated contact parameters defined by this specification are 1070 described in the following paragraphs. 1072 TCPCL Version: Both Contact Headers of a successful contact 1073 negotiation have identical TCPCL Version numbers as described 1074 above. Only upon response of a Contact Header from the passive 1075 entity is the TCPCL protocol version established and session 1076 negotiation begun. 1078 Enable TLS: Negotiation of the Enable TLS parameter is performed by 1079 taking the logical AND of the two Contact Headers' CAN_TLS flags. 1080 A local security policy is then applied to determine of the 1081 negotiated value of Enable TLS is acceptable. It can be a 1082 reasonable security policy to require or disallow the use of TLS 1083 depending upon the desired network flows. Because this state is 1084 negotiated over an unsecured medium, there is a risk of a TLS 1085 Stripping as described in Section 8. If the Enable TLS state is 1086 unacceptable, the entity SHALL terminate the session with a reason 1087 code of "Contact Failure". Note that this contact failure reason 1088 is different than a failure of TLS handshake or TLS authentication 1089 after an agreed-upon and acceptable Enable TLS state. If the 1090 negotiated Enable TLS value is true and acceptable then TLS 1091 negotiation feature (described in Section 4.4) begins immediately 1092 following the Contact Header exchange. 1094 4.4. Session Security 1096 This version of the TCPCL supports establishing a Transport Layer 1097 Security (TLS) session within an existing TCP connection. When TLS 1098 is used within the TCPCL it affects the entire session. Once TLS is 1099 established, there is no mechanism available to downgrade the TCPCL 1100 session to non-TLS operation. 1102 Once established, the lifetime of a TLS connection SHALL be bound to 1103 the lifetime of the underlying TCP connection. Immediately prior to 1104 actively ending a TLS connection after TCPCL session termination, the 1105 peer which sent the original (non-reply) SESS_TERM message SHOULD 1106 follow the Closure Alert procedure of [RFC8446] to cleanly terminate 1107 the TLS connection. Because each TCPCL message is either fixed- 1108 length or self-indicates its length, the lack of a TLS Closure Alert 1109 will not cause data truncation or corruption. 1111 Subsequent TCPCL session attempts to the same passive entity MAY 1112 attempt use the TLS connection resumption feature. There is no 1113 guarantee that the passive entity will accept the request to resume a 1114 TLS session, and the active entity cannot assume any resumption 1115 outcome. 1117 4.4.1. Entity Identification 1119 The TCPCL uses the TLS for certificate exchange in both directions to 1120 identify each entity and to allow each entity to authenticate its 1121 peer. Each certificate can potentially identify multiple entities 1122 and there is no problem using such a certificate as long as the 1123 identifiers are sufficient to meet authentication policy (as 1124 described in later sections) for the entity which presents it. 1126 The public key infrastructure (PKI) Certificate Authority (CA) or 1127 authorities available within a network are likely not controlled by 1128 the certificate end users and CA policies vary widely between 1129 networks and PKI management tools. For this reason, the TCPCL 1130 defines a prioritized list of what a certificate can identify about a 1131 TCPCL entity: 1133 Node ID: The ideal certificate identity is the Node ID of the entity 1134 using the NODE-ID definition below. When the Node ID is 1135 identified, there is no need for any lower-level identification to 1136 take place. 1138 Host Name: If CA policy forbids a certificate to contain an 1139 arbitrary NODE-ID but allows a DNS-ID to be identified then one or 1140 more stable host names can be identified in the certificate. The 1141 use of wildcard DNS-ID is discouraged due to the complex rules for 1142 matching and dependence on implementation support for wildcard 1143 matching. 1145 Network Address: If no stable host name is available but a stable 1146 network address is available and CA policy allows a certificate to 1147 contain a NETWORK-ID (as defined below) then one or more network 1148 addresses can be identified in the certificate. There is no 1149 wildcard-type address matching defined, so this is the least 1150 robust 1152 When only a DNS-ID or NETWORK-ID can be identified by a certificate, 1153 it is implied that an entity which authenticates using that 1154 certificate is trusted to provide a valid Node ID in its SESS_INIT; 1155 the certificate itself does not actually authenticate that Node ID. 1157 The RECOMMENDED security policy of an entity is to validate a peer 1158 which authenticates its Node ID regardless of an authenticated host 1159 name or address, and only consider the host/address authentication in 1160 the absence of an authenticated Node ID. 1162 This specification defines a NODE-ID of a certificate as being the 1163 subjectAltName entry of type uniformResourceIdentifier whose value is 1164 a URI consistent with the requirements of [RFC3986] and the URI 1165 schemes of the IANA "Bundle Protocol URI Scheme Type" registry. This 1166 is similar to the URI-ID of [RFC6125] but does not require any 1167 structure to the scheme-specific-part of the URI. Unless specified 1168 otherwise by the definition of the URI scheme being authenticated, 1169 URI matching of a NODE-ID SHALL use the URI comparison logic of 1170 [RFC3986] and scheme-based normalization of those schemes specified 1171 in [I-D.ietf-dtn-bpbis]. A URI scheme can refine this "exact match" 1172 logic with rules about how Node IDs within that scheme are to be 1173 compared with the certificate-authenticated NODE-ID. 1175 This specification defines a NETWORK-ID of a certificate as being the 1176 subjectAltName entry of type iPAddress whose value is encoded 1177 according to [RFC5280]. 1179 4.4.2. TLS Handshake 1181 The use of TLS is negotiated using the Contact Header as described in 1182 Section 4.3. After negotiating an Enable TLS parameter of true, and 1183 before any other TCPCL messages are sent within the session, the 1184 session entities SHALL begin a TLS handshake in accordance with 1185 [RFC8446]. By convention, this protocol uses the entity which 1186 initiated the underlying TCP connection (the active peer) as the 1187 "client" role of the TLS handshake request. 1189 The TLS handshake, if it occurs, is considered to be part of the 1190 contact negotiation before the TCPCL session itself is established. 1191 Specifics about sensitive data exposure are discussed in Section 8. 1193 The parameters within each TLS negotiation are implementation 1194 dependent but any TCPCL node SHALL follow all recommended practices 1195 of BCP 195 [RFC7525], or any updates or successors that become part 1196 of BCP 195. Within each TLS handshake, the following requirements 1197 apply (using the rough order in which they occur): 1199 Client Hello: When a resolved host name was used to establish the 1200 TCP connection, the TLS ClientHello SHOULD include a Server Name 1201 Indication (SNI) in accordance with [RFC6066] containing that host 1202 name (of the passive entity) which was resolved. Note: The SNI 1203 text is the network-layer name for the passive entity, which is 1204 not the Node ID of that entity. 1206 Server Certificate: The passive entity SHALL supply a certificate 1207 within the TLS handshake to allow authentication of its side of 1208 the session. Unless prohibited by CA policy, the passive entity 1209 certificate SHALL contain a NODE-ID which authenticates the Node 1210 ID of the peer. When assigned a stable host name, the passive 1211 entity certificate SHOULD contain a DNS-ID which authenticates 1212 that (fully qualified) name. When assigned a stable network 1213 address, the passive entity certificate MAY contain a NETWORK-ID 1214 which authenticates that address. The passive entity MAY use the 1215 SNI host name to choose an appropriate server-side certificate 1216 which authenticates that host name. 1218 Certificate Request: During TLS handshake, the passive entity SHALL 1219 request a client-side certificate. 1221 Client Certificate: The active entity SHALL supply a certificate 1222 chain within the TLS handshake to allow authentication of its side 1223 of the session. Unless prohibited by CA policy, the active entity 1224 certificate SHALL contain a NODE-ID which authenticates the Node 1225 ID of the peer. When assigned a stable host name, the active 1226 entity certificate SHOULD contain a DNS-ID which authenticates 1227 that (fully qualified) name. When assigned a stable network 1228 address, the active entity certificate MAY contain a NETWORK-ID 1229 which authenticates that address. 1231 All certificates supplied during TLS handshake SHALL conform to 1232 [RFC5280], or any updates or successors to that profile. When a 1233 certificate is supplied during TLS handshake, the full certification 1234 chain SHOULD be included unless security policy indicates that is 1235 unnecessary. 1237 If a TLS handshake cannot negotiate a TLS connection, both entities 1238 of the TCPCL session SHALL close the TCP connection. At this point 1239 the TCPCL session has not yet been established so there is no TCPCL 1240 session to terminate. 1242 After a TLS connection is successfully established, the active entity 1243 SHALL send a SESS_INIT message to begin session negotiation. This 1244 session negotiation and all subsequent messaging are secured. 1246 4.4.3. TLS Authentication 1248 Using X.509 certificates exchanged during the TLS handshake, each of 1249 the entities can attempt to authenticate its peer Node ID directly or 1250 authenticate the peer host name or network address. The Node ID 1251 exchanged in the Session Initialization is likely to be used by the 1252 BP agent for making transfer and routing decisions, so attempting 1253 Node ID validation is required while attempting host name validation 1254 is optional. The logic for attempting validation is separate from 1255 the logic for handling the result of validation, which is based on 1256 local security policy. 1258 By using the SNI host name (see Section 4.4.2) a single passive 1259 entity can act as a convergence layer for multiple BP agents with 1260 distinct Node IDs. When this "virtual host" behavior is used, the 1261 host name is used as the indication of which BP Node the active 1262 entity is attempting to communicate with. A virtual host CL entity 1263 can be authenticated by a certificate containing all of the host 1264 names and/or Node IDs being hosted or by several certificates each 1265 authenticating a single host name and/or Node ID, using the SNI value 1266 from the peer to select which certificate to use. 1268 Any certificate received during TLS handshake SHALL be validated up 1269 to one or more trusted CA certificates. If certificate validation 1270 fails or if security policy disallows a certificate for any reason, 1271 the entity SHALL terminate the session (with a reason code of 1272 "Contact Failure"). 1274 Either during or immediately after the TLS handshake, the active 1275 entity SHALL attempt to authenticate the host name (of the passive 1276 entity) used to initiate the TCP connection using any DNS-ID of the 1277 peer certificate. If host name validation fails (including failure 1278 because the certificate does not contain any DNS-ID) and security 1279 policy disallows an unauthenticated host, the entity SHALL terminate 1280 the session (with a reason code of "Contact Failure"). 1282 Either during or immediately after the TLS handshake, the active 1283 entity SHALL attempt to authenticate the IP address of the other side 1284 of the TCP connection using any NETWORK-ID of the peer certificate. 1285 Either during or immediately after the TLS handshake, the passive 1286 entity SHALL attempt to authenticate the IP address of the other side 1287 of the TCP connection using any NETWORK-ID of the peer certificate. 1288 If host address validation fails (including failure because the 1289 certificate does not contain any NETWORK-ID) and security policy 1290 disallows an unauthenticated host, the entity SHALL terminate the 1291 session (with a reason code of "Contact Failure"). 1293 Immediately before Session Parameter Negotiation, each side of the 1294 session SHALL perform Node ID validation of its peer as described 1295 below. Node ID validation SHALL succeed if the associated 1296 certificate includes a NODE-ID whose value matches the Node ID of the 1297 TCPCL entity. If Node ID validation fails (including failure because 1298 the certificate does not contain any NODE-ID) and security policy 1299 disallows an unauthenticated Node ID, the entity SHALL terminate the 1300 session (with a reason code of "Contact Failure"). 1302 4.4.4. Example TLS Initiation 1304 A summary of a typical TLS use is shown in the sequence in Figure 17 1305 below. In this example the active peer terminates the session but 1306 termination can be initiated from either peer. 1308 Entity A Entity B 1309 active peer passive peer 1311 +-------------------------+ 1312 | Open TCP Connection | -> +-------------------------+ 1313 +-------------------------+ <- | Accept Connection | 1314 +-------------------------+ 1315 +-------------------------+ 1316 | Contact Header | -> +-------------------------+ 1317 +-------------------------+ <- | Contact Header | 1318 +-------------------------+ 1320 +-------------------------+ +-------------------------+ 1321 | TLS Negotiation | -> <- | TLS Negotiation | 1322 | (as client) | | (as server) | 1323 +-------------------------+ +-------------------------+ 1325 Host name validation occurs. 1326 Secured TCPCL messaging can begin. 1328 +-------------------------+ 1329 | SESS_INIT | -> +-------------------------+ 1330 +-------------------------+ <- | SESS_INIT | 1331 +-------------------------+ 1333 Node ID validation occurs. 1334 Session is established, transfers can begin. 1336 +-------------------------+ 1337 | SESS_TERM | -> +-------------------------+ 1338 +-------------------------+ <- | SESS_TERM | 1339 +-------------------------+ 1340 +-------------------------+ 1341 | TLS Closure Alert | -> +-------------------------+ 1342 +-------------------------+ <- | TLS Closure Alert | 1343 +-------------------------+ 1344 +-------------------------+ +-------------------------+ 1345 | TCP Close | -> <- | TCP Close | 1346 +-------------------------+ +-------------------------+ 1348 Figure 17: A simple visual example of TCPCL TLS Establishment between 1349 two entities 1351 4.5. Message Header 1353 After the initial exchange of a Contact Header, all messages 1354 transmitted over the session are identified by a one-octet header 1355 with the following structure: 1357 0 1 2 3 4 5 6 7 1358 +---------------+ 1359 | Message Type | 1360 +---------------+ 1362 Figure 18: Format of the Message Header 1364 The message header fields are as follows: 1366 Message Type: Indicates the type of the message as per Table 2 1367 below. Encoded values are listed in Section 9.5. 1369 +--------------+------+---------------------------------------------+ 1370 | Name | Code | Description | 1371 +--------------+------+---------------------------------------------+ 1372 | SESS_INIT | 0x07 | Contains the session parameter | 1373 | | | inputs from one of the entities, | 1374 | | | as described in Section 4.6. | 1375 | | | | 1376 | SESS_TERM | 0x05 | Indicates that one of the | 1377 | | | entities participating in the session | 1378 | | | wishes to cleanly terminate the session, as | 1379 | | | described in Section 6.1. | 1380 | | | | 1381 | XFER_SEGMENT | 0x01 | Indicates the transmission of | 1382 | | | a segment of bundle data, as described in | 1383 | | | Section 5.2.2. | 1384 | | | | 1385 | XFER_ACK | 0x02 | Acknowledges reception of a | 1386 | | | data segment, as described in | 1387 | | | Section 5.2.3. | 1388 | | | | 1389 | XFER_REFUSE | 0x03 | Indicates that the | 1390 | | | transmission of the current bundle SHALL be | 1391 | | | stopped, as described in | 1392 | | | Section 5.2.4. | 1393 | | | | 1394 | KEEPALIVE | 0x04 | Used to keep TCPCL session | 1395 | | | active, as described in | 1396 | | | Section 5.1.1. | 1397 | | | | 1398 | MSG_REJECT | 0x06 | Contains a TCPCL message | 1399 | | | rejection, as described in | 1400 | | | Section 5.1.2. | 1401 +--------------+------+---------------------------------------------+ 1403 Table 2: TCPCL Message Types 1405 4.6. Session Initialization Message (SESS_INIT) 1407 Before a session is established and ready to transfer bundles, the 1408 session parameters are negotiated between the connected entities. 1409 The SESS_INIT message is used to convey the per-entity parameters 1410 which are used together to negotiate the per-session parameters as 1411 described in Section 4.7. 1413 The format of a SESS_INIT message is as follows in Figure 19. 1415 +-----------------------------+ 1416 | Message Header | 1417 +-----------------------------+ 1418 | Keepalive Interval (U16) | 1419 +-----------------------------+ 1420 | Segment MRU (U64) | 1421 +-----------------------------+ 1422 | Transfer MRU (U64) | 1423 +-----------------------------+ 1424 | Node ID Length (U16) | 1425 +-----------------------------+ 1426 | Node ID Data (variable) | 1427 +-----------------------------+ 1428 | Session Extension | 1429 | Items Length (U32) | 1430 +-----------------------------+ 1431 | Session Extension | 1432 | Items (var.) | 1433 +-----------------------------+ 1435 Figure 19: SESS_INIT Format 1437 The fields of the SESS_INIT message are: 1439 Keepalive Interval: A 16-bit unsigned integer indicating the minimum 1440 interval, in seconds, to negotiate the Session Keepalive using the 1441 method of Section 4.7. 1443 Segment MRU: A 64-bit unsigned integer indicating the largest 1444 allowable single-segment data payload size to be received in this 1445 session. Any XFER_SEGMENT sent to this peer SHALL have a data 1446 payload no longer than the peer's Segment MRU. The two entities 1447 of a single session MAY have different Segment MRUs, and no 1448 relation between the two is required. 1450 Transfer MRU: A 64-bit unsigned integer indicating the largest 1451 allowable total-bundle data size to be received in this session. 1452 Any bundle transfer sent to this peer SHALL have a Total Bundle 1453 Length payload no longer than the peer's Transfer MRU. This value 1454 can be used to perform proactive bundle fragmentation. The two 1455 entities of a single session MAY have different Transfer MRUs, and 1456 no relation between the two is required. 1458 Node ID Length and Node ID Data: Together these fields represent a 1459 variable-length text string. The Node ID Length is a 16-bit 1460 unsigned integer indicating the number of octets of Node ID Data 1461 to follow. A zero-length Node ID SHALL be used to indicate the 1462 lack of Node ID rather than a truly empty Node ID. This case 1463 allows an entity to avoid exposing Node ID information on an 1464 untrusted network. A non-zero-length Node ID Data SHALL contain 1465 the UTF-8 encoded Node ID of the Entity which sent the SESS_INIT 1466 message. Every Node ID SHALL be a URI consistent with the 1467 requirements of [RFC3986] and the URI schemes of the IANA "Bundle 1468 Protocol URI Scheme Type" registry. The Node ID itself can be 1469 authenticated as described in Section 4.4.3. 1471 Session Extension Length and Session Extension Items: 1472 Together these fields represent protocol extension data not 1473 defined by this specification. The Session Extension Length is 1474 the total number of octets to follow which are used to encode the 1475 Session Extension Item list. The encoding of each Session 1476 Extension Item is within a consistent data container as described 1477 in Section 4.8. The full set of Session Extension Items apply for 1478 the duration of the TCPCL session to follow. The order and 1479 multiplicity of these Session Extension Items is significant, as 1480 defined in the associated type specification(s). 1482 4.7. Session Parameter Negotiation 1484 An entity calculates the parameters for a TCPCL session by 1485 negotiating the values from its own preferences (conveyed by the 1486 SESS_INIT it sent to the peer) with the preferences of the peer node 1487 (expressed in the SESS_INIT that it received from the peer). The 1488 negotiated parameters defined by this specification are described in 1489 the following paragraphs. 1491 Transfer MTU and Segment MTU: The maximum transmit unit (MTU) for 1492 whole transfers and individual segments are identical to the 1493 Transfer MRU and Segment MRU, respectively, of the received 1494 Contact Header. A transmitting peer can send individual segments 1495 with any size smaller than the Segment MTU, depending on local 1496 policy, dynamic network conditions, etc. Determining the size of 1497 each transmitted segment is an implementation matter. If either 1498 the Transfer MRU or Segment MRU is unacceptable, the entity SHALL 1499 terminate the session with a reason code of "Contact Failure". 1501 Session Keepalive: Negotiation of the Session Keepalive parameter is 1502 performed by taking the minimum of the two Contact Headers' 1503 Keepalive Interval values. The Session Keepalive interval is a 1504 parameter for the behavior described in Section 5.1.1. If the 1505 Session Keepalive interval is unacceptable, the entity SHALL 1506 terminate the session with a reason code of "Contact Failure". 1507 Note: a negotiated Session Keepalive of zero indicates that 1508 KEEPALIVEs are disabled. 1510 Once this process of parameter negotiation is completed (which 1511 includes a possible completed TLS handshake of the connection to use 1512 TLS), this protocol defines no additional mechanism to change the 1513 parameters of an established session; to effect such a change, the 1514 TCPCL session MUST be terminated and a new session established. 1516 4.8. Session Extension Items 1518 Each of the Session Extension Items SHALL be encoded in an identical 1519 Type-Length-Value (TLV) container form as indicated in Figure 20. 1521 The fields of the Session Extension Item are: 1523 Item Flags: A one-octet field containing generic bit flags about the 1524 Item, which are listed in Table 3. All reserved header flag bits 1525 SHALL be set to 0 by the sender. All reserved header flag bits 1526 SHALL be ignored by the receiver. If a TCPCL entity receives a 1527 Session Extension Item with an unknown Item Type and the CRITICAL 1528 flag of 1, the entity SHALL close the TCPCL session with SESS_TERM 1529 reason code of "Contact Failure". If the CRITICAL flag is 0, an 1530 entity SHALL skip over and ignore any item with an unknown Item 1531 Type. 1533 Item Type: A 16-bit unsigned integer field containing the type of 1534 the extension item. This specification does not define any 1535 extension types directly, but does create an IANA registry for 1536 such codes (see Section 9.3). 1538 Item Length: A 16-bit unsigned integer field containing the number 1539 of Item Value octets to follow. 1541 Item Value: A variable-length data field which is interpreted 1542 according to the associated Item Type. This specification places 1543 no restrictions on an extension's use of available Item Value 1544 data. Extension specifications SHOULD avoid the use of large data 1545 lengths, as no bundle transfers can begin until the full extension 1546 data is sent. 1548 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1549 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 1550 +---------------+---------------+---------------+---------------+ 1551 | Item Flags | Item Type | Item Length...| 1552 +---------------+---------------+---------------+---------------+ 1553 | length contd. | Item Value... | 1554 +---------------+---------------+---------------+---------------+ 1556 Figure 20: Session Extension Item Format 1558 +----------+--------+-----------------------------------------------+ 1559 | Name | Code | Description | 1560 +----------+--------+-----------------------------------------------+ 1561 | CRITICAL | 0x01 | If bit is set, indicates that the receiving | 1562 | | | peer must handle the extension item. | 1563 | | | | 1564 | Reserved | others | 1565 +----------+--------+-----------------------------------------------+ 1567 Table 3: Session Extension Item Flags 1569 5. Established Session Operation 1571 This section describes the protocol operation for the duration of an 1572 established session, including the mechanism for transmitting bundles 1573 over the session. 1575 5.1. Upkeep and Status Messages 1577 5.1.1. Session Upkeep (KEEPALIVE) 1579 The protocol includes a provision for transmission of KEEPALIVE 1580 messages over the TCPCL session to help determine if the underlying 1581 TCP connection has been disrupted. 1583 As described in Section 4.3, a negotiated parameter of each session 1584 is the Session Keepalive interval. If the negotiated Session 1585 Keepalive is zero (i.e., one or both contact headers contains a zero 1586 Keepalive Interval), then the keepalive feature is disabled. There 1587 is no logical minimum value for the keepalive interval (within the 1588 minimum imposed by the positive-value encoding), but when used for 1589 many sessions on an open, shared network a short interval could lead 1590 to excessive traffic. For shared network use, entities SHOULD choose 1591 a keepalive interval no shorter than 30 seconds. There is no logical 1592 maximum value for the keepalive interval (within the maximum imposed 1593 by the fixed-size encoding), but an idle TCP connection is liable for 1594 closure by the host operating system if the keepalive time is longer 1595 than tens-of-minutes. Entities SHOULD choose a keepalive interval no 1596 longer than 10 minutes (600 seconds). 1598 Note: The Keepalive Interval SHOULD NOT be chosen too short as TCP 1599 retransmissions MAY occur in case of packet loss. Those will have to 1600 be triggered by a timeout (TCP retransmission timeout (RTO)), which 1601 is dependent on the measured RTT for the TCP connection so that 1602 KEEPALIVE messages can experience noticeable latency. 1604 The format of a KEEPALIVE message is a one-octet message type code of 1605 KEEPALIVE (as described in Table 2) with no additional data. Both 1606 sides SHALL send a KEEPALIVE message whenever the negotiated interval 1607 has elapsed with no transmission of any message (KEEPALIVE or other). 1609 If no message (KEEPALIVE or other) has been received in a session 1610 after some implementation-defined time duration, then the entity 1611 SHALL terminate the session by transmitting a SESS_TERM message (as 1612 described in Section 6.1) with reason code "Idle Timeout". If 1613 configurable, the idle timeout duration SHOULD be no shorter than 1614 twice the keepalive interval. If not configurable, the idle timeout 1615 duration SHOULD be exactly twice the keepalive interval. 1617 5.1.2. Message Rejection (MSG_REJECT) 1619 This message type is not expected to be seen in a well-functioning 1620 session. Its purpose is to aid in troubleshooting bad entity 1621 behavior by allowing the peer to observe why an entity is not 1622 responding as expected to its messages. 1624 If a TCPCL entity receives a message type which is unknown to it 1625 (possibly due to an unhandled protocol version mismatch or a 1626 incorrectly-negotiated session extension which defines a new message 1627 type), the entity SHALL send a MSG_REJECT message with a Reason Code 1628 of "Message Type Unknown" and close the TCP connection. If a TCPCL 1629 entity receives a message type which is known but is inappropriate 1630 for the negotiated session parameters (possibly due to incorrectly- 1631 negotiated session extension), the entity SHALL send a MSG_REJECT 1632 message with a Reason Code of "Message Unsupported". If a TCPCL 1633 entity receives a message which is inappropriate for the current 1634 session state (e.g., a SESS_INIT after the session has already been 1635 established or an XFER_ACK message with an unknown Transfer ID), the 1636 entity SHALL send a MSG_REJECT message with a Reason Code of "Message 1637 Unexpected". 1639 The format of a MSG_REJECT message is as follows in Figure 21. 1641 +-----------------------------+ 1642 | Message Header | 1643 +-----------------------------+ 1644 | Reason Code (U8) | 1645 +-----------------------------+ 1646 | Rejected Message Header | 1647 +-----------------------------+ 1649 Figure 21: Format of MSG_REJECT Messages 1651 The fields of the MSG_REJECT message are: 1653 Reason Code: A one-octet refusal reason code interpreted according 1654 to the descriptions in Table 4. 1656 Rejected Message Header: The Rejected Message Header is a copy of 1657 the Message Header to which the MSG_REJECT message is sent as a 1658 response. 1660 +-------------+------+----------------------------------------------+ 1661 | Name | Code | Description | 1662 +-------------+------+----------------------------------------------+ 1663 | Message | 0x01 | A message was received with a | 1664 | Type | | Message Type code unknown to the TCPCL node. | 1665 | Unknown | | | 1666 | | | | 1667 | Message | 0x02 | A message was received but the | 1668 | Unsupported | | TCPCL entity cannot comply with the message | 1669 | | | contents. | 1670 | | | | 1671 | Message | 0x03 | A message was received while the | 1672 | Unexpected | | session is in a state in which the message | 1673 | | | is not expected. | 1674 +-------------+------+----------------------------------------------+ 1676 Table 4: MSG_REJECT Reason Codes 1678 5.2. Bundle Transfer 1680 All of the messages in this section are directly associated with 1681 transferring a bundle between TCPCL entities. 1683 A single TCPCL transfer results in a bundle (handled by the 1684 convergence layer as opaque data) being exchanged from one node to 1685 the other. In TCPCL a transfer is accomplished by dividing a single 1686 bundle up into "segments" based on the receiving-side Segment MRU 1687 (see Section 4.2). The choice of the length to use for segments is 1688 an implementation matter, but each segment MUST NOT be larger than 1689 the receiving node's maximum receive unit (MRU) (see the field 1690 Segment MRU of Section 4.2). The first segment for a bundle is 1691 indicated by the 'START' flag and the last segment is indicated by 1692 the 'END' flag. 1694 A single transfer (and by extension a single segment) SHALL NOT 1695 contain data of more than a single bundle. This requirement is 1696 imposed on the agent using the TCPCL rather than TCPCL itself. 1698 If multiple bundles are transmitted on a single TCPCL connection, 1699 they MUST be transmitted consecutively without interleaving of 1700 segments from multiple bundles. 1702 5.2.1. Bundle Transfer ID 1704 Each of the bundle transfer messages contains a Transfer ID which is 1705 used to correlate messages (from both sides of a transfer) for each 1706 bundle. A Transfer ID does not attempt to address uniqueness of the 1707 bundle data itself and has no relation to concepts such as bundle 1708 fragmentation. Each invocation of TCPCL by the bundle protocol 1709 agent, requesting transmission of a bundle (fragmentary or 1710 otherwise), results in the initiation of a single TCPCL transfer. 1711 Each transfer entails the sending of a sequence of some number of 1712 XFER_SEGMENT and XFER_ACK messages; all are correlated by the same 1713 Transfer ID. The sending entity originates a transfer ID and the 1714 receiving entity uses that same Transfer ID in acknowledgements. 1716 Transfer IDs from each node SHALL be unique within a single TCPCL 1717 session. Upon exhaustion of the entire 64-bit Transfer ID space, the 1718 sending node SHALL terminate the session with SESS_TERM reason code 1719 "Resource Exhaustion". For bidirectional bundle transfers, a TCPCL 1720 node SHOULD NOT rely on any relation between Transfer IDs originating 1721 from each side of the TCPCL session. 1723 Although there is not a strict requirement for Transfer ID initial 1724 values or ordering (see Section 8.11), in the absence of any other 1725 mechanism for generating Transfer IDs an entity SHALL use the 1726 following algorithm: The initial Transfer ID from each node is zero 1727 and subsequent Transfer ID values are incremented from the prior 1728 Transfer ID value by one. 1730 5.2.2. Data Transmission (XFER_SEGMENT) 1732 Each bundle is transmitted in one or more data segments. The format 1733 of a XFER_SEGMENT message follows in Figure 22. 1735 +------------------------------+ 1736 | Message Header | 1737 +------------------------------+ 1738 | Message Flags (U8) | 1739 +------------------------------+ 1740 | Transfer ID (U64) | 1741 +------------------------------+ 1742 | Transfer Extension | 1743 | Items Length (U32) | 1744 | (only for START segment) | 1745 +------------------------------+ 1746 | Transfer Extension | 1747 | Items (var.) | 1748 | (only for START segment) | 1749 +------------------------------+ 1750 | Data length (U64) | 1751 +------------------------------+ 1752 | Data contents (octet string) | 1753 +------------------------------+ 1755 Figure 22: Format of XFER_SEGMENT Messages 1757 The fields of the XFER_SEGMENT message are: 1759 Message Flags: A one-octet field of single-bit flags, interpreted 1760 according to the descriptions in Table 5. All reserved header 1761 flag bits SHALL be set to 0 by the sender. All reserved header 1762 flag bits SHALL be ignored by the receiver. 1764 Transfer ID: A 64-bit unsigned integer identifying the transfer 1765 being made. 1767 Transfer Extension Length and Transfer Extension Items: 1768 Together these fields represent protocol extension data for this 1769 specification. The Transfer Extension Length and Transfer 1770 Extension Item fields SHALL only be present when the 'START' flag 1771 is set to 1 on the message. The Transfer Extension Length is the 1772 total number of octets to follow which are used to encode the 1773 Transfer Extension Item list. The encoding of each Transfer 1774 Extension Item is within a consistent data container as described 1775 in Section 5.2.5. The full set of transfer extension items apply 1776 only to the associated single transfer. The order and 1777 multiplicity of these transfer extension items is significant, as 1778 defined in the associated type specification(s). 1780 Data length: A 64-bit unsigned integer indicating the number of 1781 octets in the Data contents to follow. 1783 Data contents: The variable-length data payload of the message. 1785 +----------+--------+-----------------------------------------------+ 1786 | Name | Code | Description | 1787 +----------+--------+-----------------------------------------------+ 1788 | END | 0x01 | If bit is set, indicates that this is the | 1789 | | | last segment of the transfer. | 1790 | | | | 1791 | START | 0x02 | If bit is set, indicates that this is the | 1792 | | | first segment of the transfer. | 1793 | | | | 1794 | Reserved | others | 1795 +----------+--------+-----------------------------------------------+ 1797 Table 5: XFER_SEGMENT Flags 1799 The flags portion of the message contains two flag values in the two 1800 low-order bits, denoted 'START' and 'END' in Table 5. The 'START' 1801 flag SHALL be set to 1 when transmitting the first segment of a 1802 transfer. The 'END' flag SHALL be set to 1 when transmitting the 1803 last segment of a transfer. In the case where an entire transfer is 1804 accomplished in a single segment, both the 'START' and 'END' flags 1805 SHALL be set to 1. 1807 Once a transfer of a bundle has commenced, the entity MUST only send 1808 segments containing sequential portions of that bundle until it sends 1809 a segment with the 'END' flag set to 1. No interleaving of multiple 1810 transfers from the same node is possible within a single TCPCL 1811 session. Simultaneous transfers between two entities MAY be achieved 1812 using multiple TCPCL sessions. 1814 5.2.3. Data Acknowledgments (XFER_ACK) 1816 Although the TCP transport provides reliable transfer of data between 1817 transport peers, the typical BSD sockets interface provides no means 1818 to inform a sending application of when the receiving application has 1819 processed some amount of transmitted data. Thus, after transmitting 1820 some data, the TCPCL needs an additional mechanism to determine 1821 whether the receiving agent has successfully received and fully 1822 processed the segment. To this end, the TCPCL protocol provides 1823 feedback messaging whereby a receiving node transmits acknowledgments 1824 of reception of data segments. 1826 The format of an XFER_ACK message follows in Figure 23. 1828 +-----------------------------+ 1829 | Message Header | 1830 +-----------------------------+ 1831 | Message Flags (U8) | 1832 +-----------------------------+ 1833 | Transfer ID (U64) | 1834 +-----------------------------+ 1835 | Acknowledged length (U64) | 1836 +-----------------------------+ 1838 Figure 23: Format of XFER_ACK Messages 1840 The fields of the XFER_ACK message are: 1842 Message Flags: A one-octet field of single-bit flags, interpreted 1843 according to the descriptions in Table 5. All reserved header 1844 flag bits SHALL be set to 0 by the sender. All reserved header 1845 flag bits SHALL be ignored by the receiver. 1847 Transfer ID: A 64-bit unsigned integer identifying the transfer 1848 being acknowledged. 1850 Acknowledged length: A 64-bit unsigned integer indicating the total 1851 number of octets in the transfer which are being acknowledged. 1853 A receiving TCPCL node SHALL send an XFER_ACK message in response to 1854 each received XFER_SEGMENT message after the segment has been fully 1855 processed. The flags portion of the XFER_ACK header SHALL be set to 1856 match the corresponding XFER_SEGMENT message being acknowledged 1857 (including flags not decodable to the entity). The acknowledged 1858 length of each XFER_ACK contains the sum of the data length fields of 1859 all XFER_SEGMENT messages received so far in the course of the 1860 indicated transfer. The sending node SHOULD transmit multiple 1861 XFER_SEGMENT messages without waiting for the corresponding XFER_ACK 1862 responses. This enables pipelining of messages on a transfer stream. 1864 For example, suppose the sending node transmits four segments of 1865 bundle data with lengths 100, 200, 500, and 1000, respectively. 1866 After receiving the first segment, the entity sends an acknowledgment 1867 of length 100. After the second segment is received, the entity 1868 sends an acknowledgment of length 300. The third and fourth 1869 acknowledgments are of length 800 and 1800, respectively. 1871 5.2.4. Transfer Refusal (XFER_REFUSE) 1873 The TCPCL supports a mechanism by which a receiving node can indicate 1874 to the sender that it does not want to receive the corresponding 1875 bundle. To do so, upon receiving an XFER_SEGMENT message, the entity 1876 MAY transmit a XFER_REFUSE message. As data segments and 1877 acknowledgments can cross on the wire, the bundle that is being 1878 refused SHALL be identified by the Transfer ID of the refusal. 1880 There is no required relation between the Transfer MRU of a TCPCL 1881 node (which is supposed to represent a firm limitation of what the 1882 node will accept) and sending of a XFER_REFUSE message. A 1883 XFER_REFUSE can be used in cases where the agent's bundle storage is 1884 temporarily depleted or somehow constrained. A XFER_REFUSE can also 1885 be used after the bundle header or any bundle data is inspected by an 1886 agent and determined to be unacceptable. 1888 A transfer receiver MAY send an XFER_REFUSE message as soon as it 1889 receives any XFER_SEGMENT message. The transfer sender MUST be 1890 prepared for this and MUST associate the refusal with the correct 1891 bundle via the Transfer ID fields. 1893 The TCPCL itself does not have any required behavior to respond to an 1894 XFER_REFUSE based on its Reason Code; the refusal is passed up as an 1895 indication to the BP agent that the transfer has been refused. If a 1896 transfer refusal has a Reason Code which is not decodable to the BP 1897 agent, the agent SHOULD treat the refusal as having an Unknown 1898 reason. 1900 The format of the XFER_REFUSE message is as follows in Figure 24. 1902 +-----------------------------+ 1903 | Message Header | 1904 +-----------------------------+ 1905 | Reason Code (U8) | 1906 +-----------------------------+ 1907 | Transfer ID (U64) | 1908 +-----------------------------+ 1910 Figure 24: Format of XFER_REFUSE Messages 1912 The fields of the XFER_REFUSE message are: 1914 Reason Code: A one-octet refusal reason code interpreted according 1915 to the descriptions in Table 6. 1917 Transfer ID: A 64-bit unsigned integer identifying the transfer 1918 being refused. 1920 +------------+------+-----------------------------------------------+ 1921 | Name | Code | Description | 1922 +------------+------+-----------------------------------------------+ 1923 | Unknown | 0x00 | Reason for refusal is unknown or not | 1924 | | | specified. | 1925 | | | | 1926 | Completed | 0x01 | The receiver already has the complete bundle. | 1927 | | | The sender MAY consider the bundle as | 1928 | | | completely received. | 1929 | | | | 1930 | No | 0x02 | The receiver's resources are exhausted. The | 1931 | Resources | | sender SHOULD apply reactive bundle | 1932 | | | fragmentation before retrying. | 1933 | | | | 1934 | Retransmit | 0x03 | The receiver has encountered a problem that | 1935 | | | requires the bundle to be retransmitted in | 1936 | | | its entirety. | 1937 | | | | 1938 | Not | 0x04 | Some issue with the bundle data or the | 1939 | Acceptable | | transfer extension data was encountered. The | 1940 | | | sender SHOULD NOT retry the same bundle with | 1941 | | | the same extensions. | 1942 | | | | 1943 | Extension | 0x05 | A failure processing the Transfer Extension | 1944 | Failure | | Items has occurred. | 1945 +------------+------+-----------------------------------------------+ 1947 Table 6: XFER_REFUSE Reason Codes 1949 The receiver MUST, for each transfer preceding the one to be refused, 1950 have either acknowledged all XFER_SEGMENT messages or refused the 1951 bundle transfer. 1953 The bundle transfer refusal MAY be sent before an entire data segment 1954 is received. If a sender receives a XFER_REFUSE message, the sender 1955 MUST complete the transmission of any partially sent XFER_SEGMENT 1956 message. There is no way to interrupt an individual TCPCL message 1957 partway through sending it. The sender MUST NOT commence 1958 transmission of any further segments of the refused bundle 1959 subsequently. Note, however, that this requirement does not ensure 1960 that an entity will not receive another XFER_SEGMENT for the same 1961 bundle after transmitting a XFER_REFUSE message since messages can 1962 cross on the wire; if this happens, subsequent segments of the bundle 1963 SHALL also be refused with a XFER_REFUSE message. 1965 Note: If a bundle transmission is aborted in this way, the receiver 1966 does not receive a segment with the 'END' flag set to 1 for the 1967 aborted bundle. The beginning of the next bundle is identified by 1968 the 'START' flag set to 1, indicating the start of a new transfer, 1969 and with a distinct Transfer ID value. 1971 5.2.5. Transfer Extension Items 1973 Each of the Transfer Extension Items SHALL be encoded in an identical 1974 Type-Length-Value (TLV) container form as indicated in Figure 25. 1976 The fields of the Transfer Extension Item are: 1978 Item Flags: A one-octet field containing generic bit flags about the 1979 Item, which are listed in Table 7. All reserved header flag bits 1980 SHALL be set to 0 by the sender. All reserved header flag bits 1981 SHALL be ignored by the receiver. If a TCPCL node receives a 1982 Transfer Extension Item with an unknown Item Type and the CRITICAL 1983 flag is 1, the entity SHALL refuse the transfer with an 1984 XFER_REFUSE reason code of "Extension Failure". If the CRITICAL 1985 flag is 0, an entity SHALL skip over and ignore any item with an 1986 unknown Item Type. 1988 Item Type: A 16-bit unsigned integer field containing the type of 1989 the extension item. This specification creates an IANA registry 1990 for such codes (see Section 9.4). 1992 Item Length: A 16-bit unsigned integer field containing the number 1993 of Item Value octets to follow. 1995 Item Value: A variable-length data field which is interpreted 1996 according to the associated Item Type. This specification places 1997 no restrictions on an extension's use of available Item Value 1998 data. Extension specifications SHOULD avoid the use of large data 1999 lengths, as the associated transfer cannot begin until the full 2000 extension data is sent. 2002 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 2003 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 2004 +---------------+---------------+---------------+---------------+ 2005 | Item Flags | Item Type | Item Length...| 2006 +---------------+---------------+---------------+---------------+ 2007 | length contd. | Item Value... | 2008 +---------------+---------------+---------------+---------------+ 2010 Figure 25: Transfer Extension Item Format 2012 +----------+--------+-----------------------------------------------+ 2013 | Name | Code | Description | 2014 +----------+--------+-----------------------------------------------+ 2015 | CRITICAL | 0x01 | If bit is set, indicates that the receiving | 2016 | | | peer must handle the extension item. | 2017 | | | | 2018 | Reserved | others | 2019 +----------+--------+-----------------------------------------------+ 2021 Table 7: Transfer Extension Item Flags 2023 5.2.5.1. Transfer Length Extension 2025 The purpose of the Transfer Length extension is to allow entities to 2026 preemptively refuse bundles that would exceed their resources or to 2027 prepare storage on the receiving node for the upcoming bundle data. 2029 Multiple Transfer Length extension items SHALL NOT occur within the 2030 same transfer. The lack of a Transfer Length extension item in any 2031 transfer SHALL NOT imply anything about the potential length of the 2032 transfer. The Transfer Length extension SHALL be assigned transfer 2033 extension type ID 0x0001. 2035 If a transfer occupies exactly one segment (i.e., both START and END 2036 flags are 1) the Transfer Length extension SHOULD NOT be present. 2037 The extension does not provide any additional information for single- 2038 segment transfers. 2040 The format of the Transfer Length data is as follows in Figure 26. 2042 +----------------------+ 2043 | Total Length (U64) | 2044 +----------------------+ 2046 Figure 26: Format of Transfer Length data 2048 The fields of the Transfer Length extension are: 2050 Total Length: A 64-bit unsigned integer indicating the size of the 2051 data-to-be-transferred. The Total Length field SHALL be treated 2052 as authoritative by the receiver. If, for whatever reason, the 2053 actual total length of bundle data received differs from the value 2054 indicated by the Total Length value, the receiver SHALL treat the 2055 transmitted data as invalid and send an XFER_REFUSE with a Reason 2056 Code of "Not Acceptable". 2058 6. Session Termination 2060 This section describes the procedures for terminating a TCPCL 2061 session. The purpose of terminating a session is to allow transfers 2062 to complete before the session is closed but not allow any new 2063 transfers to start. A session state change is necessary for this to 2064 happen because transfers can be in-progress in either direction 2065 (transfer stream) within a session. Waiting for a transfer to 2066 complete in one direction does not control or influence the 2067 possibility of a transfer in the other direction. Either peer of a 2068 session can terminate an established session at any time. 2070 6.1. Session Termination Message (SESS_TERM) 2072 To cleanly terminate a session, a SESS_TERM message SHALL be 2073 transmitted by either node at any point following complete 2074 transmission of any other message. When sent to initiate a 2075 termination, the REPLY flag of a SESS_TERM message SHALL be 0. Upon 2076 receiving a SESS_TERM message after not sending a SESS_TERM message 2077 in the same session, an entity SHALL send an acknowledging SESS_TERM 2078 message. When sent to acknowledge a termination, a SESS_TERM message 2079 SHALL have identical data content from the message being acknowledged 2080 except for the REPLY flag, which is set to 1 to indicate 2081 acknowledgement. 2083 Once a SESS_TERM message is sent the state of that TCPCL session 2084 changes to Ending. While the session is in the Ending state, an 2085 entity MAY finish an in-progress transfer in either direction. While 2086 the session is in the Ending state, an entity SHALL NOT begin any new 2087 outgoing transfer for the remainder of the session. While the 2088 session is in the Ending state, an entity SHALL NOT accept any new 2089 incoming transfer for the remainder of the session. 2091 Instead of following a clean termination sequence, after transmitting 2092 a SESS_TERM message an entity MAY immediately close the associated 2093 TCP connection. When performing an unclean termination, a receiving 2094 node SHOULD acknowledge all received XFER_SEGMENTs with an XFER_ACK 2095 before closing the TCP connection. Not acknowledging received 2096 segments can result in unnecessary bundle or bundle fragment 2097 retransmission. When performing an unclean termination, a 2098 transmitting node SHALL treat either sending or receiving a SESS_TERM 2099 message (i.e., before the final acknowledgment) as a failure of the 2100 transfer. Any delay between request to close the TCP connection and 2101 actual closing of the connection (a "half-closed" state) MAY be 2102 ignored by the TCPCL entity. 2104 The TCPCL itself does not have any required behavior to respond to an 2105 SESS_TERM based on its Reason Code; the termination is passed up as 2106 an indication to the BP agent that the session state has changed. If 2107 a termination has a Reason Code which is not decodable to the BP 2108 agent, the agent SHOULD treat the termination as having an Unknown 2109 reason. 2111 The format of the SESS_TERM message is as follows in Figure 27. 2113 +-----------------------------+ 2114 | Message Header | 2115 +-----------------------------+ 2116 | Message Flags (U8) | 2117 +-----------------------------+ 2118 | Reason Code (U8) | 2119 +-----------------------------+ 2121 Figure 27: Format of SESS_TERM Messages 2123 The fields of the SESS_TERM message are: 2125 Message Flags: A one-octet field of single-bit flags, interpreted 2126 according to the descriptions in Table 8. All reserved header 2127 flag bits SHALL be set to 0 by the sender. All reserved header 2128 flag bits SHALL be ignored by the receiver. 2130 Reason Code: A one-octet refusal reason code interpreted according 2131 to the descriptions in Table 9. 2133 +----------+--------+-----------------------------------------------+ 2134 | Name | Code | Description | 2135 +----------+--------+-----------------------------------------------+ 2136 | REPLY | 0x01 | If bit is set, indicates that this message is | 2137 | | | an acknowledgement of an earlier SESS_TERM | 2138 | | | message. | 2139 | | | | 2140 | Reserved | others | 2141 +----------+--------+-----------------------------------------------+ 2143 Table 8: SESS_TERM Flags 2145 +--------------+------+---------------------------------------------+ 2146 | Name | Code | Description | 2147 +--------------+------+---------------------------------------------+ 2148 | Unknown | 0x00 | A termination reason is not available. | 2149 | | | | 2150 | Idle timeout | 0x01 | The session is being closed due to | 2151 | | | idleness. | 2152 | | | | 2153 | Version | 0x02 | The node cannot conform to the specified | 2154 | mismatch | | TCPCL protocol version. | 2155 | | | | 2156 | Busy | 0x03 | The node is too busy to handle the current | 2157 | | | session. | 2158 | | | | 2159 | Contact | 0x04 | The node cannot interpret or negotiate a | 2160 | Failure | | Contact Header or SESS_INIT option. | 2161 | | | | 2162 | Resource | 0x05 | The node has run into some resource limit | 2163 | Exhaustion | | and cannot continue the session. | 2164 +--------------+------+---------------------------------------------+ 2166 Table 9: SESS_TERM Reason Codes 2168 A session termination MAY occur immediately after transmission of a 2169 Contact Header (and prior to any further message transmit). This 2170 can, for example, be used to notify that the entity is currently not 2171 able or willing to communicate. However, an entity MUST always send 2172 the Contact Header to its peer before sending a SESS_TERM message. 2174 If reception of the Contact Header itself somehow fails (e.g., an 2175 invalid "magic string" is received), an entity SHALL close the TCP 2176 connection without sending a SESS_TERM message. If the content of 2177 the Session Extension Items data disagrees with the Session Extension 2178 Length (i.e., the last Item claims to use more octets than are 2179 present in the Session Extension Length), the reception of the 2180 SESS_INIT is considered to have failed. 2182 If a session is to be terminated before a protocol message has 2183 completed being sent, then the entity MUST NOT transmit the SESS_TERM 2184 message but still SHALL close the TCP connection. Each TCPCL message 2185 is contiguous in the octet stream and has no ability to be cut short 2186 and/or preempted by an other message. This is particularly important 2187 when large segment sizes are being transmitted; either entire 2188 XFER_SEGMENT is sent before a SESS_TERM message or the connection is 2189 simply terminated mid-XFER_SEGMENT. 2191 6.2. Idle Session Shutdown 2193 The protocol includes a provision for clean termination of idle 2194 sessions. Determining the length of time to wait before ending idle 2195 sessions, if they are to be closed at all, is an implementation and 2196 configuration matter. 2198 If there is a configured time to close idle links and if no TCPCL 2199 messages (other than KEEPALIVE messages) has been received for at 2200 least that amount of time, then either node MAY terminate the session 2201 by transmitting a SESS_TERM message indicating the reason code of 2202 "Idle timeout" (as described in Table 9). 2204 7. Implementation Status 2206 [NOTE to the RFC Editor: please remove this section before 2207 publication, as well as the reference to [RFC7942] and 2208 [github-dtn-bpbis-tcpcl].] 2210 This section records the status of known implementations of the 2211 protocol defined by this specification at the time of posting of this 2212 Internet-Draft, and is based on a proposal described in [RFC7942]. 2213 The description of implementations in this section is intended to 2214 assist the IETF in its decision processes in progressing drafts to 2215 RFCs. Please note that the listing of any individual implementation 2216 here does not imply endorsement by the IETF. Furthermore, no effort 2217 has been spent to verify the information presented here that was 2218 supplied by IETF contributors. This is not intended as, and must not 2219 be construed to be, a catalog of available implementations or their 2220 features. Readers are advised to note that other implementations can 2221 exist. 2223 An example implementation of the this draft of TCPCLv4 has been 2224 created as a GitHub project [github-dtn-bpbis-tcpcl] and is intended 2225 to use as a proof-of-concept and as a possible source of 2226 interoperability testing. This example implementation uses D-Bus as 2227 the CL-BP Agent interface, so it only runs on hosts which provide the 2228 Python "dbus" library. 2230 8. Security Considerations 2232 This section separates security considerations into threat categories 2233 based on guidance of BCP 72 [RFC3552]. 2235 8.1. Threat: Passive Leak of Node Data 2237 When used without TLS security, the TCPCL exposes the Node ID and 2238 other configuration data to passive eavesdroppers. This occurs even 2239 when no transfers occur within a TCPCL session. This can be avoided 2240 by always using TLS, even if authentication is not available (see 2241 Section 8.10). 2243 8.2. Threat: Passive Leak of Bundle Data 2245 TCPCL can be used to provide point-to-point transport security, but 2246 does not provide security of data-at-rest and does not guarantee end- 2247 to-end bundle security. The bundle security mechanisms defined in 2248 [I-D.ietf-dtn-bpsec] are to be used instead. 2250 When used without TLS security, the TCPCL exposes all bundle data to 2251 passive eavesdroppers. This can be avoided by always using TLS, even 2252 if authentication is not available (see Section 8.10). 2254 8.3. Threat: TCPCL Version Downgrade 2256 When a TCPCL entity supports multiple versions of the protocol it is 2257 possible for a malicious or misconfigured peer to use an older 2258 version of TCPCL which does not support transport security. A man- 2259 in-the-middle attacker can also manipulate a Contact Header to 2260 present a lower protocol version than desired. 2262 It is up to security policies within each TCPCL node to ensure that 2263 the negotiated TCPCL version meets transport security requirements. 2265 8.4. Threat: Transport Security Stripping 2267 When security policy allows non-TLS sessions, TCPCL does not protect 2268 against active network attackers. It is possible for a man-in-the- 2269 middle attacker to set the CAN_TLS flag to 0 on either side of the 2270 Contact Header exchange. This leads to the "SSL Stripping" attack 2271 described in [RFC7457]. 2273 The purpose of the CAN_TLS flag is to allow the use of TCPCL on 2274 entities which simply do not have a TLS implementation available. 2275 When TLS is available on an entity, it is strongly encouraged that 2276 the security policy disallow non-TLS sessions. This requires that 2277 the TLS handshake occurs, regardless of the policy-driven parameters 2278 of the handshake and policy-driven handling of the handshake outcome. 2280 The negotiated use of TLS is identical behavior to STARTTLS use in 2281 [RFC2595] and [RFC4511]. 2283 8.5. Threat: Weak TLS Configurations 2285 Even when using TLS to secure the TCPCL session, the actual 2286 ciphersuite negotiated between the TLS peers can be insecure. 2287 Recommendations for ciphersuite use are included in BCP 195 2288 [RFC7525]. It is up to security policies within each TCPCL node to 2289 ensure that the negotiated TLS ciphersuite meets transport security 2290 requirements. 2292 8.6. Threat: Certificate Validation Vulnerabilities 2294 Even when TLS itself is operating properly an attacker can attempt to 2295 exploit vulnerabilities within certificate check algorithms or 2296 configuration to establish a secure TCPCL session using an invalid 2297 certificate. A BP agent treats the peer Node ID within a TCPCL 2298 session as authoritative and an invalid certificate exploit could 2299 lead to bundle data leaking and/or denial of service to the Node ID 2300 being impersonated. There are many reasons, described in [RFC5280], 2301 why a certificate can fail to validate, including using the 2302 certificate outside of its valid time interval, using purposes for 2303 which it was not authorized, or using it after it has been revoked by 2304 its CA. Validating a certificate is a complex task and can require 2305 network connectivity outside of the primary TCPCL network path(s) if 2306 a mechanism such as the Online Certificate Status Protocol (OCSP) is 2307 used by the CA. The configuration and use of particular certificate 2308 validation methods are outside of the scope of this document. 2310 8.7. Threat: Symmetric Key Limits 2312 Even with a secure block cipher and securely-established session 2313 keys, there are limits to the amount of plaintext which can be safely 2314 encrypted with a given set of keys as described in [AEAD-LIMITS]. 2315 When permitted by the negotiated TLS version (see [RFC8446]), it is 2316 advisable to take advantage of session key updates to avoid those 2317 limits. When key updates are not possible, renegotiation of the TLS 2318 connection or establishing new TCPCL/TLS session are alternatives to 2319 limit session key use. 2321 8.8. Threat: BP Node Impersonation 2323 The certificates exchanged by TLS enable authentication of peer host 2324 name and Node ID, but it is possible that a peer either not provide a 2325 valid certificate or that the certificate does not validate either 2326 the host name or Node ID of the peer. Having a CA-validated 2327 certificate does not alone guarantee the identity of the network host 2328 or BP node from which the certificate is provided; additional 2329 validation procedures in Section 4.4.2 bind the host name or node ID 2330 based on the contents of the certificate. 2332 The host name validation is a weaker form of authentication, because 2333 even if a peer is operating on an authenticated network host name it 2334 can provide an invalid Node ID and cause bundles to be "leaked" to an 2335 invalid node. Especially in DTN environments, network names and 2336 addresses of nodes can be time-variable so binding a certificate to a 2337 Node ID is a more stable identity. Trusting an authenticated host 2338 name can be feasible on a network secured by a private CA but is not 2339 advisable on the Internet when using a variety of public CAs. 2341 Node ID validation ensures that the peer to which a bundle is 2342 transferred is in fact the node which the BP Agent expects it to be. 2343 It is a reasonable policy to skip host name validation if 2344 certificates can be guaranteed to validate the peer's Node ID. In 2345 circumstances where certificates can only be issued to network host 2346 names, Node ID validation is not possible but it could be reasonable 2347 to assume that a trusted host is not going to present an invalid Node 2348 ID. Determining of when a host name authentication can be trusted to 2349 validate a Node ID is also a policy matter outside the scope of this 2350 document. 2352 8.9. Threat: Denial of Service 2354 The behaviors described in this section all amount to a potential 2355 denial-of-service to a TCPCL entity. The denial-of-service could be 2356 limited to an individual TCPCL session, could affect other well- 2357 behaving sessions on an entity, or could affect all sessions on a 2358 host. 2360 A malicious entity can continually establish TCPCL sessions and delay 2361 sending of protocol-required data to trigger timeouts. The victim 2362 entity can block TCP connections from network peers which are thought 2363 to be incorrectly behaving within TCPCL. 2365 An entity can send a large amount of data over a TCPCL session, 2366 requiring the receiving entity to handle the data. The victim entity 2367 can attempt to stop the flood of data by sending an XFER_REFUSE 2368 message, or forcibly terminate the session. 2370 There is the possibility of a "data dribble" attack in which an 2371 entity presents a very small Segment MRU which causes transfers to be 2372 split among an large number of very small segments and causes the 2373 segmentation overhead to overwhelm the actual bundle data segments. 2374 Similarly, an entity can present a very small Transfer MRU which will 2375 cause resources to be wasted on establishment and upkeep of a TCPCL 2376 session over which a bundle could never be transferred. The victim 2377 entity can terminate the session during the negotiation of 2378 Section 4.7 if the MRUs are unacceptable. 2380 The keepalive mechanism can be abused to waste throughput within a 2381 network link which would otherwise be usable for bundle 2382 transmissions. Due to the quantization of the Keepalive Interval 2383 parameter the smallest Session Keepalive is one second, which should 2384 be long enough to not flood the link. The victim entity can 2385 terminate the session during the negotiation of Section 4.7 if the 2386 Keepalive Interval is unacceptable. 2388 Finally, an attacker or a misconfigured entity can cause issues at 2389 the TCP connection which will cause unnecessary TCP retransmissions 2390 or connection resets, effectively denying the use of the overlying 2391 TCPCL session. 2393 8.10. Alternate Uses of TLS 2395 This specification makes use of X.509 PKI certificate validation and 2396 authentication within TLS. There are alternate uses of TLS which are 2397 not necessarily incompatible with the security goals of this 2398 specification, but are outside of the scope of this document. The 2399 following subsections give examples of alternate TLS uses. 2401 8.10.1. TLS Without Authentication 2403 In environments where PKI is available but there are restrictions on 2404 the issuance of certificates (including the contents of 2405 certificates), it may be possible to make use of TLS in a way which 2406 authenticates only the passive entity of a TCPCL session or which 2407 does not authenticate either entity. Using TLS in a way which does 2408 not authenticate both peer entities of each TCPCL session is outside 2409 of the scope of this document but does have similar properties to the 2410 opportunistic security model of [RFC7435]. 2412 8.10.2. Non-Certificate TLS Use 2414 In environments where PKI is unavailable, alternate uses of TLS which 2415 do not require certificates such as pre-shared key (PSK) 2416 authentication [RFC5489] and the use of raw public keys [RFC7250] are 2417 available and can be used to ensure confidentiality within TCPCL. 2418 Using non-PKI node authentication methods is outside of the scope of 2419 this document. 2421 8.11. Predictability of Transfer IDs 2423 The only requirement on Transfer IDs is that they be unique with each 2424 session from the sending peer only. The trivial algorithm of the 2425 first transfer starting at zero and later transfers incrementing by 2426 one causes absolutely predictable Transfer IDs. Even when a TCPCL 2427 session is not TLS secured and there is a man-in-the-middle attacker 2428 causing denial of service with XFER_REFUSE messages, it is not 2429 possible to preemptively refuse a transfer so there is no benefit in 2430 having unpredictable Transfer IDs within a session. 2432 9. IANA Considerations 2434 Registration procedures referred to in this section are defined in 2435 [RFC8126]. 2437 Some of the registries have been defined as version specific to 2438 TCPCLv4, and imports some or all codepoints from TCPCLv3. This was 2439 done to disambiguate the use of these codepoints between TCPCLv3 and 2440 TCPCLv4 while preserving the semantics of some of the codepoints. 2442 9.1. Port Number 2444 Within the port registry of [IANA-PORTS], TCP port number 4556 has 2445 been previously assigned as the default port for the TCP convergence 2446 layer in [RFC7242]. This assignment is unchanged by TCPCL version 4, 2447 but the assignment reference is updated to this specification. Each 2448 TCPCL entity identifies its TCPCL protocol version in its initial 2449 contact (see Section 9.2), so there is no ambiguity about what 2450 protocol is being used. The related assignments for UDP and DCCP 2451 port 4556 (both registered by [RFC7122]) are unchanged. 2453 +------------------------+----------------------------+ 2454 | Parameter | Value | 2455 +------------------------+----------------------------+ 2456 | Service Name: | dtn-bundle | 2457 | | | 2458 | Transport Protocol(s): | TCP | 2459 | | | 2460 | Assignee: | IESG | 2461 | | | 2462 | Contact: | IESG | 2463 | | | 2464 | Description: | DTN Bundle TCP CL Protocol | 2465 | | | 2466 | Reference: | This specification. | 2467 | | | 2468 | Port Number: | 4556 | 2469 +------------------------+----------------------------+ 2471 9.2. Protocol Versions 2473 IANA has created, under the "Bundle Protocol" registry [IANA-BUNDLE], 2474 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2475 Numbers". The version number table is updated to include this 2476 specification. The registration procedure is RFC Required. 2478 +-------+-------------+-----------------------------------+ 2479 | Value | Description | Reference | 2480 +-------+-------------+-----------------------------------+ 2481 | 0 | Reserved | [RFC7242] | 2482 | | | | 2483 | 1 | Reserved | [RFC7242] | 2484 | | | | 2485 | 2 | Reserved | [RFC7242] | 2486 | | | | 2487 | 3 | TCPCL | [RFC7242] | 2488 | | | | 2489 | 4 | TCPCLv4 | This specification. | 2490 | | | | 2491 | 5-255 | Unassigned | 2492 +-------+-------------+-----------------------------------+ 2494 9.3. Session Extension Types 2496 EDITOR NOTE: sub-registry to-be-created upon publication of this 2497 specification. 2499 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 2500 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2501 4 Session Extension Types" and initialize it with the contents of 2502 Table 10. The registration procedure is Expert Review within the 2503 lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are 2504 reserved for use on private networks for functions not published to 2505 the IANA. 2507 Specifications of new session extension types need to define the 2508 encoding of the Item Value data as well as any meaning or restriction 2509 on the number of or order of instances of the type within an 2510 extension item list. Specifications need to define how the extension 2511 functions when no instance of the new extension type is received 2512 during session negotiation. 2514 Expert(s) are encouraged to be biased towards approving registrations 2515 unless they are abusive, frivolous, or actively harmful (not merely 2516 aesthetically displeasing, or architecturally dubious). 2518 +----------------+--------------------------+ 2519 | Code | Session Extension Type | 2520 +----------------+--------------------------+ 2521 | 0x0000 | Reserved | 2522 | | | 2523 | 0x0001--0x7FFF | Unassigned | 2524 | | | 2525 | 0x8000--0xFFFF | Private/Experimental Use | 2526 +----------------+--------------------------+ 2528 Table 10: Session Extension Type Codes 2530 9.4. Transfer Extension Types 2532 EDITOR NOTE: sub-registry to-be-created upon publication of this 2533 specification. 2535 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 2536 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2537 4 Transfer Extension Types" and initialize it with the contents of 2538 Table 11. The registration procedure is Expert Review within the 2539 lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are 2540 reserved for use on private networks for functions not published to 2541 the IANA. 2543 Specifications of new transfer extension types need to define the 2544 encoding of the Item Value data as well as any meaning or restriction 2545 on the number of or order of instances of the type within an 2546 extension item list. Specifications need to define how the extension 2547 functions when no instance of the new extension type is received in a 2548 transfer. 2550 Expert(s) are encouraged to be biased towards approving registrations 2551 unless they are abusive, frivolous, or actively harmful (not merely 2552 aesthetically displeasing, or architecturally dubious). 2554 +----------------+---------------------------+ 2555 | Code | Transfer Extension Type | 2556 +----------------+---------------------------+ 2557 | 0x0000 | Reserved | 2558 | | | 2559 | 0x0001 | Transfer Length Extension | 2560 | | | 2561 | 0x0002--0x7FFF | Unassigned | 2562 | | | 2563 | 0x8000--0xFFFF | Private/Experimental Use | 2564 +----------------+---------------------------+ 2566 Table 11: Transfer Extension Type Codes 2568 9.5. Message Types 2570 EDITOR NOTE: sub-registry to-be-created upon publication of this 2571 specification. 2573 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 2574 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2575 4 Message Types" and initialize it with the contents of Table 12. 2576 The registration procedure is RFC Required within the lower range 2577 0x01--0xEF. Values in the range 0xF0--0xFF are reserved for use on 2578 private networks for functions not published to the IANA. 2580 Specifications of new message types need to define the encoding of 2581 the message data as well as the purpose and relationship of the new 2582 message to existing session/transfer state within the baseline 2583 message sequencing. The use of new message types need to be 2584 negotiated between TCPCL entities within a session (using the session 2585 extension mechanism) so that the receiving entity can properly decode 2586 all message types used in the session. 2588 Expert(s) are encouraged to favor new session/transfer extension 2589 types over new message types. TCPCL messages are not self- 2590 delimiting, so care must be taken in introducing new message types. 2591 If an entity receives an unknown message type the only thing that can 2592 be done is to send a MSG_REJECT and close the TCP connection; not 2593 even a clean termination can be done at that point. 2595 +------------+--------------------------+ 2596 | Code | Message Type | 2597 +------------+--------------------------+ 2598 | 0x00 | Reserved | 2599 | | | 2600 | 0x01 | XFER_SEGMENT | 2601 | | | 2602 | 0x02 | XFER_ACK | 2603 | | | 2604 | 0x03 | XFER_REFUSE | 2605 | | | 2606 | 0x04 | KEEPALIVE | 2607 | | | 2608 | 0x05 | SESS_TERM | 2609 | | | 2610 | 0x06 | MSG_REJECT | 2611 | | | 2612 | 0x07 | SESS_INIT | 2613 | | | 2614 | 0x08--0xEF | Unassigned | 2615 | | | 2616 | 0xF0--0xFF | Private/Experimental Use | 2617 +------------+--------------------------+ 2619 Table 12: Message Type Codes 2621 9.6. XFER_REFUSE Reason Codes 2623 EDITOR NOTE: sub-registry to-be-created upon publication of this 2624 specification. 2626 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 2627 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2628 4 XFER_REFUSE Reason Codes" and initialize it with the contents of 2629 Table 13. The registration procedure is Specification Required 2630 within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF 2631 are reserved for use on private networks for functions not published 2632 to the IANA. 2634 Specifications of new XFER_REFUSE reason codes need to define the 2635 meaning of the reason and disambiguate it with pre-existing reasons. 2636 Each refusal reason needs to be usable by the receiving BP Agent to 2637 make retransmission or re-routing decisions. 2639 Expert(s) are encouraged to be biased towards approving registrations 2640 unless they are abusive, frivolous, or actively harmful (not merely 2641 aesthetically displeasing, or architecturally dubious). 2643 +------------+--------------------------+ 2644 | Code | Refusal Reason | 2645 +------------+--------------------------+ 2646 | 0x00 | Unknown | 2647 | | | 2648 | 0x01 | Completed | 2649 | | | 2650 | 0x02 | No Resources | 2651 | | | 2652 | 0x03 | Retransmit | 2653 | | | 2654 | 0x04 | Not Acceptable | 2655 | | | 2656 | 0x05 | Extension Failure | 2657 | | | 2658 | 0x06--0xEF | Unassigned | 2659 | | | 2660 | 0xF0--0xFF | Private/Experimental Use | 2661 +------------+--------------------------+ 2663 Table 13: XFER_REFUSE Reason Codes 2665 9.7. SESS_TERM Reason Codes 2667 EDITOR NOTE: sub-registry to-be-created upon publication of this 2668 specification. 2670 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 2671 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2672 4 SESS_TERM Reason Codes" and initialize it with the contents of 2673 Table 14. The registration procedure is Specification Required 2674 within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF 2675 are reserved for use on private networks for functions not published 2676 to the IANA. 2678 Specifications of new SESS_TERM reason codes need to define the 2679 meaning of the reason and disambiguate it with pre-existing reasons. 2680 Each termination reason needs to be usable by the receiving BP Agent 2681 to make re-connection decisions. 2683 Expert(s) are encouraged to be biased towards approving registrations 2684 unless they are abusive, frivolous, or actively harmful (not merely 2685 aesthetically displeasing, or architecturally dubious). 2687 +------------+--------------------------+ 2688 | Code | Termination Reason | 2689 +------------+--------------------------+ 2690 | 0x00 | Unknown | 2691 | | | 2692 | 0x01 | Idle timeout | 2693 | | | 2694 | 0x02 | Version mismatch | 2695 | | | 2696 | 0x03 | Busy | 2697 | | | 2698 | 0x04 | Contact Failure | 2699 | | | 2700 | 0x05 | Resource Exhaustion | 2701 | | | 2702 | 0x06--0xEF | Unassigned | 2703 | | | 2704 | 0xF0--0xFF | Private/Experimental Use | 2705 +------------+--------------------------+ 2707 Table 14: SESS_TERM Reason Codes 2709 9.8. MSG_REJECT Reason Codes 2711 EDITOR NOTE: sub-registry to-be-created upon publication of this 2712 specification. 2714 IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], 2715 a sub-registry titled "Bundle Protocol TCP Convergence-Layer Version 2716 4 MSG_REJECT Reason Codes" and initialize it with the contents of 2717 Table 15. The registration procedure is Specification Required 2718 within the lower range 0x01--0xEF. Values in the range 0xF0--0xFF 2719 are reserved for use on private networks for functions not published 2720 to the IANA. 2722 Specifications of new MSG_REJECT reason codes need to define the 2723 meaning of the reason and disambiguate it with pre-existing reasons. 2724 Each rejection reason needs to be usable by the receiving TCPCL 2725 Entity to make message sequencing and/or session termination 2726 decisions. 2728 Expert(s) are encouraged to be biased towards approving registrations 2729 unless they are abusive, frivolous, or actively harmful (not merely 2730 aesthetically displeasing, or architecturally dubious). 2732 +------------+--------------------------+ 2733 | Code | Rejection Reason | 2734 +------------+--------------------------+ 2735 | 0x00 | reserved | 2736 | | | 2737 | 0x01 | Message Type Unknown | 2738 | | | 2739 | 0x02 | Message Unsupported | 2740 | | | 2741 | 0x03 | Message Unexpected | 2742 | | | 2743 | 0x04--0xEF | Unassigned | 2744 | | | 2745 | 0xF0--0xFF | Private/Experimental Use | 2746 +------------+--------------------------+ 2748 Table 15: MSG_REJECT Reason Codes 2750 10. Acknowledgments 2752 This specification is based on comments on implementation of 2753 [RFC7242] provided from Scott Burleigh. 2755 11. References 2757 11.1. Normative References 2759 [I-D.ietf-dtn-bpbis] 2760 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 2761 Version 7", draft-ietf-dtn-bpbis-24 (work in progress), 2762 March 2020. 2764 [IANA-BUNDLE] 2765 IANA, "Bundle Protocol", 2766 . 2768 [IANA-PORTS] 2769 IANA, "Service Name and Transport Protocol Port Number 2770 Registry", . 2773 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2774 RFC 793, DOI 10.17487/RFC0793, September 1981, 2775 . 2777 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2778 Communication Layers", STD 3, RFC 1122, 2779 DOI 10.17487/RFC1122, October 1989, 2780 . 2782 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2783 Requirement Levels", BCP 14, RFC 2119, 2784 DOI 10.17487/RFC2119, March 1997, 2785 . 2787 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2788 Resource Identifier (URI): Generic Syntax", STD 66, 2789 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2790 . 2792 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2793 Housley, R., and W. Polk, "Internet X.509 Public Key 2794 Infrastructure Certificate and Certificate Revocation List 2795 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2796 . 2798 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 2799 Extensions: Extension Definitions", RFC 6066, 2800 DOI 10.17487/RFC6066, January 2011, 2801 . 2803 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2804 Verification of Domain-Based Application Service Identity 2805 within Internet Public Key Infrastructure Using X.509 2806 (PKIX) Certificates in the Context of Transport Layer 2807 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2808 2011, . 2810 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2811 "Recommendations for Secure Use of Transport Layer 2812 Security (TLS) and Datagram Transport Layer Security 2813 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2814 2015, . 2816 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2817 Writing an IANA Considerations Section in RFCs", BCP 26, 2818 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2819 . 2821 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2822 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2823 May 2017, . 2825 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2826 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2827 . 2829 11.2. Informative References 2831 [AEAD-LIMITS] 2832 Luykx, A. and K. Paterson, "Limits on Authenticated 2833 Encryption Use in TLS", August 2017, 2834 . 2836 [github-dtn-bpbis-tcpcl] 2837 Sipos, B., "TCPCL Example Implementation", 2838 . 2840 [I-D.ietf-dtn-bpsec] 2841 Birrane, E. and K. McKeever, "Bundle Protocol Security 2842 Specification", draft-ietf-dtn-bpsec-22 (work in 2843 progress), March 2020. 2845 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 2846 RFC 2595, DOI 10.17487/RFC2595, June 1999, 2847 . 2849 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 2850 Text on Security Considerations", BCP 72, RFC 3552, 2851 DOI 10.17487/RFC3552, July 2003, 2852 . 2854 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 2855 Protocol (LDAP): The Protocol", RFC 4511, 2856 DOI 10.17487/RFC4511, June 2006, 2857 . 2859 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 2860 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 2861 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 2862 April 2007, . 2864 [RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for 2865 Transport Layer Security (TLS)", RFC 5489, 2866 DOI 10.17487/RFC5489, March 2009, 2867 . 2869 [RFC7122] Kruse, H., Jero, S., and S. Ostermann, "Datagram 2870 Convergence Layers for the Delay- and Disruption-Tolerant 2871 Networking (DTN) Bundle Protocol and Licklider 2872 Transmission Protocol (LTP)", RFC 7122, 2873 DOI 10.17487/RFC7122, March 2014, 2874 . 2876 [RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant 2877 Networking TCP Convergence-Layer Protocol", RFC 7242, 2878 DOI 10.17487/RFC7242, June 2014, 2879 . 2881 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 2882 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 2883 Transport Layer Security (TLS) and Datagram Transport 2884 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 2885 June 2014, . 2887 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 2888 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 2889 December 2014, . 2891 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 2892 Known Attacks on Transport Layer Security (TLS) and 2893 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 2894 February 2015, . 2896 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2897 Code: The Implementation Status Section", BCP 205, 2898 RFC 7942, DOI 10.17487/RFC7942, July 2016, 2899 . 2901 Appendix A. Significant changes from RFC7242 2903 The areas in which changes from [RFC7242] have been made to existing 2904 headers and messages are: 2906 o Split Contact Header into pre-TLS protocol negotiation and 2907 SESS_INIT parameter negotiation. The Contact Header is now fixed- 2908 length. 2910 o Changed Contact Header content to limit number of negotiated 2911 options. 2913 o Added session option to negotiate maximum segment size (per each 2914 direction). 2916 o Renamed "Endpoint ID" to "Node ID" to conform with BPv7 2917 terminology. 2919 o Added session extension capability. 2921 o Added transfer extension capability. Moved transfer total length 2922 into an extension item. 2924 o Defined new IANA registries for message / type / reason codes to 2925 allow renaming some codes for clarity. 2927 o Segments of all new IANA registries are reserved for private/ 2928 experimental use. 2930 o Expanded Message Header to octet-aligned fields instead of bit- 2931 packing. 2933 o Added a bundle transfer identification number to all bundle- 2934 related messages (XFER_SEGMENT, XFER_ACK, XFER_REFUSE). 2936 o Use flags in XFER_ACK to mirror flags from XFER_SEGMENT. 2938 o Removed all uses of SDNV fields and replaced with fixed-bit-length 2939 (network byte order) fields. 2941 o Renamed SHUTDOWN to SESS_TERM to deconflict term "shutdown" 2942 related to TCP connections. 2944 o Removed the notion of a re-connection delay parameter. 2946 The areas in which extensions from [RFC7242] have been made as new 2947 messages and codes are: 2949 o Added contact negotiation failure SESS_TERM reason code. 2951 o Added MSG_REJECT message to indicate an unknown or unhandled 2952 message was received. 2954 o Added TLS connection security mechanism. 2956 o Added Resource Exhaustion SESS_TERM reason code. 2958 Authors' Addresses 2959 Brian Sipos 2960 RKF Engineering Solutions, LLC 2961 7500 Old Georgetown Road 2962 Suite 1275 2963 Bethesda, MD 20814-6198 2964 United States of America 2966 Email: BSipos@rkf-eng.com 2968 Michael Demmer 2969 University of California, Berkeley 2970 Computer Science Division 2971 445 Soda Hall 2972 Berkeley, CA 94720-1776 2973 United States of America 2975 Email: demmer@cs.berkeley.edu 2977 Joerg Ott 2978 Aalto University 2979 Department of Communications and Networking 2980 PO Box 13000 2981 Aalto 02015 2982 Finland 2984 Email: ott@in.tum.de 2986 Simon Perreault 2988 Quebec, QC 2989 Canada 2991 Email: simon@per.reau.lt