Re: [AVT] RFC 3711 and RTCP

[Mark Baugher <[e-mail]>]

Alan
   As Dave Oran has pointed out, the definition that you want is not  
supported in the signaling, at present.  The current definition of  
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions 
-07.txt treats SRTCP encryption as either on or off and does not  
address the problem of setting the E bit in SRTCP packets.  This is a  
bug that we need to fix.

   MMUSIC has finished last call on  
draft-ietf-mmusic-sdescriptions-07.txt, and the transport ADs have  
reviewed it.  We'll be making some changes at Jon Peterson's request  
and post another version in about a week.  This is an opportunity to  
address the E bit, but the MMUSIC chairs or transport ADs may want  
another WG last call.  Off the top of my head, I would offer something  
like the following.

"As the default behavior when UNENCRYPTED_SRTCP is signaled, all SRTCP  
packets MUST have the E bit set to zero and MUST NOT be encrypted.   
Otherwise, all SRTP packets MUST have the E bit set to one and MUST be  
encrypted by default.  Individual applications MAY override these  
default behaviors in their specifications.  In a session where SRTCP  
packets are encrypted, therefore, applications that use RFC 3611 MAY  
set the E bit to 0 for XR packets as recommended by RFC 3611."

Mark

On Nov 24, 2004, at 2:33 PM, Alan Clark wrote:

>
>
> 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