Last Call Review of draft-ietf-fecframe-framework-
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)
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...
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
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
- 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
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
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
NB: I don't think ciphering is an issue, but TESLA
authentication/integrity will probably not be
appropriate! There are other similar examples.