Subject: RE: [AVT] RFC 3711 and RTCP

From: "Oren Peleg" <[email-masked]>
Date: Wed, 24 Nov 2004 14:49:49 +0200

Isnt encryption is to prevent monitoring from the first place?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alan Clark
Sent: Tuesday, November 23, 2004 5:42 PM
To: [email-masked]
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
[email-masked]
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 [email-masked] and permanently delete the e-mail and files.

***********************************************************************************************************

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

---

From: "Alan Clark" <[email-masked]>
Date: Wed, 24 Nov 2004 07:54:06 -0500

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

Regards

Alan

-----Original Message-----

Regards

Alan Clark
Telchemy

****************************************************************************
********************************
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
[email-masked] and permanently delete the e-mail and files.

****************************************************************************
*******************************

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Wed, 24 Nov 2004 09:38:40 -0500

>The message is - encrypt RTP, optionally encrypt RTCP SDES but don't encrypt

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

---

From: Mark Baugher <[email-masked]>
Date: Wed, 24 Nov 2004 09:16:13 -0800

It's not possible to selectively encrypt SRTCP packets.  The default is  
to encrypt SRTCP, but it is a matter of policy.  Presumably, SRTCP will  
be authenticated and not encrypted when monitoring is desired.  I think  
Alan's plea to implementers should be to ensure that SRTCP encryption  
is strictly optional.

Mark

---

From: "Alan Clark" <[email-masked]>
Date: Wed, 24 Nov 2004 12:23:56 -0500

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.

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

Regards

Alan

-----Original Message-----
From: Michael A. Ramalho [mailto:[email-masked]]
Sent: Wednesday, November 24, 2004 9:39 AM
To: Alan Clark
Cc: Oren Peleg; [email-masked]
Subject: RE: [AVT] RFC 3711 and RTCP

Hi Alan,

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

Regards,

Michael Ramalho

---

From: David R Oran <[email-masked]>
Date: Wed, 24 Nov 2004 13:05:12 -0500

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

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

>> ********************************************************************** 
>> *****
> *
>> distribution or copying of this communication is strictly prohibited  
>> and
> may
>> be unlawful.
>>
>> ********************************************************************** 
>> *****
> *
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Mark Baugher <[email-masked]>
Date: Wed, 24 Nov 2004 10:23:46 -0800

On Nov 24, 2004, at 9:16 AM, Mark Baugher wrote:

> It's not possible to selectively encrypt SRTCP packets.

I was wrong about this:  Section 3.4 of  
http://www.ietf.org/rfc/rfc3711.txt describes the E bit, which allows  
selective encryption of SRTP packets.

Mark
> The default is to encrypt SRTCP, but it is a matter of policy.   
> Presumably, SRTCP will be authenticated and not encrypted when  
> monitoring is desired.  I think Alan's plea to implementers should be  
> to ensure that SRTCP encryption is strictly optional.
>
> Mark
>>> and may

---

From: Mark Baugher <[email-masked]>
Date: Wed, 24 Nov 2004 10:33:14 -0800

On Nov 24, 2004, at 10:05 AM, David R Oran wrote:

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

---

From: "Alan Clark" <[email-masked]>
Date: Wed, 24 Nov 2004 13:58:18 -0500

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: [email-masked] [mailto:[email-masked]]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;
[email-masked]
Subject: Re: [AVT] RFC 3711 and RTCP

Mark

---

From: Mark Baugher <[email-masked]>
Date: Wed, 24 Nov 2004 11:42:08 -0800

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

---

From: "Alan Clark" <[email-masked]>
Date: Wed, 24 Nov 2004 17:33:42 -0500

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:[email-masked]]
Sent: Wednesday, November 24, 2004 2:42 PM
To: Alan Clark
Cc: Oren Peleg; Cullen Jennings; [email-masked]; David R Oran; Michael A.
Ramalho

Mark

---

From: Mark Baugher <[email-masked]>
Date: Wed, 24 Nov 2004 16:18:10 -0800

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:

>>>>> The message is - encrypt RTP, optionally encrypt RTCP SDES but  
>>>>> don't
>>>> encrypt
>>>>> RTCP SR/RR/XR
>>>>
>>>> Hi Alan,
>>>>
>>>>> that RFC3711 implementors DO NOT encrypt RTCP SR, RR and XR  
>>>>> payloads
>>>>> as
>>>>> this
>>>>> ******************************************************************* 
>>>>> *
>>>>> *
>>>>> ******
>>>> *
>>>>> They are intended solely for the use of the designated individual  
>>>>> or
>>>>> entity
>>>>> ******************************************************************* 
>>>>> *
>>>>> *
>>>>> ******
>>>> *

---

From: "Alan Clark" <[email-masked]>
Date: Fri, 26 Nov 2004 13:38:08 -0500

Mark

The language you suggest would address the issue.  It would be great if you
could incorporate this

Regards

Alan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Mark Baugher
Sent: Wednesday, November 24, 2004 7:18 PM
To: Alan Clark
Cc: Colin Perkins; Joerg Ott; IETF AVT WG; Jon Peterson;
[email-masked]'
Subject: Re: [AVT] RFC 3711 and RTCP

Alan

Mark