RE: [AVT] RFC 3711 and RTCP

["Michael A. Ramalho" <mramalho at cisco.com>]

At 07:54 AM 11/24/2004 -0500, Alan Clark wrote:
> Hi Oren
>
> Yes - encryption is intended to provide privacy however this relates
> primarily to the voice payloads and to information within RTCP that may be
> associated with individual users (e.g. SDES).
>
> SR, RR and XR contain only peformance statistics and there is no privacy
> consideration that I can think of related to this type of data.
>
> The message is - encrypt RTP, optionally encrypt RTCP SDES but don't encrypt
> RTCP SR/RR/XR

Hi Alan,

I am wondering about implementations utilizing your advise "optionally encrypt
RTCP SDES but don't encrypt RTCP SR/RR/XR".

Is there an easy way to tell SRTP to encrypt RTCP SDES, but not RTCP
SR/RR/XR? It seems that all the RTCP blocks would otherwise be highly
related to each other. For example (quote out of RFC 3611):

"XR packets supplement the existing RTCP packets, and may be stacked with
other RTCP packets to form compound RTCP packets [9, Section 6]."

Thus, RFC3611 explicitly admits the possibility of (but does not mandate)
the piggybacking all the RTCP-XR block types.

RTCP implementations would have to know the SRTP encryption rules to
make sure they don't perform piggybacking with SDES ... but could allow
(the more bandwidth efficient) piggybacking on the other RTCP-XR blocks.

This RTCP/SRTP interaction/dependency seems to add a burden to both
RTCP and SRTP implementations ... let alone the expressiveness required
to signal your advise in existing SDP/SRTP mechanisms.

Are you aware of any implementations that have actually followed your
advise above? I rather go into this one with our eyes open ... developers
highly dislike this cross-functional entity dependency (RTCP & SRTP along
with expressing it in SDP/SRTP mechanisms).

Regards,

Michael Ramalho



> Regards
>
> Alan
>
> -----Original Message-----
> From: Oren Peleg [mailto:OrenP at audiocodes.com]
> Sent: Wednesday, November 24, 2004 7:50 AM
> To: Alan Clark; avt at ietf.org
> Subject: RE: [AVT] RFC 3711 and RTCP
>
>
>
> Isnt encryption is to prevent monitoring from the first place?
>
> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
> Alan Clark
> Sent: Tuesday, November 23, 2004 5:42 PM
> To: avt at ietf.org
> Subject: [AVT] RFC 3711 and RTCP
>
>
> >From the flurry of discussion on RFC3711 it looks as if there is
> considerable interest in SRTP implementation.  I'd like to add a request
> to
> SRTP implementors with regard to manageability.
>
> RTCP SR, RR and more particularly XR (e.g. VoIP Metrics report block)
> contain useful information for network monitoring, and are often used by
> probes and analyzers to support problem diagnosis.  RFC3711 allows the
> selective encryption of RTCP payloads and hence I would strongly
> recomment
> that RFC3711 implementors DO NOT encrypt RTCP SR, RR and XR payloads as
> this
> adversely impacts manageability.
>
> Regards
>
> Alan Clark
> Telchemy
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>
> ****************************************************************************
> ********************************
> This email and any files transmitted with it are confidential material.
> They are intended solely for the use of the designated individual or entity
> to whom they are addressed.
> If the reader of this message is not the intended recipient,
> you are hereby notified that any dissemination,use,
> distribution or copying of this communication is strictly prohibited and may
> be unlawful.
>
> If you have received this email in error please notify
> postmaster at audiocodes.com and permanently delete the e-mail and files.
>
>
> ****************************************************************************
> *******************************
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www1.ietf.org/mailman/listinfo/avt


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt