[secdir] Review of draft-ietf-avt-rtp-toffset-07

Shawn M Emery <Shawn.Emery@Sun.COM> Wed, 08 October 2008 08:03 UTC

Return-Path: <secdir-bounces@ietf.org>
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C198A28C175; Wed, 8 Oct 2008 01:03:48 -0700 (PDT)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E48E3A6BCB for <secdir@core3.amsl.com>; Wed, 8 Oct 2008 01:03:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.322
X-Spam-Level:
X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pz85c85Nctjv for <secdir@core3.amsl.com>; Wed, 8 Oct 2008 01:03:43 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id A42733A68A9 for <secdir@ietf.org>; Wed, 8 Oct 2008 01:03:43 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m98843Tb003044 for <secdir@ietf.org>; Wed, 8 Oct 2008 04:04:03 -0400
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m9883rP6003032 for <secdir@PCH.mit.edu>; Wed, 8 Oct 2008 04:03:53 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9883jHV003920 for <secdir@mit.edu>; Wed, 8 Oct 2008 04:03:46 -0400 (EDT)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by mit.edu (Spam Firewall) with ESMTP id 58AF31121DFF for <secdir@mit.edu>; Wed, 8 Oct 2008 04:03:24 -0400 (EDT)
Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9883NB5012111 for <secdir@mit.edu>; Wed, 8 Oct 2008 08:03:23 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8E00F01UDHSI00@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM) for secdir@mit.edu; Wed, 08 Oct 2008 02:03:23 -0600 (MDT)
Received: from [10.0.0.5] ([206.124.6.145]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K8E007YUUDM8KD0@mail-amer.sun.com>; Wed, 08 Oct 2008 02:03:23 -0600 (MDT)
Date: Wed, 08 Oct 2008 02:03:56 -0600
From: Shawn M Emery <Shawn.Emery@Sun.COM>
To: secdir@mit.edu
Message-id: <48EC696C.4010105@sun.com>
MIME-version: 1.0
User-Agent: Thunderbird 2.0.0.16 (X11/20080808)
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Cc: draft-ietf-avt-rtp-toffset@tools.ietf.org, iesg@ietf.org, avt-chairs@tools.ietf.org
Subject: [secdir] Review of draft-ietf-avt-rtp-toffset-07
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

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.

This draft describes a way to inference information between transmission 
of a packet vs RTP timestamp data.  This could be used to determine 
actual network jitter and the draft describes a new packet for reporting 
this data.

The security consideration section does exist and consists of one sentence:

   The given transmission offsets are only informative and it is hard to
   see security considerations from associating them with media streams.

I believe more guidance would help here.  For instance; security 
considerations should be made based on how applications act upon network 
jitter information and if the attribute is determined to be sensitive to 
a DoS attack, for instance, then protecting this information should be 
made.  Referring to recommendations outlined in the RTP RFC or better.

Other than that, I see no additional security concerns from that of RTP.

Editorial comment(s):
None.

Shawn.
--
_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir