idnits 2.17.1 draft-burleigh-dtn-stcp-00.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 (September 14, 2018) is 2051 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) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Delay-Tolerant Networking Working Group S. Burleigh 2 Internet Draft JPL, Calif. Inst. Of Technology 3 Intended status: Standards Track September 14, 2018 4 Expires: March 2019 6 Simple TCP Convergence-Layer Protocol 7 draft-burleigh-dtn-stcp-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on March 15, 2019. 32 Copyright Notice 34 Copyright (c) 2018 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. Code Components extracted from this 43 document must include Simplified BSD License text as described in 44 Section 4.e of the Trust Legal Provisions and are provided without 45 warranty as described in the Simplified BSD License. 47 Abstract 49 This document describes a Simple TCP (STCP) "convergence-layer" 50 protocol for the Delay-Tolerant Networking (DTN) Bundle Protocol 51 (BP). STCP uses Transmission Control Protocol (TCP) to transmit BP 52 "bundles" from one BP node to another node to which it is 53 topologically adjacent in the BP network. The services provided by 54 the STCP convergence-layer protocol adapter utilize a standard TCP 55 connection for the purposes of bundle transmission. 57 Table of Contents 59 1. Introduction...................................................2 60 2. Conventions used in this document..............................3 61 3. STCP Design Elements...........................................3 62 3.1. STCP Endpoints............................................3 63 3.2. STCP Protocol Data Units..................................4 64 3.3. Custody Signals................Error! Bookmark not defined. 65 3.4. Custody Transfer Status ReportsError! Bookmark not defined. 66 4. STCP Procedures................................................4 67 4.1. SPDU Transmission.........................................4 68 4.2. SPDU Reception.................Error! Bookmark not defined. 69 4.3. Retransmission Timer ExpirationError! Bookmark not defined. 70 4.4. Custody Signal Reception.......Error! Bookmark not defined. 71 5. Security Considerations........................................6 72 6. IANA Considerations............................................6 73 7. References.....................................................6 74 7.1. Normative References......................................6 75 7.2. Informative References....................................6 76 8. Acknowledgments................................................6 77 Appendix A. For More Information..................................7 78 Appendix B. CDDL expression............Error! Bookmark not defined. 80 1. Introduction 82 This document describes the Simple TCP (STCP) protocol, a Delay- 83 Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050] 84 "convergence layer" protocol that uses a standard TCP connection to 85 transmit bundles from one BP node to another node to which it is 86 topologically adjacent in the BP network. 88 Conformance to the STCP convergence-layer protocol specification is 89 OPTIONAL for BP nodes. 91 Each BP node that conforms to the STCP specification includes an 92 STCP convergence-layer adapter (SCLA). Every SCLA engages in 93 communication via the Transmission Control Protocol [RFC0793]. 95 Like any convergence-layer adapter, the STCP CLA provides: 97 . A transmission service that sends an outbound bundle (from the 98 bundle protocol agent) to a peer CLA via the STCP convergence 99 layer protocol. 100 . A reception service that delivers to the bundle protocol agent 101 an inbound bundle that was sent by a peer CLA via the STCP 102 convergence layer protocol. 104 Transmission of bundles via STCP is "reliable" to the extent that 105 TCP itself is reliable. STCP provides no supplementary error 106 detection and recovery procedures. In particular, STCP does not 107 provide to the sender any intermediate reporting of reception 108 progress. 110 2. Conventions used in this document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC-2119 [RFC2119]. 116 In this document, these words will appear with that interpretation 117 only when in ALL CAPS. Lower case uses of these words are not to be 118 interpreted as carrying RFC-2119 significance. 120 3. STCP Design Elements 122 3.1. STCP Sessions 124 An STCP "session" is formed when a TCP connection is established by 125 the matching of an active TCP OPEN request issued by some SCLA, 126 termed the session's "sender", with a passive TCP OPEN request 127 issued by some SCLA, termed the session's "receiver". That portion 128 of the state of a session that is exposed to the session's sender is 129 termed the "transmission element" of the session. That portion of 130 the state of a session that is exposed to the session's receiver is 131 termed the "reception element" of the session. 133 The values of the parameters constraining STCP's TCP connection 134 establishment, including the establishment of Transport Layer 135 Security (TLS; [RFC8446]) sessions within the connections, are 136 assumed to be provided by management. At some point a discovery 137 protocol may be developed that enables these values to be declared 138 automatically; such protocol is beyond the scope of this 139 specification. 141 STCP sessions are unidirectional; that is, bundles transmitted via 142 an STCP session are transmitted only from the session's sender to 143 its receiver. When bidirectional exchange of bundles between SCLAs 144 via STCP is required, two sessions are formed, one in each 145 direction. 147 Closure of either element of a session MAY occur either upon request 148 of the bundle protocol agent or upon detection of any error. 149 Closure of either element of an STCP session SHALL cause the 150 corresponding TCP connection to be terminated (unless termination of 151 that connection was in fact the cause of the closure of that session 152 element). Since termination of the associated TCP connection will 153 result in errors at the other element of the session, termination of 154 either element of the session will effectively terminate the 155 session. 157 3.2. STCP Protocol Data Units 159 An STCP protocol data unit (SPDU) is simply a serialized bundle 160 preceded by an integer indicating the length of that serialized 161 bundle. An SPDU is constructed as follows. 163 Each SPDU SHALL be represented as a CBOR array. The number of items 164 in the array SHALL be 2. 166 The first item of the SPDU array SHALL be the length of the 167 serialized bundle that is encapsulated in the SPDU, represented as a 168 CBOR unsigned integer. 170 The second item of the SPDU array SHALL be a single serialized BP 171 bundle, termed the "encapsulated bundle", represented as a CBOR byte 172 string. 174 4. STCP Procedures 176 4.1. SPDU Transmission 178 When an SCLA is requested by the bundle protocol agent to send a 179 bundle to a peer SCLA identified by some IP address and port number: 181 . If no STCP session enabling transmission to that SCLA has been 182 formed, the SCLA SHALL attempt to form that session. If this 183 attempt is unsuccessful, the SCLA SHALL inform the bundle 184 protocol agent that its data sending procedures with regard to 185 this bundle have concluded and transmission of the bundle was 186 unsuccessful; no further steps of this procedure will be 187 attempted. 188 . The SCLA SHALL form an SPDU from the subject bundle. 189 . The SCLA SHALL attempt to send this SPDU to the peer SCLA by 190 TCP via the transmission element of the session formed for this 191 purpose. 192 o If that transmission is completed without error, the SCLA 193 SHALL inform the bundle protocol agent that its data 194 sending procedures with regard to this bundle have 195 concluded and transmission of the bundle was successful. 196 o Otherwise: 197 . The transmission element SHALL be closed. 198 . The SCLA SHALL inform the bundle protocol agent that 199 its data sending procedures with regard to this 200 bundle have concluded and transmission of the bundle 201 was unsuccessful. 203 4.2. Reception Session Formation 205 An SCLA that is required to receive (rather than only transmit) 206 bundles SHALL issue a passive TCP OPEN. Whenever TCP matches that 207 passive OPEN with an active TCP OPEN issued by some SCLA, an STCP 208 session is formed as noted earlier; SPDUs may be received via the 209 reception element of such session. 211 4.3. SPDU Reception 213 From the moment at which an STCP session reception element is first 214 exposed to the moment at which it is closed, in a continuous cycle, 215 the corresponding session's receiver SHALL: 217 . Attempt to receive, by TCP via the corresponding session, the 218 length of the next bundle sent via this session. If this 219 attempt fails for any reason, the reception element SHALL be 220 closed and no further steps of this procedure will be 221 attempted. 222 . Attempt to receive, by TCP via the corresponding session, a 223 serialized bundle of the indicated length. If this attempt 224 fails for any reason, the reception element SHALL be closed and 225 no further steps of this procedure will be attempted. 226 . Deliver the received serialized bundle to the bundle protocol 227 agent. 229 5. Security Considerations 231 Because STCP constitutes a nearly negligible extension of TCP, it 232 introduces virtually no security considerations beyond the well- 233 known TCP security considerations. 235 An adversary could mount a denial-of-service attack by repeatedly 236 establishing and terminating STCP sessions; well-understood DOS 237 attack mitigations would apply. 239 Maliciously formed bundle lengths could disrupt the operation of 240 STCP session receivers, but STCP implementations need to be robust 241 against incorrect bundle lengths in any case. 243 Maliciously crafted serialized bundles could be received and 244 delivered to the bundle protocol agent, but that is not an STCP- 245 specific security consideration: all bundles delivered to the BPA by 246 all convergence-layer adapters need to be processed in awareness of 247 this possibility. 249 6. IANA Considerations 251 No new IANA considerations apply. 253 7. References 255 7.1. Normative References 257 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 258 793, DOI 10.17487/RFC0793, September 1981. 260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 261 Requirement Levels", BCP 14, RFC 2119, March 1997. 263 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 264 Version 1.3", RFC 8446, August 2018. 266 7.2. Informative References 268 [RFC5050] Scott, M. and S. Burleigh, "Bundle Protocol 269 Specification", RFC 5050, November 2007. 271 8. Acknowledgments 273 This document was prepared using 2-Word-v2.0.template.dot. 275 Appendix A. For More Information 277 Please refer comments to dtn@ietf.org. The Delay Tolerant Networking 278 Research Group (DTNRG) Web site is located at http://www.dtnrg.org. 280 Copyright (c) 2018 IETF Trust and the persons identified as authors 281 of the code. All rights reserved. 283 Redistribution and use in source and binary forms, with or without 284 modification, is permitted pursuant to, and subject to the license 285 terms contained in, the Simplified BSD License set forth in Section 286 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 287 (http://trustee.ietf.org/license-info). 289 Authors' Address 291 Scott Burleigh 292 Jet Propulsion Laboratory, California Institute of Technology 293 4800 Oak Grove Dr. 294 Pasadena, CA 91109-8099 295 US 296 Phone: +1 818 393 3353 297 Email: Scott.Burleigh@jpl.nasa.gov