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

[Vincent Roca <[e-mail]>]

 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