Re: [secdir] secdir review of draft-ietf-avt-rtp-rfc3984bis-10

Radia Perlman <radiaperlman@gmail.com> Mon, 26 April 2010 05:34 UTC

Return-Path: <radiaperlman@gmail.com>
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 7E7DD28C15F; Sun, 25 Apr 2010 22:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.204
X-Spam-Level:
X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_05=-1.11]
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 nP2PH50F6hSk; Sun, 25 Apr 2010 22:34:58 -0700 (PDT)
Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 2830A3A6BA5; Sun, 25 Apr 2010 22:21:37 -0700 (PDT)
Received: by qyk11 with SMTP id 11so14501553qyk.13 for <multiple recipients>; Sun, 25 Apr 2010 22:20:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=YPScOG3R6sVMpnIjOBGt1XdGkOjooOR3jBX8AfaPySk=; b=Qz23o16C5Uc00kR/apkop9dVn1z8lgNlQgd6SVLXayH+qHT3WVNdXPpbQl/HRvOCls 6uc1upH6IMo9Ug7kqkZ9gpT/UEgjX38ByuF+VRVayvSdgRPuf0oqfEBQ7Lm1daSp7e4d plmoLI3XfDxyBtK+CX+uU8X3/lSGenbc8/tMQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=RVZpXvFwYxL7r9sHdl4D4jVN+vJtLKTJFfgWqdMDH8wxwL6iCRRS4Br/auU/iSWQ0C VsB1I1CtzKsty9qQBb5yFBgjbzGgoq88FGLv9J0jG4zWxzCznNbZ0vta/1pa/iNWqpcw gx4FUqYExhY9JJhErSBLmq2RMOCnwtpnJfowo=
MIME-Version: 1.0
Received: by 10.229.227.5 with SMTP id iy5mr4326278qcb.29.1272259247872; Sun, 25 Apr 2010 22:20:47 -0700 (PDT)
Received: by 10.231.147.70 with HTTP; Sun, 25 Apr 2010 22:20:47 -0700 (PDT)
In-Reply-To: <g2nc09b97ef1004252214p3ad63f2el5cc8631617ae8b48@mail.gmail.com>
References: <g2nc09b97ef1004252214p3ad63f2el5cc8631617ae8b48@mail.gmail.com>
Date: Sun, 25 Apr 2010 22:20:47 -0700
Message-ID: <x2vc09b97ef1004252220s4666accbl4ad1a88a50c8ce0f@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: secdir@ietf.org, iesg@ietf.org, yekuiwang@huawei.com, ron.even.tlv@gmail.com, tom.kristensen@tandberg.com, tomkri@ifi.uio.no, rjesup@wgate.com
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [secdir] secdir review of draft-ietf-avt-rtp-rfc3984bis-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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/mail-archive/web/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>
X-List-Received-Date: Mon, 26 Apr 2010 05:34:59 -0000

Sorry secdir and iesg for sending this twice...I've been trying to
figure out how to use the tools thing to get all the authors, and
apparently didn't do it right, so I'll manually put in the authors
names like I have done before, on previous secdir reviews.
(sending to draft-ietf-avt-rtp-rfc3984bis-10.all@tools.ietf.org bounced)



On Sun, Apr 25, 2010 at 10:14 PM, Radia Perlman <radiaperlman@gmail.com>; wrote:
> This document just describes how to carry video in RTP. Apparently
> there is a standard in ISO and a standard in ITU (ITU-T Recommendation
> H.264 and ISO/IEC International Standard 14496 Part 10) that both
> specify nearly identical compression algorithms for video encoding.
> Given that this document is not describing the video encoding itself,
> but just how to carry it in RTP, it is a little surprising that this
> document is 104 pages, but it describes what to do about reordering,
> lost packets, fragmentation across packet boundaries, and so forth.
>
> There really are not any security considerations, and certainly not
> anything they missed in their security considerations section. One
> thing that might be nice to mention is that it is dangerous to do
> encryption without integrity protection because a single bit error in
> the ciphertext can cause a lot of errors in the plaintext.
>
> Radia
>