idnits 2.17.00 (12 Aug 2021)
/tmp/idnits36346/draft-huitema-tls-dtls-as-subtransport-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 document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 118: '... The keywords MUST, MUST NOT, REQUIR...'
RFC 2119 keyword, line 119: '... SHOULD NOT, RECOMMENDED, MAY, and O...'
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (March 5, 2015) is 2627 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147)
== Outdated reference: draft-ietf-tls-tls13 has been published as RFC 8446
Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group C. Huitema
3 Internet-Draft Microsoft
4 Intended status: Informational E. Rescorla
5 Expires: September 6, 2015 Mozilla
6 J. Iyengar
7 Google
8 March 5, 2015
10 DTLS as Subtransport protocol
11 draft-huitema-tls-dtls-as-subtransport-00.txt
13 Abstract
15 The developers of "user level" transports will benefit from a
16 standard implementation of authentication and encryption. This can
17 be achieved using DTLS as a sub-transport. Using DTLS enables
18 developers to benefit from the investment in TLS, and removes the
19 burden and the risks of re-creating similar technology.
21 There are several requirements to ensure that DTLS is a suitable sub-
22 transport: zero RTT setup, low overhead, and DOS prevention. The IAB
23 SEMI workshop outlined other potential requirements: start/stop
24 indication, and ability to accept indications from the network. The
25 draft presents guidelines for meeting these requirements in a new
26 version of DTLS.
28 Status of This Memo
30 This Internet-Draft is submitted in full conformance with the
31 provisions of BCP 78 and BCP 79.
33 Internet-Drafts are working documents of the Internet Engineering
34 Task Force (IETF). Note that other groups may also distribute
35 working documents as Internet-Drafts. The list of current Internet-
36 Drafts is at http://datatracker.ietf.org/drafts/current/.
38 Internet-Drafts are draft documents valid for a maximum of six months
39 and may be updated, replaced, or obsoleted by other documents at any
40 time. It is inappropriate to use Internet-Drafts as reference
41 material or to cite them other than as "work in progress."
43 This Internet-Draft will expire on September 6, 2015.
45 Copyright Notice
47 Copyright (c) 2015 IETF Trust and the persons identified as the
48 document authors. All rights reserved.
50 This document is subject to BCP 78 and the IETF Trust's Legal
51 Provisions Relating to IETF Documents
52 (http://trustee.ietf.org/license-info) in effect on the date of
53 publication of this document. Please review these documents
54 carefully, as they describe your rights and restrictions with respect
55 to this document. Code Components extracted from this document must
56 include Simplified BSD License text as described in Section 4.e of
57 the Trust Legal Provisions and are provided without warranty as
58 described in the Simplified BSD License.
60 Table of Contents
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
63 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
64 2. DTLS as a sub transport . . . . . . . . . . . . . . . . . . . 3
65 3. Efficient retransmissions . . . . . . . . . . . . . . . . . . 4
66 4. Zero-RTT with TLS/1.3 . . . . . . . . . . . . . . . . . . . . 5
67 5. Overhead reduction . . . . . . . . . . . . . . . . . . . . . 5
68 6. DOS resilience . . . . . . . . . . . . . . . . . . . . . . . 6
69 7. Connection-id option . . . . . . . . . . . . . . . . . . . . 7
70 8. Start/stop indication . . . . . . . . . . . . . . . . . . . . 7
71 9. Indication verification . . . . . . . . . . . . . . . . . . . 8
72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
74 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
76 13.1. Normative References . . . . . . . . . . . . . . . . . . 10
77 13.2. Informative References . . . . . . . . . . . . . . . . . 10
78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
80 1. Introduction
82 There is a growing demand to develop "user level" transport,
83 motivated by "innovation" and "deployment." The innovation part is
84 the desire to get better performance than TCP, or especially the
85 combination of TCP and TLS, addressing such issues as zero-RTT setup
86 or head of queue blocking. The deployment part is motivated by
87 observation that platform upgrades are slow, and typically only reach
88 a fraction of the deployed systems. The proposed solution is to
89 execute the transport functions in user space, so the transport
90 innovation can be distributed with application updates.
92 Any transport innovation has to work on top of an encryption layer.
93 This is good security practice, and it also prevent middleboxes from
94 interfering with the transport functions. This interference with TCP
95 is widespread and effectively blocks innovation, making it hard to
96 deploy even something as simple as ECN. Encryption prevents the
97 middle boxes from twiddling bits in the header. For example,
98 Google's QUIC [QUICBLOG]. protocol uses an encryption system that is
99 tightly integrated with the transport layer in order to optimize
100 performance and reduce the protocol's accessibility to middleboxes.
102 QUIC uses a specially designed security layer, but there was a
103 consensus in the IAB SEMI workshop [IABSEMI] that we don't want
104 multiple applications each designing their specific key exchange and
105 encryption algorithms. The natural solution is to base the end-to-
106 end transports on a standard security layer, allowing transport
107 specialists can worry about efficient retransmission, congestion and
108 multiplexing, while security specialists can implement the security
109 layer.
111 The obvious candidate is DTLS [RFC6347], as the general idea of "TLS
112 over UDP" allows us to reuse the TLS experience and the TLS
113 implementations. Of course, we may need to work on a new features to
114 meet transport requirements.
116 1.1. Requirements
118 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
119 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
120 document, are to be interpreted as described in [RFC2026].
122 2. DTLS as a sub transport
124 Examination of DTLS to the requirements for a subtransport layer
125 reveals some areas for improvement.
127 Efficient retransmissions: Part of the rationale for doing new
128 transports is to explore efficient retransmission strategies, but
129 this conflicts with the existing retransmission procedures that
130 are embedded in standard DTLS.
132 Zero-RTT setup: DTLS/1.2's minimum connection setup requires 1-RTT.
133 One of the major performance targets for new transports is low-
134 latency, motivating a 0-RTT connection setup.
136 Low overhead: DTLS/1.2 record headers include elements like version
137 number, epoch, sequence number or clear text length that cause a
138 fair bit of overhead in a small UDP datagram. Using some form of
139 header compression would reduce that overhead.
141 DOS prevention: TLS over UDP offers a big surface area for DOS
142 attacks, as unauthenticated clients can ask a server to perform
143 expensive crypto or produce large responses. This is especially
144 true if we support 0-RTT. While DTLS has some defenses against
145 DoS attacks, they may need to be strengthened.
147 connection-id: DTLS/1.2 identifies connections using the 5 tuple.
148 Having an independent ID would allow for functionalities similar
149 to "TCP multipath." It would also facilitate the work of load
150 balancers in front of a server farm.
152 Discussions in the IAB SEMI workshop also pointed out that
153 middleboxes interaction would be easier to manage if the UDP
154 transport had some specific properties:
156 Start/stop: Many middleboxes need to assign state to UDP flows. For
157 example, NATs need to assign and maintain port mappings. UDP
158 flows do not have explicit beginning and end markers similar to
159 TCP SYN/FIN/RST flags. In the absence of such flags middleboxes
160 have to resort to timer based management. This in turn forces
161 applications to use periodic "keep alive" traffic, which is
162 inefficient.
164 Indication verification: Middleboxes may wish to send informative
165 messages similar to ICMP, providing for example indications about
166 MTU size or congestion state. Application that receive these
167 messages need to differentiate between legitimate data coming from
168 network elements "on the path" and fake signals coming from
169 attackers. This is easier if the messages coming from the network
170 can copy hard to predict header elements like connection-id or
171 sequence numbers.
173 It is not yet clear whether these features are feasible or
174 deployable, but we document them here as an outcome of the IAB SEMI
175 discussion.
177 3. Efficient retransmissions
179 Protocols like QUIC implement innovative retransmission strategies,
180 combining Forward Error Correction with selective acknowledgements
181 and selective retransmissions. DTLS implements a minimalist
182 retransmission strategy for the messages that are part of the
183 handshake protocol, as explained in section 3.2 of [RFC6347]. This
184 creates a tension between adhering to the standard and efficient
185 retransmission:
187 o One could keep the QUIC retransmission for the handshake packets
188 and switch to an innovative transport for the reminder of the
189 connection. The downside is that using less efficient transport
190 during the handshake risk can cause additional latency, which is
191 contrary to the objective of transport innovation.
193 o One could design an innovative transmission as a layer under the
194 TLS framing, effectively redesign the layering of DTLS. This
195 solves the efficiency issues, but expose the clear-text
196 transmission controls to interference by middle-boxes, which may
197 ultimately prevent innovation.
199 o One could consider a hybrid design that allows clear text
200 innovation for the initial handshake and encrypted innovation for
201 data retransmissions, but no such design is available yet.
203 To put it simply, there is no consensus yet on a good solution to
204 this problem.
206 4. Zero-RTT with TLS/1.3
208 Probably the biggest requirement is to have a 0-RTT connection setup,
209 meaning that the initiator (typically the "client") can start sending
210 protected upper-level data in its initial flight of datagrams. In
211 general, a 0-RTT handshake requires that both the client and server
212 retain state:
214 o The client must retain the server's parameters, including a long-
215 term cryptographic key.
217 o The server must retain enough state to detect replays of the
218 client's initial flight.
220 In DTLS 1.2 and before, the client and server are both assumed to be
221 naive and so the first round-trip is used to establish this state.
222 This is still necessary for situations where the client and server
223 have never talked before and have no out-of-band communications
224 channel, but if both sides are primed, it is possible to define a
225 0-RTT handshake as well. Such a mode will be part of (D)TLS 1.3 and
226 is currently under development in the TLS WG.
228 5. Overhead reduction
230 DTLS is not generally very aggressive about conserving per-packet
231 overhead. The minimum DTLS record adds 13 bytes of header to the
232 packet and the common AES-GCM cipher suites add another 8 bytes or a
233 total of 21 bytes of header overhead (plus the authentication tag,
234 which is required). While these header bytes are not entirely
235 redundant (for instance, the sequence number allows the receiver to
236 deal with reordered packets) they are largely redundant in the common
237 case where the network mostly delivers packets in order essentially
238 every record is application data.
240 For maximum efficiency, it is desirable to have a mechanism for
241 compressing this data. [I-D.modadugu-dtls-short] describes one set
242 of techniques for doing so, though research into the optimal method
243 is still required.
245 6. DOS resilience
247 Our principal DoS concerns are:
249 o Preventing resource over-consumption on the server.
251 o Preventing the server from being used as a traffic amplifier.
253 Because TLS runs over TCP, it inherits TCP's DoS resistance
254 properties: an attacker must first establish a TCP connection before
255 he can talk to the TLS implementation. This generally means
256 demonstrating that he can receive traffic at the IP address he is
257 sending from. This significantly reduces the risk of amplification
258 and allows the server to differentially throttle traffic from clients
259 which appear to be sending bogus handshakes. The result is partial
260 protection against resource consumption attacks, but an attacker can
261 still mount such attacks if they control a large number of IP
262 addresses.
264 Any protocol which runs directly over UDP -- as DTLS does -- not
265 inherit these properties. DTLS already has anti-DoS measures in the
266 form of a cookie exchange which allows the server to force the client
267 to prove reachability at a given address. This is the standard
268 technique for addressing resource consumption attacks with such
269 protocols and can be deployed differentially (i.e., only when under
270 attack) to reduce the latency impact at normal times. Other
271 techniques which have been proposed for (D)TLS include computational
272 puzzles.
274 The DTLS cookie exchange also prevents amplification attacks but
275 because the server does not generally know when it is being used in
276 this fashion, it is harder to know where to set the protection/
277 latency tradeoff. It is currently unclear how important
278 amplification protection is (DNS already has significant
279 amplification vectors) but if so, possible techniques include longer-
280 term cookies and forcing the client to pad its initial flight, thus
281 reducing the impact of amplification.
283 7. Connection-id option
285 Many UDP applications identify the application connection implicitly
286 from the "five tuple" of source and destination addresses and ports,
287 and payload type. There are however several potential advantages to
288 having an explicit "connection-id:"
290 o Enabling applications to use several ports and path in parallel,
291 for performance or resiliency,
293 o Enabling seamless continuation of an application over a new port
294 if the preceding port becomes unusable.
296 The latter problem, ports becoming unusable, is often caused by NAT
297 traversal. NAT are known to forget UDP mappings if they don't see
298 traffic for some period, or for some other reason such as for example
299 hash table collision. Applications must be ready to quickly
300 reestablish their connectivity. Using an explicit connection-id
301 makes this reestablishment straighforward.
303 The connection-id could be encoded as a header parameter, and its use
304 negotiated during the initial handshake, using techniques similar to
305 the parameters negotiation proposed in [I-D.modadugu-dtls-short].
307 8. Start/stop indication
309 Middleboxes like NAT or firewall assign some state to the UDP flows,
310 such as for example a port mapping in a NAT or an explicit port
311 opening in a firewall. For TCP flows, middleboxes can examine TCP
312 flags and deduce when they see FIN or RST flags that the connection
313 is getting closed. They can then free the state associated with the
314 TCP flow. There are no such flags in UDP packets. The start of a
315 flow can be deduced implicitly from the arrival of a first packet for
316 that flow, but the end cannot. Middleboxes have to resort to timer
317 based management. The timers have to be short, and this drives
318 applications to send frequent keep-alive packets to make sure that
319 port mappings and port opening persists. An explicit indication
320 would enable more efficient management of resource.
322 TLS and DTLS include an explicit close mechanism, in which the
323 parties use the TLS Alert protocol and exchange "close notify"
324 messages. Sending such an alert message indicates that the sending
325 party is done, and will not send any more messages in the TLS
326 session. When both parties have sent a "close notify" message, the
327 session is effectively terminated.
329 If a middlebox could monitor the transmission of "close notify"
330 messages, it could effectively decide when resource can be disposed.
332 However, the alert protocol is part of the encrypted payload, and the
333 only visible indication in the clear text header is a "Content type"
334 indication set to "Alert", indicating that the encrypted payload
335 contains an Alert message. Closure indication is only one of the
336 usages of the Alert protocol, the other usages being error indication
337 and warning indication. A middlebox that monitors Alert messages
338 will only get an imperfect indication of the connection state:
340 o A closure message indicates that one party has finished sending,
341 and waits until a similar closure message from the other end to
342 terminate the session,
344 o An error message indicates that one party detected an error, will
345 not send any more data, and will not accept any more data from the
346 other party,
348 o A warning message indicates that one party detected an anomaly,
349 but that the session can continue.
351 The middlebox can gain information about the state of a DTLS
352 connection by monitoring the Alert messages, even if that information
353 is imperfect. Alternatively, we could consider adding an explicit
354 FIN bit in a revised clear-text header.
356 We should note here that there is a potential tension between the
357 management of resource and the identification of sessions discussed
358 in Section 7. The use of the context identifier allows sessions to
359 spread over multiple addresses and ports, and also allows multiple
360 sessions to share the same addresses and ports. If such multiplexing
361 is in place, the middleboxes would have to allocate resources per
362 context rather than per address and port tuples, but would have no
363 guarantee to see all the alert messages for a specific session.
365 9. Indication verification
367 Middleboxes could send messages to applications, using ICMP or
368 perhaps simply sending UDP messages using the same five-tuple as the
369 application. Assuming that such messages can be delivered, the
370 application will have to verify that they come from a legitimate
371 source, for example a middlebox on the path providing an indication
372 about acceptable MTU.
374 There is always a risk that such indications will be misused, and
375 that malevolent third parties would try to provide false indications
376 in order to disrupt the application. The application must thus be
377 able to distinguish between legitimate and spurious indication.
379 The middlebox could echo some parameters of the clear text header in
380 order to "prove" that they are on path. Typical parameters would be
381 the context ID or the sequence numbers. For this to be effective,
382 these parameters should be "hard to guess," which implies for example
383 unpredictable assignment of context ID or initial sequence numbers.
384 Of course, such desire for unpredictability conflicts with the desire
385 for low overhead, as compressed headers are inherently easier to
386 predict than long numbers.
388 One question for any indication verification scheme is how much of
389 the connection the middlebox needs to be able to see. For instance,
390 if initial sequence numbers or DTLS handshake nonces are used to
391 demonstrate that the middlebox is on-path, then the middlebox needs
392 to be on-path for the entire connection and maintain connection
393 state.
395 10. Security Considerations
397 This document proposes that user level transports use DTLS as a
398 component, instead of inventing their own transport. We believe that
399 this componentized approach will avoid many of the pitfalls of
400 inventing or implementing special purpose security designs. Instead,
401 applications will benefit from the experience accured in the design
402 and evolution of TLS [RFC5246] and will be able to reuse already
403 developed TLS and DTLS implementations.
405 We note that there is a definitive DOS exposure when running a
406 cryptographic protocol over UDP, and that this exposure is increased
407 when we attempt to enable zero RTT setup. The risk and the
408 corresponding mitigations are described in Section 6. Here again, we
409 believe that it is beneficial to reuse the DOS mitigations developed
410 for DTLS and designed for the zero RTT setup options of TLS/1.3
411 [I-D.ietf-tls-tls13].
413 Any start/stop mechanism solving the requirement presented in
414 Section 8 opens the door to an attack is similar to but distinct from
415 TCP RST attacks, where injected RST packets terminate connections.
416 An on path attacker could inject bogus packets with a "Stop"
417 indication, to cause connection state to be torn down at middleboxes,
418 potentially causing the connection to be abruptly terminated. The
419 middleboxes will not be able to separate these injected packets from
420 legitimate "Stop" packets sent by the endpoints, because they cannot
421 verify the end-to-end authentication of packets.
423 Participants to the SEMI workshop [IABSEMI] envisage a "path to
424 application" messaging system in which intermediate relays would
425 provide information to the application, such as for example MTU size
426 or congestion notification. Such messages would not benefit from the
427 end to end authentication and encryption provided by DTLS. Allowing
428 such messages exposes the application to denial of service attacks.
429 Some potential mitigations are described in Section 9
431 11. IANA Considerations
433 This draft references [I-D.modadugu-dtls-short], which proposed four
434 new extensions for DTLS. A future version of this draft will very
435 likely propose the registration of similar extensions, using the
436 mechanisms defined in [RFC5246] and [RFC6066].
438 12. Acknowledgments
440 The inspiration for this draft came from discussions in the IAB SEMI
441 workshop, and from studies of the QUIC protocol.
443 13. References
445 13.1. Normative References
447 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
448 3", BCP 9, RFC 2026, October 1996.
450 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
451 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
453 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
454 Extension Definitions", RFC 6066, January 2011.
456 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
457 Security Version 1.2", RFC 6347, January 2012.
459 13.2. Informative References
461 [I-D.ietf-tls-tls13]
462 Dierks, T. and E. Rescorla, "The Transport Layer Security
463 (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-04 (work
464 in progress), January 2015.
466 [I-D.modadugu-dtls-short]
467 Modadugu, N. and E. Rescorla, "Extensions for Datagram
468 Transport Layer Security (TLS) in Low Bandwidth
469 Environments", draft-modadugu-dtls-short-00 (work in
470 progress), March 2006.
472 [IABSEMI] Kuehlewind, M. and B. Trammell, "IAB Workshop on Stack
473 Evolution in a Middlebox Internet (SEMI)", Jan 2015,
474 .
476 [QUICBLOG]
477 Roskind, J., "Experimenting with QUIC", June 2013,
478 .
481 Authors' Addresses
483 Christian Huitema
484 Microsoft
486 Email: huitema@microsoft.com
488 Eric Rescorla
489 Mozilla
491 Email: ekr@rtfm.com
493 Jana Iyengar
494 Google
496 Email: jri@google.com