tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6726

 
 
 

FLUTE - File Delivery over Unidirectional Transport

Part 2 of 2, p. 23 to 46
Prev RFC Part

 


prevText      Top      Up      ToC       Page 23 
4.  Channels, Congestion Control, and Timing

   ALC/LCT has a concept of channels and congestion control.  There are
   four scenarios in which FLUTE is envisioned to be applied.

   (a)  Use of a single channel and a single-rate congestion control
        protocol.

   (b)  Use of multiple channels and a multiple-rate congestion control
        protocol.  In this case, the FDT Instances MAY be delivered on
        more than one channel.

   (c)  Use of a single channel without congestion control supplied by
        ALC, but only when in a controlled network environment where
        flow/congestion control is being provided by other means.

   (d)  Use of multiple channels without congestion control supplied by
        ALC, but only when in a controlled network environment where
        flow/congestion control is being provided by other means.  In
        this case, the FDT Instances MAY be delivered on more than one
        channel.

   When using just one channel for a file delivery session, as in (a)
   and (c), the notion of 'prior' and 'after' are intuitively defined
   for the delivery of objects with respect to their delivery times.

   However, if multiple channels are used, as in (b) and (d), it is not
   straightforward to state that an object was delivered 'prior' to the
   other.  An object may begin to be delivered on one or more of those
   channels before the delivery of a second object begins.  However, the
   use of multiple channels/layers may mean that the delivery of the
   second object is completed before the first.  This is not a problem
   when objects are delivered sequentially using a single channel.
   Thus, if the application of FLUTE has a mandatory or critical
   requirement that the first transmission object must complete 'prior'
   to the second one, it is RECOMMENDED that only a single channel be
   used for the file delivery session.

Top      Up      ToC       Page 24 
   Furthermore, if multiple channels are used, then a receiver joined to
   the session at a low reception rate will only be joined to the lower
   layers of the session.  Thus, since the reception of FDT Instances is
   of higher priority than the reception of files (because the reception
   of files depends on the reception of an FDT Instance describing it),
   the following are RECOMMENDED:

   1.  The layers to which packets for FDT Instances are sent SHOULD NOT
       be biased towards those layers to which lower-rate receivers are
       not joined.  For example, it is okay to put all the packets for
       an FDT Instance into the lowest layer (if this layer carries
       enough packets to deliver the FDT to higher-rate receivers in a
       reasonable amount of time), but it is not okay to put all the
       packets for an FDT Instance into the higher layers that only
       higher-rate receivers will receive.

   2.  If FDT Instances are generally longer than one Encoding Symbol in
       length and some packets for FDT Instances are sent to layers that
       lower-rate receivers do not receive, an FEC encoding other than
       Compact No-Code FEC Encoding ID 0 [RFC5445] SHOULD be used to
       deliver FDT Instances.  This is because in this case, even when
       there is no packet loss in the network, a lower-rate receiver
       will not receive all packets sent for an FDT Instance.

5.  Delivering FEC Object Transmission Information

   FLUTE inherits the use of the FEC building block [RFC5052] from ALC.
   When using FLUTE for file delivery over ALC, the FEC Object
   Transmission Information MUST be delivered in-band within the file
   delivery session.  There are two methods to achieve this: the use of
   the ALC-specific LCT Header Extension EXT_FTI [RFC5775] and the use
   of the FDT.  The latter method is specified in this section.  The use
   of EXT_FTI requires repetition of the FEC Object Transmission
   Information to ensure reception (though not necessarily in every
   packet) and thus may entail higher overhead than the use of the FDT,
   but may also provide more timely delivery of the FEC Object
   Transmission Information.

   The receiver of a file delivery session MUST support delivery of FEC
   Object Transmission Information using EXT_FTI for the FDT Instances
   carried using TOI value 0.  For the TOI values other than 0, the
   receiver MUST support both methods: the use of EXT_FTI and the use of
   the FDT.

Top      Up      ToC       Page 25 
   The FEC Object Transmission Information that needs to be delivered to
   receivers MUST be exactly the same whether it is delivered using
   EXT_FTI or using the FDT (or both).  The FEC Object Transmission
   Information that MUST be delivered to receivers is defined by the FEC
   Scheme.  This section describes the delivery using the FDT.

   The FEC Object Transmission Information regarding a given TOI may be
   available from several sources.  In this case, it is RECOMMENDED that
   the receiver of the file delivery session prioritize the sources in
   the following way (in order of decreasing priority).

   1.  FEC Object Transmission Information that is available in EXT_FTI.

   2.  FEC Object Transmission Information that is available in the FDT.

   The FDT delivers FEC Object Transmission Information for each file
   using an appropriate attribute within the "FDT-Instance" or the
   "File" element of the FDT structure.

   *  "Transfer-Length" carries the "Transfer-Length" Object
      Transmission Information element defined in [RFC5052].

   *  "FEC-OTI-FEC-Encoding-ID" carries the "FEC Encoding ID" Object
      Transmission Information element defined in [RFC5052], as carried
      in the Codepoint field of the ALC/LCT header.

   *  "FEC-OTI-FEC-Instance-ID" carries the "FEC Instance ID" Object
      Transmission Information element defined in [RFC5052] for
      Under-Specified FEC Schemes.

   *  "FEC-OTI-Maximum-Source-Block-Length" carries the
      "Maximum-Source-Block-Length" Object Transmission Information
      element defined in [RFC5052], if required by the FEC Scheme.

   *  "FEC-OTI-Encoding-Symbol-Length" carries the
      "Encoding-Symbol-Length" Object Transmission Information element
      defined in [RFC5052], if required by the FEC Scheme.

   *  "FEC-OTI-Max-Number-of-Encoding-Symbols" carries the
      "Max-Number-of-Encoding-Symbols" Object Transmission Information
      element defined in [RFC5052], if required by the FEC Scheme.

   *  "FEC-OTI-Scheme-Specific-Info" carries the "encoded
      Scheme-specific FEC Object Transmission Information" as defined in
      [RFC5052], if required by the FEC Scheme.

Top      Up      ToC       Page 26 
   In FLUTE, the FEC Encoding ID (8 bits) for a given TOI MUST be
   carried in the Codepoint field of the ALC/LCT header.  When the FEC
   Object Transmission Information for this TOI is delivered through the
   FDT, then the associated "FEC-OTI-FEC-Encoding-ID" attribute and the
   Codepoint field of all packets for this TOI MUST be the same.

6.  Describing File Delivery Sessions

   To start receiving a file delivery session, the receiver needs to
   know transport parameters associated with the session.  Interpreting
   these parameters and starting the reception therefore represent the
   entry point from which thereafter the receiver operation falls into
   the scope of this specification.  According to [RFC5775], the
   transport parameters of an ALC/LCT session that the receiver needs to
   know are:

   *  The source IP address;

   *  The number of channels in the session;

   *  The destination IP address and port number for each channel in the
      session;

   *  The Transport Session Identifier (TSI) of the session;

   *  An indication that the session is a FLUTE session.  The need to
      demultiplex objects upon reception is implicit in any use of
      FLUTE, and this fulfills the ALC requirement of an indication of
      whether or not a session carries packets for more than one object
      (all FLUTE sessions carry packets for more than one object).

   Optionally, the following parameters MAY be associated with the
   session (note that the list is not exhaustive):

   *  The start time and end time of the session;

   *  FEC Encoding ID and FEC Instance ID when the default FEC Encoding
      ID 0 is not used for the delivery of the FDT;

   *  Content encoding format if optional content encoding of the FDT
      Instance is used, e.g., compression;

   *  Some information that tells receiver, in the first place, that the
      session contains files that are of interest;

   *  Definition and configuration of a congestion control mechanism for
      the session;

Top      Up      ToC       Page 27 
   *  Security parameters relevant for the session;

   *  FLUTE version number.

   It is envisioned that these parameters would be described according
   to some session description syntax (such as SDP [RFC4566] or XML
   based) and held in a file that would be acquired by the receiver
   before the FLUTE session begins by means of some transport protocol
   (such as the Session Announcement Protocol (SAP) [RFC2974], email,
   HTTP [RFC2616], SIP [RFC3261], manual preconfiguration, etc.).
   However, the way in which the receiver discovers the above-mentioned
   parameters is out of scope of this document, as it is for LCT and
   ALC.  In particular, this specification does not mandate or exclude
   any mechanism.

7.  Security Considerations

7.1.  Problem Statement

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

   *  the network (to compromise the routing infrastructure, e.g., by
      creating congestion),

   *  the Content Delivery Protocol (CDP) (e.g., to compromise the
      normal behavior of FLUTE), or

   *  the content itself (e.g., to corrupt the files being transmitted).

   These attacks can be launched either:

   *  against the data flow itself (e.g., by sending forged packets),

   *  against the session control parameters (e.g., by corrupting the
      session description, the FDT Instances, or the ALC/LCT control
      parameters) that are sent either in-band or out-of-band, or

   *  against some associated building blocks (e.g., the congestion
      control component).

   In the following sections, we provide more details on these possible
   attacks and sketch some possible countermeasures.  We provide
   recommendations in Section 7.5.

Top      Up      ToC       Page 28 
7.2.  Attacks against the Data Flow

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

   *  attacks that are meant to give access to a confidential file
      (e.g., in the case of non-free content) and

   *  attacks that try to corrupt the file being transmitted (e.g., to
      inject malicious code within a file, or to prevent a receiver from
      using a file, which is a kind of denial of service (DoS)).

7.2.1.  Access to Confidential Files

   Access control to the file being transmitted is typically provided by
   means of encryption.  This encryption can be done over the whole
   file, i.e., before applying FEC protection (e.g., by the content
   provider, before submitting the file to FLUTE), or can be done on a
   packet-by-packet basis (e.g., when IPsec/ESP [RFC4303] is used; see
   Section 7.5).  If confidentiality is a concern, it is RECOMMENDED
   that one of these solutions be used.

7.2.2.  File Corruption

   Protection against corruptions (e.g., if an attacker sends forged
   packets) is achieved by means of a content integrity verification/
   sender authentication scheme.  This service can be provided at the
   file level, i.e., before applying content encoding and FEC encoding.
   In that case, a receiver has no way to identify which symbol(s)
   is(are) corrupted if the file is detected as corrupted.  This service
   can also be provided at the packet level, i.e., after applying
   content encoding and FEC encoding, on a packet-by-packet basis.  In
   this case, after removing all corrupted packets, the file may be in
   some cases recovered from the remaining correct packets.

   Integrity protection applied at the file level has the advantage of
   lower overhead, since only relatively few bits are added to provide
   the integrity protection compared to the file size.  However, it has
   the disadvantage that it cannot distinguish between correct packets
   and corrupt packets, and therefore correct packets, which may form
   the majority of packets received, may be unusable.  Integrity
   protection applied at the packet level has the advantage that it can
   distinguish between correct and corrupt packets, at the cost of
   additional per-packet overhead.

Top      Up      ToC       Page 29 
   Several techniques can provide this source authentication/content
   integrity service:

   *  At the file level, the file MAY be digitally signed (e.g., by
      using RSA Probabilistic Signature Scheme Public-Key Cryptography
      Standards version 1.5 (RSASSA-PKCS1-v1_5) [RFC3447]).  This
      signature enables a receiver to check the file's integrity once
      the file has been fully decoded.  Even if digital signatures are
      computationally expensive, this calculation occurs only once per
      file, which is usually acceptable.

   *  At the packet level, each packet can be digitally signed
      [RFC6584].  A major limitation is the high computational and
      transmission overheads that this solution requires.  To avoid this
      problem, the signature may span a set of symbols (instead of a
      single one) in order to amortize the signature calculation, but if
      a single symbol is missing, the integrity of the whole set cannot
      be checked.

   *  At the packet level, a Group-Keyed Message Authentication Code
      (MAC) [RFC2104] [RFC6584] scheme can be used; an example is using
      HMAC-SHA-256 with a secret key shared by all the group members,
      senders, and receivers.  This technique creates a
      cryptographically secured digest of a packet that is sent along
      with the packet.  The Group-Keyed MAC scheme does not create
      prohibitive processing load or transmission overhead, but it has a
      major limitation: it only provides a group authentication/
      integrity service, since all group members share the same secret
      group key, which means that each member can send a forged packet.
      It is therefore restricted to situations where group members are
      fully trusted (or in association with another technique as a
      pre-check).

   *  At the packet level, Timed Efficient Stream Loss-Tolerant
      Authentication (TESLA) [RFC4082] [RFC5776] is an attractive
      solution that is robust to losses, provides a true authentication/
      integrity service, and does not create any prohibitive processing
      load or transmission overhead.  However, checking a packet
      requires a small delay (a second or more) after its reception.

   *  At the packet level, IPsec/ESP [RFC4303] can be used to check the
      integrity and authenticate the sender of all the packets being
      exchanged in a session (see Section 7.5).

   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

Top      Up      ToC       Page 30 
   a Public Key Infrastructure (PKI), or by a Pretty Good Privacy (PGP)
   Web of Trust, or by pre-distributing the public keys of each group
   member.

   Techniques relying on symmetric key cryptography (Group-Keyed 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 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.  Nonetheless, in case there
   is any concern of the threat of file corruption, it is RECOMMENDED
   that at least one of these techniques be used.

7.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 attack can target the session description,

   *  the attack can target the FDT Instances,

   *  the attack can target the ALC/LCT parameters, carried within the
      LCT header, or

   *  the attack can target the FLUTE associated building blocks (e.g.,
      the multiple-rate congestion control protocol).

   The consequences of these attacks are potentially serious, since they
   might compromise the behavior of the content delivery system itself.

7.3.1.  Attacks against the Session Description

   A FLUTE 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 source authentication to ensure that receivers only

Top      Up      ToC       Page 31 
   accept legitimate session descriptions from authorized senders.  How
   these measures are achieved is outside the scope of this document,
   since this session description is usually carried out-of-band.

7.3.2.  Attacks against the FDT Instances

   Corrupting the FDT Instances is one way to create a DoS 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.

   Corrupting the FDT Instances is also a way to make the reception
   process more costly than it should be.  This can be achieved by
   changing the FEC Object Transmission Information when the FEC Object
   Transmission Information is included in the FDT Instance.  For
   example, an attacker may corrupt the FDT Instance in such a way that
   Reed-Solomon over GF(2^^16) would be used instead of GF(2^^8) with
   FEC Encoding ID 2.  This may significantly increase the processing
   load while compromising FEC decoding.

   More generally, because FDT Instance data is structured using the XML
   language by means of an XML media type, many of the security
   considerations described in [RFC3023] and [RFC3470] also apply to
   such data.

   It is therefore RECOMMENDED that measures be taken to guarantee the
   integrity and to check the sender's identity of the FDT Instances.
   To that purpose, one of the countermeasures mentioned above
   (Section 7.2.2) SHOULD be used.  These measures will either be
   applied on a packet level or globally over the whole FDT Instance
   object.  Additionally, XML digital signatures [RFC3275] are a way to
   protect the FDT Instance by digitally signing it.  When there is no
   packet-level integrity verification scheme, it is RECOMMENDED to rely
   on XML digital signatures of the FDT Instances.

7.3.3.  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 to one can lead the receiver to prematurely close the session.
   Similarly, sending forged ALC packets with the Close Object flag (B)
   set to one can lead the receiver to prematurely give up the reception
   of an object.

Top      Up      ToC       Page 32 
   It is therefore RECOMMENDED that measures be taken to guarantee the
   integrity and to check the sender's identity of the ALC packets
   received.  To that purpose, one of the countermeasures mentioned
   above (Section 7.2.2) SHOULD be used.

7.3.4.  Attacks against the Associated Building Blocks

   Let us first focus on the congestion control building block, which
   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 the congestion control building block is applied with FLUTE, it
   is 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 receiver from launching an attack, this
   authentication will enable the network operator to identify him and
   to take countermeasures.

   When the congestion control building block is applied with FLUTE, it
   is also RECOMMENDED that a packet-level authentication scheme be
   used, as explained in Section 7.2.2.  Some of them, like TESLA, only
   provide a delayed authentication service, whereas congestion control
   requires a rapid reaction.  It is therefore RECOMMENDED [RFC5775]
   that a receiver using TESLA quickly reduce its subscription level
   when the receiver believes that 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
   congestion occurred.  This is an issue for the receiver, but this
   will not compromise the network.  Other authentication methods that
   do not feature this delayed authentication could be preferred, or a
   Group-Keyed MAC scheme could be used in parallel with TESLA to
   prevent attacks launched from outside of the group.

7.4.  Other Security Considerations

   The security considerations that apply to, and are described in, ALC
   [RFC5775], LCT [RFC5651], and FEC [RFC5052] also apply to FLUTE, as
   FLUTE builds on those specifications.  In addition, any security
   considerations that apply to any congestion control building block
   used in conjunction with FLUTE also apply to FLUTE.

Top      Up      ToC       Page 33 
   Even if FLUTE defines a purely unidirectional delivery service,
   without any feedback information that would be sent to the sender,
   security considerations MAY require bidirectional communications.
   For instance, if an automated key management scheme is used, a
   bidirectional point-to-point channel is often needed to establish a
   shared secret between each receiver and the sender.  Each shared
   secret can then be used to distribute additional keys to the
   associated receiver (e.g., traffic encryption keys).

   As an example, [MBMSsecurity] details a complete security framework
   for the Third Generation Partnership Project (3GPP) Multimedia
   Broadcast/Multicast Service (MBMS) that relies on FLUTE/ALC for
   Download Sessions.  It relies on bidirectional point-to-point
   communications for User Equipment authentication and for key
   distribution, using the Multimedia Internet KEYing (MIKEY) protocol
   [RFC3830].  Because this security framework is specific to this use
   case, it cannot be reused as such for generic security
   recommendations in this specification.  Instead, the following
   section introduces minimum security recommendations.

7.5.  Minimum Security Recommendations

   We now introduce a mandatory-to-implement, but not necessarily to
   use, security configuration, in the sense of [RFC3365].  Since FLUTE
   relies on ALC/LCT, it inherits the "baseline secure ALC operation" of
   [RFC5775].  More precisely, security is achieved by means of IPsec/
   ESP in transport mode.  [RFC4303] explains that ESP can be used to
   potentially provide confidentiality, data origin authentication,
   content integrity, anti-replay, and (limited) traffic flow
   confidentiality.  [RFC5775] specifies that the data origin
   authentication, content integrity, and anti-replay services SHALL be
   supported, and that the confidentiality service is RECOMMENDED.  If a
   short-lived session MAY rely on manual keying, it is also RECOMMENDED
   that an automated key management scheme be used, especially in the
   case of long-lived sessions.

   Therefore, the RECOMMENDED solution for FLUTE provides per-packet
   security, with data origin authentication, integrity verification,
   and anti-replay.  This is sufficient to prevent most of the in-band
   attacks listed above.  If confidentiality is required, a per-packet
   encryption SHOULD also be used.

Top      Up      ToC       Page 34 
8.  IANA Considerations

   This specification contains five separate items upon which IANA has
   taken action:

   1.  Registration of the FDT Instance XML Namespace.

   2.  Registration of the FDT Instance XML Schema.

   3.  Registration of the application/fdt+xml Media Type.

   4.  Registration of the Content Encoding Algorithms.

   5.  Registration of two LCT Header Extension Types (EXT_FDT and
       EXT_CENC).

8.1.  Registration of the FDT Instance XML Namespace

   IANA has registered the following new XML Namespace in the IETF XML
   "ns" registry [RFC3688] at
   http://www.iana.org/assignments/xml-registry/ns.html.

   URI: urn:ietf:params:xml:ns:fdt

   Registrant Contact: Toni Paila (toni.paila@gmail.com)

   XML: N/A

8.2.  Registration of the FDT Instance XML Schema

   IANA has registered the following in the IETF XML "schema" registry
   [RFC3688] at
   http://www.iana.org/assignments/xml-registry/schema.html.

   URI: urn:ietf:params:xml:schema:fdt

   Registrant Contact: Toni Paila (toni.paila@gmail.com)

   XML: The XML Schema specified in Section 3.4.2

Top      Up      ToC       Page 35 
8.3.  Registration of the application/fdt+xml Media Type

   IANA has registered the following in the "Application Media Types"
   registry at http://www.iana.org/assignments/media-types/application/.

   Type name: application

   Subtype name: fdt+xml

   Required parameters: none

   Optional parameters: charset="utf-8"

   Encoding considerations: binary (the FLUTE file delivery protocol
   does not impose any restriction on the objects it carries and in
   particular on the FDT Instance itself)

   Restrictions on usage: none

   Security considerations: fdt+xml data is passive and does not
   generally represent a unique or new security threat.  However, there
   is some risk in sharing any kind of data, in that unintentional
   information may be exposed, and that risk applies to fdt+xml data as
   well.

   Interoperability considerations: None

   Published specification: [RFC6726], especially noting Section 3.4.2.
   The specified FDT Instance functions as an actual media format of use
   to the general Internet community, and thus media type registration
   under the Standards Tree is appropriate to maximize interoperability.

   Applications that use this media type: file and object delivery
   applications and protocols (e.g., FLUTE).

   Additional information:

       Magic number(s): none
       File extension(s): ".fdt" (e.g., if there is a need to store an
                          FDT Instance as a file)
       Macintosh File Type Code(s): none

   Person and email address to contact for further information:
   Toni Paila (toni.paila@gmail.com)

   Intended usage: Common

   Author/Change controller: IETF

Top      Up      ToC       Page 36 
8.4.  Creation of the FLUTE Content Encoding Algorithms Registry

   IANA has created a new registry, "FLUTE Content Encoding Algorithms",
   with a reference to [RFC6726]; see Section 3.4.3.  The registry
   entries consist of a numeric value from 0 to 255, inclusive, and may
   be registered using the Specification Required policy [RFC5226].

   The initial contents of the registry are as follows, with unspecified
   values available for new registrations:

                  +-------+----------------+-----------+
                  | Value | Algorithm Name | Reference |
                  +-------+----------------+-----------+
                  |   0   |      null      | [RFC6726] |
                  |   1   |      ZLIB      | [RFC1950] |
                  |   2   |     DEFLATE    | [RFC1951] |
                  |   3   |      GZIP      | [RFC1952] |
                  +-------+----------------+-----------+

8.5.  Registration of LCT Header Extension Types

   IANA has registered two new entries in the "Layered Coding Transport
   (LCT) Header Extension Types" registry [RFC5651], as follows:

              +--------+----------+-------------------------+
              | Number |   Name   |        Reference        |
              +--------+----------+-------------------------+
              |   192  |  EXT_FDT | [RFC6726] Section 3.4.1 |
              |   193  | EXT_CENC | [RFC6726] Section 3.4.3 |
              +--------+----------+-------------------------+

9.  Acknowledgments

   The following persons have contributed to this specification: Brian
   Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma,
   Topi Pohjolainen, Lorenzo Vicisano, Mark Watson, David Harrington,
   Ben Campbell, Stephen Farrell, Robert Sparks, Ronald Bonica, Francis
   Dupont, Peter Saint-Andre, Don Gillies, and Barry Leiba.  The authors
   would like to thank all the contributors for their valuable work in
   reviewing and providing feedback regarding this specification.

Top      Up      ToC       Page 37 
10.  Contributors

   Jani Peltotalo
   Tampere University of Technology
   P.O. Box 553 (Korkeakoulunkatu 1)
   Tampere FIN-33101
   Finland
   EMail: jani.peltotalo@tut.fi

   Sami Peltotalo
   Tampere University of Technology
   P.O. Box 553 (Korkeakoulunkatu 1)
   Tampere FIN-33101
   Finland
   EMail: sami.peltotalo@tut.fi

   Magnus Westerlund
   Ericsson Research
   Ericsson AB
   SE-164 80 Stockholm
   Sweden
   EMail: magnus.westerlund@ericsson.com

   Thorsten Lohmar
   Ericsson Research (EDD)
   Ericsson Allee 1
   52134 Herzogenrath
   Germany
   EMail: thorsten.lohmar@ericsson.com

11.  Change Log

11.1.  RFC 3926 to This Document

   Incremented the FLUTE protocol version from 1 to 2, due to concerns
   about backwards compatibility.  For instance, the LCT header changed
   between RFC 3451 and [RFC5651].  In RFC 3451, the T and R fields of
   the LCT header indicate the presence of Sender Current Time and
   Expected Residual Time, respectively.  In [RFC5651], these fields
   MUST be set to zero and MUST be ignored by receivers (instead, the
   EXT_TIME Header Extensions can convey this information if needed).
   Thus, [RFC5651] is not backwards compatible with RFC 3451, even
   though both use LCT version 1.  FLUTE version 1 as specified in
   [RFC3926] MUST use RFC 3451.  FLUTE version 2 as specified in this
   document MUST use [RFC5651].  Therefore, an implementation that
   relies on [RFC3926] and RFC 3451 will not be backwards compatible
   with FLUTE as specified in this document.

Top      Up      ToC       Page 38 
   Updated dependencies to other RFCs to revised versions; e.g., changed
   ALC reference from RFC 3450 to [RFC5775], changed LCT reference from
   RFC 3451 to [RFC5651], etc.

   Added clarification for the use of FLUTE for unicast communications
   in Section 1.1.4.

   Clarified how to reliably deliver the FDT in Section 3.3 and the
   possibility of using out-of-band delivery of FDT information.

   Clarified how to address FDT Instance expiration time wraparound with
   the notion of the NTPv4 "epoch" in Section 3.3.

   Clarified what should be considered erroneous situations in
   Section 3.4.1 (definition of FDT Instance ID).  In particular, a
   receiver MUST be ready to handle FDT Instance ID wraparounds and
   missing FDT Instances.

   Updated Section 7.5 to define IPsec/ESP as a mandatory-to-implement
   security solution.

   Removed the 'Statement of Intent' from Section 1.  The statement of
   intent was meant to clarify the "Experimental" status of [RFC3926].
   It does not apply to this document.

   Added clarification of "XML-DSIG" near the end of Section 3.

   In Section 3.2, replaced "complete FDT" with text that is more
   descriptive.

   Clarified Figure 1 with regard to "Encoding Symbol(s) for FDT
   Instance".

   Clarified the text regarding FDT Instance ID wraparound at the end of
   Section 3.4.1.

   Clarified "complete FDT" in Section 3.4.2.

   Added semantics for the case where two TOIs refer to the same
   Content-Location.  It is now in line with the way that 3GPP and
   Digital Video Broadcasting (DVB) standards interpret this case.

   In Section 3.4.2, the XML Schema of the FDT Instance was modified per
   advice from various sources.  For example, extension by element was
   missing but is now supported.  Also, the namespace definition was
   changed to URN format.

   Clarified FDT-schema extensibility at the end of Section 3.4.2.

Top      Up      ToC       Page 39 
   The CENC value allocation has been added at the end of Section 3.4.3.

   Section 5 has been modified so that EXT_FTI and the FEC issues were
   replaced by a reference to the ALC specification [RFC5775].

   Added a clarifying paragraph on the use of the Codepoint field at the
   end of Section 5.

   Reworked Section 8 -- IANA Considerations; it now contains six IANA
   registration requests:

   *  Registration of the FDT Instance XML Namespace.

   *  Registration of the FDT Instance XML Schema.

   *  Registration of the application/fdt+xml Media Type.

   *  Registration of the Content Encoding Algorithms.

   *  Registration of two LCT Header Extension Types and corresponding
      values in the LCT Header Extension Types Registry (192 for EXT_FDT
      and 193 for EXT_CENC).

   Added Section 10 -- Contributors.

   Revised lists of both Normative and Informative references.

   Added a clarification that the receiver should ignore reserved bits
   of Header Extension type 193 upon reception.

   Elaborated on what kinds of networks cannot support FLUTE congestion
   control (Section 1.1.4).

   In Section 3.2, changed "several" (meaning 3-n vs. "couple" = 2) to
   "multiple" (meaning 2-n).

   Moved the requirement in Section 3.3 (to send FDT more reliably than
   files) to a bulleted RECOMMENDED requirement, making check-off easier
   for testers.

   In Section 3.3, sharpened the definition that future FDT file
   instances can "augment" (meaning enhance) rather than "complement"
   (sometimes meaning negate, which is not allowed) the file parameters.

   Elaborated in Sections 3.3 and 4 that FEC Encoding ID = 0 is Compact
   No-Code FEC, so that the reader doesn't have to search other RFCs to
   understand these protocol constants used by FLUTE.

Top      Up      ToC       Page 40 
   Required in Section 3.3 that FLUTE receivers SHALL NOT attempt to
   decode FDTs if they do not understand the FEC Encoding ID.

   Removed the restriction of Section 3.3, in bullet #4, that TOI = 0
   for the FDT, to be consistent with Appendix A step 6 and elsewhere.
   An FDT is signaled by an FDT Instance ID, NOT only by TOI = 0.

   Standardized on the term "expiration time", and avoided using the
   redundant and possibly confusing term "expiry time".

   To interwork with experimental FLUTE, stipulated in Section 3.1 that
   only 1 instantiation of all 3 protocols -- FLUTE, ALC, and LCT -- can
   be associated with a session (source IP Address, TSI), and mentioned
   in Section 6 that one may (optionally) derive the FLUTE version from
   the file delivery session description.

   Used a software writing tool to lower the reading grade level and
   simplify Section 3.1.

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5775]  Luby, M., Watson, M., and L. Vicisano, "Asynchronous
              Layered Coding (ALC) Protocol Instantiation", RFC 5775,
              April 2010.

   [RFC5651]  Luby, M., Watson, M., and L. Vicisano, "Layered Coding
              Transport (LCT) Building Block", RFC 5651, October 2009.

   [RFC5052]  Watson, M., Luby, M., and L. Vicisano, "Forward Error
              Correction (FEC) Building Block", RFC 5052, August 2007.

   [RFC5445]  Watson, M., "Basic Forward Error Correction (FEC)
              Schemes", RFC 5445, March 2009.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, June 2010.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

Top      Up      ToC       Page 41 
   [XML-Schema-Part-1]
              Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
              "XML Schema Part 1: Structures Second Edition",
              W3C Recommendation, October 2004,
              <http://www.w3.org/TR/xmlschema-1/>.

   [XML-Schema-Part-2]
              Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
              Second Edition", W3C Recommendation, October 2004,
              <http://www.w3.org/TR/xmlschema-2/>.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226, May 2008.

   [RFC3738]  Luby, M. and V. Goyal, "Wave and Equation Based Rate
              Control (WEBRC) Building Block", RFC 3738, April 2004.

              Note: The RFC 3738 reference is to a target document of a
              lower maturity level.  Some caution should be used, since
              it may be less stable than the present document.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

12.2.  Informative References

   [RFC3926]  Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh,
              "FLUTE - File Delivery over Unidirectional Transport",
              RFC 3926, October 2004.

   [RFC2357]  Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF
              Criteria for Evaluating Reliable Multicast Transport and
              Application Protocols", RFC 2357, June 1998.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC3470]  Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for
              the Use of Extensible Markup Language (XML)
              within IETF Protocols", BCP 70, RFC 3470, January 2003.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

Top      Up      ToC       Page 42 
   [RFC1950]  Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
              Specification version 3.3", RFC 1950, May 1996.

   [RFC1951]  Deutsch, P., "DEFLATE Compressed Data Format Specification
              version 1.3", RFC 1951, May 1996.

   [RFC1952]  Deutsch, P., "GZIP file format specification version 4.3",
              RFC 1952, May 1996.

   [IANAheaderfields]
              IANA, "Message Header Fields",
              <http://www.iana.org/protocols>.

   [RFC2974]  Handley, M., Perkins, C., and E. Whelan, "Session
              Announcement Protocol", RFC 2974, October 2000.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, August 1989.

   [PAPER.SSM]
              Holbrook, H., "A Channel Model for Multicast", Ph.D.
              Dissertation, Stanford University, Department of Computer
              Science, Stanford, California, August 2001.

   [RFC3365]  Schiller, J., "Strong Security Requirements for Internet
              Engineering Task Force Standard Protocols", BCP 61,
              RFC 3365, August 2002.

   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, January 2010.

   [RFC3275]  Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible
              Markup Language) XML-Signature Syntax and Processing",
              RFC 3275, March 2002.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

Top      Up      ToC       Page 43 
   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, February 2003.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [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.

   [RFC5776]  Roca, V., Francillon, A., and S. Faurite, "Use of Timed
              Efficient Stream Loss-Tolerant Authentication (TESLA) in
              the Asynchronous Layered Coding (ALC) and NACK-Oriented
              Reliable Multicast (NORM) Protocols", RFC 5776,
              April 2010.

   [RFC6584]  Roca, V., "Simple Authentication Schemes for the
              Asynchronous Layered Coding (ALC) and NACK-Oriented
              Reliable Multicast (NORM) Protocols", RFC 6584,
              April 2012.

   [RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
              Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
              August 2004.

   [MBMSsecurity]
              3GPP, "3rd Generation Partnership Project; Technical
              Specification Group Services and System Aspects; 3G
              Security; Security of Multimedia Broadcast/Multicast
              Service (MBMS) (Release 10)", December 2010,
              <http://www.3gpp.org/ftp/Specs/archive/33_series/33.246/>.

Top      Up      ToC       Page 44 
Appendix A.  Receiver Operation (Informative)

   This section gives an example of how the receiver of the file
   delivery session may operate.  Instead of a detailed state-by-state
   specification, the following should be interpreted as a rough
   sequence of an envisioned file delivery receiver.

   1.  The receiver obtains the description of the file delivery session
       identified by the (source IP address, Transport Session
       Identifier) pair.  The receiver also obtains the destination IP
       addresses and respective ports associated with the file delivery
       session.

   2.  The receiver joins the channels in order to receive packets
       associated with the file delivery session.  The receiver may
       schedule this join operation utilizing the timing information
       contained in a possible description of the file delivery session.

   3.  The receiver receives ALC/LCT packets associated with the file
       delivery session.  The receiver checks that the packets match the
       declared Transport Session Identifier.  If not, the packets are
       silently discarded.

   4.  While receiving, the receiver demultiplexes packets based on
       their TOI and stores the relevant packet information in an
       appropriate area for recovery of the corresponding file.
       Multiple files can be reconstructed concurrently.

   5.  The receiver recovers an object.  An object can be recovered when
       an appropriate set of packets containing Encoding Symbols for the
       transmission object has been received.  An appropriate set of
       packets is dependent on the properties of the FEC Encoding ID and
       FEC Instance ID, and on other information contained in the FEC
       Object Transmission Information.

   6.  Objects with TOI = 0 are reserved for FDT Instances.  All FDT
       Instances are signaled by including an EXT_FDT Header Extension
       in the LCT header.  The EXT_FDT header contains an FDT Instance
       ID (i.e., an FDT version number).  If the object has an FDT
       Instance ID 'N', the receiver parses the payload of the instance
       'N' of the FDT and updates its FDT database accordingly.

   7.  If the object recovered is not an FDT Instance but a file, the
       receiver looks up its FDT database to get the properties
       described in the database, and assigns the file the given
       properties.  The receiver also checks that the received content

Top      Up      ToC       Page 45 
       length matches with the description in the database.  Optionally,
       if an MD5 checksum has been used, the receiver checks that the
       calculated MD5 matches the description in the FDT database.

   8.  The actions the receiver takes with imperfectly received files
       (missing data, mismatching content integrity digest, etc.) are
       outside the scope of this specification.  When a file is
       recovered before the associated file description entry is
       available, a possible behavior is to wait until an FDT Instance
       is received that includes the missing properties.

   9.  If the file delivery session end time has not been reached, go
       back to step 3.  Otherwise, end.

Appendix B.  Example of FDT Instance (Informative)

   <?xml version="1.0" encoding="UTF-8"?>
   <FDT-Instance xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:fdt
                         ietf-flute-fdt.xsd"
     Expires="2890842807">
     <File
       Content-Location="http://www.example.com/menu/tracklist.html"
       TOI="1"
       Content-Type="text/html"/>
     <File
       Content-Location="http://www.example.com/tracks/track1.mp3"
       TOI="2"
       Content-Length="6100"
       Content-Type="audio/mp3"
       Content-Encoding="gzip"
       Content-MD5="+VP5IrWploFkZWc11iLDdA=="
       Some-Private-Extension-Tag="abc123"/>
   </FDT-Instance>

Top      Up      ToC       Page 46 
Authors' Addresses

   Toni Paila
   Nokia
   Itamerenkatu 11-13
   Helsinki  00180
   Finland

   EMail: toni.paila@gmail.com


   Rod Walsh
   Nokia/Tampere University of Technology
   P.O. Box 553 (Korkeakoulunkatu 1)
   Tampere  FI-33101
   Finland

   EMail: roderick.walsh@tut.fi


   Michael Luby
   Qualcomm Technologies, Inc.
   2030 Addison Street, Suite 420
   Berkeley, CA  94704
   USA

   EMail: luby@qti.qualcomm.com


   Vincent Roca
   INRIA
   655, av. de l'Europe
   Inovallee; Montbonnot
   ST ISMIER cedex  38334
   France

   EMail: vincent.roca@inria.fr


   Rami Lehtonen
   TeliaSonera
   Hatanpaankatu 1
   Tampere  FIN-33100
   Finland

   EMail: rami.lehtonen@teliasonera.com