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

Vincent Roca <> Thu, 10 February 2011 20:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 667543A6A7F; Thu, 10 Feb 2011 12:00:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.205
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QmrYZTx93MHy; Thu, 10 Feb 2011 12:00:19 -0800 (PST)
Received: from ( []) by (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 (HELO macbook-de-roca.local) ([]) by with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 10 Feb 2011 21:00:30 +0100
Message-ID: <>
Date: Thu, 10 Feb 2011 17:25:53 +0100
From: Vincent Roca <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv: Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: IESG <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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:00:21 -0000


<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

<co-author hat off>



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