draft-ietf-straw-b2bua-rtcp-02.txt   draft-ietf-straw-b2bua-rtcp-03.txt 
STRAW Working Group L. Miniero STRAW Working Group L. Miniero
Internet-Draft Meetecho Internet-Draft Meetecho
Intended status: Standards Track S. Garcia Murillo Intended status: Standards Track S. Garcia Murillo
Expires: April 27, 2015 Medooze Expires: August 13, 2015 Medooze
V. Pascual V. Pascual
Quobis Quobis
October 24, 2014 February 9, 2015
Guidelines to support RTCP end-to-end in Back-to-Back User Agents Guidelines to support RTCP end-to-end in Back-to-Back User Agents
(B2BUAs) (B2BUAs)
draft-ietf-straw-b2bua-rtcp-02 draft-ietf-straw-b2bua-rtcp-03
Abstract Abstract
SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also be SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also be
on the media path, rather than just intercepting signalling. This on the media path, rather than just intercepting signalling. This
means that B2BUAs often implement an RTP/RTCP stack as well, whether means that B2BUAs often implement an RTP/RTCP stack as well, whether
to act as media transcoders or to just passthrough the media to act as media transcoders or to just passthrough the media
themselves, thus leading to separate multimedia sessions that the themselves, thus leading to separate multimedia sessions that the
B2BUA correlates and bridges together. If not disciplined, though, B2BUA correlates and bridges together. If not disciplined, though,
this behaviour can severely impact the communication experience, this behaviour can severely impact the communication experience,
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 27, 2015. This Internet-Draft will expire on August 13, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Signalling/Media Plane B2BUAs . . . . . . . . . . . . . . . . 5 3. Signalling/Media Plane B2BUAs . . . . . . . . . . . . . . . . 5
3.1. Media Relay . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Media Relay . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Media-aware Relay . . . . . . . . . . . . . . . . . . . . 6 3.2. Media-aware Relay . . . . . . . . . . . . . . . . . . . . 6
3.3. Media Terminator . . . . . . . . . . . . . . . . . . . . 9 3.3. Media Terminator . . . . . . . . . . . . . . . . . . . . 9
4. Media Path Security . . . . . . . . . . . . . . . . . . . . . 10 4. Media Path Security . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 11 7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Session Initiation Protocol [RFC3261] Back-to-Back User Agents Session Initiation Protocol [RFC3261] Back-to-Back User Agents
(B2BUAs) are SIP entities that can act as a logical combination of (B2BUAs) are SIP entities that can act as a logical combination of
both a User Agent Server (UAS) and a User Agent Client (UAC). As both a User Agent Server (UAS) and a User Agent Client (UAC). As
such, their behaviour is not always completelely adherent to the such, their behaviour is not always completelely adherent to the
standards, and can lead to unexpected situations the IETF is trying standards, and can lead to unexpected situations the IETF is trying
to address. [RFC7092] presents a taxonomy of the most deployed B2BUA to address. [RFC7092] presents a taxonomy of the most deployed B2BUA
skipping to change at page 10, line 35 skipping to change at page 10, line 35
B2BUA itself has no access to the keys used to secure the session, B2BUA itself has no access to the keys used to secure the session,
there would be no way to manipulate SRTP headers without violating there would be no way to manipulate SRTP headers without violating
the hashing on the packet; at the same time, there would be no way to the hashing on the packet; at the same time, there would be no way to
rewrite the RTCP information accordingly either, as most of the rewrite the RTCP information accordingly either, as most of the
packet (especially when RTCP compound packets are involved) would be packet (especially when RTCP compound packets are involved) would be
encrypted. encrypted.
For this reason, it is important to point out that the operations For this reason, it is important to point out that the operations
described in the previous sections are only possible if the B2BUA has described in the previous sections are only possible if the B2BUA has
a way to effectively manipulate the packets and messages flowing by. a way to effectively manipulate the packets and messages flowing by.
This means that, in case media security is involved, the B2BUA This means that, in case media security is involved, only the Media-
willing to act as either a Media-aware Relay or a Media Terminator unaware Relay scenario can be properly addressed. Attempting to
can only do so when acting as an intermediary with respect to the cover Media-aware Relay and Media Terminarion scenarios when
secure sessions. As such, different secure sessions would need to be involving secure sessions will inevitably lead to the B2BUA acting as
negotiated (either via SDES or DTLS-SRTP) with the involved a man-in-the-middle, and as such its behaviour is unspecified and
participants, in order to be able to have access to the unencrypted discouraged.
packets and, if needed, modify them before encrypting them again and
forwarding them.
Of course, this is only a viable solution if all the involved
participants trust the B2BUA. In fact, it is very important to point
out that a B2BUA acting as an intermediary would break any end-to-end
security mechanism that may be in place, as all the involved
participants would have a secure communication up to the B2BUA and
would have to rely on the B2BUA actually encrypting the communication
on the other end(s) as well. This means that the participants
involved in a multimedia session through a B2BUA have to trust the
B2BUA to secure the session on the other end(s), taking care of any
validation and protection that may be required as part of the
process.
It is worth noting that some additional care may be needed, with
respect to RTCP, when acting as an intermediary between two secure
sessions. Specifically, issues may arise when relaying NACK feedback
originated by a user who failed to receive some RTP packets, that
were instead received by the B2BUA: such an issue might occur when
the packet loss happens between the user and the B2BUA itself, and
not between the RTP packet sender and the B2BUA. Such a situation
might result in the RTP media sender retransmitting the encrypted
packet, which would then be rejected by the B2BUA as a replayed one.
However, this issue is well known and addressed in [RFC4588], which
both the B2BUA and the involved participants in the communication
SHOULD make use of to prevent it from happening. This mechanism
allows for a Redundancy RTP Stream to be used for the purpose, which
would prevent the replay error. Of course, all recommendations given
previously with respect to managing SSRCs across the B2BUA still
apply here as well: in fact, such a redundant RTP stream would make
use of a different SSRC, that would need to be taken care of both at
the RTP and the SDP level. If [RFC4588] is not supported, the B2BUA
SHOULD handle NACK packets directly, and only forward feedback on
lost packets it has not access to.
5. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
6. Security Considerations 6. Security Considerations
TBD. Not any additional consideration to what the standards already This document, being a summary and vest common practice overview that
give? Probably this section will need a few words about how NOT covers different standards, does not introduce any additional
following the guidelines can lead to security issues: e.g., not consideration to those described by the aforementioned standard
properly translating REMB messages can cause an increasing flow of documents themselves.
media packets, that may be seen as attacks to devices that can't
handle the amount of data. It is worth pointing out, though, that there are scenarios where an
improper management of RTCP messaging across a B2BUA may lead,
willingly or not, to situations not unlike an attack. To make a
simple example, an improper management of a REMB feedback message
containing, e.g., information on the limited bandwidth availability
for a user, may lead to missing information to its peer, who may end
up increasing the encoder bitrate up to a point where the user with
poor connectivity will inevitably be choked by an amount of data it
cannot process. This scenario may as such result in what looks like
a Denial of Service (DOS) attack towards the user.
7. Change Summary 7. Change Summary
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
The following are the major changes between the 02 and the 03
versions of the draft:
o Rephrased the Media Path Security section to take into account the
MITM-related discussion in Honolulu.
o Added some Security Considerations.
The following are the major changes between the 01 and the 02 The following are the major changes between the 01 and the 02
versions of the draft: versions of the draft:
o Updated terminology to better adhere to o Updated terminology to better adhere to
[I-D.ietf-avtext-rtp-grouping-taxonomy]. [I-D.ietf-avtext-rtp-grouping-taxonomy].
o Rephrased the Media Path Security section to take into account the o Rephrased the Media Path Security section to take into account the
MITM-related discussion in Toronto. MITM-related discussion in Toronto.
o Clarified that NACK management might be trickier when SRTP is o Clarified that NACK management might be trickier when SRTP is
skipping to change at page 13, line 16 skipping to change at page 12, line 43
Initiation Protocol (SIP) Back-to-Back User Agents", RFC Initiation Protocol (SIP) Back-to-Back User Agents", RFC
7092, December 2013. 7092, December 2013.
9.2. Informative References 9.2. Informative References
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008. January 2008.
[I-D.ietf-avtcore-rtp-topologies-update] [I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft- Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-04 (work in progress), ietf-avtcore-rtp-topologies-update-05 (work in progress),
August 2014. November 2014.
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro,
"A Taxonomy of Grouping Semantics and Mechanisms for Real- "A Taxonomy of Grouping Semantics and Mechanisms for Real-
Time Transport Protocol (RTP) Sources", draft-ietf-avtext- Time Transport Protocol (RTP) Sources", draft-ietf-avtext-
rtp-grouping-taxonomy-02 (work in progress), June 2014. rtp-grouping-taxonomy-05 (work in progress), January 2015.
[I-D.alvestrand-rmcat-remb] [I-D.alvestrand-rmcat-remb]
Alvestrand, H., "RTCP message for Receiver Estimated Alvestrand, H., "RTCP message for Receiver Estimated
Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in
progress), October 2013. progress), October 2013.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
2006. 2006.
 End of changes. 12 change blocks. 
58 lines changed or deleted 40 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/