idnits 2.17.1 draft-mattsson-perc-srtp-cloud-01.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 (October 19, 2015) is 3112 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) ** Downref: Normative reference to an Informational draft: draft-ietf-avtcore-rtp-topologies-update (ref. 'I-D.ietf-avtcore-rtp-topologies-update') ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PERC J. Mattsson 3 Internet-Draft M. Naslund 4 Intended status: Standards Track M. Westerlund 5 Expires: April 21, 2016 Ericsson 6 October 19, 2015 8 Secure Real-time Transport Protocol (SRTP) for Cloud Services 9 draft-mattsson-perc-srtp-cloud-01 11 Abstract 13 In order to support use cases when two or more end-points communicate 14 via one (or more) cloud service (e.g. virtualized cloud-based 15 conferencing) that are not trusted to access the media content, this 16 document describes the use of so called end-to-end (inner) and hop- 17 by-hop (outer) cryptographic transforms within the Secure Real-time 18 Transport Protocol (SRTP). One of the main aspects of the transforms 19 is to make the confidentiality and message authentication independent 20 of the RTP header. Another central aspect is to enable 21 identification of the cryptographic contexts (keys etc.). Besides 22 the security of the end-points, also trust assumptions regarding the 23 cloud services are addressed. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 21, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. End-To-End Security . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. End-to-End Payload . . . . . . . . . . . . . . . . . . . 4 64 3.2. RTP Header Extensions . . . . . . . . . . . . . . . . . . 6 65 3.3. Replay Protection++ . . . . . . . . . . . . . . . . . . . 7 66 3.4. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.4.1. End-to-End Authenticated RTCP . . . . . . . . . . . . 9 68 3.4.2. End-to-End Confidential RTCP . . . . . . . . . . . . 9 69 4. Hop-by-Hop Security . . . . . . . . . . . . . . . . . . . . . 9 70 5. Inband Key-Distribution . . . . . . . . . . . . . . . . . . . 10 71 6. Group Key-Management . . . . . . . . . . . . . . . . . . . . 11 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 7.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 11 74 7.2. MDD Attacks . . . . . . . . . . . . . . . . . . . . . . . 12 75 7.2.1. Denial of service . . . . . . . . . . . . . . . . . . 12 76 7.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 12 77 7.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 13 78 7.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 13 79 7.2.5. Wrong Meta Data Attack . . . . . . . . . . . . . . . 14 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 83 9.2. Informative References . . . . . . . . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 This document proposes a solution to achieve End-to-End Security for 89 an RTP media streams and its meta data within the context of PERC. 90 However, the document focuses on the RTP e2e protection mechanism. 91 It only puts requirements on the key-management, not proposing a 92 solution for that part. This draft is a complete rewrite, and the 93 proposal is based on what was sent to the PERC mailing list, but 94 substantially updated based on feedback and discussion. 96 The discussion in this document is be based on the analysis of the 97 RTP fields and how they needs to be handled written up in 98 [I-D.westerlund-perc-rtp-field-considerations]. We will assume that 99 the reader is familiar with that discussion. 101 This document assumes a basic model for protection of the data that 102 consists of the following high level functions. A end-to-end media 103 data protection mechanism as defined below in Section 3. An inband 104 key-distribution mechanism to provide endpoints with RTP stream 105 specific keys, assumed to be EKT based, whose requirements are 106 discussed in Section 5. An key-management function that provides 107 authorized endpoints with a EKT master key (Group key) (Section 6). 108 In addition an hop-by-hop security mechanism (Section 4) are in use 109 to protect that not possible to cover end-to-end with protection as 110 necessary between the endpoints and middlboxes (MDD) in the system. 112 2. Definitions 114 This section provides a set of definitions. 116 2.1. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 This document uses the following terms: 124 Endpoint: An RTP stream sending and/or receiving entity that is part 125 of the end-to-end security context. 127 MDD: Media Delivery Device - An RTP middlebox that operates 128 according to any of the three possible RTP topologies 129 [I-D.ietf-avtcore-rtp-topologies-update] that is possible in the 130 PERC system: 132 Transport Translator - Relay 134 Switching RTP Mixer 136 Selective Forwarding Middlebox (SFM) 138 Third Party: An entity that is neither an endpoint nor an MDD. 140 3. End-To-End Security 142 This section discusses the various components of the end-to-end 143 security for the media data, the RTP header fields, RTP header 144 extensions, and media related RTCP messages and information. 146 3.1. End-to-End Payload 148 The end-to-end payload consist of a couple of destinct parts that all 149 needs to be considered: 151 Media Payload: The Media Payload containing the information packed 152 according to the RTP payload format in use. 154 Padding: 0 to 256 bytes of padding octets. Used to obfuscate the 155 RTP payload length when necessary. 157 RTP Header Fields: A number of RTP header fields are closely 158 associated with the media payload. They will be discussed below. 160 The RTP header fields can be classified into several different 161 categoriezes: 163 E2E related, non-changable by MDD: 165 P 167 M 169 Header Extensions 171 E2E related, changable by MDD: 173 PT 175 Sequence number: 177 Timestamp: 179 SSRC/CSRC: Identifying the RTP Stream 181 Header Extensions: 183 Hop-by-hop: 185 V: 187 X: 189 CC: 191 Header Extensions: 193 As can be seen there are some fields that can be closely tied with 194 the payload and which MUST be forwarded by the MDD unaltered. We 195 have other fields that needs to be possible to change by the MDD. 196 For some of these it is critical that a receiving endpoint can learn 197 the original value to verify that the MDD's actions as acceptable. 198 Then there are some fields that are fixed in the protocol like V or 199 otherwise needs to be handled on a hop-by-hop basis. For the X and 200 CC field their value is dependent on the need to carry some field in 201 their corresponding data fields the Extension header and CSRC list 202 respectively. 204 The most problematic fields are the ones that have to be rewritten, 205 but still have important indicator purposes, like PT, SSRC/CSRC, 206 Timestamp and Header Extension IDs. Sequence number is not included, 207 just because we know it is so critical to know the relative order of 208 transmitted packets that this MUST be preserved end-to-end. Original 209 Timestamp we will discuss below in Replay Protection (Section 3.3). 211 Our proposal for the end-to-end media payload is the following: 213 The SSRC is assigned uniquely by a higher management function. For 214 media switching mixers, that original value is preserved using the 215 CSRC field. Any MDD that receives a RTP stream that is a switched 216 one, i.e. the SSRC belongs to the MDD, rather than originating 217 endpoint, and thus contain an CSRC field, will have to copy forward 218 the CSRC value, not the MDD's SSRC value into the produced outgoing 219 packet's CSRC field. 221 Note: We can support MDD that makes SSRC/CSRC translations, but 222 for that to work we strongly recommend to mirror the original SSRC 223 into the inband key-management protocol. This to ensure that the 224 unqiue stream identifier is preserved and can be verified and tied 225 to other functions and verifications. 227 The SSRC/CSRC field will be used by the receiving endpoint as a 228 reference to the security context established by the combination of 229 the RTP packets received and the information from the inband key- 230 management protocol. Any on-path SSRC/CSRC translation will be 231 possible as the receiving endpoint will only use the received value 232 as a reference to the context, not part of the protection operation. 233 The important is that the originating SSRC is consistently handled by 234 the system. 236 Each sent RTP packet from the originating endpoint will have in place 237 of the regular RTP payload an security protected end-to-end payload. 238 This payload will consist of 32-bit of end-to-end sequence number 239 followed by a variable number of bytes of security payload. The 240 security payload is created by applying the cipher (AES-GCM 241 [I-D.ietf-avtcore-srtp-aes-gcm] assumed) with as plaintext: RTP 242 payload format, Padding, and as associated data: P, M, PT (Original), 243 Timestamp (Original), End-to-end header extensions (both 244 confidentiality and only authenticated one in plain text). 246 As Initialization vector (IV) to the cipher the following data is 247 used: HeaderExtFlag (1 bit) : NullFlags(7 bits) : NullPadding (24 248 bits) : Stream Specific Key Sequence Nr (32 bits) : End-to-End 249 Sequence number (32-bit). These values are first concatenated and 250 then XORed with the e2e session salt to form the e2e IV. The stream 251 specific key sequence number combined with the E2E sequence number 252 forms an always increasing value for this particular RTP stream as 253 identified by the unique stream ID (Orignal SSRC). The HeaderExtFlag 254 is set to 0 for protection of the end-to-end payload (this section) 255 and set to 1 for the confidentiality and integrity operation of any 256 RTP header Extensions (Section 3.2). 258 3.2. RTP Header Extensions 260 There exist RTP header extensions that needs to be end-to-end 261 authenticated. For these we want to ensure two important properties. 262 A MDD shall not be able to remove it without detecting the removal, 263 secondly, the integrity of the content of the header extension must 264 be verified. This is proposed by including the header extensions 265 that are marked as requiring end-to-end authentication in the e2e 266 associated data for the packet. 268 This both the advantage and downside of being closely tied to the 269 payload of the packet. This is advantageous as it prevents the MDD 270 from interfeering with the information and when it is provided. 271 However, it prevents the MDD to include relevant meta data in header 272 extensions at its own descretion. One use case for this is Source 273 description information like CNAME and MID that can be included with 274 a stream when a new endpoint joins the conference. 276 A complicating factor is that like the PT (payload type) the ID field 277 for header extensions are dynamically assigned, and the mapping can 278 be endpoint specific. Which requires that the MDD can translate them 279 as needed. This makes it difficult for the receiving endpoint to 280 verify which format the source truly indicated. Preferably one 281 should have a mechanism to indicate the original ID, so that the 282 original value can be included in the associated data. 284 For RTP header extensions that requires confidentiality each header 285 extension's data part is individually encrypted using a stream 286 cipher. AES-GCM is not recommended to use due to the expansion that 287 the internal integrity tag. The key will be the one associated with 288 the source stream ID crypto context. The IV needs to contain: 289 HeaderExtFlag (1 bit = 1) : in packet order : Padding : Stream 290 Specific Key Sequence Nr (32 bits) : End-to-End Sequence number 291 (32-bit). The "in packet order" number is a counter for each header 292 extension included in the packet. So the first header extension gets 293 zero (0), the next one (1), and so on. This results in that an MDD 294 MUST retain the individual order of the header extensions when 295 forwarding them. We also note that by individually protecting each 296 header extension, any header extension where the ID is the 297 information, i.e. without any data there will be no confidentiality. 299 Note: The reason to initially consider this strucutre is that is 300 can avoid forcing a move to 2-byte header extension headers. If 301 one defines a new header extension that wraps all the header 302 extensions including their ID and Lengths then it is likely that 303 this becomes longer than 15 bytes. It also locks in the IDs which 304 forces the receiving endpoint to know how the IDs at the 305 originating source maps to specific extensions. 307 The authentication process for header extension is performed by 308 taking each header extension in the order it was received and 309 concatenate them togehter with the ID and length values in the field 310 form used by two-bytes header extensions, independently which form 311 they where received in. This avoids authentication errors if an MDD 312 needs to switch between one and two bytes header extension format. 313 The ID field is replaced with a null value. Having the original IDs 314 would be preferable, as it would like for the PT enable verification 315 of the intended format. This block of data is included as Associated 316 data in the decryption. 318 3.3. Replay Protection++ 320 This section is called Replay Protection++ as it is not only replay 321 protection that is needed. Yes, replay protection is needed against 322 replay attacks (Section 7.2.2), but also protection against a delayed 323 playout attack (Section 7.2.3). In addition the mechanism needs to 324 be robust against splicing attacks (Section 7.2.4) where the attacker 325 attempts to provide another stream as this source's one. 327 The protection mechanism against these attacks works as follows. 328 First the receiver tracks the source ID associated with a crypto 329 context. Every time a new key is provided by an EKT message the 330 receiver needs to verify that the source ID matches with the one in 331 the context. Next the key sequence number must be larger than stored 332 otherwise the key in the context is kept. 334 When an RTP packet is received the crypto context is retrieved. The 335 context stores the highest end-to-end sequence number received, and a 336 vector indicating which of the last N packets that has been received, 337 this to accept re-ordered packets that is only slightly delayed. It 338 also stores the reception time and corresponding original timestamp 339 value. First it forms the extended e2e sequence number concatinating 340 the key sequence number (from EKT message if included and verified, 341 or from context) with the e2e sequence number. If that is greater 342 than the stored highest seen extended sequence number or within the 343 window of acceptable older packets and not previously received, then 344 the processing continues. 346 Then the time based checks are performed. The reception time delta 347 is compared with the RTP timestamp difference. That difference must 348 be within a error of margin equal to network jitter boundaries and an 349 allowed fudge factor for media switching mixers to align content when 350 switching. The margin of error is no larger than one or two seconds. 351 If the difference is bigger than this MUST be indicated to the user 352 if played out, discarding media is recommended. 354 For this method to be robust clock drift between sender and receiver 355 needs to be tracked, as the RTP timestamp is based on the originating 356 endpoint's clock and the reception time uses the receivers clock. 357 Clock drift is only expected to be a significant issue if there is 358 very long periods when no RTP packets are received with media from a 359 particular sender. Using RTCP SR the receiver can track sample clock 360 versus senders general clock. Every time a timestamped packet is 361 received, SR or RTP they can be used to estimate the relative clock 362 speed difference between endpoints. 364 Next the decryption including authentication is performed. If the 365 received data is validated, then the crypto context is updated with 366 the new highest extended sequence number as well as the time 367 parameters. 369 3.4. RTCP 371 There exist a need for both end-to-end authenticated RTCP messages, 372 as well as end-to-end confidentiality protected ones. When it comes 373 to confidentiality protected ones, these includes end-to-end codec 374 control [RFC5104], such as region of interest [3GPP TS 26.114, 375 version 13.1.0]. The ROI feedback message is used by a receiver to 376 request to view a particular region of the total captured frame. 377 There exist no reason for the MDD to know what region that is 378 requested by which users. If some of the defined RTCP SDES items was 379 to be used, like name, phone, location, and tool, there is 380 significant privacy concerns around those, and they should be 381 transported such that the MDD can't get access to them. Other SDES 382 items like CNAME, MID are meta data related to the session. They can 383 be generated in such a way that there are no privacy concerns with 384 them. However, one would like to ensure that they are integrity 385 protected to prevent any modification on the path from the sender to 386 any receiver. 388 There also appears to be need for end-to-end messages providing vital 389 information about each end-points actions, that can't be modified by 390 the MDD. This is to enable auditing of the MDDs and prevent that 391 they attempt to fool the users of them. For each unique e2e stream 392 id each receiver should know how much packets actually was 393 transmitted, what the current timestamp value, and corresponding wall 394 clock time, preferably in a time base that can be tracked. 396 Below we propose how to address these cases. 398 3.4.1. End-to-End Authenticated RTCP 400 The end-to-end authenticated RTCP is a new RTCP packet type used as 401 authentication wrapper. The new RTCP wrapper packet has the RTCP 402 basic header identifying the packet type, the originating SSRC, the 403 original SSRC (Source ID), a sequence number and an transmission 404 timestamp (NTP format) and includes one or more regular RTCP packets 405 with the information that needs to be end-to-end authenticated. This 406 may lead to that what before would have been multiple items in on 407 RTCP packet, now becomes divided on multiple RTCP packets types based 408 on its security classification. The whole packet with the exception 409 of the originating SSRC field is authenticated (associated data), and 410 the tag (AES-GCM output) located last in the wrapper RTCP packet. 412 3.4.2. End-to-End Confidential RTCP 414 Similar to the e2e authenticated RTCP this packet is also a wrapper 415 for one or more RTCP packets that need to handled confidential end- 416 to-end. The 64 byte common RTPC packet header is not encrypted. 417 This is followed by a original SSRC (Source ID) field, a sequence 418 number used to build the IV for the packet. The part that is 419 confidentiality protected is the transmission timestamp, the RTCP 420 packets (in fully), and any RTCP padding. 422 4. Hop-by-Hop Security 424 We have considered that two different Hop-by-Hop security protocols 425 may be used between an end-point and the MDD, as well as between one 426 MDD and another MDD. Those two protocols are SRTP [RFC3711] and DTLS 428 [RFC6347]. DTLS is included as our analysis 429 [I-D.westerlund-perc-rtp-field-considerations] puts SRTP's design of 430 leaving the RTP header fields in the clear into question in regards 431 to use media confidentiality. To make third party attacks more 432 difficult we would recommend using DTLS over SRTP for the hop-by-hop 433 security. 435 5. Inband Key-Distribution 437 An EKT like inband key-distribution mechanism is assumed. This 438 section discusses information that appear necessary to include in 439 this security layer. 441 The unique source ID MUST be provied in EKT to prevent both denial of 442 service attacks (Section 7.2.1) as well as splicing attacks 443 (Section 7.2.4). The source ID also scopes the key sequence number. 444 The key sequence number is monontionically increased each time the 445 key distributed is changed. This is to prevent replay attacks 446 including the EKT, that would update and replace the current key with 447 an old key. 449 EKT could be used to provide other original field values that are 450 assumed to have static mappings in MDD. Thus, original PT, Header 451 Extension IDs could be provided. 453 While the current EKT mechanism is included in the RTP body of every 454 packet, with a full EKT field sent periodically (e.g. every 100 ms), 455 this may not be the optimal solution for PERC. The MDD will likely 456 have a much better understanding of when an endpoint needs the full 457 EKT field and may store and forward EKT when needed (new key sequence 458 number or new receiving endpoint). This would not only save some 459 bandwidth, but also minimize the time endpoints cannot decrypt 460 because they have not got the latest key. Further optimizations 461 could be to let the endpoint ack the reception of full EKT fields. 462 Letting the control the delivery of full EKT fields can be done with 463 the current EKT model where the full EKT fields are not bound to a 464 specific SRTP packet, but only to a specific stream. 466 When the 32 bits Stream Specific End-to-End Sequence Nr is about to 467 wrap, the sending end-point will have to rekey its transport key by 468 sending a new full EKT field with a new transport key and a bumped up 469 key sequence number. With easy rekeying, we note that 32-bits are 470 sufficient also for really high bit-rates. At 3 Gbps using 1200 471 bytes of payload one need to rekey approximately every 3 hours. 473 6. Group Key-Management 475 In many cases the party controlling the PERC conference will want to 476 limit the ability of participants to decrypt (and modify or inject) 477 media produced before the participant joined or after the participant 478 left. While some conferences will offer recording and allow all 479 participants to decrypt the whole conference, participants modifying 480 or injecting media after they have officially left the conference is 481 not acceptable and must be mitigated. The known solution to this is 482 to change the group EKT key. Either periodically or in conjunction 483 with participants joining or leaving. After each change of the group 484 EKT key, each sending endpoint needs to rekey also the transport key 485 and deliver that to all remaining participants encrypted by the new 486 group key. 488 7. Security Considerations 490 This section discusses various security considerations, especially a 491 number of attacks. 493 7.1. Third Party Attacks 495 While an on-path third party attacker is always able to perform 496 Denial of Service (DoS) Attacks by blocking all or selected packages, 497 the PERC solution should be take measures to mitigate more serious 498 DoS attacks form on-path and off-path attackers. On-path attacks are 499 mitigated by hbh integrity protection and encryption. The integrity 500 protection mitigates packet modification and encryption makes 501 selective blocking of packets harder, but not impossible. 503 Off-path attackers may perform DoS attacks by connecting to different 504 PERC entities and deliver Specificly crafted packets. One potential 505 attack is if an attacker is able to get packets forwarded by the MDD, 506 replacing a legitimate stream from one of the trusted endpoints. If 507 hbh authentication Is not used, such an attack would only be detected 508 in the receiving endpoints where the forged packets would be dropped. 509 It is therefore essential that the MDD (or the call processing node) 510 authenticates the endpoints as being invited members of the 511 conference. 513 Another potential attack is a third party claiming to be an MDD, 514 fooling endpoints points to send packets to the false MDD instead of 515 the correct one. The deceived sending endpoint would then think the 516 packets have been delivered to endpoints when they in fact have not 517 been. If the false MDD can trick several endpoints to connect (or 518 connect as an cascading MDD to another legitimate MDD) it may create 519 a false version of the real conference, giving the connected 520 endpoints a completely distorted view of the conference. To prevent 521 this attack all endpoints and MDDs MUST authenticate other MDDs to 522 ensure that They are legitimate semi-trusted MDDs. 524 7.2. MDD Attacks 526 The MDD can attack the session in a number of possible ways. 528 7.2.1. Denial of service 530 Any modification of the end-to-end authenticated data will result in 531 the receiving endpoint to get an integrity failure when performing 532 authentication on the received packet. 534 The MDD can also attempt perform resource consumption attacks on the 535 receiving endpoint. One such attack would be to provide random SSRC/ 536 CSRC value to any RTP packet with an inband key-distribution message 537 (EKT) attached. As the EKT message enables the receiver to form a 538 new crypto context, the MDD can attempt to consume the receiving 539 endpoints resources. This attack will be possible to detect and 540 mitigate if the EKT messages contains the unique e2e stream id. 542 An denial of service attack is that the MDD rewrites the PT field to 543 another codec. The MDD will usually know which PT corresponds to 544 which codec. The effect of this attack is that an payload packetized 545 and encoded according to one RTP payload format is then processed 546 using another payload format and codec. Assuming that the 547 implementation is robust to random input it is unlikely to cause 548 crashes in the receiving software/hardware. However, it is not 549 unlikely that such rewriting will cause severe media degradations. 550 For audio formats, especially sample based, this attack is likely to 551 cause highly disturbing audio, that can be damaging to hearing and 552 the playout equipment. This draft proposes that the original PT is 553 provided end-to-end. However, without knowledge about the stream 554 source's original media format MIME paraemters for each PT one can't 555 verify correct mapping. Only detect attempts of remapping during the 556 session. 558 7.2.2. Replay Attack 560 Replay attack is when an already received packets from a previous 561 point in the RTP Stream is replayed as new packets. This could for 562 example allow an MDD to transmit a sequence of packets identified as 563 a user saying "yes", instead of the "no" the user actually said. 565 The mitigation for a replay attack is to prevent old packets beyond a 566 small jitter and network re-ordering window to be rejected. The end- 567 to-end replay protection must be provided for the whole duration of 568 the conference and must therefore based on a single monotonically 569 increasing number. The proposal in this document combines an end-to- 570 end sequence number that is incremented with a key-sequence number, 571 thus preventing that the reseting of the end-to-end sequence number 572 when a re-keying occurs to allow old packets from being replayed. 574 7.2.3. Delayed Playout Attack 576 The delayed playout attack is an variant of the replay attack. This 577 attack is possible even if e2e replay protection is in place. 578 However, due to that the MDD is allowed to select a sub-set of 579 streams and not forward the rest to a receiver the receiver has to 580 accept gaps in the e2e packet sequence. The issue with this is that 581 an MDD can select to not deliver a particular stream for a while. 582 Within the window from last packet forward to the receiver and the 583 latest received by the MDD, the MDD can select an arbitrary starting 584 point when resuming forwarding packets. Thus what the media source 585 said, can be substantially delayed at the receiver with the receiver 586 believing that it is what was said just now and only delayed by the 587 transport delay. 589 To prevent this attack, we force the MDD to provide the receiver with 590 the original RTP timestamp authenticated. Thus a receiver can 591 compare the previously received sample's original timesamp with the 592 original timestamp of the recently received sample. The timestamp 593 difference should correspond to the difference in reception times 594 with a maximum allowed variation corresponding to network jitter and 595 a short fudge factor to enable the MDD to align different sources 596 when acting as media switching mixer. Note this calculation will not 597 function if the used RTP payload format switches and the different 598 formats has different RTP timestamp rates. Thus the rules in 599 [RFC7160] MUST be followed. 601 7.2.4. Splicing Attack 603 The splicing attack is an attack where a MDD receiving multiple media 604 sources splices one media stream into the other. If the MDD would be 605 able to change the SSRC without the receiver having any method for 606 verifying the orignal source ID, then the MDD could first deliver 607 stream A. And if the sequence numbers and other information allows 608 it, the MDD can forward stream B under the same SSRC as stream A was 609 previously forwarded. 611 This attack is mitigated by requiring each rtp stream to have unique 612 source IDs that are provided to the receiver. That way the receiver 613 would detect when the source ID switches for these streams. 615 7.2.5. Wrong Meta Data Attack 617 In case of several cascading MDDs, a malicious MDD may send forged 618 meta data to another MDD, either giving the endpoints connected to 619 the second MDD a modified view of what is happening in the conference 620 (like who is speaking) or just degrading the quality of experience 621 for endpoints connected to the second MDD. The false meta data could 622 be any other hbh-protected fields. Especially in cases where two 623 different conference providers or two different vendors of MDDs is 624 involved in the conference, subtle forgeries meant to lower the 625 experience for users of the competing service/MDD might be done. 627 Similar effect could result from honest MDDs having different 628 algorithms, e.g. for selecting active speaker. Minor differences 629 must likely be accepted as long as endpoints connected to different 630 MDDs do not get very different view of what happened in the 631 conference. 633 8. IANA Considerations 635 This document makes no request of IANA. 637 Note to RFC Editor: this section may be removed on publication as an 638 RFC. 640 9. References 642 9.1. Normative References 644 [I-D.ietf-avtcore-rtp-topologies-update] 645 Westerlund, M. and S. Wenger, "RTP Topologies", draft- 646 ietf-avtcore-rtp-topologies-update-10 (work in progress), 647 July 2015. 649 [I-D.ietf-avtcore-srtp-aes-gcm] 650 McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption 651 in Secure RTP (SRTP)", draft-ietf-avtcore-srtp-aes-gcm-17 652 (work in progress), June 2015. 654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 655 Requirement Levels", BCP 14, RFC 2119, 656 DOI 10.17487/RFC2119, March 1997, 657 . 659 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 660 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 661 RFC 3711, DOI 10.17487/RFC3711, March 2004, 662 . 664 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 665 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 666 January 2012, . 668 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 669 Clock Rates in an RTP Session", RFC 7160, 670 DOI 10.17487/RFC7160, April 2014, 671 . 673 9.2. Informative References 675 [I-D.westerlund-perc-rtp-field-considerations] 676 Westerlund, M., "Handling Considerations for the RTP 677 fields in PERC", draft-westerlund-perc-rtp-field- 678 considerations-00 (work in progress), October 2015. 680 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 681 "Codec Control Messages in the RTP Audio-Visual Profile 682 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 683 February 2008, . 685 Authors' Addresses 687 John Mattsson 688 Ericsson AB 689 SE-164 80 Stockholm 690 Sweden 692 Phone: +46 10 71 43 501 693 Email: john.mattsson@ericsson.com 695 Mats Naslund 696 Ericsson AB 697 SE-164 80 Stockholm 698 Sweden 700 Phone: +46 10 71 33 739 701 Email: mats.naslund@ericsson.com 702 Magnus Westerlund 703 Ericsson 704 Farogatan 2 705 SE-164 80 Stockholm 706 Sweden 708 Phone: +46 10 714 82 87 709 Email: magnus.westerlund@ericsson.com