Re: [AVTCORE] Regardingdraft-ietf-avtcore-feedback-supression-rtp-15

Hi, Tom:
Thank for your proposed text. I agree that reorgnizing security section in the compact manner makes sense to me since RFC4585 security consideration also applies to this document.
I like to change the second paragraph in the security section your proposed a little bit.
Your proposed text
"
More specifically, spoofed or maliciously created TPLR feedback messages give rise to (undesired) feedback supression at RTCP receivers that accept such TPLR messages. Any packet loss detected by a receiver and where this RTP receiver also receives a TPLR message for the same missing packet(s), will negatively impact the application that relies on the (timely) RTP retransmission capabilities. 

"
New Text:
"
More specifically, spoofed or maliciously created TPLR feedback messages cause missing RTP packets to not be repaired in a timely fashion and add risk of (undesired) feedback supression at RTCP receivers that accept such TPLR messages. Any packet loss detected by a receiver and where this RTP receiver also receives a TPLR message for the same missing packet(s), will negatively impact the application that relies on the (timely) RTP retransmission capabilities. 
"
Hope this make sense.

Regards!
-Qin
----- Original Message ----- 
From: "Van Caenegem, Tom (Tom)" <tom.van_caenegem@alcatel-lucent.com>
To: "Qin Wu" <bill.wu@huawei.com>; "IETF AVTCore WG" <avt@ietf.org>
Sent: Monday, March 19, 2012 10:07 PM
Subject: RE: [AVTCORE] Regardingdraft-ietf-avtcore-feedback-supression-rtp-15

Qin,

I scanned through the security section, and my proposal would be to make it more compact. The whole section could be written as per below. Let me know what you think and whether I missed some important statements in the current "security" section.

Regards
Tom

Proposal:

"The security considerations documented in RFC 4585 are also applicable for the TPLR messages defined in this document.

More specifically, spoofed or maliciously created TPLR feedback messages give rise to (undesired) feedback supression at RTCP receivers that accept such TPLR messages. Any packet loss detected by a receiver and where this RTP receiver also receives a TPLR message for the same missing packet(s), will negatively impact the application that relies on the (timely) RTP retransmission capabilities. 

A solution to prevent such attack with maliciously sent TPLR messages, is to apply an authentication and integrity protection framework for the feedback messages.  This can be accomplished using the RTP profile that combines Secure RTP [RFC3711] and AVPF into SAVPF [RFC5124].

Note that intermediaries that are not visible at the RTP layer that
   wish to send the Third Party Loss Reports on behalf of the media
   source can only do so if they spoof the SSRC of the media source.
   This is difficult in case SRTP is in use.  If the intermediary is
   visible at the RTP layer, this is not an issue, provided the
   intermediary is part of the security context for the session."

-----Original Message-----
From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin Wu
Sent: vrijdag 16 maart 2012 8:44
To: IETF AVTCore WG
Subject: Re: [AVTCORE] Regarding draft-ietf-avtcore-feedback-supression-rtp-15

[sorry, if you receive multiple copies of this message]

Hi, Tom:
Sorry for late. Statement 3 is just an advice.
I agree unauthenticated feedback is not equivalent to suspicious feedback. RFC4585 allow ignore suspicious feedback but does not say we MUST ignore any unauthenticated feedback.
Your proposal looks good to me. How about revise the last paragraph, section 7 as:
"
   Also note that endpoints that receive a Third Party Loss Report would
   be well-advised to minimize the risk of false TPLR messages from
   a malicious source (which results in unneeded suppression feedback
   at the target victim receiver(s). Suggested measure is to authenticate 
   the sender of the Third Party Loss Report. Accepting Third Party Loss Report 
   from un-authenticated sender can lead to a denial of service attack, where 
   the endpoint accepts poor quality media that could be repaired.
"
Hope this addresses your comment.

Regards!
-Qin

>----- Original Message -----
>From: "Van Caenegem, Tom (Tom)" <tom.van_caenegem@alcatel-lucent.com>
>To: "Qin Wu" <bill.wu@huawei.com>; "Magnus Westerlund" 
><magnus.westerlund@ericsson.com>; "IETF AVTCore WG" <avt@ietf.org>
>Sent: Tuesday, March 13, 2012 9:59 PM
>Subject: RE: [AVTCORE] Regarding 
>draft-ietf-avtcore-feedback-supression-rtp-15

>Hi Qin,

>The issue on statement 2 : OK

>IMO your statement 3 ("Also note that endpoints that receive a Third 
>Party Loss Report would be well-advised to ignore it, unless the security is in place to authenticate the sender of the Third Party Loss Report") is an advice (/requirement?) that goes well beyond the recommendations in the security >section 8 of RFC 4585.

>The latter indicates that senders/receivers should behave conservatively when observing strange reporting behaviour. 

>The section also states that false RTCP packets can be avoided by authenticating RTCP messages.  

>(see below the exact phrasing that I copied for your convenience)

>In line with these RFC 4585 recommendation, you seem to interprete "unauthenticated" RTCP messages as an example of "strange" reporting behavior, which I do not think was the intention from RFC >4585.

>My proposal would be to just indicate in your security section that a solution to minimise the risk on false TPLR messages from a malicious source (which results in unneeded suppression feedback at the >target victim receiver(s), is to make use of an authentication framework (in line with RFC 4585). 

>Regards
>Tom

>RFC 4585, section 8 (Security):

>(..)

>Senders as well as receivers SHOULD behave conservatively when
>   observing strange reporting behavior.  For excessive failure
>   reporting from one or a few receivers, the sender MAY decide to no
>   longer consider this feedback when adapting its transmission behavior
>   for the media stream.  In any case, senders and receivers SHOULD
>   still adhere to the maximum RTCP bandwidth but make sure that they
>   are capable of transmitting at least regularly scheduled RTCP
>   packets.  Senders SHOULD carefully consider how to adjust their
>   transmission bandwidth when encountering strange reporting behavior;
>   they MUST NOT increase their transmission bandwidth even if ignoring
>   suspicious feedback.

>   Attacks using false RTCP packets (Regular as well as Early ones) can
>   be avoided by authenticating all RTCP messages.  This can be achieved
>   by using the AVPF profile together with the Secure RTP profile as
>   defined in [22]; as a prerequisite, an appropriate combination of
>   those two profiles (an "SAVPF") is being specified [21].  Note that,
>   when employing group authentication (as opposed to source
>   authentication), the aforementioned attacks may be carried out by
>   malicious or malfunctioning group members in possession of the right
>   keying material.
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt