Re: [secdir] SecDir review of draft-ietf-fecframe-framework-10
Greg Shepherd <gjshep@gmail.com> Thu, 10 February 2011 20:23 UTC
Return-Path: <gjshep@gmail.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 421353A6833; Thu, 10 Feb 2011 12:23:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 7cvEXiIVgBDm; Thu, 10 Feb 2011 12:23:12 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 31BCA3A6838; Thu, 10 Feb 2011 12:23:11 -0800 (PST)
Received: by bwz12 with SMTP id 12so2719591bwz.31 for <multiple recipients>; Thu, 10 Feb 2011 12:23:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XlDy21OXgVXaBAMQp8/czeO2b3ck8vR0EXV00UNMBJs=; b=q5iCSoBg8BS2NerY3/sg5FxhEjGSOKTnPOakcaHLdL539QJg3p07mHcyfYk+I9KKf9 pI6nKTPSCkT6TFs6A/2uZprT97ZymBFti0iInHdvDgcxR79k2UuzWnQ2x2s0IEUyEONj WRL+LHQblGBy+JmVAvXDsdz6GR9RaTGkNLphE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=XyoPD8+xcBs4Gf4ATGxekmgm6kI2uLTtICZw56YrF1sbC7dqxHA5UMxcWX2dEzZdQq +jQH27OWDBVW5N5rq1sAI3Sm4DulHLMgjLZ5XOm94vOJYmFcFLZXakGkCBjhVXI3zWME 15yXNJMHYf8bnRtgt84TBeq1Dgne0eOKcxOz0=
MIME-Version: 1.0
Received: by 10.204.49.208 with SMTP id w16mr3110301bkf.166.1297369403346; Thu, 10 Feb 2011 12:23:23 -0800 (PST)
Received: by 10.204.15.72 with HTTP; Thu, 10 Feb 2011 12:23:23 -0800 (PST)
In-Reply-To: <4D541191.6040208@inrialpes.fr>
References: <4C976675.2060302@inrialpes.fr> <4D541191.6040208@inrialpes.fr>
Date: Thu, 10 Feb 2011 12:23:23 -0800
Message-ID: <AANLkTikE1QdX6hPVXLsV+SKoDYV_26fkmrC-1YWdTMtx@mail.gmail.com>
From: Greg Shepherd <gjshep@gmail.com>
To: Vincent Roca <vincent.roca@inrialpes.fr>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 14 Feb 2011 09:37:42 -0800
Cc: draft-ietf-fecframe-framework.all@tools.ietf.org, IESG <iesg@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
Reply-To: gjshep@gmail.com
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:23:14 -0000
Vincent, I see no conflict and I greatly appreciate your continued contribution to the WG. We are (were) so close to completion up until Dec. I was hoping to have the framework draft in the editors queue by Prague. Thanks, Greg On Thu, Feb 10, 2011 at 8:25 AM, Vincent Roca <vincent.roca@inrialpes.fr> wrote: > 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