Re: [secdir] COMMENT: draft-ietf-avt-rtp-toffset

Dave Singer <singer@apple.com> Tue, 21 October 2008 08:37 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 1DB3A3A6AF2; Tue, 21 Oct 2008 01:37:27 -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 862413A683C for <secdir@core3.amsl.com>; Mon, 20 Oct 2008 18:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 XMTKR3V3Na27 for <secdir@core3.amsl.com>; Mon, 20 Oct 2008 18:25:08 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 32EBF3A659A for <secdir@ietf.org>; Mon, 20 Oct 2008 18:25:07 -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 m9L1QJYD000313 for <secdir@ietf.org>; Mon, 20 Oct 2008 21:26:19 -0400
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m9L1QD91000310 for <secdir@PCH.mit.edu>; Mon, 20 Oct 2008 21:26:13 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9L1Q6bV020386 for <secdir@mit.edu>; Mon, 20 Oct 2008 21:26:06 -0400 (EDT)
X-ASG-Whitelist: Barracuda Reputation
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id ECF4D11D6C9D for <secdir@mit.edu>; Mon, 20 Oct 2008 21:26:05 -0400 (EDT)
Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 1CC76425202C; Mon, 20 Oct 2008 18:26:05 -0700 (PDT)
Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id EC25D28081; Mon, 20 Oct 2008 18:26:04 -0700 (PDT)
X-AuditID: 11807130-ac9b1bb000000ea6-69-48fd2fa82392
Received: from [59.8.107.76] (unknown [17.83.206.70]) by relay11.apple.com (Apple SCV relay) with ESMTP id D46A82804F; Mon, 20 Oct 2008 18:26:00 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06240800c522dbb85a56@[192.168.1.132]>
In-Reply-To: <20081007153748.8E7C03A6B3A@core3.amsl.com>
References: <20081007153748.8E7C03A6B3A@core3.amsl.com>
Date: Tue, 21 Oct 2008 10:16:29 +0900
To: Tim Polk <tim.polk@nist.gov>, Shawn M Emery <Shawn.Emery@Sun.COM>, secdir@mit.edu
From: Dave Singer <singer@apple.com>
X-Brightmail-Tracker: AAAAAA==
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
X-Mailman-Approved-At: Tue, 21 Oct 2008 01:37:25 -0700
Cc: avt-chairs@tools.ietf.org, hd@qualcomm.com
Subject: Re: [secdir] COMMENT: draft-ietf-avt-rtp-toffset
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

At 8:37  -0700 7/10/08, Tim Polk wrote:
>Comment:
>(1) I was amused when I read the security considerations.  It *is* 
>hard to see how informative
>offsets have any security implications, but I appreciate the effort!
>
>I would recommend adding a sentence pointing to RFC 3550 for the core security
>considerations.

added:
<t>The underlying security considerations of <xref target="RFC3550"/> 
should be taken into account.</t>

>
>(2) FYI, [hdrext] is now RFC 5285.  Perhaps that should be added to 
>the RFC Editor Note.

Yes, it is indeed published.

At 2:03  -0600 8/10/08, Shawn M Emery wrote:
>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.

added:
         <t>It is possible that malicious senders (or systems 
tampering with packets in transit) could send offsets that are 
implausible, could confuse the receiver, or result in calculated 
jitter values that might mislead the sender. Both sender and receiver 
of the transmission offsets and jitter values should take care that 
such behavior does not result in denial-of-service or other 
problems.</t>

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

-- 
David Singer
Multimedia Standards, Apple Inc.
_______________________________________________
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