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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 01 Nov 2006 10:51:10 +0100

Mark Baugher skrev:
> 
> On Oct 27, 2006, at 7:32 AM, Magnus Westerlund wrote:
>>
>> 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?

The case you are talking about is the topology discussed in section 3.6, 
Point to multipoint using RTCP-terminating MCU. Here there is a 
discussion on why this mostly work but is not the best idea.

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

Well, depending on how you key, you can either have a group key or not 
in each domain. However independently of how you key there will be a 
need for the implementation to have some context about each SSRC present 
in the session. Even if that strictly isn't crypto context, it is state 
that needs to be kept. This is however not the important issues. The 
important issue is the risk of reusing a key stream.

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

I think the best solution is to drop this discussion about how much 
state is created and focus on the real issue that hurt security.

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]

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

---

From: Mark Baugher <[email-masked]>
Date: Wed, 1 Nov 2006 07:33:58 -0800

On Nov 1, 2006, at 1:51 AM, Magnus Westerlund wrote:

>>> 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.
>> 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?
>
> The case you are talking about is the topology discussed in section  
> 3.6, Point to multipoint using RTCP-terminating MCU. Here there is  
> a discussion on why this mostly work but is not the best idea.

Yes, I see that now.

>>> 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?
>
> Well, depending on how you key, you can either have a group key or  
> not in each domain. However independently of how you key there will  
> be a need for the implementation to have some context about each  
> SSRC present in the session. Even if that strictly isn't crypto  
> context, it is state that needs to be kept. This is however not the  
> important issues. The important issue is the risk of reusing a key  
> stream.

I understand your point, which is that the translator must have its  
own key for each domain to which it sends.  In a multicast domain,  
there can be one group key shared by all senders, and the inclusion  
of unique SSRCs make each sender's keystream unique.  Alternatively,  
each sender can have its own group key that is shared by all  
receivers of that sender's packets, and it does not matter if there  
is an SSRC collision.

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

Yes, sources of packets need to have their own unique SSRC or there  
own unique key.

Mark