Re: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13

["Van Caenegem, Tom (Tom)" <[e-mail]>]

Hi Qin,

"I agree with your suggestion to the security section, that is to say the suppression rule is only 
applied when the packet are integrity protected and authenticated. I can put some text to make this clear."

I think you will have to explain/rationalise why receivers MUST  suppress feedback when receiving (unauthenticated) NACK packets (RFC 4585), whereas for 3rd party loss messages, feedback suppression is only required when the sender can be authenticated.
Tom



 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Qin Wu
Sent: vrijdag 2 maart 2012 5:53
To: Robert Sparks; [e-mail]; [e-mail]; [e-mail]; Gonzalo Camarillo
Subject: Re: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13

Hi, Robert:
Thank for your valuable review, please see my replies inline below.

Regards!
-Qin
----- Original Message -----
From: "Robert Sparks" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>; "Gonzalo Camarillo" <[e-mail]>
Sent: Friday, March 02, 2012 6:27 AM
Subject: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13


> Summary: There are some clarifications needed (and some questions to 
> discuss) before forwarding this to IETF LC.
> 
> 1) Section 3, paragraph 3, says a receiver MUST follow the rules for 
> NACK suppression on receipt of a third partly loss report. Section 4 
> says receivers MAY ignore third party lost reports, and then confusingly 
> says the SHOULD not ignore them. The security considerations section 
> says that receivers would be "well advised to ignore" (effectively 
> SHOULD ignore) third party reports unless they are authenticated. This 
> needs to be reconciled.
> 
> Are you trying to say the following?
> 
>    *) MUST follow the suppression rules if packets are authenticated
>    *) SHOULD NOT follow the suppression rules if the packets are not 
> authenticated
> 
> Or something else? Either way, please make the document internally 
> consistent.

[Qin]: The reason to use "MUST" is it was suggested by the reviewer since RFC4585 that uses "MUST" 
in the context of client feedback suppression. But I agree this description does not clarify in what 
circumstance to apply MUST. To be consistent with what we described in the security section, 
I agree with your suggestion to the security section, that is to say the suppression rule is only 
applied when the packet are integrity protected and authenticated. I can put some text to make this clear.

> 
> 2) Why aren't RFC3711 and RFC5124 normative references? They're the only 
> offered tools for authenticating these messages in the document. Even if 
> other mechanisms might exist, there needs to be discussion somewhere of 
> what's required of this authentication, and the security consideration 
> sections of those documents would suffice.

[Qin] Agree, for discussion on where the authentication is required, 

I like to follow your suggestion, please see above clarification. Also

 I will move RFC3711 and RFC5124 to normative references.

Does this address your comment?

> 
> 3) The first part of the IANA considerations section is not clear. Is 
> this trying to create a new registry with two initial values, or add two 
> values to an existing registry. If it's creating a new one, please 
> provide a registry name, and suggest where it should appear.



[Qin]: I think it is latter. To make it clear, I propose the following change:

OLD Text:

"

   For use with "nack" [RFC4585], a joint sub-registry has been set up

   that registers the following two values:

  The value registration for the attribute value "nack":

"
New Text:

"

For use with "nack" [RFC4585], this document instructs IANA to add two values in

"ack" and "nack" Attribute Values registry:

The value registration for the attribute value "nack":

"



> 4) The security considerations section speaks about attacks based on 
> spurious reports, but doesn't really discuss more directed attacks. In 
> particular, if a receiver accepts unauthenticated feedback suppression 
> messages, an attacker could cause packetloss disrupting an important 
> part of a session, preemptively sending feedback suppression. An 
> attacker that is also a receiver has enough information to suppress 
> _all_ feedback from any other listeners that don't unauthenticated 
> packets. Please make it clearer that these risks exist.

[Qin]: Okay. Based on your above suggestion, I like to propose the following change to the section 7,3rd paragraph:

OLD text:

"

Sending the spurious Third Party Loss Report (e.g., the Third Party

   Loss Report with the wrong sequence number of lost packet) that

   causes missing RTP packets to not be repaired in a timely fashion.

"

New Text:

"

Sending the spurious Third Party Loss Report packet (e.g., the Third Party

   Loss Report with the wrong sequence number of lost packet) that

   causes missing RTP packets to not be repaired in a timely fashion. 

If a receiver accepts such unauthenticated packet, 

an attacker could cause packet loss disrupting an important 
part of a session, preemptively sending feedback suppression. An 
attacker that is also a receiver has enough information to suppress 
all the feedbacks from any other listeners that don't accept unauthenticated 
packets.

"

Does this address your comment?


> 5) At the end of section 3, the document says messages SHOULD be 
> suppressed "for a period of time". Can that be made more precise?

[Qin]: Sorry, I forgot to clear that nits in the previous version. Since we follow

 the feedback suppression rule we defined in RFC4585, I think the receivers 

should suppress the further feedback for the same packet loss. Therefore I like

 to remove "for a period of time".


> Editorial suggestions:
> 
> Please expand acronyms on first use (There are a _lot_ of acronyms, many 
> of which need references to where they are defined. Consider adding a 
> glossary so you can get that out of the way without interrupting the 
> flow of the text).

[Qin]: Okay.

> The protocol definition part of this document (section 4) is a bit of a 
> puzzle for a new reader. It would help to guide the reader through the 
> definition more directly. Here's a suggested modification - feel free to 
> ignore it:
> 
> Before section 4.1 say "The following two sections each define a third 
> party loss report message. Both messages are feedback messages as 
> defined in section 6.1 of RFC4585, and use the header format defined 
> there. Each section defines how to populate the PT, FMT, length, SSRC or 
> packet sender, SSRC of media source, and FCI fields in that header."
> 
> That will make it more obvious to the reader that they need to go look 
> at the referenced section in 4585 right away, and makes it possible to 
> simplify the text in 4.1 and 4.2. 4.1 can state clearly and early that 
> it is defining the TLLEI, etc.

[Qin]: Looks good to me.


> Whether you choose to act on this suggestion or not, please change the 
> TBDs to TBD1 and TBD2, and say "length field in the" instead of "length 
> of" when talking about setting the length field in each message.

[Qin]: Okay.


> Nits sent directly to editors.

 [Qin]: Thanks.
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Core Maintenance
[e-mail]
https://www.ietf.org/mailman/listinfo/avt