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

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Fri, 3 Dec 2004 11:01:40 +0200

I do not really have a strong preference. My inclination is to leave RFC 3611 as it is and to change draft-ietf-mmusic-sdescriptions to describe how to use the E bit. It looks like the right place to define SDP security descriptions, and has chances to run faster through the process. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of Mark Baugher
> Sent: 03 December, 2004 3:32 AM
> To: Alan Clark; Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP
> 
> 
> Alan, Dan
>    I don't know where the discussion is going.  The point of 
> all this is 
> to allow RFC 3611 to use SRTP, which is not of direct interest to 
> rmonmib.  There is a problem signaling SRTP for RFC 3611 using SDP 
> security descriptions, which is not of direct interest to 
> AVT.  Because 
> RFC 3611 uses a SHOULD for leaving SRTCP XR messages in the 
> clear when 
> other SRTCP messages are encrypted, we have an ambiguity in the 
> signaling.  This ambiguity arises because SDP security descriptions 
> doesn't address use of the SRTCP E bit, which XR needs 
> packets need to 
> use.  At least two of the authors of SDP security descriptions think 
> that we need to remove the ambiguity.  So here are the choices that I 
> see.
> 
> 1. change RFC 3611 to describe how to do SDP security descriptions 
> signaling
> 2. change draft-ietf-mmusic-sdescriptions to describe how to 
> use the E 
> bit.
> 
> I would not be surprised if you favored #2.  I like #1.  But I am 
> willing to add a new parameter to sdescriptions and then run 
> it through 
> WG last call.  I'd like to resolve this and move forward.
> 
> Mark
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Mon, 6 Dec 2004 23:21:35 +0000

I'd also prefer this change to be made in sdescriptions (which needs 
another revision to address Jon Peterson's comments anyway, right?)

Colin

On 3 Dec 2004, at 09:01, Romascanu, Dan ((Dan)) wrote:
> I do not really have a strong preference. My inclination is to leave 
> RFC 3611 as it is and to change draft-ietf-mmusic-sdescriptions to 
> describe how to use the E bit. It looks like the right place to define 
> SDP security descriptions, and has chances to run faster through the 
> process.
>
> Regards,
>
> Dan
>
>
>

---

From: Mark Baugher <[email-masked]>
Date: Mon, 6 Dec 2004 15:32:28 -0800

Yes it does.  There are two possible approaches.  We have an existing 
parameter called UNENCRYPTED_SRTCP, but the default is to encrypt the 
SRTCP.  We could add a parameter specific to RFC 3611 or SRTCP XR 
packets such as UNENCRYPTED_SRTCP_XR, which would mean that SRTCP is 
encrypted but the XR packets are to be left in the clear (and signaled 
using the E bit).  That's my current default if no one speaks up with 
an alternative preference.

I'd like to resolve this issue by around the middle of the week and 
generate a new version of sdescriptions.

Mark
On Dec 6, 2004, at 3:21 PM, Colin Perkins wrote:

>> describe how to use the E bit. It looks like the right place to 
>> define SDP security descriptions, and has chances to run faster 
>> through the process.
>>
>> Regards,
>>
>> Dan
>>
>>
>>

---

From: "Alan Clark" <[email-masked]>
Date: Mon, 6 Dec 2004 19:27:26 -0500

Mark

I support your UNENCRYPTED_SRTCP_XR solution, and thanks for resolving the
issue.

Regards

Alan Clark

-----Original Message-----
From: Mark Baugher [mailto:[email-masked]]
Sent: Monday, December 06, 2004 6:32 PM
To: Colin Perkins
Cc: Romascanu, Dan (Dan); [email-masked]; Alan Clark
Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP

Mark

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 06 Dec 2004 21:38:40 -0500

There are two issues here:
1. Relationship between the SRTCP E flag and the UNENCRYPTED_SRTCP 
sdescriptions parameter.
2. The ability to selectively encrypt parts of your SRTCP.

On the first issue, I agree the sdescriptions need to be clarified.

On the second issue, I understand, from a pragmatic point of view, the 
desire to leave RTCP XR in the clear, but I have some general concerns 
with the idea of specifying a security negotiation protocol that leaves 
certain information in the clear for the sole purpose of having 
intermediaries snoop on it. Considering that we have already been 
through WG last call and AD review of sdescriptions, I would like to 
hear from both the WG chairs and the ADs, that they consider such a 
mechanism reasonable before we proceed here.

Assuming that to be the case, we need to note that sdescriptions makes a 
distinction between negotiated and declarative session parameters (see 
Section 3.4). Is the suggestion here to make this new parameter 
negotiated (i.e. both sides have to agree on it, and it applies in both 
directions), or declarative (each side merely indicates what he will do 
with packets sent by him) ? Since UNENCRYPTED_SRTCP is a negotiated 
parameter, I assume UNENCRYPTED_SRTCP_XR would also be negotiated. 
Similarly, given the name of the parameter, I assume absence of it means 
that all of SRTCP will be encrypted (unless signaled otherwise). If so, 
this means that we will only leave SRTCP_XR in the clear if both sides 
explicitly negotiate support for that, which sounds like a reasonable 
suggestion to me.
 
-- Flemming

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 07 Dec 2004 13:04:19 +0100

Hi Mark,

> an alternative preference.

I think one should consider that there actually may be need to negotiate 
what should be left unencrypted, or the other way around. Therefore my 
proposal would be to define a "PARTIALENCRYPTED_SRTCP" and then another 
negotiated attribute listing the RTCP packet types that should be 
protected or the other way around. One can also consider if the normal 
case is based on senders local policy.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Mark Baugher <[email-masked]>
Date: Tue, 7 Dec 2004 07:06:16 -0800

On Dec 6, 2004, at 6:38 PM, Flemming Andreasen wrote:

> with the idea of specifying a security negotiation protocol that 
> leaves certain information in the clear for the sole purpose of having 
> intermediaries snoop on it.

They are free to negotiate whether or not all SRTCP messages are 
unencrypted so there is no security hole in allowing offerers and 
answerers to negotiate whether or not to leave one type of SRTCP 
message in the clear.

> Considering that we have already been through WG last call and AD 
> review of sdescriptions, I would like to hear from both the WG chairs 
> and the ADs, that they consider such a mechanism reasonable before we 
> proceed here.
>
> Assuming that to be the case, we need to note that sdescriptions makes 
> a distinction between negotiated and declarative session parameters 
> (see Section 3.4). Is the suggestion here to make this new parameter 
> negotiated (i.e. both sides have to agree on it, and it applies in 
> both directions), or declarative (each side merely indicates what he 
> will do with packets sent by him) ? Since UNENCRYPTED_SRTCP is a 
> negotiated parameter, I assume UNENCRYPTED_SRTCP_XR would also be 
> negotiated. Similarly, given the name of the parameter, I assume 
> absence of it means that all of SRTCP will be encrypted (unless 
> signaled otherwise).

Yes.
> If so, this means that we will only leave SRTCP_XR in the clear if 
> both sides explicitly negotiate support for that, which sounds like a 
> reasonable suggestion to me.

Ok.

Mark
>> encrypted but the XR packets are to be left in the clear (and 
>> signaled using the E bit).  That's my current default if no one 
>> speaks up with an alternative preference.
>>
>>>> I do not really have a strong preference. My inclination is to 
>>>> leave RFC 3611 as it is and to change 
>>>> draft-ietf-mmusic-sdescriptions to describe how to use the E bit. 
>>>> It looks like the right place to define SDP security descriptions, 
>>>> and has chances to run faster through the process.
>>>>
>>>> Regards,
>>>>
>>>> Dan
>>>>
>>>>
>>>>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 07 Dec 2004 10:23:25 -0500

Magnus Westerlund wrote:

> I think one should consider that there actually may be need to 
> negotiate what should be left unencrypted, or the other way around. 
> Therefore my proposal would be to define a "PARTIALENCRYPTED_SRTCP" 
> and then another negotiated attribute listing the RTCP packet types 
> that should be protected or the other way around. One can also 
> consider if the normal case is based on senders local policy.
>
Hmm, I think we are getting on a slippery slope here with an extended 
scope, which is part of my initial concern with the whole idea of 
partially encrypted streams for the benefit of intermediate snoopers. 
What about the RTP stream ? Should we allow different treatment of 
different RTP packets, e.g. based on payload type, etc. ? Taking a step 
back, what are the motivations behind all of this added complexity and 
is this really the right time to expand the scope this way ?

-- Flemming

---

From: Colin Perkins <[email-masked]>
Date: Tue, 7 Dec 2004 16:53:06 +0000

On 7 Dec 2004, at 15:23, Flemming Andreasen wrote:
>>> signaled
> different RTP packets, e.g. based on payload type, etc. ? Taking a 
> step back, what are the motivations behind all of this added 
> complexity and is this really the right time to expand the scope this 
> way ?

All good points. How difficult would it be to write this up as a 
separate draft? That would allow the "sdescriptions" work to progress 
quickly, and allow us time to analyse the requirements for partial 
encryption, write a considered specification of the various parameters, 
and enumerate the new security considerations that might arise.

Colin

---

From: Mark Baugher <[email-masked]>
Date: Tue, 7 Dec 2004 09:22:38 -0800

hi Magnus,

> consider if the normal case is based on senders local policy.

I don't think there are any security concerns in doing what you suggest 
apart from complexity.  It is more secure to allow a particular SRTCP 
packet to be in the clear rather than having to keep all of them in the 
clear for the sake of monitoring one or a subset of the SRTCP.  This is 
the point of the E bit, I suppose.  The problem I have with negotiating 
which packet types would be encrypted or not is the complexity and the 
concomitant effort needed to test the protocol, which doubles the SRTCP 
test cases since each case needs to be run with each SRTCP message in 
the clear and encrypted using E bit settings.  It's actually much worse 
since we're dealing with subsets.  The signaling complexity is also 
huge:  For all practical purposes, implementations never test all 
possible subsets of SRTCP packets in a PARTIALENCRYPTED_SRTCP 
negotiation.  Given this level of complexity and the challenges of 
testing, the overall security of the implementations will be much 
weaker than if we kept it simple.

We would need to have a real strong motivation to take on this burden.  
So far, we have had one group ask to have one message optionally left 
in the clear when SRTCP is encrypted.  That's XR.  I think this is 
manageable.

Mark

---

From: Mark Baugher <[email-masked]>
Date: Tue, 7 Dec 2004 16:43:46 -0800

Colin
   Do we know of any other applications besides RFC 3611 that might need 
to selectively encrypt SRTCP packets?

   I am okay with putting this requirement aside pending a separate 
document.  But before someone goes to the trouble of writing the new 
draft, it might be good to consider if it's needed or not.

Mark
On Dec 7, 2004, at 8:53 AM, Colin Perkins wrote:

> encryption, write a considered specification of the various 
> parameters, and enumerate the new security considerations that might 
> arise.
>
> Colin
>
>

---

From: Colin Perkins <[email-masked]>
Date: Fri, 10 Dec 2004 11:47:35 +0000

Mark,

On 8 Dec 2004, at 00:43, Mark Baugher wrote:
>   Do we know of any other applications besides RFC 3611 that might 
> need to selectively encrypt SRTCP packets?

I don't, but I can imagine future RTCP extensions which might require 
this feature (and applications that might want to encrypt various 
subsets of the RFC 3611 data).

> draft, it might be good to consider if it's needed or not.

Even if RTCP XR is the only driver, it might be appropriate to make 
that a separate short draft. There's been enough discussion on the list 
that I'm not entirely comfortable slotting it into sdescriptions this 
late in the process.

Colin

---

From: Mark Baugher <[email-masked]>
Date: Fri, 10 Dec 2004 08:02:32 -0800

Colin,

> subsets of the RFC 3611 data).

I don't see a large downside in waiting until we see such extensions 
for real.
> that a separate short draft. There's been enough discussion on the 
> list that I'm not entirely comfortable slotting it into sdescriptions 
> this late in the process.

Ok.  If there are no objections, I'll generate a new version and post 
it early next week.

Mark

---

From: "Alan Clark" <[email-masked]>
Date: Fri, 10 Dec 2004 16:05:12 -0500

Mark, Colin

Where does this leave the issue?  Some sizeable network and telecom
equipment vendors are in the process of integrating support for the RFC3611
VoIP metrics, due in a large part to service provider and enterprise
customer demand.  The demand exists because customers need to manage their
VoIP deployments, hence they see RFC3611 as a key element in their
management infrastructure.  The accessibility of RFC3611 VoIP metrics is
therefore an issue of concern today.

If it's proposed to deal with this in a separate draft then what is the
expected timeframe - going through the regular I-D, WG draft, IESG process
seem to take a year or so. Is there some mechanism by which this can be
accelerated?

If the proposal is to address the issue in the draft currently being
finalized then my apologies if this has caused any last minute delays
however the issue is important enough to warrant this (at least in my view).
We hoped that the comment in the security considerations section of RFC3611
was strong enough to address the issue however it appears not to have been.

Regards

Alan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Mark Baugher
Sent: Friday, December 10, 2004 11:03 AM
To: Colin Perkins
Cc: [email-masked]
Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP

Colin,

Mark

---

From: Mark Baugher <[email-masked]>
Date: Fri, 10 Dec 2004 15:38:58 -0800

Alan,
   I'm finishing sdescriptions-08 without any change to accommodate XR 
packets to use the E bit.  I don't yet know who is going to do the work 
on the I-D that Colin suggested to address Magnus' issues with E-bit 
usage.  As it stands now, UNENCRYPTED_SRTCP will need to be signaled in 
order to keep XR packets in the clear.

Mark

---

From: Marc Manthey <[email-masked]>
Date: Sat, 11 Dec 2004 04:09:03 +0100

<snip>...This document defines the Extended Report (XR) packet type for 
the
    RTP Control Protocol (RTCP), and defines how the use of XR packets
    can be signaled by an application if it employs the Session
    Description Protocol (SDP).
</snip>
a protocol that protocols a protocol....

*SCNR*

leave it like it is;)

cheers

marc
-- 
    "Fragmentation is like classful addressing , an interesting early
    architectural error that shows how much experimentation was going
    on while IP was being designed."

            http://www.multicasttech.com/status/msdp.html

---

From: Colin Perkins <[email-masked]>
Date: Sat, 11 Dec 2004 12:23:21 +0000

Alan,

> therefore an issue of concern today.

Understood. I note that the sdescriptions work is also eagerly awaited 
by the industry.

> seem to take a year or so. Is there some mechanism by which this can be

We have little influence on the IESG process, but the working group 
doesn't have to take a long time. If this issue is straightforward, we 
should be able to document a solution that can be progressed to the 
IESG very quickly. Would you be willing to write such a draft?

Colin

---

From: "Alan Clark" <[email-masked]>
Date: Sat, 11 Dec 2004 07:58:34 -0500

Colin

I would of course be willing to write a suitable draft if this will expedite
things

Regards

Alan

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: Saturday, December 11, 2004 7:23 AM
To: Alan Clark
Cc: [email-masked]; Mark Baugher
Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP

Alan,

Colin

---

From: "Alan Clark" <[email-masked]>
Date: Sat, 11 Dec 2004 09:50:00 -0500

It would seem that an additional draft needs to state roughly the following:

(i) Scope - provides method for selective encryption/ unencryption of
certain RTCP payload types

(ii) Approach - allow for SRTCP encryption to be set ON by default but
overridden for certain payload types

(iii) New parameter

SELECTIVE_SRTCP_UNENCRYPTED means that by default RTCP frames are encrypted
with the exception of the listed payload types

List of RTCP payload types .. SDES, BYE, RR, SR, XR, XR_VOIPMETRICS, XR_...

Some compound types (for convenience) .. ALL_INFORMATIONAL_TYPES
where ALL_INFORMATIONAL_TYPES = SR, RR as defined in RFC3550 and XR payloads
as defined in RFC3611

(iv) Examples

 ....., SELECTIVE_SRTCP_UNENCRYPTED:ALL_INFORMATIONAL_TYPES

or

 ....., SELECTIVE_SRTCP_UNENCRYPTED:RR,SR,XR_VOIPMETRICS

Any comments on the general approach?

Regards

Alan

-----Original Message-----
From: Mark Baugher [mailto:[email-masked]]
Sent: Friday, December 10, 2004 6:39 PM
To: Alan Clark
Cc: [email-masked]; Colin Perkins
Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP

Alan,

Mark