RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting
RFC 7002
Yes
No Objection
Note: This ballot was opened for revision 14 and is now closed.
(Gonzalo Camarillo; former steering group member) Yes
(Richard Barnes; former steering group member) Yes
(Spencer Dawkins; former steering group member) Yes
My apologies for updating this comment after looking at similar text in the -jt draft. You can ignore my previous comment on -discard. In this text, 4. SDP Signaling [RFC3611] defines the use of SDP (Session Description Protocol) [RFC4566] for signaling the use of XR blocks. However XR blocks MAY be used without prior signaling (see section 5 of RFC3611). This text is saying, to me: - You can signal the use of XR blocks in SDP, - or not - but if you do signal the use of XR blocks in SDP, here's how you would do that for discards Is there any guidance you can give about which choice an implementer should lean toward?
(Adrian Farrel; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
-
Block type (BT): 8 bits
A Discard Count Metric Report Block is identified by the constant
PDC.
[Note to RFC Editor: please replace PDC with the IANA provided
RTCP XR block type for this block.]
Figure 1 needs to be changed as well, not only the text.
-
Section 1.4
This metric is believed to be applicable to a large class of RTP
applications which use a jitter buffer.
Isn't a de-jitter buffer? See https://tools.ietf.org/html/rfc5481#section-3.2
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
Had the same thought Stephen did.
(Stephen Farrell; former steering group member) No Objection
Sam Hartman's secdir review [1] of xr-discard-rle-metrics raised a good question that's probably better asked here, or here as well. I'm not asking for any change in this or any specific xrblock document, but I would ask that the WG do consider this. Sam said: "Has the WG analyzed implications of providing feedback to an attacker on what specific SRTP packets are discarded? In the past we've run into trouble with security systems that were too verbose in error reporting. As an example, in certain public-key crypto constructions knowing whether a packet produced a decoding error vs a signature error after decryption can provide an attacker generating forged packets valuable information to attack the system. It's quite possible that SRTP doesn't have problems in this regard. I just want to confirm that the analysis has been done." I think that's a good question because knowing at what stage in a security protocol a message was barfed or getting timing statistics can expose information about how some crypto operation went wrong, and that can be exploited via statistical techniques with a sufficiently large number of messages. See for example the lucky-13 attacks against certain cryptographic modes in TLS [2] or perhaps the "original" of the species, the Bleichenbacher attack. [3] I suspect the best thing to do might be for the wg to try grab a security person and ponder this for a bit, if that's not already been done. I'm happy to try help find a co-ponderer if you want:-) Maybe we can ambush one in a hallway in Berlin. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04048.html [2] http://www.isg.rhul.ac.uk/tls/Lucky13.html [3] https://en.wikipedia.org/wiki/Adaptive_chosen-ciphertext_attack
(Stewart Bryant; former steering group member) No Objection
(Ted Lemon; former steering group member) No Objection