idnits 2.17.1 draft-tschofenig-avt-rtp-dtls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 530. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 536. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2006) is 6627 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3280 (ref. '2') (Obsoleted by RFC 5280) ** Downref: Normative reference to an Historic draft: draft-rescorla-dtls (ref. '4') -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '7') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2833 (ref. '9') (Obsoleted by RFC 4733, RFC 4734) == Outdated reference: A later version (-04) exists of draft-fischl-mmusic-sdp-dtls-00 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft Siemens 4 Expires: August 29, 2006 E. Rescorla 5 Network Resonance 6 February 25, 2006 8 Real-Time Transport Protocol (RTP) over Datagram Transport Layer 9 Security (DTLS) 10 draft-tschofenig-avt-rtp-dtls-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 29, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This specification defines how to establish secure Real-Time 44 Transport Protocol (RTP) sessions over the Datagram Transport Layer 45 Security (DTLS) protocol. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 51 3. RTP Packet Generation . . . . . . . . . . . . . . . . . . . . 3 52 4. SRTP Compatibility Mode . . . . . . . . . . . . . . . . . . . 4 53 5. RTP and RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 6. Size Comparison to SRTP . . . . . . . . . . . . . . . . . . . 5 55 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 56 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 57 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 58 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 60 10.2. Informational References . . . . . . . . . . . . . . . . 8 61 Appendix A. Packet Header Formats . . . . . . . . . . . . . . . . 9 62 A.1. SRTP Packet Format . . . . . . . . . . . . . . . . . . . 9 63 A.2. DTLS/RTP Packet Format . . . . . . . . . . . . . . . . . 10 64 A.3. DTLS/RTP Packet Format in SRTP-compatibility mode . . . . 12 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 66 Intellectual Property and Copyright Statements . . . . . . . . . . 14 68 1. Introduction 70 Security is a major concern for real-time multimedia systems such as 71 Internet telephony. This document is part of a suite of documents 72 describing a complete system for securing such communications using 73 Datagram Transport Layer Security (DTLS). Readers should also read 74 [18] and [17] for background. This document focuses on using DTLS to 75 protect the Real-Time Transport Protocol (RTP). 77 2. Conventions Used In This Document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [1]. 83 DTLS[4] and TLS[5] uses the term "session" to refer to a long-lived 84 set of keying material that spans associations. In this document, 85 consistent with SIP/SDP usage, we use it to refer to a multimedia 86 session and use the term "TLS session" to refer to the TLS construct. 87 We use the term "association" to refer to a particular DTLS 88 ciphersuite and keying material set. For consistency with other SIP/ 89 SDP usage, we use the term "connection" when what's being referred to 90 is a multimedia stream that is not specifically DTLS/TLS. 92 In this document, the term "Mutual DTLS" indicates that both the DTLS 93 client and server present certificates even if one or both 94 certificates are self-signed. 96 3. RTP Packet Generation 98 The normal RTP[3] and RTCP payloads that would be sent inside a UDP 99 packet are also sent inside of a DTLS packet. The synchronization 100 source (SSRC) is filled in as with a normal RTP packet. For example, 101 in an audio session that also contains DTMF using RFC2833 [9] the 102 audio packets will have different SSRC values than the DTMF packets. 104 A DTLS/RTP packet has the following layout: 106 +-+-+-+-+-+-+-+-+-+-+-+-+ 107 | | 108 | IP Header | 109 | | 110 +-----------------------+ 111 | | 112 | UDP Header | 113 | | 114 +-----------------------+ 115 | | 116 | DTLS Header | 117 | | 118 +.......................+ 119 | +--------------------+ 120 | | | 121 | | RTP Header | 122 | | | 123 | +--------------------+ 124 | +--------------------+ 125 | | | 126 | | Payload | 127 | | | 128 | +--------------------+ 129 +.......................+ 130 | | 131 | DTLS Trailer | 132 | | 133 +-----------------------+ 135 A sample packet is shown in Appendix A (using the TLS MAC truncation 136 mode from [6] and the TLS Counter mode of [14]). 138 4. SRTP Compatibility Mode 140 SRTP [13] is a tightly coupled encryption mode for RTP which utilizes 141 a number of advanced techniques to provide optimal performance and 142 deployability for protected RTP traffic. These benefits include: 143 o Leaving the RTP header unencrypted (enabling header 144 compression[8][10][12] and easy debugging). 145 o Having the packets appear to be RTP packets for firewall 146 compatibility. 147 o Zero header overhead 148 This section describes a profile of RTP over DTLS which allows the 149 use of DTLS key management while providing an on-the-wire packet 150 format which is the same as that of SRTP. 152 This profile depends on 'Extensions for DTLS in Low Bandwidth 153 Environments' described in [15] and on 'TLS Partial Encryption Mode' 154 [16]. The former extension reduces the per-record bandwidth of the 155 data channel. The latter extension allows partial encryption of 156 record bodies. 158 In order to use DTLS/RTP in SRTP compatibility mode, implementations 159 SHOULD negotiate: 160 o The TLS partial encryption extension with an InitialPlaintext 161 value equal to the length of the RTP header. 162 o The DTLS implicit application data header. 163 o The TLS MAC truncation extension. 165 With these extensions negotiated, RTP over DTLS packets look 166 identical to SRTP records with a 10-byte MAC value. In fact, they 167 cannot be distinguished without access to the DTLS or SRTP keying 168 material. In addition, since the RTP header is in the clear, header 169 compression and debugging both work. Note that DTLS running in SRTP 170 compatibility mode has the same security properties as ordinary DTLS 171 (with the truncated MAC); there is a reduction between the two 172 protocols. 174 5. RTP and RTCP 176 Note that the active endpoint will establish two DTLS sessions with 177 the passive endpoint for each of the RTP and RTCP channels. The RTP 178 and RTCP sessions share the same certificate and thus the same 179 fingerprint. 181 [Editor's Note: In next draft revision TLS session resumption will 182 be discussed.] 184 6. Size Comparison to SRTP 186 One of the major arguments for SRTP is its low space overhead, which 187 comes from reusing as much as possible of the RTP infrastructure. 188 There are two areas where RTP over DTLS has overhead greater than 189 that of SRTP: 190 o Record header (type, version, length, sequence number, epoch) 191 o MAC (DTLS uses a 10 byte MAC and SRTP uses a 4 byte MAC). 193 +------------------+--------------+--------------+ 194 | Header | DTLS (bytes) | SRTP (bytes) | 195 +------------------+--------------+--------------+ 196 | Record Header | 5 | 0 | 197 | sequence + epoch | 8 | 0 | 198 | MAC | 10 | 4 | 199 | Total | 23 | 4 | 200 +------------------+--------------+--------------+ 202 The DTLS record header consumes 5 bytes for the type, version, and 203 length + 8 bytes for the sequence number and epoch. Thus, the total 204 size difference between DTLS and SRTP is 19 bytes if the master key 205 identifier (MKI) is not used in SRTP and 15 bytes if a 4 byte MKI is 206 used. 208 The profile discussed in the previous section allows the complete 209 removal of the header for a net difference of 6 bytes (without MKI) 210 or 2 bytes (with MKI). This difference is entirely due to the longer 211 (and more secure) MAC provided by TLS and DTLS. 213 This section provides a comparison of packet sizes for G.729 and 214 G.711 codecs using 20ms packets. Comparisons are provided for 215 unencrypted packets, SRTP without MKI, SRTP with MKI, DTLS and DTLS 216 in SRTP compatibility mode. 218 +-----------------------------------+-------------+---------------+ 219 | packet | size(bytes) | bitrate(kb/s) | 220 +-----------------------------------+-------------+---------------+ 221 | G.729 | 60 | 24.0 | 222 | G.729 + SRTP | 64 | 25.6 | 223 | G.729 + SRTP w/ MKI | 68 | 27.2 | 224 | G.729 + DTLS (SRTP-compatibility) | 70 | 28.0 | 225 | G.729 + DTLS | 98 | 39.2 | 226 | G.711 | 200 | 80.0 | 227 | G.711 + SRTP | 204 | 81.6 | 228 | G.711 + SRTP w/ MKI | 208 | 83.2 | 229 | G.711 + DTLS (SRTP-compatibility) | 210 | 84.0 | 230 | G.711 + DTLS | 238 | 95.2 | 231 +-----------------------------------+-------------+---------------+ 233 Note that DTLS with the SRTP-compatibility attributes is 1.09 times 234 the bandwidth of SRTP (without MKI) for G.729 and 1.03 times the 235 bandwidth of SRTP with MKI. It is 1.03 times the bandwidth of SRTP 236 with MKI for G.711 and 1.01 times the bandwidth of SRTP with MKI. 238 7. Security Considerations 239 Because RTP/DTLS runs over DTLS, which is based on TLS, which has 240 seen extensive security analysis, we can have fairly high confidence 241 in the security of the system once the channel is established. 242 Similarly, because DTLS incorporates a handshake mechanism, there is 243 no need to provide for confidentiality of the handshake channel. All 244 that is necessary is to ensure that the communicating peers' 245 certificates are correct. 247 The standard TLS/DTLS strategy for authenticating the communicating 248 parties is to give the server (and optionally the client) a PKIX [2] 249 certificate. The client then verifies the certificate and checks 250 that the name in the certificate matches the server's domain name. 251 This works because there are a relatively small number of servers 252 with well-defined names; a situation which does not usually occur in 253 the VoIP context. 255 An alternative strategy can be used where the certificates are self- 256 signed. When using this approach, the endpoint that acts as a client 257 MUST have a way to verify that the server's certificate is correct 258 and vice-versa. An approach to address this using the Session 259 Initiation Protocol (SIP) [11] and the Session Description Protocol 260 (SDP) [7] is described in SIP for DTLS Media [17] and SDP for DTLS 261 [18] 263 8. IANA Considerations 265 This specification does not require any IANA actions. 267 9. Acknowledgments 269 Jason Fischl and Cullen Jennings contributed substantial text and 270 comments to this document. This document benefitted from discussions 271 with Francois Audet, Nagendra Modadugu, and Dan Wing. Thanks also 272 for useful comments by Flemming Andreasen, Rohan Mahy, David McGrew, 273 and David Oran. 275 10. References 277 10.1. Normative References 279 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 280 Levels", BCP 14, RFC 2119, March 1997. 282 [2] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 283 Public Key Infrastructure Certificate and Certificate Revocation 284 List (CRL) Profile", RFC 3280, April 2002. 286 [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 287 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 288 RFC 3550, July 2003. 290 [4] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 291 Security", draft-rescorla-dtls-05 (work in progress), June 2005. 293 10.2. Informational References 295 [5] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", 296 draft-ietf-tls-rfc2246-bis-13 (work in progress), June 2005. 298 [6] Blake-Wilson, S., "Transport Layer Security (TLS) Extensions", 299 draft-ietf-tls-rfc3546bis-02 (work in progress), October 2005. 301 [7] Handley, M. and V. Jacobson, "SDP: Session Description 302 Protocol", RFC 2327, April 1998. 304 [8] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for 305 Low-Speed Serial Links", RFC 2508, February 1999. 307 [9] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, 308 Telephony Tones and Telephony Signals", RFC 2833, May 2000. 310 [10] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 311 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., 312 Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., 313 Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): 314 Framework and four profiles: RTP, UDP, ESP, and uncompressed", 315 RFC 3095, July 2001. 317 [11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 318 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 319 Session Initiation Protocol", RFC 3261, June 2002. 321 [12] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. 322 Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High 323 Delay, Packet Loss and Reordering", RFC 3545, July 2003. 325 [13] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 326 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 327 RFC 3711, March 2004. 329 [14] Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher Suites 330 for TLS and DTLS", draft-modadugu-tls-ctr-00 (work in 331 progress), October 2005. 333 [15] Modadugu, N. and E. Rescorla, "Extensions for DTLS in Low 334 Bandwidth Environments", draft-modadugu-dtls-short-00 (work in 335 progress), October 2005. 337 [16] Rescorla, E., "TLS Partial Encryption Mode", 338 draft-rescorla-tls-partial-00 (work in progress), January 2006. 340 [17] Fischl, J., Tschofenig, H., and E. Rescorla, "Session 341 Initiation Protocol (SIP) for Media Over Transport Layer 342 Security (TLS)", February 2006. 344 [18] Fischl, J. and H. Tschofenig, "Session Description Protocol 345 (SDP) Indicators for Datagram Transport Layer Security (DTLS)", 346 draft-fischl-mmusic-sdp-dtls-00 (work in progress), 347 February 2006. 349 Appendix A. Packet Header Formats 351 The subsequent figures illustrate the different packet formats and 352 the size of the headers. 354 A.1. SRTP Packet Format 356 This figure shows the SRTP packet format layout. 358 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Ver | IHL | TOS | Length | 360 4 +---------------------------------------------------------------| 361 | Identification | Flags | Fragment Offset | 362 8 +---------------------------------------------------------------| 363 | TTL | Protocol | Header Checksum | 364 12 +---------------------------------------------------------------| 365 | Source IP | 366 16 +---------------------------------------------------------------| 367 | Destination IP | 368 20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Source Port | Destination Port | 370 24 +---------------------------------------------------------------| 371 | Length | Checksum | 372 28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 |V=2|P|X| CC |M| PT | sequence number | 374 32 +---------------------------------------------------------------| 375 | timestamp | 376 36 +---------------------------------------------------------------| 377 | synchronization source (SSRC) identifier | 378 40 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 379 | | G.729 Payload (20ms) | 380 44| |-------------------------------+-------------------------------+ 381 | | G.729 Cont. | 382 48| |-------------------------------+-------------------------------+ 383 | | G.729 Cont. | 384 52| |-------------------------------+-------------------------------+ 385 | | G.729 Cont. | 386 56| |-------------------------------+-------------------------------+ 387 | | G.729 Cont. | 388 60| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | | SRTP MKI (OPTIONAL) | 390 64| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | | authentication tag (RECOMMENDED) | 392 68| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 A.2. DTLS/RTP Packet Format 396 This figure shows the DTLS/RTP packet format layout. 398 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Ver | IHL | TOS | Length | 400 4 +---------------------------------------------------------------| 401 | Identification | Flags | Fragment Offset | 402 8 +---------------------------------------------------------------| 403 | TTL | Protocol | Header Checksum | 404 12 +---------------------------------------------------------------| 405 | Source IP | 406 16 +---------------------------------------------------------------| 407 | Destination IP | 408 20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Source Port | Destination Port | 410 24 +---------------------------------------------------------------| 411 | Length | Checksum | 412 28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Type | Version | epoch-low | 414 32 +---------------------------------------------------------------| 415 | epoc-hi | seq-low-24 | 416 36 +---------------------------------------------------------------| 417 | seq-hi-24 | length-low | 418 40 +---------------------------------------------------------------| 419 | length-hi | xxxxxxxxxx NO BYTES HERE xxxxxxxxxxxxxxxxxxxx 420 41 |---------------------------------------------------------------| 421 | |V=2|P|X| CC |M| PT | sequence number | 422 45| +---------------------------------------------------------------| 423 | | timestamp | 424 49| +---------------------------------------------------------------| 425 | | synchronization source (SSRC) identifier | 426 53| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | | G.729 Payload (20ms) | 428 57| |-------------------------------+-------------------------------+ 429 | | G.729 Cont. | 430 61| |-------------------------------+-------------------------------+ 431 | | G.729 Cont. | 432 65| |-------------------------------+-------------------------------+ 433 | | G.729 Cont. | 434 69| |-------------------------------+-------------------------------+ 435 | | G.729 Cont. | 436 73 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 437 | | HMAC-SHA1 | 438 77| |-------------------------------+-------------------------------+ 439 | | HMAC-SHA1 (cont) | 440 81| |-------------------------------+-------------------------------+ 441 | | HMAC-SHA1 (cont) | 442 85| |-------------------------------+-------------------------------+ 443 | | HMAC-SHA1 (cont) | 444 89| |-------------------------------+-------------------------------+ 445 | | HMAC-SHA1 (cont) | 446 93| |-------------------------------+-------------------------------+ 447 | | PAD | 448 97| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | PAD LEN | XXX NO BYTES | 450 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 A.3. DTLS/RTP Packet Format in SRTP-compatibility mode 454 This figure shows the DTLS/RTP packet with low bandwidth extensions. 456 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Ver | IHL | TOS | Length | 458 4 +---------------------------------------------------------------| 459 | Identification | Flags | Fragment Offset | 460 8 +---------------------------------------------------------------| 461 | TTL | Protocol | Header Checksum | 462 12 +---------------------------------------------------------------| 463 | Source IP | 464 16 +---------------------------------------------------------------| 465 | Destination IP | 466 20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Source Port | Destination Port | 468 24 +---------------------------------------------------------------| 469 | Length | Checksum | 470 28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 |V=2|P|X| CC |M| PT | sequence number | 472 32 +---------------------------------------------------------------| 473 | timestamp | 474 36 +---------------------------------------------------------------| 475 | synchronization source (SSRC) identifier | 476 40 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 477 | | G.729 Payload (20ms) | 478 44| |-------------------------------+-------------------------------+ 479 | | G.729 Cont. | 480 48| |-------------------------------+-------------------------------+ 481 | | G.729 Cont. | 482 52| |-------------------------------+-------------------------------+ 483 | | G.729 Cont. | 484 56| |-------------------------------+-------------------------------+ 485 | | G.729 Cont. | 486 60| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | | SRTP MKI (OPTIONAL) | 488 64| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | | HMAC-SHA1 | 490 68| |-------------------------------+-------------------------------+ 491 | | HMAC-SHA1 (cont) | 492 72| |-------------------------------+-------------------------------+ 493 | | HMAC-SHA1 (cont) | 494 74| |-------------------------------+ 496 Authors' Addresses 498 Hannes Tschofenig 499 Siemens 500 Otto-Hahn-Ring 6 501 Munich, Bavaria 81739 502 Germany 504 Email: Hannes.Tschofenig@siemens.com 506 Eric Rescorla 507 Network Resonance 508 2483 E. Bayshore #212 509 Palo Alto, CA 94303 510 USA 512 Email: ekr@networkresonance.com 514 Intellectual Property Statement 516 The IETF takes no position regarding the validity or scope of any 517 Intellectual Property Rights or other rights that might be claimed to 518 pertain to the implementation or use of the technology described in 519 this document or the extent to which any license under such rights 520 might or might not be available; nor does it represent that it has 521 made any independent effort to identify any such rights. Information 522 on the procedures with respect to rights in RFC documents can be 523 found in BCP 78 and BCP 79. 525 Copies of IPR disclosures made to the IETF Secretariat and any 526 assurances of licenses to be made available, or the result of an 527 attempt made to obtain a general license or permission for the use of 528 such proprietary rights by implementers or users of this 529 specification can be obtained from the IETF on-line IPR repository at 530 http://www.ietf.org/ipr. 532 The IETF invites any interested party to bring to its attention any 533 copyrights, patents or patent applications, or other proprietary 534 rights that may cover technology that may be required to implement 535 this standard. Please address the information to the IETF at 536 ietf-ipr@ietf.org. 538 Disclaimer of Validity 540 This document and the information contained herein are provided on an 541 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 542 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 543 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 544 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 545 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 546 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 548 Copyright Statement 550 Copyright (C) The Internet Society (2006). This document is subject 551 to the rights, licenses and restrictions contained in BCP 78, and 552 except as set forth therein, the authors retain all their rights. 554 Acknowledgment 556 Funding for the RFC Editor function is currently provided by the 557 Internet Society.