idnits 2.17.1 draft-westerlund-perc-rtp-field-considerations-00.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 3111 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-avtext-sdes-hdr-ext-02 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-23 -- Obsolete informational reference (is this intentional?): RFC 5285 (Obsoleted by RFC 8285) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Westerlund 3 Internet-Draft Ericsson 4 Intended status: Informational October 19, 2015 5 Expires: April 21, 2016 7 Handling Considerations for the RTP fields in PERC 8 draft-westerlund-perc-rtp-field-considerations-00 10 Abstract 12 This draft discusses how the Privacy Enhanced RTP Conferencing 13 solution will need consider the different RTP header fields in 14 regards to both hop-by-hop and end-to-end security. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 21, 2016. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Connection Case . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. Additional Assumptions . . . . . . . . . . . . . . . . . 4 54 3. RTP Packets Fields . . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Version Field (V) . . . . . . . . . . . . . . . . . . . . 4 56 3.2. Padding Indicator bit (P) . . . . . . . . . . . . . . . . 5 57 3.3. Extension Indicator bit (X) . . . . . . . . . . . . . . . 6 58 3.4. CSRC Count (CC) . . . . . . . . . . . . . . . . . . . . . 6 59 3.5. Marker Bit (M) . . . . . . . . . . . . . . . . . . . . . 7 60 3.6. Payload Type (PT) . . . . . . . . . . . . . . . . . . . . 8 61 3.7. Sequence Number . . . . . . . . . . . . . . . . . . . . . 9 62 3.8. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 10 63 3.9. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 3.10. CSRC List . . . . . . . . . . . . . . . . . . . . . . . . 12 65 3.11. Header Extensions . . . . . . . . . . . . . . . . . . . . 12 66 3.11.1. Transmission Time offsets . . . . . . . . . . . . . 13 67 3.11.2. SMPTE time-code mapping . . . . . . . . . . . . . . 13 68 3.11.3. Synchronisation metadata . . . . . . . . . . . . . . 14 69 3.11.4. Client to Mixer Audio Level . . . . . . . . . . . . 14 70 3.11.5. Mixer-to-client audio level . . . . . . . . . . . . 14 71 3.11.6. Coordination of video orientation (CVO) . . . . . . 14 72 3.11.7. Region-of-interest (ROI) . . . . . . . . . . . . . . 15 73 3.11.8. SDES Information . . . . . . . . . . . . . . . . . . 15 74 3.12. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 3.13. Padding Octets . . . . . . . . . . . . . . . . . . . . . 16 76 4. Summery . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 79 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 81 9. Informative References . . . . . . . . . . . . . . . . . . . 18 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 84 1. Introduction 86 In the design of the Privacy Enchanced RTP Conferencing (PERC) end- 87 to-end security solution for RTP [RFC3550] media streams there is 88 need to carefully consider what properties the different RTP fields 89 have, their security and privacy implications, and provide 90 recommendations and requiremements for how they are handled. This 91 review needs to consider both hop-by-hop properties as well as the 92 end-to-end security. 94 The fields analysed are that of a regular RTP packet. This is to 95 consider the impact of the information that exists normally in an 96 centralized multi-party conference. 98 This document is a working document, and not intended to be published 99 as an RFC. 101 2. Definitions 103 This document uses the following definitions: 105 Endpoint: An RTP stream sending and/or receiving entity that is part 106 of the end-to-end security context. 108 MDD: Media Delivery Device - An RTP middlebox that operates 109 according to any of the three possible RTP topologies 110 [I-D.ietf-avtcore-rtp-topologies-update] that is possible in the 111 PERC system: 113 Transport Translator - Relay 115 Switching RTP Mixer 117 Selective Forwarding Middlebox (SFM) 119 Third Party: An entity that is neither an endpoint nor an MDD. 121 2.1. Connection Case 123 This analys is based on a basic connectivity use cases, where a media 124 stream sending endpoint (originating) sends one or more RTP streams 125 to a MDD. That MDD selectively forwards media to another MDD 126 (Cascaded) which further sends the media (when selecting to) from the 127 originating endpoint to the receiving endpoint. This connection case 128 is depicted in Figure 1. 130 +-------------+ +------+ +------+ +-----------+ 131 | | | | | | | | 132 | Originating +---->+ MDD +---->+ MDD +---->+ Receiving | 133 | Endpoint | | | | | | Endpoint | 134 | | | | | | | | 135 +-------------+ +------+ +------+ +-----------+ 137 Figure 1 139 The MDDs are not trusted with anything except forwarding media 140 according to the policies given to it by endpoints and to not forward 141 media from third parties. 143 2.2. Additional Assumptions 145 This document assumes that the originating media stream is uniquely 146 identified by the SSRC value used by the originating endpoint. This 147 SSRC value needs to be preserved to the receiving endpoint. It is 148 assumed that even if SSRC/CSRC translation is in use by an MDD, there 149 will exist an one to one mapping between originating SSRC value and 150 the SSRC/CSRC value the receiving endpoint receives. Further for 151 MDDs operating as Media Switching RTP mixers they will indicate the 152 originating SSRC as CSRC when it switches that stream into one of the 153 MDD's SSRCs. The CSRC will need to be maintained even over multiple 154 MDDs. 156 3. RTP Packets Fields 158 This section analyses each RTP packet field or part. The anlysis for 159 each field should answer the following questions: 161 Can it or needs to be modified on path by an MDD? 163 Does the receiving endpoint need the originating endpoint's set 164 value? 166 Does it need end-to-end authentication? 168 Does it need end-to-end confidentiality? 170 Does it need hop-by-hop authentication? 172 Does it need hob-by-hop confidentiality? 174 As a general rule, the only reason to encrypt something without 175 integrity Protection is to save the overhead of the tag. As the PERC 176 Solution will have both hbh tag and e2e tag, no overhead is saved by 177 not integrity protecting so as a general rule confidentiality implies 178 authentication. 180 Some general considerations apply. Fields that are end-to-end 181 authenticated is actually recommended to be hop-by-hop authenticated, 182 even when there only are a end-to-end version of the field. The 183 reason for this is to detect modifications at the earliest instance 184 and avoid wasting resource further down the path. 186 3.1. Version Field (V) 188 As the solution is focused on RTP as defined by [RFC3550] this field 189 must be 2. The field is not expected to be modified by an MDD. The 190 receiving endpoint will also assume that the originating endpoint 191 used RTP (v=2). Modification of this field should result in the 192 packet being dropped by the receiving endpoint or MDD, independent if 193 it is hop-by-hop authenticated. The version field does not require 194 end-to-end authentication as the MDD has more efficient denial of 195 service attacks that it can perform on the endpoints, including not 196 forwarding a single media packet/stream. The field can not be 197 confidentiality protected end-to-end as the MDD must know that it is 198 RTP (v=2) it receives. The field may be hop-by-hop confidentiality 199 protected as part of an attempt to hide that the packet stream is 200 RTP, although packet analysis is likely to reveal that the streams 201 are real-time media anyway. 203 If ever an RTP v=3 is defined in the future it is clear that one 204 particular version must be used per hop. It is not possible to 205 predict if it would be possible to have the end-to-end information 206 translated between one hop using v=2 and one using v=3. If such 207 translation and e2e authentication would be performed, the receiving 208 entity must be aware of it, to know that the field's value is not the 209 original one. Thus, it becomes a choice if one want to require 210 explicit knowledge of the translation, or not demand it by excluding 211 the field from end-to-end authentication. 213 3.2. Padding Indicator bit (P) 215 The padding bit is an indicator for the presence of the padding 216 octets at the end of the RTP payload. As further discussed in 217 Padding Octets (Section 3.13) the padding is considered part of the 218 payload and jointly protected with the payload. The reason for this 219 is that padding can help hide length variations in the payload that 220 can leak information about the media content being carried [RFC6562]. 222 As the Payload and padding octets are end-to-end protected, the 223 padding indicator can't be modified by the MDD, due to its inability 224 to remove the padding octets. For correct processing in the 225 receiving endpoint the padding indicator needs to be correct. 226 Therefore it should be end-to-end authenticated. It could be end-to- 227 end confidentiality protected. The benefit of protecting it end-to- 228 end would be that the MDD would not know if the end-to-end payload is 229 padded or not. Knowing if the payload is padded or not reduces the 230 uncertainty for an attacker that attempts to perform content analysis 231 based on payload length. Because of that it would beneficial to 232 protect the padding bit also hop-by-hop, if not already protected 233 end-to-end. The padding bit should be hop-by-hop authenticated to 234 protect if end-to-end authentication is not used. 236 3.3. Extension Indicator bit (X) 238 The extension indicator bit indicates if the header extension part is 239 present. The MDD will be the target recipient of some RTP header 240 extensions. It can also remove the ones not necessary to reach the 241 receiving endpoint. This can result that something starting out with 242 header extensions may no longer have any on the last hop. Thus, the 243 MDD must be able to modify the X bit. Currently, there is no strong 244 argument for why a receiving endpoint needs to know that there where 245 header extensions present from the originating endpoint that has been 246 removed. It might arise when using end-to-end protected header 247 extensions and want to ensure detection of removal of such header 248 extensions by the MDD. However, other methods for ensuring that 249 exist, most likley by authenticating the end-to-end header extensions 250 themselves. Conclusion is that there are no need for knowing the 251 original value. 253 There are no need for end-to-end confidentiality, nor authentication. 254 Hop-by-hop authentication shall be used to prevent unnecesary 255 erronous processing of the packet. Hop-by-hop confidentiality is 256 recommended but lack of it has very minor impact as the information 257 leaked is the presence or not of header extensions. Having this 258 knowledge may simplify payload length based attacks in regards to the 259 content. 261 3.4. CSRC Count (CC) 263 Contributing Sources count indicates how many CSRC values that are 264 part of the CSRC field and are critical to know to correctly find the 265 start of the payload within the RTP packet. When using MDDs that 266 follow the Media Switching RTP Mixer topology (Section 3.6.2 of 267 [I-D.ietf-avtcore-rtp-topologies-update]) the MDD will need to insert 268 the originating endpoint's SSRC as CSRC value in the outgoing stream 269 when that stream contains a payload from the by the CSRC identified 270 originating stream. This results that in the MDD can modify and add 271 CSRC fields when performing switching. And in cases an MDD operating 272 like a SFM (Section 3.7 of [I-D.ietf-avtcore-rtp-topologies-update]) 273 receives a switched media stream it may attempt to restore the mixed 274 stream into a number of SSRC specific streams, thus removing the CSRC 275 field. An originating endpoint is unlikely to have a need to insert 276 an CSRC, this as in PERC context it is expected that the media 277 sources have a direct relation to the endpoint. The need for an 278 endpoint to express that it generates a mixed or switched stream 279 where it can generate "end-to-end" secured payload with such 280 properties appear to be in a violation of the intended security 281 model. The current conclusion will be no need for orignal value. 283 Note: The possibility for originating endpoints to create a CSRC 284 list will need further discussion as it affects the possibility to 285 rely on the SSRC/CSRC value as reference to the originating 286 identity. 288 The CC field does not appear to need end-to-end authenticated, nor 289 confidentiality protected. The CC field shall be hop-by-hop 290 authenticated to prevent third party modifcations as it effects 291 finding the payload limit. Errors here can only lead to wasting 292 resources for further entities in the conference, and should be 293 detected as early as possible. Erronous payload delimitation due to 294 error in the CC field will result in the receiving endpoint's 295 integrity verification of the end-to-end payload will fail. Hop-by- 296 hop confidentiality is recommened as the CC field allows a third 297 party to better determine the RTP payload size, thus being 298 information with some privacy sensitivity 300 3.5. Marker Bit (M) 302 The marker bit semantics are dependent on the RTP payload format in 303 use. Two dominant semantics are in use, but not limited to these 304 two. Video primarily use it to indicate the last packet carrying 305 part of an encoded video frame. Audio primarily use it to indicate 306 the start of a talk spurt, indicating where an receiver could adjust 307 its jitter buffer and playout. 309 The MDD could depending on semantics potentially have an interest in 310 setting the marker. One example could be an MDD that like to set an 311 marker bit for audio to indicate the start of a media stream when 312 swtiching in/on a particular originating endpoint's stream. In the 313 discussion about this for PERC the conclusion is that an MDD can use 314 other methods for indicating the switch in event. The main argument 315 for this is to avoid having to understand the semantics of the 316 payload currently present. Especially as codec switches can change 317 the semantics in the middle of an ongoing conference session. The 318 marker bit is meta data about the stream that can be relevant for 319 knowing where appropriate switching points are, depending on the 320 semantics. 322 The receiving endpoint's need for original value from the originating 323 endpoint is dependent on the semantics. However, for many semantics 324 it is important for the originating value is know by the receiving 325 endpoint. Therefore the recommendation is to require the originating 326 value to be made available to the receiving endpoint. 328 The recommendation is to use end-to-end authenticaiton of the value. 329 End-to-end confidentiality needs exits as the marker bit can carry 330 semantics direclty related to the content encoded. Audio's common 331 semantics as start of speech burst, is telling the passive monitoring 332 something on the ongoing flow of information. This needs to be 333 balanced against the potential needs for the MDD to have this 334 information for better function, like knowing where to switch. 336 The marker bit should be both hop-by-hop authenticated as well as 337 confidentiality protected. This is to prevent modification of this 338 important piece of information to avoid that the MDD react to 339 manipulated data. The confidentiality is there to prevent third 340 parties from learning the information, potentially privacy sensitive. 342 3.6. Payload Type (PT) 344 The payload type identies the RTP payload format and thus normally 345 the encoding of the media content in the payload. The dominant usage 346 is to use some type of signalling protocol to agree on a mapping 347 between a payload format and its parameters following the payload 348 formats MIME type and the 7-bit field values. There exist some 349 statically assigned codecs, but these values can still be assigned to 350 other payload format configurations by the signalling. 352 The MDD is expected to be required to rewrite the PT values when 353 forwarding the payloads. The reason for this is that in many 354 signalling contexts the binding between a payload type value and the 355 payload format configuration will only have local meaning. And the 356 PT value identifying a particular codec configuration is not unlikely 357 a different PT value with another endpoint. Thus, the MDD will need 358 to maintain translation tables for each ingress and egress pair. 360 As knowing the correct payload format and codec configuration is 361 cruical to be able to correctly decode the received payload, it is in 362 the interest of the receiving endpoint to know the originating 363 payload format and codec configuration. This would indicate a need 364 to know the original value of the PT field. Unfortunately that is 365 not sufficient to securly verify that no malicious changes has 366 occurded on the path by a third party or the MDDs. The receiving 367 endpoint would need to know also how the originating PT values map 368 against the payload format and its parameters to verify correctness. 370 End-to-end authentication of original value is recommended, given 371 that the receiving endpoint also get the payload format 372 configuration. End-to-end confidentiality would be desirable as it 373 simplifies for an attacker to know which codec is used, or at least 374 detect when the codec changes. When doing content analytics it 375 simplifies to know the codec, so the codecs behaviour can be 376 accounted for. However, this is not cruical information, and it 377 appears very difficult to confidentiality protect the PT field value 378 in respect to the MDD. 380 Hop-by-hop authentication is important to prevent thrid-party 381 modifications and avoid wasting resources by forwarding erronous 382 information. Hob-by-hop confidentiality is recommended by not 383 cruical as the information leakage can be limited to knowing when the 384 same codec is being used. If the signalling is kept confidential 385 towards any third party, then this minimal leakage is achieved. If 386 one uses payload formats that has static mappings without remapping 387 them, then the codec will be known by third parties. As a countering 388 requirement that may need to be considered. The payload type is 389 usually needed in third party quality monitors that gather statitics 390 about the RTP packet stream as it passes a measuring point. 392 3.7. Sequence Number 394 The MDD will need to modify the originating sequence number when it 395 performs any switching or on/off operations on the RTP stream. This 396 to ensure that the outgoing RTP stream has consistent sequence 397 numbers with the number of packets actually sent, rather then how 398 many that is being received at the ingress. 400 The receiving endpoint likely need the originating sequence number or 401 something semantically equivalent. The reasons for this is 402 decryption, replay protection, and packet reordering. If the 403 receiving endpoint knows through an end-to-end authenticated way the 404 sequence in which the payloads was originated, the receiver can 405 prevent using payloads that are replays from previous points in the 406 RTP stream. 408 Note: Sequence number based replay is vunerable in a environment 409 where the MDD can perform swithcing operations. This from an 410 attack using delaying of packets, rathern than replaying them. 411 Due to the switching operation the receiving endpoint will need to 412 accept any sequence number that is greater than previously 413 received, as it lacks knowledge about how many payloads the 414 originating endpoint has sent in the time interval since the last 415 payload was received. Thus an MDD can select to send any payload 416 between the last forwarded and the latest received from the 417 origin. 419 End-to-End authentication of the original payload seqence number is 420 likely required. End-to-end confidentiality is not possible as the 421 MDDs needs to know in which sequence the payloads where sent. Being 422 able to re-order the payloads could help improving the 423 confidentiality of the media content as analysis using randomly 424 reordered packets would be significantly more difficult. However, 425 due to the real-time properties, such actions are unlikely to be 426 feasible. However, if any such deliberate reordering would be 427 attempted, the original sequence number would need to be 428 confidentiality protected. 430 Hop-by-hop authentication of the sequence number is recommended to 431 prevent attacks on the receiver buffer, including forcing the 432 receiver to discard other packets. Hop-by-hop confidentiality is 433 recommened but not required. This as the goal would be to attempt to 434 hide the correct sequence, across unintentional or intentional 435 reordering, and enable detection of lost packets. Such knowledge has 436 some use in content analysis. At the same time having this 437 information in the clear enables third party monitoiring to gather 438 statistics about re-ordering and packet loss. 440 3.8. Timestamp 442 The RTP timestamp expresses playout related time information. When a 443 MDD is an media switching RTP mixer, it will need to provide a 444 consistent timeline across switches. The timeline is also the 445 outgoing SSRC's (from the mixer) internal timeline, and not specific 446 to any of the originating RTP streams being switched into the stream. 447 Thus, the timestamp in relation to the originating packet will need 448 to be rewritten. 450 The receiving endpoint could have use of the original value. First 451 it could be used to detect malicous rewrite attempts that forces the 452 receiver into flusing the receiver buffer or perform concealment over 453 media that otherwise would have been played out. Secondly it can be 454 used as a protection against the delay attack discussed above in 455 Section 3.7. However, protection against these type of attacks by 456 the MDD can be fragile and may cause more harm than gain. For the 457 first type of attacks, it is clear that some modifications of the 458 timeline between originating sources are necessary. This is first to 459 align content segments so they have matching boundaries. Secondly, 460 as the different endpoint don't have synchronized clocks there will 461 be clock skew, thus some clock skew compensation at switch points are 462 to be expected. For the delay attack protection also the clock skew 463 issue is present. For both clock skew related issues this is further 464 complicated that the clock skew compensation information is in RTCP 465 and curently under control of the MDD. Thus, one would need to 466 consider protecting this RTCP information end-to-end, or provided 467 using other protocol means. 469 If the original timestamp needs end-to-end authentication is 470 dependent on if one can define a mechanism for delay attack 471 protection using it. If not it is likely not needed. End-to-end 472 confidentiality will be difficult as the MDD will need to know where 473 in the timeline a particular payload belongs to. This is also 474 closely related to the payload sequence information discussed above 475 Section 3.7. 477 Hop-by-hop authentication is needed to prevent third party attacks. 478 Hop-by-hop confidentiality is recommended as it prevents leaking 479 information about the sequence of the media and how much media is 480 packed into each payload, especially for audio. This is coupled to 481 the protection on provide the sequence number. At the same time a 482 third party quality monitor likely need the RTP timestamp to perform 483 its role adequately. 485 3.9. SSRC 487 The SSRC identifies the source of the RTP packet. As each SSRC has 488 its own RTP sequence number space as well as timestamp sequence, 489 collisions shall be avoided. For the PERC usage it is also important 490 that a receiving endpoint can separate two different originating 491 sources and to map the SSRC to a human readable name (or alias). The 492 important security related issue is that unless the originating RTP 493 stream can be identified the MDD could create one outgoing stream 494 that selects packets from either of them. This may be challenging 495 due to replay protection, but not impossible depending on how the 496 sequence number and timestamps align. To avoid having multiple 497 identifers for the RTP packet stream, the design team has proposed 498 that the SSRC shall be unique and the original value preserved to the 499 receiving endpoint. 501 Note: There where no agreement on how the uniqness shall be 502 ensured and are for further discussion. 504 Even if the originating endpoints have unique SSRCs, it is not clear 505 if the same requirement will be extended to the MDD, and then 506 especially media switching RTP mixers that have their own SSRCs. 507 Thus translation of SSRC as a method for dealing with SSRC collisions 508 may need to be dealt with. 510 The original SSRC needs to be authenticated end-to-end to prevent the 511 splicing attack described above. The SSRC can't be confidentiality 512 protected end-to-end as it is required by the MDD to know which 513 packets are part of the same RTP stream. Note that for an media 514 switching mixer, the SSRC field will not be the original one, instead 515 that value is expected to be put in the CSRC field. 517 The SSRC shall be authenticated hop-by-hop to prevent splicing or 518 redirecting packets between incoming RTP streams. It would have 519 benefits to confidentiality protect the SSRC towards third parties as 520 it would make it more difficult for such an attacker to associate 521 packets to different RTP streams, when the originating endpoint sends 522 more than one stream in the same transport flow. 524 3.10. CSRC List 526 The contributing source list contains the SSRC values of the RTP 527 streams that contributed to the media content of this packet. In the 528 PERC case, where the payload is end-to-end and not mixed in the 529 middle boxes the field is expected to contain a single value. This 530 is for the case where the originating SSRC is moved into the CSRC 531 field with the MDD acts as an media switching mixer. As discusssed 532 in Section 3.4 there could in theory be cases where an endpoint is 533 performing mixes and thus need to include multiple CSRC values, but 534 it appears to be contradicting the security model. 536 The MDD needs to be able to add the CSRC field when not present. As 537 it populates it with the orignating SSRC value, it simple moves the 538 information from one place to another. Thus, the authentication and 539 confidentiality requirements will be the same as for the SSRC field. 540 End-to-End authentication of the CSRC value is performed, when the 541 field is present instead of the SSRC field. Here CSRC fields from an 542 originating endpoint will be an issue that requires special 543 considerations. End-to-end confidentiality is not possible, due to 544 the MDD moving the field from the SSRC place. 546 Hop-by-hop the CSRC list shall be authenticated to prevent a third 547 party to corrupt the field. Hop-by-hop confidentiality is 548 recommended but not requried. 550 3.11. Header Extensions 552 This section assumes that the RTP header extension is used following 553 the mechanism in [RFC5285]. Thus, the header extension can contain 554 multiple different extensions as agreed and identified according to 555 signalling. Each header extension format in use are assigned an 556 identifer that are per endpoint and RTP session agreed. This results 557 in that the MDD are likely to need to renumber them between ingress 558 and egrees if they forward the extension. In addition a number of 559 header extensions in use will be intended and targeted to the MDD. 560 When MDDs are cascade they will likely need to forward the extension 561 between themselves, and only on the last leg towards the receiving 562 endpoint remove them. 564 What security properties that are needed will be highly dependent on 565 the header extension and their content. Therefore a number of header 566 extensions are analysed in this section to determine if they contain 567 material that need end-to-end authentication or also end-to-end 568 confidentiality. 570 The current summary of the known information is the following. The 571 MDD needs to modify the IDs and add or remove some header extensions. 572 There are header extensions that really should use hop-by-hop 573 confidentiality (See Audio levels), and all should have hop-by-hop 574 authentication to prevent modification impacting the MDD's processing 575 and forwarding decision. The SMPTE time-code mapping, the 576 Cordination of Video Orientation, the Region of Interest and the SDES 577 information are all information from the originating endpoint 578 intended to receiving endpoint. In the case of the SDES information, 579 likely also needed by the MDD. This is information that all should 580 be authenticated end-to-end to ensure that the MDD can't modify it. 581 SPMTE time-codes, Coordination of video orientation (CVO), Region of 582 Interest (ROI) are all information that the MDD lack need to see to 583 be able to perform its task to forward media appropriately. Thus 584 end-to-end confidentiality is recommended to be applied. 586 3.11.1. Transmission Time offsets 588 The Transmission Time offsets [RFC5450] are header extension that 589 encodes the time of transmission of the RTP packet in relation to the 590 RTP timestamp. Being directly related to the transmission of the 591 whole RTP packet it is non-sensitive information from a privacy and 592 confidentiality aspect. It only provides more detaild information in 593 what sequence a packet actually was sent, information that both the 594 timestamp and sequence number provide. 596 The authentication of this information can be valuable. However, as 597 the MDD receives and the potentially fowards it, it has limited end- 598 to-end value, and it is more appropriate for an MDD to rewrite this 599 header when forwarding the packet to provide hop-by-hop transport 600 information. Thus, hop-by-hop authentication is recommended. 602 3.11.2. SMPTE time-code mapping 604 The SMPTE time-code mapping [RFC5484] is providing SMPTE time codes 605 associated with the RTP packet. This information is meta data to the 606 media content in the payload. End-to-end authentication is recommend 607 to ensure that the data is non-modified from the originating 608 endpoint. The meta data may be privacy sensitive as it reveals 609 information about the timeline for the content the receiver sees, 610 inluding seeking in stored contentet provided into a conferencing 611 context. There appear to be no reason why the MDD should have access 612 to this, and end-to-end confidentiality is recommended. 614 Hop-by-hop authentication is recommended, and confidentiality should 615 be applied if not used end-to-end. 617 3.11.3. Synchronisation metadata 619 Synchronisation metadata [RFC6051] is an header extension that 620 provides the NTP and RTP Timestamp information binding, just like in 621 the RTCP Sender Report. This is information that a MDD may need to 622 perform its work efficiently, especially when functioning as an media 623 switching mixer. The information could be end-to-end authenticated 624 to prevent the MDD from intefering with it, and if included by an 625 originating endpoint it can be assumed that it is intended for any 626 current receiver of this RTP stream. The information does not appear 627 to be sensitive from a confidentiality perspective. 629 3.11.4. Client to Mixer Audio Level 631 The Client-to-Mixer Audio Level Indication [RFC6464] is very 632 interesting and problematic header extension. It contains the audio 633 level of the audio included in the RTP packet. If that information 634 is provided frequently enough is may provide an attacker of good 635 possibilities as of deducing what is being said [RFC6562]. It is 636 also is important meta data needed by an MDD if it is to perform the 637 RTP stream switching based on who is talking. 639 This header may require end-to-end confidentiality, this is for cases 640 where the meta data is inteded for the receiving endpoints only, and 641 not the MDDs. In cases of cascaded MDDs it could potentially be of 642 interest to have authentication of the origin, but with a method that 643 the MDDs could verify, and which would allow the final MDD before a 644 receiving endpoint to remove the header extension. 646 The header shall be hop-by-hop confidentiality protected and 647 authenticated. 649 3.11.5. Mixer-to-client audio level 651 Mixer-to-Client Audio Level Indication [RFC6465] is an providing 652 audio levels for individual contributing sources within an audio mix. 653 As the PERC system does not support content mixing, this header does 654 not appear relevant. 656 3.11.6. Coordination of video orientation (CVO) 658 The Coordination of video orientation (CVO) [3GPP TS 26.114, version 659 12.5.0] provides a receiver with meta data about a video stream 660 indicating which direction in the video is "up". Thus enabling the 661 receiving endpoint to display the video content correctly oriented. 663 This information is meta data about the media content itself. It 664 does not appear to be information required by an MDD for its task. 666 Changing the video orientation may in some cases completely change 667 the meaning, e.g. a hand doing sign language. Therefore, this 668 information should be end-to-end confidentiality protected as well as 669 authenticated. Hop-by-hop authentication is recommended and 670 confidentiality as well if not applied end-to-end. 672 3.11.7. Region-of-interest (ROI) 674 Region-of-interest (ROI) [3GPP TS 26.114, version 13.1.0] is an 675 header extension providing the receiving endpoint information that 676 the video image it receives is a covering a particular sub-area of 677 what is originally captured. There exist other protocol mechanism to 678 select the region of interest. 680 This information is meta data about the media content itself. It 681 does not appear to be information required by an MDD for its task. 682 Therefore this information should be end-to-end confidentiality 683 protected as well as authenticated. Hop-by-hop authentication is 684 recommended and confidentiality as well if not applied end-to-end. 686 3.11.8. SDES Information 688 The SDES header extension is defined in 689 [I-D.ietf-avtext-sdes-hdr-ext] and provides SDES CNAME and MID 690 [I-D.ietf-mmusic-sdp-bundle-negotiation] information associated with 691 the originating SSRC. 693 The privacy sensitve nature of the CNAME is dependent of how it is 694 generated. If generated with privacy in mind [RFC7022] then it will 695 not need to be end-to-end confientiality protected. If not it may 696 require end-to-end confidentiality. The MID values are references 697 into SDP media descriptions and are not expected to be sensitive. 698 This information is provided by the originating endpoint, and being 699 able to trust it is highly valuabel, thus it should be end-to-end 700 authenticated, and preferably also be possible to validate by the 701 MDD. 703 The hop-by-hop should be authenticated to avoid wasting resources, 704 and the hop-by-hop confiendiality reduces the tracking possibilities 705 by third parties. 707 3.12. Payload 709 The payload is the payload format with the media content that is to 710 be confidentiality protected end-to-end. Thus, the MDD shall not be 711 able to modify it. It needs to be end-to-end confidentiality 712 protected and authenticated. The payload should be hop-by-hop 713 authenticated to prevent wasting downstream resources by forwarding a 714 corrupt or modified payload. Hop-by-hop confidentiality is not 715 strictly needed as it will be protected end-to-end. However, to help 716 prevent tracking of how particular payloads are forwarded, it could 717 be confidentiality protected also hop-by-hop. 719 3.13. Padding Octets 721 The padding octets that come after the regular payload are often used 722 to hide payload length variations when that is sensitive and could 723 lead to breach of the confidentiality of the content. Thus, it 724 important that the amount of padding can't be determined by either 725 the MDD or any third party. Thus, end-to-end confidentiality and 726 authentication is necessary. Hop-by-hop authentication is 727 recommended to prevent wasting resources on corrupt or modified 728 padding. Hop-by-hop confidentiality is not necessary due to the end- 729 to-end one, but would reduce tracking possibilities. 731 4. Summery 733 The following table summarizes the information from the previous 734 section. Legend: 736 Yes: Something is required to be done, or in the case of MDD 737 modification need to be possible. 739 No: Something that is not to be done, nor needs to be done. 741 Rec: Recommened to be done but not required. 743 May: It can be done, but neither recommened or required (Yes). 745 *: Please see description in the section for specific considerations. 747 ?: Classification is more uncertain and need further input. 749 +------------+-------+----------+--------+--------+--------+--------+ 750 | Data | MDD | Orig | E2E | E2E | HBH | HBH | 751 | | Mod | Needed | Auth | Conf | Auth | Conf | 752 +------------+-------+----------+--------+--------+--------+--------+ 753 | V | No | No | No | No | Yes | May | 754 | P | No | Yes | Yes | May? | Yes | Rec | 755 | X | Yes | No | No | No | Yes | Rec | 756 | CC | Yes | No | No | No | Yes | Rec | 757 | M | No | Yes | Yes | Rec? | Yes | Yes | 758 | PT | Yes | Yes? | Rec? | No* | Yes | Rec | 759 | Seq No | Yes | Yes* | Yes | No | Yes | Rec | 760 | Timestamp | Yes | Yes? | Yes? | No | Yes | Rec | 761 | SSRC | May | Yes* | Yes* | No | Yes | Rec | 762 | CSRCs | Yes | Yes* | Yes* | No | Yes | Rec | 763 | Extensions | Yes | Some? | Some? | Some? | Yes | Some | 764 | Payload | No | Yes | Yes | Yes | Yes | May? | 765 | Padding | No | Yes | Yes | Yes | Yes | May? | 766 +------------+-------+----------+--------+--------+--------+--------+ 768 Table 1: Summary of Handling Required 770 5. IANA Considerations 772 This document makes no request of IANA. 774 Note to RFC Editor: this section may be removed on publication as an 775 RFC. 777 6. Security Considerations 779 The purpose of this document include discussing the security issue 780 around the information in the RTP header. That is covered above in 781 the document. Worth noting is the differences in recommendation for 782 hop-by-hop confidentiality compared to regular SRTP. Where SRTP for 783 allowing third party monitors as well as enabling the use of IP/UDP/ 784 RTP header compressors the RTP header information is in clear text 785 and only integrity protected. 787 With the increased privacy concerns [RFC6973][RFC7258] and known 788 attacks based on payload length analys, it has become more important 789 to consider confidentiality protect the whole RTP header, but 790 specifically the X, CC, M, PT fields as they reveal important 791 information around the payload and its length. Based on this I 792 recommend that we not only consider SRTP as outer security layer to 793 provide hop-by-hop confidentiality and integrity protection, but also 794 methods that protect the whole RTP packet, like DTLS. 796 7. Contributors 798 Cullen Jennings contributed the initial version of the summary table. 800 8. Acknowledgements 802 The author like to thank John Mattsson for review comments. 804 9. Informative References 806 [I-D.ietf-avtcore-rtp-topologies-update] 807 Westerlund, M. and S. Wenger, "RTP Topologies", draft- 808 ietf-avtcore-rtp-topologies-update-10 (work in progress), 809 July 2015. 811 [I-D.ietf-avtext-sdes-hdr-ext] 812 Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 813 Header Extension for RTCP Source Description Items", 814 draft-ietf-avtext-sdes-hdr-ext-02 (work in progress), July 815 2015. 817 [I-D.ietf-mmusic-sdp-bundle-negotiation] 818 Holmberg, C., Alvestrand, H., and C. Jennings, 819 "Negotiating Media Multiplexing Using the Session 820 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 821 negotiation-23 (work in progress), July 2015. 823 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 824 Jacobson, "RTP: A Transport Protocol for Real-Time 825 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 826 July 2003, . 828 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 829 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 830 2008, . 832 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 833 RTP Streams", RFC 5450, DOI 10.17487/RFC5450, March 2009, 834 . 836 [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", 837 RFC 5484, DOI 10.17487/RFC5484, March 2009, 838 . 840 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 841 Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, 842 . 844 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 845 Transport Protocol (RTP) Header Extension for Client-to- 846 Mixer Audio Level Indication", RFC 6464, 847 DOI 10.17487/RFC6464, December 2011, 848 . 850 [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- 851 time Transport Protocol (RTP) Header Extension for Mixer- 852 to-Client Audio Level Indication", RFC 6465, 853 DOI 10.17487/RFC6465, December 2011, 854 . 856 [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of 857 Variable Bit Rate Audio with Secure RTP", RFC 6562, 858 DOI 10.17487/RFC6562, March 2012, 859 . 861 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 862 Morris, J., Hansen, M., and R. Smith, "Privacy 863 Considerations for Internet Protocols", RFC 6973, 864 DOI 10.17487/RFC6973, July 2013, 865 . 867 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 868 "Guidelines for Choosing RTP Control Protocol (RTCP) 869 Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, 870 September 2013, . 872 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 873 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 874 2014, . 876 Author's Address 878 Magnus Westerlund 879 Ericsson 880 Farogatan 2 881 SE-164 80 Stockholm 882 Sweden 884 Phone: +46 10 714 82 87 885 Email: magnus.westerlund@ericsson.com