[secdir] Review of draft-ietf-payload-rtp-ancillary-06

Shawn M Emery <shawn.emery@oracle.com> Tue, 08 November 2016 08:08 UTC

Return-Path: <shawn.emery@oracle.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AE2BE1294F3 for <secdir@ietfa.amsl.com>; Tue, 8 Nov 2016 00:08:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 1Z3gJ47SDg12 for <secdir@ietfa.amsl.com>; Tue, 8 Nov 2016 00:08:31 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B30E4129468 for <secdir@ietf.org>; Tue, 8 Nov 2016 00:08:31 -0800 (PST)
Received: from aserv0021.oracle.com (aserv0021.oracle.com []) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uA888T3k016167 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Nov 2016 08:08:30 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com []) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id uA888TDn008224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Nov 2016 08:08:29 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com []) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uA888T18013687; Tue, 8 Nov 2016 08:08:29 GMT
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Nov 2016 00:08:28 -0800
References: <3413ce55-8a13-9698-5985-7fecc8c8f038@oracle.com>
To: "secdir@ietf.org" <secdir@ietf.org>
From: Shawn M Emery <shawn.emery@oracle.com>
X-Forwarded-Message-Id: <3413ce55-8a13-9698-5985-7fecc8c8f038@oracle.com>
Message-ID: <92774159-d56b-cc7f-b5cd-b8e17d038475@oracle.com>
Date: Tue, 08 Nov 2016 01:10:50 -0700
User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <3413ce55-8a13-9698-5985-7fecc8c8f038@oracle.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Source-IP: aserv0021.oracle.com []
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/jm8kvSia-ImhCOvNqaq2-SP7u_I>
Cc: draft-ietf-payload-rtp-ancillary.all@tools.ietf.org
Subject: [secdir] Review of draft-ietf-payload-rtp-ancillary-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Tue, 08 Nov 2016 08:08:33 -0000

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 specifies a Real-time Transport Protocol (RTP) payload format
for ancillary data; including time code, Closed Captioning, and Active
Format Description (AFD).

The security considerations section does exist and refers to the base
protocol specification of RTP and any profile utilized for consideration.
The section continues that RTP does not require a single media solution,
referencing RFC 7202, and references RFC 7201 for various mechanisms to
secure RTP.  I agree with this assertion.  The section goes on to discuss
the specific payload data and how to mitigate against attack by first
sanity checking said data.  I'm OK with this assertion, except for the
integrity check using Checksum_Word.  The nine bit checksum based on
summing the nine least significant bits of four out of dozens of possible
data fields doesn't seem to provide sufficient coverage for this check.

General comments:


Editorial comments:

Abstract: Does RTP and SMPTE need to be expanded first?
Abstract: Is SMPTE ST 291-1 a normative reference?
s/an SDI/a SDI/