Network Working Group                                      H. Tschofenig
Internet-Draft                                                   Siemens
Expires:  August 29, 2006                                    E. Rescorla
                                                       Network Resonance
                                                       February 25, 2006


    Real-Time Transport Protocol (RTP) over Datagram Transport Layer
                            Security (DTLS)
                  draft-tschofenig-avt-rtp-dtls-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 29, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This specification defines how to establish secure Real-Time
   Transport Protocol (RTP) sessions over the Datagram Transport Layer
   Security (DTLS) protocol.






Tschofenig & Rescorla    Expires August 29, 2006                [Page 1]


Internet-Draft                RTP over DTLS                February 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used In This Document  . . . . . . . . . . . . . .  3
   3.  RTP Packet Generation  . . . . . . . . . . . . . . . . . . . .  3
   4.  SRTP Compatibility Mode  . . . . . . . . . . . . . . . . . . .  4
   5.  RTP and RTCP . . . . . . . . . . . . . . . . . . . . . . . . .  5
   6.  Size Comparison to SRTP  . . . . . . . . . . . . . . . . . . .  5
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  7
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     10.1.  Normative References  . . . . . . . . . . . . . . . . . .  7
     10.2.  Informational References  . . . . . . . . . . . . . . . .  8
   Appendix A.  Packet Header Formats . . . . . . . . . . . . . . . .  9
     A.1.   SRTP Packet Format  . . . . . . . . . . . . . . . . . . .  9
     A.2.   DTLS/RTP Packet Format  . . . . . . . . . . . . . . . . . 10
     A.3.   DTLS/RTP Packet Format in SRTP-compatibility mode . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 14































Tschofenig & Rescorla    Expires August 29, 2006                [Page 2]


Internet-Draft                RTP over DTLS                February 2006


1.  Introduction

   Security is a major concern for real-time multimedia systems such as
   Internet telephony.  This document is part of a suite of documents
   describing a complete system for securing such communications using
   Datagram Transport Layer Security (DTLS).  Readers should also read
   [18] and [17] for background.  This document focuses on using DTLS to
   protect the Real-Time Transport Protocol (RTP).


2.  Conventions Used In This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [1].

   DTLS[4] and TLS[5] uses the term "session" to refer to a long-lived
   set of keying material that spans associations.  In this document,
   consistent with SIP/SDP usage, we use it to refer to a multimedia
   session and use the term "TLS session" to refer to the TLS construct.
   We use the term "association" to refer to a particular DTLS
   ciphersuite and keying material set.  For consistency with other SIP/
   SDP usage, we use the term "connection" when what's being referred to
   is a multimedia stream that is not specifically DTLS/TLS.

   In this document, the term "Mutual DTLS" indicates that both the DTLS
   client and server present certificates even if one or both
   certificates are self-signed.


3.  RTP Packet Generation

   The normal RTP[3] and RTCP payloads that would be sent inside a UDP
   packet are also sent inside of a DTLS packet.  The synchronization
   source (SSRC) is filled in as with a normal RTP packet.  For example,
   in an audio session that also contains DTMF using RFC2833 [9] the
   audio packets will have different SSRC values than the DTMF packets.

   A DTLS/RTP packet has the following layout:












Tschofenig & Rescorla    Expires August 29, 2006                [Page 3]


Internet-Draft                RTP over DTLS                February 2006


   +-+-+-+-+-+-+-+-+-+-+-+-+
   |                       |
   |      IP Header        |
   |                       |
   +-----------------------+
   |                       |
   |      UDP Header       |
   |                       |
   +-----------------------+
   |                       |
   |      DTLS Header      |
   |                       |
   +.......................+
   |  +--------------------+
   |  |                    |
   |  |   RTP Header       |
   |  |                    |
   |  +--------------------+
   |  +--------------------+
   |  |                    |
   |  |   Payload          |
   |  |                    |
   |  +--------------------+
   +.......................+
   |                       |
   |      DTLS Trailer     |
   |                       |
   +-----------------------+

   A sample packet is shown in Appendix A (using the TLS MAC truncation
   mode from [6] and the TLS Counter mode of [14]).


4.  SRTP Compatibility Mode

   SRTP [13] is a tightly coupled encryption mode for RTP which utilizes
   a number of advanced techniques to provide optimal performance and
   deployability for protected RTP traffic.  These benefits include:
   o  Leaving the RTP header unencrypted (enabling header
      compression[8][10][12] and easy debugging).
   o  Having the packets appear to be RTP packets for firewall
      compatibility.
   o  Zero header overhead
   This section describes a profile of RTP over DTLS which allows the
   use of DTLS key management while providing an on-the-wire packet
   format which is the same as that of SRTP.

   This profile depends on 'Extensions for DTLS in Low Bandwidth



Tschofenig & Rescorla    Expires August 29, 2006                [Page 4]


Internet-Draft                RTP over DTLS                February 2006


   Environments' described in [15] and on 'TLS Partial Encryption Mode'
   [16].  The former extension reduces the per-record bandwidth of the
   data channel.  The latter extension allows partial encryption of
   record bodies.

   In order to use DTLS/RTP in SRTP compatibility mode, implementations
   SHOULD negotiate:
   o  The TLS partial encryption extension with an InitialPlaintext
      value equal to the length of the RTP header.
   o  The DTLS implicit application data header.
   o  The TLS MAC truncation extension.

   With these extensions negotiated, RTP over DTLS packets look
   identical to SRTP records with a 10-byte MAC value.  In fact, they
   cannot be distinguished without access to the DTLS or SRTP keying
   material.  In addition, since the RTP header is in the clear, header
   compression and debugging both work.  Note that DTLS running in SRTP
   compatibility mode has the same security properties as ordinary DTLS
   (with the truncated MAC); there is a reduction between the two
   protocols.


5.  RTP and RTCP

   Note that the active endpoint will establish two DTLS sessions with
   the passive endpoint for each of the RTP and RTCP channels.  The RTP
   and RTCP sessions share the same certificate and thus the same
   fingerprint.

   [Editor's Note:  In next draft revision TLS session resumption will
   be discussed.]


6.  Size Comparison to SRTP

   One of the major arguments for SRTP is its low space overhead, which
   comes from reusing as much as possible of the RTP infrastructure.
   There are two areas where RTP over DTLS has overhead greater than
   that of SRTP:
   o  Record header (type, version, length, sequence number, epoch)
   o  MAC (DTLS uses a 10 byte MAC and SRTP uses a 4 byte MAC).










Tschofenig & Rescorla    Expires August 29, 2006                [Page 5]


Internet-Draft                RTP over DTLS                February 2006


            +------------------+--------------+--------------+
            | Header           | DTLS (bytes) | SRTP (bytes) |
            +------------------+--------------+--------------+
            | Record Header    |            5 |            0 |
            | sequence + epoch |            8 |            0 |
            | MAC              |           10 |            4 |
            | Total            |           23 |            4 |
            +------------------+--------------+--------------+

   The DTLS record header consumes 5 bytes for the type, version, and
   length + 8 bytes for the sequence number and epoch.  Thus, the total
   size difference between DTLS and SRTP is 19 bytes if the master key
   identifier (MKI) is not used in SRTP and 15 bytes if a 4 byte MKI is
   used.

   The profile discussed in the previous section allows the complete
   removal of the header for a net difference of 6 bytes (without MKI)
   or 2 bytes (with MKI).  This difference is entirely due to the longer
   (and more secure) MAC provided by TLS and DTLS.

   This section provides a comparison of packet sizes for G.729 and
   G.711 codecs using 20ms packets.  Comparisons are provided for
   unencrypted packets, SRTP without MKI, SRTP with MKI, DTLS and DTLS
   in SRTP compatibility mode.

    +-----------------------------------+-------------+---------------+
    | packet                            | size(bytes) | bitrate(kb/s) |
    +-----------------------------------+-------------+---------------+
    | G.729                             |          60 |          24.0 |
    | G.729 + SRTP                      |          64 |          25.6 |
    | G.729 + SRTP w/ MKI               |          68 |          27.2 |
    | G.729 + DTLS (SRTP-compatibility) |          70 |          28.0 |
    | G.729 + DTLS                      |          98 |          39.2 |
    | G.711                             |         200 |          80.0 |
    | G.711 + SRTP                      |         204 |          81.6 |
    | G.711 + SRTP w/ MKI               |         208 |          83.2 |
    | G.711 + DTLS (SRTP-compatibility) |         210 |          84.0 |
    | G.711 + DTLS                      |         238 |          95.2 |
    +-----------------------------------+-------------+---------------+

   Note that DTLS with the SRTP-compatibility attributes is 1.09 times
   the bandwidth of SRTP (without MKI) for G.729 and 1.03 times the
   bandwidth of SRTP with MKI.  It is 1.03 times the bandwidth of SRTP
   with MKI for G.711 and 1.01 times the bandwidth of SRTP with MKI.


7.  Security Considerations




Tschofenig & Rescorla    Expires August 29, 2006                [Page 6]


Internet-Draft                RTP over DTLS                February 2006


   Because RTP/DTLS runs over DTLS, which is based on TLS, which has
   seen extensive security analysis, we can have fairly high confidence
   in the security of the system once the channel is established.
   Similarly, because DTLS incorporates a handshake mechanism, there is
   no need to provide for confidentiality of the handshake channel.  All
   that is necessary is to ensure that the communicating peers'
   certificates are correct.

   The standard TLS/DTLS strategy for authenticating the communicating
   parties is to give the server (and optionally the client) a PKIX [2]
   certificate.  The client then verifies the certificate and checks
   that the name in the certificate matches the server's domain name.
   This works because there are a relatively small number of servers
   with well-defined names; a situation which does not usually occur in
   the VoIP context.

   An alternative strategy can be used where the certificates are self-
   signed.  When using this approach, the endpoint that acts as a client
   MUST have a way to verify that the server's certificate is correct
   and vice-versa.  An approach to address this using the Session
   Initiation Protocol (SIP) [11] and the Session Description Protocol
   (SDP) [7] is described in SIP for DTLS Media [17] and SDP for DTLS
   [18]


8.  IANA Considerations

   This specification does not require any IANA actions.


9.  Acknowledgments

   Jason Fischl and Cullen Jennings contributed substantial text and
   comments to this document.  This document benefitted from discussions
   with Francois Audet, Nagendra Modadugu, and Dan Wing.  Thanks also
   for useful comments by Flemming Andreasen, Rohan Mahy, David McGrew,
   and David Oran.


10.  References

10.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
        Public Key Infrastructure Certificate and Certificate Revocation



Tschofenig & Rescorla    Expires August 29, 2006                [Page 7]


Internet-Draft                RTP over DTLS                February 2006


        List (CRL) Profile", RFC 3280, April 2002.

   [3]  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
        "RTP: A Transport Protocol for Real-Time Applications", STD 64,
        RFC 3550, July 2003.

   [4]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
        Security", draft-rescorla-dtls-05 (work in progress), June 2005.

10.2.  Informational References

   [5]   Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1",
         draft-ietf-tls-rfc2246-bis-13 (work in progress), June 2005.

   [6]   Blake-Wilson, S., "Transport Layer Security (TLS) Extensions",
         draft-ietf-tls-rfc3546bis-02 (work in progress), October 2005.

   [7]   Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.

   [8]   Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
         Low-Speed Serial Links", RFC 2508, February 1999.

   [9]   Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
         Telephony Tones and Telephony Signals", RFC 2833, May 2000.

   [10]  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
         Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
         Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
         Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
         Framework and four profiles: RTP, UDP, ESP, and uncompressed",
         RFC 3095, July 2001.

   [11]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [12]  Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P.
         Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High
         Delay, Packet Loss and Reordering", RFC 3545, July 2003.

   [13]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
         Norrman, "The Secure Real-time Transport Protocol (SRTP)",
         RFC 3711, March 2004.

   [14]  Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher Suites
         for TLS and DTLS", draft-modadugu-tls-ctr-00 (work in
         progress), October 2005.



Tschofenig & Rescorla    Expires August 29, 2006                [Page 8]


Internet-Draft                RTP over DTLS                February 2006


   [15]  Modadugu, N. and E. Rescorla, "Extensions for DTLS in Low
         Bandwidth Environments", draft-modadugu-dtls-short-00 (work in
         progress), October 2005.

   [16]  Rescorla, E., "TLS Partial Encryption Mode",
         draft-rescorla-tls-partial-00 (work in progress), January 2006.

   [17]  Fischl, J., Tschofenig, H., and E. Rescorla, "Session
         Initiation Protocol (SIP) for Media Over Transport Layer
         Security (TLS)", February 2006.

   [18]  Fischl, J. and H. Tschofenig, "Session Description Protocol
         (SDP) Indicators for Datagram Transport Layer Security (DTLS)",
         draft-fischl-mmusic-sdp-dtls-00 (work in progress),
         February 2006.


Appendix A.  Packet Header Formats

   The subsequent figures illustrate the different packet formats and
   the size of the headers.

A.1.  SRTP Packet Format

   This figure shows the SRTP packet format layout.


























Tschofenig & Rescorla    Expires August 29, 2006                [Page 9]


Internet-Draft                RTP over DTLS                February 2006


   0   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Ver  |   IHL |      TOS      |            Length             |
   4   +---------------------------------------------------------------|
       |     Identification            | Flags   | Fragment Offset     |
   8   +---------------------------------------------------------------|
       |      TTL     |  Protocol      |   Header Checksum             |
   12  +---------------------------------------------------------------|
       |                         Source IP                             |
   16  +---------------------------------------------------------------|
       |                       Destination IP                          |
   20  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Source Port                |       Destination Port        |
   24  +---------------------------------------------------------------|
       |    Length                     |       Checksum                |
   28  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |V=2|P|X|  CC   |M|     PT      |       sequence number         |
   32  +---------------------------------------------------------------|
       |                           timestamp                           |
   36  +---------------------------------------------------------------|
       |           synchronization source (SSRC) identifier            |
   40  |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
     | |                     G.729 Payload (20ms)                      |
   44| |-------------------------------+-------------------------------+
     | |                     G.729 Cont.                               |
   48| |-------------------------------+-------------------------------+
     | |                     G.729 Cont.                               |
   52| |-------------------------------+-------------------------------+
     | |                     G.729 Cont.                               |
   56| |-------------------------------+-------------------------------+
     | |                     G.729 Cont.                               |
   60| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | |                     SRTP MKI (OPTIONAL)                       |
   64| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | |                 authentication tag (RECOMMENDED)              |
   68| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


A.2.  DTLS/RTP Packet Format

   This figure shows the DTLS/RTP packet format layout.

   0   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Ver  |   IHL |      TOS      |            Length             |
   4   +---------------------------------------------------------------|
       |     Identification            | Flags   | Fragment Offset     |
   8   +---------------------------------------------------------------|
       |      TTL     |  Protocol      |   Header Checksum             |
   12  +---------------------------------------------------------------|



Tschofenig & Rescorla    Expires August 29, 2006               [Page 10]


Internet-Draft                RTP over DTLS                February 2006


       |                         Source IP                             |
   16  +---------------------------------------------------------------|
       |                       Destination IP                          |
   20  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Source Port                |       Destination Port        |
   24  +---------------------------------------------------------------|
       |    Length                     |       Checksum                |
   28  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Type       |           Version             | epoch-low     |
   32  +---------------------------------------------------------------|
       |    epoc-hi    |           seq-low-24                          |
   36  +---------------------------------------------------------------|
       |              seq-hi-24                        | length-low    |
   40  +---------------------------------------------------------------|
       | length-hi     |  xxxxxxxxxx NO BYTES HERE xxxxxxxxxxxxxxxxxxxx
   41  |---------------------------------------------------------------|
     | |V=2|P|X|  CC   |M|     PT      |       sequence number         |
   45| +---------------------------------------------------------------|
     | |                           timestamp                           |
   49| +---------------------------------------------------------------|
     | |           synchronization source (SSRC) identifier            |
   53| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | |                     G.729 Payload (20ms)                      |
   57| |-------------------------------+-------------------------------+
     | |                     G.729 Cont.                               |
   61| |-------------------------------+-------------------------------+
     | |                     G.729 Cont.                               |
   65| |-------------------------------+-------------------------------+
     | |                     G.729 Cont.                               |
   69| |-------------------------------+-------------------------------+
     | |                     G.729 Cont.                               |
   73  |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
     | |                     HMAC-SHA1                                 |
   77| |-------------------------------+-------------------------------+
     | |                     HMAC-SHA1  (cont)                         |
   81| |-------------------------------+-------------------------------+
     | |                     HMAC-SHA1  (cont)                         |
   85| |-------------------------------+-------------------------------+
     | |                     HMAC-SHA1  (cont)                         |
   89| |-------------------------------+-------------------------------+
     | |                     HMAC-SHA1  (cont)                         |
   93| |-------------------------------+-------------------------------+
     | |                              PAD                              |
   97| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | | PAD LEN      |                XXX NO BYTES                    |
   98  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Tschofenig & Rescorla    Expires August 29, 2006               [Page 11]


Internet-Draft                RTP over DTLS                February 2006


A.3.  DTLS/RTP Packet Format in SRTP-compatibility mode

   This figure shows the DTLS/RTP packet with low bandwidth extensions.

   0   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Ver  |   IHL |      TOS      |            Length             |
   4   +---------------------------------------------------------------|
       |     Identification            | Flags   | Fragment Offset     |
   8   +---------------------------------------------------------------|
       |      TTL     |  Protocol      |   Header Checksum             |
   12  +---------------------------------------------------------------|
       |                         Source IP                             |
   16  +---------------------------------------------------------------|
       |                       Destination IP                          |
   20  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Source Port                |       Destination Port        |
   24  +---------------------------------------------------------------|
       |    Length                     |       Checksum                |
   28  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |V=2|P|X|  CC   |M|     PT      |       sequence number         |
   32  +---------------------------------------------------------------|
       |                           timestamp                           |
   36  +---------------------------------------------------------------|
       |           synchronization source (SSRC) identifier            |
   40  |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
     | |                     G.729 Payload (20ms)                      |
   44| |-------------------------------+-------------------------------+
     | |                     G.729 Cont.                               |
   48| |-------------------------------+-------------------------------+
     | |                     G.729 Cont.                               |
   52| |-------------------------------+-------------------------------+
     | |                     G.729 Cont.                               |
   56| |-------------------------------+-------------------------------+
     | |                     G.729 Cont.                               |
   60| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | |                     SRTP MKI (OPTIONAL)                       |
   64| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | |                     HMAC-SHA1                                 |
   68| |-------------------------------+-------------------------------+
     | |                     HMAC-SHA1  (cont)                         |
   72| |-------------------------------+-------------------------------+
     | |        HMAC-SHA1 (cont)       |
   74| |-------------------------------+








Tschofenig & Rescorla    Expires August 29, 2006               [Page 12]


Internet-Draft                RTP over DTLS                February 2006


Authors' Addresses

   Hannes Tschofenig
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email:  Hannes.Tschofenig@siemens.com


   Eric Rescorla
   Network Resonance
   2483 E. Bayshore #212
   Palo Alto, CA  94303
   USA

   Email:  ekr@networkresonance.com

































Tschofenig & Rescorla    Expires August 29, 2006               [Page 13]


Internet-Draft                RTP over DTLS                February 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Tschofenig & Rescorla    Expires August 29, 2006               [Page 14]