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