idnits 2.17.1 draft-ietf-avtcore-cryptex-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (10 July 2021) is 1020 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 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCORE J. Uberti 3 Internet-Draft Clubhouse 4 Intended status: Standards Track C. Jennings 5 Expires: 11 January 2022 Cisco 6 S. Garcia Murillo 7 CoSMo 8 10 July 2021 10 Completely Encrypting RTP Header Extensions and Contributing Sources 11 draft-ietf-avtcore-cryptex-02 13 Abstract 15 While the Secure Real-time Transport Protocol (SRTP) provides 16 confidentiality for the contents of a media packet, a significant 17 amount of metadata is left unprotected, including RTP header 18 extensions and contributing sources (CSRCs). However, this data can 19 be moderately sensitive in many applications. While there have been 20 previous attempts to protect this data, they have had limited 21 deployment, due to complexity as well as technical limitations. 23 This document proposes a new mechanism to completely encrypt header 24 extensions and CSRCs as well a simpler signaling mechanism intended 25 to facilitate deployment. 27 Discussion Venues 29 This note is to be removed before publishing as an RFC. 31 Source for this draft and an issue tracker can be found at 32 https://github.com/juberti/cryptex. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 11 January 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Previous Solutions . . . . . . . . . . . . . . . . . . . 4 69 1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 5. RTP Header Processing . . . . . . . . . . . . . . . . . . . . 6 74 5.1. Sending . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 5.2. Receiving . . . . . . . . . . . . . . . . . . . . . . . . 7 76 6. Encryption and Decryption . . . . . . . . . . . . . . . . . . 7 77 6.1. Packet Structure . . . . . . . . . . . . . . . . . . . . 7 78 6.2. Encryption Procedure . . . . . . . . . . . . . . . . . . 8 79 6.3. Decryption Procedure . . . . . . . . . . . . . . . . . . 8 80 7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 9 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 86 11.2. Informative References . . . . . . . . . . . . . . . . . 11 87 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 11 88 A.1. AES-CTR . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 A.1.1. RTP Packet with 1-byte header extension . . . . . . . 11 90 A.1.2. RTP Packet with 2-byte header extension . . . . . . . 12 91 A.1.3. RTP Packet with 1-byte header extension and CSRC 92 fields . . . . . . . . . . . . . . . . . . . . . . . 13 93 A.1.4. RTP Packet with 2-byte header extension and CSRC 94 fields . . . . . . . . . . . . . . . . . . . . . . . 14 96 A.1.5. RTP Packet with empty 1-byte header extension and CSRC 97 fields . . . . . . . . . . . . . . . . . . . . . . . 14 98 A.1.6. RTP Packet with empty 2-byte header extension and CSRC 99 fields . . . . . . . . . . . . . . . . . . . . . . . 15 100 A.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 16 101 A.2.1. RTP Packet with 1-byte header extension . . . . . . . 16 102 A.2.2. RTP Packet with 2-byte header extension . . . . . . . 16 103 A.2.3. RTP Packet with 1-byte header extension and CSRC 104 fields . . . . . . . . . . . . . . . . . . . . . . . 17 105 A.2.4. RTP Packet with 2-byte header extension and CSRC 106 fields . . . . . . . . . . . . . . . . . . . . . . . 18 107 A.2.5. RTP Packet with empty 1-byte header extension and CSRC 108 fields . . . . . . . . . . . . . . . . . . . . . . . 19 109 A.2.6. RTP Packet with empty 2-byte header extension and CSRC 110 fields . . . . . . . . . . . . . . . . . . . . . . . 20 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 113 1. Introduction 115 1.1. Problem Statement 117 The Secure Real-time Transport Protocol [RFC3711] mechanism provides 118 message authentication for the entire RTP packet, but only encrypts 119 the RTP payload. This has not historically been a problem, as much 120 of the information carried in the header has minimal sensitivity 121 (e.g., RTP timestamp); in addition, certain fields need to remain as 122 cleartext because they are used for key scheduling (e.g., RTP SSRC 123 and sequence number). 125 However, as noted in [RFC6904], the security requirements can be 126 different for information carried in RTP header extensions, including 127 the per-packet sound levels defined in [RFC6464] and [RFC6465], which 128 are specifically noted as being sensitive in the Security 129 Considerations section of those RFCs. 131 In addition to the contents of the header extensions, there are now 132 enough header extensions in active use that the header extension 133 identifiers themselves can provide meaningful information in terms of 134 determining the identity of endpoint and/or application. 135 Accordingly, these identifiers can be considered at least slightly 136 sensitive. 138 Finally, the CSRCs included in RTP packets can also be sensitive, 139 potentially allowing a network eavesdropper to determine who was 140 speaking and when during an otherwise secure conference call. 142 1.2. Previous Solutions 144 [RFC6904] was proposed in 2013 as a solution to the problem of 145 unprotected header extension values. However, it has not seen 146 significant adoption, and has a few technical shortcomings. 148 First, the mechanism is complicated. Since it allows encryption to 149 be negotiated on a per-extension basis, a fair amount of signaling 150 logic is required. And in the SRTP layer, a somewhat complex 151 transform is required to allow only the selected header extension 152 values to be encrypted. One of the most popular SRTP implementations 153 had a significant bug in this area that was not detected for five 154 years. 156 Second, it only protects the header extension values, and not their 157 ids or lengths. It also does not protect the CSRCs. As noted above, 158 this leaves a fair amount of potentially sensitive information 159 exposed. 161 Third, it bloats the header extension space. Because each extension 162 must be offered in both unencrypted and encrypted forms, twice as 163 many header extensions must be offered, which will in many cases push 164 implementations past the 14-extension limit for the use of one-byte 165 extension headers defined in [RFC8285]. Accordingly, implementations 166 will need to use two-byte headers in many cases, which are not 167 supported well by some existing implementations. 169 Finally, the header extension bloat combined with the need for 170 backwards compatibility results in additional wire overhead. Because 171 two-byte extension headers may not be handled well by existing 172 implementations, one-byte extension identifiers will need to be used 173 for the unencrypted (backwards compatible) forms, and two-byte for 174 the encrypted forms. Thus, deployment of [RFC6904] encryption for 175 header extensions will typically result in multiple extra bytes in 176 each RTP packet, compared to the present situation. 178 1.3. Goals 180 From this analysis we can state the desired properties of a solution: 182 * Build on existing [RFC3711] SRTP framework (simple to understand) 184 * Build on existing [RFC8285] header extension framework (simple to 185 implement) 187 * Protection of header extension ids, lengths, and values 189 * Protection of CSRCs when present 190 * Simple signaling 192 * Simple crypto transform and SRTP interactions 194 * Backward compatible with unencrypted endpoints, if desired 196 * Backward compatible with existing RTP tooling 198 The last point deserves further discussion. While we considered 199 possible solutions that would have encrypted more of the RTP header 200 (e.g., the number of CSRCs), we felt the inability to parse the 201 resultant packets with current tools, as well as additional 202 complexity incurred, outweighed the slight improvement in 203 confidentiality. 205 2. Terminology 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in [RFC2119]. 211 3. Design 213 This specification proposes a mechanism to negotiate encryption of 214 all RTP header extensions (ids, lengths, and values) as well as CSRC 215 values. It reuses the existing SRTP framework, is accordingly simple 216 to implement, and is backward compatible with existing RTP packet 217 parsing code, even when support for this mechanism has been 218 negotiated. 220 4. Signaling 222 In order to determine whether this mechanism defined in this 223 specification is supported, this document defines a new "a=cryptex" 224 Session Description Protocol (SDP) [RFC4566] attribute to indicate 225 support. This attribute takes no value, and can be used at the 226 session level or media level. Offering this attribute indicates that 227 the endpoint is capable of receiving RTP packets encrypted as defined 228 below. 230 The formal definition of this attribute is: 232 Name: cryptex 234 Value: None 236 Usage Level: session, media 238 Charset Dependent: No 240 Example: 242 a=cryptex 244 When used with BUNDLE, this attribute is assigned to the TRANSPORT 245 category [RFC8859]. 247 5. RTP Header Processing 249 [RFC8285] defines two values for the "defined by profile" field for 250 carrying one-byte and two-byte header extensions. In order to allow 251 a receiver to determine if an incoming RTP packet is using the 252 encryption scheme in this specification, two new values are defined: 254 * 0xC0DE for the encrypted version of the one-byte header extensions 255 (instead of 0xBEDE). 257 * 0xC2DE for the encrypted versions of the two-byte header 258 extensions (instead of 0x100). 260 In the case of using two-byte header extensions, the extension id 261 with value 256 MUST NOT be negotiated, as the value of this id is 262 meant to be contained in the "appbits" of the "defined by profile" 263 field, which are not available when using the values above. 265 If the "a=extmap-allow-mixed" attribute defined in [RFC8285] is 266 negotiated, either one-byte or two-byte header ids can be used (with 267 the values above), as in [RFC8285]. 269 5.1. Sending 271 When the mechanism defined by this specification has been negotiated, 272 sending a RTP packet that has any CSRCs or contains any {RFC8285}} 273 header extensions follows the steps below. This mechanism MUST NOT 274 be used with header extensions other than the [RFC8285] variety. 276 If the packet contains solely one-byte extension ids, the 16-bit RTP 277 header extension tag MUST be set to 0xC0DE to indicate that the 278 encryption has been applied, and the one-byte framing is being used. 279 If the packet contains only two-byte extension ids, the header 280 extension tag MUST be set to 0xC2DE to indicate encryption has been 281 applied, and the two-byte framing is being used. 283 If the packet contains CSRCs but no header extensions, an empty 284 extension block consisting of the 0xC0DE tag and a 16-bit length 285 field set to zero (explicitly permitted by [RFC3550]) MUST be 286 appended, and the X bit MUST be set to 1 to indicate an extension 287 block is present. This is necessary to provide the receiver an 288 indication that the CSRCs in the packet are encrypted. 290 The RTP packet MUST then be encrypted as described in Encryption 291 Procedure. 293 5.2. Receiving 295 When receiving an RTP packet that contains header extensions, the 296 "defined by profile" field MUST be checked to ensure the payload is 297 formatted according to this specification. If the field does not 298 match one of the values defined above, the implementation MUST 299 instead handle it according to the specification that defines that 300 value. The implemntation MAY stop and report an error if it 301 considers use of this specification mandatory for the RTP stream. 303 If the RTP packet passes this check, it is then decrypted according 304 to Decryption Procedure, and passed to the the next layer to process 305 the packet and its extensions. In the event that a zero-length 306 extension block was added as indicated above, it can be left as-is 307 and will be processed normally. 309 6. Encryption and Decryption 311 6.1. Packet Structure 313 When this mechanism is active, the SRTP packet is protected as 314 follows: 316 0 1 2 3 317 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 319 |V=2|P|X| CC |M| PT | sequence number | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 321 | timestamp | | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 323 | synchronization source (SSRC) identifier | | 324 +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 325 | | contributing source (CSRC) identifiers | | 326 | | .... | | 327 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 328 X | 0xC0 | 0xDE | length=3 | | 329 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 330 | | RFC 8285 header extensions | | 331 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 332 | | payload ... | | 333 | | +-------------------------------+ | 334 | | | RTP padding | RTP pad count | | 335 +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ 336 | ~ SRTP MKI (OPTIONAL) ~ | 337 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 338 | : authentication tag (RECOMMENDED) : | 339 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 340 | | 341 +- Encrypted Portions* Authenticated Portion ---+ 343 * Note that the 4 bytes at the start of the extension block are not 344 encrypted, as required by [RFC8285]. 346 Specifically, the encrypted portion MUST include any CSRC 347 identifiers, any RTP header extension (except for the first 4 bytes), 348 and the RTP payload. 350 6.2. Encryption Procedure 352 The encryption procedure is identical to that of [RFC3711] except for 353 the region to encrypt, which is as shown in the section above. 355 To minimize changes to surrounding code, the encryption mechanism can 356 choose to replace a "defined by profile" field from [RFC8285] with 357 its counterpart defined in RTP Header Processing above and encrypt at 358 the same time. 360 6.3. Decryption Procedure 362 The decryption procedure is identical to that of [RFC3711] except for 363 the region to decrypt, which is as shown in the section above. 365 To minimize changes to surrounding code, the decryption mechanism can 366 choose to replace the "defined by profile" field with its no- 367 encryption counterpart from [RFC8285] and decrypt at the same time. 369 7. Backwards Compatibility 371 This specification attempts to encrypt as much as possible without 372 interfering with backwards compatibility for systems that expect a 373 certain structure from an RTPv2 packet, including systems that 374 perform demultiplexing based on packet headers. Accordingly, the 375 first two bytes of the RTP packet are not encrypted. 377 This specification also attempts to reuse the key scheduling from 378 SRTP, which depends on the RTP packet sequence number and SSRC 379 identifier. Accordingly these values are also not encrypted. 381 8. Security Considerations 383 This specification extends SRTP by expanding the portion of the 384 packet that is encrypted, as shown in Packet Structure. It does not 385 change how SRTP authentication works in any way. Given that more of 386 the packet is being encrypted than before, this is necessarily an 387 improvement. 389 The RTP fields that are left unencrypted (see rationale above) are as 390 follows: 392 * RTP version 394 * padding bit 396 * extension bit 398 * number of CSRCs 400 * marker bit 402 * payload type 404 * sequence number 406 * timestamp 408 * SSRC identifier 410 * number of [RFC8285] header extensions 411 These values contain a fixed set (i.e., one that won't be changed by 412 extensions) of information that, at present, is observed to have low 413 sensitivity. In the event any of these values need to be encrypted, 414 SRTP is likely the wrong protocol to use and a fully-encapsulating 415 protocol such as DTLS is preferred (with its attendant per-packet 416 overhead). 418 9. IANA Considerations 420 This document defines two new 'defined by profile' attributes, as 421 noted in RTP Header Processing. 423 10. Acknowledgements 425 The authors wish to thank Lennart Grahl for pointing out many of the 426 issues with the existing header encryption mechanism, as well as 427 suggestions for this proposal. Thanks also to Jonathan Lennox and 428 Inaki Castillo for their review and suggestions. 430 11. References 432 11.1. Normative References 434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", BCP 14, RFC 2119, 436 DOI 10.17487/RFC2119, March 1997, 437 . 439 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 440 Jacobson, "RTP: A Transport Protocol for Real-Time 441 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 442 July 2003, . 444 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 445 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 446 RFC 3711, DOI 10.17487/RFC3711, March 2004, 447 . 449 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 450 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 451 July 2006, . 453 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 454 Mechanism for RTP Header Extensions", RFC 8285, 455 DOI 10.17487/RFC8285, October 2017, 456 . 458 [RFC8859] Nandakumar, S., "A Framework for Session Description 459 Protocol (SDP) Attributes When Multiplexing", RFC 8859, 460 DOI 10.17487/RFC8859, January 2021, 461 . 463 11.2. Informative References 465 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 466 Transport Protocol (RTP) Header Extension for Client-to- 467 Mixer Audio Level Indication", RFC 6464, 468 DOI 10.17487/RFC6464, December 2011, 469 . 471 [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- 472 time Transport Protocol (RTP) Header Extension for Mixer- 473 to-Client Audio Level Indication", RFC 6465, 474 DOI 10.17487/RFC6465, December 2011, 475 . 477 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 478 Real-time Transport Protocol (SRTP)", RFC 6904, 479 DOI 10.17487/RFC6904, April 2013, 480 . 482 Appendix A. Test Vectors 484 All values are in hexadecimal and represented in network order (big 485 endian). 487 A.1. AES-CTR 489 Common values are organized as follows: 491 Rollover Counter: 00000000 492 Master Key: e1f97a0d3e018be0d64fa32c06de4139 493 Master Salt: 0ec675ad498afeebb6960b3aabe6 494 Crypto Suite: AES_CM_128_HMAC_SHA1_80 495 Session Key: c61e7a93744f39ee10734afe3ff7a087 496 Session Salt: 30cbbc08863d8c85d49db34a9ae1 497 Authentication Key: cebe321f6ff7716b6fd4ab49af256a156d38baa4 499 A.1.1. RTP Packet with 1-byte header extension 501 RTP Packet: 503 900f1235 504 decafbad 505 cafebabe 506 bede0001 507 51000200 508 abababab 509 abababab 510 abababab 511 abababab 513 Encrypted RTP Packet: 515 900f1235 516 decafbad 517 cafebabe 518 c0de0001 519 eb923652 520 51c3e036 521 f8de27e9 522 c27ee3e0 523 b4651d9f 524 bc4218a7 525 0244522f 526 34a5 528 A.1.2. RTP Packet with 2-byte header extension 530 RTP Packet: 532 900f1236 533 decafbad 534 cafebabe 535 10000001 536 05020002 537 abababab 538 abababab 539 abababab 540 abababab 542 Encrypted RTP Packet: 544 900f1236 545 decafbad 546 cafebabe 547 c2de0001 548 4ed9cc4e 549 6a712b30 550 96c5ca77 551 339d4204 552 ce0d7739 553 6cab6958 554 5fbce381 555 94a5 557 A.1.3. RTP Packet with 1-byte header extension and CSRC fields 559 RTP Packet: 561 920f1238 562 decafbad 563 cafebabe 564 0001e240 565 0000b26e 566 bede0001 567 51000200 568 abababab 569 abababab 570 abababab 571 abababab 573 Encrypted RTP Packet: 575 920f1238 576 decafbad 577 cafebabe 578 8bb6e12b 579 5cff16dd 580 c0de0001 581 92838c8c 582 09e58393 583 e1de3a9a 584 74734d67 585 45671338 586 c3acf11d 587 a2df8423 588 bee0 590 A.1.4. RTP Packet with 2-byte header extension and CSRC fields 592 RTP Packet: 594 920f1239 595 decafbad 596 cafebabe 597 0001e240 598 0000b26e 599 10000001 600 05020002 601 abababab 602 abababab 603 abababab 604 abababab 606 Encrypted RTP Packet: 608 920f1239 609 decafbad 610 cafebabe 611 f70e513e 612 b90b9b25 613 c2de0001 614 bbed4848 615 faa64466 616 5f3d7f34 617 125914e9 618 f4d0ae92 619 3c6f479b 620 95a0f7b5 621 3133 623 A.1.5. RTP Packet with empty 1-byte header extension and CSRC fields 625 RTP Packet: 627 920f123a 628 decafbad 629 cafebabe 630 0001e240 631 0000b26e 632 bede0000 633 abababab 634 abababab 635 abababab 636 abababab 638 Encrypted RTP Packet: 640 920f123a 641 decafbad 642 cafebabe 643 7130b6ab 644 fe2ab0e3 645 c0de0000 646 e3d9f64b 647 25c9e74c 648 b4cf8e43 649 fb92e378 650 1c2c0cea 651 b6b3a499 652 a14c 654 A.1.6. RTP Packet with empty 2-byte header extension and CSRC fields 656 RTP Packet: 658 920f123b 659 decafbad 660 cafebabe 661 0001e240 662 0000b26e 663 10000000 664 abababab 665 abababab 666 abababab 667 abababab 669 Encrypted RTP Packet: 671 920f123b 672 decafbad 673 cafebabe 674 cbf24c12 675 4330e1c8 676 c2de0000 677 599dd45b 678 c9d687b6 679 03e8b59d 680 771fd38e 681 88b170e0 682 cd31e125 683 eabe 685 A.2. AES-GCM 687 Common values are organized as follows: 689 Rollover Counter: 00000000 690 Master Key: 000102030405060708090a0b0c0d0e0f 691 Master Salt: a0a1a2a3a4a5a6a7a8a9aaab 692 Crypto Suite: AEAD_AES_128_GCM 693 Session Key: 077c6143cb221bc355ff23d5f984a16e 694 Session Salt: 9af3e95364ebac9c99c5a7c4 696 A.2.1. RTP Packet with 1-byte header extension 698 RTP Packet: 700 900f1235 701 decafbad 702 cafebabe 703 bede0001 704 51000200 705 abababab 706 abababab 707 abababab 708 abababab 710 Encrypted RTP Packet: 712 900f1235 713 decafbad 714 cafebabe 715 c0de0001 716 39972dc9 717 572c4d99 718 e8fc355d 719 e743fb2e 720 94f9d8ff 721 54e72f41 722 93bbc5c7 723 4ffab0fa 724 9fa0fbeb 726 A.2.2. RTP Packet with 2-byte header extension 728 RTP Packet: 730 900f1236 731 decafbad 732 cafebabe 733 10000001 734 05020002 735 abababab 736 abababab 737 abababab 738 abababab 740 Encrypted RTP Packet: 742 900f1236 743 decafbad 744 cafebabe 745 c2de0001 746 bb75a4c5 747 45cd1f41 748 3bdb7daa 749 2b1e3263 750 de313667 751 c9632490 752 81b35a65 753 f5cb6c88 754 b394235f 756 A.2.3. RTP Packet with 1-byte header extension and CSRC fields 758 RTP Packet: 760 920f1238 761 decafbad 762 cafebabe 763 0001e240 764 0000b26e 765 bede0001 766 51000200 767 abababab 768 abababab 769 abababab 770 abababab 772 Encrypted RTP Packet: 774 920f1238 775 decafbad 776 cafebabe 777 63bbccc4 778 a7f695c4 779 c0de0001 780 8ad7c71f 781 ac70a80c 782 92866b4c 783 6ba98546 784 ef913586 785 e95ffaaf 786 fe956885 787 bb0647a8 788 bc094ac8 790 A.2.4. RTP Packet with 2-byte header extension and CSRC fields 792 RTP Packet: 794 920f1239 795 decafbad 796 cafebabe 797 0001e240 798 0000b26e 799 10000001 800 05020002 801 abababab 802 abababab 803 abababab 804 abababab 806 Encrypted RTP Packet: 808 920f1239 809 decafbad 810 cafebabe 811 3680524f 812 8d312b00 813 c2de0001 814 c78d1200 815 38422bc1 816 11a7187a 817 18246f98 818 0c059cc6 819 bc9df8b6 820 26394eca 821 344e4b05 822 d80fea83 824 A.2.5. RTP Packet with empty 1-byte header extension and CSRC fields 826 RTP Packet: 828 920f123a 829 decafbad 830 cafebabe 831 0001e240 832 0000b26e 833 bede0000 834 abababab 835 abababab 836 abababab 837 abababab 839 Encrypted RTP Packet: 841 920f123a 842 decafbad 843 cafebabe 844 15b6bb43 845 37906fff 846 c0de0000 847 b7b96453 848 7a2b03ab 849 7ba5389c 850 e9331712 851 6b5d974d 852 f30c6884 853 dcb651c5 854 e120c1da 856 A.2.6. RTP Packet with empty 2-byte header extension and CSRC fields 858 RTP Packet: 860 920f123b 861 decafbad 862 cafebabe 863 0001e240 864 0000b26e 865 10000000 866 abababab 867 abababab 868 abababab 869 abababab 871 Encrypted RTP Packet: 873 920f123b 874 decafbad 875 cafebabe 876 dcb38c9e 877 48bf95f4 878 c2de0000 879 61ee432c 880 f9203170 881 76613258 882 d3ce4236 883 c06ac429 884 681ad084 885 13512dc9 886 8b5207d8 888 Authors' Addresses 890 Justin Uberti 891 Clubhouse 893 Email: justin@uberti.name 895 Cullen Jennings 896 Cisco 898 Email: fluffy@iii.ca 899 Sergio Garcia Murillo 900 CoSMo 902 Email: sergio.garcia.murillo@cosmosoftware.io