idnits 2.17.1 draft-ietf-rmt-fcast-03.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 (February 10, 2011) is 4821 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-08) exists of draft-ietf-rmt-sec-discussion-05 -- 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: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: August 14, 2011 Naval Research Laboratory 6 February 10, 2011 8 FCAST: Scalable Object Delivery for the ALC and NORM Protocols 9 draft-ietf-rmt-fcast-03 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 August 14, 2011. 35 Copyright Notice 37 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 54 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 55 3. Definitions, Notations and Abbreviations . . . . . . . . . . . 6 56 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 58 4. FCAST Principles . . . . . . . . . . . . . . . . . . . . . . . 7 59 4.1. FCAST Content Delivery Service . . . . . . . . . . . . . . 7 60 4.2. Meta-Data Transmission . . . . . . . . . . . . . . . . . . 8 61 4.3. Meta-Data Content . . . . . . . . . . . . . . . . . . . . 8 62 4.4. Carousel Transmission . . . . . . . . . . . . . . . . . . 10 63 4.5. Carousel Instance Descriptor Special Object . . . . . . . 10 64 4.6. Compound Object Identification . . . . . . . . . . . . . . 12 65 4.7. FCAST/ALC Additional Specificities . . . . . . . . . . . . 13 66 4.8. FCAST/NORM Additional Specificities . . . . . . . . . . . 13 67 4.9. FCAST Sender Behavior . . . . . . . . . . . . . . . . . . 14 68 4.10. FCAST Receiver Behavior . . . . . . . . . . . . . . . . . 15 69 5. FCAST Data Formats . . . . . . . . . . . . . . . . . . . . . . 16 70 5.1. Compound Object Header Format . . . . . . . . . . . . . . 16 71 5.2. Carousel Instance Descriptor Format . . . . . . . . . . . 18 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 73 6.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 21 74 6.2. Attacks Against the Data Flow . . . . . . . . . . . . . . 21 75 6.2.1. Access to Confidential Objects . . . . . . . . . . . . 22 76 6.2.2. Object Corruption . . . . . . . . . . . . . . . . . . 22 77 6.3. Attacks Against the Session Control Parameters and 78 Associated Building Blocks . . . . . . . . . . . . . . . . 23 79 6.3.1. Attacks Against the Session Description . . . . . . . 24 80 6.3.2. Attacks Against the FCAST CID . . . . . . . . . . . . 24 81 6.3.3. Attacks Against the Object Meta-Data . . . . . . . . . 24 82 6.3.4. Attacks Against the ALC/LCT and NORM Parameters . . . 25 83 6.3.5. Attacks Against the Associated Building Blocks . . . . 25 84 6.4. Other Security Considerations . . . . . . . . . . . . . . 26 85 6.5. Minimum Security Recommendations . . . . . . . . . . . . . 26 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 87 7.1. Namespace declaration for Object Meta-Data Format . . . . 27 88 7.1.1. Object Meta-Data Format registration . . . . . . . . . 27 89 7.2. Namespace declaration for Object Meta-Data Encoding . . . 27 90 7.2.1. Object Meta-Data Encoding registration . . . . . . . . 27 91 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 93 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 94 9.2. Informative References . . . . . . . . . . . . . . . . . . 29 95 Appendix A. FCAST Examples . . . . . . . . . . . . . . . . . . . 30 96 A.1. Basic Examples . . . . . . . . . . . . . . . . . . . . . . 30 97 A.2. FCAST/NORM with NORM_INFO Examples . . . . . . . . . . . . 32 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 101 1. Introduction 103 This document introduces the FCAST reliable and scalable object 104 (e.g., file) delivery application. Two variants of FCAST exist: 106 o FCAST/ALC that relies on the Asynchronous Layer Coding (ALC) 107 [RFC5775] and the Layered Coding Transport (LCT) [RFC5651] 108 reliable multicast transport protocol, and 110 o FCAST/NORM that relies on the NACK-Oriented Reliable Multicast 111 (NORM) [RFC5740] reliable multicast transport protocol. 113 Hereafter, the term FCAST denotes either FCAST/ALC or FCAST/NORM. 114 FCAST is not a new protocol specification per se. Instead it is a 115 set of data format specifications and instructions on how to use ALC 116 and NORM to implement a file-casting service. 118 Depending on the target use case, the delivery service provided by 119 FCAST is more or less reliable. For instance, with FCAST/ALC used in 120 ON-DEMAND mode over a time period that largely exceeds the typical 121 download time, the service can be considered as fully reliable. 122 Similarly, when FCAST is used along with a session control 123 application that collects reception information and takes appropriate 124 corrective measures (e.g., a direct point-to-point retransmission of 125 missing packets, or a new multicast recovery session), then the 126 service can be considered as fully reliable. On the opposite, if 127 FCAST operates in PUSH mode, then the service is usually only 128 partially reliable, and a receiver that is disconnected during a 129 sufficient time will perhaps not have the possibility to download the 130 object. 132 Depending on the target use case, the FCAST scalability is more or 133 less important. For instance, if FCAST/ALC is used on top of purely 134 unidirectional transport channels, with no feedback information at 135 all, which is the default mode of operation, then the scalability is 136 maximum since neither FCAST, nor ALC, UDP or IP generates any 137 feedback message. On the opposite, the FCAST/NORM scalability is 138 typically limited by NORM scalability itself. Similarly, if FCAST is 139 used along with a session control application that collects reception 140 information from the receivers, then this session control application 141 may limit the scalability of the global object delivery system. This 142 situation can of course be mitigated by using a hierarchy of feedback 143 message aggregators or servers. The details of this are out of the 144 scope of the present document. 146 A design goal behind FCAST is to define a streamlined solution, in 147 order to enable lightweight implementations of the protocol stack, 148 and limit the operational processing and storage requirements. A 149 consequence of this choice is that FCAST cannot be considered as a 150 versatile application, capable of addressing all the possible use- 151 cases. On the opposite, FCAST has some intrinsic limitations. From 152 this point of view it differs from FLUTE [RMT-FLUTE] which favors 153 flexibility at the expense of some additional complexity. 155 A good example of the design choices meant to favor the simplicity is 156 the way FCAST manages the object meta-data: by default, the meta-data 157 and the object content are sent together, in a compound object. This 158 solution has many advantages in terms of simplicity as will be 159 described later on. However, as such, it also has an intrinsic 160 limitation since it does not enable a receiver to decide in advance, 161 before beginning the reception of the compound object, whether the 162 object is of interest or not, based on the information that may be 163 provided in the meta-data. Therefore this document defines 164 additional techniques that may be used to mitigate this limitation. 165 It is also possible that some use-cases require that each receiver 166 download the whole set of objects sent in the session (e.g., with 167 mirroring tools). When this is the case, the above limitation is no 168 longer be a problem. 170 1.1. Applicability 172 FCAST is compatible with any congestion control protocol designed for 173 ALC/LCT or NORM. However, depending on the use-case, the data flow 174 generated by the FCAST application might not be constant, but instead 175 be bursty in nature. Similarly, depending on the use-case, an FCAST 176 session might be very short. Whether and how this will impact the 177 congestion control protocol is out of the scope of the present 178 document. 180 FCAST is compatible with any security mechanism designed for ALC/LCT 181 or NORM. The use of a security scheme is strongly RECOMMENDED (see 182 Section 6). 184 FCAST is compatible with any FEC scheme designed for ALC/LCT or NORM. 185 Whether FEC is used or not, and the kind of FEC scheme used, is to 186 some extent transparent to FCAST. 188 FCAST is compatible with both IPv4 and IPv6. Nothing in the FCAST 189 specification has any implication on the source or destination IP 190 address. 192 2. Requirements notation 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in [RFC2119]. 198 3. Definitions, Notations and Abbreviations 200 3.1. Definitions 202 This document uses the following definitions: 204 FCAST/ALC: denotes the FCAST application running on top of the ALC/ 205 LCT reliable transport protocol; 207 FCAST/NORM: denotes the FCAST application running on top of the NORM 208 reliable transport protocol; 210 FCAST: denotes either FCAST/ALC or FCAST/NORM; 212 Compound Object: denotes an ALC or NORM transport object composed of 213 the Compound Object Header (Section 5.1), including any meta- 214 data, and the content of the original application object 215 (e.g., a file); 217 Carousel: denotes the process of sending Compound Objects 218 implemented by a FCAST sender; 220 Carousel Instance: denotes a fixed set of registered Compound 221 Objects that are sent by the carousel during a certain number 222 of cycles. Whenever Compound Objects need to be added or 223 removed, a new Carousel Instance is defined; 225 Carousel Instance Descriptor (CID): denotes a special object that 226 lists the Compound Objects that comprise a given Carousel 227 Instance; 229 Carousel Cycle: denotes a transmission round within which all the 230 Compound Objects registered in the Carousel Instance are 231 transmitted a certain number of times. By default, Compound 232 Objects are transmitted once per cycle, but higher values are 233 possible, that might differ on a per-object basis; 235 Transmission Object Identifier (TOI): denotes the numeric identifier 236 associated to a specific object by the underlying transport 237 layer. In the case of ALC, this corresponds to the TOI 238 described in that specification while for the NORM 239 specification this corresponds to the NormTransportId 240 described there. 242 3.2. Abbreviations 244 This document uses the following abbreviations: 246 CID: Carousel Instance Descriptor 248 CIID: Carousel Instance IDentifier 250 FEC OTI: FEC Object Transmission Information 252 TOI: Transmission Object Identifier 254 4. FCAST Principles 256 4.1. FCAST Content Delivery Service 258 The basic goal of FCAST is to transmit objects to a group of 259 receivers in a reliable way. The receiver set MAY be restricted to a 260 single receiver or MAY include possibly a very large number of 261 receivers. FCAST is specified to support two forms of operation: 263 1. FCAST/ALC: where the FCAST application is meant to run on top of 264 the ALC/LCT reliable multicast transport protocol, and 266 2. FCAST/NORM: where the FCAST application is meant to run on top of 267 the NORM reliable multicast transport protocol. 269 This specification is designed such that both forms of operation 270 share as much commonality as possible. 272 While the choice of the underlying transport protocol (i.e., ALC or 273 NORM) and its parameters may limit the practical receiver group size, 274 nothing in FCAST itself limits it. The transmission might be fully 275 reliable, or only partially reliable depending upon the way ALC or 276 NORM is used (e.g., whether FEC encoding and/or NACK-based repair 277 requests are used or not), the way the FCAST carousel is used (e.g., 278 whether the objects are made available for a long time span or not), 279 and the way in which FCAST itself is employed (e.g., whether there is 280 a session control application that might automatically extend an 281 existing FCAST session until all receivers have received the 282 transmitted content). 284 FCAST is designed to be as self-sufficient as possible, in particular 285 in the way object meta-data is attached to object data content. 286 However, for some uses, meta-data MAY also be communicated by an out- 287 of-band mechanism that is out of the scope of the present document. 289 4.2. Meta-Data Transmission 291 FCAST usually carries meta-data elements by prepending them to the 292 object it refers to. As a result, a Compound Object is created that 293 is composed of a header followed by the original object data. This 294 header is itself composed of the meta-data as well as several fields, 295 for instance to indicate the boundaries between the various parts of 296 this Compound Object (Figure 1). 298 <------------------------ Compound Object -----------------------> 299 +-------------------------+--------------------------------------+ 300 | Compound Object Header | Object Data | 301 | (can include meta-data) | (can be encoded by FCAST) | 302 +-------------------------+--------------------------------------+ 304 Figure 1: Compound Object composition. 306 Attaching the meta-data to the object is an efficient solution, since 307 it guaranties that meta-data be received along with the associated 308 object, and it allows the transport of the meta-data to benefit from 309 any transport-layer erasure protection of the Compound Object (e.g., 310 using FEC encoding and/or NACK-based repair). However a limit of 311 this scheme, as such, is that a client does not know the meta-data of 312 an object before beginning its reception, and in case of erasures 313 affecting the meta-data, not until the object decoding is completed. 314 The details of course depend upon the transport protocol and the FEC 315 code used. 317 In certain use-cases, FCAST can also be associated to another in-band 318 (e.g., via NORM INFO messages, Section 4.8) or out-of-band signaling 319 mechanism. In that case, this mechanism can be used in order to 320 carry the whole meta-data (or a subset of it), possibly ahead of 321 time. 323 4.3. Meta-Data Content 325 The meta-data associated to an object can be composed of, but are not 326 limited to: 328 o Content-Location: the URI of the object, which gives the name and 329 location of the object; 331 o Content-Type: the MIME type of the object; 333 o Content-Length: the size of the initial object, before any content 334 encoding (if any). Note that this content length does not include 335 the meta-data nor the fixed size Compound Object header; 337 o Content-Encoding: the optional encoding of the object performed by 338 FCAST. If there is no Content-Encoding entry, the receiver MUST 339 assume that the object is not encoded (default). The support of 340 gzip encoding, or any other solution, remains optional. 342 o Content-MD5: the MD5 message digest of the object in order to 343 check its integrity. Note that this digest is meant to protect 344 from transmission and processing errors, not from deliberate 345 attacks by an intelligent attacker. Note also that this digest 346 only protects the object, not the header, and therefore not the 347 meta-data. A separate checksum is provided to that purpose 348 (Section 5.1); 350 o a digital signature for this object; 352 This list is not limited and new meta-data information can be added. 353 For instance, when dealing with very large objects (e.g., that 354 largely exceed the working memory of a receiver), it can be 355 interesting to split this object into several sub-objects (or 356 slices). When this happens, the meta-data associated to each sub- 357 object MUST include the following entries: 359 o Fcast-Obj-Slice-Nb: the total number of slices. A value strictly 360 greater than 1 indicates that this object is the result of a split 361 of the original object; 363 o Fcast-Obj-Slice-Idx: the slice index (in the {0 .. SliceNb - 1} 364 interval); 366 o Fcast-Obj-Slice-Offset: the offset at which this slice starts 367 within the original object; 369 When meta-data elements are communicated out-of-band, in advance of 370 data transmission, the following pieces of information MAY also be 371 useful: 373 o TOI: the Transmission Object Identifier (TOI) of the object 374 (Section 4.6), in order to enable a receiver to easily associate 375 the meta-data to the object; 377 o FEC Object Transmission Information (FEC OTI). In this case the 378 FCAST sender does not need to use the optional EXT_FTI mechanism 379 of the ALC or NORM protocols. 381 4.4. Carousel Transmission 383 A set of FCAST Compound Objects scheduled for transmission are 384 considered a logical "Carousel". A given "Carousel Instance" is 385 comprised of a fixed set of Compound Objects. Whenever the FCAST 386 application needs to add new Compound Objects to, or remove old 387 Compound Objects from the transmission set, a new Carousel Instance 388 is defined since the set of Compound Objects changes. Because of the 389 native object multiplexing capability of both ALC and NORM, sender 390 and receiver(s) are both capable to multiplex and demultiplex FCAST 391 Compound Objects. 393 For a given Carousel Instance, one or more transmission cycles are 394 possible. During each cycle, all of the Compound Objects comprising 395 the Carousel are sent. By default, each object is transmitted once 396 per cycle. However, in order to allow different levels of priority, 397 some objects MAY be transmitted more often that others during a 398 cycle, and/or benefit from higher FEC protection than others. This 399 can be the case for instance for the CID objects (Section 4.5). For 400 some FCAST usage (e.g., a unidirectional "push" mode), a Carousel 401 Instance may be associated to a single transmission cycle. In other 402 cases it may be associated to a large number of transmission cycles 403 (e.g., in "on-demand" mode, where objects are made available for 404 download during a long period of time). 406 4.5. Carousel Instance Descriptor Special Object 408 The FCAST sender CAN transmit an OPTIONAL Carousel Instance 409 Descriptor (CID). The CID carries the list of the Compound Objects 410 that are part of a given Carousel Instance, by specifying their 411 respective Transmission Object Identifiers (TOI). However the CID 412 does not describe the objects themselves (i.e., there is no meta- 413 data). Additionally, the CID MAY include a "Complete" flag that is 414 used to indicate that no further modification to the enclosed list 415 will be done in the future. Finally, the CID MAY include a Carousel 416 Instance ID that identifies the Carousel Instance it pertains to. 417 These aspects are discussed in Section 5.2. 419 There is no reserved TOI value for the CID Compound Object itself, 420 since this special object is regarded by ALC/LCT or NORM as a 421 standard object. On the opposite, the nature of this object (CID) is 422 indicated by means of a specific Compound Object header field (the 423 "I" flag) so that it can be recognized and processed by the FCAST 424 application as needed. A direct consequence is the following: since 425 a receiver does not know in advance which TOI will be used for the 426 following CID (in case of a dynamic session), he MUST NOT filter out 427 packets that are not in the current CID's TOI list. Said 428 differently, the goal of CID is not to setup ALC or NORM packet 429 filters (this mechanism would not be secure in any case). 431 The use of a CID remains optional. If it is not used, then the 432 clients progressively learn what files are part of the carousel 433 instance by receiving ALC or NORM packets with new TOIs. However 434 using a CID has several benefits: 436 o When the "Complete" flag is set (if ever), the receivers know when 437 they can leave the session, i.e., when they have received all the 438 objects that are part of the last carousel instance of this 439 delivery session; 441 o In case of a session with a dynamic set of objects, the sender can 442 reliably inform the receivers that some objects have been removed 443 from the carousel with the CID. This solution is more robust than 444 the "Close Object flag (B)" of ALC/LCT since a client with an 445 intermittent connectivity might loose all the packets containing 446 this B flag. And while NORM provides a robust object cancellation 447 mechanism in the form of its NORM_CMD(SQUELCH) message in response 448 to receiver NACK repair requests, the use of the CID provides an 449 additional means for receivers to learn of objects for which it is 450 futile to request repair; 452 o The TOI equivalence (Section 4.6) can be signaled with the CID. 453 This is often preferable to the alternative solution where the 454 equivalence is identified by examining the object meta-data, 455 especially in case of erasures. 457 During idle periods, when the carousel instance does not contain any 458 object, a CID with an empty TOI list MAY be transmitted. In that 459 case, a new carousel instance ID MUST be used to differentiate this 460 (empty) carousel instance from the other ones. This mechanism can be 461 useful to inform the receivers that: 463 o all the previously sent objects have been removed from the 464 carousel. It therefore improves the FCAST robustness even during 465 "idle" period; 467 o the session is still active even if there is currently no content 468 being sent. Said differently, it can be used as a heartbeat 469 mechanism. If the "Complete" flag has not been set, it implicitly 470 informs the receivers that new objects MAY be sent in the future; 472 The decisions of whether a CID should be used or not, how often and 473 when a CID should be sent, are left to the sender and depend on many 474 parameters, including the target use case and the session dynamics. 475 For instance it may be appropriate to send a CID at the beginning of 476 each new carousel instance, and then periodically. These operational 477 aspects are out of the scope of the present document. 479 4.6. Compound Object Identification 481 The FCAST Compound Objects are directly associated with the object- 482 based transport service that the ALC and NORM protocols provide. In 483 each of these protocols, the messages containing transport object 484 content are labeled with a numeric transport object identifier (i.e., 485 the ALC TOI and the NORM NormTransportId). For the purposes of this 486 document, this identifier in either case (ALC or NORM) is referred to 487 as the TOI. 489 There are several differences between ALC and NORM: 491 o the ALC use of TOI is rather flexible, since several TOI field 492 sizes are possible (from 16 to 112 bits), since this size can be 493 changed at any time, on a per-packet basis, and since the TOI 494 management is totally free as long as each object is associated to 495 a unique TOI (if no wraparound happened); 497 o the NORM use of TOI is more directive, since the TOI field is 16 498 bit long and since TOIs MUST be managed sequentially; 500 In both NORM and ALC, it is possible that the transport 501 identification space may eventually wrap for long-lived sessions 502 (especially with NORM where this phenomenon is expected to happen 503 more frequently). This can possibly introduce some ambiguity in 504 FCAST object identification if a sender retains some older objects in 505 newer Carousel Instances with updated object sets. To avoid 506 ambiguity the active TOIs (i.e., the TOIs corresponding to objects 507 being transmitted) can only occupy half of the TOI sequence space. 508 If an old object, whose TOI has fallen outside the current window, 509 needs to be transmitted again, a new TOI must be used for it. 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 CID, 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 CID 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 CID 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 CID. 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 619 * the user wants to prematurely stop the transmissions, or 621 * the user wants to add one or several new objects to the 622 carousel, or on the opposite wants to remove old objects from 623 the carousel. In that case a new carousel instance must be 624 created. 626 7. If the session is not finished, then continue at Step 1 above; 628 4.10. FCAST Receiver Behavior 630 The following operations MAY take place at a receiver: 632 1. The receiver joins the session and collects incoming packets; 634 2. If the header portion of a Compound Object is entirely received 635 (which may happen before receiving the entire object with some 636 ALC/NORM configurations), or if the meta-data is sent by means of 637 another mechanism prior to the object, the receiver processes the 638 meta-data and chooses to continue to receive the object content 639 or not; 641 3. When a Compound Object has been entirely received, the receiver 642 processes the header, retrieves the object meta-data, perhaps 643 decodes the meta-data, and processes the object accordingly; 645 4. When a CID is received, which is indicated by the 'C' flag set in 646 the Compound Object header, the receiver decodes the CID, and 647 retrieves the list of objects that are part of the current 648 carousel instance. This list CAN be used to remove objects sent 649 in a previous carousel instance that might not have been totally 650 decoded and that are no longer part of the current carousel 651 instance; 653 5. When a CID is received, the receiver also retrieves the list of 654 TOI equivalences, if any, and takes appropriate measures, for 655 instance by informing the transport layer; 657 6. When a receiver has received a CID with the "Complete" flag set, 658 and has successfully received all the objects of the current 659 carousel instance, it can safely exit from the current FCAST 660 session; 662 7. Otherwise continue at Step 2 above. 664 5. FCAST Data Formats 666 This section details the various data formats used by FCAST. 668 5.1. Compound Object Header Format 670 In an FCAST session, Compound Objects are constructed by prepending 671 the Compound Object Header (which may include meta-data) before the 672 original object data content (Figure 2). 674 0 1 2 3 675 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 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 677 |Ver| Resvd |G|C| MDFmt | MDEnc | Checksum | | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 679 | Compound Object Header Length | h 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| d 681 | Object Meta-Data (optional, variable length) | r 682 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 683 | | Padding (optional) | | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 685 | | 686 . Object Data (optional, variable length) . 687 . . 688 . . 690 Figure 2: Compound Object Header with Meta-Data. 692 The Compound Object Header fields are: 694 +------------+------------------------------------------------------+ 695 | Field | Description | 696 +------------+------------------------------------------------------+ 697 | Version | 2-bit field that MUST be set to 0 in this | 698 | | specification and indicates the protocol version | 699 | | number. | 700 | Reserved | 4-bit field that MUST be set to 0 in this | 701 | | specification and is reserved for future use. | 702 | | Receivers MUST ignore this field. | 703 | G | 1-bit field that, when set to 1, indicates that the | 704 | | checksum encompasses the whole Compound Object | 705 | | (Global checksum). When set to 0, this field | 706 | | indicates that the checksum encompasses only the | 707 | | Compound Object header. | 708 | C | 1-bit field that, when set to 1, indicates the | 709 | | object is a Carousel Instance Descriptor (CID). | 710 | | When set to 0, this field indicates that the | 711 | | transported object is a standard object. | 712 | Meta-Data | 4-bit field that defines the format of the object | 713 | Format | meta-data (see Section 7). An HTTP/1.1 | 714 | (MDFmt) | metainformation format [RFC2616] MUST be supported | 715 | | and is associated to value 0. Other formats (e.g., | 716 | | XML) MAY be defined in the future. | 717 | Meta-Data | 4-bit field that defines the optional encoding of | 718 | Encoding | the Object Meta-Data field (see Section 7). By | 719 | (MDEnc) | default, a plain text encoding is used and is | 720 | | associated to value 0. Gzip encoding MUST also be | 721 | | supported and is associated to value 1. Other | 722 | | encodings MAY be defined in the future. | 723 | Checksum | 16-bit field that contains the checksum computed | 724 | | over either the whole Compound Object (when G is set | 725 | | to 1), or over the Compound Object header (when G is | 726 | | set to 0), using the Internet checksum algorithm | 727 | | specified in [RFC1071]. More precisely, the | 728 | | checksum field is the 16-bit one's complement of the | 729 | | one's complement sum of all 16-bit words to be | 730 | | considered. If a segment contains an odd number of | 731 | | octets to be checksummed, the last octet is padded | 732 | | on the right with zeros to form a 16-bit word for | 733 | | checksum purposes (this pad is not transmitted). | 734 | | While computing the checksum, the checksum field | 735 | | itself is set to zero. | 736 | Compound | 32-bit field indicating total length (in bytes) of | 737 | Object | all fields of the Compound Object Header, except the | 738 | Header | optional padding. A header length field set to | 739 | Length | value 8 means that there is no meta-data included. | 740 | | When this size is not multiple to 32-bits words and | 741 | | when the Compound Object Header is followed by a non | 742 | | null Compound Object Data, padding MUST be added. | 743 | | It should be noted that the meta-data field maximum | 744 | | size is equal to (2^32 - 8) bytes. | 745 | Object | Optional, variable length field that contains the | 746 | Meta-Data | meta-data associated to the object. The format and | 747 | | encoding of this field is defined by the MDFmt MDEnc | 748 | | fields. With the default HTTP/1.1 format and plain | 749 | | text encoding, the Meta-Data is NULL-terminated | 750 | | plain text that follows the "TYPE" ":" "VALUE" | 751 | | "" format used in HTTP/1.1 for | 752 | | metainformation [RFC2616]. The various meta-data | 753 | | items can appear in any order. The associated | 754 | | string, when non empty, MUST be NULL-terminated. | 755 | | When no meta-data is communicated, this field MUST | 756 | | be empty and the Compound Object Header Length MUST | 757 | | be equal to 8. | 758 | Padding | Optional, variable length field of zero-value bytes | 759 | | to align the start of the Object Data to 32-bit | 760 | | boundary. Padding is only used when the Compound | 761 | | Object Header Length value, in bytes, is not | 762 | | multiple of 4 and when the Compound Object Header is | 763 | | followed by non null Compound Object Data. | 764 +------------+------------------------------------------------------+ 766 The Compound Object Header is then followed by the Object Data, i.e., 767 the original object possibly encoded by FCAST. Note that the length 768 of this content is the transported object length (e.g., as specified 769 by the FEC OTI) minus the Compound Object Header Length and optional 770 padding if any. 772 5.2. Carousel Instance Descriptor Format 774 The format of the CID, which is a special Compound Object, is given 775 in Figure 3. 777 0 1 2 3 778 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 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 780 |Ver| Resvd |G|C| MDFmt | MDEnc | Checksum | | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 782 | Compound Object Header Length | h 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| d 784 | Object Meta-Data (optional, variable length) | r 785 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 786 | | Padding (optional) | | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 788 . . ^ 789 . Object List (variable length) . | 790 . . o 791 . +-+-+-+-+-+-+-+-+ b 792 . | j 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 795 Figure 3: Carousel Instance Object Format. 797 Because the CID is transmitted as a special Compound Object, the 798 following CID-specific meta-data entries are defined: 800 o Fcast-CID-Complete: when set to 1, it indicates that no new 801 objects in addition to the ones whose TOI are specified in this 802 CID, or the ones that have been specified in the previous CID(s), 803 will be sent in the future. Otherwise it MUST be set to 0. This 804 entry is optional. If absent, a receiver MUST conclude that the 805 session is complete. 807 o Fcast-CID-ID: this entry contains the Carousel Instance 808 IDentifier, or CIID. It starts from 0 and is incremented by 1 for 809 each new carousel instance. This entry is optional if the FCAST 810 session consists of a single, complete, carousel instance. In all 811 other cases, this entry MUST be defined. In particular, the CIID 812 is used by the TOI equivalence mechanism thanks to which any 813 object is uniquely identified, even if the TOI is updated (e.g., 814 after re-enqueuing the object with NORM). The Fcast-CID-ID value 815 can also be useful to detect possible gaps in the Carousel 816 Instances, for instance caused by long disconnection periods. 817 Finally, it can also be useful to avoid problems when TOI wrapping 818 to 0 takes place to differentiate the various incarnations of the 819 TOIs if need be. 821 The motivation for making the Fcast-CID-Complete and Fcast-CID-ID 822 entries optional is to simplify the simple case of a session 823 consisting of a single, complete, carousel instance, with an Object 824 List given in plain text, without any content encoding. In that 825 case, the CID does not need to contain any meta-data entry. 827 Additionally, the following standard meta-data entries are often used 828 (Section 4.3): 830 o Content-Length: it specifies the size of the object list, before 831 any content encoding (if any). 833 o Content-Encoding: it specifies the optional encoding of the object 834 list, performed by FCAST. For instance: 835 Content-Encoding: gzip 836 indicates that the Object List field has been encoded with gzip 837 [RFC1952]. If there is no Content-Encoding entry, the receiver 838 MUST assume that the Object List field is plain text (default). 839 The support of gzip encoding, or any other solution, remains 840 optional. 842 An empty Object List is valid and indicates that the current carousel 843 instance does not include any object (Section 4.5). This can be 844 specified by using the following meta-data entry: 845 Content-Length: 0 846 or simply by leaving the Object List empty. In both cases, padding 847 MUST NOT be used and consequently the transported object length 848 (e.g., as specified by the FEC OTI) minus the Compound Object Header 849 Length equals zero. 851 The non-encoded (i.e., plain text) Object List, when non empty, is a 852 NULL-terminated ASCII string. It can contain two things: 854 o a list of TOI values, and 856 o a list of TOI equivalences; 858 First of all, this string can contain the list of TOIs included in 859 the current carousel instance, specified either as the individual 860 TOIs of each object, or as TOI intervals, or any combination. The 861 format of the ASCII string is a comma-separated list of individual 862 "TOI" values or "TOI_a-TOI_b" elements. This latter case means that 863 all values between TOI_a and TOI_b, inclusive, are part of the list. 864 In that case TOI_a MUST be strictly inferior to TOI_b. If a TOI 865 wrapping to 0 occurs in an interval, then two TOI intervals MUST be 866 specified, TOI_a-MAX_TOI and 0-TOI_b. 868 This string can also contain the TOI equivalences, if any. The 869 format is a comma-separated list of "(" newTOI "=" 1stTOI "/" 1stCIID 870 ")" elements. Each element says that the new TOI, for the current 871 Carousel Instance, is equivalent to (i.e., refers to the same object 872 as) the provided identifier, 1stTOI, for the Carousel Instance of ID 873 1stCIID. 875 The ABNF specification is the following: 876 cid-list = *(list-elem *( "," list-elem)) 877 list-elem = toi-elem / toieq-elem 878 toi-elem = toi-value / toi-interval 879 toi-value = 1*DIGIT 880 toi-interval = toi-value "-" toi-value 881 ; additionally, the first toi-value MUST be 882 ; strictly inferior to the second toi-value 883 toieq-elem = "(" toi-value "=" toi-value "/" ciid-value ")" 884 ciid-value = 1*DIGIT 885 DIGIT = %x30-39 886 ; a digit between O and 9, inclusive 888 For readability purposes, it is RECOMMENDED that all the TOI values 889 in the list be given in increasing order. However a receiver MUST be 890 able to handle non-monotonically increasing values. It is also 891 RECOMMENDED to group the TOI equivalence elements together, at the 892 end of the list, in increasing newTOI order. However a receiver MUST 893 be able to handle lists of mixed TOI and TOI equivalence elements. 894 Specifying a TOI equivalence for a given newTOI relieves the sender 895 from specifying newTOI explicitly in the TOI list. However a 896 receiver MUST be able to handle situations where the same TOI appears 897 both in the TOI value and TOI equivalence lists. Finally, a given 898 TOI value or TOI equivalence item MUST NOT be included multiple times 899 in either list. 901 For instance, the following object list specifies that the current 902 Carousel Instance is composed of 8 objects, and that TOIs 100 to 104 903 are equivalent to the TOIs 10 to 14 of Carousel Instance ID 2 and 904 refer to the same objects: 906 97,98,99,(100=10/2),(101=11/2),(102=12/2),(103=13/2),(104=14/2) 908 or equivalently: 910 97-104,(100=10/2),(101=11/2),(102=12/2),(103=13/2),(104=14/2) 912 6. Security Considerations 914 6.1. Problem Statement 916 A content delivery system is potentially subject to attacks. Attacks 917 may target: 919 o the network (to compromise the routing infrastructure, e.g., by 920 creating congestion), 922 o the Content Delivery Protocol (CDP) (e.g., to compromise the 923 normal behavior of FCAST), or 925 o the content itself (e.g., to corrupt the objects being 926 transmitted). 928 These attacks can be launched either: 930 o against the data flow itself (e.g., by sending forged packets), 932 o against the session control parameters (e.g., by corrupting the 933 session description, the CID, the object meta-data, or the ALC/LCT 934 control parameters), that are sent either in-band or out-of-band, 935 or 937 o against some associated building blocks (e.g., the congestion 938 control component). 940 In the following sections we provide more details on these possible 941 attacks and sketch some possible counter-measures. We finally 942 provide recommendations in Section 6.5. 944 6.2. Attacks Against the Data Flow 946 Let us consider attacks against the data flow first. At least, the 947 following types of attacks exist: 949 o attacks that are meant to give access to a confidential object 950 (e.g., in case of a non-free content) and 952 o attacks that try to corrupt the object being transmitted (e.g., to 953 inject malicious code within an object, or to prevent a receiver 954 from using an object, which is a kind of Denial of Service (DoS)). 956 6.2.1. Access to Confidential Objects 958 Access control to the object being transmitted is typically provided 959 by means of encryption. This encryption can be done over the whole 960 object (e.g., by the content provider, before submitting the object 961 to FCAST), or be done on a packet per packet basis (e.g., when IPsec/ 962 ESP is used [RFC4303], see Section 6.5). If confidentiality is a 963 concern, it is RECOMMENDED that one of these solutions be used. 965 6.2.2. Object Corruption 967 Protection against corruptions (e.g., if an attacker sends forged 968 packets) is achieved by means of a content integrity verification/ 969 sender authentication scheme. This service can be provided at the 970 object level, but in that case a receiver has no way to identify 971 which symbol(s) is(are) corrupted if the object is detected as 972 corrupted. This service can also be provided at the packet level. 973 In this case, after removing all corrupted packets, the file may be 974 in some cases recovered. Several techniques can provide this content 975 integrity/sender authentication service: 977 o at the object level, the object can be digitally signed, for 978 instance by using RSASSA-PKCS1-v1_5 [RFC3447]. This signature 979 enables a receiver to check the object integrity, once this latter 980 has been fully decoded. Even if digital signatures are 981 computationally expensive, this calculation occurs only once per 982 object, which is usually acceptable; 984 o at the packet level, each packet can be digitally signed 985 [RMT-SIMPLE-AUTH]. A major limitation is the high computational 986 and transmission overheads that this solution requires. To avoid 987 this problem, the signature may span a set of packets (instead of 988 a single one) in order to amortize the signature calculation. But 989 if a single packets is missing, the integrity of the whole set 990 cannot be checked; 992 o at the packet level, a Group Message Authentication Code (MAC) 993 [RFC2104][RMT-SIMPLE-AUTH] scheme can be used, for instance by 994 using HMAC-SHA-256 with a secret key shared by all the group 995 members, senders and receivers. This technique creates a 996 cryptographically secured digest of a packet that is sent along 997 with the packet. The Group MAC scheme does not create prohibitive 998 processing load nor transmission overhead, but it has a major 999 limitation: it only provides a group authentication/integrity 1000 service since all group members share the same secret group key, 1001 which means that each member can send a forged packet. It is 1002 therefore restricted to situations where group members are fully 1003 trusted (or in association with another technique as a pre-check); 1005 o at the packet level, Timed Efficient Stream Loss-Tolerant 1006 Authentication (TESLA) [RFC4082][RFC5776] is an attractive 1007 solution that is robust to losses, provides a true authentication/ 1008 integrity service, and does not create any prohibitive processing 1009 load or transmission overhead. Yet checking a packet requires a 1010 small delay (a second or more) after its reception; 1012 o at the packet level, IPsec/ESP [RFC4303] can be used to check the 1013 integrity and authenticate the sender of all the packets being 1014 exchanged in a session (see Section 6.5). 1016 Techniques relying on public key cryptography (digital signatures and 1017 TESLA during the bootstrap process, when used) require that public 1018 keys be securely associated to the entities. This can be achieved by 1019 a Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by 1020 pre-distributing securely the public keys of each group member. 1022 Techniques relying on symmetric key cryptography (Group MAC) require 1023 that a secret key be shared by all group members. This can be 1024 achieved by means of a group key management protocol, or simply by 1025 pre-distributing securely the secret key (but this manual solution 1026 has many limitations). 1028 It is up to the developer and deployer, who know the security 1029 requirements and features of the target application area, to define 1030 which solution is the most appropriate. In any case, whenever there 1031 is any concern of the threat of file corruption, it is RECOMMENDED 1032 that at least one of these techniques be used. 1034 6.3. Attacks Against the Session Control Parameters and Associated 1035 Building Blocks 1037 Let us now consider attacks against the session control parameters 1038 and the associated building blocks. The attacker has at least the 1039 following opportunities to launch an attack: 1041 o the attack can target the session description, 1043 o the attack can target the FCAST CID, 1044 o the attack can target the meta-data of an object, 1046 o the attack can target the ALC/LCT parameters, carried within the 1047 LCT header or 1049 o the attack can target the FCAST associated building blocks, for 1050 instance the multiple rate congestion control protocol. 1052 The consequences of these attacks are potentially serious, since they 1053 can compromise the behavior of content delivery system or even 1054 compromise the network itself. 1056 6.3.1. Attacks Against the Session Description 1058 An FCAST receiver may potentially obtain an incorrect Session 1059 Description for the session. The consequence of this is that 1060 legitimate receivers with the wrong Session Description are unable to 1061 correctly receive the session content, or that receivers 1062 inadvertently try to receive at a much higher rate than they are 1063 capable of, thereby possibly disrupting other traffic in the network. 1065 To avoid these problems, it is RECOMMENDED that measures be taken to 1066 prevent receivers from accepting incorrect Session Descriptions. One 1067 such measure is the sender authentication to ensure that receivers 1068 only accept legitimate Session Descriptions from authorized senders. 1069 How these measures are achieved is outside the scope of this document 1070 since this session description is usually carried out-of-band. 1072 6.3.2. Attacks Against the FCAST CID 1074 Corrupting the FCAST CID is one way to create a Denial of Service 1075 attack. For example, the attacker can set the "Complete" flag to 1076 make the receivers believe that no further modification will be done. 1078 It is therefore RECOMMENDED that measures be taken to guarantee the 1079 integrity and to check the sender's identity of the CID. To that 1080 purpose, one of the counter-measures mentioned above (Section 6.2.2) 1081 SHOULD be used. These measures will either be applied on a packet 1082 level, or globally over the whole CID object. When there is no 1083 packet level integrity verification scheme, it is RECOMMENDED to 1084 digitally sign the CID. 1086 6.3.3. Attacks Against the Object Meta-Data 1088 Corrupting the object meta-data is another way to create a Denial of 1089 Service attack. For example, the attacker changes the MD5 sum 1090 associated to a file. This possibly leads a receiver to reject the 1091 files received, no matter whether the files have been correctly 1092 received or not. When the meta-data are appended to the object, 1093 corrupting the meta-data means that the Compound Object will be 1094 corrupted. 1096 It is therefore RECOMMENDED that measures be taken to guarantee the 1097 integrity and to check the sender's identity of the Compound Object. 1098 To that purpose, one of the counter-measures mentioned above 1099 (Section 6.2.2) SHOULD be used. These measures will either be 1100 applied on a packet level, or globally over the whole Compound 1101 Object. When there is no packet level integrity verification scheme, 1102 it is RECOMMENDED to digitally sign the Compound Object. 1104 6.3.4. Attacks Against the ALC/LCT and NORM Parameters 1106 By corrupting the ALC/LCT header (or header extensions) one can 1107 execute attacks on the underlying ALC/LCT implementation. For 1108 example, sending forged ALC packets with the Close Session flag (A) 1109 set to one can lead the receiver to prematurely close the session. 1110 Similarly, sending forged ALC packets with the Close Object flag (B) 1111 set to one can lead the receiver to prematurely give up the reception 1112 of an object. The same comments can be made for NORM. 1114 It is therefore RECOMMENDED that measures be taken to guarantee the 1115 integrity and to check the sender's identity of each ALC or NORM 1116 packet received. To that purpose, one of the counter-measures 1117 mentioned above (Section 6.2.2) SHOULD be used. 1119 6.3.5. Attacks Against the Associated Building Blocks 1121 Let us first focus on the congestion control building block that may 1122 be used in an ALC or NORM session. A receiver with an incorrect or 1123 corrupted implementation of the multiple rate congestion control 1124 building block may affect the health of the network in the path 1125 between the sender and the receiver. That may also affect the 1126 reception rates of other receivers who joined the session. 1128 When congestion control is applied with FCAST, it is therefore 1129 RECOMMENDED that receivers be required to identify themselves as 1130 legitimate before they receive the Session Description needed to join 1131 the session. If authenticating a receiver does not prevent this 1132 latter to launch an attack, it will enable the network operator to 1133 identify him and to take counter-measures. This authentication can 1134 be made either toward the network operator or the session sender (or 1135 a representative of the sender) in case of NORM. The details of how 1136 it is done are outside the scope of this document. 1138 When congestion control is applied with FCAST, it is also RECOMMENDED 1139 that a packet level authentication scheme be used, as explained in 1140 Section 6.2.2. Some of them, like TESLA, only provide a delayed 1141 authentication service, whereas congestion control requires a rapid 1142 reaction. It is therefore RECOMMENDED [RFC5775] that a receiver 1143 using TESLA quickly reduces its subscription level when the receiver 1144 believes that a congestion did occur, even if the packet has not yet 1145 been authenticated. Therefore TESLA will not prevent DoS attacks 1146 where an attacker makes the receiver believe that a congestion 1147 occurred. This is an issue for the receiver, but this will not 1148 compromise the network. Other authentication methods that do not 1149 feature this delayed authentication could be preferred, or a group 1150 MAC scheme could be used in parallel to TESLA to prevent attacks 1151 launched from outside of the group. 1153 6.4. Other Security Considerations 1155 Lastly, we note that the security considerations that apply to, and 1156 are described in, ALC [RFC5775], LCT [RFC5651], NORM [RFC5740] and 1157 FEC [RFC5052] also apply to FCAST as FCAST builds on those 1158 specifications. In addition, any security considerations that apply 1159 to any congestion control building block used in conjunction with 1160 FCAST also applies to FCAST. Finally, the security discussion of 1161 [RMT-SEC] also applies here. 1163 6.5. Minimum Security Recommendations 1165 We now introduce a mandatory to implement but not necessarily to use 1166 security configuration, in the sense of [RFC3365]. Since FCAST/ALC 1167 relies on ALC/LCT, it inherits the "baseline secure ALC operation" of 1168 [RFC5775]. Similarly, since FCAST/NORM relies on NORM, it inherits 1169 the "baseline secure NORM operation" of [RFC5740]. More precisely, 1170 in both cases security is achieved by means of IPsec/ESP in transport 1171 mode. [RFC4303] explains that ESP can be used to potentially provide 1172 confidentiality, data origin authentication, content integrity, anti- 1173 replay and (limited) traffic flow confidentiality. [RFC5775] 1174 specifies that the data origin authentication, content integrity and 1175 anti-replay services SHALL be used, and that the confidentiality 1176 service is RECOMMENDED. If a short lived session MAY rely on manual 1177 keying, it is also RECOMMENDED that an automated key management 1178 scheme be used, especially in case of long lived sessions. 1180 Therefore, the RECOMMENDED solution for FCAST provides per-packet 1181 security, with data origin authentication, integrity verification and 1182 anti-replay. This is sufficient to prevent most of the in-band 1183 attacks listed above. If confidentiality is required, a per-packet 1184 encryption SHOULD also be used. 1186 7. IANA Considerations 1188 7.1. Namespace declaration for Object Meta-Data Format 1190 This document requires a IANA registration for the following name- 1191 space: "Object Meta-Data Format" (MDFmt). Values in this namespace 1192 are 4-bit positive integers between 0 and 15 inclusive and they 1193 define the format of the object meta-data ((see Section 5.1). 1195 Initial values for the LCT Header Extension Type registry are defined 1196 in Section 7.1.1. Future assignments are to be made through Expert 1197 Review [RFC5226]. 1199 7.1.1. Object Meta-Data Format registration 1201 This document registers one value in the "Object Meta-Data Format" 1202 namespace as follows: 1204 +----------------------------------------+-------------+ 1205 | format name | Value | 1206 +----------------------------------------+-------------+ 1207 | as per HTTP/1.1 metainformation format | 0 (default) | 1208 +----------------------------------------+-------------+ 1210 All implementations MUST support format 0 (default). 1212 7.2. Namespace declaration for Object Meta-Data Encoding 1214 This document requires a IANA registration for the following name- 1215 space: "Object Meta-Data Encoding" (MDEnc). Values in this namespace 1216 are 4-bit positive integers between 0 and 15 inclusive and they 1217 define the optional encoding of the Object Meta-Data field (see 1218 Section 5.1). 1220 Initial values for the LCT Header Extension Type registry are defined 1221 in Section 7.2.1. Future assignments are to be made through Expert 1222 Review [RFC5226]. 1224 7.2.1. Object Meta-Data Encoding registration 1226 This document registers two values in the "Object Meta-Data Encoding" 1227 namespace as follows: 1229 +------------+-------------+ 1230 | Name | Value | 1231 +------------+-------------+ 1232 | plain text | 0 (default) | 1233 | gzip | 1 | 1234 +------------+-------------+ 1236 All implementations MUST support both value 0 (plain-text, default) 1237 and value 1 (gzip). 1239 8. Acknowledgments 1241 The authors are grateful to the authors of [ALC-00] for specifying 1242 the first version of FCAST/ALC. The authors are also grateful to 1243 Gorry Fairhurst and Lorenzo Vicisano for their valuable comments. 1245 9. References 1247 9.1. Normative References 1249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1250 Requirement Levels", BCP 14, RFC 2119, March 1997. 1252 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1253 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1254 May 2008. 1256 [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, 1257 "Computing the Internet checksum", RFC 1071, 1258 September 1988. 1260 [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding 1261 Transport (LCT) Building Block", RFC 5651, October 2009. 1263 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 1264 "NACK-Oriented Reliable Multicast (NORM) Transport 1265 Protocol", RFC 5740, November 2009. 1267 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 1268 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 1269 April 2010. 1271 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 1272 Randers-Pehrson, "GZIP file format specification version 1273 4.3", RFC 1952, May 1996. 1275 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1276 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1277 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1279 9.2. Informative References 1281 [ALC-00] Luby, M., Gemmell, G., Vicisano, L., Crowcroft, J., and B. 1282 Lueckenhoff, "Asynchronous Layered Coding: a Scalable 1283 Reliable Multicast Protocol", March 2000. 1285 [RMT-FLUTE] 1286 Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 1287 "FLUTE - File Delivery over Unidirectional Transport", 1288 Work in Progress, February 2011. 1290 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 1291 Engineering Task Force Standard Protocols", BCP 61, 1292 RFC 3365, August 2002. 1294 [RMT-SEC] Roca, V., Adamson, B., and H. Asaeda, "Security and 1295 Reliable Multicast Transport Protocols: Discussions and 1296 Guidelines", Work in progress, 1297 draft-ietf-rmt-sec-discussion-05.txt, May 2010. 1299 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1300 Hashing for Message Authentication", RFC 2104, 1301 February 1997. 1303 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1304 Standards (PKCS) #1: RSA Cryptography Specifications 1305 Version 2.1", RFC 3447, February 2003. 1307 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 1308 Briscoe, "Timed Efficient Stream Loss-Tolerant 1309 Authentication (TESLA): Multicast Source Authentication 1310 Transform Introduction", RFC 4082, June 2005. 1312 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1313 RFC 4303, December 2005. 1315 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1316 Correction (FEC) Building Block", RFC 5052, August 2007. 1318 [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, 1319 "Reed-Solomon Forward Error Correction (FEC) Schemes", 1320 RFC 5510, April 2009. 1322 [RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed 1323 Efficient Stream Loss-Tolerant Authentication (TESLA) in 1324 the Asynchronous Layered Coding (ALC) and NACK-Oriented 1325 Reliable Multicast (NORM) Protocols", RFC 5776, 1326 April 2010. 1328 [RMT-SIMPLE-AUTH] 1329 Roca, V., "Simple Authentication Schemes for the ALC and 1330 NORM Protocols", Work in 1331 progress draft-ietf-rmt-simple-auth-for-alc-norm-03.txt, 1332 July 2010. 1334 Appendix A. FCAST Examples 1336 A.1. Basic Examples 1337 0 1 2 3 1338 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 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | 0 | 0 |1|0| 0 | 0 | Checksum | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | 44 | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1344 . . 1345 . meta-data ASCII null terminated string (33 bytes) . 1346 . . 1347 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 | | Padding | 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 . . 1351 . Object data . 1352 . . 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 Figure 4: Compound Object Example. 1357 Figure 4 shows a regular Compound Object where the meta-data ASCII 1358 string, in HTTP/1.1 meta-information format (MDFmt=0) contains: 1360 Content-Location: example.txt 1362 This string is 33 bytes long, including the NULL-termination 1363 character. There is no gzip encoding of the meta-data (MDEnc=0) and 1364 there is no Content-Length information either since this length can 1365 easily be calculated by the receiver as the FEC OTI transfer length 1366 minus the header length. Finally, the checksum encompasses the whole 1367 Compound Object (G=1). 1369 0 1 2 3 1370 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 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 | 0 | 0 |1|0| 0 | 0 | Checksum | 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 | 8 | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 . . 1377 . Object data . 1378 . . 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 Figure 5: Compound Object Example with no Meta-Data. 1383 Figure 5 shows a Compound Object without any meta-data. The fact 1384 there is no meta-data is indicated by the value 8 of the Compound 1385 Object Header Length field. No padding is required. 1387 Figure 6 shows an example CID object, in the case of a static FCAST 1388 session, i.e., a session where the set of objects is set once and for 1389 all. There is no meta-data in this example since Fcast-CID-Complete 1390 and Fcast-CID-ID are both implicit. 1391 0 1 2 3 1392 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 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | 0 | 0 |1|1| 0 | 0 | Checksum | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 | 8 | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1398 . . 1399 . Object List string . 1400 . . 1401 . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 . | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 Figure 6: Example of CID, in case of a static session. 1407 The object list contains the following 26 byte long string, including 1408 the NULL-termination character: 1410 1,2,3,100-104,200-203,299 1412 There are therefore a total of 3+5+4+1 = 13 objects in the carousel 1413 instance, and therefore in the FCAST session. There is no meta-data 1414 associated to this CID. The session being static and composed of a 1415 single Carousel Instance, the sender did not feel the necessity to 1416 carry a Carousel Instance ID meta-data. 1418 A.2. FCAST/NORM with NORM_INFO Examples 1420 In case of FCAST/NORM, the FCAST Compound Object meta-data (or a 1421 subset of it) can be carried as part of a NORM_INFO message, as a new 1422 Compound Object that does not contain any Compound Object Data. In 1423 the following example we assume that the whole meta-data is carried 1424 in such a message for a certain Compound Object. Figure 7 shows an 1425 example NORM_INFO message that contains the FCAST Compound Object 1426 Header and meta-data as its payload. In this example, the first 16 1427 bytes are the NORM_INFO base header, the next 12 bytes are a NORM 1428 EXT_FTI header extension containing the FEC Object Transport 1429 Information for the associated object, and the remaining bytes are 1430 the FCAST Compound Object Header and meta-data. Note that "padding" 1431 MUST NOT be used and that the FCAST checksum only encompasses the 1432 Compound Object Header (G=0). 1433 0 1 2 3 1434 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 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- 1436 |version| type=1| hdr_len = 7 | sequence | ^ 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1438 | source_id | n 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o 1440 | instance_id | grtt |backoff| gsize | r 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ m 1442 | flags | fec_id = 5 | object_transport_id | v 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- 1444 | HET = 64 | HEL = 3 | | ^ 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + f 1446 | Transfer Length = 41 | t 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i 1448 | Encoding Symbol Length (E) | MaxBlkLen (B) | max_n | v 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- 1450 | 0 | 0 |0|0| 0 | 0 | Checksum | ^ 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1452 | 41 | f 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| c 1454 . . a 1455 . meta-data ASCII null terminated string (33 bytes) . s 1456 . . t 1457 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1458 | | v 1459 +-+-+-+-+-+-+-+-+ -- 1461 Figure 7: NORM_INFO containing an EXT_FTI header extension and an 1462 FCAST Compound Object Header 1464 The NORM_INFO message shown in Figure 7 contains the EXT_FTI header 1465 extension to carry the FEC OTI. In this example, the FEC OTI format 1466 is that of the Reed-Solomon FEC coding scheme for fec_id = 5 as 1467 described in [RFC5510]. Other alternatives for providing the FEC OTI 1468 would have been to either include it directly in the meta-data of the 1469 FCAST Compound Header, or to include an EXT_FTI header extension to 1470 all NORM_DATA packets (or a subset of them). Note that the NORM 1471 "Transfer_Length" is the total length of the associated FCAST 1472 Compound Object, i.e., 41 bytes. 1474 The FCAST Compound Object in this example does contain the same meta- 1475 data and is formatted as in the example of Figure 4. With the 1476 combination of the FEC_OTI and the FCAST meta-data, the NORM protocol 1477 and FCAST application have all of the information needed to reliably 1478 receive and process the associated object. Indeed, the NORM protocol 1479 provides rapid (NORM_INFO has precedence over the associated object 1480 content), reliable delivery of the NORM_INFO message and its payload, 1481 the FCAST Compound Object Header. 1483 Authors' Addresses 1485 Vincent Roca 1486 INRIA 1487 655, av. de l'Europe 1488 Inovallee; Montbonnot 1489 ST ISMIER cedex 38334 1490 France 1492 Email: vincent.roca@inria.fr 1493 URI: http://planete.inrialpes.fr/people/roca/ 1495 Brian Adamson 1496 Naval Research Laboratory 1497 Washington, DC 20375 1498 USA 1500 Email: adamson@itd.nrl.navy.mil 1501 URI: http://cs.itd.nrl.navy.mil