[secdir] SecDir review of draft-ietf-fecframe-framework-10
Vincent Roca <vincent.roca@inrialpes.fr> Mon, 20 September 2010 13:49 UTC
Return-Path: <vincent.roca@inrialpes.fr>
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 8F8313A6925; Mon, 20 Sep 2010 06:49:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.505
X-Spam-Level:
X-Spam-Status: No, score=-5.505 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 RL6-l92JRjWj; Mon, 20 Sep 2010 06:49:21 -0700 (PDT)
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id 9B6143A68E3; Mon, 20 Sep 2010 06:49:19 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.56,393,1280700000"; d="scan'208";a="67955289"
Received: from geve.inrialpes.fr ([194.199.24.116]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 20 Sep 2010 15:49:41 +0200
Message-ID: <4C976675.2060302@inrialpes.fr>
Date: Mon, 20 Sep 2010 15:49:41 +0200
From: Vincent Roca <vincent.roca@inrialpes.fr>
Organization: INRIA
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3
MIME-Version: 1.0
To: IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-fecframe-framework.all@tools.ietf.org
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [secdir] SecDir review of draft-ietf-fecframe-framework-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, 20 Sep 2010 13:49:22 -0000
Mark, all, 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. (NB: to make it clear, I've been randomly selected to review this document, I didn't ask) Main comments: -------------- 1) As a general comment, having a sound, detailed security section in this FECFRAME framework document is critical since this document is referred by all the WG documents and all of them inherit the framework recommendations. From this point of view, the current security discussion is not satisfying IMHO. If we further compare this FECFRAME/framework section to the similar section in the ALC, Flute and NORM RFC (those RMT protocols share some similarities in terms of security requirements), we see major difference in terms of completeness of the discussion. 2) There is no "Minimum security requirement". More precisely this document does not identify a mandatory to implement (but not necessarily to use) security configuration. I think this also applies here. IPsec/ESP is usually a good solution for that... Additional comments: -------------------- I'm okay with the first two paragraphs. Then: 3) I'd like to see a discussion which differentiates the various security requirements of interest: - security WRT the data flow itself, which essentially concerns the content provider; - security WRT the FECFRAME system, which essentially concerns the sending and receiving hosts; - security WRT the network, in the sense "additional risks that the use of FECFRAME may create for the network", which of course concerns all the hosts; The goal of this section is not to solve all these issues but to highlight the risks, the gradation in the risks, and to give some directions on how to mitigate them (or solve them if feasible). 4) paragraph 3 has been largely improved compared to previous versions, however I still find the discussion confusing. So I suggest another organization: - if integrity protection is required, using it above FECFRAME, at the ADU level, is operational since all corrupted ADUs are finally detected as such. But of course there are limits (e.g. DoS as already explained). - if integrity protection is required, using it below FECFRAME has the advantage of reducing DoS risks. This is therefore RECOMMENDED. - however when applied below FECFRAME, this integrity service will not necessarily be end-to-end (depends on how FECFRAME is used, end-to-end or not). Whether it's appropriate or not depends on whether one can tell where the security threats are (which is use-case dependent). BTW: use the "ADU"/"ADU flow" rather than "source packets" to be in-line with the agreed terminology. 5) paragraph 4: I don't like the discussion here. The same comment on resource waste can be made with non encrypted flows. Concerning the second comment of this paragraph, it's clear that giving a copy of plaintext repair packets to non authorized receivers will lead to problems, but is it so different than giving a copy of plaintext source packets? When we say that confidentiality protection is applied after FEC encoding, this is for instance within IPsec, i.e. all source/repair FEC packets are encrypted. That's the assumption (paragraph 2). I suggest to change this discussion as follows: - when ADU flows with different security requirements need to be FEC protected jointly, then each flow MAY be processed appropriately before entering FECFRAME e.g. to encrypt it. (Note that this is not a MUST. E.g. there are situations where the only insecure domain is the one over which FECFRAME operates => this situation may be addressed with IPsec/ESP, for the whole flow) - it is then REQUIRED that the FECFRAME aggregate flow be in line with the maximum security requirements of the individual ADU flows. E.g. if DoS protection is required, since the use of FECFRAME must not add any additional threat, an integrity protection must be provided below FECFRAME. - generally speaking it is often RECOMMENDED to avoid FEC protecting flows with largely different security requirements. 6) A note should be added to highlight the fact that attacks targeting the congestion control building block (when applicable) may severely damage the network. A pointer to section 8 should be added. 7) It should be noted that certain security transforms will add some latency to the ADU flow delivery. This latency may need to be considered when dealing with real-time flows. NB: I don't think ciphering is an issue, but TESLA authentication/integrity will probably not be appropriate! There are other similar examples. Regards, Vincent
- [secdir] SecDir review of draft-ietf-fecframe-fra… Vincent Roca
- Re: [secdir] SecDir review of draft-ietf-fecframe… Vincent Roca
- Re: [secdir] SecDir review of draft-ietf-fecframe… Greg Shepherd