Re: [AVT] draft-ietf-avt-rapid-acquisition-for-rtp-07: Minor issues

[Mark Baugher <[e-mail]>]

On 3/03/2010, at 1:20 PM, Ali C. Begen (abegen) wrote:

>> 
>> 31. Section 10.
>> The security mitigation for the authentication of the RTCP messages
>> between the RTP_RX and the RS is SRTP. However, the document fails to
>> indicate anything on how you would successfully configure the SRTP with
>> keying information. Can you provide some insight into how this would
>> work in RAMS scenario? I am more interested if you think there exist a
>> keying method that fits the trust model and scenarios? And if it does
> 
> I need some help on this. I am not really an SRTP guy.

There are a variety of ways this can be done including through a 
conditional access system, but this could be considered out of
scope for this document.  If it is in scope, I would start with a
standard multicast key management system like GSAKMP or GDOI and
define the signaling for it.  Since it's not clear that these systems
will even be used, however, this is probably a waste of the authors'
time.

> 
>> that it might be worth indicating that in the draft as a recommended
>> method. I know there will some that has different trust that can do it
>> differently. But some baseline is likely worth to lay down here.
> 
> Could be true or not. I can't really comment.


In the IPTV realm, there are a number of competing conditional access
systems that might be used for proprietary establishment of an SRTP
master key and master salt.  These are the most likely methods by
which a key might be installed.  And there are a number of standard
techniques mentioned above.


> 
>> 32. Section 10, page 43:
>>   In addition to the denial-of-service attacks, man-in-the-middle and
>>   replay attacks can also be harmful.  However, RAMS itself does not
>>   bring any new risks or threats other than the ones discussed in
>>   [I-D.ietf-avt-rtcpssm].
>> 
>> I think the document fails to describe the increased risk for other
>> attacks that isn't focused on blasting a lot of packets on to some
>> target. For example an on-path attacker can beyond preventing the RTP_RX
>> to get service, it may discretely change parameters to make the service
>> work less well.

Are you saying that there is no way to secure against this?

Mark


>> Due to that the RAMS extensions are more a control
>> protocol than a feedback protocol a different level of security threats
>> exist than what is primarily discussed in the RTCP SSM RFC.
> 
> A single RTCP packet carrying multiple NACK messages each reporting multiple missing packets will generate a lot more packets than a single RTCP packet carrying RAMS-R. No?