Document: Draft-ietf-rmt-bb-fec-raptor-object-08 Reviewer: Spencer Dawkins Review Date: 2007/05/16 IETF LC End Date: 2007/05/15 (sorry!) IESG Telechat date: (if known) Summary: I have one question for the ADs, but if the answer is "yes" (it's the "2119:" comment below), the specification is ready for publication as Proposed Standard. Comments: This draft is more clearly written than I have any right to expect. I note that the current status is "revised ID needed" - just for Russ's information. Abstract This document describes a Fully-Specified FEC scheme, corresponding to FEC Encoding ID 1, for the Raptor forward error correction code and its application to reliable delivery of data objects. Raptor is a fountain code, i.e., as many encoding symbols as needed can be generated by the encoder on-the-fly from the source symbols of a source block of data. The decoder is able to recover the source block from any set of encoding symbols only slightly more in number than the number of source symbols. The Raptor code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. 1. Introduction This document specifies an FEC Scheme for the Raptor forward error (Nit: is there any pointer to a Raptor description that provides more overview than this document?) correction code for object delivery applications. The concept of an FEC Scheme is defined in [2] and this document follows the format (Nit: Just for ease of use - I believe we're asking people to use symbolic references) prescribed there and uses the terminology of that document. The Raptor FEC Scheme is a Fully-Specified FEC Scheme corresponding to FEC Encoding ID 1. Raptor is a fountain code, i.e., as many encoding symbols as needed can be generated by the encoder on-the-fly from the source symbols of a block. The decoder is able to recover the source block from any set of encoding symbols only slightly more in number than the number of source symbols. The code described in this document is a systematic code, that is, the original source symbols can be sent unmodified from sender to receiver, as well as a number of repair symbols. (Nit: is it possible to point to a reference that provides more context for FEC, fountain codes and systemic codes, etc, where would you send an implementor to develop an understanding before diving into implementation?) 3.2.1. Mandatory The value of the FEC Encoding ID MUST be 1 (one). (Clarity: "1" being a magic number, it might be good to say "must be 1 (one) - the value assigned for Raptor by IANA." I knew what to do, but not what what "1" meant. Even a pointer to the IANA Considerations would be helpful.) 6. Security Considerations Data delivery can be subject to denial-of-service attacks by attackers which send corrupted packets that are accepted as legitimate by receivers. This is particularly a concern for multicast delivery because a corrupted packet may be injected into the session close to the root of the multicast tree, in which case the corrupted packet will arrive at many receivers. This is particularly a concern when the code described in this document is used because the use of even one corrupted packet containing encoding data may result in the decoding of an object that is completely corrupted and unusable. It is thus RECOMMENDED that source authentication and integrity checking are applied to decoded objects before delivering objects to an application. For example, a SHA-1 hash [3] of an object may be appended before transmission, and the SHA-1 hash is computed and checked after the object is decoded but before it is delivered to an application. Source authentication SHOULD be provided, for example by including a digital signature verifiable by the receiver computed on top of the hash value. It is also RECOMMENDED that a packet authentication protocol such as TESLA [4] be used to detect and discard corrupted packets upon arrival. Furthermore, it is RECOMMENDED that Reverse Path Forwarding checks be enabled in all network routers and switches along the path from the sender to receivers to limit the possibility of a bad agent successfully injecting a corrupted packet into the multicast tree data path. Another security concern is that some FEC information may be obtained by receivers out-of-band in a session description, and if the session description is forged or corrupted then the receivers will not use the correct protocol for decoding content from received packets. To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect session descriptions, e.g., by using source authentication to ensure that receivers only accept legitimate session descriptions from authorized senders. (2119: Are the ADs OK with RECOMMENDED=SHOULD strength for these considerations? The attacks seem awfully fatal for anyone using RMT protocols because R=Reliable - if an attacker is able to break, or worse, break part of a multicast tree, isn't that basically "start over" for an application that is probably using multicast because of bandwidth and processing considerations?)