Subject: [AVT] I-D ACTION:draft-ietf-avt-topologies-02.txt

From: [email-masked]
Date: Mon, 23 Oct 2006 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTP Topologies
	Author(s)	: M. Westerlund, S. Wenger
	Filename	: draft-ietf-avt-topologies-02.txt
	Pages		: 17
	Date		: 2006-10-23
	
This document disucsses multi-endpoint topologies commonly used in
   RTP based environments.  In particular, centralized topologies
   commonly employed in the video conferencing industry are mapped to
   the RTP terminology.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-topologies-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-avt-topologies-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-topologies-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Mark Baugher <[email-masked]>
Date: Mon, 23 Oct 2006 21:25:46 -0700

Magnus, Stephan,
   I gave this a first read and it's well-written and to the point  
IMHO.  I have a couple of comments off the top of my head.  Starting  
with Security Considerations,

>  Second, the number of security contexts needed (for example in
>    SRTP [RFC3711]) may vary between mixers and translators. A mixer
>    normally needs to represent only a single SSRC in any given
>    domain, and therefore needs to create only one SRTP security
>    context.  In contrast, a translator needs one context per
>    participant it translates toward in the opposite domain.

Couldn't Figure 6 have five crypto contexts installed in the mixer?   
I think you're saying that everyone but the mixer receives using the  
same crypto context.  The mixer additionally needs to receive the  
others' streams and each will have a crypto context.

There is a lot that needs to be defined that probably is outside of  
the scope of your document, but the security considerations section  
also says:
>  Including the mixer and translator in the security context allows
>    the entity if subverted or misbehaving to perform a number of very
>    serious attacks as it has full access. It can perform all the
>    attacks possible, see RFC 3550 and any applicable profiles, as if
>    the media session was not protected at all, while giving the
>    impression to the session participants that they are protected
>    against them.
>

"Security context" is vague but I think what you're saying here is  
that giving a device access to security keys adds a new risk, another  
potential point of vulnerability, to the session.  _How_ the mixer  
and translator are included in the security context can greatly  
affect the risk.  In other words, we know in security how to  
establish pairwise keys for a pair of endpoints, and we know how to  
do group keys for multiple endpoints, but I don't think there is a  
consensus for how to do key management for some of the figures in  
your document.

I had one more question come to mind when reading Section 3.5.   
Following Figure 5 it says:
> In the multicast domain, the mixer does not need to provide a
>    mixed view of the other domains and will commonly only forward the
>    media from B and D into the multicast network using B's and D's
>    SSRC.
>

I expect that mixing would be useful for a multicast network to give  
every participant the same output from the conference.  Are you  
assuming otherwise?

Mark

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 24 Oct 2006 15:14:04 +0200

Hi Mark,

Thanks for the review and I will do my best to respond to your questions 
and comments.

Mark Baugher skrev:
> Magnus, Stephan,
>   I gave this a first read and it's well-written and to the point IMHO.  I have a couple of comments off the top of my head.  Starting with Security Considerations, 
> 
> Couldn't Figure 6 have five crypto contexts installed in the mixer?  I think you're saying that everyone but the mixer receives using the same crypto context.  The mixer additionally needs to receive the others' streams and each will have a crypto context.

In the case depicted by figure 6, the mixer will have one SSRC and the 
A-D will have at least one respectively. However if we are looking at 
the link between A and the mixer, the traffic passing on this link there 
will be only two SSRCs, A's and the Mixer's. The SSRCs belonging to B, C 
and D will only occur in CSRC list and inside RTCP SDES packets. Thus 
from an SRTP perspective, A only needs two crypto contextes, one for its 
own traffic and one for the mixer. The same is true for each of the 
other participants that only receive a mixed view of the session. That 
is why I am saying that the mixer will have one SSRC (at least).

In regards to using the same crypto context for all the others, I don't 
think that is the truth. To avoid the two time padd issue, the mixer 
needs to use either different keys or different SSRC in the domains when 
using SRTP. The reason is that a mixer most likely will need to produce 
different media streams and mixes. Sending the transmitting entity a 
stream with themselves seems wrong in most applications. Thus senders 
and only receivers will at least have different streams. That is before 
even considering the need to adapt the media to the individual links.

I think I missed the word "additional" in the following sentence:
"... and therefore needs to create only one SRTP security context."

Where a mixer will need N crypto contexts in addition for N domains, a 
translator may be forced to have P*N crypto contexts where P is the 
number of participants in total.

> 
> There is a lot that needs to be defined that probably is outside of the scope of your document, but the security considerations section also says:
> 
> "Security context" is vague but I think what you're saying here is that giving a device access to security keys adds a new risk, another potential point of vulnerability, to the session.  _How_ the mixer and translator are included in the security context can greatly affect the risk.  In other words, we know in security how to establish pairwise keys for a pair of endpoints, and we know how to do group keys for multiple endpoints, but I don't think there is a consensus for how to do key management for some of the figures in your document.  

No, that is true. The security risks will depend on how you key. The 
main point is that a mixer or a translator may actually need to u

> 
> I had one more question come to mind when reading Section 3.5.  Following Figure 5 it says:
> 
> I expect that mixing would be useful for a multicast network to give every participant the same output from the conference.  Are you assuming otherwise?
> 

In this case you have deployed a mixer simply because B and D can't have 
the same view as A and C that are part of the multicast domain. There is 
no reason for the mixer to return a mixed stream to the multicast domain 
that contains all the participants, because any sender in the multicast 
domain has already received that traffic. In the same way it is 
unnecessary for the mixer to even mix B and D together unless there is a 
bandwidth issue, because the participants in the multicast part already 
are capable of handling the reception of multiple sources.

I think we should add the word additional to that sentence to clarify 
things. Are there anything else you would like to improve in this text?

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: Wed, 25 Oct 2006 10:32:11 -0700

hi Magnus,

On Oct 24, 2006, at 6:14 AM, Magnus Westerlund wrote:

> Hi Mark,
>
> Thanks for the review and I will do my best to respond to your  
> questions and comments.
>
> Mark Baugher skrev:
>> Magnus, Stephan,
>> IMHO.  I have a couple of comments off the top of my head.   
>> Starting with Security Considerations, 	 Second, the number of  
>> security contexts needed (for example in
>> Couldn't Figure 6 have five crypto contexts installed in the  
>> mixer?  I think you're saying that everyone but the mixer receives  
>> using the same crypto context.  The mixer additionally needs to  
>> receive the others' streams and each will have a crypto context.
>
> In the case depicted by figure 6, the mixer will have one SSRC and  
> the A-D will have at least one respectively. However if we are  
> looking at the link between A and the mixer, the traffic passing on  
> this link there will be only two SSRCs, A's and the Mixer's. The  
> SSRCs belonging to B, C and D will only occur in CSRC list and  
> inside RTCP SDES packets. Thus from an SRTP perspective, A only  
> needs two crypto contextes, one for its own traffic and one for the  
> mixer. The same is true for each of the other participants that  
> only receive a mixed view of the session. That is why I am saying  
> that the mixer will have one SSRC (at least).

I misread the text cited above, "A mixer normally needs to represent  
only a single SSRC per domain and therefore needs to create only one  
SRTP security context".  I think we could put it this way, "A mixer  
normally needs to represent only a single SSRC per domain and  
therefore needs to create only one SRTP crypto context per domain"  
where I added 'per domain' and changed 'security' to 'crypto'.
>
> In regards to using the same crypto context for all the others, I  
> don't think that is the truth. To avoid the two time padd issue,  
> the mixer needs to use either different keys or different SSRC in  
> the domains when using SRTP. The reason is that a mixer most likely  
> will need to produce different media streams and mixes. Sending the  
> transmitting entity a stream with themselves seems wrong in most  
> applications. Thus senders and only receivers will at least have  
> different streams. That is before even considering the need to  
> adapt the media to the individual links.
>
> Where a mixer will need N crypto contexts in addition for N  
> domains, a translator may be forced to have P*N crypto contexts  
> where P is the number of participants in total.

Ok. It seems clearer to write "may be forced to have" as "might need  
up to"
>
>> There is a lot that needs to be defined that probably is outside  
>> of the scope of your document, but the security considerations  
>> section also says:
>> that giving a device access to security keys adds a new risk,  
>> another potential point of vulnerability, to the session.  _How_  
>> the mixer and translator are included in the security context can  
>> greatly affect the risk.  In other words, we know in security how  
>> to establish pairwise keys for a pair of endpoints, and we know  
>> how to do group keys for multiple endpoints, but I don't think  
>> there is a consensus for how to do key management for some of the  
>> figures in your document.
>
> No, that is true. The security risks will depend on how you key.  
> The main point is that a mixer or a translator may actually need to u

I miss your point here, but I agree that the "security risks will  
depend on how you key", and I would add that there is no consensus on  
how to key some of the figures.  That's out-of-scope for this I-D but  
needs to be done and probably should be mentioned.

>> I expect that mixing would be useful for a multicast network to  
>> give every participant the same output from the conference.  Are  
>> you assuming otherwise?
>
> In this case you have deployed a mixer simply because B and D can't  
> have the same view as A and C that are part of the multicast  
> domain. There is no reason for the mixer to return a mixed stream  
> to the multicast domain that contains all the participants, because  
> any sender in the multicast domain has already received that  
> traffic. In the same way it is unnecessary for the mixer to even  
> mix B and D together unless there is a bandwidth issue, because the  
> participants in the multicast part already are capable of handling  
> the reception of multiple sources.

I recall that there were advantages to doing centralized mixing and  
then distribute the mixed stream over a multicast channel instead of  
every receiver doing its own mixing.  The advantage is that the  
device imposes an ordering so the receivers all hear the same thing  
at about the same time.  Not the case?
>
>
> I think we should add the word additional to that sentence to  
> clarify things. Are there anything else you would like to improve  
> in this text?

I mentioned those inline, above.

Cheers, Mark

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 27 Oct 2006 10:19:08 +0200

Mark Baugher skrev:
>>> with Security Considerations,      Second, the number of security 
>>> contexts needed (for example in
>> the link between A and the mixer, the traffic passing on this link 
>> there will be only two SSRCs, A's and the Mixer's. The SSRCs belonging 
>> to B, C and D will only occur in CSRC list and inside RTCP SDES 
>> packets. Thus from an SRTP perspective, A only needs two crypto 
>> contextes, one for its own traffic and one for the mixer. The same is 
>> true for each of the other participants that only receive a mixed view 
>> of the session. That is why I am saying that the mixer will have one 
>> SSRC (at least).
> 
> normally needs to represent only a single SSRC per domain and therefore 
> needs to create only one SRTP crypto context per domain" where I added 
> 'per domain' and changed 'security' to 'crypto'.

Your sentence seems like a improvement. However maybe I should clarify 
what I was considering was the implication on the number of session keys 
and their related parameters. If I understand crypto context in SRTP it 
normally means the master key and its parameters. Thus the number of 
crypto contexts will depend on the keying model, a shared master key or 
one master key per SSRC. But it might be easiest to not dig to deep into 
this within the document. SRTP is a recommended security mechanism but 
not the only one that may be used.

>> don't think that is the truth. To avoid the two time padd issue, the 
>> mixer needs to use either different keys or different SSRC in the 
>> domains when using SRTP. The reason is that a mixer most likely will 
>> need to produce different media streams and mixes. Sending the 
>> different streams. That is before even considering the need to adapt 
>> the media to the individual links.
>>
> Ok. It seems clearer to write "may be forced to have" as "might need up to"

Okay, we will consider this.

> I miss your point here, but I agree that the "security risks will depend 
> on how you key", and I would add that there is no consensus on how to 
> key some of the figures.  That's out-of-scope for this I-D but needs to 
> be done and probably should be mentioned.

I agree with your statement that we don't necessarily know how to key 
all these. However adding a statement that the security properties will 
depend on the keying I think is safe. I wouldn't say that there is no 
consensus on how to key, but stating that it might be done in different 
ways and thus getting different properties would be safe. I think we 
need to separate the issues between having an IETF agreed way of doing 
things and if any solution exist at all. RTP can be secured in a number 
of ways and the application will be highly influencing your choices both 
for the transport protection and how you do your keying.

>> have the same view as A and C that are part of the multicast domain. 
>> There is no reason for the mixer to return a mixed stream to the 
>> multicast domain that contains all the participants, because any 
>> sender in the multicast domain has already received that traffic. In 
>> the same way it is unnecessary for the mixer to even mix B and D 
>> together unless there is a bandwidth issue, because the participants 
>> in the multicast part already are capable of handling the reception of 
>> multiple sources.
> 
> I recall that there were advantages to doing centralized mixing and then 
> distribute the mixed stream over a multicast channel instead of every 
> receiver doing its own mixing.  The advantage is that the device imposes 
> an ordering so the receivers all hear the same thing at about the same 
> time.  Not the case?
>>

I would say that this is highly application dependent and why you deploy 
the mixer. I think the usage of centralized mixing has its usage for 
certain applications, in other the mixer is not at all centralized and 
is instead something that enables a few users to participate in a 
session they otherwise couldn't, i.e. more gateway then a conference focus.

Cheers

Magnus Westerlund

---

From: Mark Baugher <[email-masked]>
Date: Fri, 27 Oct 2006 07:20:09 -0700

Magnus,

On Oct 27, 2006, at 1:19 AM, Magnus Westerlund wrote:

>>>>   I gave this a first read and it's well-written and to the  
>>>> point IMHO.  I have a couple of comments off the top of my  
>>>> head.  Starting with Security Considerations,      Second, the  
>>>> number of security contexts needed (for example in
>>>> mixer?  I think you're saying that everyone but the mixer  
>>>> receives using the same crypto context.  The mixer additionally  
>>>> needs to receive the others' streams and each will have a crypto  
>>>> context.
>>>
>>> In the case depicted by figure 6, the mixer will have one SSRC  
>>> and the A-D will have at least one respectively. However if we  
>>> are looking at the link between A and the mixer, the traffic  
>>> passing on this link there will be only two SSRCs, A's and the  
>>> Mixer's. The SSRCs belonging to B, C and D will only occur in  
>>> CSRC list and inside RTCP SDES packets. Thus from an SRTP  
>>> perspective, A only needs two crypto contextes, one for its own  
>>> traffic and one for the mixer. The same is true for each of the  
>>> other participants that only receive a mixed view of the session.  
>>> That is why I am saying that the mixer will have one SSRC (at  
>>> least).
>> I misread the text cited above, "A mixer normally needs to  
>> represent only a single SSRC per domain and therefore needs to  
>> create only one SRTP security context".  I think we could put it  
>> this way, "A mixer normally needs to represent only a single SSRC  
>> per domain and therefore needs to create only one SRTP crypto  
>> context per domain" where I added 'per domain' and changed  
>> 'security' to 'crypto'.
>
> Your sentence seems like a improvement. However maybe I should  
> clarify what I was considering was the implication on the number of  
> session keys and their related parameters. If I understand crypto  
> context in SRTP it normally means the master key and its  
> parameters. Thus the number of crypto contexts will depend on the  
> keying model, a shared master key or one master key per SSRC. But  
> it might be easiest to not dig to deep into this within the  
> document. SRTP is a recommended security mechanism but not the only  
> one that may be used.

Yes, there can be one or multiple SRTP crypto contexts for an SRTP  
session depending on whether you share the key between senders or  
not.  It's better to count the number of RTP sessions rather than  
SRTP crypto contexts.
...
>>> In this case you have deployed a mixer simply because B and D  
>>> can't have the same view as A and C that are part of the  
>>> multicast domain. There is no reason for the mixer to return a  
>>> mixed stream to the multicast domain that contains all the  
>>> participants, because any sender in the multicast domain has  
>>> already received that traffic. In the same way it is unnecessary  
>>> for the mixer to even mix B and D together unless there is a  
>>> bandwidth issue, because the participants in the multicast part  
>>> already are capable of handling the reception of multiple sources.
>> I recall that there were advantages to doing centralized mixing  
>> and then distribute the mixed stream over a multicast channel  
>> instead of every receiver doing its own mixing.  The advantage is  
>> that the device imposes an ordering so the receivers all hear the  
>> same thing at about the same time.  Not the case?
>>>
>
> I would say that this is highly application dependent and why you  
> deploy the mixer. I think the usage of centralized mixing has its  
> usage for certain applications, in other the mixer is not at all  
> centralized and is instead something that enables a few users to  
> participate in a session they otherwise couldn't, i.e. more gateway  
> then a conference focus.

Yes, the mixing can be done on the endsystem and is commonly done in  
a middle box.

Cheers, Mark

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 27 Oct 2006 16:32:10 +0200

Mark Baugher skrev:
>>>> mixer. The same is true for each of the other participants that only 
>>>> receive a mixed view of the session. That is why I am saying that 
>>>> the mixer will have one SSRC (at least).
>> what I was considering was the implication on the number of session 
>> keys and their related parameters. If I understand crypto context in 
>> SRTP it normally means the master key and its parameters. Thus the 
>> number of crypto contexts will depend on the keying model, a shared 
>> master key or one master key per SSRC. But it might be easiest to not 
>> dig to deep into this within the document. SRTP is a recommended 
>> security mechanism but not the only one that may be used.
> 
> session depending on whether you share the key between senders or not.  
> It's better to count the number of RTP sessions rather than SRTP crypto 
> contexts.

Well, my intention was a comparison between mixers and translators. Here 
the comparision using with RTP sessions will be very misleading. A Mixer 
will have one RTP session for each domain, however there SSRC/CSRC 
spaces will be joint. A Translator will only have one session that is 
joint between the domains. When one start looking at the crypto context 
a mixer only needs to keep track of the already existing crypto contexts 
for a domain and possibly one for itself (assuming per sender keys). 
However a translator that does anything to the SRTP protected parts of 
the packet, will need to re-encrypt the packets. To avoid two-time pads 
it will need to use a different key than what was used by the  sender of 
the packet in the originating domain. Thus a translator will in worst 
case end up with N*P crypto contextes where N is the total number of 
participants in the joint session, and P the number of domains it 
handles. So from an SRTP perspective a translator may actually end up 
with much more crypto work than a mixer would.

Cheers

Magnus Westerlund

---

From: Mark Baugher <[email-masked]>
Date: Tue, 31 Oct 2006 17:43:58 -0800

On Oct 27, 2006, at 7:32 AM, Magnus Westerlund wrote:

>>>>>> receives using the same crypto context.  The mixer  
>>>>>> additionally needs to receive the others' streams and each  
>>>>>> will have a crypto context.
>>>>>
>>>>> other participants that only receive a mixed view of the  
>>>>> session. That is why I am saying that the mixer will have one  
>>>>> SSRC (at least).
>>>> this way, "A mixer normally needs to represent only a single  
>>>> SSRC per domain and therefore needs to create only one SRTP  
>>>> crypto context per domain" where I added 'per domain' and  
>>>> changed 'security' to 'crypto'.
>>>
>>> clarify what I was considering was the implication on the number  
>>> of session keys and their related parameters. If I understand  
>>> crypto context in SRTP it normally means the master key and its  
>>> document. SRTP is a recommended security mechanism but not the  
>>> only one that may be used.
> Well, my intention was a comparison between mixers and translators.  
> Here the comparision using with RTP sessions will be very  
> misleading. A Mixer will have one RTP session for each domain,  
> however there SSRC/CSRC spaces will be joint.

Is this a requirement like a "shall", or is it something that's  
obviously needed for the mixer to function properly?  Pardon me if  
I'm missing something that I should know, but I see this as one way  
to do it - and I am not aware of any standard way.  Why wouldn't the  
mixer, for example, create entirely a new SSRC space for each domain  
and map the SSRCs from the other domain into it?  In fact, it's  
permissible (though not recommended) for the mixer to not even send  
CSRCs, right?

> A Translator will only have one session that is joint between the  
> domains.
> When one start looking at the crypto context a mixer only needs to  
> keep track of the already existing crypto contexts for a domain and  
> possibly one for itself (assuming per sender keys). However a  
> translator that does anything to the SRTP protected parts of the  
> packet, will need to re-encrypt the packets. To avoid two-time pads  
> it will need to use a different key than what was used by the   
> sender of the packet in the originating domain.

Right.  I'd spell it out: "In the translator case, RFC 3550 specifies  
that the SSRC is kept 'intact' and if the translator does not have a  
different key than the source it is translating, the source and  
translator will encrypt two different plaintexts (the original  
payload and the translated payload) with the same keystream".  But  
does it need two crypto contexts when it translates and forwards to  
two hosts?  Referring to Fig. 3 and the flows from B and D to A and  
C, there could be one key that's shared on the multicast network and  
thus one crypto context.  That is, why couldn't the translator have  
it's own key for each domain rather than one key for each participant  
in each domain?

> Thus a translator will in worst case end up with N*P crypto  
> contextes where N is the total number of participants in the joint  
> session, and P the number of domains it handles. So from an SRTP  
> perspective a translator may actually end up with much more crypto  
> work than a mixer would.

I know I originally agreed with this formulation, but now I'm  
confused by it.

Mark