idnits 2.17.1
draft-ietf-rmt-flute-revised-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 21.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 1690.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1701.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1708.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1714.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (October 26, 2007) is 6028 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 1352, but not defined
== Missing Reference: '255' is mentioned on line 1352, but not defined
== Unused Reference: '28' is defined on line 1545, but no explicit
reference was found in the text
== Outdated reference: A later version (-10) exists of
draft-ietf-rmt-pi-alc-revised-03
== Outdated reference: A later version (-11) exists of
draft-ietf-rmt-bb-lct-revised-04
== Outdated reference: A later version (-07) exists of
draft-ietf-rmt-fec-bb-revised-02
** Obsolete normative reference: RFC 1305 (ref. '5') (Obsoleted by RFC 5905)
** Obsolete normative reference: RFC 2616 (ref. '6') (Obsoleted by RFC
7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
-- Possible downref: Non-RFC (?) normative reference: ref. '7'
-- Possible downref: Non-RFC (?) normative reference: ref. '8'
** Obsolete normative reference: RFC 3023 (ref. '9') (Obsoleted by RFC 7303)
** Obsolete normative reference: RFC 2279 (ref. '10') (Obsoleted by RFC
3629)
** Obsolete normative reference: RFC 2434 (ref. '11') (Obsoleted by RFC
5226)
-- Obsolete informational reference (is this intentional?): RFC 2327 (ref.
'14') (Obsoleted by RFC 4566)
-- Obsolete informational reference (is this intentional?): RFC 2633 (ref.
'19') (Obsoleted by RFC 3851)
-- Obsolete informational reference (is this intentional?): RFC 2048 (ref.
'21') (Obsoleted by RFC 4288, RFC 4289)
-- Obsolete informational reference (is this intentional?): RFC 3447 (ref.
'24') (Obsoleted by RFC 8017)
Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 13 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 Expires: April 28, 2008 Nokia
5 M. Luby
6 Digital Fountain
7 R. Lehtonen
8 TeliaSonera
9 V. Roca
10 INRIA Rhone-Alpes
11 October 26, 2007
13 FLUTE - File Delivery over Unidirectional Transport
14 draft-ietf-rmt-flute-revised-05
16 Status of this Memo
18 By submitting this Internet-Draft, each author represents that any
19 applicable patent or other IPR claims of which he or she is aware
20 have been or will be disclosed, and any of which he or she becomes
21 aware will be disclosed, in accordance with Section 6 of BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF), its areas, and its working groups. Note that
25 other groups may also distribute working documents as Internet-
26 Drafts.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 The list of current Internet-Drafts can be accessed at
34 http://www.ietf.org/ietf/1id-abstracts.txt.
36 The list of Internet-Draft Shadow Directories can be accessed at
37 http://www.ietf.org/shadow.html.
39 This Internet-Draft will expire on April 28, 2008.
41 Copyright Notice
43 Copyright (C) The IETF Trust (2007).
45 Abstract
47 This document defines FLUTE, a protocol for the unidirectional
48 delivery of files over the Internet, which is particularly suited to
49 multicast networks. The specification builds on Asynchronous Layered
50 Coding, the base protocol designed for massively scalable multicast
51 distribution.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
56 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 5
57 1.1.1. The Target Application Space . . . . . . . . . . . . . 5
58 1.1.2. The Target Scale . . . . . . . . . . . . . . . . . . . 5
59 1.1.3. Intended Environments . . . . . . . . . . . . . . . . 5
60 1.1.4. Weaknesses . . . . . . . . . . . . . . . . . . . . . . 6
61 2. Conventions used in this Document . . . . . . . . . . . . . . 6
62 3. File delivery . . . . . . . . . . . . . . . . . . . . . . . . 6
63 3.1. File delivery session . . . . . . . . . . . . . . . . . . 7
64 3.2. File Delivery Table . . . . . . . . . . . . . . . . . . . 9
65 3.3. Dynamics of FDT Instances within file delivery session . . 11
66 3.4. Structure of FDT Instance packets . . . . . . . . . . . . 12
67 3.4.1. Format of FDT Instance Header . . . . . . . . . . . . 13
68 3.4.2. Syntax of FDT Instance . . . . . . . . . . . . . . . . 14
69 3.4.3. Content Encoding of FDT Instance . . . . . . . . . . . 18
70 3.5. Multiplexing of files within a file delivery session . . . 19
71 4. Channels, congestion control and timing . . . . . . . . . . . 19
72 5. Delivering FEC Object Transmission Information . . . . . . . . 20
73 6. Describing file delivery sessions . . . . . . . . . . . . . . 22
74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
75 7.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 23
76 7.2. Attacks against the data flow . . . . . . . . . . . . . . 24
77 7.2.1. Access to confidential files . . . . . . . . . . . . . 24
78 7.2.2. File corruption . . . . . . . . . . . . . . . . . . . 24
79 7.3. Attacks against the session control parameters and
80 associated Building Blocks . . . . . . . . . . . . . . . . 25
81 7.3.1. Attacks against the Session Description . . . . . . . 26
82 7.3.2. Attacks against the FDT Instances . . . . . . . . . . 26
83 7.3.3. Attacks against the ALC/LCT parameters . . . . . . . . 27
84 7.3.4. Attacks against the associated Building Blocks . . . . 27
85 7.4. Other Security Considerations . . . . . . . . . . . . . . 28
86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
87 8.1. Registration Request for XML Schema of FDT Instance . . . 28
88 8.2. Media-Type Registration Request for application/fdt+xml . 28
89 8.3. Content Encoding Algorithm Registration Request . . . . . 30
90 8.3.1. Explicit IANA Assignment Guidelines . . . . . . . . . 30
91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
92 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
93 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 31
94 11.1. RFC3926 to draft-ietf-rmt-flute-revised-01 . . . . . . . . 31
95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
96 12.1. Normative references . . . . . . . . . . . . . . . . . . . 32
97 12.2. Informative references . . . . . . . . . . . . . . . . . . 33
98 Appendix A. Receiver operation (informative) . . . . . . . . . . 34
99 Appendix B. Example of FDT Instance (informative) . . . . . . . . 36
100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
101 Intellectual Property and Copyright Statements . . . . . . . . . . 38
103 1. Introduction
105 This document defines FLUTE version 1, a protocol for unidirectional
106 delivery of files over the Internet. The specification builds on
107 Asynchronous Layered Coding (ALC), version 1 [2], the base protocol
108 designed for massively scalable multicast distribution. ALC defines
109 transport of arbitrary binary objects. For file delivery
110 applications mere transport of objects is not enough, however. The
111 end systems need to know what the objects actually represent. This
112 document specifies a technique called FLUTE - a mechanism for
113 signaling and mapping the properties of files to concepts of ALC in a
114 way that allows receivers to assign those parameters for received
115 objects. Consequently, throughout this document the term 'file'
116 relates to an 'object' as discussed in ALC. Although this
117 specification frequently makes use of multicast addressing as an
118 example, the techniques are similarly applicable for use with unicast
119 addressing.
121 This document defines a specific transport application of ALC, adding
122 the following specifications:
124 - Definition of a file delivery session built on top of ALC,
125 including transport details and timing constraints.
127 - In-band signalling of the transport parameters of the ALC session.
129 - In-band signalling of the properties of delivered files.
131 - Details associated with the multiplexing of multiple files within
132 a session.
134 This specification is structured as follows. Section 3 begins by
135 defining the concept of the file delivery session. Following that it
136 introduces the File Delivery Table that forms the core part of this
137 specification. Further, it discusses multiplexing issues of
138 transmission objects within a file delivery session. Section 4
139 describes the use of congestion control and channels with FLUTE.
140 Section 5 defines how the Forward Error Correction (FEC) Object
141 Transmission Information is to be delivered within a file delivery
142 session. Section 6 defines the required parameters for describing
143 file delivery sessions in a general case. Section 7 outlines
144 security considerations regarding file delivery with FLUTE. Last,
145 there are two informative appendices. The first appendix describes
146 an envisioned receiver operation for the receiver of the file
147 delivery session. The second appendix gives an example of File
148 Delivery Table.
150 This specification contains part of the definitions necessary to
151 fully specify a Reliable Multicast Transport protocol in accordance
152 with RFC2357.
154 RFC3926 contained a previous version of this specification, which was
155 published in the "Experimental" category. It was the stated intent
156 of the RMT working group to re-submit this specification as an IETF
157 Proposed Standard in due course.
159 This Proposed Standard specification is thus based on RFC3926 updated
160 according to accumulated experience and growing protocol maturity
161 since the publication of RFC3926. Said experience applies both to
162 this specification itself and to congestion control strategies
163 related to the use of this specification.
165 The differences between RFC3926 and this document listed in
166 Section 11.
168 1.1. Applicability Statement
170 1.1.1. The Target Application Space
172 FLUTE is applicable to the delivery of large and small files to many
173 hosts, using delivery sessions of several seconds or more. For
174 instance, FLUTE could be used for the delivery of large software
175 updates to many hosts simultaneously. It could also be used for
176 continuous, but segmented, data such as time-lined text for
177 subtitling - potentially leveraging its layering inheritance from ALC
178 and LCT to scale the richness of the session to the congestion status
179 of the network. It is also suitable for the basic transport of
180 metadata, for example SDP [14] files which enable user applications
181 to access multimedia sessions.
183 1.1.2. The Target Scale
185 Massive scalability is a primary design goal for FLUTE. IP multicast
186 is inherently massively scalable, but the best effort service that it
187 provides does not provide session management functionality,
188 congestion control or reliability. FLUTE provides all of this using
189 ALC and IP multicast without sacrificing any of the inherent
190 scalability of IP multicast.
192 1.1.3. Intended Environments
194 All of the environmental requirements and considerations that apply
195 to the ALC building block [2] and to any additional building blocks
196 that FLUTE uses also apply to FLUTE.
198 FLUTE can be used with both multicast and unicast delivery, but it's
199 primary application is for unidirectional multicast file delivery.
200 FLUTE requires connectivity between a sender and receivers but does
201 not require connectivity from receivers to a sender. FLUTE
202 inherently works with all types of networks, including LANs, WANs,
203 Intranets, the Internet, asymmetric networks, wireless networks, and
204 satellite networks.
206 FLUTE is compatible with both IPv4 or IPv6 as no part of the packet
207 is IP version specific. FLUTE works with both multicast models: Any-
208 Source Multicast (ASM) [15] and the Source-Specific Multicast (SSM)
209 [16].
211 FLUTE is applicable for both Internet use, with a suitable congestion
212 control building block, and provisioned/controlled systems, such as
213 delivery over wireless broadcast radio systems.
215 1.1.4. Weaknesses
217 Some networks are not amenable to some congestion control protocols
218 that could be used with FLUTE. In particular, for a satellite or
219 wireless network, there may be no mechanism for receivers to
220 effectively reduce their reception rate since there may be a fixed
221 transmission rate allocated to the session.
223 FLUTE provides reliability using the FEC building block. This will
224 reduce the error rate as seen by applications. However, FLUTE does
225 not provide a method for senders to verify the reception success of
226 receivers, and the specification of such a method is outside the
227 scope of this document.
229 2. Conventions used in this Document
231 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
232 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
233 document are to be interpreted as described in RFC 2119 [1].
235 The terms "object" and "transmission object" are consistent with the
236 definitions in ALC [2] and LCT [3]. The terms "file" and "source
237 object" are pseudonyms for "object".
239 3. File delivery
241 Asynchronous Layered Coding [2] is a protocol designed for delivery
242 of arbitrary binary objects. It is especially suitable for massively
243 scalable, unidirectional, multicast distribution. ALC provides the
244 basic transport for FLUTE, and thus FLUTE inherits the requirements
245 of ALC.
247 This specification is designed for the delivery of files. The core
248 of this specification is to define how the properties of the files
249 are carried in-band together with the delivered files.
251 As an example, let us consider a 5200 byte file referred to by
252 "http://www.example.com/docs/file.txt". Using the example, the
253 following properties describe the properties that need to be conveyed
254 by the file delivery protocol.
256 * Identifier of the file, expressed as a URI. This identifier may
257 be globally unique. The identifier may also provide a location
258 for the file. In the above example:
259 "http://www.example.com/docs/file.txt".
261 * File name (usually, this can be concluded from the URI). In the
262 above example: "file.txt".
264 * File type, expressed as MIME media type (usually, this can also be
265 concluded from the extension of the file name). In the above
266 example: "text/plain". If an explicit value for the MIME type is
267 provided separately from the file extension and does not match the
268 MIME type of the file extension then the explicitly provided value
269 MUST be used as the MIME type.
271 * File size, expressed in bytes. In the above example: "5200". If
272 the file is content encoded then this is the file size before
273 content encoding.
275 * Content encoding of the file, within transport. In the above
276 example, the file could be encoded using ZLIB [12]. In this case
277 the size of the transmission object carrying the file would
278 probably differ from the file size. The transmission object size
279 is delivered to receivers as part of the FLUTE protocol.
281 * Security properties of the file such as digital signatures,
282 message digests, etc. For example, one could use S/MIME [19] as
283 the content encoding type for files with this authentication
284 wrapper, and one could use XML-DSIG [20] to digitally sign an FDT
285 Instance. XML-DSIG can also be used to provide tamper prevention
286 e.g. on the Content-Location field.
288 3.1. File delivery session
290 ALC is a protocol instantiation of Layered Coding Transport building
291 block (LCT) [3]. Thus ALC inherits the session concept of LCT. In
292 this document we will use the concept ALC/LCT session to collectively
293 denote the interchangeable terms ALC session and LCT session.
295 An ALC/LCT session consists of a set of logically grouped ALC/LCT
296 channels associated with a single sender sending packets with ALC/LCT
297 headers for one or more objects. An ALC/LCT channel is defined by
298 the combination of a sender and an address associated with the
299 channel by the sender. A receiver joins a channel to start receiving
300 the data packets sent to the channel by the sender, and a receiver
301 leaves a channel to stop receiving data packets from the channel.
303 One of the fields carried in the ALC/LCT header is the Transport
304 Session Identifier (TSI). The TSI is scoped by the source IP
305 address, and the (source IP address, TSI) pair uniquely identifies a
306 session, i.e., the receiver uses this pair carried in each packet to
307 uniquely identify from which session the packet was received. In
308 case multiple objects are carried within a session, the Transmission
309 Object Identifier (TOI) field within the ALC/LCT header identifies
310 from which object the data in the packet was generated. Note that
311 each object is associated with a unique TOI within the scope of a
312 session.
314 If the sender is not assigned a permanent IP address accessible to
315 receivers, but instead, packets that can be received by receivers
316 containing a temporary IP address for packets sent by the sender,
317 then the TSI is scoped by this temporary IP address of the sender for
318 the duration of the session. As an example, the sender may be behind
319 a Network Address Translation (NAT) device that temporarily assigns
320 an IP address for the sender that is accessible to receivers, and in
321 this case the TSI is scoped by the temporary IP address assigned by
322 the NAT that will appear in packets received by the receiver. As
323 another example, the sender may send its original packets using IPv6,
324 but some portions of the network may not be IPv6 capable and thus
325 there may be an IPv6 to IPv4 translator that changes the IP address
326 of the packets to a different IPv4 address. In this case, receivers
327 in the IPv4 portion of the network will receive packets containing
328 the IPv4 address, and thus the TSI for them is scoped by the IPv4
329 address. How the IP address of the sender to be used to scope the
330 session by receivers is delivered to receivers, whether it is a
331 permanent IP address or a temporary IP address, is outside the scope
332 of this document.
334 When FLUTE is used for file delivery over ALC the following rules
335 apply:
337 * The ALC/LCT session is called file delivery session.
339 * The ALC/LCT concept of 'object' denotes either a 'file' or a 'File
340 Delivery Table Instance' (section 3.2)
342 * The TOI field MUST be included in ALC packets sent within a FLUTE
343 session, with the exception that ALC packets sent in a FLUTE
344 session with the Close Session (A) flag set to 1 (signaling the
345 end of the session) and that contain no payload (carrying no
346 information for any file or FDT) SHALL NOT carry the TOI. See
347 Section 5.1 of RFC 3451 [3] for the LCT definition of the Close
348 Session flag, and see Section 4.2 of RFC 3450 [2] for an example
349 of its use within an ALC packet.
351 * The TOI value '0' is reserved for delivery of File Delivery Table
352 Instances. Each File Delivery Table Instance is uniquely
353 identified by an FDT Instance ID.
355 * Each file in a file delivery session MUST be associated with a TOI
356 (>0) in the scope of that session.
358 * Information carried in the headers and the payload of a packet is
359 scoped by the source IP address and the TSI. Information
360 particular to the object carried in the headers and the payload of
361 a packet is further scoped by the TOI for file objects, and is
362 further scoped by both the TOI and the FDT Instance ID for FDT
363 Instance objects.
365 3.2. File Delivery Table
367 The File Delivery Table (FDT) provides a means to describe various
368 attributes associated with files that are to be delivered within the
369 file delivery session. The following lists are examples of such
370 attributes, and are not intended to be mutually exclusive nor
371 exhaustive.
373 Attributes related to the delivery of file:
375 - TOI value that represents the file
377 - FEC Object Transmission Information (including the FEC Encoding ID
378 and, if relevant, the FEC Instance ID)
380 - Size of the transmission object carrying the file
382 - Aggregate rate of sending packets to all channels
384 Attributes related to the file itself:
386 - Name, Identification and Location of file (specified by the URI)
388 - MIME media type of file
390 - Size of file
392 - Encoding of file
394 - Message digest of file
396 Some of these attributes MUST be included in the file description
397 entry for a file, others are optional, as defined in section 3.4.2.
399 Logically, the FDT is a set of file description entries for files to
400 be delivered in the session. Each file description entry MUST
401 include the TOI for the file that it describes and the URI
402 identifying the file. The TOI is included in each ALC/LCT data
403 packet during the delivery of the file, and thus the TOI carried in
404 the file description entry is how the receiver determines which ALC/
405 LCT data packets contain information about which file. Each file
406 description entry may also contain one or more descriptors that map
407 the above-mentioned attributes to the file.
409 Each file delivery session MUST have an FDT that is local to the
410 given session. The FDT MUST provide a file description entry mapped
411 to a TOI for each file appearing within the session. An object that
412 is delivered within the ALC session, but not described in the FDT, is
413 not considered a 'file' belonging to the file delivery session.
414 Handling of these unmapped TOIs (TOIs that are not resolved by the
415 FDT) is out of scope of this specification.
417 Within the file delivery session the FDT is delivered as FDT
418 Instances. An FDT Instance contains one or more file description
419 entries of the FDT. Any FDT Instance can be equal to, a subset of, a
420 superset of, or complement any other FDT Instance. A certain FDT
421 Instance may be repeated several times during a session, even after
422 subsequent FDT Instances (with higher FDT Instance ID numbers) have
423 been transmitted. Each FDT Instance contains at least a single file
424 description entry and at most the exhaustive set of file description
425 entries of the files being delivered in the file delivery session.
427 A receiver of the file delivery session keeps an FDT database for
428 received file description entries. The receiver maintains the
429 database, for example, upon reception of FDT Instances. Thus, at any
430 given time the contents of the FDT database represent the receiver's
431 current view of the FDT of the file delivery session. Since each
432 receiver behaves independently of other receivers, it SHOULD NOT be
433 assumed that the contents of the FDT database are the same for all
434 the receivers of a given file delivery session.
436 Since FDT database is an abstract concept, the structure and the
437 maintaining of the FDT database are left to individual
438 implementations and are thus out of scope of this specification.
440 3.3. Dynamics of FDT Instances within file delivery session
442 The following rules define the dynamics of the FDT Instances within a
443 file delivery session:
445 * For every file delivered within a file delivery session there MUST
446 be a file description entry included in at least one FDT Instance
447 sent within the session. A file description entry contains at a
448 minimum the mapping between the TOI and the URI.
450 * An FDT Instance MAY appear in any part of the file delivery
451 session and packets for an FDT Instance MAY be interleaved with
452 packets for other files or other FDT Instances within a session.
454 * The TOI value of '0' MUST be reserved for delivery of FDT
455 Instances. The use of other TOI values for FDT Instances is
456 outside the scope of this specification.
458 * FDT Instance is identified by the use of a new fixed length LCT
459 Header Extension EXT_FDT (defined later in this section). Each
460 FDT Instance is uniquely identified within the file delivery
461 session by its FDT Instance ID. Any ALC/LCT packet carrying FDT
462 Instance (indicated by TOI = 0) MUST include EXT_FDT.
464 * It is RECOMMENDED that FDT Instance that contains the file
465 description entry for a file is sent prior to the sending of the
466 described file within a file delivery session.
468 * Within a file delivery session, any TOI > 0 MAY be described more
469 than once. An example: previous FDT Instance 0 describes TOI of
470 value '3'. Now, subsequent FDT Instances can either keep TOI '3'
471 unmodified on the table, not include it, or complement the
472 description. However, subsequent FDT Instances MUST NOT change
473 the parameters already described for a specific TOI.
475 * An FDT Instance is valid until its expiration time. The
476 expiration time is expressed within the FDT Instance payload as a
477 32 bit data field. The value of the data field represents the 32
478 most significant bits of a 64 bit Network Time Protocol (NTP) [5]
479 time value. These 32 bits provide an unsigned integer
480 representing the time in seconds relative to 0 hours 1 January
481 1900. Handling of wraparound of the 32 bit time is outside the
482 scope of NTP and FLUTE.
484 * The receiver SHOULD NOT use a received FDT Instance to interpret
485 packets received beyond the expiration time of the FDT Instance.
487 * A sender MUST use an expiry time in the future upon creation of an
488 FDT Instance relative to its Sender Current Time (SCT).
490 * Any FEC Encoding ID MAY be used for the sending of FDT Instances.
491 The default is to use FEC Encoding ID 0 for the sending of FDT
492 Instances. (Note that since FEC Encoding ID 0 is the default for
493 FLUTE, this implies that Source Block Number and Encoding Symbol
494 ID lengths both default to 16 bits each.)
496 Generally, a receiver needs to receive an FDT Instance describing a
497 file before it is able to recover the file itself. In this sense FDT
498 Instances are of higher priority than files. Thus, it is RECOMMENDED
499 that FDT Instances describing a file be sent with at least as much
500 reliability within a session (more often or with more FEC protection)
501 as the files they describe. In particular, if FDT Instances are
502 longer than one packet payload in length it is RECOMMENDED that an
503 FEC code that provides protection against loss be used for delivering
504 FDT Instances. How often the description of a file is sent in an FDT
505 Instance or how much FEC protection is provided for each FDT Instance
506 (if the FDT Instance is longer than one packet payload) is dependent
507 on the particular application and outside the scope of this document.
509 3.4. Structure of FDT Instance packets
511 FDT Instances are carried in ALC packets with TOI = 0 and with an
512 additional REQUIRED LCT Header extension called the FDT Instance
513 Header. The FDT Instance Header (EXT_FDT) contains the FDT Instance
514 ID that uniquely identifies FDT Instances within a file delivery
515 session. The FDT Instance Header is placed in the same way as any
516 other LCT extension header. There MAY be other LCT extension headers
517 in use.
519 The LCT extension headers are followed by the FEC Payload ID, and
520 finally the Encoding Symbols for the FDT Instance which contains one
521 or more file description entries. A FDT Instance MAY span several
522 ALC packets - the number of ALC packets is a function of the file
523 attributes associated with the FDT Instance. The FDT Instance Header
524 is carried in each ALC packet carrying the FDT Instance. The FDT
525 Instance Header is identical for all ALC/LCT packets for a particular
526 FDT Instance.
528 The overall format of ALC/LCT packets carrying an FDT Instance is
529 depicted in the Figure 1 below. All integer fields are carried in
530 "big-endian" or "network order" format, that is, most significant
531 byte (octet) first. As defined in [2], all ALC/LCT packets are sent
532 using UDP.
534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
535 | UDP header |
536 | |
537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
538 | Default LCT header (with TOI = 0) |
539 | |
540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
541 | LCT header extensions (EXT_FDT, EXT_FTI, etc.) |
542 | |
543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
544 | FEC Payload ID |
545 | |
546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
547 FLUTE Payload: Encoding Symbol(s)
548 ~ (for FDT Instance in a FDT packet) ~
550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
552 Figure 1: Overall FDT Packet
554 3.4.1. Format of FDT Instance Header
556 FDT Instance Header (EXT_FDT) is a new fixed length, ALC PI specific
557 LCT header extension [3]. The Header Extension Type (HET) for the
558 extension is 192. Its format is defined below:
560 0 1 2 3
561 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
562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
563 | HET = 192 | V | FDT Instance ID |
564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
566 Figure 2
568 Version of FLUTE (V), 4 bits:
570 This document specifies FLUTE version 1. Hence in any ALC packet
571 that carries FDT Instance and that belongs to the file delivery
572 session as specified in this specification MUST set this field to
573 '1'.
575 FDT Instance ID, 20 bits:
577 For each file delivery session the numbering of FDT Instances starts
578 from '0' and is incremented by one for each subsequent FDT Instance.
579 After reaching the maximum value (2^20-1), the numbering starts from
580 the smallest FDT Instance value assigned to an expired FDT Instance.
581 When wraparound from a greater FDT Instance value to a smaller FDT
582 Instance value occurs, the smaller FDT Instance value is considered
583 logically higher than the greater FDT Instance value. A new FDT
584 Instance reusing a previous FDT Instance ID number, due to
585 wraparound, may not implicitly expire the previous FDT Instance with
586 the same ID. Mandatory receiver behavior for handling FDT Instance
587 ID wraparound and other special situations (for example, missing FDT
588 Instance IDs resulting in larger increments than one) is outside the
589 scope of this specification and left to individual implementations of
590 FLUTE.
592 3.4.2. Syntax of FDT Instance
594 The FDT Instance contains file description entries that provide the
595 mapping functionality described in 3.2 above.
597 The FDT Instance is an XML structure that has a single root element
598 "FDT-Instance". The "FDT-Instance" element MUST contain "Expires"
599 attribute, which tells the expiry time of the FDT Instance. In
600 addition, the "FDT-Instance" element MAY contain the "Complete"
601 attribute (boolean), which, when TRUE, signals that this "FDT
602 Instance" includes the set of "File" entries that exhausts both the
603 set of files delivered so far and also the set of files to be
604 delivered in the session. This implies that no new data will be
605 provided in future FDT Instances within this session (i.e., that
606 either FDT Instances with higher ID numbers will not be used or if
607 they are used, will only provide identical file parameters to those
608 already given in this and previous FDT Instances). The "Complete"
609 attribute is therefore used to provide a complete list of files in an
610 entire FLUTE session (a "complete FDT").
612 The "FDT-Instance" element MAY contain attributes that give common
613 parameters for all files of an FDT Instance. These attributes MAY
614 also be provided for individual files in the "File" element. Where
615 the same attribute appears in both the "FDT-Instance" and the "File"
616 elements, the value of the attribute provided in the "File" element
617 takes precedence.
619 For each file to be declared in the given FDT Instance there is a
620 single file description entry in the FDT Instance. Each entry is
621 represented by element "File" which is a child element of the FDT
622 Instance structure.
624 The attributes of "File" element in the XML structure represent the
625 attributes given to the file that is delivered in the file delivery
626 session. The value of the XML attribute name corresponds to MIME
627 field name and the XML attribute value corresponds to the value of
628 the MIME field body. Each "File" element MUST contain at least two
629 attributes "TOI" and "Content-Location". "TOI" MUST be assigned a
630 valid TOI value as described in section 3.3 above. "Content-
631 Location" MUST be assigned a valid URI as defined in [6]. The
632 semantics for any two "File" elements declaring the same "Content-
633 Location" but differing "TOI" is that the element appearing in the
634 FDT Instance with the greater FDT Instance ID is considered to
635 declare newer instance (e.g. version) of the same "File".
637 In addition to mandatory attributes, the "FDT-Instance" element and
638 the "File" element MAY contain other attributes of which the
639 following are specifically pointed out.
641 * Where the MIME type is described, the attribute "Content-Type"
642 MUST be used for the purpose as defined in [6].
644 * Where the length is described, the attribute "Content-Length" MUST
645 be used for the purpose as defined in [6]. The transfer length is
646 defined to be the length of the object transported in bytes. It
647 is often important to convey the transfer length to receivers,
648 because the source block structure needs to be known for the FEC
649 decoder to be applied to recover source blocks of the file, and
650 the transfer length is often needed to properly determine the
651 source block structure of the file. There generally will be a
652 difference between the length of the original file and the
653 transfer length if content encoding is applied to the file before
654 transport, and thus the "Content-Encoding" attribute is used. If
655 the file is not content encoded before transport (and thus the
656 "Content-Encoding" attribute is not used) then the transfer length
657 is the length of the original file, and in this case the "Content-
658 Length" is also the transfer length. However, if the file is
659 content encoded before transport (and thus the "Content-Encoding"
660 attribute is used), e.g., if compression is applied before
661 transport to reduce the number of bytes that need to be
662 transferred, then the transfer length is generally different than
663 the length of the original file, and in this case the attribute
664 "Transfer-Length" MAY be used to carry the transfer length.
666 * Where the content encoding scheme is described, the attribute
667 "Content-Encoding" MUST be used for the purpose as defined in [6].
669 * Where the MD5 message digest is described, the attribute "Content-
670 MD5" MUST be used for the purpose as defined in [6].
672 * The FEC Object Transmission Information attributes as described in
673 section 5.2.
675 The following specifies the XML Schema [7][8] for FDT Instance:
677 BEGIN
678
679
683
684
685
686
687
689
690
693
696
699
702
705
708
711
714
717
721
722
723
724
725
727
728
731
734
737
740
743
746
749
752
755
758
761
764
767
768
770
771 END
773 Figure 3
775 Any valid FDT Instance must use the above XML Schema. This way FDT
776 provides extensibility to support private attributes within the file
777 description entries. Those could be, for example, the attributes
778 related to the delivery of the file (timing, packet transmission
779 rate, etc.).
781 In case the basic FDT XML Schema is extended in terms of new
782 descriptors (attributes or elements), for descriptors applying to a
783 single file, those MUST be placed within the element "File". For
784 descriptors applying to all files described by the current FDT
785 Instance, those MUST be placed within the element "FDT-Instance". It
786 is RECOMMENDED that the new attributes applied in the FDT are in the
787 format of MIME fields and are either defined in the HTTP/1.1
788 specification [6] or another well-known specification.
790 3.4.3. Content Encoding of FDT Instance
792 The FDT Instance itself MAY be content encoded, for example
793 compressed. This specification defines FDT Instance Content Encoding
794 Header (EXT_CENC). EXT_CENC is a new fixed length, ALC PI specific
795 LCT header extension [3]. The Header Extension Type (HET) for the
796 extension is 193. If the FDT Instance is content encoded, the
797 EXT_CENC MUST be used to signal the content encoding type. In that
798 case, EXT_CENC header extension MUST be used in all ALC packets
799 carrying the same FDT Instance ID. Consequently, when EXT_CENC
800 header is used, it MUST be used together with a proper FDT Instance
801 Header (EXT_FDT). Within a file delivery session, FDT Instances that
802 are not content encoded and FDT Instances that are content encoded
803 MAY both appear. If content encoding is not used for a given FDT
804 Instance, the EXT_CENC MUST NOT be used in any packet carrying the
805 FDT Instance. The format of EXT_CENC is defined below:
807 0 1 2 3
808 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
809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
810 | HET = 193 | CENC | Reserved |
811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
813 Figure 4
815 Content Encoding Algorithm (CENC), 8 bits:
817 This field signals the content encoding algorithm used in the FDT
818 Instance payload. This subsection reserves the Content Encoding
819 Algorithm values 0, 1, 2 and 3 for null, ZLIB [12], DEFLATE [17] and
820 GZIP [18] respectively.
822 Reserved, 16 bits:
824 This field MUST be set to all '0'.
826 3.5. Multiplexing of files within a file delivery session
828 The delivered files are carried as transmission objects (identified
829 with TOIs) in the file delivery session. All these objects,
830 including the FDT Instances, MAY be multiplexed in any order and in
831 parallel with each other within a session, i.e., packets for one file
832 MAY be interleaved with packets for other files or other FDT
833 Instances within a session.
835 Multiple FDT Instances MAY be delivered in a single session using TOI
836 = 0. In this case, it is RECOMMENDED that the sending of a previous
837 FDT Instance SHOULD end before the sending of the next FDT Instance
838 starts. However, due to unexpected network conditions, packets for
839 the FDT Instances MAY be interleaved. A receiver can determine which
840 FDT Instance a packet contains information about since the FDT
841 Instances are uniquely identified by their FDT Instance ID carried in
842 the EXT_FDT headers.
844 4. Channels, congestion control and timing
846 ALC/LCT has a concept of channels and congestion control. There are
847 four scenarios FLUTE is envisioned to be applied.
849 (a) Use a single channel and a single-rate congestion control
850 protocol.
852 (b) Use multiple channels and a multiple-rate congestion control
853 protocol. In this case the FDT Instances MAY be delivered on more
854 than one channel.
856 (c) Use a single channel without congestion control supplied by ALC,
857 but only when in a controlled network environment where flow/
858 congestion control is being provided by other means.
860 (d) Use multiple channels without congestion control supplied by
861 ALC, but only when in a controlled network environment where flow/
862 congestion control is being provided by other means. In this case
863 the FDT Instances MAY be delivered on more than one channel.
865 When using just one channel for a file delivery session, as in (a)
866 and (c), the notion of 'prior' and 'after' are intuitively defined
867 for the delivery of objects with respect to their delivery times.
869 However, if multiple channels are used, as in (b) and (d), it is not
870 straightforward to state that an object was delivered 'prior' to the
871 other. An object may begin to be delivered on one or more of those
872 channels before the delivery of a second object begins. However, the
873 use of multiple channels/layers may complete the delivery of the
874 second object before the first. This is not a problem when objects
875 are delivered sequentially using a single channel. Thus, if the
876 application of FLUTE has a mandatory or critical requirement that the
877 first transmission object must complete 'prior' to the second one, it
878 is RECOMMENDED that only a single channel is used for the file
879 delivery session.
881 Furthermore, if multiple channels are used then a receiver joined to
882 the session at a low reception rate will only be joined to the lower
883 layers of the session. Thus, since the reception of FDT Instances is
884 of higher priority than the reception of files (because the reception
885 of files depends on the reception of an FDT Instance describing it),
886 the following is RECOMMENDED:
888 1. The layers to which packets for FDT Instances are sent SHOULD NOT
889 be biased towards those layers to which lower rate receivers are
890 not joined. For example, it is ok to put all the packets for an
891 FDT Instance into the lowest layer (if this layer carries enough
892 packets to deliver the FDT to higher rate receivers in a
893 reasonable amount of time), but it is not ok to put all the
894 packets for an FDT Instance into the higher layers that only high
895 rate receivers will receive.
897 2. If FDT Instances are generally longer than one Encoding Symbol in
898 length and some packets for FDT Instances are sent to layers that
899 lower rate receivers do not receive, an FEC Encoding other than
900 FEC Encoding ID 0 SHOULD be used to deliver FDT Instances. This
901 is because in this case, even when there is no packet loss in the
902 network, a lower rate receiver will not receive all packets sent
903 for an FDT Instance.
905 5. Delivering FEC Object Transmission Information
907 FLUTE inherits the use of FEC building block [4] from ALC. When
908 using FLUTE for file delivery over ALC the FEC Object Transmission
909 Information MUST be delivered in-band within the file delivery
910 session. There are two methods to achieve this: the use of ALC
911 specific LCT extension header EXT_FTI [2] and the use of FDT. The
912 latter method is specified in this section.
914 The receiver of file delivery session MUST support delivery of FEC
915 Object Transmission Information using the EXT_FTI for the FDT
916 Instances carried using TOI value 0. For the TOI values other than 0
917 the receiver MUST support both methods: the use of EXT_FTI and the
918 use of FDT.
920 The FEC Object Transmission Information that needs to be delivered to
921 receivers MUST be exactly the same whether it is delivered using
922 EXT_FTI or using FDT (or both). The FEC Object Transmission
923 Information that MUST be delivered to receivers is defined by the FEC
924 Scheme. This section describes the delivery using FDT.
926 The FEC Object Transmission Information regarding a given TOI may be
927 available from several sources. In this case, it is RECOMMENDED that
928 the receiver of the file delivery session prioritizes the sources in
929 the following way (in the order of decreasing priority).
931 1. FEC Object Transmission Information that is available in EXT_FTI.
933 2. FEC Object Transmission Information that is available in the FDT.
935 The FDT delivers FEC Object Transmission Information for each file
936 using an appropriate attribute within the "FDT-Instance" or the
937 "File" element of the FDT structure.
939 * "Transfer-Length" carries the Transfer-Length Object Transmission
940 Information element defined in [4].
942 * "FEC-OTI-FEC-Encoding-ID" carries the "FEC Encoding ID" Object
943 Transmission Information element defined in [4], as carried in the
944 Codepoint field of the ALC/LCT header.
946 * "FEC-OTI-FEC-Instance-ID" carries the "FEC Instance ID" Object
947 Transmission Information element defined in [4] for Under-
948 specified FEC Schemes.
950 * "FEC-OTI-Maximum-Source-Block-Length" carries the "Maximum Source
951 Block Length" Object Transmission Information element defined in
952 [4], if required by the FEC Scheme.
954 * "FEC-OTI-Encoding-Symbol-Length" carries the "Encoding Symbol
955 Length" Object Transmission Information element defined in [4], if
956 required by the FEC Scheme.
958 * "FEC-OTI-Max-Number-of-Encoding-Symbols" carries the "Maximum
959 Number of Encoding Symbols" Object Transmission Information
960 element defined in [4], if required by the FEC Scheme.
962 * "FEC-OTI-Scheme-specific-information" carries the "encoded scheme-
963 specific FEC Object Transmission Information" as defined in [4],
964 if required by the FEC Scheme.
966 In FLUTE, the FEC Encoding ID (8 bits) for a given TOI MUST be
967 carried in the Codepoint field of the ALC/LCT header. When the FEC
968 Object Transmission Information for this TOI is delivered through the
969 FDT, then the associated "FEC-OTI-FEC-Encoding-ID" attribute and the
970 Codepoint field of all packets for this TOI MUST be the same.
972 6. Describing file delivery sessions
974 To start receiving a file delivery session, the receiver needs to
975 know transport parameters associated with the session. Interpreting
976 these parameters and starting the reception therefore represents the
977 entry point from which thereafter the receiver operation falls into
978 the scope of this specification. According to [2], the transport
979 parameters of an ALC/LCT session that the receiver needs to know are:
981 * The source IP address;
983 * The number of channels in the session;
985 * The destination IP address and port number for each channel in the
986 session;
988 * The Transport Session Identifier (TSI) of the session;
990 * An indication that the session is a FLUTE session. The need to
991 demultiplex objects upon reception is implicit in any use of
992 FLUTE, and this fulfills the ALC requirement of an indication of
993 whether or not a session carries packets for more than one object
994 (all FLUTE sessions carry packets for more than one object).
996 Optionally, the following parameters MAY be associated with the
997 session (Note, the list is not exhaustive):
999 * The start time and end time of the session;
1001 * FEC Encoding ID and FEC Instance ID when the default FEC Encoding
1002 ID 0 is not used for the delivery of FDT;
1004 * Content Encoding format if optional content encoding of FDT
1005 Instance is used, e.g., compression;
1007 * Some information that tells receiver, in the first place, that the
1008 session contains files that are of interest.
1010 It is envisioned that these parameters would be described according
1011 to some session description syntax (such as SDP [14] or XML based)
1012 and held in a file which would be acquired by the receiver before the
1013 FLUTE session begins by means of some transport protocol (such as
1014 Session Announcement Protocol [13], email, HTTP [6], SIP [22], manual
1015 pre-configuration, etc.) However, the way in which the receiver
1016 discovers the above-mentioned parameters is out of scope of this
1017 document, as it is for LCT and ALC. In particular, this
1018 specification does not mandate or exclude any mechanism.
1020 7. Security Considerations
1022 7.1. Problem Statement
1024 A content delivery system is potentially subject to attacks. Attacks
1025 may target:
1027 * the network (to compromise the routing infrastructure, e.g., by
1028 creating congestion),
1030 * the Content Delivery Protocol (CDP) (e.g., to compromise the
1031 normal behaviour of FLUTE) or
1033 * the content itself (e.g., to corrupt the files being transmitted).
1035 These attacks can be launched either:
1037 * against the data flow itself (e.g., by sending forged symbols),
1039 * against the session control parameters, (e.g., by corrupting the
1040 session description, the FDT Instances, or the ALC/LCT control
1041 parameters), that are sent either in-band or out-of-band or
1043 * against some associated building blocks (e.g., the congestion
1044 control component).
1046 In the following sections we provide more details on these possible
1047 attacks and sketch some possible counter-measures.
1049 7.2. Attacks against the data flow
1051 Let us consider attacks against the data flow first. At least, the
1052 following types of attacks exist:
1054 * attacks that are meant to give access to a confidential file
1055 (e.g., in case of a non-free content) and
1057 * attacks that try to corrupt the file being transmitted (e.g., to
1058 inject malicious code within a file, or to prevent a receiver from
1059 using a file, which is a kind of Denial of Service, DoS).
1061 7.2.1. Access to confidential files
1063 Access control to the file being transmitted is typically provided by
1064 means of encryption. This encryption can be done over the whole file
1065 (e.g., by the content provider, before submitting the file to FLUTE),
1066 or be done on a packet per packet basis (e.g., when IPSec/ESP is used
1067 [26]). If access control is a concern, it is RECOMMENDED that one of
1068 these solutions be used.
1070 7.2.2. File corruption
1072 Protection against corruptions (e.g., after sending forged packets)
1073 is achieved by means of a content integrity verification/sender
1074 authentication scheme. This service can be provided at the file
1075 level, but in that case a receiver has no way to identify which
1076 symbol(s) is(are) corrupted if the file is detected as corrupted.
1077 This service can also be provided at the packet level. In this case,
1078 after removing all corrupted packets, the file may be in some cases
1079 recovered. Several techniques can provide this source
1080 authentication/content integrity service:
1082 * at the file level, the file MAY be digitally signed (with public
1083 key cryptography), for instance by using RSASSA-PKCS1-v1_5 [24].
1084 This signature enables a receiver to check the file integrity,
1085 once this latter has been fully decoded. Even if digital
1086 signatures are computationally expensive, this calculation occurs
1087 only once per file, which is usually acceptable;
1089 * at the packet level, each packet can be digitally signed. A major
1090 limitation is the high computational and transmission overheads
1091 that this solution requires. To avoid this problem, the signature
1092 may span a set of symbols (instead of a single one) in order to
1093 amortize the signature calculation, but if a single symbol is
1094 missing, the integrity of the whole set cannot be checked;
1096 * at the packet level, a Group Message Authentication Code (MAC)
1097 [27] scheme can be used, for instance by using HMAC-SHA-1 with a
1098 secret key shared by all the group members, senders and receivers.
1099 This technique creates a cryptographically secured digest of a
1100 packet that is sent along with the packet. The Group MAC scheme
1101 does not create prohibitive processing load nor transmission
1102 overhead, but it has a major limitation: it only provides a group
1103 authentication/integrity service since all group members share the
1104 same secret group key, which means that each member can send a
1105 forged packet. It is therefore restricted to situations where
1106 group members are fully trusted (or in association with another
1107 technique as a pre-check);
1109 * at the packet level, TESLA [28]] is a very attractive and
1110 efficient solution that is robust to losses, provides a true
1111 authentication/integrity service, and does not create any
1112 prohibitive processing load or transmission overhead. Yet
1113 checking a packet requires a small delay (a second or more) after
1114 its reception; or;
1116 * at the packet level, IPSec/AH [25] (possibly associated to IPSec/
1117 ESP) can be used to protect all the packets being exchanged in a
1118 session.
1120 Techniques relying on public key cryptography (digital signatures and
1121 TESLA during the bootstrap process, when used) require that public
1122 keys be securely associated to the entities. This can be achieved by
1123 a Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by
1124 pre-distributing the public keys of each group member.
1126 Techniques relying on symmetric key cryptography (Group MAC) require
1127 that a secret key be shared by all group members. This can be
1128 achieved by means of a group key management protocol, or simply by
1129 pre-distributing the secret key (but this manual solution has many
1130 limitations).
1132 It is up to the developer and deployer, who know the security
1133 requirements and features of the target application area, to define
1134 which solution is the most appropriate. Nonetheless, in case there
1135 is any concern of the threat of file corruption, it is RECOMMENDED
1136 that at least one of these techniques be used.
1138 7.3. Attacks against the session control parameters and associated
1139 Building Blocks
1141 Let us now consider attacks against the session control parameters
1142 and the associated building blocks. The attacker has at least the
1143 following opportunities to launch an attack:
1145 * the attack can target the session description,
1147 * the attack can target the FDT Instances,
1149 * the attack can target the ALC/LCT parameters, carried within the
1150 LCT header or
1152 * the attack can target the FLUTE associated building blocks.
1154 The latter one is particularly true with the multiple rate congestion
1155 control protocol which may be required.
1157 The consequences of these attacks are potentially serious, since they
1158 might compromise the behavior of content delivery system.
1160 7.3.1. Attacks against the Session Description
1162 A FLUTE receiver may potentially obtain an incorrect Session
1163 Description for the session. The consequence of this is that
1164 legitimate receivers with the wrong Session Description are unable to
1165 correctly receive the session content, or that receivers
1166 inadvertently try to receive at a much higher rate than they are
1167 capable of, thereby possibly disrupting other traffic in the network.
1169 To avoid these problems, it is RECOMMENDED that measures be taken to
1170 prevent receivers from accepting incorrect Session Descriptions. One
1171 such measure is source authentication to ensure that receivers only
1172 accept legitimate Session Descriptions from authorized senders. How
1173 these measures are achived is outside the scope of this document
1174 since this session description is usually carried out-of-band.
1176 7.3.2. Attacks against the FDT Instances
1178 Corrupting the FDT Instances is one way to create a Denial of Service
1179 attack. For example, the attacker changes the MD5 sum associated to
1180 a file. This possibly leads a receiver to reject the files received,
1181 no matter whether the files have been correctly received or not.
1183 Corrupting the FDT Instances is also a way to make the reception
1184 process more costly than it should be. This can be achieved by
1185 changing the FEC Object Transmission Information when the FEC Object
1186 Transmission Information is included in the FDT Instance. For
1187 example, an attacker may corrupt the FDT Instance in such a way that
1188 Reed-Solomon over GF(2^^16) be used instead of GF(2^^8) with FEC
1189 Encoding ID 2. This may significantly increase the processing load
1190 while compromising FEC decoding.
1192 It is therefore RECOMMENDED that measures be taken to guarantee the
1193 integrity and to check the sender's identity of the FDT Instances.
1194 To that purpose, one of the counter-measures mentioned above
1195 (Section 7.2.2) SHOULD be used. These measures will either be
1196 applied on a packet level, or globally over the whole FDT Instance
1197 object. Additionally, XML digital signatures [20] are a way to
1198 protect the FDT Instance by digitally signing it. When there is no
1199 packet level integrity verification scheme, it is RECOMMENDED to rely
1200 on XML digital signatures of the FDT Instances.
1202 7.3.3. Attacks against the ALC/LCT parameters
1204 By corrupting the ALC/LCT header (or header extensions) one can
1205 execute attacks on underlying ALC/LCT implementation. For example,
1206 by sending forged ALC packets with the Close Session flag (A) set one
1207 can lead the receiver to prematurely close the session. Similarly,
1208 by sending forged ALC packets with the Close Object flag (B) set one
1209 can lead the receiver to prematurely give up the reception of an
1210 object.
1212 It is therefore RECOMMENDED that measures be taken to guarantee the
1213 integrity and to check the sender's identity of the ALC packets
1214 received. To that purpose, one of the counter-measures mentioned
1215 above (Section 7.2.2) SHOULD be used.
1217 7.3.4. Attacks against the associated Building Blocks
1219 Let us first focus on the congestion control building block, that is
1220 may be associated to FLUTE. A receiver with an incorrect or
1221 corrupted implementation of the multiple rate congestion control
1222 building block may affect the health of the network in the path
1223 between the sender and the receiver. That may also affect the
1224 reception rates of other receivers who joined the session.
1226 When congestion control building block is applied with FLUTE, it is
1227 therefore RECOMMENDED that receivers be required to identify
1228 themselves as legitimate before they receive the Session Description
1229 needed to join the session. How receivers identify themselves as
1230 legitimate is outside the scope of this document. If authenticating
1231 a receiver does not prevent this latter to launch an attack, it will
1232 enable the network operator to identify him and to take counter-
1233 measures.
1235 When congestion control building block is applied with FLUTE, it is
1236 also RECOMMENDED that a packet level authentication scheme be used,
1237 as explained in Section 7.2.2. Some of them, like TESLA, only
1238 provide a delayed authentication service, whereas congestion control
1239 requires a rapid reaction. It is therefore RECOMMENDED [2] that a
1240 receiver using TESLA quickly reduces its subscription level when the
1241 receiver believes that a congestion did occur, even if the packet has
1242 not yet been authenticated. Therefore TESLA will not prevent DoS
1243 attacks where an attacker makes the receiver believe that a
1244 congestion occurred. This is an issue for the receiver, but this
1245 will not compromise the network since no congestion actually
1246 occurred. Other authentication methods that do not feature this
1247 delayed authentication could be prefered, or a group MAC scheme could
1248 be used in parallel to TESLA.
1250 7.4. Other Security Considerations
1252 Lastly, we note that the security considerations that apply to, and
1253 are described in, ALC [2], LCT [3] and FEC [4] also apply to FLUTE as
1254 FLUTE builds on those specifications. In addition, any security
1255 considerations that apply to any congestion control building block
1256 used in conjunction with FLUTE also apply to FLUTE.
1258 8. IANA Considerations
1260 This specification contains three separate items for IANA
1261 Considerations:
1263 1. Registration Request for XML Schema of FDT Instance
1264 (urn:ietf:params:xml:schema:fdt).
1266 2. Media-Type Registration Request for application/fdt+xml.
1268 3. Content Encoding Algorithm Registration Request (ietf:rmt:cenc).
1270 8.1. Registration Request for XML Schema of FDT Instance
1272 Document [23] defines an IANA maintained registry of XML documents
1273 used within IETF protocols. The following is the registration
1274 request for the FDT XML schema.
1276 URI: urn:ietf:params:xml:schema:fdt
1278 Registrant Contact: Toni Paila (toni.paila (at) nokia.com)
1280 XML: The XML Schema specified in Section 3.4.2
1282 8.2. Media-Type Registration Request for application/fdt+xml
1284 This section provides the registration request, as per [21] and [9],
1285 to be submitted to IANA following IESG approval.
1287 Type name: application
1288 Subtype name: fdt+xml
1290 Required parameters: none
1292 Optional parameters: none
1294 Encoding considerations: The fdt+xml type consists of UTF-8 ASCII
1295 characters [10] and must be well-formed XML.
1297 Additional content and transfer encodings may be used with fdt+xml
1298 files, with the appropriate encoding for any specific file being
1299 entirely dependant upon the deployed application.
1301 Restrictions on usage: Only for usage with FDT Instances which are
1302 valid according to the XML schema of section 3.4.2.
1304 Security considerations: fdt+xml data is passive, and does not
1305 generally represent a unique or new security threat. However, there
1306 is some risk in sharing any kind of data, in that unintentional
1307 information may be exposed, and that risk applies to fdt+xml data as
1308 well.
1310 Interoperability considerations: None
1312 Published specification: The present document including section
1313 3.4.2. The specified FDT Instance functions as an actual media
1314 format of use to the general Internet community and thus media type
1315 registration under the Standards Tree is appropriate to maximize
1316 interoperability.
1318 Applications which use this media type: Not restricted to any
1319 particular application
1321 Additional information:
1323 Magic number(s): none
1324 File extension(s): An FDT Instance may use the extension ".fdt"
1325 but this is not required.
1326 Macintosh File Type Code(s): none
1328 Person & email address to contact for further information: Toni Paila
1329 (toni.paila (at) nokia.com)
1331 Intended usage: Common
1333 Author/Change controller: Toni Paila (toni.paila (at) nokia.com)
1335 8.3. Content Encoding Algorithm Registration Request
1337 Values of Content Encoding Algorithms are subject to IANA
1338 registration. The value of Content Encoding Algorithm is a numeric
1339 non-negative index. In this document, the range of values for
1340 Content Encoding Algorithms is 0 to 255. This specification already
1341 assigns the values 0, 1, 2 and 3 as described in section 3.4.3.
1343 8.3.1. Explicit IANA Assignment Guidelines
1345 This document defines a name-space for Content Encoding Algorithms
1346 named:
1348 ietf:rmt:cenc
1350 IANA has established and manages the new registry for the "ietf:rmt:
1351 cenc" name-space. The values that can be assigned within the "ietf:
1352 rmt:cenc" name-space are numeric indexes in the range [0, 255],
1353 boundaries included. Assignment requests are granted on a
1354 "Specification Required" basis as defined in RFC 2434 [11]. Note
1355 that the values 0, 1, 2 and 3 of "ietf:rmt:cenc" are already assigned
1356 by this document as described in section 3.4.3.
1358 9. Acknowledgements
1360 The following persons have contributed to this specification: Brian
1361 Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma,
1362 Topi Pohjolainen, Lorenzo Vicisano, and Mark Watson. The authors
1363 would like to thank all the contributors for their valuable work in
1364 reviewing and providing feedback regarding this specification.
1366 10. Contributors
1368 Jani Peltotalo
1369 Tampere University of Technology
1370 P.O. Box 553 (Korkeakoulunkatu 1)
1371 Tampere FIN-33101
1372 Finland
1373 Email: jani.peltotalo (at) tut.fi
1375 Sami Peltotalo
1376 Tampere University of Technology
1377 P.O. Box 553 (Korkeakoulunkatu 1)
1378 Tampere FIN-33101
1379 Finland
1380 Email: sami.peltotalo (at) tut.fi
1381 Magnus Westerlund
1382 Ericsson Research
1383 Ericsson AB
1384 SE-164 80 Stockholm
1385 Sweden
1386 EMail: magnus.westerlund (at) ericsson.com
1388 Thorsten Lohmar
1389 Ericsson Research (EDD)
1390 Ericsson Allee 1
1391 52134 Herzogenrath, Germany
1392 EMail: thorsten.lohmar (at) ericsson.com
1394 11. Change Log
1396 11.1. RFC3926 to draft-ietf-rmt-flute-revised-01
1398 Removed the 'Statement of Intent' from the Section 1. The statement
1399 of intent was meant to clarify the "Experimental" status of RFC3926.
1400 It does not apply to this draft that is intended for "Standard Track"
1401 submission.
1403 Added clarification on XML-DSIG in the end of Section 3.
1405 Revised the use of word "complete" in the Section 3.2.
1407 Clarified Figure 1 vrt. "Encoding Symbol(s) for FDT Instance".
1409 Clarified the FDT Instance ID wrap-around in the end of
1410 Section 3.4.1.
1412 Clarification for "Complete FDT" in the Section 3.4.2.
1414 Added semantics for the case two TOIs refer to same Content-Location.
1415 Now it is in line how 3GPP and DVB interpret the case.
1417 In the Section 3.4.2 XML Schema of FDT instance is modified to
1418 various advices. For example, extension by element was missing but
1419 is now supported. Also namespace definition is changed to URN
1420 format.
1422 Clarified FDT-schema extensibility in the end of Section 3.4.2.
1424 The CENC value allocation is added in the end of Section 3.4.3.
1426 Section 5 is modified so that EXT_FTI and the FEC issues are replaced
1427 by a reference to LCT specification. We count on revised LCT
1428 specification to specify the EXT_FTI.
1430 Added a clarifying paragraph on the use of Codepoint in the very end
1431 of Section 5.
1433 Reworked Section 8 - IANA Considerations. Now it contains three IANA
1434 registration requests:
1436 * Registration Request for XML Schema of FDT Instance
1437 (urn:ietf:params:xml:schema:fdt)
1439 * Media-Type Registration Request for application/fdt+xml
1441 * Content Encoding Algorithm Registration Request (ietf:rmt:cenc)
1443 Added Section 10 - Contributors.
1445 Added three Normative References: [9], [10], [11].
1447 Deleted one Normative Reference: Compact FEC Schemes.
1449 12. References
1451 12.1. Normative references
1453 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1454 Levels", RFC 2119, BCP 14, March 1997.
1456 [2] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered
1457 Coding (ALC) Protocol Instantiation",
1458 draft-ietf-rmt-pi-alc-revised-03 (work in progress),
1459 April 2006.
1461 [3] Luby, M., Watson, M., and L. Vicisano, "Layered Coding
1462 Transport (LCT) Building Block",
1463 draft-ietf-rmt-bb-lct-revised-04 (work in progress), June 2006.
1465 [4] Watson, M., Luby, M., and L. Vicisano, "Forward Error
1466 Correction (FEC) Building Block",
1467 draft-ietf-rmt-fec-bb-revised-02 (work in progress),
1468 October 2005.
1470 [5] Mills, D., "Network Time Protocol (Version 3), Specification,
1471 Implementation and Analysis", RFC 1305, March 1992.
1473 [6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
1474 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
1475 HTTP/1.1", RFC 2616, June 1999.
1477 [7] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML
1478 Schema Part 1: Structures", W3C Recommendation, May 2001.
1480 [8] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes",
1481 W3C Recommendation, May 2001.
1483 [9] Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types",
1484 RFC 3023, January 2001.
1486 [10] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
1487 RFC 2279, January 1998.
1489 [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
1490 Considerations Section in RFCs", RFC 2434, October 1998.
1492 12.2. Informative references
1494 [12] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
1495 Specification version 3.3", RFC 1950, May 1996.
1497 [13] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
1498 Protocol", RFC 2974, October 2000.
1500 [14] Handley, M. and V. Jacobson, "Session Description Protocol",
1501 RFC 2327, April 1998.
1503 [15] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
1504 STD 5, August 1989.
1506 [16] Holbrook, H., "A Channel Model for Multicast, Ph.D.
1507 Dissertation, Stanford University, Department of Computer
1508 Science, Stanford, California", August 2001.
1510 [17] Deutsch, P., "DEFLATE Compressed Data Format Specification
1511 version 1.3", RFC 1951, May 1996.
1513 [18] Deutsch, P., "GZIP file format specification version 4.3",
1514 RFC 1952, May 1996.
1516 [19] Ramsdell, B., "S/MIME Version 3 Message Specification",
1517 RFC 2633, June 1999.
1519 [20] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
1520 Language) XML-Signature Syntax and Processing", RFC 3275,
1521 March 2002.
1523 [21] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
1524 Mail Extensions (MIME) Part Four: Registration Procedures",
1525 RFC 2048, November 1996.
1527 [22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
1528 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
1529 session initiation protocol", RFC 3261, June 2002.
1531 [23] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
1533 [24] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
1534 (PKCS) #1: RSA Cryptography Specifications Version 2.1",
1535 RFC 3447, February 2003.
1537 [25] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
1539 [26] Kent, S., "Encapsulating Security Payload (ESP)", RFC 4303,
1540 December 2005.
1542 [27] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
1543 for Message Authentication", RFC 2104, February 1997.
1545 [28] Perrig, A., Canetti, R., Tygar, J D., and B. Briscoe, "Timed
1546 Efficient Stream Loss-Tolerant Authentication (TESLA):
1547 Multicast Source Authentication Transform Introduction",
1548 RFC 4082, June 2005.
1550 Appendix A. Receiver operation (informative)
1552 This section gives an example how the receiver of the file delivery
1553 session may operate. Instead of a detailed state-by-state
1554 specification the following should be interpreted as a rough sequence
1555 of an envisioned file delivery receiver.
1557 1. The receiver obtains the description of the file delivery session
1558 identified by the pair: (source IP address, Transport Session
1559 Identifier). The receiver also obtains the destination IP
1560 addresses and respective ports associated with the file delivery
1561 session.
1563 2. The receiver joins the channels in order to receive packets
1564 associated with the file delivery session. The receiver may
1565 schedule this join operation utilizing the timing information
1566 contained in a possible description of the file delivery session.
1568 3. The receiver receives ALC/LCT packets associated with the file
1569 delivery session. The receiver checks that the packets match the
1570 declared Transport Session Identifier. If not, packets are
1571 silently discarded.
1573 4. While receiving, the receiver demultiplexes packets based on
1574 their TOI and stores the relevant packet information in an
1575 appropriate area for recovery of the corresponding file.
1576 Multiple files can be reconstructed concurrently.
1578 5. Receiver recovers an object. An object can be recovered when an
1579 appropriate set of packets containing Encoding Symbols for the
1580 transmission object have been received. An appropriate set of
1581 packets is dependent on the properties of the FEC Encoding ID and
1582 FEC Instance ID, and on other information contained in the FEC
1583 Object Transmission Information.
1585 6. If the recovered object was an FDT Instance with FDT Instance ID
1586 'N', the receiver parses the payload of the instance 'N' of FDT
1587 and updates its FDT database accordingly. The receiver
1588 identifies FDT Instances within a file delivery session by the
1589 EXT_FDT header extension. Any object that is delivered using
1590 EXT_FDT header extension is an FDT Instance, uniquely identified
1591 by the FDT Instance ID. Note that TOI '0' is exclusively
1592 reserved for FDT delivery.
1594 7. If the object recovered is not an FDT Instance but a file, the
1595 receiver looks up its FDT database to get the properties
1596 described in the database, and assigns file with the given
1597 properties. The receiver also checks that received content
1598 length matches with the description in the database. Optionally,
1599 if MD5 checksum has been used, the receiver checks that
1600 calculated MD5 matches with the description in the FDT database.
1602 8. The actions the receiver takes with imperfectly received files
1603 (missing data, mismatching digestive, etc.) is outside the scope
1604 of this specification. When a file is recovered before the
1605 associated file description entry is available, a possible
1606 behavior is to wait until an FDT Instance is received that
1607 includes the missing properties.
1609 9. If the file delivery session end time has not been reached go
1610 back to 3. Otherwise end.
1612 Appendix B. Example of FDT Instance (informative)
1614
1615
1619
1623
1631
1633 Authors' Addresses
1635 Toni Paila
1636 Nokia
1637 102 Corporate Park Drive
1638 White Plains, NY 10604
1639 USA
1641 Email: toni.paila (at) nokia.com
1643 Rod Walsh
1644 Nokia
1645 Visiokatu 1
1646 Tampere FIN-33720
1647 Finland
1649 Email: rod.walsh (at) nokia.com
1650 Michael Luby
1651 Digital Fountain
1652 39141 Civic Center Dr.
1653 Suite 300
1654 Fremont, CA 94538
1655 USA
1657 Email: luby (at) digitalfountain.com
1659 Rami Lehtonen
1660 TeliaSonera
1661 Hatanpaan valtatie 18
1662 Tampere FIN-33100
1663 Finland
1665 Email: rami.lehtonen (at) teliasonera.com
1667 Vincent Roca
1668 INRIA Rhone-Alpes
1669 655, av. de l'Europe
1670 Montbonnot
1671 St Ismier cedex 38334
1672 France
1674 Email: vincent.roca (at) inrialpes.fr
1676 Full Copyright Statement
1678 Copyright (C) The IETF Trust (2007).
1680 This document is subject to the rights, licenses and restrictions
1681 contained in BCP 78, and except as set forth therein, the authors
1682 retain all their rights.
1684 This document and the information contained herein are provided on an
1685 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1686 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1687 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1688 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1689 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1690 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1692 Intellectual Property
1694 The IETF takes no position regarding the validity or scope of any
1695 Intellectual Property Rights or other rights that might be claimed to
1696 pertain to the implementation or use of the technology described in
1697 this document or the extent to which any license under such rights
1698 might or might not be available; nor does it represent that it has
1699 made any independent effort to identify any such rights. Information
1700 on the procedures with respect to rights in RFC documents can be
1701 found in BCP 78 and BCP 79.
1703 Copies of IPR disclosures made to the IETF Secretariat and any
1704 assurances of licenses to be made available, or the result of an
1705 attempt made to obtain a general license or permission for the use of
1706 such proprietary rights by implementers or users of this
1707 specification can be obtained from the IETF on-line IPR repository at
1708 http://www.ietf.org/ipr.
1710 The IETF invites any interested party to bring to its attention any
1711 copyrights, patents or patent applications, or other proprietary
1712 rights that may cover technology that may be required to implement
1713 this standard. Please address the information to the IETF at
1714 ietf-ipr@ietf.org.
1716 Acknowledgment
1718 Funding for the RFC Editor function is provided by the IETF
1719 Administrative Support Activity (IASA).