idnits 2.17.00 (12 Aug 2021) /tmp/idnits39123/draft-hardie-mdtls-session-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4347]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 18, 2010) is 4226 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 168, but not defined ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ted. Hardie 3 Internet-Draft Panasonic Wireless Research Lab 4 Intended status: Informational Jake. Khuon 5 Expires: April 21, 2011 October 18, 2010 7 Multipath DTLS Session Layer 8 draft-hardie-mdtls-session-00 10 Abstract 12 The Internet model has traditionally avoided the complication of an 13 explicit session layer, in favor of having applications and 14 transports divide the relevant work between them. While this has 15 been a successful strategy when the packet flows from two hosts all 16 take the same path, there may be advantages in using a session-layer 17 strategy when a host initiates related flows from multiple interfaces 18 in independent routing domains (e.g. a 3G or 4G interface and a WiFi 19 interface). This draft discusses an approach re-using the security 20 association mechanisms present in DTLS [RFC4347] to create a simple 21 session layer. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 21, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Why DTLS? . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Protocol Mechanics . . . . . . . . . . . . . . . . . . . . . . 3 66 3.1. Datagram Transport Layer Security (DTLS) 67 Client-Senders and Server-Receivers . . . . . . . . . . . . 3 68 3.2. Sequence and Epoch Number Management . . . . . . . . . . . 4 69 3.3. Cookie Management . . . . . . . . . . . . . . . . . . . . . 4 70 4. Messaging and Message Types . . . . . . . . . . . . . . . . . . 4 71 4.1. Session Setup . . . . . . . . . . . . . . . . . . . . . . . 4 72 4.1.1. The Prime Initiator . . . . . . . . . . . . . . . . . . 4 73 4.1.2. The Reuse Initiator . . . . . . . . . . . . . . . . . . 4 74 5. Traffic Profile . . . . . . . . . . . . . . . . . . . . . . . . 5 75 6. DTLS receiver behavior . . . . . . . . . . . . . . . . . . . . 5 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 79 10. Normative References . . . . . . . . . . . . . . . . . . . . . 6 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 82 1. Introduction 84 The Internet model has traditionally avoided the complication of an 85 explicit session layer, in favor of having applications and 86 transports divide the relevant work between them. While this has 87 been a successful strategy when the packet flows from two hosts all 88 take the same path, there may be advantages in using a session-layer 89 strategy when a host initiates related flows from multiple interfaces 90 in independent routing domains (e.g. a 3G or 4G interface and a WiFi 91 interface). This draft discusses an experimental approach re-using 92 the security association mechanisms present in DTLS [RFC4347] to 93 create a simple session layer. 95 2. Why DTLS? 97 DTLS uses a return routability check to avoid certain classes of 98 Denial of Service attacks. Essentially, it passes a cookie to a host 99 requesting a security association; only after it receives a request 100 containing this cookie does it move forward with an association. In 101 the current DTLS design, each cookie is designed to be used only 102 once, and the method for checking a cookie is entirely stateless. 103 But much the same design can be used to associate multiple inbound 104 flows with the same session; in this case the cookie identifies new 105 flows as being part of the same session. 107 Though the application data transmitted using DTLS is sent 108 unreliably, DTLS uses a simple retransmission-based mechanism to 109 create a reliable command channel. This command channel can be used 110 to manage the state machine across flows. The experiment conducted 111 locally explored some of those in detail, but that output will be 112 described in detail in a later report. 114 3. Protocol Mechanics 116 3.1. Datagram Transport Layer Security (DTLS) Client-Senders and 117 Server-Receivers 119 The transport mechanism is based on DTLS record flights. The Clien/ 120 Sender sends traffic from a single flight out multiple physical 121 interfaces, after a modified ClientHello confirms that multiple flows 122 can be aggregated by the receiver. The Server/Receiver of the 123 traffic creates a common queue for records received from all flows in 124 the session, which are read out by applications just as any other 125 DTLS data would be. 127 3.2. Sequence and Epoch Number Management 129 To enable reassembly of multiple transport packet streams at the 130 receiver side, packets from all flows in the session must include a 131 sequence and epoch number that originates from a single global number 132 space. 134 3.3. Cookie Management 136 All packets received by the DTLS server must appear as part of the 137 same session. For this reason, flows after the initial cookie 138 assignment reuse the same cookie. In this case, that cookie re-use 139 is a way of managing the association of multiple flows to a single 140 session. 142 4. Messaging and Message Types 144 4.1. Session Setup 146 A session may be composed of several DTLS flows. Before any data 147 traffic can be sent, the transport flows themselves must first be 148 negotiated and set up. Once all DTLS flows are set up, traffic can 149 be multiplexed across them. In order to set up these flows a series 150 of messages will be used to communicate between the DTLS clients and 151 servers. 153 The ClientHello message is used by the DTLS Client/Sender to begin 154 the DTLS handshake with the DTLS Server/Receiver. There are two 155 variants required by this proposal. 157 4.1.1. The Prime Initiator 159 This is sent by the first DTLS Client/Sender in a multisender client 160 array. This message is set to type [TBD] in the type field and has 161 an epoch and sequence set to zero. A successful ClientHello 162 negotiation of this type results in the sender receiving a cookie 163 which may be reused by later Client/Senders. 165 4.1.2. The Reuse Initiator 167 This is sent by subsequent DTLS senders in the array. It is set to a 168 type value of [TBD] and includes the session cookie received in the 169 Prime Initiator exchange. Its epoch should be the same as that set 170 at the end of the previous flow set-up and its sequence number should 171 be subsequent to the last sequence number used by the previous flow. 172 The DTLS Receiver/Server should not send back a new cookie in 173 response to this variant of the ClientHello. 175 5. Traffic Profile 177 Packets between the DTLS clients and the DTLS server appear to the 178 network as UDP traffic and could be marked by any QoS classes 179 available for UDP. 181 6. DTLS receiver behavior 183 The DTLS Receiver/Server sees all packets from the flows connected by 184 the initiating session cookie as part of the same session. All flows 185 share a single sequence number space. When packets are received from 186 any flow within the session, they can thus be correctly inserted into 187 the receiver-side queue in order. This does require mid-queue 188 insertion, with the resulting receiver-side costs. 190 7. IANA Considerations 192 This document makes no request of IANA. If the described mechanisms 193 were standardized, they would require registrations in the Extension 194 Type registry set up in RFC 5246 [RFC5246] . We note that there is 195 no private use space in this registry. 197 Note to RFC Editor: this section may be removed on publication as an 198 RFC. 200 8. Security Considerations 202 Since there are now multiple individual path carrying a portion of 203 the overall session flow, there is a greater possibility of an on- 204 path attacker disrupting the flow. The re-use of a return- 205 routability cookie for multiple flows also re-opens the possibility 206 of denial of service, though this can be handled in a variety of 207 ways. The easiest would likely be to introduce a limitation in the 208 number of flows eligible to re-use a cookie. More robust methods 209 requiring a double cookie (session cookie and return routability 210 check cookie) are also relatively easy to implement. 212 9. Acknowledgements 214 Some work in this area was funded by Panasonic's Next-Generation 215 Mobile Development Center, and Iishi Hidenori, Takei Ichiro, and 216 Sanda Takako of NMDC gave valuable feedback and encouragement. 217 Girish Kumar coded most of the DTLS aspects of the test system. Eric 218 Rescorla gave valuable early feedback. 220 10. Normative References 222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 223 Requirement Levels", BCP 14, RFC 2119, March 1997. 225 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 226 Security", RFC 4347, April 2006. 228 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 229 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 231 Authors' Addresses 233 Ted Hardie 234 Panasonic Wireless Research Lab 235 10900 Tantau Ave. 236 Cupertino, California 95014 237 USA 239 Phone: +1-408-628-5864 240 Email: ted.ietf@gmail.com 242 Jake Khuon 244 Email: khuon@neebu.net