idnits 2.17.1
draft-ietf-rmt-flute-revised-07.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** The document seems to lack a License Notice according IETF Trust
Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
Section 6.b -- however, there's a paragraph with a matching beginning.
Boilerplate error?
(You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Feb 2009 rather than one of the newer Notices. See
https://trustee.ietf.org/license-info/.)
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document seems to contain a disclaimer for pre-RFC5378 work, and may
have content which was first submitted before 10 November 2008. The
disclaimer is necessary when there are original authors that you have
been unable to contact, or if some do not wish to grant the BCP78 rights
to the IETF Trust. If you are able to get all authors (current and
original) to grant those rights, you can and should remove the
disclaimer; otherwise, the disclaimer is needed and you can ignore this
comment. (See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (August 6, 2009) is 5370 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: '0' is mentioned on line 1365, but not defined
== Missing Reference: '255' is mentioned on line 1365, but not defined
== Outdated reference: A later version (-10) exists of
draft-ietf-rmt-pi-alc-revised-07
== Outdated reference: A later version (-11) exists of
draft-ietf-rmt-bb-lct-revised-10
** Obsolete normative reference: RFC 1305 (ref. '6') (Obsoleted by RFC 5905)
** Obsolete normative reference: RFC 2616 (ref. '7') (Obsoleted by RFC
7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
-- Possible downref: Non-RFC (?) normative reference: ref. '8'
-- Possible downref: Non-RFC (?) normative reference: ref. '9'
** Obsolete normative reference: RFC 3023 (ref. '10') (Obsoleted by RFC
7303)
** Obsolete normative reference: RFC 5226 (ref. '12') (Obsoleted by RFC
8126)
-- Obsolete informational reference (is this intentional?): RFC 4566 (ref.
'14') (Obsoleted by RFC 8866)
-- Obsolete informational reference (is this intentional?): RFC 3851 (ref.
'17') (Obsoleted by RFC 5751)
-- Obsolete informational reference (is this intentional?): RFC 4288 (ref.
'19') (Obsoleted by RFC 6838)
-- Obsolete informational reference (is this intentional?): RFC 3447 (ref.
'23') (Obsoleted by RFC 8017)
Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Reliable Multicast Transport (RMT) T. Paila
3 Internet-Draft R. Walsh
4 Obsoletes: 3926 (if approved) Nokia
5 Intended status: Standards Track M. Luby
6 Expires: February 7, 2010 Digital Fountain
7 R. Lehtonen
8 TeliaSonera
9 V. Roca
10 INRIA Rhone-Alpes
11 August 6, 2009
13 FLUTE - File Delivery over Unidirectional Transport
14 draft-ietf-rmt-flute-revised-07
16 Status of this Memo
18 This Internet-Draft is submitted to IETF in full conformance with the
19 provisions of BCP 78 and BCP 79. This document may contain material
20 from IETF Documents or IETF Contributions published or made publicly
21 available before November 10, 2008. The person(s) controlling the
22 copyright in some of this material may not have granted the IETF
23 Trust the right to allow modifications of such material outside the
24 IETF Standards Process. Without obtaining an adequate license from
25 the person(s) controlling the copyright in such materials, this
26 document may not be modified outside the IETF Standards Process, and
27 derivative works of it may not be created outside the IETF Standards
28 Process, except to format it for publication as an RFC or to
29 translate it into languages other than English.
31 Internet-Drafts are working documents of the Internet Engineering
32 Task Force (IETF), its areas, and its working groups. Note that
33 other groups may also distribute working documents as Internet-
34 Drafts.
36 Internet-Drafts are draft documents valid for a maximum of six months
37 and may be updated, replaced, or obsoleted by other documents at any
38 time. It is inappropriate to use Internet-Drafts as reference
39 material or to cite them other than as "work in progress."
41 The list of current Internet-Drafts can be accessed at
42 http://www.ietf.org/ietf/1id-abstracts.txt.
44 The list of Internet-Draft Shadow Directories can be accessed at
45 http://www.ietf.org/shadow.html.
47 This Internet-Draft will expire on February 7, 2010.
49 Copyright Notice
51 Copyright (c) 2009 IETF Trust and the persons identified as the
52 document authors. All rights reserved.
54 This document is subject to BCP 78 and the IETF Trust's Legal
55 Provisions Relating to IETF Documents in effect on the date of
56 publication of this document (http://trustee.ietf.org/license-info).
57 Please review these documents carefully, as they describe your rights
58 and restrictions with respect to this document.
60 Abstract
62 This document defines FLUTE, a protocol for the unidirectional
63 delivery of files over the Internet, which is particularly suited to
64 multicast networks. The specification builds on Asynchronous Layered
65 Coding, the base protocol designed for massively scalable multicast
66 distribution. This document obsoletes RFC3926.
68 Table of Contents
70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
71 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 5
72 1.1.1. The Target Application Space . . . . . . . . . . . . . 5
73 1.1.2. The Target Scale . . . . . . . . . . . . . . . . . . . 5
74 1.1.3. Intended Environments . . . . . . . . . . . . . . . . 5
75 1.1.4. Weaknesses . . . . . . . . . . . . . . . . . . . . . . 6
76 2. Conventions used in this Document . . . . . . . . . . . . . . 6
77 3. File delivery . . . . . . . . . . . . . . . . . . . . . . . . 6
78 3.1. File delivery session . . . . . . . . . . . . . . . . . . 7
79 3.2. File Delivery Table . . . . . . . . . . . . . . . . . . . 9
80 3.3. Dynamics of FDT Instances within file delivery session . . 11
81 3.4. Structure of FDT Instance packets . . . . . . . . . . . . 12
82 3.4.1. Format of FDT Instance Header . . . . . . . . . . . . 13
83 3.4.2. Syntax of FDT Instance . . . . . . . . . . . . . . . . 14
84 3.4.3. Content Encoding of FDT Instance . . . . . . . . . . . 18
85 3.5. Multiplexing of files within a file delivery session . . . 19
86 4. Channels, congestion control and timing . . . . . . . . . . . 19
87 5. Delivering FEC Object Transmission Information . . . . . . . . 20
88 6. Describing file delivery sessions . . . . . . . . . . . . . . 22
89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
90 7.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 23
91 7.2. Attacks against the data flow . . . . . . . . . . . . . . 24
92 7.2.1. Access to confidential files . . . . . . . . . . . . . 24
93 7.2.2. File corruption . . . . . . . . . . . . . . . . . . . 24
94 7.3. Attacks against the session control parameters and
95 associated Building Blocks . . . . . . . . . . . . . . . . 25
96 7.3.1. Attacks against the Session Description . . . . . . . 26
97 7.3.2. Attacks against the FDT Instances . . . . . . . . . . 26
98 7.3.3. Attacks against the ALC/LCT parameters . . . . . . . . 27
99 7.3.4. Attacks against the associated Building Blocks . . . . 27
100 7.4. Other Security Considerations . . . . . . . . . . . . . . 28
101 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
102 8.1. Registration Request for XML Schema of FDT Instance . . . 28
103 8.2. Media-Type Registration Request for application/fdt+xml . 28
104 8.3. Content Encoding Algorithm Registration Request . . . . . 30
105 8.3.1. Explicit IANA Assignment Guidelines . . . . . . . . . 30
106 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
107 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
108 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 31
109 11.1. RFC3926 to draft-ietf-rmt-flute-revised-07 . . . . . . . . 31
110 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
111 12.1. Normative references . . . . . . . . . . . . . . . . . . . 32
112 12.2. Informative references . . . . . . . . . . . . . . . . . . 33
113 Appendix A. Receiver operation (informative) . . . . . . . . . . 34
114 Appendix B. Example of FDT Instance (informative) . . . . . . . . 36
115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
117 1. Introduction
119 This document defines FLUTE version 1, a protocol for unidirectional
120 delivery of files over the Internet. The specification builds on
121 Asynchronous Layered Coding (ALC), version 1 [2], the base protocol
122 designed for massively scalable multicast distribution. ALC defines
123 transport of arbitrary binary objects. For file delivery
124 applications mere transport of objects is not enough, however. The
125 end systems need to know what the objects actually represent. This
126 document specifies a technique called FLUTE - a mechanism for
127 signaling and mapping the properties of files to concepts of ALC in a
128 way that allows receivers to assign those parameters for received
129 objects. Consequently, throughout this document the term 'file'
130 relates to an 'object' as discussed in ALC. Although this
131 specification frequently makes use of multicast addressing as an
132 example, the techniques are similarly applicable for use with unicast
133 addressing.
135 This document defines a specific transport application of ALC, adding
136 the following specifications:
138 - Definition of a file delivery session built on top of ALC,
139 including transport details and timing constraints.
141 - In-band signalling of the transport parameters of the ALC session.
143 - In-band signalling of the properties of delivered files.
145 - Details associated with the multiplexing of multiple files within
146 a session.
148 This specification is structured as follows. Section 3 begins by
149 defining the concept of the file delivery session. Following that it
150 introduces the File Delivery Table that forms the core part of this
151 specification. Further, it discusses multiplexing issues of
152 transmission objects within a file delivery session. Section 4
153 describes the use of congestion control and channels with FLUTE.
154 Section 5 defines how the Forward Error Correction (FEC) Object
155 Transmission Information is to be delivered within a file delivery
156 session. Section 6 defines the required parameters for describing
157 file delivery sessions in a general case. Section 7 outlines
158 security considerations regarding file delivery with FLUTE. Last,
159 there are two informative appendices. The first appendix describes
160 an envisioned receiver operation for the receiver of the file
161 delivery session. The second appendix gives an example of File
162 Delivery Table.
164 This specification contains part of the definitions necessary to
165 fully specify a Reliable Multicast Transport protocol in accordance
166 with RFC2357.
168 This document obsoletes RFC3926 which contained a previous version of
169 this specification and was published in the "Experimental" category.
170 This Proposed Standard specification is thus based on RFC3926 updated
171 according to accumulated experience and growing protocol maturity
172 since the publication of RFC3926. Said experience applies both to
173 this specification itself and to congestion control strategies
174 related to the use of this specification.
176 The differences between RFC3926 and this document listed in
177 Section 11.
179 1.1. Applicability Statement
181 1.1.1. The Target Application Space
183 FLUTE is applicable to the delivery of large and small files to many
184 hosts, using delivery sessions of several seconds or more. For
185 instance, FLUTE could be used for the delivery of large software
186 updates to many hosts simultaneously. It could also be used for
187 continuous, but segmented, data such as time-lined text for
188 subtitling - potentially leveraging its layering inheritance from ALC
189 and LCT to scale the richness of the session to the congestion status
190 of the network. It is also suitable for the basic transport of
191 metadata, for example SDP [14] files which enable user applications
192 to access multimedia sessions.
194 1.1.2. The Target Scale
196 Massive scalability is a primary design goal for FLUTE. IP multicast
197 is inherently massively scalable, but the best effort service that it
198 provides does not provide session management functionality,
199 congestion control or reliability. FLUTE provides all of this using
200 ALC and IP multicast without sacrificing any of the inherent
201 scalability of IP multicast.
203 1.1.3. Intended Environments
205 All of the environmental requirements and considerations that apply
206 to the ALC building block [2] and to any additional building blocks
207 that FLUTE uses also apply to FLUTE.
209 FLUTE can be used with both multicast and unicast delivery, but it's
210 primary application is for unidirectional multicast file delivery.
211 FLUTE requires connectivity between a sender and receivers but does
212 not require connectivity from receivers to a sender. FLUTE
213 inherently works with all types of networks, including LANs, WANs,
214 Intranets, the Internet, asymmetric networks, wireless networks, and
215 satellite networks.
217 FLUTE is compatible with both IPv4 or IPv6 as no part of the packet
218 is IP version specific. FLUTE works with both multicast models: Any-
219 Source Multicast (ASM) [15] and the Source-Specific Multicast (SSM)
220 [16].
222 FLUTE is applicable for both Internet use, with a suitable congestion
223 control building block, and provisioned/controlled systems, such as
224 delivery over wireless broadcast radio systems.
226 1.1.4. Weaknesses
228 Some networks are not amenable to some congestion control protocols
229 that could be used with FLUTE. In particular, for a satellite or
230 wireless network, there may be no mechanism for receivers to
231 effectively reduce their reception rate since there may be a fixed
232 transmission rate allocated to the session.
234 FLUTE provides reliability using the FEC building block. This will
235 reduce the error rate as seen by applications. However, FLUTE does
236 not provide a method for senders to verify the reception success of
237 receivers, and the specification of such a method is outside the
238 scope of this document.
240 2. Conventions used in this Document
242 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
243 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
244 document are to be interpreted as described in RFC 2119 [1].
246 The terms "object" and "transmission object" are consistent with the
247 definitions in ALC [2] and LCT [3]. The terms "file" and "source
248 object" are pseudonyms for "object".
250 3. File delivery
252 Asynchronous Layered Coding [2] is a protocol designed for delivery
253 of arbitrary binary objects. It is especially suitable for massively
254 scalable, unidirectional, multicast distribution. ALC provides the
255 basic transport for FLUTE, and thus FLUTE inherits the requirements
256 of ALC.
258 This specification is designed for the delivery of files. The core
259 of this specification is to define how the properties of the files
260 are carried in-band together with the delivered files.
262 As an example, let us consider a 5200 byte file referred to by
263 "http://www.example.com/docs/file.txt". Using the example, the
264 following properties describe the properties that need to be conveyed
265 by the file delivery protocol.
267 * Identifier of the file, expressed as a URI. This identifier may
268 be globally unique. The identifier may also provide a location
269 for the file. In the above example:
270 "http://www.example.com/docs/file.txt".
272 * File name (usually, this can be concluded from the URI). In the
273 above example: "file.txt".
275 * File type, expressed as MIME media type (usually, this can also be
276 concluded from the extension of the file name). In the above
277 example: "text/plain". If an explicit value for the MIME type is
278 provided separately from the file extension and does not match the
279 MIME type of the file extension then the explicitly provided value
280 MUST be used as the MIME type.
282 * File size, expressed in bytes. In the above example: "5200". If
283 the file is content encoded then this is the file size before
284 content encoding.
286 * Content encoding of the file, within transport. In the above
287 example, the file could be encoded using ZLIB [28]. In this case
288 the size of the transmission object carrying the file would
289 probably differ from the file size. The transmission object size
290 is delivered to receivers as part of the FLUTE protocol.
292 * Security properties of the file such as digital signatures,
293 message digests, etc. For example, one could use S/MIME [17] as
294 the content encoding type for files with this authentication
295 wrapper, and one could use XML-DSIG [18] to digitally sign an FDT
296 Instance. XML-DSIG can also be used to provide tamper prevention
297 e.g. on the Content-Location field.
299 3.1. File delivery session
301 ALC is a protocol instantiation of Layered Coding Transport building
302 block (LCT) [3]. Thus ALC inherits the session concept of LCT. In
303 this document we will use the concept ALC/LCT session to collectively
304 denote the interchangeable terms ALC session and LCT session.
306 An ALC/LCT session consists of a set of logically grouped ALC/LCT
307 channels associated with a single sender sending packets with ALC/LCT
308 headers for one or more objects. An ALC/LCT channel is defined by
309 the combination of a sender and an address associated with the
310 channel by the sender. A receiver joins a channel to start receiving
311 the data packets sent to the channel by the sender, and a receiver
312 leaves a channel to stop receiving data packets from the channel.
314 One of the fields carried in the ALC/LCT header is the Transport
315 Session Identifier (TSI). The TSI is scoped by the source IP
316 address, and the (source IP address, TSI) pair uniquely identifies a
317 session, i.e., the receiver uses this pair carried in each packet to
318 uniquely identify from which session the packet was received. In
319 case multiple objects are carried within a session, the Transmission
320 Object Identifier (TOI) field within the ALC/LCT header identifies
321 from which object the data in the packet was generated. Note that
322 each object is associated with a unique TOI within the scope of a
323 session.
325 If the sender is not assigned a permanent IP address accessible to
326 receivers, but instead, packets that can be received by receivers
327 containing a temporary IP address for packets sent by the sender,
328 then the TSI is scoped by this temporary IP address of the sender for
329 the duration of the session. As an example, the sender may be behind
330 a Network Address Translation (NAT) device that temporarily assigns
331 an IP address for the sender that is accessible to receivers, and in
332 this case the TSI is scoped by the temporary IP address assigned by
333 the NAT that will appear in packets received by the receiver. As
334 another example, the sender may send its original packets using IPv6,
335 but some portions of the network may not be IPv6 capable and thus
336 there may be an IPv6 to IPv4 translator that changes the IP address
337 of the packets to a different IPv4 address. In this case, receivers
338 in the IPv4 portion of the network will receive packets containing
339 the IPv4 address, and thus the TSI for them is scoped by the IPv4
340 address. How the IP address of the sender to be used to scope the
341 session by receivers is delivered to receivers, whether it is a
342 permanent IP address or a temporary IP address, is outside the scope
343 of this document.
345 When FLUTE is used for file delivery over ALC the following rules
346 apply:
348 * The ALC/LCT session is called file delivery session.
350 * The ALC/LCT concept of 'object' denotes either a 'file' or a 'File
351 Delivery Table Instance' (section 3.2)
353 * The TOI field MUST be included in ALC packets sent within a FLUTE
354 session, with the exception that ALC packets sent in a FLUTE
355 session with the Close Session (A) flag set to 1 (signaling the
356 end of the session) and that contain no payload (carrying no
357 information for any file or FDT) SHALL NOT carry the TOI. See
358 Section 5.1 of RFC 3451 [3] for the LCT definition of the Close
359 Session flag, and see Section 4.2 of RFC 3450 [2] for an example
360 of its use within an ALC packet.
362 * The TOI value '0' is reserved for delivery of File Delivery Table
363 Instances. Each File Delivery Table Instance is uniquely
364 identified by an FDT Instance ID.
366 * Each file in a file delivery session MUST be associated with a TOI
367 (>0) in the scope of that session.
369 * Information carried in the headers and the payload of a packet is
370 scoped by the source IP address and the TSI. Information
371 particular to the object carried in the headers and the payload of
372 a packet is further scoped by the TOI for file objects, and is
373 further scoped by both the TOI and the FDT Instance ID for FDT
374 Instance objects.
376 3.2. File Delivery Table
378 The File Delivery Table (FDT) provides a means to describe various
379 attributes associated with files that are to be delivered within the
380 file delivery session. The following lists are examples of such
381 attributes, and are not intended to be mutually exclusive nor
382 exhaustive.
384 Attributes related to the delivery of file:
386 - TOI value that represents the file
388 - FEC Object Transmission Information (including the FEC Encoding ID
389 and, if relevant, the FEC Instance ID)
391 - Size of the transmission object carrying the file
393 - Aggregate rate of sending packets to all channels
395 Attributes related to the file itself:
397 - Name, Identification and Location of file (specified by the URI)
398 - MIME media type of file
400 - Size of file
402 - Encoding of file
404 - Message digest of file
406 Some of these attributes MUST be included in the file description
407 entry for a file, others are optional, as defined in section 3.4.2.
409 Logically, the FDT is a set of file description entries for files to
410 be delivered in the session. Each file description entry MUST
411 include the TOI for the file that it describes and the URI
412 identifying the file. The TOI is included in each ALC/LCT data
413 packet during the delivery of the file, and thus the TOI carried in
414 the file description entry is how the receiver determines which ALC/
415 LCT data packets contain information about which file. Each file
416 description entry may also contain one or more descriptors that map
417 the above-mentioned attributes to the file.
419 Each file delivery session MUST have an FDT that is local to the
420 given session. The FDT MUST provide a file description entry mapped
421 to a TOI for each file appearing within the session. An object that
422 is delivered within the ALC session, but not described in the FDT, is
423 not considered a 'file' belonging to the file delivery session.
424 Handling of these unmapped TOIs (TOIs that are not resolved by the
425 FDT) is out of scope of this specification.
427 Within the file delivery session the FDT is delivered as FDT
428 Instances. An FDT Instance contains one or more file description
429 entries of the FDT. Any FDT Instance can be equal to, a subset of, a
430 superset of, or complement any other FDT Instance. A certain FDT
431 Instance may be repeated several times during a session, even after
432 subsequent FDT Instances (with higher FDT Instance ID numbers) have
433 been transmitted. Each FDT Instance contains at least a single file
434 description entry and at most the exhaustive set of file description
435 entries of the files being delivered in the file delivery session.
437 A receiver of the file delivery session keeps an FDT database for
438 received file description entries. The receiver maintains the
439 database, for example, upon reception of FDT Instances. Thus, at any
440 given time the contents of the FDT database represent the receiver's
441 current view of the FDT of the file delivery session. Since each
442 receiver behaves independently of other receivers, it SHOULD NOT be
443 assumed that the contents of the FDT database are the same for all
444 the receivers of a given file delivery session.
446 Since FDT database is an abstract concept, the structure and the
447 maintaining of the FDT database are left to individual
448 implementations and are thus out of scope of this specification.
450 3.3. Dynamics of FDT Instances within file delivery session
452 The following rules define the dynamics of the FDT Instances within a
453 file delivery session:
455 * For every file delivered within a file delivery session there MUST
456 be a file description entry included in at least one FDT Instance
457 sent within the session. A file description entry contains at a
458 minimum the mapping between the TOI and the URI.
460 * An FDT Instance MAY appear in any part of the file delivery
461 session and packets for an FDT Instance MAY be interleaved with
462 packets for other files or other FDT Instances within a session.
464 * The TOI value of '0' MUST be reserved for delivery of FDT
465 Instances. The use of other TOI values for FDT Instances is
466 outside the scope of this specification.
468 * FDT Instance is identified by the use of a new fixed length LCT
469 Header Extension EXT_FDT (defined later in this section). Each
470 FDT Instance is uniquely identified within the file delivery
471 session by its FDT Instance ID. Any ALC/LCT packet carrying FDT
472 Instance (indicated by TOI = 0) MUST include EXT_FDT.
474 * It is RECOMMENDED that FDT Instance that contains the file
475 description entry for a file is sent prior to the sending of the
476 described file within a file delivery session.
478 * Within a file delivery session, any TOI > 0 MAY be described more
479 than once. An example: previous FDT Instance 0 describes TOI of
480 value '3'. Now, subsequent FDT Instances can either keep TOI '3'
481 unmodified on the table, not include it, or complement the
482 description. However, subsequent FDT Instances MUST NOT change
483 the parameters already described for a specific TOI.
485 * An FDT Instance is valid until its expiration time. The
486 expiration time is expressed within the FDT Instance payload as a
487 32 bit data field. The value of the data field represents the 32
488 most significant bits of a 64 bit Network Time Protocol (NTP) [6]
489 time value. These 32 bits provide an unsigned integer
490 representing the time in seconds relative to 0 hours 1 January
491 1900. Handling of wraparound of the 32 bit time is outside the
492 scope of NTP and FLUTE.
494 * The receiver SHOULD NOT use a received FDT Instance to interpret
495 packets received beyond the expiration time of the FDT Instance.
497 * A sender MUST use an expiry time in the future upon creation of an
498 FDT Instance relative to its Sender Current Time (SCT).
500 * Any FEC Encoding ID MAY be used for the sending of FDT Instances.
501 The default is to use FEC Encoding ID 0 [5] for the sending of FDT
502 Instances. (Note that since FEC Encoding ID 0 is the default for
503 FLUTE, this implies that Source Block Number and Encoding Symbol
504 ID lengths both default to 16 bits each.)
506 Generally, a receiver needs to receive an FDT Instance describing a
507 file before it is able to recover the file itself. In this sense FDT
508 Instances are of higher priority than files. Thus, it is RECOMMENDED
509 that FDT Instances describing a file be sent with at least as much
510 reliability within a session (more often or with more FEC protection)
511 as the files they describe. In particular, if FDT Instances are
512 longer than one packet payload in length it is RECOMMENDED that an
513 FEC code that provides protection against loss be used for delivering
514 FDT Instances. How often the description of a file is sent in an FDT
515 Instance or how much FEC protection is provided for each FDT Instance
516 (if the FDT Instance is longer than one packet payload) is dependent
517 on the particular application and outside the scope of this document.
519 3.4. Structure of FDT Instance packets
521 FDT Instances are carried in ALC packets with TOI = 0 and with an
522 additional REQUIRED LCT Header extension called the FDT Instance
523 Header. The FDT Instance Header (EXT_FDT) contains the FDT Instance
524 ID that uniquely identifies FDT Instances within a file delivery
525 session. The FDT Instance Header is placed in the same way as any
526 other LCT extension header. There MAY be other LCT extension headers
527 in use.
529 The LCT extension headers are followed by the FEC Payload ID, and
530 finally the Encoding Symbols for the FDT Instance which contains one
531 or more file description entries. A FDT Instance MAY span several
532 ALC packets - the number of ALC packets is a function of the file
533 attributes associated with the FDT Instance. The FDT Instance Header
534 is carried in each ALC packet carrying the FDT Instance. The FDT
535 Instance Header is identical for all ALC/LCT packets for a particular
536 FDT Instance.
538 The overall format of ALC/LCT packets carrying an FDT Instance is
539 depicted in the Figure 1 below. All integer fields are carried in
540 "big-endian" or "network order" format, that is, most significant
541 byte (octet) first. As defined in [2], all ALC/LCT packets are sent
542 using UDP.
544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
545 | UDP header |
546 | |
547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
548 | Default LCT header (with TOI = 0) |
549 | |
550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
551 | LCT header extensions (EXT_FDT, EXT_FTI, etc.) |
552 | |
553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
554 | FEC Payload ID |
555 | |
556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
557 FLUTE Payload: Encoding Symbol(s)
558 ~ (for FDT Instance in a FDT packet) ~
560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
562 Figure 1: Overall FDT Packet
564 3.4.1. Format of FDT Instance Header
566 FDT Instance Header (EXT_FDT) is a new fixed length, ALC PI specific
567 LCT header extension [3]. The Header Extension Type (HET) for the
568 extension is 192. Its format is defined below:
570 0 1 2 3
571 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
572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
573 | HET = 192 | V | FDT Instance ID |
574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
576 Figure 2
578 Version of FLUTE (V), 4 bits:
580 This document specifies FLUTE version 1. Hence in any ALC packet
581 that carries FDT Instance and that belongs to the file delivery
582 session as specified in this specification MUST set this field to
583 '1'.
585 FDT Instance ID, 20 bits:
587 For each file delivery session the numbering of FDT Instances starts
588 from '0' and is incremented by one for each subsequent FDT Instance.
589 After reaching the maximum value (2^20-1), the numbering starts from
590 the smallest FDT Instance value assigned to an expired FDT Instance.
591 When wraparound from a greater FDT Instance value to a smaller FDT
592 Instance value occurs, the smaller FDT Instance value is considered
593 logically higher than the greater FDT Instance value. A new FDT
594 Instance reusing a previous FDT Instance ID number, due to
595 wraparound, may not implicitly expire the previous FDT Instance with
596 the same ID. Mandatory receiver behavior for handling FDT Instance
597 ID wraparound and other special situations (for example, missing FDT
598 Instance IDs resulting in larger increments than one) is outside the
599 scope of this specification and left to individual implementations of
600 FLUTE.
602 3.4.2. Syntax of FDT Instance
604 The FDT Instance contains file description entries that provide the
605 mapping functionality described in 3.2 above.
607 The FDT Instance is an XML structure that has a single root element
608 "FDT-Instance". The "FDT-Instance" element MUST contain "Expires"
609 attribute, which tells the expiry time of the FDT Instance. In
610 addition, the "FDT-Instance" element MAY contain the "Complete"
611 attribute (boolean), which, when TRUE, signals that this "FDT
612 Instance" includes the set of "File" entries that exhausts both the
613 set of files delivered so far and also the set of files to be
614 delivered in the session. This implies that no new data will be
615 provided in future FDT Instances within this session (i.e., that
616 either FDT Instances with higher ID numbers will not be used or if
617 they are used, will only provide identical file parameters to those
618 already given in this and previous FDT Instances). The "Complete"
619 attribute is therefore used to provide a complete list of files in an
620 entire FLUTE session (a "complete FDT").
622 The "FDT-Instance" element MAY contain attributes that give common
623 parameters for all files of an FDT Instance. These attributes MAY
624 also be provided for individual files in the "File" element. Where
625 the same attribute appears in both the "FDT-Instance" and the "File"
626 elements, the value of the attribute provided in the "File" element
627 takes precedence.
629 For each file to be declared in the given FDT Instance there is a
630 single file description entry in the FDT Instance. Each entry is
631 represented by element "File" which is a child element of the FDT
632 Instance structure.
634 The attributes of "File" element in the XML structure represent the
635 attributes given to the file that is delivered in the file delivery
636 session. The value of the XML attribute name corresponds to MIME
637 field name and the XML attribute value corresponds to the value of
638 the MIME field body. Each "File" element MUST contain at least two
639 attributes "TOI" and "Content-Location". "TOI" MUST be assigned a
640 valid TOI value as described in section 3.3 above. "Content-
641 Location" MUST be assigned a valid URI as defined in [7]. The
642 semantics for any two "File" elements declaring the same "Content-
643 Location" but differing "TOI" is that the element appearing in the
644 FDT Instance with the greater FDT Instance ID is considered to
645 declare newer instance (e.g. version) of the same "File".
647 In addition to mandatory attributes, the "FDT-Instance" element and
648 the "File" element MAY contain other attributes of which the
649 following are specifically pointed out.
651 * Where the MIME type is described, the attribute "Content-Type"
652 MUST be used for the purpose as defined in [7].
654 * Where the length is described, the attribute "Content-Length" MUST
655 be used for the purpose as defined in [7]. The transfer length is
656 defined to be the length of the object transported in bytes. It
657 is often important to convey the transfer length to receivers,
658 because the source block structure needs to be known for the FEC
659 decoder to be applied to recover source blocks of the file, and
660 the transfer length is often needed to properly determine the
661 source block structure of the file. There generally will be a
662 difference between the length of the original file and the
663 transfer length if content encoding is applied to the file before
664 transport, and thus the "Content-Encoding" attribute is used. If
665 the file is not content encoded before transport (and thus the
666 "Content-Encoding" attribute is not used) then the transfer length
667 is the length of the original file, and in this case the "Content-
668 Length" is also the transfer length. However, if the file is
669 content encoded before transport (and thus the "Content-Encoding"
670 attribute is used), e.g., if compression is applied before
671 transport to reduce the number of bytes that need to be
672 transferred, then the transfer length is generally different than
673 the length of the original file, and in this case the attribute
674 "Transfer-Length" MAY be used to carry the transfer length.
676 * Where the content encoding scheme is described, the attribute
677 "Content-Encoding" MUST be used for the purpose as defined in [7].
679 * Where the MD5 message digest is described, the attribute "Content-
680 MD5" MUST be used for the purpose as defined in [7].
682 * The FEC Object Transmission Information attributes as described in
683 section 5.2.
685 The following specifies the XML Schema [8][9] for FDT Instance:
687 BEGIN
688
689
693
694
695
696
697
699
700
703
706
709
712
715
718
721
724
727
730
731
732
733
734
736
737
740
743
746
749
752
755
758
761
764
767
770
773
776
777
778
779 END
781 Figure 3
783 Any valid FDT Instance must use the above XML Schema. This way FDT
784 provides extensibility to support private attributes within the file
785 description entries. Those could be, for example, the attributes
786 related to the delivery of the file (timing, packet transmission
787 rate, etc.).
789 In case the basic FDT XML Schema is extended in terms of new
790 descriptors (attributes or elements), for descriptors applying to a
791 single file, those MUST be placed within the element "File". For
792 descriptors applying to all files described by the current FDT
793 Instance, those MUST be placed within the element "FDT-Instance". It
794 is RECOMMENDED that the new attributes applied in the FDT are in the
795 format of MIME fields and are either defined in the HTTP/1.1
796 specification [7] or another well-known specification.
798 3.4.3. Content Encoding of FDT Instance
800 The FDT Instance itself MAY be content encoded, for example
801 compressed. This specification defines FDT Instance Content Encoding
802 Header (EXT_CENC). EXT_CENC is a new fixed length, ALC PI specific
803 LCT header extension [3]. The Header Extension Type (HET) for the
804 extension is 193. If the FDT Instance is content encoded, the
805 EXT_CENC MUST be used to signal the content encoding type. In that
806 case, EXT_CENC header extension MUST be used in all ALC packets
807 carrying the same FDT Instance ID. Consequently, when EXT_CENC
808 header is used, it MUST be used together with a proper FDT Instance
809 Header (EXT_FDT). Within a file delivery session, FDT Instances that
810 are not content encoded and FDT Instances that are content encoded
811 MAY both appear. If content encoding is not used for a given FDT
812 Instance, the EXT_CENC MUST NOT be used in any packet carrying the
813 FDT Instance. The format of EXT_CENC is defined below:
815 0 1 2 3
816 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
817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
818 | HET = 193 | CENC | Reserved |
819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
821 Figure 4
823 Content Encoding Algorithm (CENC), 8 bits:
825 This field signals the content encoding algorithm used in the FDT
826 Instance payload. This subsection reserves the Content Encoding
827 Algorithm values 0, 1, 2 and 3 for null, ZLIB [28], DEFLATE [29] and
828 GZIP [30] respectively.
830 Reserved, 16 bits:
832 This field MUST be set to all '0'. This field SHOULD be ignored on
833 reception.
835 3.5. Multiplexing of files within a file delivery session
837 The delivered files are carried as transmission objects (identified
838 with TOIs) in the file delivery session. All these objects,
839 including the FDT Instances, MAY be multiplexed in any order and in
840 parallel with each other within a session, i.e., packets for one file
841 MAY be interleaved with packets for other files or other FDT
842 Instances within a session.
844 Multiple FDT Instances MAY be delivered in a single session using TOI
845 = 0. In this case, it is RECOMMENDED that the sending of a previous
846 FDT Instance SHOULD end before the sending of the next FDT Instance
847 starts. However, due to unexpected network conditions, packets for
848 the FDT Instances MAY be interleaved. A receiver can determine which
849 FDT Instance a packet contains information about since the FDT
850 Instances are uniquely identified by their FDT Instance ID carried in
851 the EXT_FDT headers.
853 4. Channels, congestion control and timing
855 ALC/LCT has a concept of channels and congestion control. There are
856 four scenarios FLUTE is envisioned to be applied.
858 (a) Use a single channel and a single-rate congestion control
859 protocol.
861 (b) Use multiple channels and a multiple-rate congestion control
862 protocol. In this case the FDT Instances MAY be delivered on more
863 than one channel.
865 (c) Use a single channel without congestion control supplied by ALC,
866 but only when in a controlled network environment where flow/
867 congestion control is being provided by other means.
869 (d) Use multiple channels without congestion control supplied by
870 ALC, but only when in a controlled network environment where flow/
871 congestion control is being provided by other means. In this case
872 the FDT Instances MAY be delivered on more than one channel.
874 When using just one channel for a file delivery session, as in (a)
875 and (c), the notion of 'prior' and 'after' are intuitively defined
876 for the delivery of objects with respect to their delivery times.
878 However, if multiple channels are used, as in (b) and (d), it is not
879 straightforward to state that an object was delivered 'prior' to the
880 other. An object may begin to be delivered on one or more of those
881 channels before the delivery of a second object begins. However, the
882 use of multiple channels/layers may complete the delivery of the
883 second object before the first. This is not a problem when objects
884 are delivered sequentially using a single channel. Thus, if the
885 application of FLUTE has a mandatory or critical requirement that the
886 first transmission object must complete 'prior' to the second one, it
887 is RECOMMENDED that only a single channel is used for the file
888 delivery session.
890 Furthermore, if multiple channels are used then a receiver joined to
891 the session at a low reception rate will only be joined to the lower
892 layers of the session. Thus, since the reception of FDT Instances is
893 of higher priority than the reception of files (because the reception
894 of files depends on the reception of an FDT Instance describing it),
895 the following is RECOMMENDED:
897 1. The layers to which packets for FDT Instances are sent SHOULD NOT
898 be biased towards those layers to which lower rate receivers are
899 not joined. For example, it is ok to put all the packets for an
900 FDT Instance into the lowest layer (if this layer carries enough
901 packets to deliver the FDT to higher rate receivers in a
902 reasonable amount of time), but it is not ok to put all the
903 packets for an FDT Instance into the higher layers that only high
904 rate receivers will receive.
906 2. If FDT Instances are generally longer than one Encoding Symbol in
907 length and some packets for FDT Instances are sent to layers that
908 lower rate receivers do not receive, an FEC Encoding other than
909 FEC Encoding ID 0 [5] SHOULD be used to deliver FDT Instances.
910 This is because in this case, even when there is no packet loss in
911 the network, a lower rate receiver will not receive all packets
912 sent for an FDT Instance.
914 5. Delivering FEC Object Transmission Information
916 FLUTE inherits the use of FEC building block [4] from ALC. When
917 using FLUTE for file delivery over ALC the FEC Object Transmission
918 Information MUST be delivered in-band within the file delivery
919 session. There are two methods to achieve this: the use of ALC
920 specific LCT extension header EXT_FTI [2] and the use of FDT. The
921 latter method is specified in this section.
923 The receiver of file delivery session MUST support delivery of FEC
924 Object Transmission Information using the EXT_FTI for the FDT
925 Instances carried using TOI value 0. For the TOI values other than 0
926 the receiver MUST support both methods: the use of EXT_FTI and the
927 use of FDT.
929 The FEC Object Transmission Information that needs to be delivered to
930 receivers MUST be exactly the same whether it is delivered using
931 EXT_FTI or using FDT (or both). The FEC Object Transmission
932 Information that MUST be delivered to receivers is defined by the FEC
933 Scheme. This section describes the delivery using FDT.
935 The FEC Object Transmission Information regarding a given TOI may be
936 available from several sources. In this case, it is RECOMMENDED that
937 the receiver of the file delivery session prioritizes the sources in
938 the following way (in the order of decreasing priority).
940 1. FEC Object Transmission Information that is available in EXT_FTI.
942 2. FEC Object Transmission Information that is available in the FDT.
944 The FDT delivers FEC Object Transmission Information for each file
945 using an appropriate attribute within the "FDT-Instance" or the
946 "File" element of the FDT structure.
948 * "Transfer-Length" carries the Transfer-Length Object Transmission
949 Information element defined in [4].
951 * "FEC-OTI-FEC-Encoding-ID" carries the "FEC Encoding ID" Object
952 Transmission Information element defined in [4], as carried in the
953 Codepoint field of the ALC/LCT header.
955 * "FEC-OTI-FEC-Instance-ID" carries the "FEC Instance ID" Object
956 Transmission Information element defined in [4] for Under-
957 specified FEC Schemes.
959 * "FEC-OTI-Maximum-Source-Block-Length" carries the "Maximum Source
960 Block Length" Object Transmission Information element defined in
961 [4], if required by the FEC Scheme.
963 * "FEC-OTI-Encoding-Symbol-Length" carries the "Encoding Symbol
964 Length" Object Transmission Information element defined in [4], if
965 required by the FEC Scheme.
967 * "FEC-OTI-Max-Number-of-Encoding-Symbols" carries the "Maximum
968 Number of Encoding Symbols" Object Transmission Information
969 element defined in [4], if required by the FEC Scheme.
971 * "FEC-OTI-Scheme-specific-information" carries the "encoded scheme-
972 specific FEC Object Transmission Information" as defined in [4],
973 if required by the FEC Scheme.
975 In FLUTE, the FEC Encoding ID (8 bits) for a given TOI MUST be
976 carried in the Codepoint field of the ALC/LCT header. When the FEC
977 Object Transmission Information for this TOI is delivered through the
978 FDT, then the associated "FEC-OTI-FEC-Encoding-ID" attribute and the
979 Codepoint field of all packets for this TOI MUST be the same.
981 6. Describing file delivery sessions
983 To start receiving a file delivery session, the receiver needs to
984 know transport parameters associated with the session. Interpreting
985 these parameters and starting the reception therefore represents the
986 entry point from which thereafter the receiver operation falls into
987 the scope of this specification. According to [2], the transport
988 parameters of an ALC/LCT session that the receiver needs to know are:
990 * The source IP address;
992 * The number of channels in the session;
994 * The destination IP address and port number for each channel in the
995 session;
997 * The Transport Session Identifier (TSI) of the session;
999 * An indication that the session is a FLUTE session. The need to
1000 demultiplex objects upon reception is implicit in any use of
1001 FLUTE, and this fulfills the ALC requirement of an indication of
1002 whether or not a session carries packets for more than one object
1003 (all FLUTE sessions carry packets for more than one object).
1005 Optionally, the following parameters MAY be associated with the
1006 session (Note, the list is not exhaustive):
1008 * The start time and end time of the session;
1010 * FEC Encoding ID and FEC Instance ID when the default FEC Encoding
1011 ID 0 is not used for the delivery of FDT;
1013 * Content Encoding format if optional content encoding of FDT
1014 Instance is used, e.g., compression;
1016 * Some information that tells receiver, in the first place, that the
1017 session contains files that are of interest;
1019 * Definition and configuration of congestion control mechanism for
1020 the session ;
1022 * Security parameters relevant for the session.
1024 It is envisioned that these parameters would be described according
1025 to some session description syntax (such as SDP [14] or XML based)
1026 and held in a file which would be acquired by the receiver before the
1027 FLUTE session begins by means of some transport protocol (such as
1028 Session Announcement Protocol [13], email, HTTP [7], SIP [21], manual
1029 pre-configuration, etc.) However, the way in which the receiver
1030 discovers the above-mentioned parameters is out of scope of this
1031 document, as it is for LCT and ALC. In particular, this
1032 specification does not mandate or exclude any mechanism.
1034 7. Security Considerations
1036 7.1. Problem Statement
1038 A content delivery system is potentially subject to attacks. Attacks
1039 may target:
1041 * the network (to compromise the routing infrastructure, e.g., by
1042 creating congestion),
1044 * the Content Delivery Protocol (CDP) (e.g., to compromise the
1045 normal behaviour of FLUTE) or
1047 * the content itself (e.g., to corrupt the files being transmitted).
1049 These attacks can be launched either:
1051 * against the data flow itself (e.g., by sending forged packets),
1053 * against the session control parameters (e.g., by corrupting the
1054 session description, the FDT Instances, or the ALC/LCT control
1055 parameters) that are sent either in-band or out-of-band or
1057 * against some associated building blocks (e.g., the congestion
1058 control component).
1060 In the following sections we provide more details on these possible
1061 attacks and sketch some possible counter-measures.
1063 7.2. Attacks against the data flow
1065 Let us consider attacks against the data flow first. At least, the
1066 following types of attacks exist:
1068 * attacks that are meant to give access to a confidential file
1069 (e.g., in case of a non-free content) and
1071 * attacks that try to corrupt the file being transmitted (e.g., to
1072 inject malicious code within a file, or to prevent a receiver from
1073 using a file, which is a kind of Denial of Service, DoS).
1075 7.2.1. Access to confidential files
1077 Access control to the file being transmitted is typically provided by
1078 means of encryption. This encryption can be done over the whole file
1079 (e.g., by the content provider, before submitting the file to FLUTE),
1080 or be done on a packet per packet basis (e.g., when IPSec/ESP is used
1081 [25]). If confidentiality is a concern, it is RECOMMENDED that one
1082 of these solutions be used.
1084 7.2.2. File corruption
1086 Protection against corruptions (e.g., after sending forged packets)
1087 is achieved by means of a content integrity verification/sender
1088 authentication scheme. This service can be provided at the file
1089 level, but in that case a receiver has no way to identify which
1090 symbol(s) is(are) corrupted if the file is detected as corrupted.
1091 This service can also be provided at the packet level. In this case,
1092 after removing all corrupted packets, the file may be in some cases
1093 recovered. Several techniques can provide this source
1094 authentication/content integrity service:
1096 * at the file level, the file MAY be digitally signed (with public
1097 key cryptography), for instance by using RSASSA-PKCS1-v1_5 [23].
1098 This signature enables a receiver to check the file integrity,
1099 once this latter has been fully decoded. Even if digital
1100 signatures are computationally expensive, this calculation occurs
1101 only once per file, which is usually acceptable;
1103 * at the packet level, each packet can be digitally signed. A major
1104 limitation is the high computational and transmission overheads
1105 that this solution requires. To avoid this problem, the signature
1106 may span a set of symbols (instead of a single one) in order to
1107 amortize the signature calculation, but if a single symbol is
1108 missing, the integrity of the whole set cannot be checked;
1110 * at the packet level, a Group Message Authentication Code (MAC)
1111 [26] scheme can be used, for instance by using HMAC-SHA-1 with a
1112 secret key shared by all the group members, senders and receivers.
1113 This technique creates a cryptographically secured digest of a
1114 packet that is sent along with the packet. The Group MAC scheme
1115 does not create prohibitive processing load nor transmission
1116 overhead, but it has a major limitation: it only provides a group
1117 authentication/integrity service since all group members share the
1118 same secret group key, which means that each member can send a
1119 forged packet. It is therefore restricted to situations where
1120 group members are fully trusted (or in association with another
1121 technique as a pre-check);
1123 * at the packet level, TESLA [27] is an attractive solution that is
1124 robust to losses, provides a true authentication/integrity
1125 service, and does not create any prohibitive processing load or
1126 transmission overhead. Yet checking a packet requires a small
1127 delay (a second or more) after its reception; or;
1129 * at the packet level, IPSec/AH [24] (possibly associated to IPSec/
1130 ESP) can be used to protect all the packets being exchanged in a
1131 session.
1133 Techniques relying on public key cryptography (digital signatures and
1134 TESLA during the bootstrap process, when used) require that public
1135 keys be securely associated to the entities. This can be achieved by
1136 a Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by
1137 pre-distributing the public keys of each group member.
1139 Techniques relying on symmetric key cryptography (Group MAC) require
1140 that a secret key be shared by all group members. This can be
1141 achieved by means of a group key management protocol, or simply by
1142 pre-distributing the secret key (but this manual solution has many
1143 limitations).
1145 It is up to the developer and deployer, who know the security
1146 requirements and features of the target application area, to define
1147 which solution is the most appropriate. Nonetheless, in case there
1148 is any concern of the threat of file corruption, it is RECOMMENDED
1149 that at least one of these techniques be used.
1151 7.3. Attacks against the session control parameters and associated
1152 Building Blocks
1154 Let us now consider attacks against the session control parameters
1155 and the associated building blocks. The attacker has at least the
1156 following opportunities to launch an attack:
1158 * the attack can target the session description,
1160 * the attack can target the FDT Instances,
1162 * the attack can target the ALC/LCT parameters, carried within the
1163 LCT header or
1165 * the attack can target the FLUTE associated building blocks.
1167 The latter one is particularly true with the multiple rate congestion
1168 control protocol which may be required.
1170 The consequences of these attacks are potentially serious, since they
1171 might compromise the behavior of content delivery system.
1173 7.3.1. Attacks against the Session Description
1175 A FLUTE receiver may potentially obtain an incorrect Session
1176 Description for the session. The consequence of this is that
1177 legitimate receivers with the wrong Session Description are unable to
1178 correctly receive the session content, or that receivers
1179 inadvertently try to receive at a much higher rate than they are
1180 capable of, thereby possibly disrupting other traffic in the network.
1182 To avoid these problems, it is RECOMMENDED that measures be taken to
1183 prevent receivers from accepting incorrect Session Descriptions. One
1184 such measure is source authentication to ensure that receivers only
1185 accept legitimate Session Descriptions from authorized senders. How
1186 these measures are achived is outside the scope of this document
1187 since this session description is usually carried out-of-band.
1189 7.3.2. Attacks against the FDT Instances
1191 Corrupting the FDT Instances is one way to create a Denial of Service
1192 attack. For example, the attacker changes the MD5 sum associated to
1193 a file. This possibly leads a receiver to reject the files received,
1194 no matter whether the files have been correctly received or not.
1196 Corrupting the FDT Instances is also a way to make the reception
1197 process more costly than it should be. This can be achieved by
1198 changing the FEC Object Transmission Information when the FEC Object
1199 Transmission Information is included in the FDT Instance. For
1200 example, an attacker may corrupt the FDT Instance in such a way that
1201 Reed-Solomon over GF(2^^16) be used instead of GF(2^^8) with FEC
1202 Encoding ID 2. This may significantly increase the processing load
1203 while compromising FEC decoding.
1205 It is therefore RECOMMENDED that measures be taken to guarantee the
1206 integrity and to check the sender's identity of the FDT Instances.
1207 To that purpose, one of the counter-measures mentioned above
1208 (Section 7.2.2) SHOULD be used. These measures will either be
1209 applied on a packet level, or globally over the whole FDT Instance
1210 object. Additionally, XML digital signatures [18] are a way to
1211 protect the FDT Instance by digitally signing it. When there is no
1212 packet level integrity verification scheme, it is RECOMMENDED to rely
1213 on XML digital signatures of the FDT Instances.
1215 7.3.3. Attacks against the ALC/LCT parameters
1217 By corrupting the ALC/LCT header (or header extensions) one can
1218 execute attacks on underlying ALC/LCT implementation. For example,
1219 by sending forged ALC packets with the Close Session flag (A) set one
1220 can lead the receiver to prematurely close the session. Similarly,
1221 by sending forged ALC packets with the Close Object flag (B) set one
1222 can lead the receiver to prematurely give up the reception of an
1223 object.
1225 It is therefore RECOMMENDED that measures be taken to guarantee the
1226 integrity and to check the sender's identity of the ALC packets
1227 received. To that purpose, one of the counter-measures mentioned
1228 above (Section 7.2.2) SHOULD be used.
1230 7.3.4. Attacks against the associated Building Blocks
1232 Let us first focus on the congestion control building block, that may
1233 be used in the ALC session. A receiver with an incorrect or
1234 corrupted implementation of the multiple rate congestion control
1235 building block may affect the health of the network in the path
1236 between the sender and the receiver. That may also affect the
1237 reception rates of other receivers who joined the session.
1239 When congestion control building block is applied with FLUTE, it is
1240 therefore RECOMMENDED that receivers be required to identify
1241 themselves as legitimate before they receive the Session Description
1242 needed to join the session. How receivers identify themselves as
1243 legitimate is outside the scope of this document. If authenticating
1244 a receiver does not prevent this latter to launch an attack, it will
1245 enable the network operator to identify him and to take counter-
1246 measures.
1248 When congestion control building block is applied with FLUTE, it is
1249 also RECOMMENDED that a packet level authentication scheme be used,
1250 as explained in Section 7.2.2. Some of them, like TESLA, only
1251 provide a delayed authentication service, whereas congestion control
1252 requires a rapid reaction. It is therefore RECOMMENDED [2] that a
1253 receiver using TESLA quickly reduces its subscription level when the
1254 receiver believes that a congestion did occur, even if the packet has
1255 not yet been authenticated. Therefore TESLA will not prevent DoS
1256 attacks where an attacker makes the receiver believe that a
1257 congestion occurred. This is an issue for the receiver, but this
1258 will not compromise the network since no congestion actually
1259 occurred. Other authentication methods that do not feature this
1260 delayed authentication could be prefered, or a group MAC scheme could
1261 be used in parallel to TESLA.
1263 7.4. Other Security Considerations
1265 Lastly, we note that the security considerations that apply to, and
1266 are described in, ALC [2], LCT [3] and FEC [4] also apply to FLUTE as
1267 FLUTE builds on those specifications. In addition, any security
1268 considerations that apply to any congestion control building block
1269 used in conjunction with FLUTE also apply to FLUTE.
1271 8. IANA Considerations
1273 This specification contains three separate items for IANA
1274 Considerations:
1276 1. Registration Request for XML Schema of FDT Instance
1277 (urn:ietf:params:xml:schema:fdt).
1279 2. Media-Type Registration Request for application/fdt+xml.
1281 3. Content Encoding Algorithm Registration Request (ietf:rmt:cenc).
1283 8.1. Registration Request for XML Schema of FDT Instance
1285 Document [22] defines an IANA maintained registry of XML documents
1286 used within IETF protocols. The following is the registration
1287 request for the FDT XML schema.
1289 URI: urn:ietf:params:xml:schema:fdt
1291 Registrant Contact: Toni Paila (toni.paila (at) nokia.com)
1293 XML: The XML Schema specified in Section 3.4.2
1295 8.2. Media-Type Registration Request for application/fdt+xml
1297 This section provides the registration request, as per [19], [20] and
1298 [10], to be submitted to IANA following IESG approval.
1300 Type name: application
1301 Subtype name: fdt+xml
1303 Required parameters: none
1305 Optional parameters: none
1307 Encoding considerations: The fdt+xml type consists of UTF-8 ASCII
1308 characters [11] and must be well-formed XML.
1310 Additional content and transfer encodings may be used with fdt+xml
1311 files, with the appropriate encoding for any specific file being
1312 entirely dependant upon the deployed application.
1314 Restrictions on usage: Only for usage with FDT Instances which are
1315 valid according to the XML schema of section 3.4.2.
1317 Security considerations: fdt+xml data is passive, and does not
1318 generally represent a unique or new security threat. However, there
1319 is some risk in sharing any kind of data, in that unintentional
1320 information may be exposed, and that risk applies to fdt+xml data as
1321 well.
1323 Interoperability considerations: None
1325 Published specification: The present document including section
1326 3.4.2. The specified FDT Instance functions as an actual media
1327 format of use to the general Internet community and thus media type
1328 registration under the Standards Tree is appropriate to maximize
1329 interoperability.
1331 Applications which use this media type: Not restricted to any
1332 particular application
1334 Additional information:
1336 Magic number(s): none
1337 File extension(s): An FDT Instance may use the extension ".fdt"
1338 but this is not required.
1339 Macintosh File Type Code(s): none
1341 Person & email address to contact for further information: Toni Paila
1342 (toni.paila (at) nokia.com)
1344 Intended usage: Common
1346 Author/Change controller: IETF
1348 8.3. Content Encoding Algorithm Registration Request
1350 Values of Content Encoding Algorithms are subject to IANA
1351 registration. The value of Content Encoding Algorithm is a numeric
1352 non-negative index. In this document, the range of values for
1353 Content Encoding Algorithms is 0 to 255. This specification already
1354 assigns the values 0, 1, 2 and 3 as described in section 3.4.3.
1356 8.3.1. Explicit IANA Assignment Guidelines
1358 This document defines a name-space for Content Encoding Algorithms
1359 named:
1361 ietf:rmt:cenc
1363 IANA has established and manages the new registry for the "ietf:rmt:
1364 cenc" name-space. The values that can be assigned within the "ietf:
1365 rmt:cenc" name-space are numeric indexes in the range [0, 255],
1366 boundaries included. Assignment requests are granted on a
1367 "Specification Required" basis as defined in RFC 2434 [12]. Note
1368 that the values 0, 1, 2 and 3 of "ietf:rmt:cenc" are already assigned
1369 by this document as described in section 3.4.3.
1371 9. Acknowledgements
1373 The following persons have contributed to this specification: Brian
1374 Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma,
1375 Topi Pohjolainen, Lorenzo Vicisano, and Mark Watson. The authors
1376 would like to thank all the contributors for their valuable work in
1377 reviewing and providing feedback regarding this specification.
1379 10. Contributors
1381 Jani Peltotalo
1382 Tampere University of Technology
1383 P.O. Box 553 (Korkeakoulunkatu 1)
1384 Tampere FIN-33101
1385 Finland
1386 Email: jani.peltotalo (at) tut.fi
1388 Sami Peltotalo
1389 Tampere University of Technology
1390 P.O. Box 553 (Korkeakoulunkatu 1)
1391 Tampere FIN-33101
1392 Finland
1393 Email: sami.peltotalo (at) tut.fi
1394 Magnus Westerlund
1395 Ericsson Research
1396 Ericsson AB
1397 SE-164 80 Stockholm
1398 Sweden
1399 EMail: magnus.westerlund (at) ericsson.com
1401 Thorsten Lohmar
1402 Ericsson Research (EDD)
1403 Ericsson Allee 1
1404 52134 Herzogenrath, Germany
1405 EMail: thorsten.lohmar (at) ericsson.com
1407 11. Change Log
1409 11.1. RFC3926 to draft-ietf-rmt-flute-revised-07
1411 Removed the 'Statement of Intent' from the Section 1. The statement
1412 of intent was meant to clarify the "Experimental" status of RFC3926.
1413 It does not apply to this draft that is intended for "Standard Track"
1414 submission.
1416 Added clarification on XML-DSIG in the end of Section 3.
1418 Revised the use of word "complete" in the Section 3.2.
1420 Clarified Figure 1 vrt. "Encoding Symbol(s) for FDT Instance".
1422 Clarified the FDT Instance ID wrap-around in the end of
1423 Section 3.4.1.
1425 Clarification for "Complete FDT" in the Section 3.4.2.
1427 Added semantics for the case two TOIs refer to same Content-Location.
1428 Now it is in line how 3GPP and DVB interpret the case.
1430 In the Section 3.4.2 XML Schema of FDT instance is modified to
1431 various advices. For example, extension by element was missing but
1432 is now supported. Also namespace definition is changed to URN
1433 format.
1435 Clarified FDT-schema extensibility in the end of Section 3.4.2.
1437 The CENC value allocation is added in the end of Section 3.4.3.
1439 Section 5 is modified so that EXT_FTI and the FEC issues are replaced
1440 by a reference to LCT specification. We count on revised LCT
1441 specification to specify the EXT_FTI.
1443 Added a clarifying paragraph on the use of Codepoint in the very end
1444 of Section 5.
1446 Reworked Section 8 - IANA Considerations. Now it contains three IANA
1447 registration requests:
1449 * Registration Request for XML Schema of FDT Instance
1450 (urn:ietf:params:xml:schema:fdt)
1452 * Media-Type Registration Request for application/fdt+xml
1454 * Content Encoding Algorithm Registration Request (ietf:rmt:cenc)
1456 Added Section 10 - Contributors.
1458 Revised list of both Normative as well as Informative references.
1460 Added a clarification that receiver should ignore reserved bits of
1461 Header Extension type 193 upon reception.
1463 12. References
1465 12.1. Normative references
1467 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1468 Levels", RFC 2119, BCP 14, March 1997.
1470 [2] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered
1471 Coding (ALC) Protocol Instantiation",
1472 draft-ietf-rmt-pi-alc-revised-07 (work in progress), July 2009.
1474 [3] Luby, M., Watson, M., and L. Vicisano, "Layered Coding
1475 Transport (LCT) Building Block",
1476 draft-ietf-rmt-bb-lct-revised-10 (work in progress), July 2009.
1478 [4] Watson, M., Luby, M., and L. Vicisano, "Forward Error
1479 Correction (FEC) Building Block", RFC 5052, August 2007.
1481 [5] Watson, M., "Basic Forward Error Correction (FEC) Schemes",
1482 RFC 5445, March 2009.
1484 [6] Mills, D., "Network Time Protocol (Version 3), Specification,
1485 Implementation and Analysis", RFC 1305, March 1992.
1487 [7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
1488 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
1489 HTTP/1.1", RFC 2616, June 1999.
1491 [8] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML
1492 Schema Part 1: Structures", W3C Recommendation, May 2001.
1494 [9] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes",
1495 W3C Recommendation, May 2001.
1497 [10] Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types",
1498 RFC 3023, January 2001.
1500 [11] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
1501 RFC 3629, November 2003.
1503 [12] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
1504 Considerations Section in RFCs", RFC 5226, May 2008.
1506 12.2. Informative references
1508 [13] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
1509 Protocol", RFC 2974, October 2000.
1511 [14] Handley, M., Jacobson, V., and C. Perkins, "Session Description
1512 Protocol", RFC 4566, July 2006.
1514 [15] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
1515 STD 5, August 1989.
1517 [16] Holbrook, H., "A Channel Model for Multicast, Ph.D.
1518 Dissertation, Stanford University, Department of Computer
1519 Science, Stanford, California", August 2001.
1521 [17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
1522 (S/MIME) Version 3.1 Message Specification", RFC 3851,
1523 July 2004.
1525 [18] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
1526 Language) XML-Signature Syntax and Processing", RFC 3275,
1527 March 2002.
1529 [19] Freed, N. and J. Klensin, "Media Type Specifications and
1530 Registration Procedures", RFC 4288, December 2005.
1532 [20] Freed, N. and J. Klensin, "Multipurpose Internet Mail
1533 Extensions (MIME) Part Four: Registration Procedures",
1534 RFC 4289, December 2005.
1536 [21] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
1537 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
1538 session initiation protocol", RFC 3261, June 2002.
1540 [22] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
1542 [23] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
1543 (PKCS) #1: RSA Cryptography Specifications Version 2.1",
1544 RFC 3447, February 2003.
1546 [24] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
1548 [25] Kent, S., "Encapsulating Security Payload (ESP)", RFC 4303,
1549 December 2005.
1551 [26] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
1552 for Message Authentication", RFC 2104, February 1997.
1554 [27] Perrig, A., Canetti, R., Tygar, J D., and B. Briscoe, "Timed
1555 Efficient Stream Loss-Tolerant Authentication (TESLA):
1556 Multicast Source Authentication Transform Introduction",
1557 RFC 4082, June 2005.
1559 [28] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
1560 Specification version 3.3", RFC 1950, May 1996.
1562 [29] Deutsch, P., "DEFLATE Compressed Data Format Specification
1563 version 1.3", RFC 1951, May 1996.
1565 [30] Deutsch, P., "GZIP file format specification version 4.3",
1566 RFC 1952, May 1996.
1568 Appendix A. Receiver operation (informative)
1570 This section gives an example how the receiver of the file delivery
1571 session may operate. Instead of a detailed state-by-state
1572 specification the following should be interpreted as a rough sequence
1573 of an envisioned file delivery receiver.
1575 1. The receiver obtains the description of the file delivery session
1576 identified by the pair: (source IP address, Transport Session
1577 Identifier). The receiver also obtains the destination IP
1578 addresses and respective ports associated with the file delivery
1579 session.
1581 2. The receiver joins the channels in order to receive packets
1582 associated with the file delivery session. The receiver may
1583 schedule this join operation utilizing the timing information
1584 contained in a possible description of the file delivery session.
1586 3. The receiver receives ALC/LCT packets associated with the file
1587 delivery session. The receiver checks that the packets match the
1588 declared Transport Session Identifier. If not, packets are
1589 silently discarded.
1591 4. While receiving, the receiver demultiplexes packets based on
1592 their TOI and stores the relevant packet information in an
1593 appropriate area for recovery of the corresponding file.
1594 Multiple files can be reconstructed concurrently.
1596 5. Receiver recovers an object. An object can be recovered when an
1597 appropriate set of packets containing Encoding Symbols for the
1598 transmission object have been received. An appropriate set of
1599 packets is dependent on the properties of the FEC Encoding ID and
1600 FEC Instance ID, and on other information contained in the FEC
1601 Object Transmission Information.
1603 6. If the recovered object was an FDT Instance with FDT Instance ID
1604 'N', the receiver parses the payload of the instance 'N' of FDT
1605 and updates its FDT database accordingly. The receiver
1606 identifies FDT Instances within a file delivery session by the
1607 EXT_FDT header extension. Any object that is delivered using
1608 EXT_FDT header extension is an FDT Instance, uniquely identified
1609 by the FDT Instance ID. Note that TOI '0' is exclusively
1610 reserved for FDT delivery.
1612 7. If the object recovered is not an FDT Instance but a file, the
1613 receiver looks up its FDT database to get the properties
1614 described in the database, and assigns file with the given
1615 properties. The receiver also checks that received content
1616 length matches with the description in the database. Optionally,
1617 if MD5 checksum has been used, the receiver checks that
1618 calculated MD5 matches with the description in the FDT database.
1620 8. The actions the receiver takes with imperfectly received files
1621 (missing data, mismatching digestive, etc.) is outside the scope
1622 of this specification. When a file is recovered before the
1623 associated file description entry is available, a possible
1624 behavior is to wait until an FDT Instance is received that
1625 includes the missing properties.
1627 9. If the file delivery session end time has not been reached go
1628 back to 3. Otherwise end.
1630 Appendix B. Example of FDT Instance (informative)
1632
1633
1637
1641
1649
1651 Authors' Addresses
1653 Toni Paila
1654 Nokia
1655 Itamerenkatu 11-13
1656 Helsinki 00180
1657 Finland
1659 Email: toni.paila@nokia.com
1661 Rod Walsh
1662 Nokia
1663 Visiokatu 1
1664 Tampere FIN-33720
1665 Finland
1667 Email: rod.walsh@nokia.com
1668 Michael Luby
1669 Digital Fountain
1670 39141 Civic Center Dr.
1671 Suite 300
1672 Fremont, CA 94538
1673 USA
1675 Email: luby@digitalfountain.com
1677 Rami Lehtonen
1678 TeliaSonera
1679 Hatanpaan valtatie 18
1680 Tampere FIN-33100
1681 Finland
1683 Email: rami.lehtonen@teliasonera.com
1685 Vincent Roca
1686 INRIA Rhone-Alpes
1687 655, av. de l'Europe
1688 Montbonnot
1689 St Ismier cedex 38334
1690 France
1692 Email: vincent.roca@inrialpes.fr