idnits 2.17.1 draft-ietf-rmt-fcast-06.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 (October 22, 2012) is 4201 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 1071 ** Downref: Normative reference to an Informational RFC: RFC 1952 ** 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-06 -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) Summary: 4 errors (**), 0 flaws (~~), 2 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: Standards Track B. Adamson 5 Expires: April 25, 2013 Naval Research Laboratory 6 October 22, 2012 8 FCAST: Scalable Object Delivery for the ALC and NORM Protocols 9 draft-ietf-rmt-fcast-06 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 April 25, 2013. 35 Copyright Notice 37 Copyright (c) 2012 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. Requirements Notation . . . . . . . . . . . . . . . . . . 5 54 1.2. Definitions, Notations and Abbreviations . . . . . . . . . 5 55 2. FCAST Data Formats . . . . . . . . . . . . . . . . . . . . . . 6 56 2.1. Compound Object Format . . . . . . . . . . . . . . . . . . 6 57 2.2. Carousel Instance Descriptor Format . . . . . . . . . . . 8 58 3. FCAST Principles . . . . . . . . . . . . . . . . . . . . . . . 12 59 3.1. FCAST Content Delivery Service . . . . . . . . . . . . . . 12 60 3.2. Meta-Data Transmission . . . . . . . . . . . . . . . . . . 12 61 3.3. Meta-Data Content . . . . . . . . . . . . . . . . . . . . 13 62 3.4. Carousel Transmission . . . . . . . . . . . . . . . . . . 14 63 3.5. Carousel Instance Descriptor Special Object . . . . . . . 14 64 3.6. Compound Object Identification . . . . . . . . . . . . . . 16 65 3.7. FCAST Sender Behavior . . . . . . . . . . . . . . . . . . 17 66 3.8. FCAST Receiver Behavior . . . . . . . . . . . . . . . . . 18 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 68 4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 18 69 4.2. Attacks Against the Data Flow . . . . . . . . . . . . . . 19 70 4.2.1. Access to Confidential Objects . . . . . . . . . . . . 19 71 4.2.2. Object Corruption . . . . . . . . . . . . . . . . . . 19 72 4.3. Attacks Against the Session Control Parameters and 73 Associated Building Blocks . . . . . . . . . . . . . . . . 21 74 4.3.1. Attacks Against the Session Description . . . . . . . 21 75 4.3.2. Attacks Against the FCAST CID . . . . . . . . . . . . 22 76 4.3.3. Attacks Against the Object Meta-Data . . . . . . . . . 22 77 4.3.4. Attacks Against the ALC/LCT and NORM Parameters . . . 22 78 4.3.5. Attacks Against the Associated Building Blocks . . . . 23 79 4.4. Other Security Considerations . . . . . . . . . . . . . . 23 80 4.5. Minimum Security Recommendations . . . . . . . . . . . . . 24 81 5. Requirements for Compliant Implementations . . . . . . . . . . 24 82 5.1. Requirements Related to the Object Meta-Data . . . . . . . 24 83 5.2. Requirements Related to the Carousel Instance 84 Descriptor (CID) Mechanism . . . . . . . . . . . . . . . . 26 85 6. Operational Considerations . . . . . . . . . . . . . . . . . . 26 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 87 7.1. Creation of the FCAST Object Meta-Data Format Registry . . 27 88 7.2. Creation of the FCAST Object Meta-Data Encoding 89 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 28 90 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 29 94 Appendix A. FCAST Examples . . . . . . . . . . . . . . . . . . . 30 95 A.1. Regular Compound Object Example . . . . . . . . . . . . . 30 96 A.2. Carousel Instance Descriptor Example . . . . . . . . . . . 31 97 Appendix B. Additional Meta-Data Transmission Mechanisms . . . . 31 98 B.1. Supporting Additional Mechanisms . . . . . . . . . . . . . 31 99 B.2. Using NORM_INFO Messages with FCAST/NORM . . . . . . . . . 32 100 B.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 32 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 103 1. Introduction 105 This document introduces the FCAST reliable and scalable object 106 (e.g., file) delivery application. Two variants of FCAST exist: 108 o FCAST/ALC that relies on the Asynchronous Layer Coding (ALC) 109 [RFC5775] and the Layered Coding Transport (LCT) [RFC5651] 110 reliable multicast transport protocol, and 112 o FCAST/NORM that relies on the NACK-Oriented Reliable Multicast 113 (NORM) [RFC5740] reliable multicast transport protocol. 115 Hereafter, the term FCAST denotes either FCAST/ALC or FCAST/NORM. 116 FCAST is not a new protocol specification per se. Instead it is a 117 set of data format specifications and instructions on how to use ALC 118 and NORM to implement a file-casting service. 120 A design goal behind FCAST is to define a streamlined solution, in 121 order to enable lightweight implementations of the protocol stack, 122 and limit the operational processing and storage requirements. A 123 consequence of this choice is that FCAST cannot be considered as a 124 versatile application, capable of addressing all the possible use- 125 cases. On the contrary, FCAST has some intrinsic limitations. From 126 this point of view it differs from FLUTE [I-D.ietf-rmt-flute-revised] 127 which favors flexibility at the expense of some additional 128 complexity. 130 A good example of the design choices meant to favor simplicity is the 131 way FCAST manages the object meta-data: by default, the meta-data and 132 the object content are sent together, in a compound object. This 133 solution has many advantages in terms of simplicity as will be 134 described later on. However this solution has an intrinsic 135 limitation since it does not enable a receiver to decide in advance, 136 before beginning the reception of the compound object, whether the 137 object is of interest or not, based on the information that may be 138 provided in the meta-data. Therefore this document discusses 139 additional techniques that may be used to mitigate this limitation. 140 When use-cases require that each receiver download the whole set of 141 objects sent in the session (e.g., with mirroring tools), this 142 limitation is not considered a problem. 144 FCAST is expected to work in many different environments and is 145 designed to be flexible. The service provided by FCAST can differ 146 according to the exact conditions FCAST is used, like the presence or 147 not of reception feedbacks. For example, environments exist where no 148 feedback is possible with FCAST/ALC, which guarantees a maximum 149 scalability but at the same time may reduce transmission reliability. 150 Section 6 discusses such operational considerations in detail. 152 Finally, Section 5 provides the guidance for compliant implementation 153 of the specification and identifies those features that are optional. 155 1.1. Requirements Notation 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 1.2. Definitions, Notations and Abbreviations 163 This document uses the following definitions: 165 FCAST/ALC: denotes the FCAST application running on top of the ALC/ 166 LCT reliable transport protocol; 168 FCAST/NORM: denotes the FCAST application running on top of the NORM 169 reliable transport protocol; 171 FCAST: denotes either FCAST/ALC or FCAST/NORM; 173 Compound Object: denotes an ALC or NORM transport object composed of 174 the Compound Object Header (Section 2.1), including any meta- 175 data, and the content of the original application object 176 (e.g., a file); 178 Carousel: denotes the process of sending Compound Objects 179 implemented by a FCAST sender; 181 Carousel Instance: denotes a fixed set of registered Compound 182 Objects that are sent by the carousel during a certain number 183 of cycles. Whenever Compound Objects need to be added or 184 removed, a new Carousel Instance is defined; 186 Carousel Instance Descriptor (CID): denotes a special object that 187 lists the Compound Objects that comprise a given Carousel 188 Instance; 190 Carousel Instance IDentifier (CIID): numeric value that identifies a 191 Carousel Instance. 193 Carousel Cycle: denotes a transmission round within which all the 194 Compound Objects registered in the Carousel Instance are 195 transmitted a certain number of times. By default, Compound 196 Objects are transmitted once per cycle, but higher values are 197 possible, that might differ on a per-object basis; 199 Transport Object Identifier (TOI): denotes the numeric identifier 200 associated to a specific object by the underlying transport 201 protocol. In the case of ALC, this corresponds to the TOI 202 described in [RFC5651]. In the case of NORM, this corresponds 203 to the NormTransportId described in [RFC5740]. 205 FEC Object Transmission Information (FEC OTI): FEC information 206 associated with an object and that is essential for the FEC 207 decoder to decode a specific object. 209 2. FCAST Data Formats 211 This section details the various data formats used by FCAST. 213 2.1. Compound Object Format 215 In an FCAST session, Compound Objects are constructed by prepending 216 the Compound Object Header (which contains the meta-data of the 217 object) before the original object data content (see Section 3.2). 218 Figure 1 illustrates the associated Compound Object header format. 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 223 |Ver| Resvd |G|C| MDFmt | MDEnc | Checksum | | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 225 | Compound Object Header Length | h 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| d 227 | Object Meta-Data (variable length) | r 228 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 229 | | Padding (optional) | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 231 | | 232 . Object Data (optional, variable length) . 233 . . 234 . . 236 Figure 1: Compound Object Format. 238 The Compound Object Header fields are: 240 +------------+------------------------------------------------------+ 241 | Field | Description | 242 +------------+------------------------------------------------------+ 243 | Version | 2-bit field that MUST be set to 0 in this | 244 | | specification and indicates the protocol version | 245 | | number. | 246 | Reserved | 4-bit field that MUST be set to 0 in this | 247 | | specification and is reserved for future use. | 248 | | Receivers MUST ignore this field. | 249 | G | 1-bit field that, when set to 1, indicates that the | 250 | | checksum encompasses the whole Compound Object | 251 | | (Global checksum). When set to 0, this field | 252 | | indicates that the checksum encompasses only the | 253 | | Compound Object header. | 254 | C | 1-bit field that, when set to 1, indicates the | 255 | | object is a Carousel Instance Descriptor (CID). | 256 | | When set to 0, this field indicates that the | 257 | | transported object is a standard object. | 258 | Meta-Data | 4-bit field that defines the format of the object | 259 | Format | meta-data (see Section 7). An HTTP/1.1 | 260 | (MDFmt) | metainformation format [RFC2616] MUST be supported | 261 | | and is associated to value 0. Other formats (e.g., | 262 | | XML) MAY be defined in the future. | 263 | Meta-Data | 4-bit field that defines the optional encoding of | 264 | Encoding | the Object Meta-Data field (see Section 7). By | 265 | (MDEnc) | default, a plain text encoding is used and is | 266 | | associated to value 0. GZIP encoding MUST also be | 267 | | supported and is associated to value 1. Other | 268 | | encodings MAY be defined in the future. | 269 | Checksum | 16-bit field that contains the checksum computed | 270 | | over either the whole Compound Object (when G is set | 271 | | to 1), or over the Compound Object header (when G is | 272 | | set to 0), using the Internet checksum algorithm | 273 | | specified in [RFC1071]. More precisely, the | 274 | | checksum field is the 16-bit one's complement of the | 275 | | one's complement sum of all 16-bit words to be | 276 | | considered. If a segment contains an odd number of | 277 | | octets to be checksummed, the last octet is padded | 278 | | on the right with zeros to form a 16-bit word for | 279 | | checksum purposes (this pad is not transmitted). | 280 | | While computing the checksum, the checksum field | 281 | | itself is set to zero. | 282 | Compound | 32-bit field indicating total length (in bytes) of | 283 | Object | all fields of the Compound Object Header, except the | 284 | Header | optional padding. A header length field set to | 285 | Length | value 8 means that there is no meta-data included. | 286 | | When this size is not multiple to 32-bits words and | 287 | | when the Compound Object Header is followed by a non | 288 | | null Compound Object Data, padding MUST be added. | 289 | | It should be noted that the meta-data field maximum | 290 | | size is equal to (2^32 - 8) bytes. | 291 | Object | Variable length field that contains the meta-data | 292 | Meta-Data | associated to the object. The format and encoding | 293 | | of this field are defined respectively by the MDFmt | 294 | | and MDEnc fields. With the default HTTP/1.1 format | 295 | | and plain text encoding, the Meta-Data is | 296 | | NULL-terminated plain text that follows the "TYPE" | 297 | | ":" "VALUE" "" format used in HTTP/1.1 for | 298 | | metainformation [RFC2616]. The various meta-data | 299 | | items can appear in any order. The associated | 300 | | string, when non empty, MUST be NULL-terminated. | 301 | | When no meta-data is communicated, this field MUST | 302 | | be empty and the Compound Object Header Length MUST | 303 | | be equal to 8. | 304 | Padding | Optional, variable length field of zero-value bytes | 305 | | to align the start of the Object Data to 32-bit | 306 | | boundary. Padding is only used when the Compound | 307 | | Object Header Length value, in bytes, is not | 308 | | multiple of 4 and when the Compound Object Header is | 309 | | followed by non null Compound Object Data. | 310 +------------+------------------------------------------------------+ 312 The Compound Object Header is then followed by the Object Data, i.e., 313 the original object possibly encoded by FCAST. Note that the length 314 of this content is the transported object length (e.g., as specified 315 by the FEC OTI) minus the Compound Object Header Length and optional 316 padding if any. 318 2.2. Carousel Instance Descriptor Format 320 In an FCAST session, a Carousel Instance Descriptor (CID) MAY be sent 321 in order to carry the list of Compound Objects that are part of a 322 given Carousel Instance (see Section 3.5). The format of the CID, 323 that is sent as a special Compound Object, is given in Figure 2. 324 Being a special case of Compound Object, this format is in line with 325 the format described in Section 2.1. 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 330 |Ver| Resvd |G|C| MDFmt | MDEnc | Checksum | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 332 | Compound Object Header Length | h 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| d 334 | Object Meta-Data (variable length) | r 335 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 336 | | Padding (optional) | | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 338 . . ^ 339 . Object List (variable length) . | 340 . . o 341 . +-+-+-+-+-+-+-+-+ b 342 . | j 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 345 Figure 2: Carousel Instance Descriptor Format. 347 Because the CID is transmitted as a special Compound Object, the 348 following CID-specific meta-data entries are defined: 350 o Fcast-CID-Complete: when set to 1, it indicates that no new object 351 in addition to the ones whose TOI are specified in this CID, or 352 the ones that have been specified in the previous CID(s), will be 353 sent in the future. Otherwise it MUST be set to 0. This entry is 354 optional. If absent, a receiver MUST conclude that the session is 355 complete. 357 o Fcast-CID-ID: this entry contains the Carousel Instance 358 IDentifier, or CIID. It starts from 0 and is incremented by 1 for 359 each new carousel instance. This entry is optional if the FCAST 360 session consists of a single, complete, carousel instance. In all 361 other cases, this entry MUST be defined. In particular, the CIID 362 is used by the TOI equivalence mechanism thanks to which any 363 object is uniquely identified, even if the TOI is updated (e.g., 364 after re-enqueuing the object with NORM). The Fcast-CID-ID value 365 can also be useful to detect possible gaps in the Carousel 366 Instances, for instance caused by long disconnection periods. 367 Finally, it can also be useful to avoid problems when TOI wrapping 368 to 0 takes place to differentiate the various incarnations of the 369 TOIs if need be. 371 The motivation for making the Fcast-CID-Complete and Fcast-CID-ID 372 entries optional is to simplify the simple case of a session 373 consisting of a single, complete, carousel instance, with an Object 374 List given in plain text, without any content encoding. In that 375 case, the CID does not need to contain any meta-data entry. 377 The following standard meta-data entry types are also used 378 (Section 3.3): 380 o Content-Length: it specifies the size of the object list, before 381 any content encoding (if any). 383 o Content-Encoding: it specifies the optional encoding of the object 384 list, performed by FCAST. For instance: 385 Content-Encoding: gzip 386 indicates that the Object List field has been encoded with GZIP 387 [RFC1952]. If there is no Content-Encoding entry, the receiver 388 MUST assume that the Object List field is plain text (default). 389 The support of GZIP encoding, in addition to the plain text form, 390 is REQUIRED. The Content-Encoding entry MAY be used to indicate 391 other encoding types to support non-standard FCAST implementation 392 or future extended specifications. 394 An empty Object List is valid and indicates that the current carousel 395 instance does not include any objects (Section 3.5). This can be 396 specified by using the following meta-data entry: 397 Content-Length: 0 398 or simply by leaving the Object List empty. In both cases, padding 399 MUST NOT be used and consequently the transported object length 400 (e.g., as specified by the FEC OTI) minus the Compound Object Header 401 Length equals zero. 403 The non-encoded (i.e., plain text) Object List, when non empty, is a 404 NULL-terminated ASCII string. It can contain two things: 406 o a list of TOI values, and 408 o a list of TOI equivalences; 410 A list of TOIs included in the current carousel instance is specified 411 as an ASCII string containing comma-delimited individual TOI values 412 and/or TOI intervals. Inidividual TOIs consist of a single integer 413 value while TOI intervals are a hyphen-delimited pair of TOI values 414 to indicate a inclusive range of TOI values (e.g., "1,2,4-6" would 415 indicate the list of TOI values of 1,2,4,5, and 6). For a TOI 416 Interval indicated by ""TOI_a-TOI_b", the 'TOI_a' value MUST be 417 strictly inferior to the 'TOI_b' value. If a TOI wrapping to 0 418 occurs in an interval, then two TOI intervals MUST be specified, 419 TOI_a-MAX_TOI and 0-TOI_b. 421 This string CAN also contain the TOI equivalences, if any. The 422 format is a comma-separated list of equivalence TOI value pairs with 423 a delimiting equals size '=' to indicate the equivalence assignment 424 (e.g., " newTOI "=" 1stTOI "/" 1stCIID "). Each equivalence 425 indicates that the new TOI, for the current Carousel Instance, is 426 equivalent to (i.e., refers to the same object as) the provided 427 identifier, 1stTOI, for the Carousel Instance of ID 1stCIID. In the 428 case of the NORM protocol where NormTransportId values need to 429 monotonically increase for NACK-based protocol operation, this allows 430 an object from a prior Carousel Instance to be reincluded in a 431 subsequent Carousel Instance with the receiver set informed of the 432 equivalence so that unnecessary retransmission requests can be 433 avoided. 435 The ABNF specification is the following: 436 cid-list = *(list-elem *( "," list-elem)) 437 list-elem = toi-elem / toieq-elem 438 toi-elem = toi-value / toi-interval 439 toi-value = 1*DIGIT 440 toi-interval = toi-value "-" toi-value 441 ; additionally, the first toi-value MUST be 442 ; strictly inferior to the second toi-value 443 toieq-elem = "(" toi-value "=" toi-value "/" ciid-value ")" 444 ciid-value = 1*DIGIT 445 DIGIT = %x30-39 446 ; a digit between O and 9, inclusive 448 For readability purposes and to simplify processing, the TOI values 449 in the list MUST be given in increasing order handling wrap of the 450 TOI space appropriately. TOI equivalence elements MUST be grouped 451 together at the end of the list in increasing newTOI order. 452 Specifying a TOI equivalence for a given newTOI relieves the sender 453 from specifying newTOI explicitly in the TOI list. A receiver MUST 454 be able to handle situations where the same TOI appears both in the 455 TOI value and TOI equivalence lists. Finally, a given TOI value or 456 TOI equivalence item MUST NOT be included multiple times in either 457 list. 459 For instance, the following object list specifies that the current 460 Carousel Instance is composed of 8 objects, and that TOIs 100 to 104 461 are equivalent to the TOIs 10 to 14 of Carousel Instance ID 2 and 462 refer to the same objects: 464 97,98,99,(100=10/2),(101=11/2),(102=12/2),(103=13/2),(104=14/2) 466 or equivalently: 468 97-104,(100=10/2),(101=11/2),(102=12/2),(103=13/2),(104=14/2) 470 3. FCAST Principles 472 This section details the principles of FCAST. 474 3.1. FCAST Content Delivery Service 476 The basic goal of FCAST is to transmit objects to a group of 477 receivers in a reliable way, where the receiver set may be restricted 478 to a single receiver or may include possibly a very large number of 479 receivers. FCAST supports two forms of operation: 481 1. FCAST/ALC, where the FCAST application works on top of the ALC/ 482 LCT reliable multicast transport protocol, without any feedback 483 from the receivers, and 485 2. FCAST/NORM, where the FCAST application works on top of the NORM 486 reliable multicast transport protocol, that requires positive/ 487 negative acknowledgements from the receivers. 489 This specification is designed such that both forms of operation 490 share as much commonality as possible. Section 6 discusses some 491 operational aspects and the content delivery service that is provided 492 by FCAST for a given use-case. 494 3.2. Meta-Data Transmission 496 FCAST carries meta-data elements by prepending them to the object 497 they refer to. As a result, a Compound Object is created that is 498 composed of a header followed by the original object data. This 499 header is itself composed of the meta-data as well as several fields, 500 for instance to indicate the boundaries between the various parts of 501 this Compound Object (Figure 3). 503 <------------------------ Compound Object -----------------------> 504 +-------------------------+--------------------------------------+ 505 | Compound Object Header | Object Data | 506 | (can include meta-data) | (can be encoded by FCAST) | 507 +-------------------------+--------------------------------------+ 509 Figure 3: Compound Object composition. 511 Attaching the meta-data to the object is an efficient solution, since 512 it guaranties that meta-data are received along with the associated 513 object, and it allows the transport of the meta-data to benefit from 514 any transport-layer erasure protection of the Compound Object (e.g., 515 using FEC encoding and/or NACK-based repair). However a limit of 516 this scheme is that a client does not know the meta-data of an object 517 before beginning its reception, and in case of erasures affecting the 518 meta-data, not until the object decoding is completed. The details 519 of course depend upon the transport protocol and the FEC code used. 521 Appendix B describes extensions that provide additional means to 522 carry meta-data, e.g., to communicate meta-data ahead of time. 524 3.3. Meta-Data Content 526 A compliant FCAST implementation MUST support the following meta-data 527 items: 529 o Content-Location: the URI of the object, which gives the name and 530 location of the object; 532 o Content-Type: a string that contains the MIME type of the object; 534 o Content-Length: an unsigned 64-bit integer that contains the size 535 of the initial object, before any content encoding (if any) and 536 without considering the Compound Object header. Note that the use 537 of certain FEC schemes MAY further limit the maximum value of the 538 object; 540 o Content-Encoding: a string that contains the optional encoding of 541 the object performed by FCAST. If there is no Content-Encoding 542 entry, the receiver MUST assume that the object is not encoded 543 (default). The support of GZIP encoding, or any other solution, 544 remains optional. 546 o Content-MD5: a binary content coded as "base64" that contains the 547 MD5 message digest of the object in order to check its integrity. 548 This digest is meant to protect from transmission and processing 549 errors, not from deliberate attacks by an intelligent attacker 550 (see Section 4). This digest only protects the object, not the 551 header, and therefore not the meta-data. A separate checksum is 552 provided to that purpose (Section 2.1); 554 A compliant FCAST implementation MUST support the following meta-data 555 types that can be used for dealing with very large objects (e.g., 556 that largely exceed the working memory of a receiver). In that case 557 the initial object is split into several slices. Each slice is 558 considered as a separate sub-object and the meta-data associated to 559 each sub-object MUST include the following entries: 561 o Fcast-Obj-Slice-Nb: an unsigned 32-bit integer that contains the 562 total number of slices. A value greater than 1 indicates that 563 this object is the result of a split of the original object; 565 o Fcast-Obj-Slice-Idx: an unsigned 32-bit integer that contains the 566 slice index (in the {0 .. SliceNb - 1} interval); 568 o Fcast-Obj-Slice-Offset: an unsigned 64-bit integer that contains 569 the offset at which this slice starts within the original object; 571 Future standards actions MAY extend the set of meta-data items 572 supported by FCAST. 574 3.4. Carousel Transmission 576 A set of FCAST Compound Objects scheduled for transmission are 577 considered a logical "Carousel". A given "Carousel Instance" is 578 comprised of a fixed set of Compound Objects. Whenever the FCAST 579 application needs to add new Compound Objects to or remove old 580 Compound Objects from the transmission set, a new Carousel Instance 581 is defined since the set of Compound Objects changes. Because of the 582 native object multiplexing capability of both ALC and NORM, sender 583 and receiver(s) are both capable to multiplex and demultiplex FCAST 584 Compound Objects. 586 For a given Carousel Instance, one or more transmission cycles are 587 possible. During each cycle, all of the Compound Objects comprising 588 the Carousel are sent. By default, each object is transmitted once 589 per cycle. However, in order to allow different levels of priority, 590 some objects MAY be transmitted more often that others during a 591 cycle, and/or benefit from higher FEC protection than others. For 592 example, this can be the case for the CID objects (Section 3.5) where 593 extra protection can benefit overall carousel integrity. For some 594 FCAST usage (e.g., a unidirectional "push" mode), a Carousel Instance 595 may be sent in a single transmission cycle. In other cases it may be 596 conveyed in a large number of transmission cycles (e.g., in "on- 597 demand" mode, where objects are made available for download during a 598 long period of time). 600 3.5. Carousel Instance Descriptor Special Object 602 The FCAST sender CAN transmit an OPTIONAL Carousel Instance 603 Descriptor (CID). The CID carries the list of the Compound Objects 604 that are part of a given Carousel Instance, by specifying their 605 respective Transmission Object Identifiers (TOI). However the CID 606 does not describe the objects themselves (i.e., there is no meta- 607 data). Additionally, the CID MAY include a "Complete" flag that is 608 used to indicate that no further modification to the enclosed list 609 will be done in the future. Finally, the CID MAY include a Carousel 610 Instance ID (CIID) that identifies the Carousel Instance it pertains 611 to. These aspects are discussed in Section 2.2. 613 There is no reserved TOI value for the CID Compound Object itself, 614 since this special object is regarded by ALC/LCT or NORM as a 615 standard object. On the contrary, the nature of this object (CID) is 616 indicated by means of a specific Compound Object header field (the 617 "I" flag) so that it can be recognized and processed by the FCAST 618 application as needed. A direct consequence is the following: since 619 a receiver does not know in advance which TOI will be used for the 620 following CID (in case of a dynamic session), he MUST NOT filter out 621 packets that are not in the current CID's TOI list. Said 622 differently, the goal of CID is not to setup ALC or NORM packet 623 filters (this mechanism would not be secure in any case). 625 The use of a CID remains OPTIONAL. If it is not used, then the 626 clients progressively learn what files are part of the carousel 627 instance by receiving ALC or NORM packets with new TOIs. However 628 using a CID has several benefits: 630 o When the "Complete" flag is set (if ever), the receivers know when 631 they can leave the session, i.e., when they have received all the 632 objects that are part of the last carousel instance of this 633 delivery session; 635 o In case of a session with a dynamic set of objects, the sender can 636 reliably inform the receivers that some objects have been removed 637 from the carousel with the CID. This solution is more robust than 638 the "Close Object flag (B)" of ALC/LCT since a client with an 639 intermittent connectivity might loose all the packets containing 640 this B flag. And while NORM provides a robust object cancellation 641 mechanism in the form of its NORM_CMD(SQUELCH) message in response 642 to receiver NACK repair requests, the use of the CID provides an 643 additional means for receivers to learn of objects for which it is 644 futile to request repair; 646 o The TOI equivalence (Section 3.6) can be signaled with the CID. 647 This is often preferable to the alternative solution where the 648 equivalence is identified by examining the object meta-data, 649 especially in case of erasures. 651 During idle periods, when the carousel instance does not contain any 652 object, a CID with an empty TOI list MAY be transmitted. In that 653 case, a new carousel instance ID MUST be used to differentiate this 654 (empty) carousel instance from the other ones. This mechanism can be 655 useful to inform the receivers that: 657 o all the previously sent objects have been removed from the 658 carousel. It therefore improves the FCAST robustness even during 659 "idle" period; 661 o the session is still active even if there is currently no content 662 being sent. Said differently, it can be used as a heartbeat 663 mechanism. If the "Complete" flag has not been set, it implicitly 664 informs the receivers that new objects MAY be sent in the future; 666 3.6. Compound Object Identification 668 The FCAST Compound Objects are directly associated with the object- 669 based transport service that the ALC and NORM protocols provide. In 670 each of these protocols, the messages containing transport object 671 content are labeled with a numeric transport object identifier (i.e., 672 the ALC TOI and the NORM NormTransportId). For the purposes of this 673 document, this identifier in either case (ALC or NORM) is referred to 674 as the TOI. 676 There are several differences between ALC and NORM: 678 o the ALC use of TOI is rather flexible, since several TOI field 679 sizes are possible (from 16 to 112 bits), since this size can be 680 changed at any time, on a per-packet basis, and since the TOI 681 management is totally free as long as each object is associated to 682 a unique TOI (if no wraparound happened); 684 o the NORM use of TOI is more directive, since the TOI field is 16 685 bit long and since TOIs MUST be managed sequentially; 687 In both NORM and ALC, it is possible that the transport 688 identification space may eventually wrap for long-lived sessions 689 (especially with NORM where this phenomenon is expected to happen 690 more frequently). This can possibly introduce some ambiguity in 691 FCAST object identification if a sender retains some older objects in 692 newer Carousel Instances with updated object sets. To avoid 693 ambiguity the active TOIs (i.e., the TOIs corresponding to objects 694 being transmitted) can only occupy half of the TOI sequence space. 695 If an old object, whose TOI has fallen outside the current window, 696 needs to be transmitted again, a new TOI must be used for it. In 697 case of NORM, this constraint limits to 32768 the maximum number of 698 objects that can be part of any carousel instance. In order to allow 699 receivers to properly combine the transport packets with a newly- 700 assigned TOI to those of associated to the previously-assigned TOI, a 701 mechanism is required to equate the objects with the new and the old 702 TOIs. 704 The preferred mechanism consists in signaling, within the CID, that 705 the newly assigned TOI, for the current Carousel Instance, is 706 equivalent to the TOI used within a previous Carousel Instance. By 707 convention, the reference tuple for any object is the {TOI; CI ID} 708 tuple used for its first transmission within a Carousel Instance. 710 This tuple MUST be used whenever a TOI equivalence is provided. 712 An alternative solution, when meta-data can be processed rapidly 713 (e.g., by using NORM-INFO messages), consists for the receiver in 714 identifying that both objects are the same, after examining the meta- 715 data. The receiver can then take appropriate measures. 717 3.7. FCAST Sender Behavior 719 The following operations MAY take place at a sender: 721 1. The user (or another application) selects a set of objects (e.g., 722 files) to deliver and submits them, along with their meta-data, 723 to the FCAST application; 725 2. For each object, FCAST creates the Compound Object and registers 726 this latter in the carousel instance; 728 3. The user then informs FCAST that all the objects of the set have 729 been submitted. If the user knows that no new object will be 730 submitted in the future (i.e., if the session's content is now 731 complete), the user informs FCAST. Finally, the user specifies 732 how many transmission cycles are desired (this number may be 733 infinite); 735 4. At this point, the FCAST application knows the full list of 736 Compound Objects that are part of the Carousel Instance and can 737 create a CID if desired, possibly with the complete flag set; 739 5. The FCAST application can now define a transmission schedule of 740 these Compound Objects, including the optional CID. This 741 schedule defines in which order the packets of the various 742 Compound Objects should be sent. This document does not specify 743 any scheme. This is left to the developer within the provisions 744 of the underlying ALC or NORM protocol used and the knowledge of 745 the target use-case. 747 6. The FCAST application then starts the carousel transmission, for 748 the number of cycles specified. Transmissions take place until: 750 * the desired number of transmission cycles has been reached, or 752 * the user wants to prematurely stop the transmissions, or 754 * the user wants to add one or several new objects to the 755 carousel, or on the contrary wants to remove old objects from 756 the carousel. In that case a new carousel instance must be 757 created. 759 7. If the session is not finished, then continue at Step 1 above; 761 3.8. FCAST Receiver Behavior 763 The following operations MAY take place at a receiver: 765 1. The receiver joins the session and collects incoming packets; 767 2. If the header portion of a Compound Object is entirely received 768 (which may happen before receiving the entire object with some 769 ALC/NORM configurations), or if the meta-data is sent by means of 770 another mechanism prior to the object, the receiver processes the 771 meta-data and chooses to continue to receive the object content 772 or not; 774 3. When a Compound Object has been entirely received, the receiver 775 processes the header, retrieves the object meta-data, perhaps 776 decodes the meta-data, and processes the object accordingly; 778 4. When a CID is received, which is indicated by the 'C' flag set in 779 the Compound Object header, the receiver decodes the CID, and 780 retrieves the list of objects that are part of the current 781 carousel instance. This list CAN be used to remove objects sent 782 in a previous carousel instance that might not have been totally 783 decoded and that are no longer part of the current carousel 784 instance; 786 5. When a CID is received, the receiver also retrieves the list of 787 TOI equivalences, if any, and takes appropriate measures, for 788 instance by informing the transport layer; 790 6. When a receiver has received a CID with the "Complete" flag set, 791 and has successfully received all the objects of the current 792 carousel instance, it can safely exit from the current FCAST 793 session; 795 7. Otherwise continue at Step 2 above. 797 4. Security Considerations 799 4.1. Problem Statement 801 A content delivery system is potentially subject to attacks. Attacks 802 may target: 804 o the network (to compromise the routing infrastructure, e.g., by 805 creating congestion), 807 o the Content Delivery Protocol (CDP) (e.g., to compromise the 808 normal behavior of FCAST), or 810 o the content itself (e.g., to corrupt the objects being 811 transmitted). 813 These attacks can be launched either: 815 o against the data flow itself (e.g., by sending forged packets), 817 o against the session control parameters (e.g., by corrupting the 818 session description, the CID, the object meta-data, or the ALC/LCT 819 control parameters), that are sent either in-band or out-of-band, 820 or 822 o against some associated building blocks (e.g., the congestion 823 control component). 825 In the following sections we provide more details on these possible 826 attacks and sketch some possible counter-measures. We finally 827 provide recommendations in Section 4.5. 829 4.2. Attacks Against the Data Flow 831 Let us consider attacks against the data flow first. At least, the 832 following types of attacks exist: 834 o attacks that are meant to give access to a confidential object 835 (e.g., in case of a non-free content) and 837 o attacks that try to corrupt the object being transmitted (e.g., to 838 inject malicious code within an object, or to prevent a receiver 839 from using an object, which is a kind of Denial of Service (DoS)). 841 4.2.1. Access to Confidential Objects 843 Access control to the object being transmitted is typically provided 844 by means of encryption. This encryption can be done over the whole 845 object (e.g., by the content provider, before submitting the object 846 to FCAST), or be done on a packet per packet basis (e.g., when IPsec/ 847 ESP is used [RFC4303], see Section 4.5). If confidentiality is a 848 concern, it is RECOMMENDED that one of these solutions be used. 850 4.2.2. Object Corruption 852 Protection against corruptions (e.g., if an attacker sends forged 853 packets) is achieved by means of a content integrity verification/ 854 sender authentication scheme. This service can be provided at the 855 object level, but in that case a receiver has no way to identify 856 which symbol(s) is(are) corrupted if the object is detected as 857 corrupted. This service can also be provided at the packet level. 858 In this case, after removing all corrupted packets, the file may be 859 in some cases recovered. Several techniques can provide this content 860 integrity/sender authentication service: 862 o at the object level, the object can be digitally signed, for 863 instance by using RSASSA-PKCS1-v1_5 [RFC3447]. This signature 864 enables a receiver to check the object integrity, once this latter 865 has been fully decoded. Even if digital signatures are 866 computationally expensive, this calculation occurs only once per 867 object, which is usually acceptable; 869 o at the packet level, each packet can be digitally signed 870 [RFC6584]. A major limitation is the high computational and 871 transmission overheads that this solution requires. To avoid this 872 problem, the signature may span a set of packets (instead of a 873 single one) in order to amortize the signature calculation. But 874 if a single packets is missing, the integrity of the whole set 875 cannot be checked; 877 o at the packet level, a Group Message Authentication Code (MAC) 878 [RFC2104][RFC6584] scheme can be used, for instance by using HMAC- 879 SHA-256 with a secret key shared by all the group members, senders 880 and receivers. This technique creates a cryptographically secured 881 digest of a packet that is sent along with the packet. The Group 882 MAC scheme does not create prohibitive processing load nor 883 transmission overhead, but it has a major limitation: it only 884 provides a group authentication/integrity service since all group 885 members share the same secret group key, which means that each 886 member can send a forged packet. It is therefore restricted to 887 situations where group members are fully trusted (or in 888 association with another technique as a pre-check); 890 o at the packet level, Timed Efficient Stream Loss-Tolerant 891 Authentication (TESLA) [RFC4082][RFC5776] is an attractive 892 solution that is robust to losses, provides a true authentication/ 893 integrity service, and does not create any prohibitive processing 894 load or transmission overhead. Yet checking a packet requires a 895 small delay (a second or more) after its reception; 897 o at the packet level, IPsec/ESP [RFC4303] can be used to check the 898 integrity and authenticate the sender of all the packets being 899 exchanged in a session (see Section 4.5). 901 Techniques relying on public key cryptography (digital signatures and 902 TESLA during the bootstrap process, when used) require that public 903 keys be securely associated to the entities. This can be achieved by 904 a Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by 905 pre-distributing securely the public keys of each group member. 907 Techniques relying on symmetric key cryptography (Group MAC) require 908 that a secret key be shared by all group members. This can be 909 achieved by means of a group key management protocol, or simply by 910 pre-distributing securely the secret key (but this manual solution 911 has many limitations). 913 It is up to the developer and deployer, who know the security 914 requirements and features of the target application area, to define 915 which solution is the most appropriate. In any case, whenever there 916 is any concern of the threat of file corruption, it is RECOMMENDED 917 that at least one of these techniques be used. 919 4.3. Attacks Against the Session Control Parameters and Associated 920 Building Blocks 922 Let us now consider attacks against the session control parameters 923 and the associated building blocks. The attacker has at least the 924 following opportunities to launch an attack: 926 o the attack can target the session description, 928 o the attack can target the FCAST CID, 930 o the attack can target the meta-data of an object, 932 o the attack can target the ALC/LCT parameters, carried within the 933 LCT header or 935 o the attack can target the FCAST associated building blocks, for 936 instance the multiple rate congestion control protocol. 938 The consequences of these attacks are potentially serious, since they 939 can compromise the behavior of content delivery system or even 940 compromise the network itself. 942 4.3.1. Attacks Against the Session Description 944 An FCAST receiver may potentially obtain an incorrect Session 945 Description for the session. The consequence of this is that 946 legitimate receivers with the wrong Session Description are unable to 947 correctly receive the session content, or that receivers 948 inadvertently try to receive at a much higher rate than they are 949 capable of, thereby possibly disrupting other traffic in the network. 951 To avoid these problems, it is RECOMMENDED that measures be taken to 952 prevent receivers from accepting incorrect Session Descriptions. One 953 such measure is the sender authentication to ensure that receivers 954 only accept legitimate Session Descriptions from authorized senders. 955 How these measures are achieved is outside the scope of this document 956 since this session description is usually carried out-of-band. 958 4.3.2. Attacks Against the FCAST CID 960 Corrupting the FCAST CID is one way to create a Denial of Service 961 attack. For example, the attacker can set the "Complete" flag to 962 make the receivers believe that no further modification will be done. 964 It is therefore RECOMMENDED that measures be taken to guarantee the 965 integrity and to check the sender's identity of the CID. To that 966 purpose, one of the counter-measures mentioned above (Section 4.2.2) 967 SHOULD be used. These measures will either be applied on a packet 968 level, or globally over the whole CID object. When there is no 969 packet level integrity verification scheme, it is RECOMMENDED to 970 digitally sign the CID. 972 4.3.3. Attacks Against the Object Meta-Data 974 Corrupting the object meta-data is another way to create a Denial of 975 Service attack. For example, the attacker changes the MD5 sum 976 associated to a file. This possibly leads a receiver to reject the 977 files received, no matter whether the files have been correctly 978 received or not. When the meta-data are appended to the object, 979 corrupting the meta-data means that the Compound Object will be 980 corrupted. 982 It is therefore RECOMMENDED that measures be taken to guarantee the 983 integrity and to check the sender's identity of the Compound Object. 984 To that purpose, one of the counter-measures mentioned above 985 (Section 4.2.2) SHOULD be used. These measures will either be 986 applied on a packet level, or globally over the whole Compound 987 Object. When there is no packet level integrity verification scheme, 988 it is RECOMMENDED to digitally sign the Compound Object. 990 4.3.4. Attacks Against the ALC/LCT and NORM Parameters 992 By corrupting the ALC/LCT header (or header extensions) one can 993 execute attacks on the underlying ALC/LCT implementation. For 994 example, sending forged ALC packets with the Close Session flag (A) 995 set to one can lead the receiver to prematurely close the session. 996 Similarly, sending forged ALC packets with the Close Object flag (B) 997 set to one can lead the receiver to prematurely give up the reception 998 of an object. The same comments can be made for NORM. 1000 It is therefore RECOMMENDED that measures be taken to guarantee the 1001 integrity and to check the sender's identity of each ALC or NORM 1002 packet received. To that purpose, one of the counter-measures 1003 mentioned above (Section 4.2.2) SHOULD be used. 1005 4.3.5. Attacks Against the Associated Building Blocks 1007 Let us first focus on the congestion control building block that may 1008 be used in an ALC or NORM session. A receiver with an incorrect or 1009 corrupted implementation of the multiple rate congestion control 1010 building block may affect the health of the network in the path 1011 between the sender and the receiver. That may also affect the 1012 reception rates of other receivers who joined the session. 1014 When congestion control is applied with FCAST, it is therefore 1015 RECOMMENDED that receivers be required to identify themselves as 1016 legitimate before they receive the Session Description needed to join 1017 the session. If authenticating a receiver does not prevent this 1018 latter to launch an attack, it will enable the network operator to 1019 identify him and to take counter-measures. This authentication can 1020 be made either toward the network operator or the session sender (or 1021 a representative of the sender) in case of NORM. The details of how 1022 it is done are outside the scope of this document. 1024 When congestion control is applied with FCAST, it is also RECOMMENDED 1025 that a packet level authentication scheme be used, as explained in 1026 Section 4.2.2. Some of them, like TESLA, only provide a delayed 1027 authentication service, whereas congestion control requires a rapid 1028 reaction. It is therefore RECOMMENDED [RFC5775] that a receiver 1029 using TESLA quickly reduces its subscription level when the receiver 1030 believes that a congestion did occur, even if the packet has not yet 1031 been authenticated. Therefore TESLA will not prevent DoS attacks 1032 where an attacker makes the receiver believe that a congestion 1033 occurred. This is an issue for the receiver, but this will not 1034 compromise the network. Other authentication methods that do not 1035 feature this delayed authentication could be preferred, or a group 1036 MAC scheme could be used in parallel to TESLA to prevent attacks 1037 launched from outside of the group. 1039 4.4. Other Security Considerations 1041 Lastly, we note that the security considerations that apply to, and 1042 are described in, ALC [RFC5775], LCT [RFC5651], NORM [RFC5740] and 1043 FEC [RFC5052] also apply to FCAST as FCAST builds on those 1044 specifications. In addition, any security considerations that apply 1045 to any congestion control building block used in conjunction with 1046 FCAST also applies to FCAST. Finally, the security discussion of 1047 [I-D.ietf-rmt-sec-discussion] also applies here. 1049 4.5. Minimum Security Recommendations 1051 We now introduce a mandatory to implement but not necessarily to use 1052 security configuration, in the sense of [RFC3365]. Since FCAST/ALC 1053 relies on ALC/LCT, it inherits the "baseline secure ALC operation" of 1054 [RFC5775]. Similarly, since FCAST/NORM relies on NORM, it inherits 1055 the "baseline secure NORM operation" of [RFC5740]. More precisely, 1056 in both cases security is achieved by means of IPsec/ESP in transport 1057 mode. [RFC4303] explains that ESP can be used to potentially provide 1058 confidentiality, data origin authentication, content integrity, anti- 1059 replay and (limited) traffic flow confidentiality. [RFC5775] 1060 specifies that the data origin authentication, content integrity and 1061 anti-replay services SHALL be used, and that the confidentiality 1062 service is RECOMMENDED. If a short lived session MAY rely on manual 1063 keying, it is also RECOMMENDED that an automated key management 1064 scheme be used, especially in case of long lived sessions. 1066 Therefore, the RECOMMENDED solution for FCAST provides per-packet 1067 security, with data origin authentication, integrity verification and 1068 anti-replay. This is sufficient to prevent most of the in-band 1069 attacks listed above. If confidentiality is required, a per-packet 1070 encryption SHOULD also be used. 1072 5. Requirements for Compliant Implementations 1074 This section lists the features that any compliant FCAST/ALC or 1075 FCAST/NORM implementation MUST support, and those that remain 1076 OPTIONAL, e.g., in order to enable some optimizations for a given 1077 use-case, at a receiver. 1079 5.1. Requirements Related to the Object Meta-Data 1081 Meta-data transmission mechanisms: 1083 +-----------------------+-------------------------------------------+ 1084 | Feature | Status | 1085 +-----------------------+-------------------------------------------+ 1086 | meta-data | An FCAST sender MUST send meta-data with | 1087 | transmission using | the in-band mechanism provided by FCAST, | 1088 | FCAST's in-band | i.e., within the Compound Object header. | 1089 | mechanism | All the FCAST receivers MUST be able to | 1090 | | process meta-data sent with this FCAST | 1091 | | in-band mechanism. | 1092 | meta-data | In addition to the FCAST in-band | 1093 | transmission using | transmission of meta-data, an FCAST | 1094 | other mechanisms | sender MAY send a subset or all of the | 1095 | | meta-data using another mechanism. | 1096 | | Supporting this mechanism in a compliant | 1097 | | FCAST receiver is OPTIONAL, and its use | 1098 | | is OPTIONAL too. An FCAST receiver MAY | 1099 | | support this mechanism and take advantage | 1100 | | of the meta-data sent in this way. If it | 1101 | | is not the case, the FCAST receiver will | 1102 | | anyway receive and process meta-data sent | 1103 | | in-bound. See Annex Appendix B. | 1104 +-----------------------+-------------------------------------------+ 1106 Meta-data format and encoding: 1108 +-----------------------+-------------------------------------------+ 1109 | Feature | Status | 1110 +-----------------------+-------------------------------------------+ 1111 | Meta-Data Format | All FCAST implementations MUST support an | 1112 | (MDFmt field) | HTTP/1.1 metainformation format | 1113 | | [RFC2616]. Other formats (e.g., XML) MAY | 1114 | | be defined in the future. | 1115 | Meta-Data Encoding | All FCAST implementations MUST support | 1116 | (MDEnc field) | both a plain text and a GZIP encoding | 1117 | | [RFC1952] of the Object Meta-Data field. | 1118 | | Other encodings MAY be defined in the | 1119 | | future. | 1120 +-----------------------+-------------------------------------------+ 1122 Meta-data items (Section 3.3): 1124 +------------------------+-------------------+ 1125 | Feature | Status | 1126 +------------------------+-------------------+ 1127 | Content-Location | MUST be supported | 1128 | Content-Type | MUST be supported | 1129 | Content-Length | MUST be supported | 1130 | Content-Encoding | MUST be supported | 1131 | Content-MD5 | MUST be supported | 1132 | Fcast-Obj-Slice-Nb | MUST be supported | 1133 | Fcast-Obj-Slice-Idx | MUST be supported | 1134 | Fcast-Obj-Slice-Offset | MUST be supported | 1135 +------------------------+-------------------+ 1137 5.2. Requirements Related to the Carousel Instance Descriptor (CID) 1138 Mechanism 1140 Any compliant FCAST implementation MUST support the CID mechanism, in 1141 order to list the Compound Objects that are part of a given Carousel 1142 Instance. However its use is OPTIONAL. 1144 6. Operational Considerations 1146 FCAST is compatible with any congestion control protocol designed for 1147 ALC/LCT or NORM. However, depending on the use-case, the data flow 1148 generated by the FCAST application might not be constant, but instead 1149 be bursty in nature. Similarly, depending on the use-case, an FCAST 1150 session might be very short. Whether and how this will impact the 1151 congestion control protocol is out of the scope of the present 1152 document. 1154 FCAST is compatible with any security mechanism designed for ALC/LCT 1155 or NORM. The use of a security scheme is strongly RECOMMENDED (see 1156 Section 4). 1158 FCAST is compatible with any FEC scheme designed for ALC/LCT or NORM. 1159 Whether FEC is used or not, and the kind of FEC scheme used, is to 1160 some extent transparent to FCAST. 1162 FCAST is compatible with both IPv4 and IPv6. Nothing in the FCAST 1163 specification has any implication on the source or destination IP 1164 address type. 1166 The delivery service provided by FCAST might be fully reliable, or 1167 only partially reliable depending upon: 1169 o the way ALC or NORM is used (e.g., whether FEC encoding and/or 1170 NACK-based repair requests are used or not), 1172 o the way the FCAST carousel is used (e.g., whether the objects are 1173 made available for a long time span or not), and 1175 o the way in which FCAST itself is employed (e.g., whether there is 1176 a session control application that might automatically extend an 1177 existing FCAST session until all receivers have received the 1178 transmitted content). 1180 The receiver set MAY be restricted to a single receiver or MAY 1181 include possibly a very large number of receivers. While the choice 1182 of the underlying transport protocol (i.e., ALC or NORM) and its 1183 parameters may limit the practical receiver group size, nothing in 1184 FCAST itself limits it. For instance, if FCAST/ALC is used on top of 1185 purely unidirectional transport channels, with no feedback 1186 information at all, which is the default mode of operation, then the 1187 scalability is maximum since neither FCAST, nor ALC, UDP or IP 1188 generates any feedback message. On the contrary, the FCAST/NORM 1189 scalability is typically limited by NORM scalability itself. 1190 Similarly, if FCAST is used along with a session control application 1191 that collects reception information from the receivers, then this 1192 session control application may limit the scalability of the global 1193 object delivery system. This situation can of course be mitigated by 1194 using a hierarchy of feedback message aggregators or servers. The 1195 details of this are out of the scope of the present document. 1197 The content of a carousel instance MAY be described by means of an 1198 OPTIONAL Carousel Instance Descriptor (CID) (Section 3.5). The 1199 decisions of whether a CID should be used or not, how often and when 1200 a CID should be sent, are left to the sender and depend on many 1201 parameters, including the target use case and the session dynamics. 1202 For instance it may be appropriate to send a CID at the beginning of 1203 each new carousel instance, and then periodically. These operational 1204 aspects are out of the scope of the present document. 1206 7. IANA Considerations 1208 This specification requires IANA to create two new registries. 1210 7.1. Creation of the FCAST Object Meta-Data Format Registry 1212 This document requires IANA to create a new registry, "FCAST Object 1213 Meta-Data Format" (MDFmt), with a reference to this document. The 1214 registry entries consist of a numeric value from 0 to 15, inclusive 1215 (i.e., they are 4-bit positive integers) that define the format of 1216 the object meta-data (see Section 2.1). 1218 The initial value for this registry registry is defined below. 1219 Future assignments are to be made through Expert Review with 1220 Specification Required [RFC5226]. 1222 +----------------------------------------+-------------+ 1223 | format name | Value | 1224 +----------------------------------------+-------------+ 1225 | as per HTTP/1.1 metainformation format | 0 (default) | 1226 +----------------------------------------+-------------+ 1228 7.2. Creation of the FCAST Object Meta-Data Encoding Registry 1230 This document requires IANA to create a new registry, "FCAST Object 1231 Meta-Data Encoding" (MDEnc), with a reference to this document. The 1232 registry entries consist of a numeric value from 0 to 15, inclusive 1233 (i.e., they are 4-bit positive integers) that define the optional 1234 encoding of the Object Meta-Data field (see Section 2.1). 1236 The initial values for this registry registry are defined below. 1237 Future assignments are to be made through Expert Review [RFC5226]. 1239 +------------+-------------+ 1240 | Name | Value | 1241 +------------+-------------+ 1242 | plain text | 0 (default) | 1243 | GZIP | 1 | 1244 +------------+-------------+ 1246 8. Acknowledgments 1248 The authors are grateful to the authors of [ALC-00] for specifying 1249 the first version of FCAST/ALC. The authors are also grateful to 1250 David Harrington, Gorry Fairhurst and Lorenzo Vicisano for their 1251 valuable comments. 1253 9. References 1255 9.1. Normative References 1257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1258 Requirement Levels", BCP 14, RFC 2119, March 1997. 1260 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1261 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1262 May 2008. 1264 [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, 1265 "Computing the Internet checksum", RFC 1071, 1266 September 1988. 1268 [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding 1269 Transport (LCT) Building Block", RFC 5651, October 2009. 1271 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 1272 "NACK-Oriented Reliable Multicast (NORM) Transport 1273 Protocol", RFC 5740, November 2009. 1275 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 1276 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 1277 April 2010. 1279 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 1280 Randers-Pehrson, "GZIP file format specification version 1281 4.3", RFC 1952, May 1996. 1283 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1284 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1285 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1287 9.2. Informative References 1289 [ALC-00] Luby, M., Gemmell, G., Vicisano, L., Crowcroft, J., and B. 1290 Lueckenhoff, "Asynchronous Layered Coding: a Scalable 1291 Reliable Multicast Protocol", March 2000. 1293 [I-D.ietf-rmt-flute-revised] 1294 Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 1295 "FLUTE - File Delivery over Unidirectional Transport", 1296 draft-ietf-rmt-flute-revised-16 (work in progress), 1297 June 2012. 1299 [I-D.ietf-rmt-sec-discussion] 1300 Adamson, B., Roca, V., and H. Asaeda, "Security and 1301 Reliable Multicast Transport Protocols: Discussions and 1302 Guidelines", draft-ietf-rmt-sec-discussion-06 (work in 1303 progress), March 2011. 1305 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 1306 Engineering Task Force Standard Protocols", BCP 61, 1307 RFC 3365, August 2002. 1309 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1310 Hashing for Message Authentication", RFC 2104, 1311 February 1997. 1313 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1314 Standards (PKCS) #1: RSA Cryptography Specifications 1315 Version 2.1", RFC 3447, February 2003. 1317 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 1318 Briscoe, "Timed Efficient Stream Loss-Tolerant 1319 Authentication (TESLA): Multicast Source Authentication 1320 Transform Introduction", RFC 4082, June 2005. 1322 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1323 RFC 4303, December 2005. 1325 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1326 Correction (FEC) Building Block", RFC 5052, August 2007. 1328 [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, 1329 "Reed-Solomon Forward Error Correction (FEC) Schemes", 1330 RFC 5510, April 2009. 1332 [RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed 1333 Efficient Stream Loss-Tolerant Authentication (TESLA) in 1334 the Asynchronous Layered Coding (ALC) and NACK-Oriented 1335 Reliable Multicast (NORM) Protocols", RFC 5776, 1336 April 2010. 1338 [RFC6584] Roca, V., "Simple Authentication Schemes for the 1339 Asynchronous Layered Coding (ALC) and NACK-Oriented 1340 Reliable Multicast (NORM) Protocols", RFC 6584, 1341 April 2012. 1343 Appendix A. FCAST Examples 1345 A.1. Regular Compound Object Example 1346 0 1 2 3 1347 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 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 |V=0|Resvd=0|1|0|MDFmt=0|MDEnc=0| Checksum | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | Compound Object Header Length=41 | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1353 . . 1354 . meta-data ASCII null terminated string (33 bytes) . 1355 . . 1356 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 | | Padding | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 . . 1360 . Object data . 1361 . . 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 Figure 4: Compound Object Example. 1366 Figure 4 shows a regular Compound Object where the meta-data ASCII 1367 string, in HTTP/1.1 meta-information format (MDFmt=0) contains: 1369 Content-Location: example.txt 1370 This string is 33 bytes long, including the NULL-termination 1371 character. There is no GZIP encoding of the meta-data (MDEnc=0) and 1372 there is no Content-Length information either since this length can 1373 easily be calculated by the receiver as the FEC OTI transfer length 1374 minus the header length. Finally, the checksum encompasses the whole 1375 Compound Object (G=1). 1377 A.2. Carousel Instance Descriptor Example 1379 Figure 5 shows an example CID object, in the case of a static FCAST 1380 session, i.e., a session where the set of objects is set once and for 1381 all. There is no meta-data in this example since Fcast-CID-Complete 1382 and Fcast-CID-ID are both implicit. 1383 0 1 2 3 1384 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 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 |V=0|Resvd=0|1|1|MDFmt=0|MDEnc=0| Checksum | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 | Compound Object Header Length=8 | 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1390 . . 1391 . Object List string . 1392 . . 1393 . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 . | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 Figure 5: Example of CID, in case of a static session. 1399 The object list contains the following 26 byte long string, including 1400 the NULL-termination character: 1402 1,2,3,100-104,200-203,299 1404 There are therefore a total of 3+5+4+1 = 13 objects in the carousel 1405 instance, and therefore in the FCAST session. There is no meta-data 1406 associated to this CID. The session being static and composed of a 1407 single Carousel Instance, the sender did not feel the necessity to 1408 carry a Carousel Instance ID meta-data. 1410 Appendix B. Additional Meta-Data Transmission Mechanisms 1412 B.1. Supporting Additional Mechanisms 1414 In certain use-cases, FCAST MAY take advantage of another in-band 1415 (e.g., via NORM INFO messages Appendix B.2) or out-of-band signaling 1416 mechanism. This additional signaling scheme MAY be used to carry the 1417 whole meta-data, or a subset of it, ahead of time, before the 1418 associated compound object. Therefore a receiver may be able to 1419 decide in advance, before beginning the reception of the compound 1420 object, whether the object is of interest or not, based on the 1421 information retrieved by this way, which mitigates FCAST limitations. 1422 While out-of-band techniques are out of the scope of this document, 1423 we explain below how this may be achieved in case of FCAST/NORM. 1425 Supporting one of these additional mechanisms is OPTIONAL in FCAST 1426 implementations. An FCAST/NORM sender MUST continue to send all the 1427 required meta-data in the compound object, even if the whole meta- 1428 data, or a subset of it, is sent by another mechanism (Section 5). 1429 Additionally, when meta-data is sent several times, there MUST NOT be 1430 any contradiction in the information provided by the different 1431 mechanisms. In case a mismatch is detected, the meta-data contained 1432 in the Compound Object MUST be used as the definitive source. 1434 When meta-data elements are communicated out-of-band, in advance of 1435 data transmission, the following piece of information MAY be useful: 1437 o TOI: a positive integer that contains the Transmission Object 1438 Identifier (TOI) of the object, in order to enable a receiver to 1439 easily associate the meta-data to the object. The valid range for 1440 TOI values is discussed in Section 3.6; 1442 B.2. Using NORM_INFO Messages with FCAST/NORM 1444 The NORM_INFO message of NORM can convey "out-of-band" content with 1445 respect to a given transport object. With FCAST, this message MAY be 1446 used as an additional mechanism to transmit meta-data. In that case, 1447 the NORM_INFO message carries a new Compound Object that contains all 1448 the meta-data of the original object, or a subset of it. The 1449 NORM_INFO Compound Object MUST NOT contain any Object Data field 1450 (i.e., it is only composed of the header), it MUST feature a non 1451 global checksum, and it MUST NOT include any padding field. Finally, 1452 note that the availability of NORM_INFO for a given object is 1453 signaled through the use of a dedicated flag in the NORM_DATA message 1454 header. Along with NORM's NACK-based repair request signaling, it 1455 allows a receiver to quickly (and independently) request an object's 1456 NORM_INFO content. However, a limitation here is that the NORM_INFO 1457 Compound Object header MUST fit within the byte size limit defined by 1458 the NORM sender's configured "segment size" (typically a little less 1459 than the network MTU); 1461 B.2.1. Example 1463 In case of FCAST/NORM, the FCAST Compound Object meta-data (or a 1464 subset of it) can be carried as part of a NORM_INFO message, as a new 1465 Compound Object that does not contain any Compound Object Data. In 1466 the following example we assume that the whole meta-data is carried 1467 in such a message for a certain Compound Object. Figure 6 shows an 1468 example NORM_INFO message that contains the FCAST Compound Object 1469 Header and meta-data as its payload. In this example, the first 16 1470 bytes are the NORM_INFO base header, the next 12 bytes are a NORM 1471 EXT_FTI header extension containing the FEC Object Transport 1472 Information for the associated object, and the remaining bytes are 1473 the FCAST Compound Object Header and meta-data. Note that "padding" 1474 MUST NOT be used and that the FCAST checksum only encompasses the 1475 Compound Object Header (G=0). 1476 0 1 2 3 1477 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 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- 1479 |version| type=1| hdr_len = 7 | sequence | ^ 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1481 | source_id | n 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o 1483 | instance_id | grtt |backoff| gsize | r 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ m 1485 | flags | fec_id = 5 | object_transport_id | v 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- 1487 | HET = 64 | HEL = 3 | | ^ 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + f 1489 | Transfer Length = 41 | t 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i 1491 | Encoding Symbol Length (E) | MaxBlkLen (B) | max_n | v 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- 1493 | 0 | 0 |0|0| 0 | 0 | Checksum | ^ 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1495 | 41 | f 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| c 1497 . . a 1498 . meta-data ASCII null terminated string (33 bytes) . s 1499 . . t 1500 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1501 | | v 1502 +-+-+-+-+-+-+-+-+ -- 1504 Figure 6: NORM_INFO containing an EXT_FTI header extension and an 1505 FCAST Compound Object Header 1507 The NORM_INFO message shown in Figure 6 contains the EXT_FTI header 1508 extension to carry the FEC OTI. In this example, the FEC OTI format 1509 is that of the Reed-Solomon FEC coding scheme for fec_id = 5 as 1510 described in [RFC5510]. Other alternatives for providing the FEC OTI 1511 would have been to either include it directly in the meta-data of the 1512 FCAST Compound Header, or to include an EXT_FTI header extension to 1513 all NORM_DATA packets (or a subset of them). Note that the NORM 1514 "Transfer_Length" is the total length of the associated FCAST 1515 Compound Object, i.e., 41 bytes. 1517 The FCAST Compound Object in this example does contain the same meta- 1518 data and is formatted as in the example of Figure 4. With the 1519 combination of the FEC_OTI and the FCAST meta-data, the NORM protocol 1520 and FCAST application have all of the information needed to reliably 1521 receive and process the associated object. Indeed, the NORM protocol 1522 provides rapid (NORM_INFO has precedence over the associated object 1523 content), reliable delivery of the NORM_INFO message and its payload, 1524 the FCAST Compound Object. 1526 Authors' Addresses 1528 Vincent Roca 1529 INRIA 1530 655, av. de l'Europe 1531 Inovallee; Montbonnot 1532 ST ISMIER cedex 38334 1533 France 1535 Email: vincent.roca@inria.fr 1536 URI: http://planete.inrialpes.fr/people/roca/ 1538 Brian Adamson 1539 Naval Research Laboratory 1540 Washington, DC 20375 1541 USA 1543 Email: adamson@itd.nrl.navy.mil 1544 URI: http://cs.itd.nrl.navy.mil