RTP Stream Pause and Resume
draft-ietf-avtext-rtp-stream-pause-09
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7728.
|
|
---|---|---|---|
Authors | Bo Burman , Azam Akram , Roni Even , Magnus Westerlund | ||
Last updated | 2015-09-03 | ||
Replaces | draft-westerlund-avtext-rtp-stream-pause | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Telechat review
(of
-08)
by Meral Shirazipour
Ready w/nits
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Jonathan Lennox | ||
Shepherd write-up | Show Last changed 2015-06-08 | ||
IESG | IESG state | Became RFC 7728 (Proposed Standard) | |
Consensus boilerplate | Yes | ||
Telechat date |
(None)
Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass. |
||
Responsible AD | Ben Campbell | ||
Send notices to | draft-ietf-avtext-rtp-stream-pause@ietf.org, draft-ietf-avtext-rtp-stream-pause.ad@ietf.org, jonathan@vidyo.com, draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org, avtext-chairs@ietf.org | ||
IANA | IANA review state | Version Changed - Review Needed |
draft-ietf-avtext-rtp-stream-pause-09
gt; | | | t9:PAUSED(S,8) | | | |----------------->| | | | | t10:PAUSED(S,8) | | | |----------------->------------------>| : : : : | | t11:RESUME(S,8) | | | |<-----------------| | | t12:RESUME(S,8) | | | |<-----------------|------------------------------------>| | t13:RTP(S) | | | |----------------->| | | | | t14:RTP(S) | | | |----------------->------------------>| : : : : Figure 19: Pause and Resume Operation Between One Sender and Two Receivers Through Relay Figure 19 explains the pause and resume operations when a transport Relay is involved between a sender and two receivers in an RTP session. Each message exchange is represented by the time it happens. At time t1, Sender (S) starts sending an RTP stream to the Relay, which is forwarded to R1 and R2 through the Relay, Rel. R1 and R2 receives RTP data from Relay at t2. At this point, both R1 and R2 Burman, et al. Expires March 6, 2016 [Page 48] Internet-Draft RTP Stream Pause September 2015 will send RTCP Receiver Reports to S informing that they receive S's stream. After some time (at t3), R1 chooses to pause the stream. On receiving the PAUSE request from R1 at t4, S knows that there are at least one receiver that may still want to receive the data and uses a non-zero hold-off period to wait for possible RESUME messages. R2 did also receive the PAUSE request at time t4 and since it still wants to receive the stream, it sends a RESUME for it at time t5, which is forwarded to the sender S by the Relay. The sender S sees the RESUME at time t6 and continues to send data to Relay which forwards to both R1 and R2. At t7, the receiver R2 chooses to pause the stream by sending a PAUSE request with an updated PauseID. The sender S still knows that there are more than one receiver (R1 and R2) that may want the stream and again waits a non-zero hold-off period, after which and not having received any disapproving RESUME, it concludes that the stream must be paused. S now stops sending the stream and replies with PAUSED to R1 and R2. When any of the receivers (R1 or R2) chooses to resume the stream from S, in this example R1, it sends a RESUME request to the sender (also seen by R2). The RTP sender immediately resumes the stream. Consider also an RTP session which includes one or more receivers, paused sender(s), and a Relay. Further assume that a new participant joins the session, which is not aware of the paused sender(s). On receiving knowledge about the newly joined participant, e.g. any RTP traffic or RTCP report (i.e. either SR or RR) from the newly joined participant, the paused sender(s) immediately sends PAUSED indications for the paused streams since there is now a receiver in the session that did not pause the sender(s) and may want to receive the streams. Having this information, the newly joined participant has the same possibility as any other participant to resume the paused streams. 11. IANA Considerations This specification requests the following registrations from IANA: 1. A new value for media stream pause / resume to be registered with IANA in the "FMT Values for RTPFB Payload Types" registry located at the time of publication at: http://www.iana.org/assignments/ rtp-parameters/rtp-parameters.xhtml#rtp-parameters-8 Value: TBA1 Name: PAUSE-RESUME Long Name: Media Pause / Resume Burman, et al. Expires March 6, 2016 [Page 49] Internet-Draft RTP Stream Pause September 2015 Reference: This RFC 2. A new value "pause" to be registered with IANA in the "Codec Control Messages" registry located at the time of publication at: http://www.iana.org/assignments/sdp-parameters/sdp- parameters.xhtml#sdp-parameters-19 Value Name: pause Long Name: Media Pause / Resume Usable with: ccm Reference: This RFC 12. Security Considerations This document extends the CCM [RFC5104] and defines new messages, i.e. PAUSE, RESUME, PAUSED, and REFUSED. The exchange of these new messages have some security implications, which need to be addressed by the user. The messages defined in this specification can have substantial impact on the perceived media quality if used in a malicious way. First of all, there is the risk for Denial of Service (DoS) on any RTP session that uses the PAUSE-RESUME functionality. By injecting one or more PAUSE requests into the RTP session, an attacker can potentially prevent any media from flowing, especially when the hold- off period is zero. The injection of PAUSE messages is quite simple, requiring knowledge of the SSRC and the PauseID. This information is visible to an on-path attacker unless RTCP messages are encrypted. Even off-path attacks are possible as signalling messages often carry the SSRC value, while the 16-bit PauseID have to be guessed or tried. The way of protecting the RTP session from these injections is to perform source authentication combined with message integrity, to prevent other than intended session participants from sending these messages. The security solution should provide replay protection, otherwise an attacker could for sessions that are long lived enough to wrap the PauseID replay old messages at the appropriate time to influence the media sender state. There exist several different choices for securing RTP sessions to prevent this type of attack. SRTP is the most common, but also other methods exist as discussed in "Options for Securing RTP Sessions" [RFC7201]. Most of the methods for securing RTP however do not provide source authentication of each individual participant in a multi-party use case. In case one of the session participants is malicious, it can wreck significant havoc within the RTP session and similarly cause a Burman, et al. Expires March 6, 2016 [Page 50] Internet-Draft RTP Stream Pause September 2015 DoS on the RTP session from within. That damage can also be attempted to be obfuscated by having the attacker impersonate other endpoints within the session. These attacks can be mitigated by using a solution that provides true source authentication of all participants' RTCP packets. However, that has other implications. For multi-party sessions including a middlebox, that middlebox is RECOMMENDED to perform checks on all forwarded RTCP packets so that each participant only uses its set of SSRCs, to prevent the attacker utilizing another participant's SSRCs. An attacker that can send a PAUSE request without it reaching any other participant than the media sender can have its request being unopposed. This is mitigated in multi-party topologies that ensure that requests are seen by all or most of the RTP session participants, enabling these participants to send RESUME. In topologies with middleboxes that consume and process PAUSE requests, the middlebox can also mitigate such behavior as it will commonly not generate or forward a PAUSE message if it knows of another participant having use for the media stream. The above text has been focused on using the PAUSE message as the tool for malicious impact on the RTP session. That is because of the greater impact from denying users access to RTP media streams. In contrast, if an attacker attempts to use RESUME in a malicious purpose, it will result in that the media streams are delivered. However, such an attack basically prevents the use the Pause and Resume functionality. Thus, potentially forcing a reduction of the media quality due to limitation in available resources, like bandwidth that must be shared. The session establishment signalling is also a potential venue of attack, as that can be used to prevent the enabling of Pause and Resume functionality by modifying the signalling messages. The above mitigation of attacks based on source authentication also requires the signalling system to securely handle identities, and assert that only the intended identities are allowed into the RTP session and provided the relevant security contexts. 13. Contributors Daniel Grondal contributed in the creation and writing of early versions of this specification. Christian Groves contributed significantly to the SDP config attribute and its use in Offer/ Answer. 14. Acknowledgements Daniel Grondal made valuable contributions during the initial versions of this draft. The authors would also like to thank Emil Ivov, Christian Groves, David Madnelberg, Meral Shirazipour, Spencer Burman, et al. Expires March 6, 2016 [Page 51] Internet-Draft RTP Stream Pause September 2015 Dawkins, Bernard Aboba, and Ben Campbell, who provided valuable review comments. 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>. [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <http://www.rfc-editor.org/info/rfc5104>. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>. Burman, et al. Expires March 6, 2016 [Page 52] Internet-Draft RTP Stream Pause September 2015 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows", RFC 6263, DOI 10.17487/RFC6263, June 2011, <http://www.rfc-editor.org/info/rfc6263>. 15.2. Informative References [I-D.ietf-avtcore-rtp-multi-stream-optimisation] Lennox, J., Westerlund, M., Wu, W., and C. Perkins, "Sending Multiple Media Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback", draft-ietf-avtcore-rtp-multi-stream-optimisation-06 (work in progress), July 2015. [I-D.ietf-avtcore-rtp-topologies-update] Westerlund, M. and S. Wenger, "RTP Topologies", draft- ietf-avtcore-rtp-topologies-update-10 (work in progress), July 2015. [I-D.ietf-avtext-rtp-grouping-taxonomy] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", draft-ietf- avtext-rtp-grouping-taxonomy-08 (work in progress), July 2015. [I-D.ietf-mmusic-sdp-simulcast] Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, "Using Simulcast in SDP and RTP Sessions", draft-ietf- mmusic-sdp-simulcast-01 (work in progress), July 2015. [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, DOI 10.17487/RFC2326, April 1998, <http://www.rfc-editor.org/info/rfc2326>. [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, <http://www.rfc-editor.org/info/rfc2974>. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>. Burman, et al. Expires March 6, 2016 [Page 53] Internet-Draft RTP Stream Pause September 2015 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, <http://www.rfc-editor.org/info/rfc6190>. [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <http://www.rfc-editor.org/info/rfc7201>. [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 2015, <http://www.rfc-editor.org/info/rfc7478>. Appendix A. Changes From Earlier Versions NOTE TO RFC EDITOR: Please remove this section prior to publication. A.1. Modifications Between Version -08 and -09 Changes based on IETF last call and IESG comments. o Expanded some acronyms on first usage. o Clarified why this document updated RFC 5104. o Removed some unused abbreviations. o Clarified when TMMBR/TMMBN is expected to be used in Section 5.6. o Mandate using SHALL repetition of PAUSED indications in Section 6.4. o Removed paragraph in Section 8.4 on PauseID and REFUSED as being redundant. o Transmission rules in Section 8.5 was reworded and stoped using RFC 2119 terms, instead uses recommendations and lists motivations. o In Section 9 (Signalling) it was clarified that one SHOULD only send messages supported by receivers, but provide example of cases when one may still send messages not supported by every receiver of that message. Also clarified that TMMBR/TMMBN for pause is monolithic in capability. o Security consideration was updated to consider replay attacks. Burman, et al. Expires March 6, 2016 [Page 54] Internet-Draft RTP Stream Pause September 2015 o Security consideration was updated to describe the mitigation against malicous RTP session participants in multi-party cases that seeing all messages provide. A.2. Modifications Between Version -07 and -08 Changes based on IESG AD Evaluation. o Moved the mentioning of RTCWEB RFC7478 API requirements out from 3.1 to section 3, adding a couple of clarifying sentences. o Highlighted that the use case in section 3.4 deals with a different direction of the pause request than the previous use cases. o Added text on partial capability and interoperability to section 5.1. o Added an overview explanation of PauseID as a new section 5.2, and moved a few sentences on PauseID from other 5.x sections in there. o Changed all occurrences of "available" and "valid" PauseID to the more clear "current" PauseID, and re-phrased sentences involving that to become more clear. o Changed all occurrences of "smaller" and "larger" PauseID to "past" and "future", respectively, to better align with "current". o Removed an incorrect sentence in 5.2 about when it is not feasible to send repeated PAUSE. o Changed a few capitalized words that could be taken as normative text from section 5, which is intended to be a non-normative description. o Added some explanatory text on why RTP stream is resumed when the stream receiver that paused the stream leaves the RTP session to last bullet in 6.3.1. o Added caption to Figure 5. o Moved the detailed description on what PauseID ranges are defined as "past" and "future" before section 8.1, instead of having it in section 8.1, and added a comment on the "not current" part of the value range. Burman, et al. Expires March 6, 2016 [Page 55] Internet-Draft RTP Stream Pause September 2015 o Added text in section 8.1 on appropriate time to wait between sending PAUSE, when the first PAUSE was rejected by a RESUME or a REFUSED. o Added text in section 8.3 on appropriate time to wait between sending RESUME, when the first RESUME was rejected by a REFUSED. o Added text in section 8.4 on time to wait before sending the REFUSED request again, referencing sections 8.1 and 8.3. o Added a couple of paragraphs in section 9 on partial capability and interoperability, including a description on when different config values are expected to be useful, and when they are not. o Added arrows in Figure 19 to highlight that the Relay sends out all received messages to all receivers, not only the first PAUSE message. o Changed references to RFC3264 and RFC4566 to be normative. o Updated ietf-rtcweb-use-cases-and-requirements reference to be RFC7478. o Editorial improvements and clarifications. A.3. Modifications Between Version -06 and -07 o Completely rewrote the Security Consideration section. o Aligned text such that REFUSED is always referred to as a notification, not indication. o Added and changed text in several places, clarifying the case when TMMBR/TMMBN bounding set overhead value matters, related to whether local RTP stream sender or remote RTP stream receiver owns the TMMBR 0 restriction, and the consequences this has on pause/ resume logic. o Moved text on when to stop media stream transmission from when receiving PAUSE and entering pausing state, to when entering paused or local paused states. o Added text on how to determine if there is a single receiver or not, aligned with what is specified in draft-ietf-avtcore-multi- stream, adding a reference to draft-ietf-avtcore-multi-stream- optimisation to be able to use a single RTCP reporting group as one criteria. Burman, et al. Expires March 6, 2016 [Page 56] Internet-Draft RTP Stream Pause September 2015 o Added clarifying text on repeating PAUSED and RESUME messages only as long as remaining in the relevant state. o Clarified that it is the RTP stream sender's responsibility to leave local paused state when the condition causing that state is no longer true. o Added text to better allow for extensions to this specification, since there is already some text on extensions. o Corrected and amended ABNF to make CCM pause parameters order- independent, allow for a larger config pause attribute value range, and added corresponding text to handle that additional flexibility. o Added SDP rules on how to handle unknown pause attribute values. o Clarified how to handle an SDP with both "ccm pause" and "ccm tmmbr". o Changed from "Translator" to "Relay" in examples, to make it clearer in relation to the updated topologies draft. o Editorial improvements. A.4. Modifications Between Version -05 and -06 o Clarified in Message Details section for PAUSED that retransmission of the message can be used to increase the probability that the message reaches the receiver in a timely fashion, and also added text that says the number of repetitions can be tuned to observed loss rate and the desired loss probability. Also removed Editor's notes on potential ACK for unsolicited PAUSED, since the issue is solved by the above. o In the same section as above, added that PAUSED may be included in all compound RTCP reports, as long as the negotiated RTCP bandwidth is not exceeded. o In Message Details section for RESUME, added text on retransmission similar to the one mentioned for PAUSED above. Also included text that says such retransmission SHOULD stop as soon as RTP packets or a REFUSED with a valid PauseID from the targeted stream are received. o Changed simulcast reference, since that draft was moved from AVTCORE to MMUSIC and made WG draft. Burman, et al. Expires March 6, 2016 [Page 57] Internet-Draft RTP Stream Pause September 2015 o Changed End Point to Endpoint to reflect change in RTP Grouping Taxonomy draft. o Editorial improvements. A.5. Modifications Between Version -04 and -05 o Added text in sections 4.1, 4.6, 6.4 and 8.5 on retransmission and timing of unsolicited PAUSED, to improve the message timeliness and probability of reception. A.6. Modifications Between Version -03 and -04 o Change of Copyright boilerplate A.7. Modifications Between Version -02 and -03 o Changed the section on SDP signaling to be more explicit and clear in what is supported, replacing the 'paused' parameter and the 'dir' attribute with a 'config' parameter that can take a value, and an explicit listing of what each value means. o Added a sentence in section on paused state (Section 6.3) that pause must not affect RTP keepalive. o Replaced REFUSE message name with REFUSED throughout, to better indicate that it is not a command but a notification. o Added text in a few places, clarifying that PAUSED message may be used unsolicited due to RTP sender local considerations, and also clarified the interaction between this usage and an RTP stream receiver pausing the stream. Also added an example describing this case. o Clarified that when TMMBN 0 is used as PAUSED message, and when sent unsolicited due to RTP sender local considerations, the TMMBN message includes the RTP stream sender itself as part of the bounding set. o Clarified that there is no reply to a PAUSED indication. o Improved the IANA section. o Editorial improvements. Burman, et al. Expires March 6, 2016 [Page 58] Internet-Draft RTP Stream Pause September 2015 A.8. Modifications Between Version -01 and -02 o Replaced most text on relation with other signaling technologies in previous section 5 with a single, summarizing paragraph, as discussed at IETF 90 in Toronto, and placed it as the last sub- section of section 4 (design considerations). o Removed unused references. A.9. Modifications Between Version -00 and -01 o Corrected text in section 6.5 and 6.2 to indicate that a PAUSE signaled via TMMBR 0 cannot be REFUSED using TMMBN > 0 o Improved alignment with RTP Taxonomy draft, including the change of Packet Stream to RTP Stream o Editorial improvements Authors' Addresses Bo Burman Ericsson Kistavagen 25 SE - 164 80 Kista Sweden Email: bo.burman@ericsson.com Azam Akram Ericsson Farogatan 6 SE - 164 80 Kista Sweden Phone: +46107142658 Email: muhammad.azam.akram@ericsson.com URI: www.ericsson.com Roni Even Huawei Technologies Tel Aviv Israel Email: roni.even@mail01.huawei.com Burman, et al. Expires March 6, 2016 [Page 59] Internet-Draft RTP Stream Pause September 2015 Magnus Westerlund Ericsson Farogatan 6 SE- 164 80 Kista Sweden Phone: +46107148287 Email: magnus.westerlund@ericsson.com Burman, et al. Expires March 6, 2016 [Page 60]