idnits 2.17.1 draft-mentz-ipfix-dtls-recommendations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2009) is 5398 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3758' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'RFC4960' is defined on line 310, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) == Outdated reference: A later version (-02) exists of draft-seggelmann-tls-dtls-heartbeat-00 == Outdated reference: A later version (-02) exists of draft-seggelmann-tls-dtls-heartbeat-00 -- Duplicate reference: draft-seggelmann-tls-dtls-heartbeat, mentioned in 'I-D.ietf-tsvwg-dtls-for-sctp', was also mentioned in 'I-D.seggelmann-tls-dtls-heartbeat'. == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-sctpsocket-19 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Flow Information Export WG D. Mentz 3 Internet-Draft G. Muenz 4 Intended status: Informational L. Braun 5 Expires: January 7, 2010 TU Muenchen 6 July 6, 2009 8 Recommendations for Implementing IPFIX over DTLS 9 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 7, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document discusses problems and solutions regarding the 48 implementation of the IPFIX protocol over SCTP and DTLS. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Issues and Recommendations Regarding IPFIX over DTLS/UDP . . . 3 57 3.1. Undetected Collector Crashes . . . . . . . . . . . . . . . 3 58 3.2. Possible Solutions . . . . . . . . . . . . . . . . . . . . 4 60 4. Issues and Recommendations Regarding IPFIX over DTLS/SCTP . . . 6 61 4.1. Renegotiation for DTLS and SCTP-AUTH . . . . . . . . . . . 6 62 4.2. Possible Solutions . . . . . . . . . . . . . . . . . . . . 7 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 70 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 All implementations of the IPFIX protocol conforming to [RFC5101] 77 must support DTLS [RFC4347] if SCTP or UDP is used as transport 78 protocol. 80 This document discusses specific issues that have arisen during the 81 implementation of the IPFIX protocol over DTLS. These issues may 82 degrade the performance of an IPFIX Exporter as they require to 83 periodically interrupt the data export. As a solution, we proposes 84 workarounds which solve these problems without requiring any changes 85 to DTLS and the IPFIX protocol. 87 This document is to be considered as a possible update of the IPFIX 88 Implementation Guidelines [RFC5153]. 90 2. Terminology 92 This document adopts the IPFIX terminology used in [RFC5101]. As in 93 all IPFIX document, all IPFIX specific terms have the first letter of 94 a word capitalized when used in this document. 96 3. Issues and Recommendations Regarding IPFIX over DTLS/UDP 98 3.1. Undetected Collector Crashes 100 DTLS has been conceived for deployment on top of unreliable transport 101 protocols, such as UDP. Hence, it is able to cope with lost 102 datagrams and datagrams that arrive out of order at the receiver. In 103 contrast to UDP, which does not maintain any connection state, DTLS 104 has to maintain state across multiple datagrams at both endpoints. 105 This state is established during the DTLS handshake. 107 During the DTLS handshake, the two peers authenticate each other and 108 agree upon several parameters which are necessary to communicate over 109 DTLS. Among these parameters are a cipher suite as well as a shared 110 key that is usually established using a Diffie-Hellman key exchange. 111 If one of the peers crashes unexpectedly, these parameters as well as 112 the maintained DTLS state usually get lost. As a consequence, the 113 peer is not able to check the integrity of newly arrived datagrams or 114 to decrypted the datagrams' payload. 116 In the case of connection oriented transport protocols, such as TCP 117 or SCTP, a connection endpoint will be informed about the crash of 118 its correspondent by the transport protocol. UDP, however, is 119 connection less, which means that the crash of the receiver is not 120 noticed by the sender. There are situations in which the sender 121 might receive ICMP messages that indicate that the receiver is 122 experiencing problems, but there is no guarantee that those ICMP 123 messages will be sent. As DTLS itself does not provide any 124 mechanisms for dead peer detection, the crash of one of the peers has 125 to be detected and handled by protocols in the upper layers. 127 As IPFIX is a unidirectional protocol, a conform implementation of an 128 IPFIX Exporter only sends but does not receive any data. Hence, the 129 Exporter cannot tell from the absence of returning traffic that the 130 Collector has crashed. Instead, the Exporter keeps on sending data 131 which must be discarded by the recovered Collector because the 132 information needed to check the integrity and to decrypt the data is 133 lost. 135 3.2. Possible Solutions 137 There are three options to circumvent this problem. 139 1. The first option is to let the Exporter periodically trigger 140 renegotiations on the DTLS layer. This means that both peers 141 have to participate in a new handshake, implying the exchange of 142 datagrams in both direction. Hence, due to a timeout, the 143 Exporter will notice that the Collector has crashed. 145 Under normal conditions, such a renegotiation is used to renew 146 the keying material in a long living connection. Depending on 147 whether a full or abbreviated handshake is carried out, such a 148 renegotiation can be very costly in terms of computational 149 overhead because it involves public key operations. In addition, 150 the DTLS specification [RFC4347] leaves open if application data 151 can be sent during the handshake or not. Typical 152 implementations, such as OpenSSL [OpenSSL], require that sending 153 data is interrupted until the handshake is finished. 154 Consequently, the export of IPFIX Messages must be stalled for at 155 least two round trip times, which could lead to IPFIX Messages 156 queuing up in the buffer of the Exporting Process and potential 157 loss of data. 159 The most substantial argument against this solution is that the 160 renegotiation was simply not conceived to serve as a dead peer 161 detection mechanism. To make sure that the Exporter learns 162 quickly about a crashed Collector, renegotiations would have to 163 be carried out in short intervals. 165 2. The authors of this draft endorse the second option which is to 166 periodically establish new DTLS connections and replace the 167 active DTLS connection by a new one. Establishing a new DTLS 168 connection involves a bidirectional handshake which requires both 169 peers to be alive. If the Collector crashes unexpectedly and 170 recovers quickly, then the time during which he receives 171 meaningless data is limited until a new DTLS connection is 172 established. Care should be taken that two successive 173 connections overlap in a way such that no data is lost at the 174 Exporting Process. This can be achieved by swapping the 175 connections only after all active templates have been sent out on 176 the new DTLS connection. 178 As regards the computational overhead, this solution suffers from 179 the same limitations as the first one. Every new DTLS connection 180 might involve costly public key operations and a small overhead 181 in terms of the transmitted data volume. However, public key 182 operations do not have to be carried out if the DTLS 183 implementations support a feature called session resumption which 184 allows the reuse of keying material from an earlier session. 185 This feature could also be used to simplify the renegotiation 186 proposed in the first solution. 188 The main advantage over periodical renegotiations is that this 189 solution does not suffer from the data stall that is due to the 190 fact that OpenSSL does not allow sending application data during 191 handshakes. IPFIX records can be transmitted without 192 interruption due to the overlap of the old and the new DTLS 193 connection. 195 From the point of view of IPFIX, every new DTLS connection 196 represents a new Transport Session. At the collector side, 197 however, it should be straight forward to associate the different 198 Transport Sessions to the same Exporter since the exporter IP 199 address remains the same. At the beginning of every new 200 Transport Session, not only all active Templates have to be sent, 201 but also certain Data Records defined by Option Templates. In 202 the case of UDP, however, this does not cause significant 203 additional overhead because Templates and Data Records defined by 204 Option Templates are periodically resent anyway. 206 3. A third alternative to detect a dead or recovered collector is to 207 implement the DTLS Heartbeat Extension which has been very 208 recently suggested in [I-D.seggelmann-tls-dtls-heartbeat]. This 209 DTLS extension allows detecting a dead peer without interfering 210 with the ongoing data transfer. The computational and bandwidth 211 overhead is negligible plus the data transmission does not stall. 213 The problems with this solution are that the necessary DTLS 214 extension has not yet been standardized and that there are 215 literally no implementations available at the time of writing. 217 4. Issues and Recommendations Regarding IPFIX over DTLS/SCTP 219 4.1. Renegotiation for DTLS and SCTP-AUTH 221 The DTLS binding for SCTP is more sophisticated than the DTLS/UDP 222 binding. This is due to the fact that SCTP provides a connection 223 oriented service to upper layers. It also carries additional data 224 items with each user message. Among those items are: 225 o stream ID 226 o payload protocol identifiers 228 DTLS only protects the bare user data. Without additional security 229 mechanisms, a man-in-the-middle attacker could easily tamper with the 230 stream ID or the payload protocol identifier. He could also defeat 231 SCTP's efforts to provide a reliable or partially reliable service by 232 forging SACK and Forward-TSN chunks. 234 The solution to this problem is SCTP-AUTH [RFC4895] which allows the 235 SCTP implementation to insert an authentication chunk which 236 authenticates certain types of subsequent chunks in the same packet 237 using a Hashed Message Authentication Code (HMAC). While SCTP-AUTH 238 allows for the negotiation of the hash algorithm it does not provide 239 means for secure key agreement. Therefore a cross layer approach is 240 used to extract keying material from the DTLS layer and use it on the 241 SCTP layer. This approach is described in 242 [I-D.ietf-tsvwg-dtls-for-sctp] and is readily available in OpenSSL. 244 Due to limitations of DTLS, no renegotiation (i.e., change of keying 245 material) can be performed without impeding the ongoing data 246 transfer. The implementation has to make sure that there is no data 247 in flight at the point in time that the keying material is swapped. 248 This means that data transfer on all streams has to stop before a 249 renegotiation can be initiated. Moreover, there must not be any 250 unacknowledged messages in the send buffers of the SCTP sockets. In 251 practice, the renegotiation has to wait until the SCTP sockets at 252 both endpoints return SCTP_SENDER_DRY_EVENT 253 [I-D.ietf-tsvwg-sctpsocket]. Only after the handshake has been 254 completed, the data transfer can continue because DTLS does not 255 guarantee the proper authentication and decryption of user messages 256 that were secured with outdated keying material. 258 In the case of IPFIX, this means that the Exporting Process has to 259 interrupt the export of IPFIX Messages for a certain period of time. 260 IPFIX Messages generated in the meantime have to be buffered or 261 dropped until the renegotiation is over. 263 4.2. Possible Solutions 265 To solve this problem of data stall, the authors of this draft 266 suggest to employ the same mechanism as in the UDP case, which is to 267 periodically establish a new DTLS/SCTP association between Exporter 268 and Collector in parallel to the existing one. Only after the 269 handshakes of SCTP and DTLS are completed and the IPFIX Templates are 270 sent on the new association, the Exporter starts sending Data Records 271 on the new Transport Session. 273 Again, the establishment of a new SCTP association represents a new 274 IPFIX Transport Session. Some overhead is produced because Templates 275 as well as certain Data Records defined by Option Template have to be 276 resent, which would not be necessary if the old Transport Session was 277 kept. However, the amount of additional data that has to be sent is 278 assumed to be rather small. 280 5. Security Considerations 282 The recommendations in this document do not introduce any additional 283 security issues to those already mentioned in [RFC5101]. 285 Appendix A. Acknowledgements 287 The authors thank Michael Tuexen and Robin Seggelmann for their 288 contribution on the standardization and implementation of DTLS for 289 SCTP as well as for their valuable advice regarding the 290 implementation of IPFIX over DTLS. 292 6. References 294 6.1. Normative References 296 [RFC5101] Claise, B., "Specification of the IP Flow Information 297 Export (IPFIX) Protocol for the Exchange of IP Traffic 298 Flow Information", RFC 5101, January 2008. 300 6.2. Informative References 302 [RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. 303 Aitken, "IP Flow Information Export (IPFIX) Implementation 304 Guidelines", RFC 5153, April 2008. 306 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 307 Conrad, "Stream Control Transmission Protocol (SCTP) 308 Partial Reliability Extension", RFC 3758, May 2004. 310 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 311 RFC 4960, September 2007. 313 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 314 Security", RFC 4347, April 2006. 316 [OpenSSL] "OpenSSL Cryptography and SSL/TLS Toolkit", 317 Homepage http://www.openssl.org/, 2009. 319 [I-D.seggelmann-tls-dtls-heartbeat] 320 Seggelmann, R., Tuexen, M., and M. Williams, "Datagram 321 Transport Layer Security Heartbeat Extension", 322 draft-seggelmann-tls-dtls-heartbeat-00 (work in progress), 323 July 2009. 325 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 326 "Authenticated Chunks for the Stream Control Transmission 327 Protocol (SCTP)", RFC 4895, August 2007. 329 [I-D.ietf-tsvwg-dtls-for-sctp] 330 Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 331 Transport Layer Security for Stream Control Transmission 332 Protocol", draft-seggelmann-tls-dtls-heartbeat-00 (work in 333 progress), October 2008. 335 [I-D.ietf-tsvwg-sctpsocket] 336 Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. 337 Lei, "Sockets API Extensions for Stream Control 338 Transmission Protocol (SCTP)", 339 draft-ietf-tsvwg-sctpsocket-19 (work in progress), 340 February 2009. 342 Authors' Addresses 344 Daniel Mentz 345 Technische Universitaet Muenchen 346 Department of Informatics 347 Chair for Network Architectures and Services (I8) 348 Boltzmannstr. 3 349 Garching D-85748 350 DE 352 Email: mentz@in.tum.de 353 Gerhard Muenz 354 Technische Universitaet Muenchen 355 Department of Informatics 356 Chair for Network Architectures and Services (I8) 357 Boltzmannstr. 3 358 Garching D-85748 359 DE 361 Phone: +49 89 289-18008 362 Email: muenz@net.in.tum.de 363 URI: http://www.net.in.tum.de/~muenz 365 Lothar Braun 366 Technische Universitaet Muenchen 367 Department of Informatics 368 Chair for Network Architectures and Services (I8) 369 Boltzmannstr. 3 370 Garching D-85748 371 DE 373 Phone: +49 89 289-18010 374 Email: braun@net.in.tum.de 375 URI: http://www.net.in.tum.de/~braun