idnits 2.17.1 draft-roca-rmt-newfcast-06.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.ii 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 (October 19, 2009) is 5295 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-rmt-sec-discussion-04 -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RMT V. Roca 3 Internet-Draft INRIA 4 Intended status: Experimental B. Adamson 5 Expires: April 22, 2010 Naval Research Laboratory 6 October 19, 2009 8 FCAST: Scalable Object Delivery for the ALC and NORM Protocols 9 draft-roca-rmt-newfcast-06 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on April 22, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document introduces the FCAST object (e.g., file) delivery 58 application on top of the ALC and NORM reliable multicast protocols. 59 FCAST is a highly scalable application that provides a reliable 60 object delivery service. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 66 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 67 3. Definitions, Notations and Abbreviations . . . . . . . . . . . 6 68 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 70 4. FCAST Principles . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.1. FCAST Content Delivery Service . . . . . . . . . . . . . . 7 72 4.2. Meta-Data Transmission . . . . . . . . . . . . . . . . . . 7 73 4.3. Meta-Data Content . . . . . . . . . . . . . . . . . . . . 8 74 4.4. Carousel Transmission . . . . . . . . . . . . . . . . . . 9 75 4.5. Carousel Instance Object . . . . . . . . . . . . . . . . . 10 76 4.6. Compound Object Identification . . . . . . . . . . . . . . 11 77 4.7. FCAST/ALC Additional Specificities . . . . . . . . . . . . 12 78 4.8. FCAST/NORM Additional Specificities . . . . . . . . . . . 13 79 4.9. FCAST Sender Behavior . . . . . . . . . . . . . . . . . . 14 80 4.10. FCAST Receiver Behavior . . . . . . . . . . . . . . . . . 15 81 5. FCAST Specifications . . . . . . . . . . . . . . . . . . . . . 15 82 5.1. Compound Object Header Format . . . . . . . . . . . . . . 15 83 5.2. Carousel Instance Object Format . . . . . . . . . . . . . 18 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 85 6.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 21 86 6.2. Attacks Against the Data Flow . . . . . . . . . . . . . . 21 87 6.2.1. Access to Confidential Objects . . . . . . . . . . . . 21 88 6.2.2. Object Corruption . . . . . . . . . . . . . . . . . . 22 89 6.3. Attacks Against the Session Control Parameters and 90 Associated Building Blocks . . . . . . . . . . . . . . . . 23 91 6.3.1. Attacks Against the Session Description . . . . . . . 24 92 6.3.2. Attacks Against the FCAST CIO . . . . . . . . . . . . 24 93 6.3.3. Attacks Against the Object Meta-Data . . . . . . . . . 24 94 6.3.4. Attacks Against the ALC/LCT and NORM Parameters . . . 25 95 6.3.5. Attacks Against the Associated Building Blocks . . . . 25 96 6.4. Other Security Considerations . . . . . . . . . . . . . . 26 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 98 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 100 9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 101 9.2. Informative References . . . . . . . . . . . . . . . . . . 27 102 Appendix A. FCAST Examples . . . . . . . . . . . . . . . . . . . 28 103 A.1. Basic Examples . . . . . . . . . . . . . . . . . . . . . . 28 104 A.2. FCAST/NORM with NORM_INFO Examples . . . . . . . . . . . . 30 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 107 1. Introduction 109 This document introduces the FCAST reliable and scalable object 110 (e.g., file) delivery application. Two versions of FCAST exist: 112 o FCAST/ALC that relies on the Asynchronous Layer Coding (ALC) 113 [RMT-PI-ALC] and the Layered Coding Transport (LCT) [RMT-BB-LCT] 114 reliable multicast transport protocol, and 116 o FCAST/NORM that relies on the NACK-Oriented Reliable Multicast 117 (NORM) [RMT-PI-NORM] reliable multicast transport protocol. 119 Hereafter, the term FCAST denotes either FCAST/ALC or FCAST/NORM. 121 Depending on the target use case, the delivery service provided by 122 FCAST is more or less reliable. For instance, with FCAST/ALC used in 123 ON-DEMAND mode over a time period that largely exceeds the typical 124 download time, the service can be considered as fully reliable. 125 Similarly, when FCAST is used along with a session control 126 application that collects reception information and takes appropriate 127 corrective measures (e.g., a direct point-to-point retransmission of 128 missing packets, or a new multicast recovery session), then the 129 service can be considered as fully reliable. On the opposite, if 130 FCAST operates in PUSH mode, then the service is usually only 131 partially reliable, and a receiver that is disconnected during a 132 sufficient time will perhaps not have the possibility to download the 133 object. 135 Depending on the target use case, the FCAST scalability is more or 136 less important. For instance, if FCAST/ALC is used on top of purely 137 unidirectional transport channels, with no feedback information at 138 all, which is the default mode of operation, then the scalability is 139 maximum since neither FCAST, nor ALC, UDP or IP generates any 140 feedback message. On the opposite, the FCAST/NORM scalability is 141 typically limited by NORM scalability itself. Similarly, if FCAST is 142 used along with a session control application that collects reception 143 information from the receivers, then this session control application 144 may limit the scalability of the global object delivery system. This 145 situation can of course be mitigated by using a hierarchy of feedback 146 message aggregators or servers. The details of this are out of the 147 scope of the present document. 149 A design goal behind FCAST is to define a streamlined solution, in 150 order to enable lightweight implementations of the protocol stack, 151 and limit the operational processing and storage requirements. A 152 consequence of this choice is that FCAST cannot be considered as a 153 versatile application, capable of addressing all the possible use- 154 cases. On the opposite, FCAST has some intrinsic limitations. From 155 this point of view it differs from FLUTE [RMT-FLUTE] which favors 156 flexibility at the expense of some additional complexity. 158 A good example of the design choices meant to favor the simplicity is 159 the way FCAST manages the object meta-data: by default, the meta-data 160 and the object content are sent together, in a compound object. This 161 solution has many advantages in terms of simplicity as will be 162 described later on. However, as such, it also has an intrinsic 163 limitation since it does not enable a receiver to decide in advance, 164 before beginning the reception of the compound object, whether the 165 object is of interest or not, based on the information that may be 166 provided in the meta-data. Therefore this document defines 167 additional techniques that may be used to mitigate this limitation. 168 It is also possible that some use-cases require that each receiver 169 download the whole set of objects sent in the session (e.g., with 170 mirroring tools). When this is the case, the above limitation is no 171 longer be a problem. 173 1.1. Applicability 175 FCAST is compatible with any congestion control protocol designed for 176 ALC/LCT or NORM. However, depending on the use-case, the data flow 177 generated by the FCAST application might not be constant, but instead 178 be bursty in nature. Similarly, depending on the use-case, an FCAST 179 session might be very short. Whether and how this will impact the 180 congestion control protocol is out of the scope of the present 181 document. 183 FCAST is compatible with any security mechanism designed for ALC/LCT 184 or NORM. The use of a security scheme is strongly RECOMMENDED (see 185 Section 6). 187 FCAST is compatible with any FEC scheme designed for ALC/LCT or NORM. 188 Whether FEC is used or not, and the kind of FEC scheme used, is to 189 some extent transparent to FCAST. 191 FCAST is compatible with both IPv4 and IPv6. Nothing in the FCAST 192 specification has any implication on the source or destination IP 193 address. 195 2. Requirements notation 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in [RFC2119]. 201 3. Definitions, Notations and Abbreviations 203 3.1. Definitions 205 This document uses the following definitions: 207 FCAST/ALC: denotes the FCAST application running on top of the ALC/ 208 LCT reliable transport protocol; 210 FCAST/NORM: denotes the FCAST application running on top of the NORM 211 reliable transport protocol; 213 FCAST: denotes either FCAST/ALC or FCAST/NORM; 215 Compound Object: denotes an ALC or NORM transport object composed of 216 the Compound Object Header (Section 5.1), including any meta- 217 data, and the content of the original application object 218 (e.g., a file); 220 Carousel: denotes the Compound Object transmission system of an 221 FCAST sender; 223 Carousel Instance: denotes a fixed set of registered Compound 224 Objects that are sent by the carousel during a certain number 225 of cycles. Whenever Compound Objects need to be added or 226 removed, a new Carousel Instance is defined; 228 Carousel Instance Object (CIO): denotes a specific object that lists 229 the Compound Objects that comprise a given Carousel Instance; 231 Carousel Cycle: denotes a transmission round within which all the 232 Compound Objects registered in the Carousel Instance are 233 transmitted a certain number of times. By default, Compound 234 Objects are transmitted once per cycle, but higher values are 235 possible, that might differ on a per-object basis; 237 Transmission Object Identifier (TOI): denotes the numeric identifier 238 associated to a specific object by the underlying transport 239 layer. In the case of ALC, this corresponds to the TOI 240 described in that specification while for the NORM 241 specification this corresponds to the NormTransportId 242 described there. 244 3.2. Abbreviations 246 This document uses the following abbreviations: 248 CIO: Carousel Instance Object 250 CIID: Carousel Instance IDentifier 252 FEC OTI: FEC Object Transmission Information 254 TOI: Transmission Object Identifier 256 4. FCAST Principles 258 4.1. FCAST Content Delivery Service 260 The basic goal of FCAST is to transmit objects to a group of 261 receivers in a reliable way. The receiver set MAY be restricted to a 262 single receiver or MAY include possibly a very large number of 263 receivers. FCAST is specified to support two forms of operation: 265 1. FCAST/ALC: where the FCAST application is meant to run on top of 266 the ALC/LCT reliable multicast transport protocol, and 268 2. FCAST/NORM: where the FCAST application is meant to run on top of 269 the NORM reliable multicast transport protocol. 271 This specification is designed such that both forms of operation 272 share as much commonality as possible. 274 While the choice of the underlying transport protocol (i.e., ALC or 275 NORM) and its parameters may limit the practical receiver group size, 276 nothing in FCAST itself limits it. The transmission might be fully 277 reliable, or only partially reliable depending upon the way ALC or 278 NORM is used (e.g., whether FEC encoding and/or NACK-based repair 279 requests are used or not), the way the FCAST carousel is used (e.g., 280 whether the objects are made available for a long time span or not), 281 and the way in which FCAST itself is employed (e.g., whether there is 282 a session control application that might automatically extend an 283 existing FCAST session until all receivers have received the 284 transmitted content). 286 FCAST is designed to be as self-sufficient as possible, in particular 287 in the way object meta-data is attached to object data content. 288 However, for some uses, meta-data MAY also be communicated by an out- 289 of-band mechanism that is out of the scope of the present document. 291 4.2. Meta-Data Transmission 293 FCAST usually carries meta-data elements by prepending them to the 294 object it refers to. As a result, a Compound Object is created that 295 is composed of a header followed by the original object data. This 296 header is itself composed of the meta-data as well as several fields, 297 for instance to indicate the boundaries between the various parts of 298 this Compound Object (Figure 1). 300 <------------------------ Compound Object -----------------------> 301 +-------------------------+--------------------------------------+ 302 | Compound Object Header | Object Data | 303 | (can include meta-data) | (can be encoded by FCAST) | 304 +-------------------------+--------------------------------------+ 306 Figure 1: Compound Object composition. 308 Attaching the meta-data to the object is an efficient solution, since 309 it guaranties that meta-data be received along with the associated 310 object, and it allows the transport of the meta-data to benefit from 311 any transport-layer erasure protection of the Compound Object (e.g., 312 using FEC encoding and/or NACK-based repair). However a limit of 313 this scheme, as such, is that a client does not know the meta-data of 314 an object before beginning its reception, and in case of erasures 315 affecting the meta-data, not until the object decoding is completed. 316 The details of course depend upon the transport protocol and the FEC 317 code used. 319 In certain use-cases, FCAST can also be associated to another in-band 320 (e.g., via NORM INFO messages, Section 4.8) or out-of-band signaling 321 mechanism. In that case, this mechanism can be used in order to 322 carry the whole meta-data (or a subset of it), possibly ahead of 323 time. 325 4.3. Meta-Data Content 327 The meta-data associated to an object can be composed of, but are not 328 limited to: 330 o Content-Location: the URI of the object, which gives the name and 331 location of the object; 333 o Content-Type: the MIME type of the object; 335 o Content-Length: the size of the initial object, before any content 336 encoding (if any). Note that this content length does not include 337 the meta-data nor the fixed size Compound Object header; 339 o Content-Encoding: the optional encoding of the object performed by 340 FCAST. If there is no Content-Encoding entry, the receiver MUST 341 assume that the object is not encoded (default). The support of 342 gzip encoding, or any other solution, remains optional. 344 o Content-MD5: the MD5 message digest of the object in order to 345 check its integrity. Note that this digest is meant to protect 346 from transmission and processing errors, not from deliberate 347 attacks by an intelligent attacker. Note also that this digest 348 only protects the object, not the header, and therefore not the 349 meta-data. A separate checksum is provided to that purpose 350 (Section 5.1); 352 o a digital signature for this object; 354 This list is not limited and new meta-data information can be added. 355 For instance, when dealing with very large objects (e.g., that 356 largely exceed the working memory of a receiver), it can be 357 interesting to split this object into several sub-objects (or 358 slices). When this happens, the meta-data associated to each sub- 359 object MUST include the following entries: 361 o Fcast-Obj-Slice-Nb: the total number of slices. A value strictly 362 greater than 1 indicates that this object is the result of a split 363 of the original object; 365 o Fcast-Obj-Slice-Idx: the slice index (in the {0 .. SliceNb - 1} 366 interval); 368 o Fcast-Obj-Slice-Offset: the offset at which this slice starts 369 within the original object; 371 When meta-data elements are communicated out-of-band, in advance of 372 data transmission, the following pieces of information MAY also be 373 useful: 375 o TOI: the Transmission Object Identifier (TOI) of the object 376 (Section 4.6), in order to enable a receiver to easily associate 377 the meta-data to the object; 379 o FEC Object Transmission Information (FEC OTI). In this case the 380 FCAST sender does not need to use the optional EXT_FTI mechanism 381 of the ALC or NORM protocols. 383 4.4. Carousel Transmission 385 A set of FCAST Compound Objects scheduled for transmission are 386 considered a logical "Carousel". A given "Carousel Instance" is 387 comprised of a fixed set of Compound Objects. Whenever the FCAST 388 application needs to add new Compound Objects to, or remove old 389 Compound Objects from the transmission set, a new Carousel Instance 390 is defined since the set of Compound Objects changes. 392 For a given Carousel Instance, one or more transmission cycles are 393 possible. During each cycle, all of the Compound Objects comprising 394 the Carousel are sent. By default, each object is transmitted once 395 per cycle. However, in order to allow different levels of priority, 396 some objects MAY be transmitted more often that others during a 397 cycle, and/or benefit from higher FEC protection than others. This 398 can be the case for instance of the CIO objects (Section 4.5). For 399 some FCAST usage (e.g., a unidirectional "push" mode), a Carousel 400 Instance may be associated to a single transmission cycle. In other 401 cases it may be associated to a large number of transmission cycles 402 (e.g., in "on-demand" mode, where objects are made available for 403 download during a long period of time). 405 4.5. Carousel Instance Object 407 The FCAST sender CAN transmit an OPTIONAL Carousel Instance Object 408 (CIO). The CIO carries the list of the Compound Objects that are 409 part of a given Carousel Instance, by specifying their respective 410 Transmission Object Identifiers (TOI). However the CIO does not 411 describe the objects themselves (i.e., there is no meta-data). 412 Additionally, the CIO MAY include a "Complete" flag that is used to 413 indicate that no further modification to the enclosed list will be 414 done in the future. Finally, the CIO MAY include a Carousel Instance 415 ID that identifies the Carousel Instance it pertains to. These 416 aspects are discussed in Section 5.2. 418 There is no reserved TOI value for the CIO itself, since this object 419 is regarded by ALC/LCT or NORM as a standard object. On the 420 opposite, the nature of this object (CIO) is indicated by means of a 421 specific Compound Object header field (the "I" flag) so that it can 422 be recognized and processed by the FCAST application as needed. A 423 direct consequence is the following: since a receiver does not know 424 in advance which TOI will be used for the following CIO (in case of a 425 dynamic session), he MUST NOT filter out packets that are not in the 426 current CIO's TOI list. Said differently, the goal of CIO is not to 427 setup ALC or NORM packet filters (this mechanism would not be secure 428 in any case). 430 The use of a CIO remains optional. If it is not used, then the 431 clients progressively learn what files are part of the carousel 432 instance by receiving ALC or NORM packets with new TOIs. However 433 using a CIO has several benefits: 435 o When the "Complete" flag is set (if ever), the receivers know when 436 they can leave the session, i.e., when they have received all the 437 objects that are part of the last carousel instance of this 438 delivery session; 440 o In case of a session with a dynamic set of objects, the sender can 441 reliably inform the receivers that some objects have been removed 442 from the carousel with the CIO. This solution is more robust than 443 the "Close Object flag (B)" of ALC/LCT since a client with an 444 intermittent connectivity might loose all the packets containing 445 this B flag. And while NORM provides a robust object cancellation 446 mechanism in the form of its NORM_CMD(SQUELCH) message in response 447 to receiver NACK repair requests, the use of the CIO provides an 448 additional means for receivers to learn of objects for which it is 449 futile to request repair; 451 o The TOI equivalence (Section 4.6) can be signaled with the CIO. 452 This is often preferable to the alternative solution where the 453 equivalence is identified by examining the object meta-data, 454 especially in case of erasures. 456 During idle periods, when the carousel instance does not contain any 457 object, a CIO with an empty TOI list MAY be transmitted. In that 458 case, a new carousel instance ID MUST be used to differentiate this 459 (empty) carousel instance from the other ones. This mechanism can be 460 useful to inform the receivers that: 462 o all the previously sent objects have been removed from the 463 carousel. It therefore improves the FCAST robustness even during 464 "idle" period; 466 o the session is still active even if there is currently no content 467 being sent. Said differently, it can be used as a heartbeat 468 mechanism. If the "Complete" flag has not been set, it implicitly 469 informs the receivers that new objects MAY be sent in the future; 471 The decisions of whether a CIO should be used or not, how often and 472 when a CIO should be sent, are left to the sender and depend on many 473 parameters, including the target use case and the session dynamics. 474 For instance it may be appropriate to send a CIO at the beginning of 475 each new carousel instance, and then periodically. These operational 476 aspects are out of the scope of the present document. 478 4.6. Compound Object Identification 480 The FCAST Compound Objects are directly associated with the object- 481 based transport service that the ALC and NORM protocols provide. In 482 each of these protocols, the messages containing transport object 483 content are labeled with a numeric transport object identifier (i.e., 484 the ALC TOI and the NORM NormTransportId). For the purposes of this 485 document, this identifier in either case (ALC or NORM) is referred to 486 as the TOI. 488 There are several differences between ALC and NORM: 490 o the ALC use of TOI is rather flexible, since several TOI field 491 sizes are possible (from 16 to 112 bits), since this size can be 492 changed at any time, on a per-packet basis, and since the TOI 493 management is totally free as long as each object is associated to 494 a unique TOI (if no wraparound happened); 496 o the NORM use of TOI is more directive, since the TOI field is 16 497 bit long and since TOIs MUST be managed sequentially; 499 In both NORM and ALC, it is possible that the transport 500 identification space may eventually wrap for long-lived sessions 501 (especially with NORM where this phenomenon is expected to happen 502 more frequently). This can possibly introduce some ambiguity in 503 FCAST object identification if a sender retains some older objects in 504 newer Carousel Instances with updated object sets. Thus, when an 505 updated object set, for a new Carousel Instance, would transport 506 identifiers that exceed one-half of the TOI sequence space (or 507 otherwise exceed the sender repair window capability in the case of 508 NORM), it MAY be necessary to re-enqueue old objects within the 509 Carousel with new TOI to stay within transport identifier limits. In 510 case of NORM, this constraint limits to 32768 the maximum number of 511 objects that can be part of any carousel instance. In order to allow 512 receivers to properly combine the transport packets with a newly- 513 assigned TOI to those of associated to the previously-assigned TOI, a 514 mechanism is required to equate the objects with the new and the old 515 TOIs. 517 The preferred mechanism consists in signaling, within the CIO, that 518 the newly assigned TOI, for the current Carousel Instance, is 519 equivalent to the TOI used within a previous Carousel Instance. By 520 convention, the reference tuple for any object is the {TOI; CI ID} 521 tuple used for its first transmission within a Carousel Instance. 522 This tuple MUST be used whenever a TOI equivalence is provided. 524 An alternative solution, when meta-data can be processed rapidly 525 (e.g., by using NORM-INFO messages), consists for the receiver in 526 identifying that both objects are the same, after examining the meta- 527 data. The receiver can then take appropriate measures. 529 4.7. FCAST/ALC Additional Specificities 531 There are no additional detail or option for FCAST/ALC operation. 533 4.8. FCAST/NORM Additional Specificities 535 The NORM Protocol provides a few additional capabilities that can be 536 used to specifically support FCAST operation: 538 1. The NORM_INFO message can convey "out-of-band" content with 539 respect to a given transport object. With FCAST, it MAY be used 540 to provide to the receivers a new, associated, Compound Object 541 which contains the main Compound Object meta-data, or a subset of 542 it. In that case the NORM_INFO Compound Object MUST NOT contain 543 any Object Data field (i.e., it is only composed of the header), 544 it MUST feature a non global checksum, and it MUST NOT include 545 any padding field. The main Compound Object MUST in any case 546 contain the whole meta-data (e.g., because a receiver MAY not 547 support the NORM_INFO facility). Additionally, the meta-data 548 entries contained in the NORM_INFO MUST be identical to the same 549 entries in the main Compound Object. Finally, note that the 550 availability of NORM_INFO for a given object is signaled through 551 the use of a dedicated flag in the NORM_DATA message header. 552 Along with NORM's NACK-based repair request signaling, it allows 553 a receiver to quickly (and independently) request an object's 554 NORM_INFO content. However, a limitation here is that the 555 NORM_INFO Compound Object header MUST fit within the byte size 556 limit defined by the NORM sender's configured "segment size" 557 (typically a little less than the network MTU); 559 2. The NORM_CMD(SQUELCH) messages are used by the NORM protocol 560 sender to inform receivers of objects that have been canceled 561 when receivers make repair requests for such invalid objects. 562 Along with the CIO mechanism, a receiver has two efficient and 563 reliable ways to discover old objects that have been removed from 564 the carousel instance; 566 3. NORM also supports an optional positive acknowledgment mechanism 567 that can be used for small-scale multicast receiver group sizes. 568 Also, it may be possible in some cases for the sender to infer, 569 after some period without receiving NACKs at the end of its 570 transmission that the receiver set has fully received the 571 transmitted content. In particular, if the sender completes its 572 end-of-transmission series of NORM_CMD(FLUSH) messages without 573 receiving repair requests from the group, it may have some 574 assurance that the receiver set has received the content prior to 575 that point. These mechanisms are likely to help FCAST in 576 achieving fully reliable transmissions; 578 It should be noted that the NORM_INFO message header may carry the 579 EXT_FTI extension. The reliable delivery of the NORM_INFO content 580 allows the individual objects' FEC Transmission Information to be 581 provided to the receivers without burdening every packet (i.e. 582 NORM_DATA messages) with this additional, but important, content. 583 Examples are provided in Appendix A. 585 4.9. FCAST Sender Behavior 587 The following operations MAY take place at a sender: 589 1. The user (or another application) selects a set of objects (e.g., 590 files) to deliver and submits them, along with their meta-data, 591 to the FCAST application; 593 2. For each object, FCAST creates the Compound Object and registers 594 this latter in the carousel instance; 596 3. The user then informs FCAST that all the objects of the set have 597 been submitted. If the user knows that no new object will be 598 submitted in the future (i.e., if the session's content is now 599 complete), the user informs FCAST. Finally, the user specifies 600 how many transmission cycles are desired (this number may be 601 infinite); 603 4. At this point, the FCAST application knows the full list of 604 Compound Objects that are part of the Carousel Instance and can 605 create a CIO if desired, possibly with the complete flag set; 607 5. The FCAST application can now define a transmission schedule of 608 these Compound Objects, including the optional CIO. This 609 schedule defines in which order the packets of the various 610 Compound Objects should be sent. This document does not specify 611 any scheme. This is left to the developer within the provisions 612 of the underlying ALC or NORM protocol used and the knowledge of 613 the target use-case. 615 6. The FCAST application then starts the carousel transmission, for 616 the number of cycles specified. Transmissions take place until: 618 * the desired number of transmission cycles has been reached, or 620 * the user wants to prematurely stop the transmissions, or 622 * the user wants to add one or several new objects to the 623 carousel, or on the opposite wants to remove old objects from 624 the carousel. In that case a new carousel instance must be 625 created. 627 7. If the session is not finished, then continue as Set 1 above; 629 4.10. FCAST Receiver Behavior 631 The following operations MAY take place at a receiver: 633 1. The receiver joins the session and collects incoming packets; 635 2. If the header portion of a Compound Object is entirely received 636 (which may happen before receiving the entire object with some 637 ALC/NORM configurations), or if the meta-data is sent by means of 638 another mechanism prior to the object, the receiver processes the 639 meta-data and chooses to continue to receive the object content 640 or not; 642 3. When a Compound Object has been entirely received, the receiver 643 processes the header, retrieves the object meta-data, perhaps 644 decodes the meta-data, and processes the object accordingly; 646 4. When a CIO is received, which is indicated by the 'I' flag set in 647 the Compound Object header, the receiver decodes the CIO, and 648 retrieves the list of objects that are part of the current 649 carousel instance. This list CAN be used to remove objects sent 650 in a previous carousel instance that might not have been totally 651 decoded and that are no longer part of the current carousel 652 instance; 654 5. When a CIO is received, the receiver also retrieves the list of 655 TOI equivalences, if any, and takes appropriate measures, for 656 instance by informing the transport layer; 658 6. When a receiver has received a CIO with the "Complete" flag set, 659 and has successfully received all the objects of the current 660 carousel instance, it can safely exit from the current FCAST 661 session; 663 7. Otherwise continue at Step 2 above. 665 5. FCAST Specifications 667 This section details the technical aspects of FCAST. 669 5.1. Compound Object Header Format 671 In an FCAST session, Compound Objects are constructed by prepending 672 the Compound Object Header (which may include meta-data) before the 673 original object data content (Figure 2). 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 678 |rsv|G|C|MDF|MDE| Header Length | | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 680 | Checksum | | h 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d 682 | Object Meta-Data (optional, variable length) | r 683 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 684 | | Padding (optional) | | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 686 | | 687 . Object Data (optional, variable length) . 688 . . 689 . . 691 Figure 2: Compound Object Header with Meta-Data. 693 The Compound Object Header fields are: 695 +------------+------------------------------------------------------+ 696 | Field | Description | 697 +------------+------------------------------------------------------+ 698 | Reserved | 2-bit field set to 0 in this specification and | 699 | | reserved for future use. | 700 | G | 1-bit field that, when set to 1, indicates that the | 701 | | checksum encompasses the whole Compound Object | 702 | | (Global checksum). When set to 0, this field | 703 | | indicates that the checksum encompasses only the | 704 | | Compound Object header. | 705 | C | 1-bit field that, when set to 1, indicates the | 706 | | object is a Carousel Instance Object (CIO). When | 707 | | set to 0, this field indicates that the transported | 708 | | object is a standard object. | 709 | Meta-Data | 2-bit field that defines the format of the object | 710 | Format | meta-data (see Section 7). An HTTP/1.1 | 711 | (MDFmt) | metainformation format [RFC2068] MUST be supported | 712 | | and is associated to value 0. Other formats (e.g., | 713 | | XML) MAY be defined in the future. | 714 | Meta-Data | 2-bit field that defines the optional encoding of | 715 | Encoding | the Object Meta-Data field (see Section 7). By | 716 | (MDEnc) | default, a plain text encoding is used and is | 717 | | associated to value 0. Gzip encoding MUST also be | 718 | | supported and is associated to value 1. Other | 719 | | encodings MAY be defined in the future. | 720 | Header | 24-bit field indicating total length (in bytes) of | 721 | Length | all fields of the Compound Object Header, except the | 722 | | optional padding. A header length field set to | 723 | | value 6 means that there is no meta-data included. | 724 | | When this size is not multiple to 32-bits words and | 725 | | when the Compound Object Header is followed by a non | 726 | | null Compound Object Data, padding MUST be added. | 727 | | It should be noted that the meta-data field maximum | 728 | | size is equal to 2^24 - 6 bytes. | 729 | Checksum | 16-bit field that contains the checksum computed | 730 | | over either the whole Compound Object (when G is set | 731 | | to 1), or over the Compound Object header (when G is | 732 | | set to 0), using the algorithm specified for TCP in | 733 | | RFC793. More precisely, the checksum field is the | 734 | | 16-bit one's complement of the one's complement sum | 735 | | of all 16-bit words to be considered. If a segment | 736 | | contains an odd number of octets to be checksummed, | 737 | | the last octet is padded on the right with zeros to | 738 | | form a 16-bit word for checksum purposes (this pad | 739 | | is not transmitted). While computing the checksum, | 740 | | the checksum field itself is set to zero. | 741 | Object | Optional, variable length field that contains the | 742 | Meta-Data | meta-data associated to the object, either in plain | 743 | | text or encoded, as specified by the MDEnc field. | 744 | | The Meta-Data is NULL-terminated plain text that | 745 | | follows the "TYPE" ":" "VALUE" "" format used | 746 | | in HTTP/1.1 for metainformation [RFC2068]. The | 747 | | various meta-data items can appear in any order. | 748 | | The associated string, when non empty, MUST be | 749 | | NULL-terminated. When no meta-data is communicated, | 750 | | this field MUST be empty and the Header Length MUST | 751 | | be equal to 6. | 752 | Padding | Optional, variable length field of zero-value bytes | 753 | | to align the start of the Object Data to 32-bit | 754 | | boundary. Padding is only used when the header | 755 | | length value, in bytes, is not multiple of 4 and | 756 | | when the Compound Object Header is followed by a non | 757 | | null Compound Object Data. | 758 +------------+------------------------------------------------------+ 760 The Compound Object Header is then followed by the Object Data, i.e., 761 the original object possibly encoded by FCAST. Note that the length 762 of this content is the transported object length (e.g., as specified 763 by the FEC OTI) minus the Header Length and optional padding if any. 765 5.2. Carousel Instance Object Format 767 The format of the CIO, which is a particular Compound Object, is 768 given in Figure 3. 770 0 1 2 3 771 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 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 773 |rsv|G|1|MDF|MDE| Header Length | | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 775 | Checksum | | h 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d 777 | Object Meta-Data (optional, variable length) | r 778 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 779 | | Padding (optional) | | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 781 . . ^ 782 . Object List (variable length) . | 783 . . o 784 . +-+-+-+-+-+-+-+-+ b 785 . | j 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 788 Figure 3: Carousel Instance Object Format. 790 Because the CIO is transmitted as a special Compound Object, the 791 following CIO-specific meta-data entries are defined: 793 o Fcast-CIO-Complete: when set to 1, it indicates that no new 794 objects in addition to the ones whose TOI are specified in this 795 CIO, or the ones that have been specified in the previous CIO(s), 796 will be sent in the future. Otherwise it MUST be set to 0. This 797 entry is optional. If absent, a receiver MUST conclude that the 798 session is complete. 800 o Fcast-CIO-ID: this value identifies the carousel instance. It 801 starts from 0 and is incremented by 1 for each new carousel 802 instance. This entry is optional if the FCAST session consists of 803 a single, complete, carousel instance. In all other cases, this 804 entry MUST be defined. In particular, the CIID is used by the TOI 805 equivalence mechanism thanks to which any object is uniquely 806 identified, even if the TOI is updated (e.g., after re-enqueuing 807 the object with NORM). The Fcast-CIO-ID value can also be useful 808 to detect possible gaps in the Carousel Instances, for instance 809 caused by long disconnection periods. Finally, it can also be 810 useful to avoid problems when TOI wrapping to 0 takes place to 811 differentiate the various incarnations of the TOIs if need be. 813 The motivation for making the Fcast-CIO-Complete and Fcast-CIO- 814 Complete entries optional is to simplify the simple case of a session 815 consisting of a single, complete, carousel instance. Indeed, the CIO 816 does not need to contain any meta-data entry then. 818 Additionally, the following standard meta-data entries are often used 819 (Section 4.3): 821 o Content-Length: it specifies the size of the object list, before 822 any content encoding (if any). 824 o Content-Encoding: it specifies the optional encoding of the object 825 list, performed by FCAST. For instance: 826 Content-Encoding: gzip 827 indicates that the Object List field has been encoded with gzip 828 [RFC1952]. If there is no Content-Encoding entry, the receiver 829 MUST assume that the Object List field is plain text (default). 830 The support of gzip encoding, or any other solution, remains 831 optional. 833 An empty Object List is valid and indicates that the current carousel 834 instance does not include any object (Section 4.5). This can be 835 specified by using the following meta-data entry: 836 Content-Length: 0 837 or simply by leaving the Object List empty. In both cases, padding 838 MUST NOT be used and consequently the transported object length 839 (e.g., as specified by the FEC OTI) minus the Header Length equals 840 zero. 842 The non-encoded (i.e., plain text) Object List, when non empty, is a 843 NULL-terminated ASCII string. It can contain two things: 845 o a list of TOI values, and 847 o a list of TOI equivalences; 849 First of all, this string can contain the list of TOIs included in 850 the current carousel instance, specified either as the individual 851 TOIs of each object, or as TOI intervals, or any combination. The 852 format of the ASCII string is a comma-separated list of individual 853 "TOI" values or "TOI_a-TOI_b" elements. This latter case means that 854 all values between TOI_a and TOI_b, inclusive, are part of the list. 855 In that case TOI_a MUST be strictly inferior to TOI_b. If a TOI 856 wrapping to 0 occurs in an interval, then two TOI intervals MUST be 857 specified, TOI_a-MAX_TOI and 0-TOI_b. 859 This string can also contain the TOI equivalences, if any. The 860 format is a comma-separated list of "(" newTOI "=" 1stTOI "/" 1stCIID 861 ")" elements. Each element says that the new TOI, for the current 862 Carousel Instance, is equivalent to (i.e., refers to the same object 863 as) the provided identifier, 1stTOI, for the Carousel Instance of ID 864 1stCIID. 866 The ABNF specification is the following: 867 cio-list = *(list-elem *( "," list-elem)) 868 list-elem = toi-elem / toieq-elem 869 toi-elem = toi-value / toi-interval 870 toi-value = 1*DIGIT 871 toi-interval = toi-value "-" toi-value 872 ; additionally, the first toi-value MUST be 873 ; strictly inferior to the second toi-value 874 toieq-elem = "(" toi-value "=" toi-value "/" ciid-value ")" 875 ciid-value = 1*DIGIT 876 DIGIT = %x30-39 877 ; a digit between O and 9, inclusive 879 For readability purposes, it is RECOMMENDED that all the TOI values 880 in the list be given in increasing order. However a receiver MUST be 881 able to handle non-monotonically increasing values. It is also 882 RECOMMENDED to group the TOI equivalence elements together, at the 883 end of the list, in increasing newTOI order. However a receiver MUST 884 be able to handle lists of mixed TOI and TOI equivalence elements. 885 Specifying a TOI equivalence for a given newTOI relieves the sender 886 from specifying newTOI explicitly in the TOI list. However a 887 receiver MUST be able to handle situations where the same TOI appears 888 both in the TOI value and TOI equivalence lists. Finally, a given 889 TOI value or TOI equivalence item MUST NOT be included multiple times 890 in either list. 892 For instance, the following object list specifies that the current 893 Carousel Instance is composed of 8 objects, and that TOIs 100 to 104 894 are equivalent to the TOIs 10 to 14 of Carousel Instance ID 2 and 895 refer to the same objects: 897 97,98,99,(100=10/2),(101=11/2),(102=12/2),(103=13/2),(104=14/2) 899 or equivalently: 901 97-104,(100=10/2),(101=11/2),(102=12/2),(103=13/2),(104=14/2) 903 6. Security Considerations 904 6.1. Problem Statement 906 A content delivery system is potentially subject to attacks. Attacks 907 may target: 909 o the network (to compromise the routing infrastructure, e.g., by 910 creating congestion), 912 o the Content Delivery Protocol (CDP) (e.g., to compromise the 913 normal behavior of FCAST) or 915 o the content itself (e.g., to corrupt the objects being 916 transmitted). 918 These attacks can be launched either: 920 o against the data flow itself (e.g., by sending forged packets), 922 o against the session control parameters (e.g., by corrupting the 923 session description, the CIO, the object meta-data, or the ALC/LCT 924 control parameters), that are sent either in-band or out-of-band, 925 or 927 o against some associated building blocks (e.g., the congestion 928 control component). 930 In the following sections we provide more details on these possible 931 attacks and sketch some possible counter-measures. 933 6.2. Attacks Against the Data Flow 935 Let us consider attacks against the data flow first. At least, the 936 following types of attacks exist: 938 o attacks that are meant to give access to a confidential object 939 (e.g., in case of a non-free content) and 941 o attacks that try to corrupt the object being transmitted (e.g., to 942 inject malicious code within an object, or to prevent a receiver 943 from using an object, which is a kind of Denial of Service (DoS)). 945 6.2.1. Access to Confidential Objects 947 Access control to the object being transmitted is typically provided 948 by means of encryption. This encryption can be done over the whole 949 object (e.g., by the content provider, before submitting the object 950 to FCAST), or be done on a packet per packet basis (e.g., when IPSec/ 951 ESP is used [RFC4303]). If confidentiality is a concern, it is 952 RECOMMENDED that one of these solutions be used. 954 6.2.2. Object Corruption 956 Protection against corruptions (e.g., in case of forged packets) is 957 achieved by means of a content integrity verification/sender 958 authentication scheme. This service can be provided at the object 959 level, but in that case a receiver has no way to identify which 960 symbol(s) is(are) corrupted if the object is detected as corrupted. 961 This service can also be provided at the packet level. In this case, 962 after removing all corrupted packets, the file may be in some cases 963 recovered. Several techniques can provide this content integrity/ 964 sender authentication service: 966 o at the object level, the object can be digitally signed (with 967 public key cryptography), for instance by using RSASSA-PKCS1-v1_5 968 [RFC3447]. This signature enables a receiver to check the object 969 integrity, once this latter has been fully decoded. Even if 970 digital signatures are computationally expensive, this calculation 971 occurs only once per object, which is usually acceptable; 973 o at the packet level, each packet can be digitally signed. A major 974 limitation is the high computational and transmission overheads 975 that this solution requires (unless perhaps if Elliptic Curve 976 Cryptography (ECC) is used). To avoid this problem, the signature 977 may span a set of packets (instead of a single one) in order to 978 amortize the signature calculation. But if a single packets is 979 missing, the integrity of the whole set cannot be checked; 981 o at the packet level, a Group Message Authentication Code (MAC) 982 [RFC2104] scheme can be used, for instance by using HMAC-SHA-1 983 with a secret key shared by all the group members, senders and 984 receivers. This technique creates a cryptographically secured 985 digest of a packet that is sent along with the packet. The Group 986 MAC scheme does not create prohibitive processing load nor 987 transmission overhead, but it has a major limitation: it only 988 provides a group authentication/integrity service since all group 989 members share the same secret group key, which means that each 990 member can send a forged packet. It is therefore restricted to 991 situations where group members are fully trusted (or in 992 association with another technique as a pre-check); 994 o at the packet level, Timed Efficient Stream Loss-Tolerant 995 Authentication (TESLA) [RFC4082] is an attractive solution that is 996 robust to losses, provides a true authentication/integrity 997 service, and does not create any prohibitive processing load or 998 transmission overhead. Yet checking a packet requires a small 999 delay (a second or more) after its reception; 1001 o at the packet level, IPSec/AH [RFC4302] (possibly associated to 1002 IPSec/ ESP) can be used to protect all the packets being exchanged 1003 in a session. 1005 Techniques relying on public key cryptography (digital signatures and 1006 TESLA during the bootstrap process, when used) require that public 1007 keys be securely associated to the entities. This can be achieved by 1008 a Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by 1009 pre-distributing securely the public keys of each group member. 1011 Techniques relying on symmetric key cryptography (Group MAC) require 1012 that a secret key be shared by all group members. This can be 1013 achieved by means of a group key management protocol, or simply by 1014 pre-distributing securely the secret key (but this manual solution 1015 has many limitations). 1017 It is up to the developer and deployer, who know the security 1018 requirements and features of the target application area, to define 1019 which solution is the most appropriate. In any case, whenever there 1020 is any concern of the threat of file corruption, it is RECOMMENDED 1021 that at least one of these techniques be used. 1023 6.3. Attacks Against the Session Control Parameters and Associated 1024 Building Blocks 1026 Let us now consider attacks against the session control parameters 1027 and the associated building blocks. The attacker has at least the 1028 following opportunities to launch an attack: 1030 o the attack can target the session description, 1032 o the attack can target the FCAST CIO, 1034 o the attack can target the meta-data of an object, 1036 o the attack can target the ALC/LCT parameters, carried within the 1037 LCT header or 1039 o the attack can target the FCAST associated building blocks. 1041 The latter one is particularly true with the multiple rate congestion 1042 control protocol which may be required. 1044 The consequences of these attacks are potentially serious, since they 1045 can compromise the behavior of content delivery system or even 1046 compromise the network itself. 1048 6.3.1. Attacks Against the Session Description 1050 An FCAST receiver may potentially obtain an incorrect Session 1051 Description for the session. The consequence of this is that 1052 legitimate receivers with the wrong Session Description are unable to 1053 correctly receive the session content, or that receivers 1054 inadvertently try to receive at a much higher rate than they are 1055 capable of, thereby possibly disrupting other traffic in the network. 1057 To avoid these problems, it is RECOMMENDED that measures be taken to 1058 prevent receivers from accepting incorrect Session Descriptions. One 1059 such measure is the sender authentication to ensure that receivers 1060 only accept legitimate Session Descriptions from authorized senders. 1061 How these measures are archived is outside the scope of this document 1062 since this session description is usually carried out-of-band. 1064 6.3.2. Attacks Against the FCAST CIO 1066 Corrupting the FCAST CIO is one way to create a Denial of Service 1067 attack. For example, the attacker can set the "Complete" flag to 1068 make the receivers believe that no further modification will be done. 1070 It is therefore RECOMMENDED that measures be taken to guarantee the 1071 integrity and to check the sender's identity of the CIO. To that 1072 purpose, one of the counter-measures mentioned above (Section 6.2.2) 1073 SHOULD be used. These measures will either be applied on a packet 1074 level, or globally over the whole CIO object. When there is no 1075 packet level integrity verification scheme, it is RECOMMENDED to 1076 digitally sign the CIO. 1078 6.3.3. Attacks Against the Object Meta-Data 1080 Corrupting the object meta-data is another way to create a Denial of 1081 Service attack. For example, the attacker changes the MD5 sum 1082 associated to a file. This possibly leads a receiver to reject the 1083 files received, no matter whether the files have been correctly 1084 received or not. When the meta-data are appended to the object, 1085 corrupting the meta-data means that the Compound Object will be 1086 corrupted. 1088 It is therefore RECOMMENDED that measures be taken to guarantee the 1089 integrity and to check the sender's identity of the Compound Object. 1090 To that purpose, one of the counter-measures mentioned above 1091 (Section 6.2.2) SHOULD be used. These measures will either be 1092 applied on a packet level, or globally over the whole Compound 1093 Object. When there is no packet level integrity verification scheme, 1094 it is RECOMMENDED to digitally sign the Compound Object. 1096 6.3.4. Attacks Against the ALC/LCT and NORM Parameters 1098 By corrupting the ALC/LCT header (or header extensions) one can 1099 execute attacks on the underlying ALC/LCT implementation. For 1100 example, sending forged ALC packets with the Close Session flag (A) 1101 set one can lead the receiver to prematurely close the session. 1102 Similarly, sending forged ALC packets with the Close Object flag (B) 1103 set one can lead the receiver to prematurely give up the reception of 1104 an object. The same comments can be made for NORM. 1106 It is therefore RECOMMENDED that measures be taken to guarantee the 1107 integrity and to check the sender's identity of each ALC or NORM 1108 packet received. To that purpose, one of the counter-measures 1109 mentioned above (Section 6.2.2) SHOULD be used. 1111 6.3.5. Attacks Against the Associated Building Blocks 1113 Let us first focus on the congestion control building block that may 1114 be used in an ALC or NORM session. A receiver with an incorrect or 1115 corrupted implementation of the multiple rate congestion control 1116 building block may affect the health of the network in the path 1117 between the sender and the receiver. That may also affect the 1118 reception rates of other receivers who joined the session. 1120 When congestion control is applied with FCAST, it is therefore 1121 RECOMMENDED that receivers be required to identify themselves as 1122 legitimate before they receive the Session Description needed to join 1123 the session. If authenticating a receiver does not prevent this 1124 latter to launch an attack, it will enable the network operator to 1125 identify him and to take counter-measures. This authentication can 1126 be made either toward the network operator or the session sender (or 1127 a representative of the sender) in case of NORM. The details of how 1128 it is done are outside the scope of this document. 1130 When congestion control is applied with FCAST, it is also RECOMMENDED 1131 that a packet level authentication scheme be used, as explained in 1132 Section 6.2.2. Some of them, like TESLA, only provide a delayed 1133 authentication service, whereas congestion control requires a rapid 1134 reaction. It is therefore RECOMMENDED [RMT-PI-ALC] that a receiver 1135 using TESLA quickly reduces its subscription level when the receiver 1136 believes that a congestion did occur, even if the packet has not yet 1137 been authenticated. Therefore TESLA will not prevent DoS attacks 1138 where an attacker makes the receiver believe that a congestion 1139 occurred. This is an issue for the receiver, but this will not 1140 compromise the network since no congestion actually occurred. Other 1141 authentication methods that do not feature this delayed 1142 authentication could be preferred, or a group MAC scheme could be 1143 used in parallel to TESLA to reduce the probability of this attack. 1145 6.4. Other Security Considerations 1147 Lastly, we note that the security considerations that apply to, and 1148 are described in, ALC [RMT-PI-ALC], LCT [RMT-BB-LCT], NORM 1149 [RMT-PI-NORM] and FEC [RFC5052] also apply to FCAST as FCAST builds 1150 on those specifications. In addition, any security considerations 1151 that apply to any congestion control building block used in 1152 conjunction with FCAST also applies to FCAST. Finally, the security 1153 discussion of [RMT-SEC] also applies here. 1155 7. IANA Considerations 1157 This document requires a IANA registration for the following 1158 attributes: 1160 Object meta-data format (MDFmt): All implementations MUST support 1161 format 0 (default). 1163 +----------------------------------------+-------------+ 1164 | format name | Value | 1165 +----------------------------------------+-------------+ 1166 | as per HTTP/1.1 metainformation format | 0 (default) | 1167 +----------------------------------------+-------------+ 1169 Object Meta-Data Encoding (MDENC): All implementations MUST support 1170 value 0 (plain-text, default) and value 1 (gzip). 1172 +------------+-------------+ 1173 | Name | Value | 1174 +------------+-------------+ 1175 | plain text | 0 (default) | 1176 | gzip | 1 | 1177 +------------+-------------+ 1179 8. Acknowledgments 1181 The authors are grateful to the authors of [ALC-00] for specifying 1182 the first version of FCAST/ALC. The authors are also grateful to 1183 Gorry Fairhurst for his valuable comments. 1185 9. References 1186 9.1. Normative References 1188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1189 Requirement Levels", BCP 14, RFC 2119, March 1997. 1191 [RMT-PI-ALC] 1192 Luby, M., Watson, M., and L. Vicisano, "Asynchronous 1193 Layered Coding (ALC) Protocol Instantiation", Work 1194 in Progress, November 2008. 1196 [RMT-BB-LCT] 1197 Luby, M., Watson, M., and L. Vicisano, "Layered Coding 1198 Transport (LCT) Building Block", Work in Progress, 1199 March 2009. 1201 [RMT-PI-NORM] 1202 Adamson, B., Bormann, C., Handley, M., and J. Macker, 1203 "Negative-acknowledgment (NACK)-Oriented Reliable 1204 Multicast (NORM) Protocol", Work in Progress, June 2009. 1206 9.2. Informative References 1208 [ALC-00] Luby, M., Gemmell, G., Vicisano, L., Crowcroft, J., and B. 1209 Lueckenhoff, "Asynchronous Layered Coding: a Scalable 1210 Reliable Multicast Protocol", March 2000. 1212 [RMT-FLUTE] 1213 Paila, T., Walsh, R., Luby, M., Lehtonen, R., and V. Roca, 1214 "FLUTE - File Delivery over Unidirectional Transport", 1215 Work in Progress, September 2008. 1217 [RMT-SEC] Roca, V., Adamson, B., and H. Asaeda, "Security and 1218 Reliable Multicast Transport Protocols: Discussions and 1219 Guidelines", Work in progress, 1220 draft-ietf-rmt-sec-discussion-04.txt, July 2009. 1222 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 1223 Randers-Pehrson, "GZIP file format specification version 1224 4.3", RFC 1952, May 1996. 1226 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 1227 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 1228 RFC 2068, January 1997. 1230 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1231 Hashing for Message Authentication", RFC 2104, 1232 February 1997. 1234 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1235 Standards (PKCS) #1: RSA Cryptography Specifications 1236 Version 2.1", RFC 3447, February 2003. 1238 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 1239 Briscoe, "Timed Efficient Stream Loss-Tolerant 1240 Authentication (TESLA): Multicast Source Authentication 1241 Transform Introduction", RFC 4082, June 2005. 1243 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1244 December 2005. 1246 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1247 RFC 4303, December 2005. 1249 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1250 Correction (FEC) Building Block", RFC 5052, August 2007. 1252 [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, 1253 "Reed-Solomon Forward Error Correction (FEC) Schemes", 1254 RFC 5510, April 2009. 1256 Appendix A. FCAST Examples 1258 A.1. Basic Examples 1259 0 1 2 3 1260 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 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | 0 |1|0| 0 | 0 | 39 | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | Checksum | | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1266 . . 1267 . meta-data ASCII null terminated string (33 bytes) . 1268 . . 1269 + +-+-+-+-+-+-+-+-+ 1270 | | Padding | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 . . 1273 . Object data . 1274 . . 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 Figure 4: Compound Object Example. 1279 Figure 4 shows a regular Compound Object where the meta-data ASCII 1280 string, in HTTP/1.1 meta-information format (MDFmt=0) contains: 1282 Content-Location: example.txt 1284 This string is 33 bytes long, including the NULL-termination 1285 character. There is no gzip encoding of the meta-data (MDEnc=0) and 1286 there is no Content-Length information either since this length can 1287 easily be calculated by the receiver as the FEC OTI transfer length 1288 minus the header length. Finally, the checksum encompasses the whole 1289 Compound Object (G=1). 1290 0 1 2 3 1291 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 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | 0 |1|0| 0 | 0 | 6 | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | Checksum | Padding | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 . . 1298 . Object data . 1299 . . 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 Figure 5: Compound Object Example with no Meta-Data. 1304 Figure 5 shows a Compound Object without any meta-data. The fact 1305 there is no meta-data is indicated by the value 6 of the Header 1306 Length field. 1308 Figure 6 shows an example CIO object, in the case of a static FCAST 1309 session, i.e., a session where the set of objects is set once and for 1310 all. 1311 0 1 2 3 1312 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 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 | 0 |1| 0 | 0 | 4 | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 . . 1317 . Object List string . 1318 . . 1319 . +-+-+-+-+-+-+-+-+ 1320 . | 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 Figure 6: Example of CIO, in case of a static session. 1325 The object list contains the following string: 1327 1,2,3,100-104,200-203,299 1329 There are therefore a total of 3+5+4+1 = 13 objects in the carousel 1330 instance, and therefore in the FCAST session. There is no meta-data 1331 associated to this CIO. The session being static and composed of a 1332 single Carousel Instance, the sender did not feel the necessity to 1333 carry a Carousel Instance ID meta-data. 1335 A.2. FCAST/NORM with NORM_INFO Examples 1337 In case of FCAST/NORM, the FCAST Compound Object meta-data (or a 1338 subset of it) can be carried as part of a NORM_INFO message, as a new 1339 Compound Object that does not contain any Compound Object Data. In 1340 the following example we assume that the whole meta-data is carried 1341 in such a message for a certain Compound Object. Figure 7 shows an 1342 example NORM_INFO message that contains the FCAST Compound Object 1343 Header and meta-data as its payload. In this example, the first 16 1344 bytes are the NORM_INFO base header, the next 12 bytes are a NORM 1345 EXT_FTI header extension containing the FEC Object Transport 1346 Information for the associated object, and the remaining bytes are 1347 the FCAST Compound Object Header and meta-data. Note that "padding" 1348 MUST NOT be used and that the FCAST checksum only encompasses the 1349 Compound Object Header (G=0). 1351 0 1 2 3 1352 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 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 |version| type=1| hdr_len = 7 | sequence | 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 | source_id | 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | instance_id | grtt |backoff| gsize | 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 | flags | fec_id = 5 | object_transport_id | 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 | HET = 64 | HEL = 3 | | 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1364 | Transfer Length (L) | 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 | Encoding Symbol Length (E) | MaxBlkLen (B) | max_n | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | 0 |0|0| 0 | 0 | 39 | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | Checksum | | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1372 . . 1373 . meta-data ASCII null terminated string (33 bytes) . 1374 . . 1375 + +-+-+-+-+-+-+-+-+ 1376 | | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 Figure 7: NORM_INFO containing FCAST Compound Object Header 1381 The NORM_INFO message shown in Figure 7 contains the EXT_FTI header 1382 extension to carry the FEC OTI. In this example, the FEC OTI format 1383 is that of the Reed-Solomon FEC coding scheme for fec_id = 5 as 1384 described in [RFC5510]. Other alternatives for providing the FEC OTI 1385 would have been to either include it directly in the meta-data of the 1386 FCAST Compound Header, or to include an EXT_FTI header extension to 1387 all NORM_DATA packets (or a subset of them). Note that the NORM 1388 "Transfer_Length" is the total length of the associated FCAST 1389 Compound Object. 1391 The FCAST Compound Object in this example does contain the same meta- 1392 data and is formatted as in the example of Figure 4. With the 1393 combination of the FEC_OTI and the FCAST meta-data, the NORM protocol 1394 and FCAST application have all of the information needed to reliably 1395 receive and process the associated object. Indeed, the NORM protocol 1396 provides rapid (NORM_INFO has precedence over the associated object 1397 content), reliable delivery of the NORM_INFO message and its payload, 1398 the FCAST Compound Object Header. 1400 Authors' Addresses 1402 Vincent Roca 1403 INRIA 1404 655, av. de l'Europe 1405 Inovallee; Montbonnot 1406 ST ISMIER cedex 38334 1407 France 1409 Email: vincent.roca@inria.fr 1410 URI: http://planete.inrialpes.fr/people/roca/ 1412 Brian Adamson 1413 Naval Research Laboratory 1414 Washington, DC 20375 1415 USA 1417 Email: adamson@itd.nrl.navy.mil 1418 URI: http://cs.itd.nrl.navy.mil