Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP

[Mark Baugher <[e-mail]>]

Michael
   Here's my take on the security of all of this:  Endpoints can choose 
to negotiate UNENCRYPTED_SRTCP or refuse such an offer, but the goal is 
to not force use of UNENCRYPTED_SRTCP when only the XR packet needs to 
be in the clear.  If we enabled the E bit for XR packets, that would 
not prevent an endpoint from rejecting the offer or any offer in which 
the SRTCP is not encrypted.

   If one does not want to expose information in the XR packets, then 
reject UNENCRYPTED_SRTCP or any offer that allows use of the E bit (in 
the future).  I don't see any security problem apart from having no 
recourse except to offer UNENCRYPTED_SRTCP when all that is desired is 
to leave one SRTCP packet type in the clear.

   Besides that, all sequence numbers are always in the clear in SRTP.

Mark
On Dec 8, 2004, at 11:01 AM, Michael A. Ramalho wrote:

> At 09:02 AM 12/2/2004 -0800, Mark Baugher wrote:
>> Dan
>>   I think use of the E bit needs to be explicitly signaled the SDP 
>> security descriptions.  That way, an offerer or answerer can express 
>> whether it wants to have all SRTCP messages encrypted or allow some 
>> to be in the clear.  I don't know if we need to call out the specific 
>> SRTCP messages that may be left in the clear or do make it "general 
>> purpose."
>
> Mark,
>
> I was looking into this last week. I think it would be unwise to leave
> UNencrypted any RTCP block type that has RTP Sequence Numbers
> in it (as they would be in the clear).
>
> For example, the Loss RLE block (a RTCP-XR block) has information
> on the base RTP sequence numbers the Loss RLE block reports on.
> There are many such RTCP-XR block types (but the VoIP Metrics
> Block is not one of these :-)).
>
> This would expose a "guess-able range" for *part of* the packet index
> used in SRTP (as I remember it, the SRTP packet index uses the
> RTP sequence number for low order portion of the packet index).
> I think this would be a no-no for the cryptographic experts.
>
>> A general-purpose approach would be to signal that ENCRYPTED_SRTP can 
>> be overridden for any packet for which the sender chooses to clear 
>> the E bit.  The general-purpose mechanism might be suitable for going 
>> into draft-ietf-mmusic-sdescriptions-08.txt.  If we want to 
>> explicitly signal that the E bit can be clear just for XR packets 
>> when UNENCRYPTED_SRTCP is set, then I think that belongs in RFC 
>> 3611bis.
>
> If my assertion/guess above is correct, then I'd only recommend the
> option to leave in the clear only those RTCP-XR packets that do not
> expose information sensitive to the SRTP context. This would be a 
> trivial
> exercise (to look at the blocks and decide which ones you do not want
> sent in the clear) but does complicate the permutations/combinations of
> what would need to be signaled in SDP.
>
> And then, since RTPC blocks may be piggybacked, one must take
> care not to have*potentially unencrptable* blocks piggybacked with
> other "normally encrypted" blocks. I still don't like the potential 
> interaction
> between the "encryption" and "RTCP" layers here.
>
> Michael Ramalho
>
>
>> Mark
>> On Dec 2, 2004, at 3:45 AM, Romascanu, Dan ((Dan)) wrote:
>>
>>> I would be cautious in saying that in no circumstances the contents 
>>> of an XR payload would be remotely useful to an eavesdropper. We may 
>>> encounter some very security aware environments where even the fact 
>>> that a call happens between two IP phones, its duration, or QoS 
>>> parameters need to be kept confidential. For this reason, while 
>>> working to provide a strong recommendation for RTCP XR packets not 
>>> to be encrypted, I do not believe that we can make this a MUST 
>>> requirements. As an alternative, I suggest to use  RAQMON extensions 
>>> to report the RTCP XR metrics to RAQMON collectors without the 
>>> security risks that may be of concern in some environments.
>>>
>>> Regards,
>>>
>>> Dan
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: [e-mail]
>>>> [mailto:[e-mail]]On Behalf Of Alan Clark
>>>> Sent: 01 December, 2004 2:08 PM
>>>> To: Mark Baugher
>>>> Cc: [e-mail]
>>>> Subject: [MMUSIC] RE: [AVT] RFC 3711 and RTCP
>>>>
>>>>
>>>> Mark
>>>>
>>>> To provide some background to the list - RFC3611 states the
>>>> following:-
>>>>
>>>>    "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."
>>>>
>>>> I can't conceive of any circumstance in which the contents of
>>>> an XR payload
>>>> would be remotely useful to an eavesdropper and hence stating that 
>>>> XR
>>>> payloads should always be left unencrypted would be (at least
>>>> in my opinion)
>>>> ok.  If we wanted to make this even more specific we could narrow 
>>>> this
>>>> requirement down to only XR VoIP Metrics payloads to avoid
>>>> the situation in
>>>> which some future XR payload may be problematic.
>>>>
>>>> The availability of VoIP metrics payloads will be a huge
>>>> issue for service
>>>> providers - as we move through 2005 RTCP XR will be a mainstay of 
>>>> VoIP
>>>> performance management and is already a mandatory requirement
>>>> within certain
>>>> sectors of the industry.  Making the VoIP metrics payload
>>>> unencrypted by
>>>> default may seem a small issue today however it will have
>>>> major consequences
>>>> to the industry as SRTP starts to roll out.
>>>>
>>>> Regards
>>>>
>>>> Alan
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Mark Baugher [mailto:[e-mail]]
>>>> Sent: Tuesday, November 30, 2004 6:45 PM
>>>> To: Alan Clark
>>>> Cc: [e-mail]
>>>> Subject: Re: [AVT] RFC 3711 and RTCP
>>>>
>>>>
>>>> Alan
>>>>    I am copying MMUSIC (and not cross-posting to AVT) to
>>>> further discuss
>>>> a possible change to SDP security descriptions, which has completed 
>>>> WG
>>>> last call.  The change is needed for RFC 3611, and we also 
>>>> discovered
>>>> that
>>>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions
>>>> -07.txt does not address the SRTCP E bit properly. I offered the
>>>> following text in a posting to AVT:
>>>> "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."
>>>>
>>>> One of my co-authors pointed out that the last sentence is
>>>> more than an
>>>> editorial change.  We also don't like the fact that an offerer or
>>>> answerer cannot explicitly signal when it wants the XR packet to be
>>>> encrypted or unencrypted.  In other words, if ENCRYPTED_SRTCP is the
>>>> default setting and RFC 3611 is also signaled, it is ambiguous as to
>>>> whether the SRTCP sender will encrypt the XR packet or not.  It's
>>>> solely up to the sender.  If the offerer or answerer want the
>>>> XR packet
>>>> to always be encrypted, there is no way to signal that.  Ditto for 
>>>> the
>>>> unencrypted case.
>>>>
>>>> I think we need to put the first three sentences of the above-quoted
>>>> paragraph into SDP security descriptions as an editorial change.  
>>>> I'm
>>>> proposing this to the working group.  I also propose not to
>>>> include the
>>>> last sentence.  Instead, we could add a new signaling parameter,
>>>> UNENCRYPTED_XR, which implies that all SRTCP messages are to be
>>>> encrypted except for the XR packets, which will have their E
>>>> bit clear,
>>>> of course.
>>>>
>>>> This new parameter could be placed in an RFC 3611bis or in a 
>>>> revision
>>>> of draft-ietf-mmusic-sdescriptions-07.txt, which will then need to
>>>> undergo another WG last call.  What do you (all) think about this?
>>>>
>>>> Mark
>>>>
>>>> On Nov 24, 2004, at 4:18 PM, Mark Baugher wrote:
>>>>
>>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [e-mail]
>>>> https://www1.ietf.org/mailman/listinfo/mmusic
>>>
>>> _______________________________________________
>>> 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