[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                        Ted. Hardie
Internet-Draft                           Panasonic Wireless Research Lab
Intended status: Informational                               Jake. Khuon
Expires: April 21, 2011                                 October 18, 2010


                      Multipath DTLS Session Layer
                     draft-hardie-mdtls-session-00

Abstract

   The Internet model has traditionally avoided the complication of an
   explicit session layer, in favor of having applications and
   transports divide the relevant work between them.  While this has
   been a successful strategy when the packet flows from two hosts all
   take the same path, there may be advantages in using a session-layer
   strategy when a host initiates related flows from multiple interfaces
   in independent routing domains (e.g. a 3G or 4G interface and a WiFi
   interface).  This draft discusses an approach re-using the security
   association mechanisms present in DTLS [RFC4347] to create a simple
   session layer.

Requirements Language

   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 RFC 2119 [RFC2119].

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 April 21, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the



Hardie & Khuon           Expires April 21, 2011                 [Page 1]


Internet-Draft                    MDTLS                     October 2010


   document authors.  All rights reserved.

   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
   2.  Why DTLS? . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Protocol Mechanics  . . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Datagram Transport Layer Security (DTLS)
           Client-Senders and Server-Receivers . . . . . . . . . . . . 3
     3.2.  Sequence and Epoch Number Management  . . . . . . . . . . . 4
     3.3.  Cookie Management . . . . . . . . . . . . . . . . . . . . . 4
   4.  Messaging and Message Types . . . . . . . . . . . . . . . . . . 4
     4.1.  Session Setup . . . . . . . . . . . . . . . . . . . . . . . 4
       4.1.1.  The Prime Initiator . . . . . . . . . . . . . . . . . . 4
       4.1.2.  The Reuse Initiator . . . . . . . . . . . . . . . . . . 4
   5.  Traffic Profile . . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  DTLS receiver behavior  . . . . . . . . . . . . . . . . . . . . 5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   10. Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6


















Hardie & Khuon           Expires April 21, 2011                 [Page 2]


Internet-Draft                    MDTLS                     October 2010


1.  Introduction

   The Internet model has traditionally avoided the complication of an
   explicit session layer, in favor of having applications and
   transports divide the relevant work between them.  While this has
   been a successful strategy when the packet flows from two hosts all
   take the same path, there may be advantages in using a session-layer
   strategy when a host initiates related flows from multiple interfaces
   in independent routing domains (e.g. a 3G or 4G interface and a WiFi
   interface).  This draft discusses an experimental approach re-using
   the security association mechanisms present in DTLS [RFC4347] to
   create a simple session layer.


2.  Why DTLS?

   DTLS uses a return routability check to avoid certain classes of
   Denial of Service attacks.  Essentially, it passes a cookie to a host
   requesting a security association; only after it receives a request
   containing this cookie does it move forward with an association.  In
   the current DTLS design, each cookie is designed to be used only
   once, and the method for checking a cookie is entirely stateless.
   But much the same design can be used to associate multiple inbound
   flows with the same session; in this case the cookie identifies new
   flows as being part of the same session.

   Though the application data transmitted using DTLS is sent
   unreliably, DTLS uses a simple retransmission-based mechanism to
   create a reliable command channel.  This command channel can be used
   to manage the state machine across flows.  The experiment conducted
   locally explored some of those in detail, but that output will be
   described in detail in a later report.


3.  Protocol Mechanics

3.1.  Datagram Transport Layer Security (DTLS) Client-Senders and
      Server-Receivers

   The transport mechanism is based on DTLS record flights.  The Clien/
   Sender sends traffic from a single flight out multiple physical
   interfaces, after a modified ClientHello confirms that multiple flows
   can be aggregated by the receiver.  The Server/Receiver of the
   traffic creates a common queue for records received from all flows in
   the session, which are read out by applications just as any other
   DTLS data would be.





Hardie & Khuon           Expires April 21, 2011                 [Page 3]


Internet-Draft                    MDTLS                     October 2010


3.2.  Sequence and Epoch Number Management

   To enable reassembly of multiple transport packet streams at the
   receiver side, packets from all flows in the session must include a
   sequence and epoch number that originates from a single global number
   space.

3.3.  Cookie Management

   All packets received by the DTLS server must appear as part of the
   same session.  For this reason, flows after the initial cookie
   assignment reuse the same cookie.  In this case, that cookie re-use
   is a way of managing the association of multiple flows to a single
   session.


4.  Messaging and Message Types

4.1.  Session Setup

   A session may be composed of several DTLS flows.  Before any data
   traffic can be sent, the transport flows themselves must first be
   negotiated and set up.  Once all DTLS flows are set up, traffic can
   be multiplexed across them.  In order to set up these flows a series
   of messages will be used to communicate between the DTLS clients and
   servers.

   The ClientHello message is used by the DTLS Client/Sender to begin
   the DTLS handshake with the DTLS Server/Receiver.  There are two
   variants required by this proposal.

4.1.1.  The Prime Initiator

   This is sent by the first DTLS Client/Sender in a multisender client
   array.  This message is set to type [TBD] in the type field and has
   an epoch and sequence set to zero.  A successful ClientHello
   negotiation of this type results in the sender receiving a cookie
   which may be reused by later Client/Senders.

4.1.2.  The Reuse Initiator

   This is sent by subsequent DTLS senders in the array.  It is set to a
   type value of [TBD] and includes the session cookie received in the
   Prime Initiator exchange.  Its epoch should be the same as that set
   at the end of the previous flow set-up and its sequence number should
   be subsequent to the last sequence number used by the previous flow.
   The DTLS Receiver/Server should not send back a new cookie in
   response to this variant of the ClientHello.



Hardie & Khuon           Expires April 21, 2011                 [Page 4]


Internet-Draft                    MDTLS                     October 2010


5.  Traffic Profile

   Packets between the DTLS clients and the DTLS server appear to the
   network as UDP traffic and could be marked by any QoS classes
   available for UDP.


6.  DTLS receiver behavior

   The DTLS Receiver/Server sees all packets from the flows connected by
   the initiating session cookie as part of the same session.  All flows
   share a single sequence number space.  When packets are received from
   any flow within the session, they can thus be correctly inserted into
   the receiver-side queue in order.  This does require mid-queue
   insertion, with the resulting receiver-side costs.


7.  IANA Considerations

   This document makes no request of IANA.  If the described mechanisms
   were standardized, they would require registrations in the Extension
   Type registry set up in RFC 5246 [RFC5246] .  We note that there is
   no private use space in this registry.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


8.  Security Considerations

   Since there are now multiple individual path carrying a portion of
   the overall session flow, there is a greater possibility of an on-
   path attacker disrupting the flow.  The re-use of a return-
   routability cookie for multiple flows also re-opens the possibility
   of denial of service, though this can be handled in a variety of
   ways.  The easiest would likely be to introduce a limitation in the
   number of flows eligible to re-use a cookie.  More robust methods
   requiring a double cookie (session cookie and return routability
   check cookie) are also relatively easy to implement.


9.  Acknowledgements

   Some work in this area was funded by Panasonic's Next-Generation
   Mobile Development Center, and Iishi Hidenori, Takei Ichiro, and
   Sanda Takako of NMDC gave valuable feedback and encouragement.
   Girish Kumar coded most of the DTLS aspects of the test system.  Eric
   Rescorla gave valuable early feedback.



Hardie & Khuon           Expires April 21, 2011                 [Page 5]


Internet-Draft                    MDTLS                     October 2010


10.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.


Authors' Addresses

   Ted Hardie
   Panasonic Wireless Research Lab
   10900 Tantau Ave.
   Cupertino, California  95014
   USA

   Phone: +1-408-628-5864
   Email: ted.ietf@gmail.com


   Jake Khuon

   Email: khuon@neebu.net
























Hardie & Khuon           Expires April 21, 2011                 [Page 6]