Reed-Solomon Forward Error Correction (FEC) Schemes
RFC 5510

Note: This ballot was opened for revision 05 and is now closed.

Magnus Westerlund Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lars Eggert) No Objection

(Sam Hartman) No Objection

(Russ Housley) No Objection

Comment (2007-11-28)
No email
send info
  From Gen-ART Review by Elwyn Davies.

  s/packet per packet/packet-by-packet/
  s/Even if we mention these attacks/Although these attacks are described/

  s9.2.2, para 1:
  s/may be in some case/may be in some cases/

  s9.2.2, TESLA bullet:

  s9.2.2, last para:
  s/Nonetheless, in case there is any concern of the threat of object corruption/
   /Nonetheless, if there is any risk of object corruption/

(Chris Newman) No Objection

(Jon Peterson) No Objection

(Tim Polk) No Objection

Comment (2007-11-28)
No email
send info
The authors should be commended for the great improvement in the Security Considerations
section between draft -03 and -05.  The current text is probably *too* prescriptive, given that
the broad applicability of the Reed Solomon FEC scheme.  I can not in good conscience
block this document for being too perscriptive, since the changes were a vigorous response to
a secdir review, but I do believe that the points Steve Kent raised in his re-review should be
addressed.  I have appended his re-review comments below.

--- re-review comments on fec-rs section 9 (security considerations)  ---

I appreciate the efforts of the authors to make this section more precise and technically accurate.  However, in retrospect, I wonder if a document that is so broad in its scope of applicability (it contains no normative references to ANY specific protocols for multicast content distribution) ought to make statements about requirements for specific security mechanisms. I think it might be appropriate to remove the MAYs and SHOULDs from this section, and just cite examples of relevant IETF standards that are probably appropriate for use in this context. Also, the authors need not assume the burden of making security recommendations for all multicast content distribution schemes.  They should focus only on the need for such security relative to use of FEC. This is what they sate in the intro to section 9, but the text that follows tends to ignore this statement in most instances.

Section 9.2.1

        IPsec is misspelled.

        The use of "access control" here seems a bit odd.  We usually say that encryption is employed to provide confidentiality for objects during transmission (or in storage).  We say that access control is afforded to objects in storage, or to machines or networks. Finally, since the focus of this document is use of FEC in a multicast context, this section should refer to MSEC documents that describe use of IPsec confidentiality in that context, not just RFC 4303, if the section is retained.

        I think this subsection should be removed, or substantially reduced in size, since the authors note that there appear to be no confidentiality implications of using FEC in this context.

Section 9.2.2

        the discussion of object-level integrity and authentication discusses PKCS #1. I think that a reference to RFC 3852 (CMS) would be more appropriate, as it is standards track while PKCS #1 is Informational.  Also I question the use of MAY here, given the overall flavor of this document, and the lack of a similar requirements statement for any of the other alternatives presented in this subsection.

        The discussion of ECC use needs to be improved. First, it is not clear that ECC is fast enough and imposes low enough overhead to make it an acceptable per-packet solution in all contexts, contrary to what the text here suggests.  Also, the comments about ECC patent claims should be softened (and the phrase "proprietary patents" is poor English).

        TESLA may be fine in some contexts, but here too the authors seem to endorse it too broadly, given the very general nature of the multicast content distribution contexts where the FEC technology might be employed. Soften the text a bit here as well.

        The very brief discussion of key management here is probably not worth including, since it is bereft of any citations to relevant IETF standards.

        Since IETF specs like this are oriented toward protocol developers, the following statement seems odd: "It is up to the developer and deployer, who know the security requirements and features of the target application area, to define which solution is the most appropriate."  Just refer to the content distribution  protocol developers, not users or "deployers."

Section 9.3

        The recommendation for use of an XML signature to protect FEC OTI when it is carried in an FDT Instance makes sense, given that this data structure is an XML construct. If FEC OTI is sent out-of-band, then the corresponding recommendation should be more specific, e.g., to use CMS, rather than just saying "digitally signing it."

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection