Internet DRAFT - draft-badra-tls-multiplexing
draft-badra-tls-multiplexing
Network Working Group M. Badra
Internet-Draft CNRS/LIMOS Laboratory
Intended status: Standards Track I. Hajjeh
Expires: October 30, 2011 INEOVATION
April 28, 2011
Multiplexing Single-Application Multiple-Connection over TLS
draft-badra-tls-multiplexing-01.txt
Abstract
The Transport Layer Security (TLS) is the most widely deployed
protocol for securing network traffic. It provides mutual
authentication, data confidentiality and integrity, key generation
and distribution, and security parameters negotiation. However,
missing from the protocol is a way to multiplex single-application
multiple-stream applications that commonly use parallel connections
to the same logical and/or physical server application data.
This document describes a mechanism to multiplex single-application
multiple-stream over TLS. It extends TLS to multiplex parallel
connections of a given application over a single TLS session,
avoiding additional delay related to the TLS/TCP session/connection
setup.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 30, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Badra, et al. Expires October 30, 2011 [Page 1]
Internet-Draft MTA-TLS April 2011
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. TLS multiplexing Overview and Considerations . . . . . . . . . 4
2.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Opening Channels . . . . . . . . . . . . . . . . . . . 4
2.1.2. Closing Channels . . . . . . . . . . . . . . . . . . . 6
2.2. MTA-TLS Flow Control . . . . . . . . . . . . . . . . . . . 7
2.3. MTA-TLS Message Types . . . . . . . . . . . . . . . . . . 8
3. Security Considerations . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Badra, et al. Expires October 30, 2011 [Page 2]
Internet-Draft MTA-TLS April 2011
1. Introduction
A single-application multiple-stream/-thread/-connection commonly
uses parallel connections to the same logical and/or physical server
application data. When that application is run over TCP, a TCP
connection must be established for each stream/thread/connection
(channel). This incurs a significant additional delay due to the TCP
slow-start and to the duplication of an existing TLS session as well.
Having a single TCP connection and opening additional channels over
that single TCP connection can benefit of a high TCP congestion
window and throughput instantaneously via statistical multiplexing,
and raising the throughput further (incrementally) from an already
high level can be achieved much faster in TCP.
TLS does not multiplex single-application multiple-channel; it must
instead duplicate the existing TLS session for each channel. This
document defines Multiplexing Multi-Threaded Application over
Transport Layer Security (MTA-TLS). MTA-TLS extends TLS to multiplex
a single-application multiple-channel over a single TLS session,
avoiding additional delay related to the TLS/TCP session/connection
setup.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Badra, et al. Expires October 30, 2011 [Page 3]
Internet-Draft MTA-TLS April 2011
2. TLS multiplexing Overview and Considerations
This document makes use of TLS extensions described in [RFC5246] and
defines an extension of type data_multiplexing(TBD). The
"extension_data" field of this extension SHALL be empty (zero-
length).
2.1. Handshake
The client and the server can, in an ordinary TLS handshake,
negotiate the future use of MTA-TLS. The negotiation usually starts
with the client that indicates its support of MTA-TLS by including an
extension of type 'data_multiplexing' in its hello message.
If the client does attempt to initiate a TLS session using MTA-TLS
with a server that does not support it, it will be automatically
alerted. For servers aware of MTA-TLS but not wishing to use it, it
will gracefully revert to an ordinary TLS handshake or stop the
negotiation.
If the server is able of and willing to use the "data_multiplexing"
extension, it MUST reply with an empty extension of the same type.
Once the Handshake is complete, both the client and the server can
start 'channel multiplexing' using a set of requests/responses
defined below. All requests/responses will pass through MTA-TLS
layer and are formatted into MTA-TLS packets, depending on each
request/response.
2.1.1. Opening Channels
The sender MAY request the opening of many channels. For each
channel, the MTA-TLS layer generates and sends the following request:
struct {
uint8 type;
uint16 length;
opaque sender_channel_id[2];
uint32 sender_window_length;
uint32 sender_max_packet_length;
opaque source_address_machine<1..2^16-1>;
opaque source_port[2];
opaque destination_address_machine<1..2^16-1>;
opaque destination_port[2];
} ChannelEstablishmentRequest;
type
Badra, et al. Expires October 30, 2011 [Page 4]
Internet-Draft MTA-TLS April 2011
The "type" field specifies the MTA-TLS packet type (types are
summarized below).
length
The "length" field indicates the length, in octets, of the current
MTA-TLS packet.
sender_channel_id
The "sender_channel_id" is the first half of the channel
identifier. The second half is generated by the receiver of that
MTA-TLS packet.
sender_window_length
The "sender_window_length" field conveys the data length (in
octets), specifying how many bytes the receiver of the packet can
maximally send on the channel before receiving a new window length
(available free space). Each end of the channel establishes a
"receive buffer" and a "send buffer".
sender_max_packet_length
The "sender_max_packet_length" field conveys the data length (in
octets), specifying the maximal packet's length in octets the
receiver of that packet can send on the channel. The
sender_max_packet_length is always smaller than the free space of
the sender_window_length (the sender's "receive buffer").
source_address_machine and source_port
The "source_address_machine" MAY carry either the numeric IP
address or the domain name of the host from where the application
originates the data multiplexing request and the "source_port" is
the port on the host from where the connection originated.
destination_address_machine and destination_port
The "destination_address_machine" and "destination_port" specify
the TCP/IP host and port where the recipient should connect the
channel. The "destination_address_machine" MAY be either a domain
name or a numeric IP address.
The receiver decides whether it can open the channel, and replies
with one of the following messages:
Badra, et al. Expires October 30, 2011 [Page 5]
Internet-Draft MTA-TLS April 2011
struct {
uint8 type;
uint16 length;
opaque sender_channel_id[2];
opaque receiver_channel_id[2];
uint32 receiver_window_length;
uint32 receiver_max_packet_length;
} ChannelEstablishmentSuccess;
struct {
uint8 type;
uint16 length;
opaque sender_channel_id[2];
opaque error<0..2^16-6>;
} ChannelRequestEchec;
The "sender_channel_id" and "receiver_channel_id" are the same
generated during the channel establishment. The length conveys the
data length of the current packet.
The field "error" conveys a description of the error.
Each MTA-TLS channel has its identifier computed as:
channel_id = sender_channel_id + receiver_channel_id
Where "+" indicates concatenation.
Note: channel_id may be susceptible to collisions. The receiver
needs to take care not to choose a "receiver_channel_id" to avoid any
collide with any of the established channel identifiers.
2.1.2. Closing Channels
The following packet MAY be sent to notify the receiver that the
sender will not send any more data on this channel and that any data
received after a closure request will be ignored. The sender of the
closure request MAY close its "receive buffer" without waiting for
the receiver's response. However, the receiver MUST respond with a
confirmation of the closure and close down the channel immediately,
discarding any pending writes.
Badra, et al. Expires October 30, 2011 [Page 6]
Internet-Draft MTA-TLS April 2011
struct {
uint8 type;
uint16 length;
opaque channel_id[4];
} ChannelCloseRequest;
struct {
uint8 type;
uint16 length;
opaque channel_id[4];
} ChannelCloseConfirmation;
The above two packets can be sent even if no window space is
available.
2.2. MTA-TLS Flow Control
The structure of the MTA-TLS data packet is described below.
Each entity maintains its "max_packet_length" (that is originally
initialized during the channel establishment) to a value not bigger
than the free space of its "receive buffer". For each received
packet, the receiver MUST subtract the packet's length from the free
space of its "receive buffer". For each transmitted packet, the
sender MUST subtract the packet's length from the free space of its
"send buffer". In any case, the result is always positive.
If the entity is willing to notify the other side about any change in
the "max_packet_length", the entity MUST send a NewMaxPacketLength
conveying the new "max_packet_length" that MUST be smaller than the
free space of the entity's "receive buffer"
The free space of the "receive buffer" of the sender (resp. the
receiver) MAY increase in length. The sender SHOULD send an
Acknowledgment packet to inform the receiver about this increase,
allowing this latter to send more packets but with length smaller or
equal than the minimum of the "max_packet_length" and the "receive
buffer" of the sender.
If the length of the "receive buffer" does not change, the
Acknowledgment packet will never be sent.
In the case where the "receive buffer" of an entity fills up, the
other entity MUST wait for an Acknowledgment packet before sending
any more MTATLSPlaintext packets.
Badra, et al. Expires October 30, 2011 [Page 7]
Internet-Draft MTA-TLS April 2011
struct {
uint8 type;
uint32 length;
opaque channel_id[4];
opaque data[MTATLSPlaintext.length];
} MTATLSPlaintext;
struct {
uint8 type;
uint16 length;
opaque channel_id[4];
uint32 max_packet_length;
/* the max_packet_length of the sender of that packet */
} NewMaxPacketLength;
struct {
uint8 type;
uint16 length;
opaque channel_id[4];
uint32 free_space;
} Acknowledgment;
The Acknowledgment and NewMaxPacketLength packets can be sent even if
no window space is available.
The TLS Record Layer receives data from MTA-TLS, supposes it as
uninterpreted data and applies the fragmentation and the
cryptographic operations on it, as defined in [RFC5246].
Note: multiple MTA-TLS fragments MAY be coalesced into a single
TLSPlaintext record.
Received data is decrypted, verified, decompressed, and reassembled,
then delivered to MTA-TLS entity. Next, the MTA-TLS sends data to
the appropriate application using the channel identifier and the
length value.
2.3. MTA-TLS Message Types
This section defines the initial set of MTA-TLS Message Types used in
Request/Response exchanges. The Message Type field is one octet and
identifies the structure of an MTA-TLS Request or Response message.
The messages defined in this document are listed below. More Message
Types may be defined in future documents. The list of Message Types,
as defined through this document, is maintained by the Internet
Assigned Numbers Authority (IANA). Thus, an application needs to be
made to the IANA in order to obtain a new Message Type value. Since
Badra, et al. Expires October 30, 2011 [Page 8]
Internet-Draft MTA-TLS April 2011
there are subtle (and not-so-subtle) interactions that may occur in
this protocol between new features and existing features that may
result in a significant reduction in overall security, new values
SHALL be defined only through the IETF Review process specified in
[RFC5226].
ChannelEstablishmentRequest 1
ChannelEstablishmentSuccess 2
ChannelRequestEchec 3
ChannelCloseRequest 4
ChannelCloseConfirmation 5
MTATLSPlaintext 6
NewMaxPacketLength 7
Acknowledgment 8
Badra, et al. Expires October 30, 2011 [Page 9]
Internet-Draft MTA-TLS April 2011
3. Security Considerations
Security issues are discussed throughout this document and in
[RFC5246].
If a fatal error related to any channel of an arbitrary application
occurs, the secure session MUST NOT be resumed. This is logic since
the Record protocol does not distinguish between the MTA-TLS
channels. However, if an error occurs at the MTA-TLS layer, both
parties immediately close the related channel, but not the TLS
session (no alert of any type is sent by the TLS Record).
Badra, et al. Expires October 30, 2011 [Page 10]
Internet-Draft MTA-TLS April 2011
4. IANA Considerations
This section provides guidance to the IANA regarding registration of
values related to the TLS protocol.
There are name spaces that require registration: the
data_multiplexing extension and the MTA-TLS message types.
Message Types have a range from 1 to 255, of which 1-8 are to be
allocated for this document. Because a new Message Type has
considerable impact on interoperability, a new Message Type SHALL be
defined only through the IETF Review process specified in [RFC5226].
Badra, et al. Expires October 30, 2011 [Page 11]
Internet-Draft MTA-TLS April 2011
5. Acknowledgments
The authors appreciate Alfred Hoenes for his detailed review.
Badra, et al. Expires October 30, 2011 [Page 12]
Internet-Draft MTA-TLS April 2011
6. Contributors
TBC
Badra, et al. Expires October 30, 2011 [Page 13]
Internet-Draft MTA-TLS April 2011
7. Normative References
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Badra, et al. Expires October 30, 2011 [Page 14]
Internet-Draft MTA-TLS April 2011
Authors' Addresses
Mohamad Badra
CNRS/LIMOS Laboratory
Campus de cezeaux, Bat. ISIMA
Aubiere
France
Email: badra@isima.fr
Ibrahim Hajjeh
INEOVATION
Paris
France
Email: ibrahim.hajjeh@ineovation.fr
James Blaisdell
Mocana
San Francisco
USA
Email: JBlaisdell@mocana.com
Badra, et al. Expires October 30, 2011 [Page 15]
