RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting
RFC 7002

Note: This ballot was opened for revision 14 and is now closed.

(Richard Barnes) Yes

(Gonzalo Camarillo) Yes

(Spencer Dawkins) Yes

Comment (2013-06-21 for -14)
No email
send info
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?

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

(Benoît Claise) No Objection

Comment (2013-06-24 for -14)
No email
send info
   Block type (BT): 8 bits

      A Discard Count Metric Report Block is identified by the constant

      [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

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2013-06-25 for -14)
No email
send info
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

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Comment (2013-06-26 for -14)
No email
send info
Had the same thought Stephen did.