Subject: [AVTCORE] Regarding draft-ietf-avtcore-feedback-supression-rtp-15

From: Magnus Westerlund <[email-masked]>
Date: Sat, 10 Mar 2012 11:38:01 +0100

Hi,

Qin Wu has been very diligent in addressing raised comments. I want to
state that I believe that this latest version do address the ADs
comments in a reasonable way. I do want to point out to the WG that the
authors choice of how to resolve one issue was to remove the whole
problematic sentence. I personally believe this is right, but if any in
the WG thinks it is problematic then speak up during the IETF last call.

   In other words, receivers MAY ignore RTCP TPLR messages, but SHOULD
   react to them unless they have good reason to still send	
   feedback messages despite having been requested to suppress them.

Cheers

Magnus Westerlund
AVTCORE WG chair

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Mon, 12 Mar 2012 10:42:50 +0100

Hi Magnus  (, Qin)

Version 15 makes the following three statements:

1)Section 3:

"When a receiver gets a RTCP TPLR message, it MUST follow the rules
for NACK suppression in RFC4585 [RFC4585]and refrain from sending a
feedback request (e.g., NACK or FIR) for the missing packets reported
in the message,which is dealt with in the same way as receiving NACK"

2)Section 3:

"A receiver may have sent a Feedback message according to the RTP/AVPF
scheduling algorithm of RFC4585 [RFC4585] before receiving a RTCP
TPLR message, but further feedback messages for those sequence
numbers SHOULD be suppressed after receiving the RTCP TPLR"

3)Section 7:

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

These statements are still not aligned with each other. 

1) -> indicates that a TPLR message always results in FB suppression (MUST), and aligned with RFC 4585

2) -> why does the case where a receiver sent a NACK before receiving a TPLR, represents an exception on the receiver behaviour defined in the 1st statement (SHOULD instead of MUST)

3) -> is effective a SHOULD for non-authenticated TPLR messages.

Magnus, from your statement below, I take it that you propose a receiver behaviour different from the one defined in RFC 4585 (so SHOULD suppress feedback instead of MUST suppress feedback in RFC 4585).

If you do this , it requires some explicit reasoning that explains this difference , and explicit indication that this behaviour is different from feedback suppression rule defined in RFC 4585.
Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: zaterdag 10 maart 2012 11:38
To: IETF AVTCore WG
Subject: [AVTCORE] Regarding draft-ietf-avtcore-feedback-supression-rtp-15

Hi,

Qin Wu has been very diligent in addressing raised comments. I want to state that I believe that this latest version do address the ADs comments in a reasonable way. I do want to point out to the WG that the authors choice of how to resolve one issue was to remove the whole problematic sentence. I personally believe this is right, but if any in the WG thinks it is problematic then speak up during the IETF last call.

Cheers

Magnus Westerlund
AVTCORE WG chair

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Qin Wu <[email-masked]>
Date: Tue, 13 Mar 2012 09:44:53 +0800

Hi, all:
>----- Original Message ----- 
>From: "Van Caenegem, Tom (Tom)" <[email-masked]>
>To: "Magnus Westerlund" <[email-masked]>; "IETF AVTCore WG" <[email-masked]>
>Sent: Monday, March 12, 2012 5:42 PM
>Subject: Re: [AVTCORE] Regarding draft-ietf-avtcore-feedback-supression-rtp-15

>[Qin]: I think statement 2) can use the "MUST" to get alignment with statement 1).

>3) -> is effective a SHOULD for non-authenticated TPLR messages.
 
[Qin]: As I clarified earlier to AD review, statement 3) emphasizes the different thing, i.e, how to prevent attacks using false RTCP packets from malicious group members.
This statement gets alignment with what RFC4585 said in the last paragraph of section 8:
"
   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.
"
So I don't think this statement 3) conflicts with statement 1) and 2). Also I must emphasize countermeasures we proposed here in the statement 3) 
should apply to any Feedback messages including NACK, TPLR.
Hope this clarifies.

>Magnus, from your statement below, I take it that you propose a receiver behaviour different from the one defined in RFC 4585 (so SHOULD suppress feedback instead of MUST suppress feedback in >RFC 4585).

>Qin Wu has been very diligent in addressing raised comments. I want to state that I believe that this latest version do address the ADs comments in a reasonable way. I do want to point out to the WG that >the authors choice of how to resolve one issue was to remove the whole problematic sentence. I personally believe this is right, but if any in the WG thinks it is problematic then speak up during the IETF >last call.

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 13 Mar 2012 14:59:43 +0100

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.

-----Original Message-----
From: Qin Wu [mailto:[email-masked]] 
Sent: dinsdag 13 maart 2012 2:45
To: Van Caenegem, Tom (Tom); Magnus Westerlund; IETF AVTCore WG
Subject: Re: [AVTCORE] Regarding draft-ietf-avtcore-feedback-supression-rtp-15

Hi, all:
>Subject: Re: [AVTCORE] Regarding 
>draft-ietf-avtcore-feedback-supression-rtp-15

>"When a receiver gets a RTCP TPLR message, it MUST follow the rules for 
>NACK suppression in RFC4585 [RFC4585]and refrain from sending a 

>scheduling algorithm of RFC4585 [RFC4585] before receiving a RTCP TPLR 
>message, but further feedback messages for those sequence numbers 
>SHOULD be suppressed after receiving the RTCP TPLR"

>2) -> why does the case where a receiver sent a NACK before receiving a 
>TPLR, represents an exception on the receiver behaviour defined in the 
>1st statement (SHOULD instead of MUST)

 
So I don't think this statement 3) conflicts with statement 1) and 2). Also I must emphasize countermeasures we proposed here in the statement 3) should apply to any Feedback messages including NACK, TPLR.
Hope this clarifies.

>Subject: [AVTCORE] Regarding 
>draft-ietf-avtcore-feedback-supression-rtp-15

---

From: Qin Wu <[email-masked]>
Date: Fri, 16 Mar 2012 15:44:27 +0800

[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

>To: "Qin Wu" <[email-masked]>; "Magnus Westerlund" <[email-masked]>; "IETF AVTCore WG" <[email-masked]>
>Sent: Tuesday, March 13, 2012 9:59 PM
>Subject: RE: [AVTCORE] Regarding draft-ietf-avtcore-feedback-supression-rtp-15

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

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

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Mon, 19 Mar 2012 15:07:38 +0100

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: [email-masked] [mailto:[email-masked]] 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

Hi, Tom:

Regards!
-Qin

>To: "Qin Wu" <[email-masked]>; "Magnus Westerlund" 
><[email-masked]>; "IETF AVTCore WG" <[email-masked]>
>Subject: RE: [AVTCORE] Regarding 

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

---

From: Qin Wu <[email-masked]>
Date: Tue, 20 Mar 2012 10:15:36 +0800

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)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "IETF AVTCore WG" <[email-masked]>
Sent: Monday, March 19, 2012 10:07 PM
Subject: RE: [AVTCORE] Regardingdraft-ietf-avtcore-feedback-supression-rtp-15

Qin,

Regards
Tom

Proposal:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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

Hi, Tom:

Regards!
-Qin

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 20 Mar 2012 10:16:04 +0100

Looks fine too!
Tom 

-----Original Message-----
From: Qin Wu [mailto:[email-masked]] 
Sent: dinsdag 20 maart 2012 3:16
To: Van Caenegem, Tom (Tom); IETF AVTCore WG
Subject: Re: [AVTCORE] Regardingdraft-ietf-avtcore-feedback-supression-rtp-15

Hi, Tom:

"
New Text:
"

Regards!
-Qin
----- Original Message -----
From: "Van Caenegem, Tom (Tom)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "IETF AVTCore WG" <[email-masked]>
Sent: Monday, March 19, 2012 10:07 PM
Subject: RE: [AVTCORE] Regardingdraft-ietf-avtcore-feedback-supression-rtp-15

Qin,

Regards
Tom

Proposal:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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

Hi, Tom:

Regards!
-Qin