idnits 2.17.1 draft-ietf-dtn-mtcpcl-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 (February 28, 2019) is 1882 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 7525 (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 2 errors (**), 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 February 28, 2019 4 Expires: September 2019 6 Minimal TCP Convergence-Layer Protocol 7 draft-ietf-dtn-mtcpcl-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 September 1, 2019. 32 Copyright Notice 34 Copyright (c) 2019 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 Minimal TCP (MTCP) "convergence-layer" 50 protocol for the Delay-Tolerant Networking (DTN) Bundle Protocol 51 (BP). MTCP 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 MTCP 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. MTCP Design Elements...........................................3 62 3.1. MTCP Sessions.............................................3 63 3.2. MTCP Protocol Data Units..................................4 64 4. MTCP Procedures................................................5 65 4.1. MPDU Transmission.........................................5 66 4.2. Reception Session Formation...............................5 67 4.3. MPDU Reception............................................5 68 5. Security Considerations........................................6 69 6. IANA Considerations............................................6 70 7. References.....................................................7 71 7.1. Normative References......................................7 72 7.2. Informative References....................................7 73 8. Acknowledgments................................................7 74 Appendix A. For More Information..................................8 76 1. Introduction 78 This document describes the Minimal TCP (MTCP) protocol, a Delay- 79 Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050] 80 "convergence layer" protocol that uses a standard TCP connection to 81 transmit bundles from one BP node to another node to which it is 82 topologically adjacent in the BP network. 84 Conformance to the MTCP convergence-layer protocol specification is 85 OPTIONAL for BP nodes. 87 Each BP node that conforms to the MTCP specification includes an 88 MTCP convergence-layer adapter (MCLA). Every MCLA engages in 89 communication via the Transmission Control Protocol [RFC0793]. 91 Like any convergence-layer adapter, the MTCP CLA provides: 93 . A transmission service that sends an outbound bundle (from the 94 bundle protocol agent) to a peer CLA via the MTCP convergence 95 layer protocol. 96 . A reception service that delivers to the bundle protocol agent 97 an inbound bundle that was sent by a peer CLA via the MTCP 98 convergence layer protocol. 100 Transmission of bundles via MTCP is "reliable" to the extent that 101 TCP itself is reliable. MTCP provides no supplementary error 102 detection and recovery procedures. In particular, MTCP does not 103 provide to the sender any interim reporting of reception progress. 105 2. Conventions used in this document 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC-2119 [RFC2119]. 111 In this document, these words will appear with that interpretation 112 only when in ALL CAPS. Lower case uses of these words are not to be 113 interpreted as carrying RFC-2119 significance. 115 3. MTCP Design Elements 117 3.1. MTCP Sessions 119 An MTCP "session" is formed when a TCP connection is established by 120 the matching of an active TCP OPEN request issued by some MCLA, 121 termed the session's "sender", with a passive TCP OPEN request 122 issued by some MCLA, termed the session's "receiver". That portion 123 of the state of a session that is exposed to the session's sender is 124 termed the "transmission element" of the session. That portion of 125 the state of a session that is exposed to the session's receiver is 126 termed the "reception element" of the session. 128 The values of the parameters constraining MTCP's TCP connection 129 establishment, including the establishment of Transport Layer 130 Security (TLS; [RFC8446]) sessions within the connections, SHALL be 131 provided by management, by means that are beyond the scope of this 132 specification. 134 The use of TLS to secure MTCP sessions is optional but is strongly 135 recommended. When it is determined, by management, that an MTCP 136 session between a given sender and receiver is to be secured by TLS: 138 . Following establishment of the session's TCP connection, the 139 sender and receiver SHALL undertake a TLS handshake in 140 accordance with [RFC8446] with the sender acting in the role of 141 "client". The parameter settings governing each such handshake 142 (again, determined by management) are an implementation matter, 143 but the handshake SHOULD conform to all recommended best 144 practices of [RFC7525] and its updates and successors. 145 . If the handshake does not result in successful establishment of 146 a TLS session, then the session's TCP connection SHALL be 147 terminated and the attempt to form an MTCP session shall be 148 abandoned. 150 MTCP sessions are unidirectional; that is, bundles transmitted via 151 an MTCP session are transmitted only from the session's sender to 152 its receiver. When bidirectional exchange of bundles between MCLAs 153 via MTCP is required, two MTCP sessions are formed, one in each 154 direction. 156 Closure of either element of a session MAY occur either upon request 157 of the bundle protocol agent or upon detection of any error. 158 Closure of either element of an MTCP session SHALL cause the 159 corresponding TCP connection to be terminated (unless termination of 160 that connection was in fact the cause of the closure of that session 161 element). Since termination of the associated TCP connection will 162 result in errors at the other element of the session, termination of 163 either element of the session will effectively terminate the 164 session. 166 3.2. MTCP Protocol Data Units 168 An MTCP protocol data unit (MPDU) is simply a serialized bundle 169 preceded by an integer indicating the length of that serialized 170 bundle. An MPDU is constructed as follows. 172 Each MPDU SHALL be represented as a CBOR array. The number of items 173 in the array SHALL be 2. 175 The first item of the MPDU array SHALL be the length of the 176 serialized bundle that is encapsulated in the MPDU, represented as a 177 CBOR unsigned integer. 179 The second item of the MPDU array SHALL be a single serialized BP 180 bundle, termed the "encapsulated bundle", represented as a CBOR byte 181 string of definite length (NOT an indefinite-length byte string). 183 4. MTCP Procedures 185 4.1. MPDU Transmission 187 When an MCLA is requested by the bundle protocol agent to send a 188 bundle to a peer MCLA identified by some IP address and port number: 190 . If no MTCP session enabling transmission to that MCLA has been 191 formed, the MCLA SHALL attempt to form that session. If this 192 attempt is unsuccessful, the MCLA SHALL inform the bundle 193 protocol agent that its data sending procedures with regard to 194 this bundle have concluded and transmission of the bundle was 195 unsuccessful; no further steps of this procedure will be 196 attempted. 197 . The MCLA SHALL form an MPDU from the subject bundle. 198 . The MCLA SHALL attempt to send this MPDU to the peer MCLA by 199 TCP via the transmission element of the session formed for this 200 purpose. 201 o If that transmission is completed without error, the MCLA 202 SHALL inform the bundle protocol agent that its data 203 sending procedures with regard to this bundle have 204 concluded and transmission of the bundle was successful. 205 o Otherwise: 206 . The transmission element SHALL be closed. 207 . The MCLA SHALL inform the bundle protocol agent that 208 its data sending procedures with regard to this 209 bundle have concluded and transmission of the bundle 210 was unsuccessful. 212 4.2. Reception Session Formation 214 An MCLA that is required to receive (rather than only transmit) 215 bundles SHALL issue a passive TCP OPEN. Whenever TCP matches that 216 passive OPEN with an active TCP OPEN issued by some MCLA, an MTCP 217 session is formed as noted earlier; MPDUs may be received via the 218 reception element of such session. 220 4.3. MPDU Reception 222 From the moment at which an MTCP session reception element is first 223 exposed to the moment at which it is closed, in a continuous cycle, 224 the corresponding session's receiver SHALL: 226 . Attempt to receive, by TCP via the corresponding session, the 227 length of the next bundle sent via this session. If this 228 attempt fails for any reason, the reception element SHALL be 229 closed and no further steps of this procedure will be 230 attempted. 231 . Attempt to receive, by TCP via the corresponding session, a 232 serialized bundle of the indicated length. If this attempt 233 fails for any reason, the reception element SHALL be closed and 234 no further steps of this procedure will be attempted. 235 . Deliver the received serialized bundle to the bundle protocol 236 agent. 238 5. Security Considerations 240 Because MTCP constitutes a nearly negligible extension of TCP, it 241 introduces virtually no security considerations beyond the well- 242 known TCP security considerations. To address these considerations, 243 the use of TLS to secure MTCP sessions is strongly recommended. 245 Even when TLS is used to secure an MTCP session, the ciphersuite 246 specified for the TLS session may be insecure. For example, TLS can 247 be configured to support authentication without confidentiality. 248 MCLA management MUST ensure that the ciphersuites employed to secure 249 MTCP sessions meet transport security requirements. This constraint 250 echoes constraints on STARTTLS in [RFC2595]. 252 An adversary could mount a denial-of-service attack by repeatedly 253 establishing and terminating MTCP sessions; well-understood DOS 254 attack mitigations would apply. 256 Maliciously formed bundle lengths could disrupt the operation of 257 MTCP session receivers, but MTCP implementations need to be robust 258 against incorrect bundle lengths in any case. 260 Maliciously crafted serialized bundles could be received and 261 delivered to the bundle protocol agent, but that is not an MTCP- 262 specific security consideration: all bundles delivered to the BPA by 263 all convergence-layer adapters need to be processed in awareness of 264 this possibility. 266 6. IANA Considerations 268 No new IANA considerations apply. 270 7. References 272 7.1. Normative References 274 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations 275 for Secure Use of Transport Layer Security (TLS) and Datagram 276 Transport Layer Security (DTLS)", BCP 195, RFC 7525, May 2015. 278 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 279 793, DOI 10.17487/RFC0793, September 1981. 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, March 1997. 284 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 285 Version 1.3", RFC 8446, August 2018. 287 7.2. Informative References 289 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 290 2595, August 2018. 292 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 293 Specification", RFC 5050, November 2007. 295 8. Acknowledgments 297 This document was prepared using 2-Word-v2.0.template.dot. 299 Appendix A. For More Information 301 Please refer comments to dtn@ietf.org. The Delay Tolerant Networking 302 Research Group (DTNRG) Web site is located at http://www.dtnrg.org. 304 Copyright (c) 2019 IETF Trust and the persons identified as authors 305 of the code. All rights reserved. 307 Redistribution and use in source and binary forms, with or without 308 modification, is permitted pursuant to, and subject to the license 309 terms contained in, the Simplified BSD License set forth in Section 310 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 311 (http://trustee.ietf.org/license-info). 313 Authors' Address 315 Scott Burleigh 316 Jet Propulsion Laboratory, California Institute of Technology 317 4800 Oak Grove Dr. 318 Pasadena, CA 91109-8099 319 US 320 Phone: +1 818 393 3353 321 Email: Scott.Burleigh@jpl.nasa.gov