All, Apologies for the delay in responding to these comments. Please find inline below my proposals for addressing these comments. These proposals are implemented in draft 09 which I have just submitted.
Best regards, Mark Watson On 5/18/07 4:41 AM, "Spencer Dawkins" <[EMAIL PROTECTED]> wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please resolve these comments along with any other Last Call comments > you may receive. > > 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?) I can add an informative reference to a paper some of us published last year which provides an overview. I also realise I should add a reference to the paper which first introduced Raptor Codes. > > 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) Ok. > > 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?) There is more background in RFC3453 ("The Use of Forward Error Correction (FEC) in Reliable Multicast"). I will add a reference. > > 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.) > Ok. > 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?) > >
_______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
