draft-ietf-straw-b2bua-rtcp-11.txt   draft-ietf-straw-b2bua-rtcp-12.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: December 2, 2016 Medooze Expires: December 12, 2016 Medooze
V. Pascual V. Pascual
Quobis Quobis
May 31, 2016 June 10, 2016
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-11 draft-ietf-straw-b2bua-rtcp-12
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, thus means that B2BUAs often implement an RTP/RTCP stack as well, thus
leading to separate multimedia sessions that the B2BUA correlates and leading to separate multimedia sessions that the B2BUA correlates and
bridges together. If not disciplined, though, this behaviour can bridges together. If not disciplined, though, this behaviour can
severely impact the communication experience, especially when severely impact the communication experience, especially when
statistics and feedback information contained in RTCP messages get statistics and feedback information contained in RTCP messages get
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 December 2, 2016. This Internet-Draft will expire on December 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 5, line 8 skipping to change at page 5, line 8
As described in the introductory section, it's very common for B2BUA As described in the introductory section, it's very common for B2BUA
deployments to also act on the media plane, rather than just deployments to also act on the media plane, rather than just
signalling alone. In particular, [RFC7092] describes three different signalling alone. In particular, [RFC7092] describes three different
categories of such B2BUAs: a B2BUA, in fact, may act as a simple categories of such B2BUAs: a B2BUA, in fact, may act as a simple
media relay (1), effectively unaware of anything that is transported; media relay (1), effectively unaware of anything that is transported;
it may be a media-aware relay (2), also inspecting and/or modifying it may be a media-aware relay (2), also inspecting and/or modifying
RTP and RTCP messages as they flow by; or it may be a full-fledged RTP and RTCP messages as they flow by; or it may be a full-fledged
media termination entity (3), terminating and generating RTP and RTCP media termination entity (3), terminating and generating RTP and RTCP
messages as needed. messages as needed.
While [RFC3550] and [RFC7667] already mandate some specific [RFC3550] and [RFC7667] already mandate some specific behaviours in
behaviours in the presence of certain topologies, not all deployments the presence of certain topologies. Anyway, due to their mixed
strictly adhere to the specifications. This means that it's not rare nature B2BUAs sometimes can't or won't implement all relevant
to encounter issues that may be avoided with a more disciplined specifications. This means that it's not rare to encounter issues
behaviour in that regard. For this reason, the following subsections that may be avoided with a more disciplined behaviour in that regard,
that is if the B2BUAs followed at least a set of guidelines to ensure
no known problems occur. For this reason, the following subsections
will describe the proper behaviour B2BUAs, whatever above category will describe the proper behaviour B2BUAs, whatever above category
they fall in, should follow in order not to impact any end-to-end they fall in, should follow in order not to impact any end-to-end
RTCP effectiveness. RTCP effectiveness.
3.1. Media Relay 3.1. Media Relay
A media relay, as identified in [RFC7092], simply forwards all RTP A media relay, as identified in [RFC7092], simply forwards all RTP
and RTCP messages it receives, without either inspecting or modifying and RTCP messages it receives, without either inspecting or modifying
them. Using the RTP Topologies terminology, this can be seen as a them. Using the RTP Topologies terminology, this can be seen as a
RTP Transport Translator. As such, B2BUA acting as media relays are RTP Transport Translator. As such, B2BUA acting as media relays are
skipping to change at page 5, line 50 skipping to change at page 6, line 4
rather than using the original session description. This may cause rather than using the original session description. This may cause
participants to find a mismatch between the SSRCs advertized in the participants to find a mismatch between the SSRCs advertized in the
SDP and the ones actually observed in RTP and RTCP messages, or to SDP and the ones actually observed in RTP and RTCP messages, or to
have them either ignore or generate RTCP feedback packets that were have them either ignore or generate RTCP feedback packets that were
not explicitly advertized as supported. not explicitly advertized as supported.
In order to prevent such an issue, a media-relay B2BUA SHOULD forward In order to prevent such an issue, a media-relay B2BUA SHOULD forward
all the SSRC- and RTCP-related SDP attributes when handling a all the SSRC- and RTCP-related SDP attributes when handling a
multimedia session setup between participants: this includes multimedia session setup between participants: this includes
attributes like 'ssrc' [RFC3261], 'rtcp-fb' [RFC4585], 'rtcp-xr- attributes like 'ssrc' [RFC3261], 'rtcp-fb' [RFC4585], 'rtcp-xr-
attrib' [RFC3611] and others. It SHOULD NOT, though, blindly forward attrib' [RFC3611] and others. It SHOULD NOT, though, forward SDP
all SDP attributes, as some of them (e.g., candidates, fingerprints, attributes that may lead to call failures (e.g., candidates,
crypto, etc.) may lead to call failures for different reasons out of fingerprints, crypto, etc.) for different reasons out of scope to
scope to this document. One notable example is the 'rtcp' [RFC3605] this document. One notable example is the 'rtcp' [RFC3605]
attribute, that UAC may make use of to explicitly state the port attribute, that UAC may make use of to explicitly state the port
they're willing to use for RTCP. Considering the B2BUA would relay they're willing to use for RTCP. Considering the B2BUA would relay
RTCP messages, the port as seen by the other UAC involved in the RTCP messages, the port as seen by the other UAC involved in the
communication would differ from the one negotiated originally, and it communication would differ from the one negotiated originally, and it
MUST be rewritten accordingly. MUST be rewritten accordingly. Apart from the mentioned attributes,
B2BUAs SHOULD forward all other SDP attributes they don't have a
reason not to forward, in order to avoid breaking additional
functionality endpoints may be relying on.
It is worth mentioning that, leaving RTCP messages untouched, a media It is worth mentioning that, leaving RTCP messages untouched, a media
relay may also leak information that, according to policies, may need relay may also leak information that, according to policies, may need
to be hidden or masqueraded, e.g., domain names in CNAME items. to be hidden or masqueraded, e.g., domain names in CNAME items.
Besides, these CNAME items may actually contain IP addresses: this Besides, these CNAME items may actually contain IP addresses: this
means that, should a NAT be involved in the communication, this may means that, should a NAT be involved in the communication, this may
actually result in CNAME collisions, which could indeed break the actually result in CNAME collisions, which could indeed break the
end-to-end RTCP behaviour. While [RFC7022] can prevent this from end-to-end RTCP behaviour. While [RFC7022] can prevent this from
happening, there may be implementations that don't make use of it. happening, there may be implementations that don't make use of it.
As such, a B2BUA MAY rewrite CNAME items if any potential collision As such, a B2BUA MAY rewrite CNAME items if any potential collision
skipping to change at page 12, line 5 skipping to change at page 12, line 9
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, when media security is involved, only the Media- This means that, when media security is involved, only the Media-
unaware Relay scenario can be properly addressed. Attempting to unaware Relay scenario can be properly addressed. Attempting to
cover Media-aware Relay and Media Termination scenarios when cover Media-aware Relay and Media Termination scenarios when
involving secure sessions will inevitably lead to the B2BUA acting as involving secure sessions will inevitably lead to the B2BUA acting as
a man-in-the-middle, and consequently its behaviour is unspecified a man-in-the-middle, and consequently its behaviour is unspecified
and discouraged. More considerations on this are provided in and discouraged. More considerations on this are provided in
[I-D.ietf-straw-b2bua-dtls-srtp]. [RFC7879].
It is also worth pointing out that there are scenarios where an It is also worth pointing out that there are scenarios where an
improper management of RTCP messaging across a B2BUA may lead, improper management of RTCP messaging across a B2BUA may lead,
willingly or not, to situations not unlike an attack. To make a willingly or not, to situations not unlike an attack. To make a
simple example, an improper management of a REMB feedback message simple example, an improper management of a REMB feedback message
containing, e.g., information on the limited bandwidth availability containing, e.g., information on the limited bandwidth availability
for a user, may lead to missing or misleading information to its for a user, may lead to missing or misleading information to its
peer. This may cause the peer to increase the encoder bitrate, maybe peer. This may cause the peer to increase the encoder bitrate, maybe
up to a point where a user with poor connectivity will inevitably be up to a point where a user with poor connectivity will inevitably be
choked by an amount of data it cannot process. This scenario may choked by an amount of data it cannot process. This scenario may
thus result in what looks like a Denial of Service (DOS) attack thus result in what looks like a Denial of Service (DOS) attack
towards the user. towards the user.
6. Change Summary 6. 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 11 and the 12
versions of the draft:
o Addressed remaining points in Ben's second review.
o Updated reference of STRAW's DTLS-SRTP draft to new [RFC7879].
The following are the major changes between the 10 and the 11 The following are the major changes between the 10 and the 11
versions of the draft: versions of the draft:
o Addressed Ben's second review. o Addressed Ben's second review.
The following are the major changes between the 09 and the 10 The following are the major changes between the 09 and the 10
versions of the draft: versions of the draft:
o Replaced references to obsoleted RFC 5117 with [RFC7667]. o Replaced references to obsoleted RFC 5117 with [RFC7667].
skipping to change at page 16, line 46 skipping to change at page 17, line 15
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, DOI 10.17487/RFC5506, April and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <http://www.rfc-editor.org/info/rfc5506>. 2009, <http://www.rfc-editor.org/info/rfc5506>.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022,
September 2013, <http://www.rfc-editor.org/info/rfc7022>. September 2013, <http://www.rfc-editor.org/info/rfc7022>.
[I-D.ietf-straw-b2bua-dtls-srtp] [RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V.,
R, R., Reddy, T., Salgueiro, G., Pascual, V., and P. and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back
Ravindran, "DTLS-SRTP Handling in Session Initiation User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016,
Protocol (SIP) Back-to-Back User Agents (B2BUAs)", draft- <http://www.rfc-editor.org/info/rfc7879>.
ietf-straw-b2bua-dtls-srtp-12 (work in progress), April
2016.
Authors' Addresses Authors' Addresses
Lorenzo Miniero Lorenzo Miniero
Meetecho Meetecho
Email: lorenzo@meetecho.com Email: lorenzo@meetecho.com
Sergio Garcia Murillo Sergio Garcia Murillo
Medooze Medooze
 End of changes. 10 change blocks. 
21 lines changed or deleted 31 lines changed or added

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