idnits 2.17.1
draft-ietf-rmt-flute-revised-08.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (December 23, 2009) is 5231 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 1424, but not defined
== Missing Reference: '255' is mentioned on line 1424, but not defined
** 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)
** Downref: Normative reference to an Informational RFC: RFC 1950 (ref.
'13')
** Downref: Normative reference to an Informational RFC: RFC 1951 (ref.
'14')
** Downref: Normative reference to an Informational RFC: RFC 1952 (ref.
'15')
-- Obsolete informational reference (is this intentional?): RFC 4566 (ref.
'17') (Obsoleted by RFC 8866)
-- Obsolete informational reference (is this intentional?): RFC 3851 (ref.
'22') (Obsoleted by RFC 5751)
-- Obsolete informational reference (is this intentional?): RFC 4288 (ref.
'24') (Obsoleted by RFC 6838)
-- Obsolete informational reference (is this intentional?): RFC 3447 (ref.
'29') (Obsoleted by RFC 8017)
== Outdated reference: A later version (-06) exists of
draft-ietf-rmt-simple-auth-for-alc-norm-02
Summary: 8 errors (**), 0 flaws (~~), 4 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: June 26, 2010 Digital Fountain
7 V. Roca
8 INRIA
9 R. Lehtonen
10 TeliaSonera
11 December 23, 2009
13 FLUTE - File Delivery over Unidirectional Transport
14 draft-ietf-rmt-flute-revised-08
16 Abstract
18 This document defines FLUTE, a protocol for the unidirectional
19 delivery of files over the Internet, which is particularly suited to
20 multicast networks. The specification builds on Asynchronous Layered
21 Coding, the base protocol designed for massively scalable multicast
22 distribution. This document obsoletes RFC3926.
24 Status of this Memo
26 This Internet-Draft is submitted to IETF in full conformance with the
27 provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF), its areas, and its working groups. Note that
31 other groups may also distribute working documents as Internet-
32 Drafts.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 The list of current Internet-Drafts can be accessed at
40 http://www.ietf.org/ietf/1id-abstracts.txt.
42 The list of Internet-Draft Shadow Directories can be accessed at
43 http://www.ietf.org/shadow.html.
45 This Internet-Draft will expire on June 26, 2010.
47 Copyright Notice
48 Copyright (c) 2009 IETF Trust and the persons identified as the
49 document authors. All rights reserved.
51 This document is subject to BCP 78 and the IETF Trust's Legal
52 Provisions Relating to IETF Documents
53 (http://trustee.ietf.org/license-info) in effect on the date of
54 publication of this document. Please review these documents
55 carefully, as they describe your rights and restrictions with respect
56 to this document. Code Components extracted from this document must
57 include Simplified BSD License text as described in Section 4.e of
58 the Trust Legal Provisions and are provided without warranty as
59 described in the BSD License.
61 This document may contain material from IETF Documents or IETF
62 Contributions published or made publicly available before November
63 10, 2008. The person(s) controlling the copyright in some of this
64 material may not have granted the IETF Trust the right to allow
65 modifications of such material outside the IETF Standards Process.
66 Without obtaining an adequate license from the person(s) controlling
67 the copyright in such materials, this document may not be modified
68 outside the IETF Standards Process, and derivative works of it may
69 not be created outside the IETF Standards Process, except to format
70 it for publication as an RFC or to translate it into languages other
71 than English.
73 Table of Contents
75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
76 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 6
77 1.1.1. The Target Application Space . . . . . . . . . . . . . 6
78 1.1.2. The Target Scale . . . . . . . . . . . . . . . . . . . 6
79 1.1.3. Intended Environments . . . . . . . . . . . . . . . . 6
80 1.1.4. Weaknesses . . . . . . . . . . . . . . . . . . . . . . 7
81 2. Conventions used in this Document . . . . . . . . . . . . . . 7
82 3. File delivery . . . . . . . . . . . . . . . . . . . . . . . . 8
83 3.1. File delivery session . . . . . . . . . . . . . . . . . . 9
84 3.2. File Delivery Table . . . . . . . . . . . . . . . . . . . 10
85 3.3. Dynamics of FDT Instances within file delivery session . . 12
86 3.4. Structure of FDT Instance packets . . . . . . . . . . . . 14
87 3.4.1. Format of FDT Instance Header . . . . . . . . . . . . 15
88 3.4.2. Syntax of FDT Instance . . . . . . . . . . . . . . . . 16
89 3.4.3. Content Encoding of FDT Instance . . . . . . . . . . . 20
90 3.5. Multiplexing of files within a file delivery session . . . 21
91 4. Channels, congestion control and timing . . . . . . . . . . . 21
92 5. Delivering FEC Object Transmission Information . . . . . . . . 22
93 6. Describing file delivery sessions . . . . . . . . . . . . . . 24
94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
95 7.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 25
96 7.2. Attacks against the data flow . . . . . . . . . . . . . . 26
97 7.2.1. Access to confidential files . . . . . . . . . . . . . 26
98 7.2.2. File corruption . . . . . . . . . . . . . . . . . . . 26
99 7.3. Attacks against the session control parameters and
100 associated Building Blocks . . . . . . . . . . . . . . . . 28
101 7.3.1. Attacks against the Session Description . . . . . . . 28
102 7.3.2. Attacks against the FDT Instances . . . . . . . . . . 28
103 7.3.3. Attacks against the ALC/LCT parameters . . . . . . . . 29
104 7.3.4. Attacks against the associated Building Blocks . . . . 29
105 7.4. Other Security Considerations . . . . . . . . . . . . . . 30
106 7.5. Minimum Security Recommendations . . . . . . . . . . . . . 30
107 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
108 8.1. Registration Request for XML Schema of FDT Instance . . . 31
109 8.2. Media-Type Registration Request for application/fdt+xml . 31
110 8.3. Content Encoding Algorithm Registration Request . . . . . 32
111 8.3.1. Explicit IANA Assignment Guidelines . . . . . . . . . 32
112 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
113 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33
114 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 33
115 11.1. RFC3926 to draft-ietf-rmt-flute-revised-08 . . . . . . . . 33
116 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
117 12.1. Normative references . . . . . . . . . . . . . . . . . . . 35
118 12.2. Informative references . . . . . . . . . . . . . . . . . . 36
119 Appendix A. Receiver operation (informative) . . . . . . . . . . 37
120 Appendix B. Example of FDT Instance (informative) . . . . . . . . 39
121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
123 1. Introduction
125 This document defines FLUTE version 1, a protocol for unidirectional
126 delivery of files over the Internet. The specification builds on
127 Asynchronous Layered Coding (ALC), version 1 [2], the base protocol
128 designed for massively scalable multicast distribution. ALC defines
129 transport of arbitrary binary objects. For file delivery
130 applications mere transport of objects is not enough, however. The
131 end systems need to know what the objects actually represent. This
132 document specifies a technique called FLUTE - a mechanism for
133 signaling and mapping the properties of files to concepts of ALC in a
134 way that allows receivers to assign those parameters for received
135 objects. Consequently, throughout this document the term 'file'
136 relates to an 'object' as discussed in ALC. Although this
137 specification frequently makes use of multicast addressing as an
138 example, the techniques are similarly applicable for use with unicast
139 addressing.
141 This document defines a specific transport application of ALC, adding
142 the following specifications:
144 - Definition of a file delivery session built on top of ALC,
145 including transport details and timing constraints.
147 - In-band signalling of the transport parameters of the ALC session.
149 - In-band signalling of the properties of delivered files.
151 - Details associated with the multiplexing of multiple files within
152 a session.
154 This specification is structured as follows. Section 3 begins by
155 defining the concept of the file delivery session. Following that it
156 introduces the File Delivery Table that forms the core part of this
157 specification. Further, it discusses multiplexing issues of
158 transmission objects within a file delivery session. Section 4
159 describes the use of congestion control and channels with FLUTE.
160 Section 5 defines how the Forward Error Correction (FEC) Object
161 Transmission Information is to be delivered within a file delivery
162 session. Section 6 defines the required parameters for describing
163 file delivery sessions in a general case. Section 7 outlines
164 security considerations regarding file delivery with FLUTE. Last,
165 there are two informative appendices. The first appendix describes
166 an envisioned receiver operation for the receiver of the file
167 delivery session. The second appendix gives an example of File
168 Delivery Table.
170 This specification contains part of the definitions necessary to
171 fully specify a Reliable Multicast Transport protocol in accordance
172 with RFC2357.
174 This document obsoletes RFC3926 which contained a previous version of
175 this specification and was published in the "Experimental" category.
176 This Proposed Standard specification is thus based on RFC3926 updated
177 according to accumulated experience and growing protocol maturity
178 since the publication of RFC3926. Said experience applies both to
179 this specification itself and to congestion control strategies
180 related to the use of this specification.
182 The differences between RFC3926 and this document listed in
183 Section 11.
185 1.1. Applicability Statement
187 1.1.1. The Target Application Space
189 FLUTE is applicable to the delivery of large and small files to many
190 hosts, using delivery sessions of several seconds or more. For
191 instance, FLUTE could be used for the delivery of large software
192 updates to many hosts simultaneously. It could also be used for
193 continuous, but segmented, data such as time-lined text for
194 subtitling - potentially leveraging its layering inheritance from ALC
195 and LCT to scale the richness of the session to the congestion status
196 of the network. It is also suitable for the basic transport of
197 metadata, for example SDP [17] files which enable user applications
198 to access multimedia sessions.
200 1.1.2. The Target Scale
202 Massive scalability is a primary design goal for FLUTE. IP multicast
203 is inherently massively scalable, but the best effort service that it
204 provides does not provide session management functionality,
205 congestion control or reliability. FLUTE provides all of this using
206 ALC and IP multicast without sacrificing any of the inherent
207 scalability of IP multicast.
209 1.1.3. Intended Environments
211 All of the environmental requirements and considerations that apply
212 to the ALC building block [2] and to any additional building blocks
213 that FLUTE uses also apply to FLUTE.
215 FLUTE can be used with both multicast and unicast delivery, but it's
216 primary application is for unidirectional multicast file delivery.
217 FLUTE requires connectivity between a sender and receivers but does
218 not require connectivity from receivers to a sender. FLUTE
219 inherently works with all types of networks, including LANs, WANs,
220 Intranets, the Internet, asymmetric networks, wireless networks, and
221 satellite networks.
223 FLUTE is compatible with both IPv4 or IPv6 as no part of the packet
224 is IP version specific. FLUTE works with both multicast models: Any-
225 Source Multicast (ASM) [18] and the Source-Specific Multicast (SSM)
226 [19].
228 FLUTE is applicable for both Internet use, with a suitable congestion
229 control building block, and provisioned/controlled systems, such as
230 delivery over wireless broadcast radio systems.
232 1.1.4. Weaknesses
234 Some networks are not amenable to some congestion control protocols
235 that could be used with FLUTE. In particular, for a satellite or
236 wireless network, there may be no mechanism for receivers to
237 effectively reduce their reception rate since there may be a fixed
238 transmission rate allocated to the session.
240 FLUTE can also be used for point-to-point (unicast) communications.
241 At a minimum, implementions of ALC MUST support the WEBRC [27]
242 multiple rate congestion control scheme [2]. However, since WEBRC
243 has been designed for massively scalable multicast flows, it is not
244 clear how appropriate it is to the particular case of unicast flows.
245 Using a separate point-to-point congestion control scheme is another
246 alternative. How to do do that is outside the scope of the present
247 document.
249 FLUTE provides reliability using the FEC building block. This will
250 reduce the error rate as seen by applications. However, FLUTE does
251 not provide a method for senders to verify the reception success of
252 receivers, and the specification of such a method is outside the
253 scope of this document.
255 2. Conventions used in this Document
257 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
258 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
259 document are to be interpreted as described in RFC 2119 [1].
261 The terms "object" and "transmission object" are consistent with the
262 definitions in ALC [2] and LCT [3]. The terms "file" and "source
263 object" are pseudonyms for "object".
265 3. File delivery
267 Asynchronous Layered Coding [2] is a protocol designed for delivery
268 of arbitrary binary objects. It is especially suitable for massively
269 scalable, unidirectional, multicast distribution. ALC provides the
270 basic transport for FLUTE, and thus FLUTE inherits the requirements
271 of ALC.
273 This specification is designed for the delivery of files. The core
274 of this specification is to define how the properties of the files
275 are carried in-band together with the delivered files.
277 As an example, let us consider a 5200 byte file referred to by
278 "http://www.example.com/docs/file.txt". Using the example, the
279 following properties describe the properties that need to be conveyed
280 by the file delivery protocol.
282 * Identifier of the file, expressed as a URI. This identifier may
283 be globally unique. The identifier may also provide a location
284 for the file. In the above example:
285 "http://www.example.com/docs/file.txt".
287 * File name (usually, this can be concluded from the URI). In the
288 above example: "file.txt".
290 * File type, expressed as MIME media type (usually, this can also be
291 concluded from the extension of the file name). In the above
292 example: "text/plain". If an explicit value for the MIME type is
293 provided separately from the file extension and does not match the
294 MIME type of the file extension then the explicitly provided value
295 MUST be used as the MIME type.
297 * File size, expressed in bytes. In the above example: "5200". If
298 the file is content encoded then this is the file size before
299 content encoding.
301 * Content encoding of the file, within transport. In the above
302 example, the file could be encoded using ZLIB [13]. In this case
303 the size of the transmission object carrying the file would
304 probably differ from the file size. The transmission object size
305 is delivered to receivers as part of the FLUTE protocol.
307 * Security properties of the file such as digital signatures,
308 message digests, etc. For example, one could use S/MIME [22] as
309 the content encoding type for files with this authentication
310 wrapper, and one could use XML-DSIG [23] to digitally sign an FDT
311 Instance. XML-DSIG can also be used to provide tamper prevention
312 e.g. on the Content-Location field.
314 3.1. File delivery session
316 ALC is a protocol instantiation of Layered Coding Transport building
317 block (LCT) [3]. Thus ALC inherits the session concept of LCT. In
318 this document we will use the concept ALC/LCT session to collectively
319 denote the interchangeable terms ALC session and LCT session.
321 An ALC/LCT session consists of a set of logically grouped ALC/LCT
322 channels associated with a single sender sending packets with ALC/LCT
323 headers for one or more objects. An ALC/LCT channel is defined by
324 the combination of a sender and an address associated with the
325 channel by the sender. A receiver joins a channel to start receiving
326 the data packets sent to the channel by the sender, and a receiver
327 leaves a channel to stop receiving data packets from the channel.
329 One of the fields carried in the ALC/LCT header is the Transport
330 Session Identifier (TSI). The TSI is scoped by the source IP
331 address, and the (source IP address, TSI) pair uniquely identifies a
332 session, i.e., the receiver uses this pair carried in each packet to
333 uniquely identify from which session the packet was received. In
334 case multiple objects are carried within a session, the Transmission
335 Object Identifier (TOI) field within the ALC/LCT header identifies
336 from which object the data in the packet was generated. Note that
337 each object is associated with a unique TOI within the scope of a
338 session.
340 If the sender is not assigned a permanent IP address accessible to
341 receivers, but instead, packets that can be received by receivers
342 containing a temporary IP address for packets sent by the sender,
343 then the TSI is scoped by this temporary IP address of the sender for
344 the duration of the session. As an example, the sender may be behind
345 a Network Address Translation (NAT) device that temporarily assigns
346 an IP address for the sender that is accessible to receivers, and in
347 this case the TSI is scoped by the temporary IP address assigned by
348 the NAT that will appear in packets received by the receiver. As
349 another example, the sender may send its original packets using IPv6,
350 but some portions of the network may not be IPv6 capable and thus
351 there may be an IPv6 to IPv4 translator that changes the IP address
352 of the packets to a different IPv4 address. In this case, receivers
353 in the IPv4 portion of the network will receive packets containing
354 the IPv4 address, and thus the TSI for them is scoped by the IPv4
355 address. How the IP address of the sender to be used to scope the
356 session by receivers is delivered to receivers, whether it is a
357 permanent IP address or a temporary IP address, is outside the scope
358 of this document.
360 When FLUTE is used for file delivery over ALC the following rules
361 apply:
363 * The ALC/LCT session is called file delivery session.
365 * The ALC/LCT concept of 'object' denotes either a 'file' or a 'File
366 Delivery Table Instance' (section 3.2)
368 * The TOI field MUST be included in ALC packets sent within a FLUTE
369 session, with the exception that ALC packets sent in a FLUTE
370 session with the Close Session (A) flag set to 1 (signaling the
371 end of the session) and that contain no payload (carrying no
372 information for any file or FDT) SHALL NOT carry the TOI. See
373 Section 5.1 of RFC 3451 [3] for the LCT definition of the Close
374 Session flag, and see Section 4.2 of RFC 3450 [2] for an example
375 of its use within an ALC packet.
377 * The TOI value '0' is reserved for delivery of File Delivery Table
378 Instances. Each non expired File Delivery Table Instance is
379 uniquely identified by an FDT Instance ID.
381 * Each file in a file delivery session MUST be associated with a TOI
382 (>0) in the scope of that session.
384 * Information carried in the headers and the payload of a packet is
385 scoped by the source IP address and the TSI. Information
386 particular to the object carried in the headers and the payload of
387 a packet is further scoped by the TOI for file objects, and is
388 further scoped by both the TOI and the FDT Instance ID for FDT
389 Instance objects.
391 3.2. File Delivery Table
393 The File Delivery Table (FDT) provides a means to describe various
394 attributes associated with files that are to be delivered within the
395 file delivery session. The following lists are examples of such
396 attributes, and are not intended to be mutually exclusive nor
397 exhaustive.
399 Attributes related to the delivery of file:
401 - TOI value that represents the file
403 - FEC Object Transmission Information (including the FEC Encoding ID
404 and, if relevant, the FEC Instance ID)
406 - Size of the transmission object carrying the file
407 - Aggregate rate of sending packets to all channels
409 Attributes related to the file itself:
411 - Name, Identification and Location of file (specified by the URI)
413 - MIME media type of file
415 - Size of file
417 - Encoding of file
419 - Message digest of file
421 Some of these attributes MUST be included in the file description
422 entry for a file, others are optional, as defined in section 3.4.2.
424 Logically, the FDT is a set of file description entries for files to
425 be delivered in the session. Each file description entry MUST
426 include the TOI for the file that it describes and the URI
427 identifying the file. The TOI is included in each ALC/LCT data
428 packet during the delivery of the file, and thus the TOI carried in
429 the file description entry is how the receiver determines which ALC/
430 LCT data packets contain information about which file. Each file
431 description entry may also contain one or more descriptors that map
432 the above-mentioned attributes to the file.
434 Each file delivery session MUST have an FDT that is local to the
435 given session. The FDT MUST provide a file description entry mapped
436 to a TOI for each file appearing within the session. An object that
437 is delivered within the ALC session, but not described in the FDT, is
438 not considered a 'file' belonging to the file delivery session.
439 Handling of these unmapped TOIs (TOIs that are not resolved by the
440 FDT) is out of scope of this specification.
442 Within the file delivery session the FDT is delivered as FDT
443 Instances. An FDT Instance contains one or more file description
444 entries of the FDT. Any FDT Instance can be equal to, a subset of, a
445 superset of, or complement any other FDT Instance. A certain FDT
446 Instance may be repeated several times during a session, even after
447 subsequent FDT Instances (with higher FDT Instance ID numbers) have
448 been transmitted. Each FDT Instance contains at least a single file
449 description entry and at most the exhaustive set of file description
450 entries of the files being delivered in the file delivery session.
452 A receiver of the file delivery session keeps an FDT database for
453 received file description entries. The receiver maintains the
454 database, for example, upon reception of FDT Instances. Thus, at any
455 given time the contents of the FDT database represent the receiver's
456 current view of the FDT of the file delivery session. Since each
457 receiver behaves independently of other receivers, it SHOULD NOT be
458 assumed that the contents of the FDT database are the same for all
459 the receivers of a given file delivery session.
461 Since FDT database is an abstract concept, the structure and the
462 maintaining of the FDT database are left to individual
463 implementations and are thus out of scope of this specification.
465 3.3. Dynamics of FDT Instances within file delivery session
467 The following rules define the dynamics of the FDT Instances within a
468 file delivery session:
470 * For every file delivered within a file delivery session there MUST
471 be a file description entry included in at least one FDT Instance
472 sent within the session. A file description entry contains at a
473 minimum the mapping between the TOI and the URI.
475 * An FDT Instance MAY appear in any part of the file delivery
476 session and packets for an FDT Instance MAY be interleaved with
477 packets for other files or other FDT Instances within a session.
479 * The TOI value of '0' MUST be reserved for delivery of FDT
480 Instances. The use of other TOI values for FDT Instances is
481 outside the scope of this specification.
483 * FDT Instance is identified by the use of a new fixed length LCT
484 Header Extension EXT_FDT (defined later in this section). Each
485 non expired FDT Instance is uniquely identified within the file
486 delivery session by its FDT Instance ID. Any ALC/LCT packet
487 carrying FDT Instance (indicated by TOI = 0) MUST include EXT_FDT.
489 * It is RECOMMENDED that an FDT Instance that contains the file
490 description entry for a file is sent prior to the sending of the
491 described file within a file delivery session.
493 * Within a file delivery session, any TOI > 0 MAY be described more
494 than once. An example: previous FDT Instance 0 describes TOI of
495 value '3'. Now, subsequent FDT Instances can either keep TOI '3'
496 unmodified on the table, not include it, or complement the
497 description. However, subsequent FDT Instances MUST NOT change
498 the parameters already described for a specific TOI.
500 * An FDT Instance is valid until its expiration time. The
501 expiration time is expressed within the FDT Instance payload as a
502 32 bit data field. The value of the data field represents the 32
503 most significant bits of a 64 bit Network Time Protocol (NTP) [6]
504 time value. These 32 bits provide an unsigned integer
505 representing the time in seconds relative to 0 hours 1 January
506 1900 in case of the prime epoch (era 0) [20]. The handling of
507 time wraparound (to happen in 2036) requires to consider the
508 associated epoch. In any case, both a sender and a receiver can
509 easily determine to which (136 year) epoch the FDT Instance
510 expiration time value pertains to.
512 * The receiver SHOULD NOT use a received FDT Instance to interpret
513 packets received beyond the expiration time of the FDT Instance.
515 * A sender MUST use an expiry time in the future upon creation of an
516 FDT Instance relative to its Sender Current Time (SCT).
518 * Any FEC Encoding ID MAY be used for the sending of FDT Instances.
519 The default is to use FEC Encoding ID 0 [5] for the sending of FDT
520 Instances. (Note that since FEC Encoding ID 0 is the default for
521 FLUTE, this implies that Source Block Number and Encoding Symbol
522 ID lengths both default to 16 bits each.)
524 Generally, a receiver needs to receive an FDT Instance describing a
525 file before it is able to recover the file itself. In this sense FDT
526 Instances are of higher priority than files. Additionally, a FLUTE
527 sender SHOULD assume receivers will not receive all packets
528 pertaining to FDT Instances, i.e., it is RECOMMENDED that FDT
529 Instances be managed in such a way that a receiver will be able to
530 recover at least one FDT Instance describing a file delivered within
531 the file delivery session with as much or greater reliability as the
532 receiver is able to receive enough packets containing encoding
533 symbols to recover the file.
535 From this point of view, the way a given FDT Instance is transmitted
536 has great impacts. As an example, one way to satisfy this
537 recommendation is to repeat FDT Instances describing the file often
538 enough. As another example, if an FDT Instance is longer than one
539 packet payload in length, it is RECOMMENDED that an FEC code that
540 provides protection against loss be used for delivering this FDT
541 Instance. The way the FDT is delivered as FDT Instances has also
542 great impacts. As an example, a way to satisfy this recommendation
543 is to use an FDT Instance that describes all the files being
544 transmitted at that time, and to transmit this FDT Instance reliably,
545 as explained above. If instead those files are described in separate
546 FDT Instances, another way to satisfy this recommendation is to
547 transmit all the relevant FDT Instances reliably, as explained above.
549 In any case, how often the description of a file is sent in an FDT
550 Instance, how often an FDT Instance is sent, and how much FEC
551 protection is provided for an FDT Instance (if longer than one packet
552 payload) are dependent on the particular application and are outside
553 the scope of this document.
555 3.4. Structure of FDT Instance packets
557 FDT Instances are carried in ALC packets with TOI = 0 and with an
558 additional REQUIRED LCT Header extension called the FDT Instance
559 Header. The FDT Instance Header (EXT_FDT) contains the FDT Instance
560 ID that uniquely identifies FDT Instances within a file delivery
561 session. The FDT Instance Header is placed in the same way as any
562 other LCT extension header. There MAY be other LCT extension headers
563 in use.
565 The LCT extension headers are followed by the FEC Payload ID, and
566 finally the Encoding Symbols for the FDT Instance which contains one
567 or more file description entries. A FDT Instance MAY span several
568 ALC packets - the number of ALC packets is a function of the file
569 attributes associated with the FDT Instance. The FDT Instance Header
570 is carried in each ALC packet carrying the FDT Instance. The FDT
571 Instance Header is identical for all ALC/LCT packets for a particular
572 FDT Instance.
574 The overall format of ALC/LCT packets carrying an FDT Instance is
575 depicted in the Figure 1 below. All integer fields are carried in
576 "big-endian" or "network order" format, that is, most significant
577 byte (octet) first. As defined in [2], all ALC/LCT packets are sent
578 using UDP.
580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
581 | UDP header |
582 | |
583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
584 | Default LCT header (with TOI = 0) |
585 | |
586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
587 | LCT header extensions (EXT_FDT, EXT_FTI, etc.) |
588 | |
589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
590 | FEC Payload ID |
591 | |
592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
593 FLUTE Payload: Encoding Symbol(s)
594 ~ (for FDT Instance in a FDT packet) ~
596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
598 Figure 1: Overall FDT Packet
600 3.4.1. Format of FDT Instance Header
602 FDT Instance Header (EXT_FDT) is a new fixed length, ALC PI specific
603 LCT header extension [3]. The Header Extension Type (HET) for the
604 extension is 192. Its format is defined below:
606 0 1 2 3
607 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
608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
609 | HET = 192 | V | FDT Instance ID |
610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
612 Figure 2
614 Version of FLUTE (V), 4 bits:
616 This document specifies FLUTE version 1. Hence in any ALC packet
617 that carries FDT Instance and that belongs to the file delivery
618 session as specified in this specification MUST set this field to
619 '1'.
621 FDT Instance ID, 20 bits:
623 For each file delivery session the numbering of FDT Instances starts
624 from '0' and is incremented by one for each subsequent FDT Instance.
625 After reaching the maximum value (2^20-1), the numbering starts from
626 the smallest FDT Instance value assigned to an expired FDT Instance.
627 When wraparound from a greater FDT Instance ID value to a smaller FDT
628 Instance ID value occurs, the smaller FDT Instance ID value is
629 considered logically higher than the greater FDT Instance ID value.
630 A new FDT Instance reusing a previous FDT Instance ID number, due to
631 wraparound, does not implicitly expire the previous FDT Instance with
632 the same ID. Sender behavior when all the FDT Instance IDs are used
633 by non expired FEC Instances is outside the scope of this
634 specification and left to individual implementations of FLUTE.
635 Receiver behavior when receiving an FDT Instance that reuses an FDT
636 Instance ID value that is currently used by a non expired FDT
637 Instance is outside the scope of this specification and left to
638 individual implementations of FLUTE. However a receiver MUST be
639 ready to handle FDT Instance ID wraparound and situations where
640 missing FDT Instance IDs result in increments larger than one.
642 3.4.2. Syntax of FDT Instance
644 The FDT Instance contains file description entries that provide the
645 mapping functionality described in 3.2 above.
647 The FDT Instance is an XML structure that has a single root element
648 "FDT-Instance". The "FDT-Instance" element MUST contain "Expires"
649 attribute, which tells the expiry time of the FDT Instance. In
650 addition, the "FDT-Instance" element MAY contain the "Complete"
651 attribute (boolean), which, when TRUE, signals that this "FDT
652 Instance" includes the set of "File" entries that exhausts both the
653 set of files delivered so far and also the set of files to be
654 delivered in the session. This implies that no new data will be
655 provided in future FDT Instances within this session (i.e., that
656 either FDT Instances with higher ID numbers will not be used or if
657 they are used, will only provide identical file parameters to those
658 already given in this and previous FDT Instances). The "Complete"
659 attribute is therefore used to provide a complete list of files in an
660 entire FLUTE session (a "complete FDT").
662 The "FDT-Instance" element MAY contain attributes that give common
663 parameters for all files of an FDT Instance. These attributes MAY
664 also be provided for individual files in the "File" element. Where
665 the same attribute appears in both the "FDT-Instance" and the "File"
666 elements, the value of the attribute provided in the "File" element
667 takes precedence.
669 For each file to be declared in the given FDT Instance there is a
670 single file description entry in the FDT Instance. Each entry is
671 represented by element "File" which is a child element of the FDT
672 Instance structure.
674 The attributes of "File" element in the XML structure represent the
675 attributes given to the file that is delivered in the file delivery
676 session. The value of the XML attribute name corresponds to MIME
677 field name and the XML attribute value corresponds to the value of
678 the MIME field body. Each "File" element MUST contain at least two
679 attributes "TOI" and "Content-Location". "TOI" MUST be assigned a
680 valid TOI value as described in section 3.3 above. "Content-
681 Location" MUST be assigned a valid URI as defined in [7]. The
682 semantics for any two "File" elements declaring the same "Content-
683 Location" but differing "TOI" is that the element appearing in the
684 FDT Instance with the greater FDT Instance ID is considered to
685 declare newer instance (e.g. version) of the same "File".
687 In addition to mandatory attributes, the "FDT-Instance" element and
688 the "File" element MAY contain other attributes of which the
689 following are specifically pointed out.
691 * Where the MIME type is described, the attribute "Content-Type"
692 MUST be used for the purpose as defined in [7].
694 * Where the length is described, the attribute "Content-Length" MUST
695 be used for the purpose as defined in [7]. The transfer length is
696 defined to be the length of the object transported in bytes. It
697 is often important to convey the transfer length to receivers,
698 because the source block structure needs to be known for the FEC
699 decoder to be applied to recover source blocks of the file, and
700 the transfer length is often needed to properly determine the
701 source block structure of the file. There generally will be a
702 difference between the length of the original file and the
703 transfer length if content encoding is applied to the file before
704 transport, and thus the "Content-Encoding" attribute is used. If
705 the file is not content encoded before transport (and thus the
706 "Content-Encoding" attribute is not used) then the transfer length
707 is the length of the original file, and in this case the "Content-
708 Length" is also the transfer length. However, if the file is
709 content encoded before transport (and thus the "Content-Encoding"
710 attribute is used), e.g., if compression is applied before
711 transport to reduce the number of bytes that need to be
712 transferred, then the transfer length is generally different than
713 the length of the original file, and in this case the attribute
714 "Transfer-Length" MAY be used to carry the transfer length.
716 * Where the content encoding scheme is described, the attribute
717 "Content-Encoding" MUST be used for the purpose as defined in [7].
719 * Where the MD5 message digest is described, the attribute "Content-
720 MD5" MUST be used for the purpose as defined in [7].
722 * The FEC Object Transmission Information attributes as described in
723 section 5.2.
725 The following specifies the XML Schema [8][9] for FDT Instance:
727 BEGIN
728
729
733
734
735
736
737
739
740
743
746
749
752
755
758
761
764
767
771
772
773
774
775
777
778
781
784
787
790
793
796
799
802
805
808
811
814
817
818
820
821 END
823 Figure 3
825 Any valid FDT Instance must use the above XML Schema. This way FDT
826 provides extensibility to support private attributes within the file
827 description entries. Those could be, for example, the attributes
828 related to the delivery of the file (timing, packet transmission
829 rate, etc.).
831 In case the basic FDT XML Schema is extended in terms of new
832 descriptors (attributes or elements), for descriptors applying to a
833 single file, those MUST be placed within the element "File". For
834 descriptors applying to all files described by the current FDT
835 Instance, those MUST be placed within the element "FDT-Instance". It
836 is RECOMMENDED that the new attributes applied in the FDT are in the
837 format of MIME fields and are either defined in the HTTP/1.1
838 specification [7] or another well-known specification.
840 3.4.3. Content Encoding of FDT Instance
842 The FDT Instance itself MAY be content encoded, for example
843 compressed. This specification defines FDT Instance Content Encoding
844 Header (EXT_CENC). EXT_CENC is a new fixed length, ALC PI specific
845 LCT header extension [3]. The Header Extension Type (HET) for the
846 extension is 193. If the FDT Instance is content encoded, the
847 EXT_CENC MUST be used to signal the content encoding type. In that
848 case, EXT_CENC header extension MUST be used in all ALC packets
849 carrying the same FDT Instance ID. Consequently, when EXT_CENC
850 header is used, it MUST be used together with a proper FDT Instance
851 Header (EXT_FDT). Within a file delivery session, FDT Instances that
852 are not content encoded and FDT Instances that are content encoded
853 MAY both appear. If content encoding is not used for a given FDT
854 Instance, the EXT_CENC MUST NOT be used in any packet carrying the
855 FDT Instance. The format of EXT_CENC is defined below:
857 0 1 2 3
858 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
859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
860 | HET = 193 | CENC | Reserved |
861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
863 Figure 4
865 Content Encoding Algorithm (CENC), 8 bits:
867 This field signals the content encoding algorithm used in the FDT
868 Instance payload. This subsection reserves the Content Encoding
869 Algorithm values 0, 1, 2 and 3 for null, ZLIB [13], DEFLATE [14] and
870 GZIP [15] respectively.
872 Reserved, 16 bits:
874 This field MUST be set to all '0'. This field SHOULD be ignored on
875 reception.
877 3.5. Multiplexing of files within a file delivery session
879 The delivered files are carried as transmission objects (identified
880 with TOIs) in the file delivery session. All these objects,
881 including the FDT Instances, MAY be multiplexed in any order and in
882 parallel with each other within a session, i.e., packets for one file
883 MAY be interleaved with packets for other files or other FDT
884 Instances within a session.
886 Multiple FDT Instances MAY be delivered in a single session using TOI
887 = 0. In this case, it is RECOMMENDED that the sending of a previous
888 FDT Instance SHOULD end before the sending of the next FDT Instance
889 starts. However, due to unexpected network conditions, packets for
890 the FDT Instances MAY be interleaved. A receiver can determine which
891 FDT Instance a packet contains information about since the FDT
892 Instances are uniquely identified by their FDT Instance ID carried in
893 the EXT_FDT headers.
895 4. Channels, congestion control and timing
897 ALC/LCT has a concept of channels and congestion control. There are
898 four scenarios FLUTE is envisioned to be applied.
900 (a) Use a single channel and a single-rate congestion control
901 protocol.
903 (b) Use multiple channels and a multiple-rate congestion control
904 protocol. In this case the FDT Instances MAY be delivered on more
905 than one channel.
907 (c) Use a single channel without congestion control supplied by ALC,
908 but only when in a controlled network environment where flow/
909 congestion control is being provided by other means.
911 (d) Use multiple channels without congestion control supplied by
912 ALC, but only when in a controlled network environment where flow/
913 congestion control is being provided by other means. In this case
914 the FDT Instances MAY be delivered on more than one channel.
916 When using just one channel for a file delivery session, as in (a)
917 and (c), the notion of 'prior' and 'after' are intuitively defined
918 for the delivery of objects with respect to their delivery times.
920 However, if multiple channels are used, as in (b) and (d), it is not
921 straightforward to state that an object was delivered 'prior' to the
922 other. An object may begin to be delivered on one or more of those
923 channels before the delivery of a second object begins. However, the
924 use of multiple channels/layers may complete the delivery of the
925 second object before the first. This is not a problem when objects
926 are delivered sequentially using a single channel. Thus, if the
927 application of FLUTE has a mandatory or critical requirement that the
928 first transmission object must complete 'prior' to the second one, it
929 is RECOMMENDED that only a single channel is used for the file
930 delivery session.
932 Furthermore, if multiple channels are used then a receiver joined to
933 the session at a low reception rate will only be joined to the lower
934 layers of the session. Thus, since the reception of FDT Instances is
935 of higher priority than the reception of files (because the reception
936 of files depends on the reception of an FDT Instance describing it),
937 the following is RECOMMENDED:
939 1. The layers to which packets for FDT Instances are sent SHOULD NOT
940 be biased towards those layers to which lower rate receivers are
941 not joined. For example, it is okay to put all the packets for an
942 FDT Instance into the lowest layer (if this layer carries enough
943 packets to deliver the FDT to higher rate receivers in a
944 reasonable amount of time), but it is not okay to put all the
945 packets for an FDT Instance into the higher layers that only high
946 rate receivers will receive.
948 2. If FDT Instances are generally longer than one Encoding Symbol in
949 length and some packets for FDT Instances are sent to layers that
950 lower rate receivers do not receive, an FEC Encoding other than
951 FEC Encoding ID 0 [5] SHOULD be used to deliver FDT Instances.
952 This is because in this case, even when there is no packet loss in
953 the network, a lower rate receiver will not receive all packets
954 sent for an FDT Instance.
956 5. Delivering FEC Object Transmission Information
958 FLUTE inherits the use of FEC building block [4] from ALC. When
959 using FLUTE for file delivery over ALC the FEC Object Transmission
960 Information MUST be delivered in-band within the file delivery
961 session. There are two methods to achieve this: the use of ALC
962 specific LCT extension header EXT_FTI [2] and the use of FDT. The
963 latter method is specified in this section.
965 The receiver of file delivery session MUST support delivery of FEC
966 Object Transmission Information using the EXT_FTI for the FDT
967 Instances carried using TOI value 0. For the TOI values other than 0
968 the receiver MUST support both methods: the use of EXT_FTI and the
969 use of FDT.
971 The FEC Object Transmission Information that needs to be delivered to
972 receivers MUST be exactly the same whether it is delivered using
973 EXT_FTI or using FDT (or both). The FEC Object Transmission
974 Information that MUST be delivered to receivers is defined by the FEC
975 Scheme. This section describes the delivery using FDT.
977 The FEC Object Transmission Information regarding a given TOI may be
978 available from several sources. In this case, it is RECOMMENDED that
979 the receiver of the file delivery session prioritizes the sources in
980 the following way (in the order of decreasing priority).
982 1. FEC Object Transmission Information that is available in EXT_FTI.
984 2. FEC Object Transmission Information that is available in the FDT.
986 The FDT delivers FEC Object Transmission Information for each file
987 using an appropriate attribute within the "FDT-Instance" or the
988 "File" element of the FDT structure.
990 * "Transfer-Length" carries the Transfer-Length Object Transmission
991 Information element defined in [4].
993 * "FEC-OTI-FEC-Encoding-ID" carries the "FEC Encoding ID" Object
994 Transmission Information element defined in [4], as carried in the
995 Codepoint field of the ALC/LCT header.
997 * "FEC-OTI-FEC-Instance-ID" carries the "FEC Instance ID" Object
998 Transmission Information element defined in [4] for Under-
999 specified FEC Schemes.
1001 * "FEC-OTI-Maximum-Source-Block-Length" carries the "Maximum Source
1002 Block Length" Object Transmission Information element defined in
1003 [4], if required by the FEC Scheme.
1005 * "FEC-OTI-Encoding-Symbol-Length" carries the "Encoding Symbol
1006 Length" Object Transmission Information element defined in [4], if
1007 required by the FEC Scheme.
1009 * "FEC-OTI-Max-Number-of-Encoding-Symbols" carries the "Maximum
1010 Number of Encoding Symbols" Object Transmission Information
1011 element defined in [4], if required by the FEC Scheme.
1013 * "FEC-OTI-Scheme-specific-information" carries the "encoded scheme-
1014 specific FEC Object Transmission Information" as defined in [4],
1015 if required by the FEC Scheme.
1017 In FLUTE, the FEC Encoding ID (8 bits) for a given TOI MUST be
1018 carried in the Codepoint field of the ALC/LCT header. When the FEC
1019 Object Transmission Information for this TOI is delivered through the
1020 FDT, then the associated "FEC-OTI-FEC-Encoding-ID" attribute and the
1021 Codepoint field of all packets for this TOI MUST be the same.
1023 6. Describing file delivery sessions
1025 To start receiving a file delivery session, the receiver needs to
1026 know transport parameters associated with the session. Interpreting
1027 these parameters and starting the reception therefore represents the
1028 entry point from which thereafter the receiver operation falls into
1029 the scope of this specification. According to [2], the transport
1030 parameters of an ALC/LCT session that the receiver needs to know are:
1032 * The source IP address;
1034 * The number of channels in the session;
1036 * The destination IP address and port number for each channel in the
1037 session;
1039 * The Transport Session Identifier (TSI) of the session;
1041 * An indication that the session is a FLUTE session. The need to
1042 demultiplex objects upon reception is implicit in any use of
1043 FLUTE, and this fulfills the ALC requirement of an indication of
1044 whether or not a session carries packets for more than one object
1045 (all FLUTE sessions carry packets for more than one object).
1047 Optionally, the following parameters MAY be associated with the
1048 session (Note, the list is not exhaustive):
1050 * The start time and end time of the session;
1052 * FEC Encoding ID and FEC Instance ID when the default FEC Encoding
1053 ID 0 is not used for the delivery of FDT;
1055 * Content Encoding format if optional content encoding of FDT
1056 Instance is used, e.g., compression;
1058 * Some information that tells receiver, in the first place, that the
1059 session contains files that are of interest;
1061 * Definition and configuration of congestion control mechanism for
1062 the session ;
1064 * Security parameters relevant for the session.
1066 It is envisioned that these parameters would be described according
1067 to some session description syntax (such as SDP [17] or XML based)
1068 and held in a file which would be acquired by the receiver before the
1069 FLUTE session begins by means of some transport protocol (such as
1070 Session Announcement Protocol [16], email, HTTP [7], SIP [26], manual
1071 pre-configuration, etc.) However, the way in which the receiver
1072 discovers the above-mentioned parameters is out of scope of this
1073 document, as it is for LCT and ALC. In particular, this
1074 specification does not mandate or exclude any mechanism.
1076 7. Security Considerations
1078 7.1. Problem Statement
1080 A content delivery system is potentially subject to attacks. Attacks
1081 may target:
1083 * the network (to compromise the routing infrastructure, e.g., by
1084 creating congestion),
1086 * the Content Delivery Protocol (CDP) (e.g., to compromise the
1087 normal behaviour of FLUTE), or
1089 * the content itself (e.g., to corrupt the files being transmitted).
1091 These attacks can be launched either:
1093 * against the data flow itself (e.g., by sending forged packets),
1095 * against the session control parameters (e.g., by corrupting the
1096 session description, the FDT Instances, or the ALC/LCT control
1097 parameters) that are sent either in-band or out-of-band, or
1099 * against some associated building blocks (e.g., the congestion
1100 control component).
1102 In the following sections we provide more details on these possible
1103 attacks and sketch some possible counter-measures. We finally
1104 provide recommendations in Section 7.5.
1106 7.2. Attacks against the data flow
1108 Let us consider attacks against the data flow first. At least, the
1109 following types of attacks exist:
1111 * attacks that are meant to give access to a confidential file
1112 (e.g., in case of a non-free content) and
1114 * attacks that try to corrupt the file being transmitted (e.g., to
1115 inject malicious code within a file, or to prevent a receiver from
1116 using a file, which is a kind of Denial of Service, DoS).
1118 7.2.1. Access to confidential files
1120 Access control to the file being transmitted is typically provided by
1121 means of encryption. This encryption can be done over the whole file
1122 (e.g., by the content provider, before submitting the file to FLUTE),
1123 or be done on a packet per packet basis (e.g., when IPsec/ESP is used
1124 [30], see Section 7.5). If confidentiality is a concern, it is
1125 RECOMMENDED that one of these solutions be used.
1127 7.2.2. File corruption
1129 Protection against corruptions (e.g., if an attacker sends forged
1130 packets) is achieved by means of a content integrity verification/
1131 sender authentication scheme. This service can be provided at the
1132 file level, but in that case a receiver has no way to identify which
1133 symbol(s) is(are) corrupted if the file is detected as corrupted.
1134 This service can also be provided at the packet level. In this case,
1135 after removing all corrupted packets, the file may be in some cases
1136 recovered. Several techniques can provide this source
1137 authentication/content integrity service:
1139 * at the file level, the file MAY be digitally signed, for instance
1140 by using RSASSA-PKCS1-v1_5 [29]. This signature enables a
1141 receiver to check the file integrity, once this latter has been
1142 fully decoded. Even if digital signatures are computationally
1143 expensive, this calculation occurs only once per file, which is
1144 usually acceptable;
1146 * at the packet level, each packet can be digitally signed [34]. A
1147 major limitation is the high computational and transmission
1148 overheads that this solution requires. To avoid this problem, the
1149 signature may span a set of symbols (instead of a single one) in
1150 order to amortize the signature calculation, but if a single
1151 symbol is missing, the integrity of the whole set cannot be
1152 checked;
1154 * at the packet level, a Group Message Authentication Code (MAC)
1155 [31][34] scheme can be used, for instance by using HMAC-SHA-256
1156 with a secret key shared by all the group members, senders and
1157 receivers. This technique creates a cryptographically secured
1158 digest of a packet that is sent along with the packet. The Group
1159 MAC scheme does not create prohibitive processing load nor
1160 transmission overhead, but it has a major limitation: it only
1161 provides a group authentication/integrity service since all group
1162 members share the same secret group key, which means that each
1163 member can send a forged packet. It is therefore restricted to
1164 situations where group members are fully trusted (or in
1165 association with another technique as a pre-check);
1167 * at the packet level, TESLA [32][33] is an attractive solution that
1168 is robust to losses, provides a true authentication/integrity
1169 service, and does not create any prohibitive processing load or
1170 transmission overhead. Yet checking a packet requires a small
1171 delay (a second or more) after its reception;
1173 * at the packet level, IPsec/ESP [30] can be used to check the
1174 integrity and authenticate the sender of all the packets being
1175 exchanged in a session (see Section 7.5).
1177 Techniques relying on public key cryptography (digital signatures and
1178 TESLA during the bootstrap process, when used) require that public
1179 keys be securely associated to the entities. This can be achieved by
1180 a Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by
1181 pre-distributing the public keys of each group member.
1183 Techniques relying on symmetric key cryptography (Group MAC) require
1184 that a secret key be shared by all group members. This can be
1185 achieved by means of a group key management protocol, or simply by
1186 pre-distributing the secret key (but this manual solution has many
1187 limitations).
1189 It is up to the developer and deployer, who know the security
1190 requirements and features of the target application area, to define
1191 which solution is the most appropriate. Nonetheless, in case there
1192 is any concern of the threat of file corruption, it is RECOMMENDED
1193 that at least one of these techniques be used.
1195 7.3. Attacks against the session control parameters and associated
1196 Building Blocks
1198 Let us now consider attacks against the session control parameters
1199 and the associated building blocks. The attacker has at least the
1200 following opportunities to launch an attack:
1202 * the attack can target the session description,
1204 * the attack can target the FDT Instances,
1206 * the attack can target the ALC/LCT parameters, carried within the
1207 LCT header or
1209 * the attack can target the FLUTE associated building blocks, for
1210 instance the multiple rate congestion control protocol.
1212 The consequences of these attacks are potentially serious, since they
1213 might compromise the behavior of content delivery system itself.
1215 7.3.1. Attacks against the Session Description
1217 A FLUTE receiver may potentially obtain an incorrect Session
1218 Description for the session. The consequence of this is that
1219 legitimate receivers with the wrong Session Description are unable to
1220 correctly receive the session content, or that receivers
1221 inadvertently try to receive at a much higher rate than they are
1222 capable of, thereby possibly disrupting other traffic in the network.
1224 To avoid these problems, it is RECOMMENDED that measures be taken to
1225 prevent receivers from accepting incorrect Session Descriptions. One
1226 such measure is source authentication to ensure that receivers only
1227 accept legitimate Session Descriptions from authorized senders. How
1228 these measures are achieved is outside the scope of this document
1229 since this session description is usually carried out-of-band.
1231 7.3.2. Attacks against the FDT Instances
1233 Corrupting the FDT Instances is one way to create a Denial of Service
1234 attack. For example, the attacker changes the MD5 sum associated to
1235 a file. This possibly leads a receiver to reject the files received,
1236 no matter whether the files have been correctly received or not.
1238 Corrupting the FDT Instances is also a way to make the reception
1239 process more costly than it should be. This can be achieved by
1240 changing the FEC Object Transmission Information when the FEC Object
1241 Transmission Information is included in the FDT Instance. For
1242 example, an attacker may corrupt the FDT Instance in such a way that
1243 Reed-Solomon over GF(2^^16) be used instead of GF(2^^8) with FEC
1244 Encoding ID 2. This may significantly increase the processing load
1245 while compromising FEC decoding.
1247 It is therefore RECOMMENDED that measures be taken to guarantee the
1248 integrity and to check the sender's identity of the FDT Instances.
1249 To that purpose, one of the counter-measures mentioned above
1250 (Section 7.2.2) SHOULD be used. These measures will either be
1251 applied on a packet level, or globally over the whole FDT Instance
1252 object. Additionally, XML digital signatures [23] are a way to
1253 protect the FDT Instance by digitally signing it. When there is no
1254 packet level integrity verification scheme, it is RECOMMENDED to rely
1255 on XML digital signatures of the FDT Instances.
1257 7.3.3. Attacks against the ALC/LCT parameters
1259 By corrupting the ALC/LCT header (or header extensions) one can
1260 execute attacks on underlying ALC/LCT implementation. For example,
1261 sending forged ALC packets with the Close Session flag (A) set to one
1262 can lead the receiver to prematurely close the session. Similarly,
1263 sending forged ALC packets with the Close Object flag (B) set to one
1264 can lead the receiver to prematurely give up the reception of an
1265 object.
1267 It is therefore RECOMMENDED that measures be taken to guarantee the
1268 integrity and to check the sender's identity of the ALC packets
1269 received. To that purpose, one of the counter-measures mentioned
1270 above (Section 7.2.2) SHOULD be used.
1272 7.3.4. Attacks against the associated Building Blocks
1274 Let us first focus on the congestion control building block, that may
1275 be used in the ALC session. A receiver with an incorrect or
1276 corrupted implementation of the multiple rate congestion control
1277 building block may affect the health of the network in the path
1278 between the sender and the receiver. That may also affect the
1279 reception rates of other receivers who joined the session.
1281 When congestion control building block is applied with FLUTE, it is
1282 therefore RECOMMENDED that receivers be required to identify
1283 themselves as legitimate before they receive the Session Description
1284 needed to join the session. How receivers identify themselves as
1285 legitimate is outside the scope of this document. If authenticating
1286 a receiver does not prevent this latter to launch an attack, it will
1287 enable the network operator to identify him and to take counter-
1288 measures.
1290 When congestion control building block is applied with FLUTE, it is
1291 also RECOMMENDED that a packet level authentication scheme be used,
1292 as explained in Section 7.2.2. Some of them, like TESLA, only
1293 provide a delayed authentication service, whereas congestion control
1294 requires a rapid reaction. It is therefore RECOMMENDED [2] that a
1295 receiver using TESLA quickly reduces its subscription level when the
1296 receiver believes that a congestion did occur, even if the packet has
1297 not yet been authenticated. Therefore TESLA will not prevent DoS
1298 attacks where an attacker makes the receiver believe that a
1299 congestion occurred. This is an issue for the receiver, but this
1300 will not compromise the network. Other authentication methods that
1301 do not feature this delayed authentication could be preferred, or a
1302 group MAC scheme could be used in parallel to TESLA to prevent
1303 attacks launched from outside of the group.
1305 7.4. Other Security Considerations
1307 Lastly, we note that the security considerations that apply to, and
1308 are described in, ALC [2], LCT [3] and FEC [4] also apply to FLUTE as
1309 FLUTE builds on those specifications. In addition, any security
1310 considerations that apply to any congestion control building block
1311 used in conjunction with FLUTE also apply to FLUTE.
1313 7.5. Minimum Security Recommendations
1315 We now introduce a mandatory to implement but not necessarily to use
1316 security configuration, in the sense of [21]. Since FLUTE relies on
1317 ALC/LCT, it inherits the "baseline secure ALC operation" of [2].
1318 More precisely, security is achieved by means of IPsec/ESP in
1319 transport mode. [30] explains that ESP can be used to potentially
1320 provide confidentiality, data origin authentication, content
1321 integrity, anti-replay and (limited) traffic flow confidentiality.
1322 [2] specifies that the data origin authentication, content integrity
1323 and anti-replay services SHALL be used, and that the confidentiality
1324 service is RECOMMENDED. If a short lived session MAY rely on manual
1325 keying, it is also RECOMMENDED that an automated key management
1326 scheme be used, especially in case of long lived sessions.
1328 Therefore, the RECOMMENDED solution for FLUTE provides per-packet
1329 security, with data origin authentication, integrity verification and
1330 anti-replay. This is sufficient to prevent most of the in-band
1331 attacks listed above. If confidentiality is required, a per-packet
1332 encryption SHOULD also be used.
1334 8. IANA Considerations
1336 This specification contains three separate items for IANA
1337 Considerations:
1339 1. Registration Request for XML Schema of FDT Instance.
1341 2. Media-Type Registration Request for application/fdt+xml.
1343 3. Content Encoding Algorithm Registration Request.
1345 8.1. Registration Request for XML Schema of FDT Instance
1347 Document [28] defines an IANA maintained registry of XML documents
1348 used within IETF protocols. The following is the registration
1349 request for the FDT XML schema.
1351 Registrant Contact: Toni Paila (toni.paila (at) nokia.com)
1353 XML: The XML Schema specified in Section 3.4.2
1355 8.2. Media-Type Registration Request for application/fdt+xml
1357 This section provides the registration request, as per [24], [25] and
1358 [10], to be submitted to IANA following IESG approval.
1360 Type name: application
1362 Subtype name: fdt+xml
1364 Required parameters: none
1366 Optional parameters: none
1368 Encoding considerations: The fdt+xml type consists of UTF-8 ASCII
1369 characters [11] and must be well-formed XML.
1371 Additional content and transfer encodings may be used with fdt+xml
1372 files, with the appropriate encoding for any specific file being
1373 entirely dependant upon the deployed application.
1375 Restrictions on usage: Only for usage with FDT Instances which are
1376 valid according to the XML schema of section 3.4.2.
1378 Security considerations: fdt+xml data is passive, and does not
1379 generally represent a unique or new security threat. However, there
1380 is some risk in sharing any kind of data, in that unintentional
1381 information may be exposed, and that risk applies to fdt+xml data as
1382 well.
1384 Interoperability considerations: None
1386 Published specification: The present document including section
1387 3.4.2. The specified FDT Instance functions as an actual media
1388 format of use to the general Internet community and thus media type
1389 registration under the Standards Tree is appropriate to maximize
1390 interoperability.
1392 Applications which use this media type: Not restricted to any
1393 particular application
1395 Additional information:
1397 Magic number(s): none
1398 File extension(s): An FDT Instance may use the extension ".fdt"
1399 but this is not required.
1400 Macintosh File Type Code(s): none
1402 Person and email address to contact for further information: Toni
1403 Paila (toni.paila (at) nokia.com)
1405 Intended usage: Common
1407 Author/Change controller: IETF
1409 8.3. Content Encoding Algorithm Registration Request
1411 Values of Content Encoding Algorithms are subject to IANA
1412 registration. The value of Content Encoding Algorithm is a numeric
1413 non-negative index. In this document, the range of values for
1414 Content Encoding Algorithms is 0 to 255. This specification already
1415 assigns the values 0, 1, 2 and 3 as described in section 3.4.3.
1417 8.3.1. Explicit IANA Assignment Guidelines
1419 This document defines a name-space called "Content Encoding
1420 Algorithms".
1422 IANA has established and manages the new registry for the "Content
1423 Encoding Algorithm" name-space. The values that can be assigned
1424 within this name-space are numeric indexes in the range [0, 255],
1425 boundaries included. Assignment requests are granted on a
1426 "Specification Required" basis as defined in RFC 2434 [12]. Note
1427 that the values 0, 1, 2 and 3 of this registry are already assigned
1428 by this document as described in section 3.4.3.
1430 9. Acknowledgements
1432 The following persons have contributed to this specification: Brian
1433 Adamson, Mark Handley, Esa Jalonen, Roger Kermode, Juha-Pekka Luoma,
1434 Topi Pohjolainen, Lorenzo Vicisano, and Mark Watson. The authors
1435 would like to thank all the contributors for their valuable work in
1436 reviewing and providing feedback regarding this specification.
1438 10. Contributors
1440 Jani Peltotalo
1441 Tampere University of Technology
1442 P.O. Box 553 (Korkeakoulunkatu 1)
1443 Tampere FIN-33101
1444 Finland
1445 Email: jani.peltotalo (at) tut.fi
1447 Sami Peltotalo
1448 Tampere University of Technology
1449 P.O. Box 553 (Korkeakoulunkatu 1)
1450 Tampere FIN-33101
1451 Finland
1452 Email: sami.peltotalo (at) tut.fi
1454 Magnus Westerlund
1455 Ericsson Research
1456 Ericsson AB
1457 SE-164 80 Stockholm
1458 Sweden
1459 EMail: magnus.westerlund (at) ericsson.com
1461 Thorsten Lohmar
1462 Ericsson Research (EDD)
1463 Ericsson Allee 1
1464 52134 Herzogenrath, Germany
1465 EMail: thorsten.lohmar (at) ericsson.com
1467 11. Change Log
1469 11.1. RFC3926 to draft-ietf-rmt-flute-revised-08
1471 Added clarification for the use of FLUTE for unicast communications
1472 in Section 1.1.4.
1474 Clarified how to reliably deliver the FDT in Section 3.3.
1476 Clarified how to address FDT Instance expiry time wraparound with the
1477 notion of "epoch" of NTPv4 in Section 3.3.
1479 Clarified what should be considered as erroneous situations in
1480 Section 3.4.1 (definition of FDT Instance ID). In particular a
1481 receiver MUST be ready to handle FDT Instance ID wraparounds and
1482 missing FDT Instances.
1484 Updated the security section to define IPsec/ESP as a mandatory to
1485 implement security solution in Section 7.5.
1487 Removed the 'Statement of Intent' from the Section 1. The statement
1488 of intent was meant to clarify the "Experimental" status of RFC3926.
1489 It does not apply to this draft that is intended for "Standard Track"
1490 submission.
1492 Added clarification on XML-DSIG in the end of Section 3.
1494 Revised the use of word "complete" in the Section 3.2.
1496 Clarified Figure 1 WRT "Encoding Symbol(s) for FDT Instance".
1498 Clarified the FDT Instance ID wrap-around in the end of
1499 Section 3.4.1.
1501 Clarification for "Complete FDT" in the Section 3.4.2.
1503 Added semantics for the case two TOIs refer to same Content-Location.
1504 Now it is in line how 3GPP and DVB interpret the case.
1506 In the Section 3.4.2 XML Schema of FDT instance is modified to
1507 various advices. For example, extension by element was missing but
1508 is now supported. Also namespace definition is changed to URN
1509 format.
1511 Clarified FDT-schema extensibility in the end of Section 3.4.2.
1513 The CENC value allocation is added in the end of Section 3.4.3.
1515 Section 5 is modified so that EXT_FTI and the FEC issues are replaced
1516 by a reference to LCT specification. We count on revised LCT
1517 specification to specify the EXT_FTI.
1519 Added a clarifying paragraph on the use of Codepoint in the very end
1520 of Section 5.
1522 Reworked Section 8 - IANA Considerations. Now it contains three IANA
1523 registration requests:
1525 * Registration Request for XML Schema of FDT Instance
1526 (urn:ietf:params:xml:schema:fdt)
1528 * Media-Type Registration Request for application/fdt+xml
1530 * Content Encoding Algorithm Registration Request (ietf:rmt:cenc)
1532 Added Section 10 - Contributors.
1534 Revised list of both Normative as well as Informative references.
1536 Added a clarification that receiver should ignore reserved bits of
1537 Header Extension type 193 upon reception.
1539 12. References
1541 12.1. Normative references
1543 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1544 Levels", RFC 2119, BCP 14, March 1997.
1546 [2] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered
1547 Coding (ALC) Protocol Instantiation",
1548 draft-ietf-rmt-pi-alc-revised-10 (work in progress),
1549 November 2009.
1551 [3] Luby, M., Watson, M., and L. Vicisano, "Layered Coding
1552 Transport (LCT) Building Block", RFC 5651, October 2009.
1554 [4] Watson, M., Luby, M., and L. Vicisano, "Forward Error
1555 Correction (FEC) Building Block", RFC 5052, August 2007.
1557 [5] Watson, M., "Basic Forward Error Correction (FEC) Schemes",
1558 RFC 5445, March 2009.
1560 [6] Mills, D., "Network Time Protocol (Version 3), Specification,
1561 Implementation and Analysis", RFC 1305, March 1992.
1563 [7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
1564 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
1565 HTTP/1.1", RFC 2616, June 1999.
1567 [8] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML
1568 Schema Part 1: Structures", W3C Recommendation, May 2001.
1570 [9] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes",
1571 W3C Recommendation, May 2001.
1573 [10] Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types",
1574 RFC 3023, January 2001.
1576 [11] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
1577 RFC 3629, November 2003.
1579 [12] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
1580 Considerations Section in RFCs", RFC 5226, May 2008.
1582 [13] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
1583 Specification version 3.3", RFC 1950, May 1996.
1585 [14] Deutsch, P., "DEFLATE Compressed Data Format Specification
1586 version 1.3", RFC 1951, May 1996.
1588 [15] Deutsch, P., "GZIP file format specification version 4.3",
1589 RFC 1952, May 1996.
1591 12.2. Informative references
1593 [16] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
1594 Protocol", RFC 2974, October 2000.
1596 [17] Handley, M., Jacobson, V., and C. Perkins, "Session Description
1597 Protocol", RFC 4566, July 2006.
1599 [18] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
1600 STD 5, August 1989.
1602 [19] Holbrook, H., "A Channel Model for Multicast, Ph.D.
1603 Dissertation, Stanford University, Department of Computer
1604 Science, Stanford, California", August 2001.
1606 [20] Kasch, W., Mills, D., and J. Burbank, "Network Time Protocol
1607 Version 4 Protocol And Algorithms Specification",
1608 draft-ietf-ntp-ntpv4-proto-13 (work in progress) (work in
1609 progress), October 2009.
1611 [21] Schiller, J., "Strong Security Requirements for Internet
1612 Engineering Task Force Standard Protocols", BCP 61, RFC 3365,
1613 August 2002.
1615 [22] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
1616 (S/MIME) Version 3.1 Message Specification", RFC 3851,
1617 July 2004.
1619 [23] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
1620 Language) XML-Signature Syntax and Processing", RFC 3275,
1621 March 2002.
1623 [24] Freed, N. and J. Klensin, "Media Type Specifications and
1624 Registration Procedures", RFC 4288, December 2005.
1626 [25] Freed, N. and J. Klensin, "Multipurpose Internet Mail
1627 Extensions (MIME) Part Four: Registration Procedures",
1628 RFC 4289, December 2005.
1630 [26] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
1631 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
1632 session initiation protocol", RFC 3261, June 2002.
1634 [27] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control
1635 (WEBRC) Building Block", RFC 3738, April 2004.
1637 [28] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
1639 [29] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
1640 (PKCS) #1: RSA Cryptography Specifications Version 2.1",
1641 RFC 3447, February 2003.
1643 [30] Kent, S., "Encapsulating Security Payload (ESP)", RFC 4303,
1644 December 2005.
1646 [31] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
1647 for Message Authentication", RFC 2104, February 1997.
1649 [32] Perrig, A., Canetti, R., Tygar, J D., and B. Briscoe, "Timed
1650 Efficient Stream Loss-Tolerant Authentication (TESLA):
1651 Multicast Source Authentication Transform Introduction",
1652 RFC 4082, June 2005.
1654 [33] Roca, V., Francillon, A., and S. Faurite, "Use of TESLA in the
1655 ALC and NORM Protocols",
1656 draft-ietf-msec-tesla-for-alc-norm-10.txt (work in progress),
1657 October 2009.
1659 [34] Roca, V., "Simple Authentication Schemes for the ALC and NORM
1660 Protocols", draft-ietf-rmt-simple-auth-for-alc-norm-02.txt
1661 (work in progress), October 2009.
1663 Appendix A. Receiver operation (informative)
1665 This section gives an example how the receiver of the file delivery
1666 session may operate. Instead of a detailed state-by-state
1667 specification the following should be interpreted as a rough sequence
1668 of an envisioned file delivery receiver.
1670 1. The receiver obtains the description of the file delivery session
1671 identified by the pair: (source IP address, Transport Session
1672 Identifier). The receiver also obtains the destination IP
1673 addresses and respective ports associated with the file delivery
1674 session.
1676 2. The receiver joins the channels in order to receive packets
1677 associated with the file delivery session. The receiver may
1678 schedule this join operation utilizing the timing information
1679 contained in a possible description of the file delivery session.
1681 3. The receiver receives ALC/LCT packets associated with the file
1682 delivery session. The receiver checks that the packets match the
1683 declared Transport Session Identifier. If not, packets are
1684 silently discarded.
1686 4. While receiving, the receiver demultiplexes packets based on
1687 their TOI and stores the relevant packet information in an
1688 appropriate area for recovery of the corresponding file.
1689 Multiple files can be reconstructed concurrently.
1691 5. Receiver recovers an object. An object can be recovered when an
1692 appropriate set of packets containing Encoding Symbols for the
1693 transmission object have been received. An appropriate set of
1694 packets is dependent on the properties of the FEC Encoding ID and
1695 FEC Instance ID, and on other information contained in the FEC
1696 Object Transmission Information.
1698 6. If the recovered object was an FDT Instance with FDT Instance ID
1699 'N', the receiver parses the payload of the instance 'N' of FDT
1700 and updates its FDT database accordingly. The receiver
1701 identifies FDT Instances within a file delivery session by the
1702 EXT_FDT header extension. Any object that is delivered using
1703 EXT_FDT header extension is an FDT Instance, uniquely identified
1704 by the FDT Instance ID. Note that TOI '0' is exclusively
1705 reserved for FDT delivery.
1707 7. If the object recovered is not an FDT Instance but a file, the
1708 receiver looks up its FDT database to get the properties
1709 described in the database, and assigns file with the given
1710 properties. The receiver also checks that received content
1711 length matches with the description in the database. Optionally,
1712 if MD5 checksum has been used, the receiver checks that
1713 calculated MD5 matches with the description in the FDT database.
1715 8. The actions the receiver takes with imperfectly received files
1716 (missing data, mismatching digestive, etc.) is outside the scope
1717 of this specification. When a file is recovered before the
1718 associated file description entry is available, a possible
1719 behavior is to wait until an FDT Instance is received that
1720 includes the missing properties.
1722 9. If the file delivery session end time has not been reached go
1723 back to 3. Otherwise end.
1725 Appendix B. Example of FDT Instance (informative)
1727
1728
1732
1736
1744
1746 Authors' Addresses
1748 Toni Paila
1749 Nokia
1750 Itamerenkatu 11-13
1751 Helsinki 00180
1752 Finland
1754 Email: toni.paila@nokia.com
1755 Rod Walsh
1756 Nokia
1757 Visiokatu 1
1758 Tampere FIN-33720
1759 Finland
1761 Email: rod.walsh@nokia.com
1763 Michael Luby
1764 Digital Fountain
1765 Qualcomm, Inc.
1766 3165 Kifer Rd.
1767 Santa Clara, CA 95051
1768 US
1770 Email: luby@qualcomm.com
1772 Vincent Roca
1773 INRIA
1774 655, av. de l'Europe
1775 Inovallee; Montbonnot
1776 ST ISMIER cedex 38334
1777 France
1779 Email: vincent.roca@inria.fr
1781 Rami Lehtonen
1782 TeliaSonera
1783 Hatanpaan valtatie 18
1784 Tampere FIN-33100
1785 Finland
1787 Email: rami.lehtonen@teliasonera.com