Subject: [Gen-art] Re: Gen-ART LC Review of draft-ietf-rmt-bb-fec-raptor-object-08

From: Mark Watson <[email-masked]>
Date: Thu, 28 Jun 2007 21:35:34 -0700

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-masked]> 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-masked]
https://www1.ietf.org/mailman/listinfo/gen-art