idnits 2.17.1 draft-mentz-ipfix-dtls-recommendations-02.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 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.) ** The abstract seems to contain references ([RFC5153]), 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 date (March 14, 2011) is 4792 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3758' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'RFC4960' is defined on line 520, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-sctpsocket-27 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: September 15, 2011 TU Muenchen 6 March 14, 2011 8 Recommendations for Implementing IPFIX over DTLS 9 11 Abstract 13 This document discusses problems and solutions regarding the 14 implementation of the IPFIX protocol over DTLS. It updates the 15 "IPFIX Implementation Guidelines" [RFC5153]. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 15, 2011. 34 Copyright Notice 36 Copyright (c) 2011 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 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Issues and Recommendations Regarding IPFIX over DTLS/UDP . . . 4 56 3.1. Undetected Collector Crashes . . . . . . . . . . . . . . . 4 57 3.1.1. Problem Description . . . . . . . . . . . . . . . . . 4 58 3.1.2. Recommendation . . . . . . . . . . . . . . . . . . . . 5 59 3.1.3. Alternative Workarounds . . . . . . . . . . . . . . . 6 60 3.2. Incorrect Path MTU Values . . . . . . . . . . . . . . . . 7 61 3.2.1. Problem Description . . . . . . . . . . . . . . . . . 7 62 3.2.2. Recommendation . . . . . . . . . . . . . . . . . . . . 8 64 4. Issues and Recommendations Regarding IPFIX over DTLS/SCTP . . 9 65 4.1. SCTP-AUTH . . . . . . . . . . . . . . . . . . . . . . . . 9 66 4.2. Renegotiation for DTLS and SCTP-AUTH . . . . . . . . . . . 9 67 4.2.1. Problem Description . . . . . . . . . . . . . . . . . 9 68 4.2.2. Recommendation . . . . . . . . . . . . . . . . . . . . 10 70 5. Mutual Authentication via Pre-Shared Keys . . . . . . . . . . 10 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 78 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 All implementations of the IPFIX protocol conforming to [RFC5101] 85 must support DTLS [RFC4347] if SCTP or UDP is selected as IPFIX 86 transport protocol. This document discusses specific issues that 87 have arisen during the implementation of the IPFIX protocol over DTLS 88 (the source code of the implementation is available as part of 89 VERMONT [VERMONT]). 91 Section 3 discusses two issues which may lead to the loss of IPFIX 92 Messages if DTLS is used with UDP as transport protocol: unexpected 93 Collector crashes and wrong path MTU values. In the first case, the 94 data loss may even not be recognized by the Collector. By following 95 the recommendations of this document, these two problems can be 96 avoided. 98 Section 4 discusses one issue which corresponds to the implementation 99 of IPFIX over DTLS/SCTP. In this case, DTLS renegotiations require 100 the interruption of the data export for a short period of time, which 101 may lead to the queuing and potential loss of IPFIX Messages at the 102 Exporting Process. For Exporters that operate at a high data rate, 103 it is recommended to switch over to a newly established DTLS/SCTP 104 Transport Session instead of triggering DTLS renegotiation for an 105 existing Transport Session. 107 When the "IPFIX Implementation Guidelines" were published [RFC5153], 108 no implementation of IPFIX over DTLS/UDP or DTLS/SCTP actually 109 existed. Therefore, Sections 8.4 and 8.5 of [RFC5153] are incomplete 110 and do not cover the issues described in this document. Hence, the 111 recommendations of this document complement and update the "IPFIX 112 Implementation Guidelines" [RFC5153]. 114 Finally, Section 5 suggests to support the pre-shared key 115 ciphersuites for TLS for mutual authentication. These ciphersuites 116 can do without a public-key infrastructure (PKI) and can therefore 117 facilitate the setup of an environment with a limited number of IPFIX 118 devices. 120 2. Terminology 122 This document adopts the IPFIX terminology used in [RFC5101]. As in 123 all IPFIX documents, all IPFIX specific terms have the first letter 124 of a word capitalized when used in this document. 126 3. Issues and Recommendations Regarding IPFIX over DTLS/UDP 128 Regarding IPFIX over DTLS/UDP, [RFC5101] and [RFC5153] refer to 129 [RFC4347] which specifies the usage of DTLS over the transport 130 protocol UDP. [RFC5153] explains that Exporting Processes and 131 Collecting Processes should behave as if UDP without DTLS was 132 transport protocol. 134 During the implementation of IPFIX over DTLS/UDP, it turned out that 135 the specification of [RFC4347] is insufficient for IPFIX data export 136 because the loss of DTLS state at the Collecting Process may not be 137 detected by the Exporting Process. As a consequence, it remains 138 unnoticed that all further IPFIX Messages arriving at the Collecting 139 Process must be discarded. This issue as well as recommendations how 140 to solve it are discussed in Section 3.1. 142 For IPFIX export over UDP, [RFC5101] specifies that the total packet 143 size of IPFIX Messages must not exceed the path MTU (PMTU). Section 144 8.4 of [RFC5153] points out that DTLS introduces overhead which 145 affects the packet size. In fact, the utilization of DTLS affects 146 the packet size, yet it does not generally result in larger packet 147 sizes. In particular, if the IPFIX Message is compressed before 148 being encrypted, the size of the DTLS record is likely to be smaller 149 than the original IPFIX Message. However, since the compression 150 ratio cannot be predicted, it is save to make conservative 151 assumptions about the DTLS record size. 153 Another general problem regarding the utilization of UDP as transport 154 protocol is that the total packet size should not exceed 512 octets 155 if the PMTU is not available [RFC5101]. Since the PMTU is usually 156 larger than 512 octets, this limitation causes overhead due to 157 unnecessarily small IPFIX Messages. Hence, there is an interest to 158 provide the Exporting Process with a correct PMTU value. 160 If the PMTU is known, it can be configured by the user. Otherwise, 161 the PMTU can be determined by PMTU discovery mechanisms defined in 162 [RFC1191] and [RFC1981]. However, these mechanisms do not always 163 provide reliable results. Section 3.2 discusses this issue in more 164 detail and presents a better PMTU discovery mechanism for DTLS/UDP. 166 3.1. Undetected Collector Crashes 168 3.1.1. Problem Description 170 DTLS has been conceived for deployment on top of unreliable transport 171 protocols, such as UDP. Hence, the handshaking protocol of DTLS is 172 able to cope with lost datagrams and datagrams that arrive out of 173 order at the receiver. In contrast to UDP, which does not maintain 174 any connection state, DTLS has to maintain state across multiple 175 datagrams at both endpoints. This state is established and 176 initialized during the DTLS handshake [RFC4347]. 178 During the DTLS handshake, the two peers authenticate each other and 179 agree upon several parameters which are necessary to communicate over 180 DTLS. Among these parameters are a cipher suite as well as a shared 181 key that is usually established using a Diffie-Hellman key exchange. 182 If one of the peers crashes unexpectedly, these parameters as well as 183 the maintained DTLS state usually get lost. As a consequence, the 184 peer is not able to check the integrity of newly arrived datagrams or 185 to decrypted the datagrams' payload. 187 In the case of connection-oriented transport protocols, such as TCP 188 or SCTP, a connection endpoint will be informed about the crash of 189 its correspondent by the transport protocol. UDP, however, is 190 connection-less, which means that the crash of the receiver is not 191 noticed by the sender. There are situations in which the sender 192 might receive ICMP messages indicating that the receiver is 193 experiencing problems, for example if an ICMP port unreachable 194 message is returned because the UDP port is closed. However, there 195 is no guarantee that these ICMP messages will be sent. Also, 196 implementations should ignore these messages as they are not 197 authenticated and might therefore be forged. DTLS as specified in 198 [RFC4347] does not provide any mechanisms for dead peer detection, 199 thus the crash of one of the peers has to be detected and handled by 200 protocols in the upper layers. 202 As IPFIX is a unidirectional protocol, a conforming implementation of 203 an IPFIX Exporter only sends but does not receive any data. Hence, 204 the Exporter cannot tell from the absence of returning traffic that 205 the Collector has crashed. Instead, the Exporter keeps on sending 206 data which must be discarded by the recovered Collector because the 207 information needed to check the integrity and to decrypt the data is 208 lost. 210 3.1.2. Recommendation 212 The DTLS heartbeat extension which has been suggested in 213 [I-D.seggelmann-tls-dtls-heartbeat] allows a DTLS endpoint to detect 214 a dead peer. With this extension, each endpoint may transmit DTLS 215 heartbeat request messages to the other peer. Each peer is supposed 216 to send back a heartbeat response message for every heartbeat request 217 message it receives. As UDP provides unreliable transport, it may 218 happen that heartbeat request or response messages are lost. 219 Nevertheless, a peer can be declared dead if it fails to respond to a 220 certain number of consecutive heartbeat requests. 222 The computational and bandwidth overhead of the heartbeat messages is 223 very small. As another advantage, the exchange of heartbeat messages 224 does not affect the transport of user data. In particular, the 225 transport of user data does not have to be interrupted. 227 IPFIX Exporters and Collectors should support the DTLS heartbeat 228 extension to allow an Exporting Process to check whether the 229 Collecting Process is still able to decrypt the exported IPFIX 230 Messages. To detect a crashed Collector, the Exporting Process must 231 actively trigger the sending of a DTLS heartbeat request message. 232 This should be done on a regular basis (e.g., periodically). It must 233 be noted that a dead peer remains undetected in the time interval 234 between two successive heartbeat requests. 236 The only problem with this solution is that the DTLS heartbeat 237 extension has not yet been standardized. 239 3.1.3. Alternative Workarounds 241 If the DTLS heartbeat extension is not available, there exist two 242 workarounds which also enable the detection of a crashed Collector. 243 However, these approaches have several disadvantages compared to 244 heartbeat messages. 246 1. The first option is to let the Exporting Process periodically 247 trigger renegotiations on the DTLS layer. During a 248 renegotiation, the Collecting Process has to participate in a new 249 handshake, implying the exchange of datagrams in both direction. 250 If a Collector has crashed, it cannot respond to the handshake 251 messages. Thus, the absence of any return messages during the 252 renegotiation tells the Exporter that the Collector has probably 253 lost the DTLS state. 255 Under normal conditions, renegotiations are used to renew the 256 keying material in a long living connection. Depending on 257 whether a full or abbreviated handshake is carried out, a 258 renegotiation can be very costly in terms of computational 259 overhead because it involves public key operations. In addition, 260 the DTLS specification [RFC4347] leaves open if user data can be 261 sent while the rehandshake is in progress or if data transmission 262 has to pause. Typical implementations, such as OpenSSL 263 [OpenSSL], require data transmission to pause until the handshake 264 is completed. Consequently, the export of IPFIX Messages must be 265 stalled for at least two round trip times, which could lead to 266 IPFIX Messages queuing up in the buffer of the Exporting Process 267 and potential loss of data. 269 To make sure that the Exporter learns quickly about a crashed 270 Collector, renegotiations would have to be carried out on a 271 regular basis. 273 2. Another approach is to periodically establish new DTLS 274 connections and replace the existing DTLS connection by a new 275 one. Establishing a new DTLS connection involves a bidirectional 276 handshake which requires both peers to be alive. Two successive 277 connections should overlap in a way such that no IPFIX Message is 278 lost. This can be achieved by switching to the new connections 279 only after all Templates have been sent. 281 This solution has the same computational overhead as the first 282 workaround. Every DTLS connection setup might involve costly 283 public key operations and a small overhead in terms of the 284 transmitted packets. However, public key operations do not have 285 to be carried out if both DTLS implementations support a feature 286 called session resumption which allows the reuse of keying 287 material from an earlier session. 289 The main advantage over periodical DTLS renegotiations is that 290 this solution does not require to stall the transmission of user 291 data. IPFIX records can be transmitted without interruption 292 thanks to the overlap of the old and the new DTLS connection. 294 From the point of view of IPFIX, every new DTLS connection 295 represents a new Transport Session. At the Collector side, 296 however, the different Transport Sessions can be easily 297 associated to the same Exporter since the Exporter IP address 298 remains the same. At the beginning of every new Transport 299 Session, not only all active Templates have to be sent, but also 300 certain Data Records defined by Option Templates. In the case of 301 UDP, however, this does not cause significant additional overhead 302 because Templates and Data Records defined by Option Templates 303 need to be resent periodically anyway. 305 3.2. Incorrect Path MTU Values 307 3.2.1. Problem Description 309 [RFC5101] states that the Exporter must not generate IPFIX Messages 310 that result in IP packets which are larger than the PMTU. The 311 mechanism that is commonly used to discover the PMTU is described in 312 [RFC1191] and [RFC1981] and works as follows: The sender sets the 313 Don't Fragment (DF) bit on all outgoing IP packets, which bans the 314 routers on the path from fragmenting these IP packets. If a router 315 on the path cannot forward a packet because it is larger than the MTU 316 of the outbound link, it discards the packet and sends back an ICMP 317 "fragmentation needed and DF set" message [RFC0792]. This message 318 also includes a hint about the MTU of the outbound link. Upon 319 receiving this ICMP message, the sender updates its PMTU estimate for 320 this specific destination IP address. In order to avoid that future 321 packets are discarded, the sender limits, from now on, the size of IP 322 packets to the current PMTU estimate. This new estimate may or may 323 not be the final PMTU estimate as there are potentially other links 324 further down the path with even smaller MTUs. The PMTU discovery 325 process is therefore repeated until all IP packets that are as big as 326 the PMTU estimate are delivered to the destination. 328 An important characteristic of this mechanism is that at least one 329 UDP datagram is lost per update of the PMTU estimate. Hence, if 330 deployed by an IPFIX Exporting Process, a certain number of IPFIX 331 Messages will be lost until the final PMTU estimate is found. A more 332 severe problem is that ICMP messages may be blocked by firewalls. As 333 a result, the PMTU discovery mechanism fails without being noticed by 334 the Exporting Process. Instead, the Exporting Process sticks to an 335 incorrect PMTU estimate which is larger than the true PMTU. As a 336 consequence, all packets which exceed the actual PMTU will be 337 discarded on their way to the Collector, given that the "don't 338 fragment" bit is set for all packets. 340 3.2.2. Recommendation 342 If DTLS is used, the PMTU can be determined with the DTLS heartbeat 343 extension [I-D.seggelmann-tls-dtls-heartbeat] which has already been 344 presented as solution to the dead peer detection problem in 345 Section 3.1.2. This DTLS extension enables the Exporting Process to 346 send heartbeat request messages which have the size of the PMTU 347 estimate. If the Collecting Process acknowledges the reception of 348 such a heartbeat request messages with a heartbeat response message, 349 the Exporting Process knows that the PMTU estimate is less than or 350 equal to the real PMTU to the Collector. If there is no response, 351 the Exporting Process reduces the PMTU estimate and tries to send 352 another heartbeat request message with the size of the new PMTU 353 estimate. This procedure is repeated until the Exporting Process 354 receives a heartbeat response messages. Since packets may be lost 355 due to other reasons as well, every PMTU estimate should be probed in 356 multiple attempts. 358 The described PMTU discovery mechanism can be used in conjunction 359 with [RFC1191]. If a heartbeat request messages triggers an ICMP 360 "fragmentation needed and DF set" message, the Exporting Process may 361 decrease the PMTU estimate according to the returned MTU value. As a 362 general advantage, only DTLS heartbeat messages are involved in the 363 PMTU discovery. Hence, if the PMTU discovery using heartbeat 364 messages is completed before starting the IPFIX export, no IPFIX 365 Messages will be lost because of their size. 367 Since the PMTU may change over time due to routing changes, PMTU 368 discovery with heartbeat messages should be repeated on a regular 369 basis in order to ensure that the PMTU estimate is kept up to date. 371 4. Issues and Recommendations Regarding IPFIX over DTLS/SCTP 373 When [RFC5153] was published, the standardization of DTLS for SCTP 374 was not yet completed. Therefore, the guidelines regarding the 375 implementation of IPFIX over DTLS/SCTP are incomplete as well. In 376 particular, [RFC5153] does not mention that DTLS for SCTP, as 377 specified in [RFC6083], requires that the SCTP implementation 378 supports the SCTP-AUTH extension [RFC4895]. The relationship between 379 SCTP-AUTH and DTLS is explained in Section 4.1. As another change to 380 [RFC5153], an implementation of DTLS for SCTP is now available at 381 . 383 If IPFIX data is exported over DTLS/SCTP, the export needs to be 384 interrupted during DTLS renegotiations. For situations where this is 385 unacceptable, Section 4.2 presents a workaround. 387 4.1. SCTP-AUTH 389 DTLS only protects the user data transported by SCTP. SCTP-AUTH is 390 needed to protect SCTP control information which could otherwise be 391 tampered with by an attacker. For example, a man-in-the-middle 392 attacker could easily tamper with the stream ID or the payload 393 protocol identifier of a data chunk. If PR-SCTP is used, an attacker 394 may even suppress data chunks without being detected by forging SACK 395 and FORWARD-TSN chunks. 397 SCTP-AUTH [RFC4895] deploys authentication chunks to authenticate 398 certain types of subsequent chunks in the same packet using a hashed 399 message authentication code (HMAC). While SCTP-AUTH enables the 400 negotiation of the hash algorithm, it provides no means for secure 401 key agreement. Therefore, a cross layer approach is used to extract 402 keying material from the DTLS layer and use it in the SCTP layer. 403 This approach is described in [RFC6083] and is readily available in 404 OpenSSL. 406 4.2. Renegotiation for DTLS and SCTP-AUTH 408 4.2.1. Problem Description 410 A DTLS renegotiation (i.e., change of keying material) requires to 411 interrupt the ongoing data transfer because DTLS does not guarantee 412 the proper authentication and decryption of user messages that were 413 secured with outdated keying material. The implementation has to 414 make sure that no data is in flight when the keying material is 415 exchanged. This means that data transfer on all SCTP streams has to 416 stop before a renegotiation can be initiated. Moreover, all data 417 chunks in the send buffer need to be acknowledged before the 418 renegotiation can start. In practice, the renegotiation has to wait 419 until the SCTP sockets at both endpoints return SCTP_SENDER_DRY_EVENT 420 [I-D.ietf-tsvwg-sctpsocket]. Only after the handshake has been 421 completed, the data transfer can be resumed. 423 In the case of IPFIX, this means that the Exporting Process has to 424 interrupt the export of IPFIX Messages for a certain period of time. 425 IPFIX Messages generated in the meantime have to be buffered or 426 dropped until the renegotiation is completed. 428 4.2.2. Recommendation 430 If an Exporting Process exports IPFIX Messages at a very high rate, 431 it is probably impossible to buffer IPFIX Messages during a DTLS 432 renegotiation. In order to avoid that IPFIX Messages need to be 433 dropped at the Exporter, DTLS renegotiations should not be performed 434 in such situations. If the keying material needs to be changed, a 435 better solution is to establish a new DTLS/SCTP association to the 436 same Collector. After completing the handshakes of SCTP and DTLS and 437 after sending the IPFIX Templates on the new association, the 438 Exporting Process switches to the new Transport Session. 440 Compared to a renegotiation, some overhead is produced because 441 Templates as well as certain Data Records defined by Option Template 442 have to be resent, which would not be necessary if the old Transport 443 Session was kept. However, the amount of additional data that has to 444 be sent is assumed to be rather small. 446 5. Mutual Authentication via Pre-Shared Keys 448 [RFC5101] mandates strong mutual authentication of Exporters and 449 Collectors via asymmetric keys which are stored in X.509 450 certificates. This enables the user to take advantage of a public- 451 key infrastructure (PKI) and let the endpoints verify the identity of 452 their peers by using this infrastructure. 454 While a PKI is beneficial in an environment with a large number of 455 endpoints that potentially communicate with each other, the cost of 456 maintaining a PKI maybe disproportionate in smaller environments. 457 [RFC4279] defines a set of new ciphersuites that use pre-shared keys 458 instead of asymmetric keys for mutual authentication and therefore do 459 not require a PKI. Allowing IPFIX implementations to use these 460 ciphersuites can lower the administrative burden of setting up an 461 IPFIX connection that is based on DTLS or TLS. These ciphersuites 462 are also of benefit to performance-constrained environments as they 463 do not require computational expensive public key operations. 465 If the IPFIX specification allows these new ciphersuites to be used, 466 it still has to be decided which identity type Exporters send with 467 the ClientKeyExchange message. Refer to Section 5 of [RFC4279] for 468 more details. The authors recommend to use the Fully Qualified 469 Domain Name (FQDN) of the Exporter as the identity when initiating a 470 connection. The security considerations outlined in Section 7 of 471 [RFC4279] apply. 473 6. Security Considerations 475 The recommendations in this document do not introduce any additional 476 security issues to those already mentioned in [RFC5101] and 477 [RFC4279]. 479 Appendix A. Acknowledgements 481 The authors thank Michael Tuexen and Robin Seggelmann for their 482 contribution on the standardization and implementation of DTLS for 483 SCTP as well as for their valuable advice regarding the 484 implementation of IPFIX over DTLS. 486 7. References 488 7.1. Normative References 490 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 491 Security", RFC 4347, April 2006. 493 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 494 for Transport Layer Security (TLS)", RFC 4279, 495 December 2005. 497 [RFC5101] Claise, B., "Specification of the IP Flow Information 498 Export (IPFIX) Protocol for the Exchange of IP Traffic 499 Flow Information", RFC 5101, January 2008. 501 7.2. Informative References 503 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 504 RFC 792, September 1981. 506 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 507 November 1990. 509 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 510 for IP version 6", RFC 1981, August 1996. 512 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 513 Conrad, "Stream Control Transmission Protocol (SCTP) 514 Partial Reliability Extension", RFC 3758, May 2004. 516 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 517 "Authenticated Chunks for the Stream Control Transmission 518 Protocol (SCTP)", RFC 4895, August 2007. 520 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 521 RFC 4960, September 2007. 523 [RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. 524 Aitken, "IP Flow Information Export (IPFIX) Implementation 525 Guidelines", RFC 5153, April 2008. 527 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 528 Transport Layer Security (DTLS) for Stream Control 529 Transmission Protocol (SCTP)", RFC 6083, January 2011. 531 [VERMONT] "VERMONT (VERsatile MONitoring Toolkit)", 532 Homepage http://vermont.berlios.de/, 2010. 534 [OpenSSL] "OpenSSL Cryptography and SSL/TLS Toolkit", 535 Homepage http://www.openssl.org/, 2010. 537 [I-D.seggelmann-tls-dtls-heartbeat] 538 Seggelmann, R., Tuexen, M., and M. Williams, "Transport 539 Layer Security and Datagram Transport Layer Security 540 Heartbeat Extension", 541 draft-seggelmann-tls-dtls-heartbeat-02 (work in progress), 542 February 2010. 544 [I-D.ietf-tsvwg-sctpsocket] 545 Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 546 Yasevich, "Sockets API Extensions for Stream Control 547 Transmission Protocol (SCTP)", 548 draft-ietf-tsvwg-sctpsocket-27 (work in progress), 549 March 2011. 551 Authors' Addresses 553 Daniel Mentz 554 Technische Universitaet Muenchen 555 Department of Informatics 556 Chair for Network Architectures and Services (I8) 557 Boltzmannstr. 3 558 Garching D-85748 559 DE 561 Email: mentz@in.tum.de 563 Gerhard Muenz 564 Technische Universitaet Muenchen 565 Department of Informatics 566 Chair for Network Architectures and Services (I8) 567 Boltzmannstr. 3 568 Garching D-85748 569 DE 571 Phone: +49 89 289-18008 572 Email: muenz@net.in.tum.de 573 URI: http://www.net.in.tum.de/~muenz 575 Lothar Braun 576 Technische Universitaet Muenchen 577 Department of Informatics 578 Chair for Network Architectures and Services (I8) 579 Boltzmannstr. 3 580 Garching D-85748 581 DE 583 Phone: +49 89 289-18010 584 Email: braun@net.in.tum.de 585 URI: http://www.net.in.tum.de/~braun