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

From: Vincent Roca <[email-masked]>
Date: Wed, 1 Aug 2012 23:31:44 +0200

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

---

From: Tina TSOU <[email-masked]>
Date: Fri, 3 Aug 2012 17:41:20 +0000

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.

Draft-ietf-avtcore-monarch-17 as a whole provides useful advice. 
There are a number of editorial nits that will be provided to the authors in a separate E-mail.

Unfortunately, the Security Considerations section fails to appreciate both the more nuanced view and the contradiction exhibited by the same section of RFC 3611, to which it refers. On the one hand, the measurements reported in XR blocks could be sensitive and one might wish to provide them with confidentiality. On the other hand, intermediate parties may have legitimate reasons to view the measurements, so that end-to-end encryption is not always desirable.

It would be helpful for this document to discuss the trust models that might be encountered in operation, and how confidentiality and authorized usage could co-exist within these models. Of course, it may be legitimate to conclude that under some circumstances such coexistence may be impossible, and local policy may therefore be either to suppress the measurements or accept the consequences of their disclosure.

Tina

---

From: Qin Wu <[email-masked]>
Date: Fri, 17 Aug 2012 10:38:36 +0800

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

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

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

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