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

From: Spencer Dawkins <[email-masked]>
Date: Fri, 18 May 2007 06:41:13 -0500

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?)

   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?) 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art