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]