[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

IP Flow Information Export WG                                   D. Mentz
Internet-Draft                                                  G. Muenz
Intended status: Informational                                  L. Braun
Expires: September 15, 2011                                  TU Muenchen
                                                          March 14, 2011


            Recommendations for Implementing IPFIX over DTLS
              <draft-mentz-ipfix-dtls-recommendations-02>

Abstract

   This document discusses problems and solutions regarding the
   implementation of the IPFIX protocol over DTLS.  It updates the
   "IPFIX Implementation Guidelines" [RFC5153].

Status of this Memo

   This Internet-Draft is submitted to IETF 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 September 15, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   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.




Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-01.txt    [Page 1]


Internet-Draft     Recommendations for IPFIX over DTLS        March 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3

   3.  Issues and Recommendations Regarding IPFIX over DTLS/UDP . . .  4
     3.1.  Undetected Collector Crashes . . . . . . . . . . . . . . .  4
       3.1.1.  Problem Description  . . . . . . . . . . . . . . . . .  4
       3.1.2.  Recommendation . . . . . . . . . . . . . . . . . . . .  5
       3.1.3.  Alternative Workarounds  . . . . . . . . . . . . . . .  6
     3.2.  Incorrect Path MTU Values  . . . . . . . . . . . . . . . .  7
       3.2.1.  Problem Description  . . . . . . . . . . . . . . . . .  7
       3.2.2.  Recommendation . . . . . . . . . . . . . . . . . . . .  8

   4.  Issues and Recommendations Regarding IPFIX over DTLS/SCTP  . .  9
     4.1.  SCTP-AUTH  . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.2.  Renegotiation for DTLS and SCTP-AUTH . . . . . . . . . . .  9
       4.2.1.  Problem Description  . . . . . . . . . . . . . . . . .  9
       4.2.2.  Recommendation . . . . . . . . . . . . . . . . . . . . 10

   5.  Mutual Authentication via Pre-Shared Keys  . . . . . . . . . . 10

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11

   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 11

   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 11

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12



















Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-01.txt    [Page 2]


Internet-Draft     Recommendations for IPFIX over DTLS        March 2011


1.  Introduction

   All implementations of the IPFIX protocol conforming to [RFC5101]
   must support DTLS [RFC4347] if SCTP or UDP is selected as IPFIX
   transport protocol.  This document discusses specific issues that
   have arisen during the implementation of the IPFIX protocol over DTLS
   (the source code of the implementation is available as part of
   VERMONT [VERMONT]).

   Section 3 discusses two issues which may lead to the loss of IPFIX
   Messages if DTLS is used with UDP as transport protocol: unexpected
   Collector crashes and wrong path MTU values.  In the first case, the
   data loss may even not be recognized by the Collector.  By following
   the recommendations of this document, these two problems can be
   avoided.

   Section 4 discusses one issue which corresponds to the implementation
   of IPFIX over DTLS/SCTP.  In this case, DTLS renegotiations require
   the interruption of the data export for a short period of time, which
   may lead to the queuing and potential loss of IPFIX Messages at the
   Exporting Process.  For Exporters that operate at a high data rate,
   it is recommended to switch over to a newly established DTLS/SCTP
   Transport Session instead of triggering DTLS renegotiation for an
   existing Transport Session.

   When the "IPFIX Implementation Guidelines" were published [RFC5153],
   no implementation of IPFIX over DTLS/UDP or DTLS/SCTP actually
   existed.  Therefore, Sections 8.4 and 8.5 of [RFC5153] are incomplete
   and do not cover the issues described in this document.  Hence, the
   recommendations of this document complement and update the "IPFIX
   Implementation Guidelines" [RFC5153].

   Finally, Section 5 suggests to support the pre-shared key
   ciphersuites for TLS for mutual authentication.  These ciphersuites
   can do without a public-key infrastructure (PKI) and can therefore
   facilitate the setup of an environment with a limited number of IPFIX
   devices.


2.  Terminology

   This document adopts the IPFIX terminology used in [RFC5101].  As in
   all IPFIX documents, all IPFIX specific terms have the first letter
   of a word capitalized when used in this document.







Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-01.txt    [Page 3]


Internet-Draft     Recommendations for IPFIX over DTLS        March 2011


3.  Issues and Recommendations Regarding IPFIX over DTLS/UDP

   Regarding IPFIX over DTLS/UDP, [RFC5101] and [RFC5153] refer to
   [RFC4347] which specifies the usage of DTLS over the transport
   protocol UDP.  [RFC5153] explains that Exporting Processes and
   Collecting Processes should behave as if UDP without DTLS was
   transport protocol.

   During the implementation of IPFIX over DTLS/UDP, it turned out that
   the specification of [RFC4347] is insufficient for IPFIX data export
   because the loss of DTLS state at the Collecting Process may not be
   detected by the Exporting Process.  As a consequence, it remains
   unnoticed that all further IPFIX Messages arriving at the Collecting
   Process must be discarded.  This issue as well as recommendations how
   to solve it are discussed in Section 3.1.

   For IPFIX export over UDP, [RFC5101] specifies that the total packet
   size of IPFIX Messages must not exceed the path MTU (PMTU).  Section
   8.4 of [RFC5153] points out that DTLS introduces overhead which
   affects the packet size.  In fact, the utilization of DTLS affects
   the packet size, yet it does not generally result in larger packet
   sizes.  In particular, if the IPFIX Message is compressed before
   being encrypted, the size of the DTLS record is likely to be smaller
   than the original IPFIX Message.  However, since the compression
   ratio cannot be predicted, it is save to make conservative
   assumptions about the DTLS record size.

   Another general problem regarding the utilization of UDP as transport
   protocol is that the total packet size should not exceed 512 octets
   if the PMTU is not available [RFC5101].  Since the PMTU is usually
   larger than 512 octets, this limitation causes overhead due to
   unnecessarily small IPFIX Messages.  Hence, there is an interest to
   provide the Exporting Process with a correct PMTU value.

   If the PMTU is known, it can be configured by the user.  Otherwise,
   the PMTU can be determined by PMTU discovery mechanisms defined in
   [RFC1191] and [RFC1981].  However, these mechanisms do not always
   provide reliable results.  Section 3.2 discusses this issue in more
   detail and presents a better PMTU discovery mechanism for DTLS/UDP.

3.1.  Undetected Collector Crashes

3.1.1.  Problem Description

   DTLS has been conceived for deployment on top of unreliable transport
   protocols, such as UDP.  Hence, the handshaking protocol of DTLS is
   able to cope with lost datagrams and datagrams that arrive out of
   order at the receiver.  In contrast to UDP, which does not maintain



Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-01.txt    [Page 4]


Internet-Draft     Recommendations for IPFIX over DTLS        March 2011


   any connection state, DTLS has to maintain state across multiple
   datagrams at both endpoints.  This state is established and
   initialized during the DTLS handshake [RFC4347].

   During the DTLS handshake, the two peers authenticate each other and
   agree upon several parameters which are necessary to communicate over
   DTLS.  Among these parameters are a cipher suite as well as a shared
   key that is usually established using a Diffie-Hellman key exchange.
   If one of the peers crashes unexpectedly, these parameters as well as
   the maintained DTLS state usually get lost.  As a consequence, the
   peer is not able to check the integrity of newly arrived datagrams or
   to decrypted the datagrams' payload.

   In the case of connection-oriented transport protocols, such as TCP
   or SCTP, a connection endpoint will be informed about the crash of
   its correspondent by the transport protocol.  UDP, however, is
   connection-less, which means that the crash of the receiver is not
   noticed by the sender.  There are situations in which the sender
   might receive ICMP messages indicating that the receiver is
   experiencing problems, for example if an ICMP port unreachable
   message is returned because the UDP port is closed.  However, there
   is no guarantee that these ICMP messages will be sent.  Also,
   implementations should ignore these messages as they are not
   authenticated and might therefore be forged.  DTLS as specified in
   [RFC4347] does not provide any mechanisms for dead peer detection,
   thus the crash of one of the peers has to be detected and handled by
   protocols in the upper layers.

   As IPFIX is a unidirectional protocol, a conforming implementation of
   an IPFIX Exporter only sends but does not receive any data.  Hence,
   the Exporter cannot tell from the absence of returning traffic that
   the Collector has crashed.  Instead, the Exporter keeps on sending
   data which must be discarded by the recovered Collector because the
   information needed to check the integrity and to decrypt the data is
   lost.

3.1.2.  Recommendation

   The DTLS heartbeat extension which has been suggested in
   [I-D.seggelmann-tls-dtls-heartbeat] allows a DTLS endpoint to detect
   a dead peer.  With this extension, each endpoint may transmit DTLS
   heartbeat request messages to the other peer.  Each peer is supposed
   to send back a heartbeat response message for every heartbeat request
   message it receives.  As UDP provides unreliable transport, it may
   happen that heartbeat request or response messages are lost.
   Nevertheless, a peer can be declared dead if it fails to respond to a
   certain number of consecutive heartbeat requests.




Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-01.txt    [Page 5]


Internet-Draft     Recommendations for IPFIX over DTLS        March 2011


   The computational and bandwidth overhead of the heartbeat messages is
   very small.  As another advantage, the exchange of heartbeat messages
   does not affect the transport of user data.  In particular, the
   transport of user data does not have to be interrupted.

   IPFIX Exporters and Collectors should support the DTLS heartbeat
   extension to allow an Exporting Process to check whether the
   Collecting Process is still able to decrypt the exported IPFIX
   Messages.  To detect a crashed Collector, the Exporting Process must
   actively trigger the sending of a DTLS heartbeat request message.
   This should be done on a regular basis (e.g., periodically).  It must
   be noted that a dead peer remains undetected in the time interval
   between two successive heartbeat requests.

   The only problem with this solution is that the DTLS heartbeat
   extension has not yet been standardized.

3.1.3.  Alternative Workarounds

   If the DTLS heartbeat extension is not available, there exist two
   workarounds which also enable the detection of a crashed Collector.
   However, these approaches have several disadvantages compared to
   heartbeat messages.

   1.  The first option is to let the Exporting Process periodically
       trigger renegotiations on the DTLS layer.  During a
       renegotiation, the Collecting Process has to participate in a new
       handshake, implying the exchange of datagrams in both direction.
       If a Collector has crashed, it cannot respond to the handshake
       messages.  Thus, the absence of any return messages during the
       renegotiation tells the Exporter that the Collector has probably
       lost the DTLS state.

       Under normal conditions, renegotiations are used to renew the
       keying material in a long living connection.  Depending on
       whether a full or abbreviated handshake is carried out, a
       renegotiation can be very costly in terms of computational
       overhead because it involves public key operations.  In addition,
       the DTLS specification [RFC4347] leaves open if user data can be
       sent while the rehandshake is in progress or if data transmission
       has to pause.  Typical implementations, such as OpenSSL
       [OpenSSL], require data transmission to pause until the handshake
       is completed.  Consequently, the export of IPFIX Messages must be
       stalled for at least two round trip times, which could lead to
       IPFIX Messages queuing up in the buffer of the Exporting Process
       and potential loss of data.

       To make sure that the Exporter learns quickly about a crashed



Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-01.txt    [Page 6]


Internet-Draft     Recommendations for IPFIX over DTLS        March 2011


       Collector, renegotiations would have to be carried out on a
       regular basis.

   2.  Another approach is to periodically establish new DTLS
       connections and replace the existing DTLS connection by a new
       one.  Establishing a new DTLS connection involves a bidirectional
       handshake which requires both peers to be alive.  Two successive
       connections should overlap in a way such that no IPFIX Message is
       lost.  This can be achieved by switching to the new connections
       only after all Templates have been sent.

       This solution has the same computational overhead as the first
       workaround.  Every DTLS connection setup might involve costly
       public key operations and a small overhead in terms of the
       transmitted packets.  However, public key operations do not have
       to be carried out if both DTLS implementations support a feature
       called session resumption which allows the reuse of keying
       material from an earlier session.

       The main advantage over periodical DTLS renegotiations is that
       this solution does not require to stall the transmission of user
       data.  IPFIX records can be transmitted without interruption
       thanks to the overlap of the old and the new DTLS connection.

       From the point of view of IPFIX, every new DTLS connection
       represents a new Transport Session.  At the Collector side,
       however, the different Transport Sessions can be easily
       associated to the same Exporter since the Exporter IP address
       remains the same.  At the beginning of every new Transport
       Session, not only all active Templates have to be sent, but also
       certain Data Records defined by Option Templates.  In the case of
       UDP, however, this does not cause significant additional overhead
       because Templates and Data Records defined by Option Templates
       need to be resent periodically anyway.

3.2.  Incorrect Path MTU Values

3.2.1.  Problem Description

   [RFC5101] states that the Exporter must not generate IPFIX Messages
   that result in IP packets which are larger than the PMTU.  The
   mechanism that is commonly used to discover the PMTU is described in
   [RFC1191] and [RFC1981] and works as follows: The sender sets the
   Don't Fragment (DF) bit on all outgoing IP packets, which bans the
   routers on the path from fragmenting these IP packets.  If a router
   on the path cannot forward a packet because it is larger than the MTU
   of the outbound link, it discards the packet and sends back an ICMP
   "fragmentation needed and DF set" message [RFC0792].  This message



Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-01.txt    [Page 7]


Internet-Draft     Recommendations for IPFIX over DTLS        March 2011


   also includes a hint about the MTU of the outbound link.  Upon
   receiving this ICMP message, the sender updates its PMTU estimate for
   this specific destination IP address.  In order to avoid that future
   packets are discarded, the sender limits, from now on, the size of IP
   packets to the current PMTU estimate.  This new estimate may or may
   not be the final PMTU estimate as there are potentially other links
   further down the path with even smaller MTUs.  The PMTU discovery
   process is therefore repeated until all IP packets that are as big as
   the PMTU estimate are delivered to the destination.

   An important characteristic of this mechanism is that at least one
   UDP datagram is lost per update of the PMTU estimate.  Hence, if
   deployed by an IPFIX Exporting Process, a certain number of IPFIX
   Messages will be lost until the final PMTU estimate is found.  A more
   severe problem is that ICMP messages may be blocked by firewalls.  As
   a result, the PMTU discovery mechanism fails without being noticed by
   the Exporting Process.  Instead, the Exporting Process sticks to an
   incorrect PMTU estimate which is larger than the true PMTU.  As a
   consequence, all packets which exceed the actual PMTU will be
   discarded on their way to the Collector, given that the "don't
   fragment" bit is set for all packets.

3.2.2.  Recommendation

   If DTLS is used, the PMTU can be determined with the DTLS heartbeat
   extension [I-D.seggelmann-tls-dtls-heartbeat] which has already been
   presented as solution to the dead peer detection problem in
   Section 3.1.2.  This DTLS extension enables the Exporting Process to
   send heartbeat request messages which have the size of the PMTU
   estimate.  If the Collecting Process acknowledges the reception of
   such a heartbeat request messages with a heartbeat response message,
   the Exporting Process knows that the PMTU estimate is less than or
   equal to the real PMTU to the Collector.  If there is no response,
   the Exporting Process reduces the PMTU estimate and tries to send
   another heartbeat request message with the size of the new PMTU
   estimate.  This procedure is repeated until the Exporting Process
   receives a heartbeat response messages.  Since packets may be lost
   due to other reasons as well, every PMTU estimate should be probed in
   multiple attempts.

   The described PMTU discovery mechanism can be used in conjunction
   with [RFC1191].  If a heartbeat request messages triggers an ICMP
   "fragmentation needed and DF set" message, the Exporting Process may
   decrease the PMTU estimate according to the returned MTU value.  As a
   general advantage, only DTLS heartbeat messages are involved in the
   PMTU discovery.  Hence, if the PMTU discovery using heartbeat
   messages is completed before starting the IPFIX export, no IPFIX
   Messages will be lost because of their size.



Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-01.txt    [Page 8]


Internet-Draft     Recommendations for IPFIX over DTLS        March 2011


   Since the PMTU may change over time due to routing changes, PMTU
   discovery with heartbeat messages should be repeated on a regular
   basis in order to ensure that the PMTU estimate is kept up to date.


4.  Issues and Recommendations Regarding IPFIX over DTLS/SCTP

   When [RFC5153] was published, the standardization of DTLS for SCTP
   was not yet completed.  Therefore, the guidelines regarding the
   implementation of IPFIX over DTLS/SCTP are incomplete as well.  In
   particular, [RFC5153] does not mention that DTLS for SCTP, as
   specified in [RFC6083], requires that the SCTP implementation
   supports the SCTP-AUTH extension [RFC4895].  The relationship between
   SCTP-AUTH and DTLS is explained in Section 4.1.  As another change to
   [RFC5153], an implementation of DTLS for SCTP is now available at
   <http://sctp.fh-muenster.de/>.

   If IPFIX data is exported over DTLS/SCTP, the export needs to be
   interrupted during DTLS renegotiations.  For situations where this is
   unacceptable, Section 4.2 presents a workaround.

4.1.  SCTP-AUTH

   DTLS only protects the user data transported by SCTP.  SCTP-AUTH is
   needed to protect SCTP control information which could otherwise be
   tampered with by an attacker.  For example, a man-in-the-middle
   attacker could easily tamper with the stream ID or the payload
   protocol identifier of a data chunk.  If PR-SCTP is used, an attacker
   may even suppress data chunks without being detected by forging SACK
   and FORWARD-TSN chunks.

   SCTP-AUTH [RFC4895] deploys authentication chunks to authenticate
   certain types of subsequent chunks in the same packet using a hashed
   message authentication code (HMAC).  While SCTP-AUTH enables the
   negotiation of the hash algorithm, it provides no means for secure
   key agreement.  Therefore, a cross layer approach is used to extract
   keying material from the DTLS layer and use it in the SCTP layer.
   This approach is described in [RFC6083] and is readily available in
   OpenSSL.

4.2.  Renegotiation for DTLS and SCTP-AUTH

4.2.1.  Problem Description

   A DTLS renegotiation (i.e., change of keying material) requires to
   interrupt the ongoing data transfer because DTLS does not guarantee
   the proper authentication and decryption of user messages that were
   secured with outdated keying material.  The implementation has to



Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-01.txt    [Page 9]


Internet-Draft     Recommendations for IPFIX over DTLS        March 2011


   make sure that no data is in flight when the keying material is
   exchanged.  This means that data transfer on all SCTP streams has to
   stop before a renegotiation can be initiated.  Moreover, all data
   chunks in the send buffer need to be acknowledged before the
   renegotiation can start.  In practice, the renegotiation has to wait
   until the SCTP sockets at both endpoints return SCTP_SENDER_DRY_EVENT
   [I-D.ietf-tsvwg-sctpsocket].  Only after the handshake has been
   completed, the data transfer can be resumed.

   In the case of IPFIX, this means that the Exporting Process has to
   interrupt the export of IPFIX Messages for a certain period of time.
   IPFIX Messages generated in the meantime have to be buffered or
   dropped until the renegotiation is completed.

4.2.2.  Recommendation

   If an Exporting Process exports IPFIX Messages at a very high rate,
   it is probably impossible to buffer IPFIX Messages during a DTLS
   renegotiation.  In order to avoid that IPFIX Messages need to be
   dropped at the Exporter, DTLS renegotiations should not be performed
   in such situations.  If the keying material needs to be changed, a
   better solution is to establish a new DTLS/SCTP association to the
   same Collector.  After completing the handshakes of SCTP and DTLS and
   after sending the IPFIX Templates on the new association, the
   Exporting Process switches to the new Transport Session.

   Compared to a renegotiation, some overhead is produced because
   Templates as well as certain Data Records defined by Option Template
   have to be resent, which would not be necessary if the old Transport
   Session was kept.  However, the amount of additional data that has to
   be sent is assumed to be rather small.


5.  Mutual Authentication via Pre-Shared Keys

   [RFC5101] mandates strong mutual authentication of Exporters and
   Collectors via asymmetric keys which are stored in X.509
   certificates.  This enables the user to take advantage of a public-
   key infrastructure (PKI) and let the endpoints verify the identity of
   their peers by using this infrastructure.

   While a PKI is beneficial in an environment with a large number of
   endpoints that potentially communicate with each other, the cost of
   maintaining a PKI maybe disproportionate in smaller environments.
   [RFC4279] defines a set of new ciphersuites that use pre-shared keys
   instead of asymmetric keys for mutual authentication and therefore do
   not require a PKI.  Allowing IPFIX implementations to use these
   ciphersuites can lower the administrative burden of setting up an



Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-01.txt    [Page 10]


Internet-Draft     Recommendations for IPFIX over DTLS        March 2011


   IPFIX connection that is based on DTLS or TLS.  These ciphersuites
   are also of benefit to performance-constrained environments as they
   do not require computational expensive public key operations.

   If the IPFIX specification allows these new ciphersuites to be used,
   it still has to be decided which identity type Exporters send with
   the ClientKeyExchange message.  Refer to Section 5 of [RFC4279] for
   more details.  The authors recommend to use the Fully Qualified
   Domain Name (FQDN) of the Exporter as the identity when initiating a
   connection.  The security considerations outlined in Section 7 of
   [RFC4279] apply.


6.  Security Considerations

   The recommendations in this document do not introduce any additional
   security issues to those already mentioned in [RFC5101] and
   [RFC4279].


Appendix A.  Acknowledgements

   The authors thank Michael Tuexen and Robin Seggelmann for their
   contribution on the standardization and implementation of DTLS for
   SCTP as well as for their valuable advice regarding the
   implementation of IPFIX over DTLS.


7.  References

7.1.  Normative References

   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

   [RFC4279]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
              for Transport Layer Security (TLS)", RFC 4279,
              December 2005.

   [RFC5101]  Claise, B., "Specification of the IP Flow Information
              Export (IPFIX) Protocol for the Exchange of IP Traffic
              Flow Information", RFC 5101, January 2008.

7.2.  Informative References

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.




Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-01.txt    [Page 11]


Internet-Draft     Recommendations for IPFIX over DTLS        March 2011


   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
              for IP version 6", RFC 1981, August 1996.

   [RFC3758]  Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
              Conrad, "Stream Control Transmission Protocol (SCTP)
              Partial Reliability Extension", RFC 3758, May 2004.

   [RFC4895]  Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
              "Authenticated Chunks for the Stream Control Transmission
              Protocol (SCTP)", RFC 4895, August 2007.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC5153]  Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P.
              Aitken, "IP Flow Information Export (IPFIX) Implementation
              Guidelines", RFC 5153, April 2008.

   [RFC6083]  Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
              Transport Layer Security (DTLS) for Stream Control
              Transmission Protocol (SCTP)", RFC 6083, January 2011.

   [VERMONT]  "VERMONT (VERsatile MONitoring Toolkit)",
              Homepage http://vermont.berlios.de/, 2010.

   [OpenSSL]  "OpenSSL Cryptography and SSL/TLS Toolkit",
              Homepage http://www.openssl.org/, 2010.

   [I-D.seggelmann-tls-dtls-heartbeat]
              Seggelmann, R., Tuexen, M., and M. Williams, "Transport
              Layer Security and Datagram Transport Layer Security
              Heartbeat Extension",
              draft-seggelmann-tls-dtls-heartbeat-02 (work in progress),
              February 2010.

   [I-D.ietf-tsvwg-sctpsocket]
              Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
              Yasevich, "Sockets API Extensions for Stream Control
              Transmission Protocol (SCTP)",
              draft-ietf-tsvwg-sctpsocket-27 (work in progress),
              March 2011.







Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-01.txt    [Page 12]


Internet-Draft     Recommendations for IPFIX over DTLS        March 2011


Authors' Addresses

   Daniel Mentz
   Technische Universitaet Muenchen
   Department of Informatics
   Chair for Network Architectures and Services (I8)
   Boltzmannstr. 3
   Garching  D-85748
   DE

   Email: mentz@in.tum.de


   Gerhard Muenz
   Technische Universitaet Muenchen
   Department of Informatics
   Chair for Network Architectures and Services (I8)
   Boltzmannstr. 3
   Garching  D-85748
   DE

   Phone: +49 89 289-18008
   Email: muenz@net.in.tum.de
   URI:   http://www.net.in.tum.de/~muenz


   Lothar Braun
   Technische Universitaet Muenchen
   Department of Informatics
   Chair for Network Architectures and Services (I8)
   Boltzmannstr. 3
   Garching  D-85748
   DE

   Phone: +49 89 289-18010
   Email: braun@net.in.tum.de
   URI:   http://www.net.in.tum.de/~braun














Mentz, et al.  draft-mentz-ipfix-dtls-recommendations-01.txt    [Page 13]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/