RE: [AVT] RFC 3711 and RTCP

["Alan Clark" <[e-mail]>]

Mark

We tried to flag this in RFC3611 with the following text in the "security
considerations" section

   Any encryption or filtering of XR report blocks entails a loss of
   monitoring information to third parties.  For example, a network that
   establishes a tunnel to encrypt VoIP Report Blocks denies that
   information to the service providers traversed by the tunnel.  The
   service providers cannot then monitor or respond to the quality of
   the VoIP calls that they carry, potentially creating problems for the
   network's users.  As a default, XR packets should not be encrypted or
   filtered.

Could we potentially interpret this as being the definition of what to
selectively encrypt in the case of the RFC3611 specification?

Regards

Alan


-----Original Message-----
From: Mark Baugher [mailto:[e-mail]]
Sent: Wednesday, November 24, 2004 2:42 PM
To: Alan Clark
Cc: Oren Peleg; Cullen Jennings; [e-mail]; David R Oran; Michael A.
Ramalho
Subject: Re: [AVT] RFC 3711 and RTCP


So, when the sender and receiver agree to encrypt SRTCP, this would mean
only that some SRTCP messages would be encrypted and the sender would
decide which ones to encrypt?  My personal opinion is that this is not
secure because it is unpredictable to the receiver, which may have a
policy that all messages related to its session be encrypted.

I can think of a few potential approaches to this problem.

1. Let individual SRTCP messages or a bundle of SRTCP messages
be signaled to be unencrypted when SRTCP encryption is used.

2. Make a blanket policy that the sender determine what
to selectively encrypt, as you suggest.

3. Define the policy of what to selectively encrypt in
the particular specification.  In other words, a document could
re-define the signaling of SRTCP encryption according to its
needs.  The specification of foo, therefore, could define a new
parameter such as foo_ENCRYPTED_SRTCP to be used in place of
ENCRYPTED_SRTCP.  The foo document would define what gets
encrypted and what does not get encrypted as per its needs.

I commented on #2 already.  I don't like #1 because of its signaling
complexity.  I like #3 because it limits the complexity to the
specific needs of an application.  #1 would be more efficient than
#3 if lots of applications had their own specific needs for
selective encryption of SRTCP message.  But I don't think this is
the case.

Mark

On Nov 24, 2004, at 10:58 AM, Alan Clark wrote:

>
> If the use of encryption in SRTCP is signalled by an explicit (E) bit
> in the
> SRTCP header then perhaps the sender could autonomously decide whether
> it
> wants to encrypt?  Presumably since the sender is in the best position
> to
> decide if the data is sensitive then this would be ok - and the
> receiver is
> able to just look at the E bit and hence recognize that decryption is
> needed.
>
> Alan
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of
> Mark Baugher
> Sent: Wednesday, November 24, 2004 1:33 PM
> To: David R Oran
> Cc: Cullen Jennings; Oren Peleg; Michael A. Ramalho; Alan Clark;
> [e-mail]
> Subject: Re: [AVT] RFC 3711 and RTCP
>
>
>
> On Nov 24, 2004, at 10:05 AM, David R Oran wrote:
>
>>
>> On Nov 24, 2004, at 12:23 PM, Alan Clark wrote:
>>
>>>
>>> Michael
>>>
>>> I don't see why this would be a problem unless you included SDES and
>>> (SR or
>>> RR or XR) in the same RTCP packet.  SRTP (at least the protocol) is
>>> apparently able to decided on a packet by packet basis whether to
>>> encrypt
>>> RTCP - hopefully SRTP implementations also permit this.
>>>
>> Sure, they can do this. But remember offer-answer. How does a receiver
>> communicate such a granular policy to the transmitter? Right now if
>> can say whether to auth or auth+encrypt RTP, and auth or auth+encrypt
>> RTCP. There's no way to say auth+encrypt SDES but only auth SR/XR etc.
>
> Seems to me that this is a problem with SDP security descriptions.
> That problem might be there because we forgot about the E bit.  This
> seems very messy for the reason you mention above - granularity.  I
> don't think that we want to negotiate the encryption policy for each
> type SDP message, which is a problem with something like the E bit.
>
> Mark
>>
>>
>>> Logically I'd send SDES on its own at the start of a call to provide
>>> some
>>> user info, but would not send SR/RR/XR until at least 8-10 seconds
>>> into the
>>> call as I need some time to gather statistics to report.
>> That's not exactly what the RTP specs say. RTCP timers don't have this
>> kind of policy today. In fact, there are porposals on the table to use
>> RTCP for early feedback to assess reception quality on some initial
>> packets - e.g. the RTP-noop proposal. In any event that has no bearing
>> on the present discussion.
>>
>>> After the
>>> start-of-call exchange there would appear to be minimal need to
>>> include
>>> SDES. I'm sure we could construct some scenarios in which you "may"
>>> need to
>>> include SDES with SR/RR/XR however the vast majority of cases would
>>> either
>>> need only a single initial exchange or may not need SDES at all.
>>>
>> Any time you change SSRC you potentially need to send SDES.
>> That said, I still don't see what bearing this has on the discussion
>> about whether we need the complexity of encrypting some RTCP packets
>> and not others for a single session.
>>
>> It's a tradeoff between extra complexity+less privacy versus allowing
>> snoopers to gather RTCP stats.
>>
>> Dave.
>>
>>> Regards
>>>
>>> Alan
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Michael A. Ramalho [mailto:[e-mail]]
>>> Sent: Wednesday, November 24, 2004 9:39 AM
>>> To: Alan Clark
>>> Cc: Oren Peleg; [e-mail]
>>> Subject: RE: [AVT] RFC 3711 and RTCP
>>>
>>>
>>> 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:[e-mail]]
>>>> Sent: Wednesday, November 24, 2004 7:50 AM
>>>> To: Alan Clark; [e-mail]
>>>> Subject: RE: [AVT] RFC 3711 and RTCP
>>>>
>>>>
>>>>
>>>> Isnt encryption is to prevent monitoring from the first place?
>>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On Behalf
>>>> Of
>>>> Alan Clark
>>>> Sent: Tuesday, November 23, 2004 5:42 PM
>>>> To: [e-mail]
>>>> 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
>>>> [e-mail]
>>>> 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
>>>> [e-mail] and permanently delete the e-mail and
>>>> files.
>>>>
>>>>
>>>> ********************************************************************
>>>> *
>>>> ******
>>> *
>>>> *******************************
>>>>
>>>>
>>>> _______________________________________________
>>>> Audio/Video Transport Working Group
>>>> [e-mail]
>>>> https://www1.ietf.org/mailman/listinfo/avt
>>>
>>>
>>> _______________________________________________
>>> Audio/Video Transport Working Group
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/avt
>>>
>> David R. Oran
>> Cisco Fellow
>> Cisco Systems
>> 7 Ladyslipper Lane
>> Acton, MA 01720 USA
>> Tel: [phone]
>> Email: [e-mail]
>>
>>
>> _______________________________________________
>> Audio/Video Transport Working Group
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/avt
>>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt
>


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt