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