[secdir] Review of draft-ietf-fecframe-interleaved-fec-scheme-05

Tero Kivinen <kivinen@iki.fi> Mon, 07 December 2009 13:01 UTC

Return-Path: <kivinen@iki.fi>
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 B16C728C153; Mon, 7 Dec 2009 05:01:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.591
X-Spam-Level:
X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599]
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 4KM8RjCl5yPT; Mon, 7 Dec 2009 05:01:00 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 88C563A679C; Mon, 7 Dec 2009 05:01:00 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nB7D0j9M011379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Dec 2009 15:00:45 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nB7D0jbP004255; Mon, 7 Dec 2009 15:00:45 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19228.64637.664835.801627@fireball.kivinen.iki.fi>
Date: Mon, 7 Dec 2009 15:00:45 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: iesg@ietf.org, secdir@ietf.org
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 14 min
X-Total-Time: 35 min
Cc: fecframe-chairs@tools.ietf.org, draft-ietf-fecframe-interleaved-fec-scheme@tools.ietf.org
Subject: [secdir] Review of draft-ietf-fecframe-interleaved-fec-scheme-05
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, 07 Dec 2009 13:01:01 -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 defines new RTP payload format for sending forward error
correction that is generated by the 1-D interleaved parity code.

The security considerations section refers to the generic RTP
(RFC3550) security considerations. It also mentions generic solutions
to different security problems (encryption for confidentiality,
integrity protection mechanism for integrity and authentication of the
source of the payload).

It does not list any specific mechanisms, but points to Secure
Real-time Transport Protocol SRTP (RFC3711), IPsec (RFC4301) and TLS
(RFC5246).

The only thing missing from the security considerations section is
that it should mention that the repair flow should require exactly
same security features that what is provided to the source flow. The
repair flow packets are xor of the multiple source flow packets, and
if those do not get exactly same confidentiality, integrity and
authentication of source protection then the original source flow
confidentiality, integrity or authentication of the source could be
compromized.

I.e. it is not acceptable for using for example AES, SHA2-256 to
protect source flow, but send repair flow without encryption and
without integrity protection, as when doing that attacker can replace
repair flow packets, and cause source flow packets to drop triggering
error correcting procedures on the receiver which will then use repair
flow packets having weaker security than source flow packets.
-- 
kivinen@iki.fi