Reed-Solomon Forward Error Correction (FEC) Schemes
draft-ietf-rmt-bb-fec-rs-05

[Ballot comment]
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."

[Ballot comment]
The authors should be commended for the great improvement in the Security Considerations
section between draft -04 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."

[Ballot comment]
From Gen-ART Review by Elwyn Davies.

  s9.2.1:
  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:
  s/Yet/However/

  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/

IANA Last Call comments:

The IANA Considerations section does not appear to have changed
since the document's first Last Call.

Assignment #1:

Upon approval of this document, the IANA will make the following
assignments in the "Reliable Multicast Transport (RMT) FEC
Encoding IDs and FEC Instance IDs - per [RFC5052]" registry
located at
http://www.iana.org/assignments/rmt-fec-parameters
sub-registry "ietf:rmt:fec:encoding
Fully-Specified FEC schemes (0-127)"

Value Description Reference
----- ------------------------------------------------- ---------
2 Reed-Solomon Codes over GF(2^^m) [RFC-rmt-bb-fec-rs-
03]
5 Reed-Solomon Codes over GF(2^^8) [RFC-rmt-bb-fec-rs-
03]

Assignment #2:

Upon approval of this document, the IANA will make the following
assignments in the "Reliable Multicast Transport (RMT) FEC
Encoding IDs and FEC Instance IDs - per [RFC5052]" registry
located at

http://www.iana.org/assignments/rmt-fec-parameters
sub-registry "ietf:rmt:fec:encoding:instance:129
ietf:rmt:fec:encoding = 129 (Small Block Systematic FEC Codes)"

Value Description Reference
----- ------------------------------------------------- ---------
0 Reed-Solomon Codes over GF(2^^8) [RFC-rmt-bb-fec-rs-
03]


We understand the above to be the only IANA Actions for this
document.

IANA Last Call comments:

Assignment #1:

Upon approval of this document, the IANA will make the following assignments in the "Reliable Multicast Transport (RMT) FEC Encoding IDs and FEC Instance IDs - per [RFC5052]" registry located at
http://www.iana.org/assignments/rmt-fec-parameters
sub-registry "ietf:rmt:fec:encoding
Fully-Specified FEC schemes (0-127)"

Value Description Reference
----- ------------------------------------------------- ---------
2 Reed-Solomon Codes over GF(2^^m) [RFC-rmt-bb-fec-rs-
03]
5 Reed-Solomon Codes over GF(2^^8) [RFC-rmt-bb-fec-rs-
03]

Assignment #2
Upon approval of this document, the IANA will make the following assignments in the "Reliable Multicast Transport (RMT) FEC Encoding IDs and FEC Instance IDs - per [RFC5052]" registry located at
http://www.iana.org/assignments/rmt-fec-parameters
sub-registry "ietf:rmt:fec:encoding:instance:129
ietf:rmt:fec:encoding = 129 (Small Block Systematic FEC Codes)"

Value Description Reference
----- ------------------------------------------------- ---------
0 Reed-Solomon Codes over GF(2^^8) [RFC-rmt-bb-fec-rs-
03]


We understand the above to be the only IANA Actions for this document.

draft-ietf-rmt-bb-fec-rs-03 intended for publication in the
"Experimental" category.

This writeup complies with RFC 4858.

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Document Shepherd is Brian Adamson, who has personally
reviewed this version of the document and believes it is ready
for forwarding to the IESG for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document had adequate review both key WG members and from key non-WG members. 
A working, open source implementation of the FEC algorithms
this document describes has been available from Luigi Rizzo for several
years and has been applied in many applications.  The Reed-Solomon FEC
encoding technique is well-understood.  It's application to the packet erasure
channel for network transport is 10 years mature.
  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

No additional reviews needed.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

There are no specific concerns or known IPR issues with this document.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

This document represent a solid consensus of the RMT WG.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No notable discontent.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

There are three outdated Informative References that can be repaired immediately:

== Outdated reference: draft-ietf-rmt-fec-bb-revised has been published as
    RFC 5052

  == Outdated reference: A later version (-09) exists of
    draft-ietf-rmt-bb-fec-raptor-object-08

  == Outdated reference: A later version (-05) exists of
    draft-ietf-rmt-pi-norm-revised-04
  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The document splits its references into normative and
informative. No Downward References.

  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

The IANA consideration section exists, it is consistent with the rest
of the document and is consistent with the registration guidelines
specified in draft-ietf-rmt-fec-bb-revised. No new registry is
defined. No Expert Review Process is necessary for the IANA assignments
requested by this document.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

The documents contains no section written in formal language.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

          Working Group Summary
            Was there anything in WG process that is worth noting?  For
            example, was there controversy about particular points or
            were there decisions where the consensus was particularly
            rough?

          Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type or other expert review,
            what was its course (briefly)?  In the case of a Media Type
            review, on what date was the request posted?

          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?


Document Announcement Write-Up follows.

Technical Summary

    This document is an optional Building Block usable to fully define
    an RMT Protocol.  It fully-specifies Forward Error Correction
    (FEC) Codes based on the well-known Reed-Solomon algorithm for application
    in the packet erasure channel as consistent with RMT Protocol needs.  This
    is done within the guidelines of draft-ietf-rmt-fec-bb-revised. It also
    specifies procedures and packet-header fields, as required by
    draft-ietf-rmt-fec-bb-revised.

    The combination of this document and draft-ietf-rmt-fec-bb-revised
    allows the implementation of an interoperable Forward Error Correction
    scheme usable in the context of an RMT transport protocol (e.g.
    LCT/ALC or NORM).
   
    The Reed-Solomon code specified is a systematic code.  Parity symbols
    are generated using Galois field mathmatics.  A range of block sizes
    with varying computational complexity are covered with codes with
    individual symbol sizes from 2^^8..2^^16 described.  Reed-Solomon codes
    belong to the class of Maximum Distance Separable symbols from any set
    of k received symbols.  This idealized property allows adaptation to
    maximumally-efficient repair strategies for RMT protocol like NORM
    that use FEC-based repair.
Working Group Summary

    There is consensus in the WG to publish these documents.

Document Quality

    A very mature working, open source implementation of the FEC algorithms
    this document describes is available.  The FEC implementation has been used
    in working RMT NORM implementations.  The Reed-Solomon technique described
    has been successfully used in reliable multicast transport for over 10 years.

Brian Adamson is the Document Shepherd.
Magnus Westerlund is the Responsible Area Director.