Re: [AVT] SRTP with layered encoding

[Marc Petit-Huguenin <[e-mail]>]

Hi David,

David McGrew wrote:
> Hi Marc,
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Marc
>> Petit-Huguenin
>> Sent: Monday, October 19, 2009 4:05 PM
>> To: [e-mail]
>> Subject: [AVT] SRTP with layered encoding
>>
>> I was not able to find guidelines on how to use SRTP with multicast
>> layered
>> encoding.  As all the layers share the same SSRC, the same master key
>> cannot
>> be shared between them.
> 
> right.
> 
>>
>> Using the same master key for all the layers would be great though, so
>> I was
>> thinking that a way to do this would be to redefine the label byte so
>> the 5
>> first bits are used for the layer number (from 0 to 31).
> 
> That seems like a reasonable use of the label byte.
> 
> The tricky part here is that the receiver would need to know the
> correspondence between the layer number and the RTP session.   This
> would need to be communicated via signaling, presumably, and then
> stored/used by all of the session participants.

If the basic way (RFC 4566) of allocating layers is used then an implicit
mapping can be used, i.e. with m= lines like this:

c=IN IP4 224.2.1.1/127/2
m=video 49170/2 RTP/AVP 31

then the first layer is assigned to label 0b00000xxx and the second layer to
0b00001xxx.

AFAIK RFC 5583 uses a different m= line for each layer, so the layers will have
a different SSRC.

> 
>>
>> Any thoughts on this?  Should I write an I-D?
> 
> How much savings will this key-sharing method bring?  Each of the RTP
> sessions will have some amount of state associated with it.  Is the
> savings of not storing a key or two per session really that valuable?

I think that this is more valuable when SRTP is used with EKT.  Without sharing,
there will be EKT packets on each RTCP stream associated to each layer.  With
sharing, only the base layer will have to carry the EKT extension.  This fits
nicely with how the layers works in RFC 3550, i.e. the BYE packets and non-CNAME
SDES items are also sent only on the RTCP stream associated with the base layer.

On the other hand, that seems a lot of work for something that was rarely
implemented, so an alternative solution is simply to deprecate section 8.3 in
RFC 3550, as proposed by Colin Perkins.

An interesting note that neither draft-ietf-avt-rtp-rfc3984bis or
draft-ietf-avt-rtp-g718, two payload formats that explicitly talk about layers,
have text in their Security Considerations section talking about this problem.

-- 
Marc Petit-Huguenin
Personal email: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org