[secdir] secdir review of draft-ietf-fecframe-dvb-al-fec

scott@hyperthought.com Thu, 31 December 2009 19:03 UTC

Return-Path: <scott@hyperthought.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 DB1E43A6864 for <secdir@core3.amsl.com>; Thu, 31 Dec 2009 11:03:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.392
X-Spam-Level:
X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 IJ8MPyMXmHVU for <secdir@core3.amsl.com>; Thu, 31 Dec 2009 11:03:32 -0800 (PST)
Received: from smtp172.iad.emailsrvr.com (smtp172.iad.emailsrvr.com [207.97.245.172]) by core3.amsl.com (Postfix) with ESMTP id 9D4453A6873 for <secdir@ietf.org>; Thu, 31 Dec 2009 11:03:32 -0800 (PST)
Received: from relay27.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay27.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id D8F7F1B40A6; Thu, 31 Dec 2009 14:03:10 -0500 (EST)
Received: from dynamic4.wm-web.iad.mlsrvr.com (dynamic4.wm-web.iad.mlsrvr.com [192.168.2.153]) by relay27.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id CCB2E1B40A0; Thu, 31 Dec 2009 14:03:10 -0500 (EST)
Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic4.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id A11A61D4806E; Thu, 31 Dec 2009 14:03:10 -0500 (EST)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Thu, 31 Dec 2009 11:03:10 -0800 (PST)
Date: Thu, 31 Dec 2009 11:03:10 -0800 (PST)
From: scott@hyperthought.com
To: iesg@ietf.org, secdir@ietf.org, abegen@cisco.com, stockhammer@nomor.de, fecframe-chairs@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
Message-ID: <1262286190.65839253@192.168.2.230>
X-Mailer: webmail7.0
Subject: [secdir] secdir review of draft-ietf-fecframe-dvb-al-fec
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: Thu, 31 Dec 2009 19:03: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 document describes implementation of a forward error correction protocol over RTP using already-defined protocol elements. The protocol was originally defined by an ETSI group.

The security considerations section says, "This specification adds no new security considerations to the DVB-IPTV AL-FEC protocol", which I take to mean that the authors see no way in which the proposed approach changes the security properties of the original ETSI specification. Since the protocol doesn't seem to implement any security features, I guess this is probably correct. Still, it might be better to add some additional commentary such as what is found in the security considerations section of draft-ietf-fecframe-interleaved-fec-scheme-07.txt (or, perhaps point to that and the framework doc). 

Lacking much necessary background in this area, I don't feel qualified to fully evaluate this document. With that deficiency noted, the only possible red flag I saw is that the FEC protocol requires that the SSRC fields of the FEC frames be set to 0, while SRTP requires unique SSRC values for security reasons. With my very limited background, I can't be sure if there is an important security interaction here or not, but it seems worth asking about.

--Scott