idnits 2.17.1 draft-badra-tls-multiplexing-01.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 (April 28, 2011) is 4747 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '2' on line 210 -- Looks like a reference, but probably isn't: '4' on line 304 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Badra 3 Internet-Draft CNRS/LIMOS Laboratory 4 Intended status: Standards Track I. Hajjeh 5 Expires: October 30, 2011 INEOVATION 6 April 28, 2011 8 Multiplexing Single-Application Multiple-Connection over TLS 9 draft-badra-tls-multiplexing-01.txt 11 Abstract 13 The Transport Layer Security (TLS) is the most widely deployed 14 protocol for securing network traffic. It provides mutual 15 authentication, data confidentiality and integrity, key generation 16 and distribution, and security parameters negotiation. However, 17 missing from the protocol is a way to multiplex single-application 18 multiple-stream applications that commonly use parallel connections 19 to the same logical and/or physical server application data. 21 This document describes a mechanism to multiplex single-application 22 multiple-stream over TLS. It extends TLS to multiplex parallel 23 connections of a given application over a single TLS session, 24 avoiding additional delay related to the TLS/TCP session/connection 25 setup. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 30, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 63 2. TLS multiplexing Overview and Considerations . . . . . . . . . 4 64 2.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1.1. Opening Channels . . . . . . . . . . . . . . . . . . . 4 66 2.1.2. Closing Channels . . . . . . . . . . . . . . . . . . . 6 67 2.2. MTA-TLS Flow Control . . . . . . . . . . . . . . . . . . . 7 68 2.3. MTA-TLS Message Types . . . . . . . . . . . . . . . . . . 8 69 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 72 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 7. Normative References . . . . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 76 1. Introduction 78 A single-application multiple-stream/-thread/-connection commonly 79 uses parallel connections to the same logical and/or physical server 80 application data. When that application is run over TCP, a TCP 81 connection must be established for each stream/thread/connection 82 (channel). This incurs a significant additional delay due to the TCP 83 slow-start and to the duplication of an existing TLS session as well. 84 Having a single TCP connection and opening additional channels over 85 that single TCP connection can benefit of a high TCP congestion 86 window and throughput instantaneously via statistical multiplexing, 87 and raising the throughput further (incrementally) from an already 88 high level can be achieved much faster in TCP. 90 TLS does not multiplex single-application multiple-channel; it must 91 instead duplicate the existing TLS session for each channel. This 92 document defines Multiplexing Multi-Threaded Application over 93 Transport Layer Security (MTA-TLS). MTA-TLS extends TLS to multiplex 94 a single-application multiple-channel over a single TLS session, 95 avoiding additional delay related to the TLS/TCP session/connection 96 setup. 98 1.1. Conventions Used in This Document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. TLS multiplexing Overview and Considerations 106 This document makes use of TLS extensions described in [RFC5246] and 107 defines an extension of type data_multiplexing(TBD). The 108 "extension_data" field of this extension SHALL be empty (zero- 109 length). 111 2.1. Handshake 113 The client and the server can, in an ordinary TLS handshake, 114 negotiate the future use of MTA-TLS. The negotiation usually starts 115 with the client that indicates its support of MTA-TLS by including an 116 extension of type 'data_multiplexing' in its hello message. 118 If the client does attempt to initiate a TLS session using MTA-TLS 119 with a server that does not support it, it will be automatically 120 alerted. For servers aware of MTA-TLS but not wishing to use it, it 121 will gracefully revert to an ordinary TLS handshake or stop the 122 negotiation. 124 If the server is able of and willing to use the "data_multiplexing" 125 extension, it MUST reply with an empty extension of the same type. 127 Once the Handshake is complete, both the client and the server can 128 start 'channel multiplexing' using a set of requests/responses 129 defined below. All requests/responses will pass through MTA-TLS 130 layer and are formatted into MTA-TLS packets, depending on each 131 request/response. 133 2.1.1. Opening Channels 135 The sender MAY request the opening of many channels. For each 136 channel, the MTA-TLS layer generates and sends the following request: 138 struct { 139 uint8 type; 140 uint16 length; 141 opaque sender_channel_id[2]; 142 uint32 sender_window_length; 143 uint32 sender_max_packet_length; 144 opaque source_address_machine<1..2^16-1>; 145 opaque source_port[2]; 146 opaque destination_address_machine<1..2^16-1>; 147 opaque destination_port[2]; 148 } ChannelEstablishmentRequest; 150 type 151 The "type" field specifies the MTA-TLS packet type (types are 152 summarized below). 154 length 156 The "length" field indicates the length, in octets, of the current 157 MTA-TLS packet. 159 sender_channel_id 161 The "sender_channel_id" is the first half of the channel 162 identifier. The second half is generated by the receiver of that 163 MTA-TLS packet. 165 sender_window_length 167 The "sender_window_length" field conveys the data length (in 168 octets), specifying how many bytes the receiver of the packet can 169 maximally send on the channel before receiving a new window length 170 (available free space). Each end of the channel establishes a 171 "receive buffer" and a "send buffer". 173 sender_max_packet_length 175 The "sender_max_packet_length" field conveys the data length (in 176 octets), specifying the maximal packet's length in octets the 177 receiver of that packet can send on the channel. The 178 sender_max_packet_length is always smaller than the free space of 179 the sender_window_length (the sender's "receive buffer"). 181 source_address_machine and source_port 183 The "source_address_machine" MAY carry either the numeric IP 184 address or the domain name of the host from where the application 185 originates the data multiplexing request and the "source_port" is 186 the port on the host from where the connection originated. 188 destination_address_machine and destination_port 190 The "destination_address_machine" and "destination_port" specify 191 the TCP/IP host and port where the recipient should connect the 192 channel. The "destination_address_machine" MAY be either a domain 193 name or a numeric IP address. 195 The receiver decides whether it can open the channel, and replies 196 with one of the following messages: 198 struct { 199 uint8 type; 200 uint16 length; 201 opaque sender_channel_id[2]; 202 opaque receiver_channel_id[2]; 203 uint32 receiver_window_length; 204 uint32 receiver_max_packet_length; 205 } ChannelEstablishmentSuccess; 207 struct { 208 uint8 type; 209 uint16 length; 210 opaque sender_channel_id[2]; 211 opaque error<0..2^16-6>; 212 } ChannelRequestEchec; 214 The "sender_channel_id" and "receiver_channel_id" are the same 215 generated during the channel establishment. The length conveys the 216 data length of the current packet. 218 The field "error" conveys a description of the error. 220 Each MTA-TLS channel has its identifier computed as: 222 channel_id = sender_channel_id + receiver_channel_id 224 Where "+" indicates concatenation. 226 Note: channel_id may be susceptible to collisions. The receiver 227 needs to take care not to choose a "receiver_channel_id" to avoid any 228 collide with any of the established channel identifiers. 230 2.1.2. Closing Channels 232 The following packet MAY be sent to notify the receiver that the 233 sender will not send any more data on this channel and that any data 234 received after a closure request will be ignored. The sender of the 235 closure request MAY close its "receive buffer" without waiting for 236 the receiver's response. However, the receiver MUST respond with a 237 confirmation of the closure and close down the channel immediately, 238 discarding any pending writes. 240 struct { 241 uint8 type; 242 uint16 length; 243 opaque channel_id[4]; 244 } ChannelCloseRequest; 246 struct { 247 uint8 type; 248 uint16 length; 249 opaque channel_id[4]; 250 } ChannelCloseConfirmation; 252 The above two packets can be sent even if no window space is 253 available. 255 2.2. MTA-TLS Flow Control 257 The structure of the MTA-TLS data packet is described below. 259 Each entity maintains its "max_packet_length" (that is originally 260 initialized during the channel establishment) to a value not bigger 261 than the free space of its "receive buffer". For each received 262 packet, the receiver MUST subtract the packet's length from the free 263 space of its "receive buffer". For each transmitted packet, the 264 sender MUST subtract the packet's length from the free space of its 265 "send buffer". In any case, the result is always positive. 267 If the entity is willing to notify the other side about any change in 268 the "max_packet_length", the entity MUST send a NewMaxPacketLength 269 conveying the new "max_packet_length" that MUST be smaller than the 270 free space of the entity's "receive buffer" 272 The free space of the "receive buffer" of the sender (resp. the 273 receiver) MAY increase in length. The sender SHOULD send an 274 Acknowledgment packet to inform the receiver about this increase, 275 allowing this latter to send more packets but with length smaller or 276 equal than the minimum of the "max_packet_length" and the "receive 277 buffer" of the sender. 279 If the length of the "receive buffer" does not change, the 280 Acknowledgment packet will never be sent. 282 In the case where the "receive buffer" of an entity fills up, the 283 other entity MUST wait for an Acknowledgment packet before sending 284 any more MTATLSPlaintext packets. 286 struct { 287 uint8 type; 288 uint32 length; 289 opaque channel_id[4]; 290 opaque data[MTATLSPlaintext.length]; 291 } MTATLSPlaintext; 293 struct { 294 uint8 type; 295 uint16 length; 296 opaque channel_id[4]; 297 uint32 max_packet_length; 298 /* the max_packet_length of the sender of that packet */ 299 } NewMaxPacketLength; 301 struct { 302 uint8 type; 303 uint16 length; 304 opaque channel_id[4]; 305 uint32 free_space; 306 } Acknowledgment; 308 The Acknowledgment and NewMaxPacketLength packets can be sent even if 309 no window space is available. 311 The TLS Record Layer receives data from MTA-TLS, supposes it as 312 uninterpreted data and applies the fragmentation and the 313 cryptographic operations on it, as defined in [RFC5246]. 315 Note: multiple MTA-TLS fragments MAY be coalesced into a single 316 TLSPlaintext record. 318 Received data is decrypted, verified, decompressed, and reassembled, 319 then delivered to MTA-TLS entity. Next, the MTA-TLS sends data to 320 the appropriate application using the channel identifier and the 321 length value. 323 2.3. MTA-TLS Message Types 325 This section defines the initial set of MTA-TLS Message Types used in 326 Request/Response exchanges. The Message Type field is one octet and 327 identifies the structure of an MTA-TLS Request or Response message. 329 The messages defined in this document are listed below. More Message 330 Types may be defined in future documents. The list of Message Types, 331 as defined through this document, is maintained by the Internet 332 Assigned Numbers Authority (IANA). Thus, an application needs to be 333 made to the IANA in order to obtain a new Message Type value. Since 334 there are subtle (and not-so-subtle) interactions that may occur in 335 this protocol between new features and existing features that may 336 result in a significant reduction in overall security, new values 337 SHALL be defined only through the IETF Review process specified in 338 [RFC5226]. 340 ChannelEstablishmentRequest 1 341 ChannelEstablishmentSuccess 2 342 ChannelRequestEchec 3 343 ChannelCloseRequest 4 344 ChannelCloseConfirmation 5 345 MTATLSPlaintext 6 346 NewMaxPacketLength 7 347 Acknowledgment 8 349 3. Security Considerations 351 Security issues are discussed throughout this document and in 352 [RFC5246]. 354 If a fatal error related to any channel of an arbitrary application 355 occurs, the secure session MUST NOT be resumed. This is logic since 356 the Record protocol does not distinguish between the MTA-TLS 357 channels. However, if an error occurs at the MTA-TLS layer, both 358 parties immediately close the related channel, but not the TLS 359 session (no alert of any type is sent by the TLS Record). 361 4. IANA Considerations 363 This section provides guidance to the IANA regarding registration of 364 values related to the TLS protocol. 366 There are name spaces that require registration: the 367 data_multiplexing extension and the MTA-TLS message types. 369 Message Types have a range from 1 to 255, of which 1-8 are to be 370 allocated for this document. Because a new Message Type has 371 considerable impact on interoperability, a new Message Type SHALL be 372 defined only through the IETF Review process specified in [RFC5226]. 374 5. Acknowledgments 376 The authors appreciate Alfred Hoenes for his detailed review. 378 6. Contributors 380 TBC 382 7. Normative References 384 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 385 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 386 May 2008. 388 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 389 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 392 Requirement Levels", BCP 14, RFC 2119, March 1997. 394 Authors' Addresses 396 Mohamad Badra 397 CNRS/LIMOS Laboratory 398 Campus de cezeaux, Bat. ISIMA 399 Aubiere 400 France 402 Email: badra@isima.fr 404 Ibrahim Hajjeh 405 INEOVATION 406 Paris 407 France 409 Email: ibrahim.hajjeh@ineovation.fr 411 James Blaisdell 412 Mocana 413 San Francisco 414 USA 416 Email: JBlaisdell@mocana.com