Re: [secdir] Secdir review of draft-ietf-xrblock-rtcp-xr-pdv-03

[Qin Wu <[e-mail]>]

One more point to add, you are correct about forged PDV values, but this can be solved by authentication using SRTP.

Regards!
-Qin
  ----- Original Message ----- 
  From: Qin Wu 
  To: Vincent Roca ; The IESG ; [e-mail] ; [e-mail] 
  Cc: Vincent Roca 
  Sent: Friday, August 17, 2012 10:38 AM
  Subject: Re: Secdir review of draft-ietf-xrblock-rtcp-xr-pdv-03


  Hi,Vincent:
  Thank for your review, please see my comments inline below.

  Regards!
  -Qin
  ----- Original Message ----- 
  From: "Vincent Roca" <[e-mail]>
  To: "The IESG" <[e-mail]>; <[e-mail]>; <[e-mail]>
  Cc: "Vincent Roca" <[e-mail]>
  Sent: Thursday, August 02, 2012 5:31 AM
  Subject: Secdir review of draft-ietf-xrblock-rtcp-xr-pdv-03


  > 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.

  [Qin]: In security consideration section in RFC3611, it said:
  "
  The security considerations that apply to RTCP reports [RFC3550] also apply
   to XR reports. 
  "
  In Security consideration section in RFC3550, it said:
  "
     RTP suffers from the same security liabilities as the underlying
     protocols.  For example, an impostor can fake source or destination
     network addresses, or change the header or payload.  Within RTCP, the
     CNAME and NAME information may be used to impersonate another
     participant.  In addition, RTP may be sent via IP multicast, which
     provides no direct means for a sender to know all the receivers of
     the data sent and therefore no measure of privacy.  Rightly or not,
     users may be more sensitive to privacy concerns with audio and video
     communication than they have been with more traditional forms of
     network communication [33].  Therefore, the use of security
     mechanisms with RTP is important.  These mechanisms are 
     discussed in  Section 9.

  "
  That is to say, your concerns has already been taken in accounted in the security consideration section in RFC3550.

  Furthermore, In section 9 of RFC3550, it said:
  "
     Lower layer protocols may eventually provide all the security
     services that may be desired for applications of RTP, including
     authentication, integrity, and confidentiality.  These services have
     been specified for IP in [27].  Since the initial audio and video
     applications using RTP needed a confidentiality service before such
     services were available for the IP layer, the confidentiality service
     described in the next section was defined for use with RTP and RTCP.
     That description is included here to codify existing practice.  New
     applications of RTP MAY implement this RTP-specific confidentiality
     service for backward compatibility, and/or they MAY implement
     alternative security services.  The overhead on the RTP protocol for
     this confidentiality service is low, so the penalty will be minimal
     if this service is obsoleted by other services in the future.

     Alternatively, other services, other implementations of services and
     other algorithms may be defined for RTP in the future.  In
     particular, an RTP profile called Secure Real-time Transport Protocol
     (SRTP) [28] is being developed to provide confidentiality of the RTP
     payload while leaving the RTP header in the clear so that link-level
     header compression algorithms can still operate.  It is expected that
     SRTP will be the correct choice for many applications.  SRTP is based
     on the Advanced Encryption Standard (AES) and provides stronger
     security than the service described here.  No claim is made that the
     methods presented here are appropriate for a particular security
     need.  A profile may specify which services and algorithms should be
     offered by applications, and may provide guidance as to their
     appropriate use.

     Key distribution and certificates are outside the scope of this
     document.


  "
  Does the security consideration section described in RFC3550 address your concern?


  > 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. 

  [Qin]:The PDV reveals the variations in latency caused by congestion, route changes, queuing, etc.
  That is to say, you can not simply using PDV reporting to detect congestion. Please correct me if 
  I am wrong.

  > I think a paragraph on these risks should be added.
  > 
  > Cheers,
  > 
  >   Vincent