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