RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting
draft-ietf-xrblock-rtcp-xr-discard-15

-
   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

Had the same thought Stephen did.

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