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