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

Qin Wu <> Fri, 17 August 2012 02:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D303C21F8505; Thu, 16 Aug 2012 19:40:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.89
X-Spam-Status: No, score=-3.89 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BGSZUvp6fkX4; Thu, 16 Aug 2012 19:40:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 90F8721F84F8; Thu, 16 Aug 2012 19:40:03 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.5-GA FastPath) with ESMTP id AJM11471; Thu, 16 Aug 2012 18:40:03 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Aug 2012 19:38:54 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Aug 2012 19:38:52 -0700
Received: from w53375 ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 17 Aug 2012 10:38:37 +0800
Message-ID: <>
From: Qin Wu <>
To: Vincent Roca <>, The IESG <>, <>, <>
References: <>
Date: Fri, 17 Aug 2012 10:38:36 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_016D_01CD7C64.75451D50"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Originating-IP: []
X-CFilter-Loop: Reflected
Subject: Re: [secdir] Secdir review of draft-ietf-xrblock-rtcp-xr-pdv-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Aug 2012 02:40:05 -0000

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

----- Original Message ----- 
From: "Vincent Roca" <>
To: "The IESG" <>rg>; <>rg>; <>
Cc: "Vincent Roca" <>
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

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