[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
- [secdir] Review of draft-ietf-fecframe-interleave… Tero Kivinen
- Re: [secdir] Review of draft-ietf-fecframe-interl… Ali C. Begen (abegen)