Re: [secdir] SecDir review of draft-ietf-fecframe-framework-10
Vincent Roca <vincent.roca@inrialpes.fr> Thu, 10 February 2011 20:00 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 667543A6A7F; Thu, 10 Feb 2011 12:00:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.205
X-Spam-Level:
X-Spam-Status: No, score=-10.205 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
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 QmrYZTx93MHy; Thu, 10 Feb 2011 12:00:19 -0800 (PST)
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 AFE323A6A64; Thu, 10 Feb 2011 12:00:18 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.60,451,1291590000"; d="scan'208";a="99669915"
Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO macbook-de-roca.local) ([82.236.155.50]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 10 Feb 2011 21:00:30 +0100
Message-ID: <4D541191.6040208@inrialpes.fr>
Date: Thu, 10 Feb 2011 17:25:53 +0100
From: Vincent Roca <vincent.roca@inrialpes.fr>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: IESG <iesg@ietf.org>
References: <4C976675.2060302@inrialpes.fr>
In-Reply-To: <4C976675.2060302@inrialpes.fr>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-fecframe-framework.all@tools.ietf.org, secdir@ietf.org
Subject: Re: [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: Thu, 10 Feb 2011 20:00:21 -0000
All, <SecDir hat on> The goal of this email is to clarify the situation WRT my SecDir review of this document, back in September. All my comments have been addressed in the new version -12. A very constructive discussion took place on the FECFRAME mailing list in Nov-Dec. Additional considerations, not listed in my review, have been raised during the discussion and included in version -12. <SecDir hat off> <co-author hat on> If you go through the -12 version, you'll see I'm now a co-author of this I-D (I'm an active contributor to this WG which explains why this is so). Some of you may consider there's now a conflict of interest... <co-author hat off> Cheers, Vincent 0n 20/09/10 15:49, Vincent Roca wrote: > 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