TOC 
RMTV. Roca
Internet-DraftINRIA
Intended status: ExperimentalB. Adamson
Expires: September 10, 2009Naval Research Laboratory
 March 09, 2009


FCAST: Scalable Object Delivery for the ALC and NORM Protocols
draft-roca-rmt-newfcast-04

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 10, 2009.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document introduces the FCAST object (e.g., file) delivery application on top of the ALC and NORM reliable multicast protocols. FCAST is a highly scalable application that provides a reliable object delivery service.



Table of Contents

1.  Introduction
    1.1.  Applicability
2.  Requirements notation
3.  Definitions, Notations and Abbreviations
    3.1.  Definitions
    3.2.  Abbreviations
4.  FCAST Principles
    4.1.  FCAST Content Delivery Service
    4.2.  Meta-Data Transmission
    4.3.  Meta-Data Content
    4.4.  Carousel Transmission
    4.5.  Carousel Instance Object
    4.6.  Compound Object Identification
    4.7.  FCAST/ALC Additional Specificities
    4.8.  FCAST/NORM Additional Specificities
    4.9.  FCAST Sender Behavior
    4.10.  FCAST Receiver Behavior
5.  FCAST Specifications
    5.1.  Compound Object Header Format
    5.2.  Carousel Instance Object Format
6.  Security Considerations
    6.1.  Problem Statement
    6.2.  Attacks Against the Data Flow
        6.2.1.  Access to Confidential Objects
        6.2.2.  Object Corruption
    6.3.  Attacks Against the Session Control Parameters and Associated Building Blocks
        6.3.1.  Attacks Against the Session Description
        6.3.2.  Attacks Against the FCAST CIO
        6.3.3.  Attacks Against the Object Meta-Data
        6.3.4.  Attacks Against the ALC/LCT Parameters
        6.3.5.  Attacks Against the Associated Building Blocks
    6.4.  Other Security Considerations
7.  IANA Considerations
8.  Acknowledgments
9.  References
    9.1.  Normative References
    9.2.  Informative References
Appendix A.  FCAST Examples
    A.1.  Basic Examples
    A.2.  FCAST/NORM with NORM_INFO Examples
§  Authors' Addresses




 TOC 

1.  Introduction

This document introduces the FCAST reliable and scalable object (e.g., file) delivery application. Two versions of FCAST exist:

Hereafter, the term FCAST denotes either FCAST/ALC or FCAST/NORM.

Depending on the target use case, the delivery service provided by FCAST is more or less reliable. For instance, with FCAST/ALC used in ON-DEMAND mode over a time period that largely exceeds the typical download time, the service can be considered as fully reliable. Similarly, when FCAST is used along with a session control application that collects reception information and takes appropriate corrective measures (e.g., a direct point-to-point retransmission of missing packets, or a new multicast recovery session), then the service can be considered as fully reliable. On the opposite, if FCAST operates in PUSH mode, then the service is usually only partially reliable, and a receiver that is disconnected during a sufficient time will perhaps not have the possibility to download the object.

Depending on the target use case, the FCAST scalability is more or less important. For instance, if FCAST/ALC is used on top of purely unidirectional transport channels, with no feedback information at all, which is the default mode of operation, then the scalability is maximum since neither FCAST, nor ALC, UDP or IP generates any feedback message. On the opposite, the FCAST/NORM scalability is typically limited by NORM scalability itself. Similarly, if FCAST is used along with a session control application that collects reception information from the receivers, then this session control application limits the scalability of the global object delivery system. This situation can of course be mitigated by using a hierarchy of feedback message aggregators or servers. The details of this is out of the scope of the present document.

A design goal behind FCAST is to define a streamlined solution, in order to enable lightweight implementations of the protocol stack, and limit the operational processing and storage requirements. A consequence of this choice is that FCAST cannot be considered as a versatile application, capable of addressing all the possible use-cases. On the opposite, FCAST has some intrinsic limitations. From this point of view it differs from FLUTE [RMT‑FLUTE] (Paila, T., Walsh, R., Luby, M., Lehtonen, R., and V. Roca, “FLUTE - File Delivery over Unidirectional Transport,” October 2007.) which favors flexibility at the expense of some additional complexity.

A good example of the design choices meant to favor the simplicity is the way FCAST manages the object meta-data: by default, the meta-data and the object content are sent together, in a compound object. This solution has many advantages in terms of simplicity as will be described later on. However, as such, it also has an intrinsic limitation since it does not enable a receiver to decide in advance, before beginning the reception of the compound object, whether the object is of interest or not, based on the information that may be provided in the meta-data. Therefore this document defines additional techniques that may be used to mitigate this limitation. It is also possible that some use-cases require that each receiver download the whole set of objects sent in the session (e.g., with mirroring tools). When this is the case, the above limitation is no longer be a problem.



 TOC 

1.1.  Applicability

FCAST is compatible with any congestion control protocol designed for ALC/LCT or NORM. However, depending on the use-case, the data flow generated by the FCAST application might not be constant, but instead be bursty in nature. Similarly, depending on the use-case, an FCAST session might be very short. Whether and how this will impact the congestion control protocol is out of the scope of the present document.

FCAST is compatible with any security mechanism designed for ALC/LCT or NORM. The use of a security scheme is strongly RECOMMENDED (see Section 6 (Security Considerations)).

FCAST is compatible with any FEC scheme designed for ALC/LCT or NORM. Whether FEC is used or not, and the kind of FEC scheme used, is to some extent transparent to FCAST.

FCAST is compatible with both IPv4 and IPv6. Nothing in the FCAST specification has any implication on the source or destination IP address.



 TOC 

2.  Requirements notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

3.  Definitions, Notations and Abbreviations



 TOC 

3.1.  Definitions

This document uses the following definitions:

FCAST/ALC denotes the FCAST application running on top of the ALC/LCT reliable transport protocol;

FCAST/NORM denotes the FCAST application running on top of the NORM reliable transport protocol;

FCAST denotes either FCAST/ALC or FCAST/NORM;

Compound Object denotes an ALC or NORM transport object composed of the Compound Object Header Section 5.1 (Compound Object Header Format), including any meta-data and the content of the original application object (e.g., a file);

Carousel denotes the compound object transmission system of an FCAST sender;

Carousel Instance denotes a fixed set of registered compound objects that are sent by the carousel during a certain number of cycles. Whenever compound objects need to be added or removed, a new Carousel Instance is defined;

Carousel Instance Object (CIO) denotes a specific object that lists the compound objects that comprise a given carousel instance;

Carousel Cycle denotes a transmission round within which all the compound objects registered in the Carousel Instance are transmitted a certain number of times. By default, compound objects are transmitted once per cycle, but higher values are possible, that might differ on a per-object basis;

The Transmission Object Identifier (TOI) refers the numeric identifier associated to a specific object by the underlying transport layer. In the case of ALC, this corresponds to the TOI described in that specification while for the NORM specification this corresponds to the NormObjectId described there.



 TOC 

3.2.  Abbreviations

This document uses the following abbreviations:

AbbreviationDefinition
CIO Carousel Instance Object
FEC OTI FEC Object Transmission Information
TOI Transmission Object Identifier



 TOC 

4.  FCAST Principles



 TOC 

4.1.  FCAST Content Delivery Service

The basic goal of FCAST is to transmit objects to a group of receivers in a reliable way. The receiver set MAY be restricted to a single receiver or MAY include possibly a very large number of receivers. FCAST is specified to support two forms of operation.

  1. FCAST/ALC: where the FCAST application is meant to run on top of the ALC/LCT reliable multicast transport protocol, and
  2. FCAST/NORM: where the FCAST application is meant to run on top of the NORM reliable multicast transport protocol.

This specification is designed such that both forms of operation share as much commonality as possible.

While the choice of the underlying transport protocol (i.e., ALC or NORM) and its parameters may limit the practical receiver group size, nothing in FCAST itself limits it. The transmission might be fully reliable, or only partially reliable depending upon the way ALC or NORM is used (e.g., whether FEC encoding and/or NACK-based repair requests are used or not), the way the FCAST carousel is used (e.g., whether the objects are made available for a long time span or not), and the way in which FCAST itself is employed (e.g., whether there is a session control application that might automatically extend an existing FCAST session until all receivers have received the transmitted content).

FCAST is designed to be as self-sufficient as possible, in particular in the way object meta-data is attached to object data content. However, for some uses, meta-data MAY also be communicated by an out-of-band mechanism that is out of the scope of the present document.



 TOC 

4.2.  Meta-Data Transmission

FCAST usually carries meta-data elements by prepending them to the object it refers to. As a result, a compound object is created that is composed of a header followed by the original object content. This header is itself composed of the meta-data as well as several fields, for instance to indicate the boundaries between the various parts of this compound object (Figure 1 (Compound Object composition.)).



<------------------------ Compound Object ----------------------->
+-------------------------+--------------------------------------+
|  Compound Object Header |             Object Content           |
| (can include meta-data) |       (can be encoded by FCAST)      |
+-------------------------+--------------------------------------+
 Figure 1: Compound Object composition. 

Attaching the meta-data to the object is an efficient solution, since it guaranties that meta-data be received along with the associated object, and it allows the transport of the meta-data to benefit from any transport-layer FEC erasure protection of the compound object. However a limit of this scheme, as such, is that a client does not know the meta-data of an object before begining its reception, and (in case of erasures) perhaps not until the object decoding is completed. The details of course depend upon the transport protocol and the FEC code used.

In certain use-cases, FCAST can also be associated to another in-band (e.g., via NORM INFO messages, Section 4.8 (FCAST/NORM Additional Specificities)) or out-of-band signaling mechanism. In that case, this mechanism can be used in order to carry the whole meta-data (or a subset of it), possibly ahead of time.



 TOC 

4.3.  Meta-Data Content

The meta-data associated to an object can be composed of, but are not limited to:

This list is not limited and new meta-data information can be added. For instance, when dealing with very large objects (e.g., that largely exceed the working memory of a receiver), it can be interesting to split this object into several sub-objects. When a file is split into several objects by FCAST, the meta-data includes:

When meta-data elements are communicated out-of-band, in advance of data transmission, the following pieces of information may also be useful:



 TOC 

4.4.  Carousel Transmission

A set of FCAST compound objects scheduled for transmission are considered a logical "Carousel". A single "Carousel Instance" is comprised of a fixed set of compound objects. Whenever the FCAST application needs to add new compound objects to or remove old compound objects from the transmission set, a new Carousel Instance is defined since the set of compound objects changes.

For a given Carousel Instance, one or more transmission cycles are possible. During each cycle, all of the compound objects comprising the Carousel are sent. By default, each object is transmitted once per cycle. However, in order to allow different levels of priority, some objects MAY be transmitted more often that others during a cycle, and/or benefit from higher FEC protection than others. This can be the case for instance of the CIO objects (Section 4.5 (Carousel Instance Object)). For some FCAST usage (e.g., a unidirectional "push" mode), a Carousel Instance may be associated to a single transmission cycle. In other cases it may be associated to a large number of transmission cycles (e.g., in "on-demand" mode, where objects are made available for download during a long period of time).



 TOC 

4.5.  Carousel Instance Object

The FCAST sender CAN transmit an OPTIONAL Carousel Instance Object (CIO). The CIO carries the list of the compound objects that are part of a given Carousel Instance, by specifying their respective Transmission Object Identifiers (TOI). However the CIO does not describe the objects themselves (i.e., there is no meta-data). Additionally, the CIO includes a "Complete" flag that is used to indicate that no further modification to the enclosed list will be done in the future. Finally, the CIO includes a Carousel Instance ID that identifies the Carousel Instance it pertains to.

There is no reserved TOI value for the CIO itself, since this object is regarded by ALC/LCT or NORM as a standard object. On the opposite, the nature of this object (CIO) is indicated by means of a specific compound object header field (the "I" flag) so that it can be recognized and processed by the FCAST application as needed. A direct consequence is the following: since a receiver does not know in advance which TOI will be used for the following CIO (i.e., with dynamic sessions), he MUST NOT filter out packets that are not in the CIO's TOI list. Said differently, the goal of CIO is not to setup ALC or NORM packet filters (this mechanism would not be secure in any case).

The use of a CIO remains optional. If it is not used, then the clients progressively learn what files are part of the carousel instance by receiving ALC or NORM packets with new TOIs. However using a CIO has several benefits:

During idle periods, when the carousel instance does not contain any object, a CIO with an empty TOI list MAY be transmitted. In that case, a new carousel instance ID MUST be used to differentiate this (empty) carousel instance from the other ones. This mechanism can be useful to inform the receivers that:

The decisions of whether a CIO should be used or not, how often and when a CIO should be sent, are left to the sender and depend on many parameters, including the target use case and the session dynamics. For instance it may be appropriate to send a CIO at the beginning of each new carousel instance, and then periodically. These operational aspects are out of the scope of the present document.



 TOC 

4.6.  Compound Object Identification

The FCAST compound objects are directly associated with the object-based transport service that the ALC and NORM protocols provide. In each of these protocols, the messages containing transport object content are labeled with a numeric transport object identifier (i.e., the ALC TOI and the NORM NormTransportId). For purposes of this document, this identifier in either case (ALC or NORM) is referred to as the TOI.

There are several differences between ALC and NORM:

In both NORM and ALC, it is possible that the transport identification space may eventually wrap for long-lived sessions (especially with NORM where this phenomenon is expected to happen more frequently). This can possibly introduce some ambiguity in FCAST object identification if a sender retains some older objects in newer Carousel Instances with updated object sets. Thus, when an updated object set for a new Carousel Instance transport identifiers that exceed one-half of the TOI sequence space (or otherwise exceed the sender repair window capability in the case of NORM) it may be necessary to re-enqueue old objects within the Carousel with new TOI to stay within transport identifier limits. To allow receivers to properly combine new transport symbols for any older objects with newly-assigned TOIs to achieve reliable transfer, a mechanism is required to equate the object(s) with new TOI with the older object TOI.

*** Editor's note: This mechanism is TBD. Two complementary possibilities are: (1) if the meta-data are processed rapidly (e.g., by using NORM-INFO messages), a receiver quickly detects that both objects are the same and take appropriate measures; (2) we can also add a way, in the CIO, to say that {TOI, current CI} == {prev_TOI, prev CI}.



 TOC 

4.7.  FCAST/ALC Additional Specificities

There are no additional detail or option for FCAST/ALC operation.



 TOC 

4.8.  FCAST/NORM Additional Specificities

The NORM Protocol provides a few additional capabilities that can be used to specifically support FCAST operation:

  1. The NORM_INFO message for conveying "out-of-band" content with respect to a given transport object MAY be used to provide the compound object header, and in particular the object meta-data, to the receivers. Note that the availability of NORM_INFO for a given object is signaled through the use of a dedicated flag in the NORM_DATA message header. Additionally, NORM's NACK-based repair request signaling allows a receiver to request separately and quickly an object's NORM_INFO content. However, the limitation here is that the Compound Object Header and its meta-data MUST fit within the byte size limit defined by the NORM sender's configured "segment size" (typically a little less than the network MTU);
  2. The NORM_CMD(SQUELCH) messages are used by the NORM protocol sender to inform receivers of objects that have been canceled when receivers make repair requests for such invalid objects. Along with the CIO mechanism, a receiver has an efficient and reliable way to discover old objects that have been removed from the carousel instance;
  3. NORM also supports an optional positive acknowledgment mechanism that can be used for small-scale multicast receiver group sizes. Also, it may be possible in some cases for the sender to infer, after some period without receiving NACKs at the end of its transmission that the receiver set has fully received the transmitted content. In particular, if the sender completes its end-of-transmission series of NORM_CMD(FLUSH) messages without receiving repair requests from the group, it may have some assurance that the receiver set has received the content prior to that point. These mechanisms are likely to help FCAST in achieving fully reliable transmissions;

When NORM_INFO is used with FCAST/NORM, the NORM_INFO content MUST contain the FCAST Compound Object Header and meta-data for that object, or a subset of the meta-data. In this case, the compound object sent in the regular NORM_DATA packets MAY be streamlined in order to contain no meta-data at all, or only the subset of the meta-data that is not carried in the NORM_INFO message.

It should also be noted that the NORM_INFO message header may carry the EXT_FTI extension. The reliable delivery of the NORM_INFO content allows the individual objects' FEC Transmission Information to be provided to the receivers without burdening every packet (i.e. NORM_DATA messages) with this additional, but important, content. Examples are provided in Appendix A (FCAST Examples).



 TOC 

4.9.  FCAST Sender Behavior

The following operations take place at a sender:

  1. The user (or another application) selects a set of objects (e.g., files) to deliver and submits them, along with their meta-data, to the FCAST application;
  2. For each object, FCAST creates the compound object and registers this latter in the carousel instance.
  3. The user then informs FCAST when all the objects of the set have been submitted. If the user knows that no new object will be submitted in the future (i.e., if the session's content is now complete), the user informs FCAST. Finally, the user specifies how many transmission cycles are desired (this number may be infinite);
  4. At this point, the FCAST application knows the full list of compound objects that are part of the carousel instance and can create a CIO if desired, possibly with the complete flag set;
  5. The FCAST application can now define a transmission schedule of these compound objects, including the optional CIO(s). This schedule defines in which order the packets of the various compound objects should be sent. This document does not specify any scheme. This is left to the developer within the provisions of the underlying ALC or NORM protocol used and the knowledge of the target use-case.
  6. The FCAST application then starts the carousel transmission, for the number of cycles specified. Transmissions take place until: Then continue at Step 1 above.


 TOC 

4.10.  FCAST Receiver Behavior

The following operations take place at an FCAST receiver:

  1. The receiver joins the session and collects symbols;
  2. If the header portion of a compound object is entirely received (which may happen before receiving the entire object with some ALC/NORM transport configurations), the receiver processes the meta-data and chooses to continue to receive the object content or not;
  3. When a compound object has been entirely received, the receiver processes the header, retrieves the object meta-data, perhaps decodes the meta-data, and processes the object accordingly;
  4. When a CIO is received, which is indicated by the 'I' flag set in the compound object header, the receiver decodes the CIO, and retrieves the list of objects that are part of the current carousel instance. This list CAN be used to remove objects sent in a previous carousel instance that might not have been totally decoded and that are no longer part of the current carousel instance;
  5. When a receiver has received a CIO with the "Complete" flag set, and has successfully received all the objects of the current carousel instance, it can safely exit from the current FCAST session;
  6. Otherwise continue at Step 2 above.


 TOC 

5.  FCAST Specifications

This section details the technical aspects of FCAST.



 TOC 

5.1.  Compound Object Header Format

In an FCAST session, compound objects are constructed by prepending the Compound Object Header (which may include meta-data) before the original object data content (Figure 2 (Compound Object Header with Meta-Data.)).



 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ^
|rsv|G|I|MDF|MDE|                 Header Length                 |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|            Checksum           |                               |  h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |  d
|         Object Meta-Data (optional, variable length)          |  r
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                               |      Padding (optional)       |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  v
|                                                               |
.          Object Data (optional, variable length)              .
.                                                               .
.                                                               .
 Figure 2: Compound Object Header with Meta-Data. 

The Compound Object Header fields are:

FieldDescription
Reserved 2-bit field set to 0 in this specification and reserved for future use.
G 1-bit field that, when set to 1, indicates that the checksum encompasses the whole compound object (Global checksum). When set to 0, this field indicates that the checksum encompasses only the compound object header.
I 1-bit field that, when set to 1, indicates the object is a Carousel Instance Object (CIO). When set to 0, this field indicates that the transported object is a standard object.
Meta-Data Format (MDFmt) 2-bit field that defines the format of the object meta-data (see Section 7 (IANA Considerations)). An HTTP/1.1 metainformation format [RFC2068] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” January 1997.) MUST be supported and is associated to value 0. Other formats (e.g., XML) MAY be defined in the future.
Meta-Data Encoding (MDEnc) 2-bit field that defines the optional encoding of the Object Meta-Data field (see Section 7 (IANA Considerations)). By default, a plain text encoding is used and is associated to value 0. Gzip encoding MUST also be supported and is associated to value 1. Other encodings MAY be defined in the future.
Header Length 24-bit field indicating total length (in bytes) of all fields of the Compound Object Header, except the optional padding. A header length field set to value 6 means that there is no meta-data included. When this size is not multiple to 32 bits words, padding is added. It should be noted that the meta-data field maximum size is equal to 2^24 - 6 bytes.
Checksum 16-bit field that contains the checksum computed over either the whole compound object (when G is set to 1), or over the compound object header (when G is set to 0), using the algorithm specified for TCP in RFC793. More precisely, the checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words to be considered. If a segment contains an odd number of octets to be checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes (this pad is not transmitted). While computing the checksum, the checksum field itself is set to zero.
Object Meta-Data Optional, variable length field that contains the meta-data associated to the object, either in plain text or encoded, as specified by the MDEnc field. The Meta-Data is NULL-terminated plain text that follows the "TYPE" ":" "VALUE" "<CR-LF>" format used in HTTP/1.1 for metainformation [RFC2068] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” January 1997.). The various meta-data items can appear in any order. The associated string, when non empty, MUST be NULL-terminated. When no meta-data is communicated, this field MUST be empty.
Padding Optional, variable length field of zero-value bytes to align the start of the object data content to 32-bit boundary. Padding is only used when the header length value, in bytes, is not multiple of 4.

The Compound Object Header is then followed by the Object Data, i.e., the original object possibly encoded by FCAST. Note that the length of this content is the transported object length (e.g., as specified by the FEC OTI) minus the Header Length.



 TOC 

5.2.  Carousel Instance Object Format

The format of the CIO, which is a particular compound object, is given in Figure 3 (Carousel Instance Object Format.).



 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ^
|rsv|G|1|MDF|MDE|                 Header Length                 |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|            Checksum           |                               |  h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |  d
|         Object Meta-Data (optional, variable length)          |  r
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                               |      Padding (optional)       |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  v
.                                                               .  ^
.                Object List (variable length)                  .  |
.                                                               .  o
.                                               +-+-+-+-+-+-+-+-+  b
.                                               |                  j
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                  v
 Figure 3: Carousel Instance Object Format. 

Because the CIO is transmitted as a special compound object, the following CIO-specific meta-data entries are defined:

Additionally, the following standard meta-data entries are often used (Section 4.3 (Meta-Data Content)):

An empty Object List is valid and indicates that the current carousel instance does not include any object (Section 4.5 (Carousel Instance Object)). This can be specified by using the following meta-data entry:

        Content-Length: 0

or simply by leaving the Object List empty. In the latter case, the transported object length (e.g., as specified by the FEC OTI) minus the Header Length equals zero.

The non-encoded (i.e., plain text) Object List, when non empty, is a NULL-terminated ASCII string. It contains the list of TOIs included in the current carousel instance, specified either as the individual TOIs of each object, or as TOI intervals, or any combination. The format of the ASCII string is a comma-separated list of individual "TOI" values or "TOI_a-TOI_b" elements. This latter case means that all values between TOI_a and TOI_b, inclusive, are part of the list. We further require that TOI_a be strictly inferior to TOI_b. If a TOI wrapping to 0 occurs in an interval, then two TOI intervals MUST be specified, TOI_a-MAX_TOI and 0-TOI_b.

The ABNF specification is the following:

cio-list   =  *(list-elem *( "," list-elem))
list-elem  =  toi-value / toi-interval
toi-value  =  1*DIGIT
toi-interval  =  toi-value "-" toi-value
              ; additionally, the first toi-value MUST be
              ; strictly inferior to the second toi-value
DIGIT      =  %x30-39
              ; a digit between O and 9, inclusive

For processing reasons, all the TOI values in the list MUST be given in increasing order. However a receiver MUST be able to handle non-monotonically increasing values. Furthermore, a given TOI value MUST NOT be included multiple times in the list.



 TOC 

6.  Security Considerations



 TOC 

6.1.  Problem Statement

A content delivery system is potentially subject to attacks. Attacks may target:

These attacks can be launched either:

In the following sections we provide more details on these possible attacks and sketch some possible counter-measures.



 TOC 

6.2.  Attacks Against the Data Flow

Let us consider attacks against the data flow first. At least, the following types of attacks exist:



 TOC 

6.2.1.  Access to Confidential Objects

Access control to the object being transmitted is typically provided by means of encryption. This encryption can be done over the whole object (e.g., by the content provider, before submitting the object to FCAST), or be done on a packet per packet basis (e.g., when IPSec/ESP is used [RFC4303] (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.)). If confidentiality is a concern, it is RECOMMENDED that one of these solutions be used.



 TOC 

6.2.2.  Object Corruption

Protection against corruptions (e.g., in case of forged packets) is achieved by means of a content integrity verification/sender authentication scheme. This service can be provided at the object level, but in that case a receiver has no way to identify which symbol(s) is(are) corrupted if the object is detected as corrupted. This service can also be provided at the packet level. In this case, after removing all corrupted packets, the file may be in some cases recovered. Several techniques can provide this content integrity/sender authentication service:

Techniques relying on public key cryptography (digital signatures and TESLA during the bootstrap process, when used) require that public keys be securely associated to the entities. This can be achieved by a Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by pre-distributing securely the public keys of each group member.

Techniques relying on symmetric key cryptography (Group MAC) require that a secret key be shared by all group members. This can be achieved by means of a group key management protocol, or simply by pre-distributing securely the secret key (but this manual solution has many limitations).

It is up to the developer and deployer, who know the security requirements and features of the target application area, to define which solution is the most appropriate. In any case, whenever there is any concern of the threat of file corruption, it is RECOMMENDED that at least one of these techniques be used.



 TOC 

6.3.  Attacks Against the Session Control Parameters and Associated Building Blocks

Let us now consider attacks against the session control parameters and the associated building blocks. The attacker has at least the following opportunities to launch an attack:

The latter one is particularly true with the multiple rate congestion control protocol which may be required.

The consequences of these attacks are potentially serious, since they can compromise the behavior of content delivery system or even compromise the network itself.



 TOC 

6.3.1.  Attacks Against the Session Description

An FCAST receiver may potentially obtain an incorrect Session Description for the session. The consequence of this is that legitimate receivers with the wrong Session Description are unable to correctly receive the session content, or that receivers inadvertently try to receive at a much higher rate than they are capable of, thereby possibly disrupting other traffic in the network.

To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect Session Descriptions. One such measure is the sender authentication to ensure that receivers only accept legitimate Session Descriptions from authorized senders. How these measures are archived is outside the scope of this document since this session description is usually carried out-of-band.



 TOC 

6.3.2.  Attacks Against the FCAST CIO

Corrupting the FCAST CIO is one way to create a Denial of Service attack. For example, the attacker can set the "Complete" flag to make the receivers believe that no further modification will be done.

It is therefore RECOMMENDED that measures be taken to guarantee the integrity and to check the sender's identity of the CIO. To that purpose, one of the counter-measures mentioned above (Section 6.2.2 (Object Corruption)) SHOULD be used. These measures will either be applied on a packet level, or globally over the whole CIO object. When there is no packet level integrity verification scheme, it is RECOMMENDED to digitally sign the CIO.



 TOC 

6.3.3.  Attacks Against the Object Meta-Data

Corrupting the object meta-data is another way to create a Denial of Service attack. For example, the attacker changes the MD5 sum associated to a file. This possibly leads a receiver to reject the files received, no matter whether the files have been correctly received or not. When the meta-data are appended to the object, corrupting the meta-data means that the compound object will be corrupted.

It is therefore RECOMMENDED that measures be taken to guarantee the integrity and to check the sender's identity of the compound object. To that purpose, one of the counter-measures mentioned above (Section 6.2.2 (Object Corruption)) SHOULD be used. These measures will either be applied on a packet level, or globally over the whole compound object. When there is no packet level integrity verification scheme, it is RECOMMENDED to digitally sign the compound object.



 TOC 

6.3.4.  Attacks Against the ALC/LCT Parameters

By corrupting the ALC/LCT header (or header extensions) one can execute attacks on the underlying ALC/LCT implementation. For example, sending forged ALC packets with the Close Session flag (A) set one can lead the receiver to prematurely close the session. Similarly, sending forged ALC packets with the Close Object flag (B) set one can lead the receiver to prematurely give up the reception of an object.

It is therefore RECOMMENDED that measures be taken to guarantee the integrity and to check the sender's identity of each ALC packet received. To that purpose, one of the counter-measures mentioned above (Section 6.2.2 (Object Corruption)) SHOULD be used.



 TOC 

6.3.5.  Attacks Against the Associated Building Blocks

Let us first focus on the congestion control building block that may be used in the ALC session. A receiver with an incorrect or corrupted implementation of the multiple rate congestion control building block may affect the health of the network in the path between the sender and the receiver. That may also affect the reception rates of other receivers who joined the session.

When congestion control building block is applied with FCAST, it is therefore RECOMMENDED that receivers be required to identify themselves as legitimate before they receive the Session Description needed to join the session. How receivers identify themselves as legitimate is outside the scope of this document. If authenticating a receiver does not prevent this latter to launch an attack, it will enable the network operator to identify him and to take counter-measures.

When congestion control building block is applied with FCAST/ALC, it is also RECOMMENDED that a packet level authentication scheme be used, as explained in Section 6.2.2 (Object Corruption). Some of them, like TESLA, only provide a delayed authentication service, whereas congestion control requires a rapid reaction. It is therefore RECOMMENDED [2] that a receiver using TESLA quickly reduces its subscription level when the receiver believes that a congestion did occur, even if the packet has not yet been authenticated. Therefore TESLA will not prevent DoS attacks where an attacker makes the receiver believe that a congestion occurred. This is an issue for the receiver, but this will not compromise the network since no congestion actually occurred. Other authentication methods that do not feature this delayed authentication could be preferred, or a group MAC scheme could be used in parallel to TESLA to reduce the probability of this attack.



 TOC 

6.4.  Other Security Considerations

Lastly, we note that the security considerations that apply to, and are described in, ALC [2], LCT [3] and FEC [4] also apply to FCAST as FCAST builds on those specifications. In addition, any security considerations that apply to any congestion control building block used in conjunction with FCAST also applies to FCAST.



 TOC 

7.  IANA Considerations

This document requires a IANA registration for the following attributes:

Object meta-data format (MDFmt): All implementations MUST support format 0 (default).

format nameValue
as per HTTP/1.1 metainformation format 0 (default)

Object Meta-Data Encoding (MDENC): All implementations MUST support value 0 (plain-text, default) and value 1 (gzip).

NameValue
plain text 0 (default)
gzip 1



 TOC 

8.  Acknowledgments

The authors are grateful to the authors of [ALC_00] (Luby, M., Gemmell, G., Vicisano, L., Crowcroft, J., and B. Lueckenhoff, “Asynchronous Layered Coding: a Scalable Reliable Multicast Protocol,” March 2000.) for specifying the first version of FCAST/ALC. The authors are also grateful to Gorry Fairhurst for his valuable comments.



 TOC 

9.  References



 TOC 

9.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RMT-PI-ALC] Luby, M., Watson, M., and L. Vicisano, “Asynchronous Layered Coding (ALC) Protocol Instantiation,” Work in Progress, November 2007.
[RMT-BB-LCT] Luby, M., Watson, M., and L. Vicisano, “Layered Coding Transport (LCT) Building Block,” Work in Progress, July 2008.
[RMT-PI-NORM] Adamson, B., Bormann, C., Handley, M., and J. Macker, “Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol,” Work in Progress, May 2008.
[RMT-FLUTE] Paila, T., Walsh, R., Luby, M., Lehtonen, R., and V. Roca, “FLUTE - File Delivery over Unidirectional Transport,” Work in Progress, October 2007.


 TOC 

9.2. Informative References

[ALC_00] Luby, M., Gemmell, G., Vicisano, L., Crowcroft, J., and B. Lueckenhoff, “Asynchronous Layered Coding: a Scalable Reliable Multicast Protocol,”  draft-ietf-rmt-pi-alc-00.txt, March 2000.
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. Randers-Pehrson, “GZIP file format specification version 4.3,” RFC 1952, May 1996 (TXT, PS, PDF).
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2068, January 1997 (TXT).
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” RFC 2104, February 1997 (TXT).
[RFC3447] Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” RFC 3447, February 2003 (TXT).
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, “Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction,” RFC 4082, June 2005 (TXT).
[RFC4302] Kent, S., “IP Authentication Header,” RFC 4302, December 2005 (TXT).
[RFC4303] Kent, S., “IP Encapsulating Security Payload (ESP),” RFC 4303, December 2005 (TXT).


 TOC 

Appendix A.  FCAST Examples



 TOC 

A.1.  Basic Examples



 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |1|0| 0 | 0 |                   39                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Checksum           |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
.                                                               .
.       meta-data ASCII null terminated string (33 bytes)       .
.                                                               .
+                                               +-+-+-+-+-+-+-+-+
|                                               |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                         Object data                           .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 4: Compound Object Example. 

Figure 4 (Compound Object Example.) shows a regular compound object where the meta-data ASCII string, in HTTP/1.1 meta-information format (MDFmt=0) contains:

Content-Location: example.txt <CR-LF>

This string is 33 bytes long, including the NULL-termination character. There is no gzip encoding of the meta-data (MDEnc=0) and there is no Content-Length information either since this length can easily be calculated by the receiver as the FEC OTI transfer length minus the header length. Finally, the checksum encompasses the whole Compound Object (G=1).



 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |1|0| 0 | 0 |                    6                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Checksum           |            Padding            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                         Object data                           .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 5: Compound Object Example with no Meta-Data. 

Figure 5 (Compound Object Example with no Meta-Data.) shows a compound object without any meta-data. The fact there is no meta-data is indicated by the value 6 of the Header Length field.

Figure 6 (Example of CIO, in case of a static session.) shows an example CIO object, in the case of a static FCAST session, i.e., a session where the set of objects is set once and for all.



 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  0  |1| 0 | 0 |                4                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                Object List string                             .
.                                                               .
.                                               +-+-+-+-+-+-+-+-+
.                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 6: Example of CIO, in case of a static session. 

The object list contains the following string:

1,2,3,100-104,200-203,299

There are therefore a total of 3+5+4+1 = 13 objects in the carousel instance, and therefore in the FCAST session. There is no meta-data associated to this CIO. The session being static the sender did not feel the necessity to carry a Carousel Instance ID meta-data.



 TOC 

A.2.  FCAST/NORM with NORM_INFO Examples

In case of FCAST/NORM, the meta-data (or a subset of it) can be carried as part of a NORM_INFO message. In the following example we assume that the whole meta-data is carried in such a message for a certain object.

The NORM_INFO message is the following... TODO

Note that this message contains the EXT_FTI header extension to carry the FEC OTI. Two alternatives would have been to either include FEC OTI directly in the meta-data part of the NORM_INFO message, or to include an EXT_FTI header extension to all NORM_DATA packets (or a subset of them).

The FCAST compound object does not contain any meta-data and is formatted as in Figure 5 (Compound Object Example with no Meta-Data.).



 TOC 

Authors' Addresses

  Vincent Roca
  INRIA
  655, av. de l'Europe
  Inovallee; Montbonnot
  ST ISMIER cedex 38334
  France
Email:  vincent.roca@inria.fr
URI:  http://planete.inrialpes.fr/people/roca/
  
  Brian Adamson
  Naval Research Laboratory
  Washington, DC 20375
  USA
Email:  adamson@itd.nrl.navy.mil
URI:  http://cs.itd.nrl.navy.mil