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

["Ali C. Begen (abegen)" <[e-mail]>]

Hi Magnus,

We are addressing the other minor issues in the -08 version, which I
hope will be submitted before the deadline.

For the security-related part, see below:

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

Dan W. has suggested the following text. If you are happy with it, let
me know so that we can put it in the draft before Monday's deadline. I
am afraid we are not addressing all potential man-in-the-middle attacks.

-acbegen


To protect the RTCP messages from man-in-the-middle and replay attacks,
the RTP receivers and Retransmission Server SHOULD perform a DTLS-SRTP
handshake [I-D.ietf-avt-dtls-srtp] over the RTCP channel.  Because there
is no integrity-protected signaling channel between an RTP receiver and
the Retransmission Server, the Retransmission Server MUST maintain a
list of certificates owned by legitimate RTP receivers, or their
certificates MUST be signed by a trusted Certificate Authority. Once the
DTLS-SRTP security is established, non-SRTCP-protected messages received
from a particular RTP receiver are ignored by the Retransmission Server.
To reduce the impact of DTLS-SRTP overhead when communicating with
different feedback targets on the same Retransmission Server, it is
RECOMMENDED that RTP receivers and the Retransmission Server both
support TLS Session Resumption without Server-side State [RFC5077].