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