Last Call Review of draft-ietf-xrblock-rtcp-xr-pdv-
review-ietf-xrblock-rtcp-xr-pdv-secdir-lc-roca-2012-08-10-00

Request Review of draft-ietf-xrblock-rtcp-xr-pdv
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-07-23
Requested 2012-07-13
Authors Alan Clark, Qin Wu
Draft last updated 2012-08-10
Completed reviews Genart Last Call review of -?? by Alexey Melnikov
Secdir Last Call review of -?? by Vincent Roca
Assignment Reviewer Vincent Roca
State Completed
Review review-ietf-xrblock-rtcp-xr-pdv-secdir-lc-roca-2012-08-10
Review result Ready with Issues
Review completed: 2012-08-10

Review
review-ietf-xrblock-rtcp-xr-pdv-secdir-lc-roca-2012-08-10

Hello,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.


The authors explain this document introduces no new security
considerations beyond those described in [RFC3611].
I agree there is no privacy risk, but a question I'd like the authors
to discuss a little bit concerns the case where an attacker sends
forged RTCP XR reports, with erroneous Packet Delay Variation values
(e.g. the attacker may pretend the PDV are much smaller than the reality).
I assume this may result in back playout buffer setups, isn't it? This
looks like a cool way to create a DoS.

Is the PDV used for other purposes, like imminent congestion detection?
In that case there could be other incentives for an attacker to fake XR
packets, with possible additional damages. 

I think a paragraph on these risks should be added.

Cheers,

   Vincent