Re: [secdir] SecDir review of draft-ietf-fecframe-framework-10

Greg Shepherd <> Thu, 10 February 2011 20:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 421353A6833; Thu, 10 Feb 2011 12:23:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.599
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7cvEXiIVgBDm; Thu, 10 Feb 2011 12:23:12 -0800 (PST)
Received: from ( []) by (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;; 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;; 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 with SMTP id w16mr3110301bkf.166.1297369403346; Thu, 10 Feb 2011 12:23:23 -0800 (PST)
Received: by with HTTP; Thu, 10 Feb 2011 12:23:23 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Thu, 10 Feb 2011 12:23:23 -0800
Message-ID: <>
From: Greg Shepherd <>
To: Vincent Roca <>
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:, IESG <>,
Subject: Re: [secdir] SecDir review of draft-ietf-fecframe-framework-10
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Feb 2011 20:23:14 -0000


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.


On Thu, Feb 10, 2011 at 8:25 AM, Vincent Roca <>; 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