idnits 2.17.1 draft-ietf-rmt-pi-alc-revised-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2009) is 5395 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) == Outdated reference: A later version (-11) exists of draft-ietf-rmt-bb-lct-revised-09 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Downref: Normative reference to an Experimental RFC: RFC 3738 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-10) exists of draft-ietf-msec-tesla-for-alc-norm-07 == Outdated reference: A later version (-06) exists of draft-ietf-rmt-simple-auth-for-alc-norm-01 -- Obsolete informational reference (is this intentional?): RFC 3450 (Obsoleted by RFC 5775) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Reliable Multicast Transport (RMT) Luby 3 Working Group Watson 4 Internet-Draft Vicisano 5 Obsoletes: 3450 (if approved) Qualcomm Inc. 6 Intended status: Standards Track July 13, 2009 7 Expires: January 14, 2010 9 Asynchronous Layered Coding (ALC) Protocol Instantiation 10 draft-ietf-rmt-pi-alc-revised-07 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 14, 2010. 35 Copyright Notice 37 Copyright (c) 2009 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 in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document describes the Asynchronous Layered Coding (ALC) 49 protocol, a massively scalable reliable content delivery protocol. 50 Asynchronous Layered Coding combines the Layered Coding Transport 51 (LCT) building block, a multiple rate congestion control building 52 block and the Forward Error Correction (FEC) building block to 53 provide congestion controlled reliable asynchronous delivery of 54 content to an unlimited number of concurrent receivers from a single 55 sender. This document obsoletes RFC3450. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Delivery service models . . . . . . . . . . . . . . . . . 4 61 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.3. Environmental Requirements and Considerations . . . . . . 5 63 2. Architecture Definition . . . . . . . . . . . . . . . . . . . 6 64 2.1. LCT building block . . . . . . . . . . . . . . . . . . . . 7 65 2.2. Multiple rate congestion control building block . . . . . 9 66 2.3. FEC building block . . . . . . . . . . . . . . . . . . . . 9 67 2.4. Session Description . . . . . . . . . . . . . . . . . . . 11 68 2.5. Packet authentication building block . . . . . . . . . . . 12 69 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 14 70 4. Functionality Definition . . . . . . . . . . . . . . . . . . . 15 71 4.1. Packet format used by ALC . . . . . . . . . . . . . . . . 15 72 4.2. LCT Header-Extension Fields . . . . . . . . . . . . . . . 16 73 4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 17 74 4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 17 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 76 5.1. Baseline Secure ALC Operation . . . . . . . . . . . . . . 20 77 5.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 20 78 5.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 21 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 80 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 81 8. Changes from RFC3450 . . . . . . . . . . . . . . . . . . . . . 26 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 83 9.1. Normative references . . . . . . . . . . . . . . . . . . . 27 84 9.2. Informative references . . . . . . . . . . . . . . . . . . 27 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 87 1. Introduction 89 This document describes a massively scalable reliable content 90 delivery protocol, Asynchronous Layered Coding (ALC), for multiple 91 rate congestion controlled reliable content delivery. The protocol 92 is specifically designed to provide massive scalability using IP 93 multicast as the underlying network service. Massive scalability in 94 this context means the number of concurrent receivers for an object 95 is potentially in the millions, the aggregate size of objects to be 96 delivered in a session ranges from hundreds of kilobytes to hundreds 97 of gigabytes, each receiver can initiate reception of an object 98 asynchronously, the reception rate of each receiver in the session is 99 the maximum fair bandwidth available between that receiver and the 100 sender, and all of this can be supported using a single sender. 102 Because ALC is focused on reliable content delivery, the goal is to 103 deliver objects as quickly as possible to each receiver while at the 104 same time remaining network friendly to competing traffic. Thus, the 105 congestion control used in conjunction with ALC should strive to 106 maximize use of available bandwidth between receivers and the sender 107 while at the same time backing off aggressively in the face of 108 competing traffic. 110 The sender side of ALC consists of generating packets based on 111 objects to be delivered within the session and sending the 112 appropriately formatted packets at the appropriate rates to the 113 channels associated with the session. The receiver side of ALC 114 consists of joining appropriate channels associated with the session, 115 performing congestion control by adjusting the set of joined channels 116 associated with the session in response to detected congestion, and 117 using the packets to reliably reconstruct objects. All information 118 flow in an ALC session is in the form of data packets sent by a 119 single sender to channels that receivers join to receive data. 121 ALC does specify the Session Description needed by receivers before 122 they join a session, but the mechanisms by which receivers obtain 123 this required information is outside the scope of ALC. An 124 application that uses ALC may require that receivers report 125 statistics on their reception experience back to the sender, but the 126 mechanisms by which receivers report back statistics is outside the 127 scope of ALC. In general, ALC is designed to be a minimal protocol 128 instantiation that provides reliable content delivery without 129 unnecessary limitations to the scalability of the basic protocol. 131 This document is a product of the IETF RMT WG and follows the general 132 guidelines provided in [RFC3269]. 134 [RFC3450], which was published in the "Experimental" category and 135 which is obsoleted by this document, contained a previous versions of 136 the protocol. 138 This Proposed Standard specification is thus based on and backwards 139 compatible with the protocol defined in [RFC3450] updated according 140 to accumulated experience and growing protocol maturity since its 141 original publication. Said experience applies both to this 142 specification itself and to congestion control strategies related to 143 the use of this specification. 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in BCP 14, [RFC2119]. 149 1.1. Delivery service models 151 ALC can support several different reliable content delivery service 152 models as described in [I-D.ietf-rmt-bb-lct-revised]. 154 1.2. Scalability 156 Massive scalability is a primary design goal for ALC. IP multicast 157 is inherently massively scalable, but the best effort service that it 158 provides does not provide session management functionality, 159 congestion control or reliability. ALC provides all of this on top 160 of IP multicast without sacrificing any of the inherent scalability 161 of IP multicast. ALC has the following properties: 163 o To each receiver, it appears as if though there is a dedicated 164 session from the sender to the receiver, where the reception rate 165 adjusts to congestion along the path from sender to receiver. 167 o To the sender, there is no difference in load or outgoing rate if 168 one receiver is joined to the session or a million (or any number 169 of) receivers are joined to the session, independent of when the 170 receivers join and leave. 172 o No feedback packets are required from receivers to the sender. 174 o Almost all packets in the session that pass through a bottleneck 175 link are utilized by downstream receivers, and the session shares 176 the link with competing flows fairly in proportion to their 177 utility. 179 Thus, ALC provides a massively scalable content delivery transport 180 that is network friendly. 182 ALC intentionally omits any application specific features that could 183 potentially limit its scalability. By doing so, ALC provides a 184 minimal protocol that is massively scalable. Applications may be 185 built on top of ALC to provide additional features that may limit the 186 scalability of the application. Such applications are outside the 187 scope of this document. 189 1.3. Environmental Requirements and Considerations 191 All of the environmental requirements and considerations that apply 192 to the LCT building block [I-D.ietf-rmt-bb-lct-revised], the FEC 193 building block [RFC5052], the multiple rate congestion control 194 building block and to any additional building blocks that ALC uses 195 also apply to ALC. 197 One issues that is specific to ALC with respect to the Any- Source 198 Multicast (ASM) model of IP multicast as defined in RFC 1112 199 [RFC1112] is the way the multiple rate congestion control building 200 block interacts with ASM. The congestion control building block may 201 use the measured difference in time between when a join to a channel 202 is sent and when the first packet from the channel arrives in 203 determining the receiver reception rate. The congestion control 204 building block may also uses packet sequence numbers per channel to 205 measure losses, and this is also used to determine the receiver 206 reception rate. These features raise two concerns with respect to 207 ASM: The time difference between when the join to a channel is sent 208 and when the first packet arrives can be significant due to the use 209 of Rendezvous Points (RPs) and the MSDP protocol, and packets can be 210 lost in the switch over from the (*,G) join to the RP and the (S,G) 211 join directly to the sender. Both of these issues could potentially 212 substantially degrade the reception rate of receivers. To ameliorate 213 these concerns, it is RECOMMENDED that the RP be as close to the 214 sender as possible. SSM does not share these same concerns. For a 215 fuller consideration of these issues, consult the multiple rate 216 congestion control building block. 218 2. Architecture Definition 220 ALC uses the LCT building block [I-D.ietf-rmt-bb-lct-revised] to 221 provide in-band session management functionality. ALC uses a 222 multiple rate congestion control building block that is compliant 223 with [RFC2357] to provide congestion control that is feedback free. 224 Receivers adjust their reception rates individually by joining and 225 leaving channels associated with the session. ALC uses the FEC 226 building block [RFC5052] to provide reliability. The sender 227 generates encoding symbols based on the object to be delivered using 228 FEC codes and sends them in packets to channels associated with the 229 session. Receivers simply wait for enough packets to arrive in order 230 to reliably reconstruct the object. Thus, there is no request for 231 retransmission of individual packets from receivers that miss packets 232 in order to assure reliable reception of an object, and the packets 233 and their rate of transmission out of the sender can be independent 234 of the number and the individual reception experiences of the 235 receivers. 237 The definition of a session for ALC is the same as it is for LCT. An 238 ALC session comprises multiple channels originating at a single 239 sender that are used for some period of time to carry packets 240 pertaining to the transmission of one or more objects that can be of 241 interest to receivers. Congestion control is performed over the 242 aggregate of packets sent to channels belonging to a session. The 243 fact that an ALC session is restricted to a single sender does not 244 preclude the possibility of receiving packets for the same objects 245 from multiple senders. However, each sender would be sending packets 246 to a a different session to which congestion control is individually 247 applied. Although receiving concurrently from multiple sessions is 248 allowed, how this is done at the application level is outside the 249 scope of this document. 251 ALC is a protocol instantiation as defined in [RFC3048]. This 252 document describes version 1 of ALC which MUST use version 1 of LCT 253 described in [I-D.ietf-rmt-bb-lct-revised]. Like LCT, ALC is 254 designed to be used with the IP multicast network service. This 255 specification defines ALC as payload of the UDP transport protocol 256 [RFC0768] that supports IP multicast delivery of packets. 258 An ALC packet header immediately follows the UDP header and consists 259 of the default LCT header that is described in 260 [I-D.ietf-rmt-bb-lct-revised] followed by the FEC Payload ID that is 261 described in [RFC5052]. The Congestion Control Information field 262 within the LCT header carries the required Congestion Control 263 Information that is described in the multiple rate congestion control 264 building block specified that is compliant with [RFC2357]. The 265 packet payload that follows the ALC packet header consists of 266 encoding symbols that are identified by the FEC Payload ID as 267 described in [RFC5052]. 269 Each receiver is required to obtain a Session Description before 270 joining an ALC session. As described later, the Session Description 271 includes out-of-band information required for the LCT, FEC and the 272 multiple rate congestion control building blocks. The FEC Object 273 Transmission Information specified in the FEC building block 274 [RFC5052] required for each object to be received by a receiver can 275 be communicated to a receiver either out-of-band or in-band using a 276 Header Extension. The means for communicating the Session 277 Description and the FEC Object Transmission Information to a receiver 278 is outside the scope of this document. 280 2.1. LCT building block 282 LCT requires receivers to be able to uniquely identify and 283 demultiplex packets associated with an LCT session, and ALC inherits 284 and strengthens this requirement. A Transport Session Identifier 285 (TSI) MUST be associated with each session and MUST be carried in the 286 LCT header of each ALC packet. The TSI is scoped by the sender IP 287 address, and the (sender IP address, TSI) pair MUST uniquely identify 288 the session. 290 The LCT header contains a Congestion Control Information (CCI) field 291 that MUST be used to carry the Congestion Control Information from 292 the specified multiple rate congestion control protocol. There is a 293 field in the LCT header that specifies the length of the CCI field, 294 and the multiple rate congestion control building block MUST uniquely 295 identify a format of the CCI field that corresponds to this length. 297 The LCT header contains a Codepoint field that MAY be used to 298 communicate to a receiver the settings for information that may vary 299 during a session. If used, the mapping between settings and 300 Codepoint values is to be communicated in the Session Description, 301 and this mapping is outside the scope of this document. For example, 302 the FEC Encoding ID that is part of the FEC Object Transmission 303 Information as specified in the FEC building block [RFC5052] could 304 vary for each object carried in the session, and the Codepoint value 305 could be used to communicate the FEC Encoding ID to be used for each 306 object. The mapping between FEC Encoding IDs and Codepoints could 307 be, for example, the identity mapping. 309 If more than one object is to be carried within a session then the 310 Transmission Object Identifier (TOI) MUST be used in the LCT header 311 to identify which packets are to be associated with which objects. 312 In this case the receiver MUST use the TOI to associate received 313 packets with objects. The TOI is scoped by the IP address of the 314 sender and the TSI, i.e., the TOI is scoped by the session. The TOI 315 for each object is REQUIRED to be unique within a session, but is not 316 required be unique across sessions. Furthermore, the same object MAY 317 have a different TOI in different sessions. The mapping between TOIs 318 and objects carried in a session is outside the scope of this 319 document. 321 If only one object is carried within a session then the TOI MAY be 322 omitted from the LCT header. 324 The LCT header from version 1 of the LCT building block 325 [I-D.ietf-rmt-bb-lct-revised] MUST be used. 327 The LCT Header includes a two-bit Protocol Specific Indication (PSI) 328 field in bits 6 and 7 of the first word of the LCT header. These two 329 bits are used by ALC as follows: 331 0 1 2 3 332 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 333 +-+-+ 334 ...|X|Y|... 335 +-+-+ 337 Figure 1: PSI bits within LCT Headder 339 PSI bit X - Source Packet Indicator (SPI) 341 PSI bit Y - Reserved 343 The Source Packet Indicator is used with systematic FEC Schemes which 344 define a different FEC Payload ID format for packets containing only 345 source data compared to the FEC Payload ID format for packets 346 containing repair data. For such FEC Schemes, then the SPI MUST be 347 set to 1 when the FEC Payload ID format for packets containing only 348 source data is used and the SPI MUST be set to zero, when the FEC 349 Payload ID for packerts containing repair data is used. In the case 350 of FEC Schemes which define only a single FEC Payload ID format, then 351 the SPI MUST be set to zero by the sender and MUST be ignored by the 352 receiver. 354 Support of two FEC Payload ID formats allows FEC Payload ID 355 information which is only of relevance when FEC decoding is to be 356 performed to be provided in the FEC Payload ID format for packets 357 containing repair data. This information need not be processed by 358 receivers which do not perform FEC decoding (either because no FEC 359 decoding is required or because the receiver does not support FEC 360 decoding). 362 2.2. Multiple rate congestion control building block 364 At a minimum, implementions of ALC MUST support [RFC3738]. 366 Congestion control MUST be applied to all packets within a session 367 independently of which information about which object is carried in 368 each packet. Multiple rate congestion control is specified because 369 of its suitability to scale massively and because of its suitability 370 for reliable content delivery. [RFC3738] specifies in-band 371 Congestion Control Information (CCI) that MUST be carried in the CCI 372 field of the LCT header. 374 Alternative multiple rate congestion control building blocks MAY be 375 supported. The multiple rate congestion control building block MAY 376 specify more than one format for the CCI field, but it MUST specify 377 at most one format for each of the possible lengths 32, 64, 96 or 128 378 bits. The value of C in the LCT header that determines the length of 379 the CCI field MUST correspond to one of the lengths for the CCI 380 defined in the multiple rate congestion control building block, this 381 length MUST be the same for all packets sent to a session, and the 382 CCI format that corresponds to the length as specified in the 383 multiple rate congestion control building block MUST be the format 384 used for the CCI field in the LCT header. 386 When using a multiple rate congestion control building block a sender 387 sends packets in the session to several channels at potentially 388 different rates. Then, individual receivers adjust their reception 389 rate within a session by adjusting which set of channels they are 390 joined to at each point in time depending on the available bandwidth 391 between the receiver and the sender, but independent of other 392 receivers. 394 2.3. FEC building block 396 The FEC building block [RFC5052] provides reliable object delivery 397 within an ALC session. Each object sent in the session is 398 independently encoded using FEC codes as described in [RFC3453], 399 which provide a more in-depth description of the use of FEC codes in 400 reliable content delivery protocols. All packets in an ALC session 401 MUST contain an FEC Payload ID in a format that is compliant with the 402 FEC Scheme in use. The FEC Payload ID uniquely identifies the 403 encoding symbols that constitute the payload of each packet, and the 404 receiver MUST use the FEC Payload ID to determine how the encoding 405 symbols carried in the payload of the packet were generated from the 406 object as described in the FEC building block. 408 As described in [RFC5052], a receiver is REQUIRED to obtain the FEC 409 Object Transmission Information for each object for which data 410 packets are received from the session. In the context of ALC, the 411 FEC Object Transmission Information includes: 413 o The FEC Encoding ID. 415 o If an Under-Specified FEC Encoding ID is used then the FEC 416 Instance ID associated with the FEC Encoding ID. 418 o For each object in the session, the transfer length of the object 419 in bytes. 421 Additional FEC Object Transmission Information may be required 422 depending on the FEC Scheme that is used (identified by the FEC 423 Encoding ID). 425 Some of the FEC Object Transmission Information MAY be implicit based 426 on the FEC Scheme and/or implementation. As an example, source block 427 lengths may be derived by a fixed algorithm from the object length. 428 As another example, it may be that all source blocks are the same 429 length and this is what is passed out-of-band to the receiver. As 430 another example, it could be that the full sized source block length 431 is provided and this is the length used for all but the last source 432 block, which is calculated based on the full source block length and 433 the object length. As another example, it could be that the same FEC 434 Encoding ID and FEC Instance ID are always used for a particular 435 application and thus the FEC Encoding ID and FEC Instance ID are 436 implicitly defined. 438 Sometimes the objects that will be sent in a session are completely 439 known before the receiver joins the session, in which case the FEC 440 Object Transmission Information for all objects in the session can be 441 communicated to receivers before they join the session. At other 442 times the objects may not know when the session begins, or receivers 443 may join a session in progress and may not be interested in some 444 objects for which transmission has finished, or receivers may leave a 445 session before some objects are even available within the session. 446 In these cases, the FEC Object Transmission Information for each 447 object may be dynamically communicated to receivers at or before the 448 time packets for the object are received from the session. This may 449 be accomplished using either an out-of-band mechanism, in-band using 450 the Codepoint field or a Header Extension, or any combination of 451 these methods. How the FEC Object Transmission Information is 452 communicated to receivers is outside the scope of this document. 454 If packets for more than one object are transmitted within a session 455 then a Transmission Object Identifier (TOI) that uniquely identifies 456 objects within a session MUST appear in each packet header. Portions 457 of the FEC Object Transmission Information could be the same for all 458 objects in the session, in which case these portions can be 459 communicated to the receiver with an indication that this applies to 460 all objects in the session. These portions may be implicitly 461 determined based on the application, e.g., an application may use the 462 same FEC Encoding ID for all objects in all sessions. If there is a 463 portion of the FEC Object Transmission Information that may vary from 464 object to object and if this FEC Object Transmission Information is 465 communicated to a receiver out-of-band then the TOI for the object 466 MUST also be communicated to the receiver together with the 467 corresponding FEC Object Transmission Information, and the receiver 468 MUST use the corresponding FEC Object Transmission Information for 469 all packets received with that TOI. How the TOI and corresponding 470 FEC Object Transmission Information is communicated out-of-band to 471 receivers is outside the scope of this document. 473 It is also possible that there is a portion of the FEC Object 474 Transmission Information that may vary from object to object that is 475 carried in-band, for example in the CodePoint field or in Header 476 Extensions. How this is done is outside the scope of this document. 477 In this case the FEC Object Transmission Information is associated 478 with the object identified by the TOI carried in the packet. 480 2.4. Session Description 482 The Session Description that a receiver is REQUIRED to obtain before 483 joining an ALC session MUST contain the following information: 485 o The multiple rate congestion control building block to be used for 486 the session; 488 o The sender IP address; 490 o The number of channels in the session; 492 o The address and port number used for each channel in the session; 494 o The Transport Session ID (TSI) to be used for the session; 496 o An indication of whether or not the session carries packets for 497 more than one object; 499 o If Header Extensions are to be used, the format of these Header 500 Extensions. 502 o Enough information to determine the packet authentication scheme 503 being used, if it is being used. 505 How the Session Description is communicated to receivers is outside 506 the scope of this document. 508 The Codepoint field within the LCT portion of the header CAN be used 509 to communicate in-band some of the dynamically changing information 510 within a session. To do this, a mapping between Codepoint values and 511 the different dynamic settings MUST be included within the Session 512 Description, and then settings to be used are communicated via the 513 Codepoint value placed into each packet. For example, it is possible 514 that multiple objects are delivered within the same session and that 515 a different FEC encoding algorithm is used for different types of 516 objects. Then the Session Description could contain the mapping 517 between Codepoint values and FEC Encoding IDs. As another example, 518 it is possible that a different packet authentication scheme is used 519 for different packets sent to the session. In this case, the mapping 520 between the packet authentication scheme and Codepoint values could 521 be provided in the Session Description. Combinations of settings can 522 be mapped to Codepoint values as well. For example, a particular 523 combination of a FEC Encoding ID and a packet authentication scheme 524 could be associated with a Codepoint value. 526 The Session Description could also include, but is not limited to: 528 o The mappings between combinations of settings and Codepoint 529 values; 531 o The data rates used for each channel; 533 o The length of the packet payload; 535 o Any information that is relevant to each object being transported, 536 such as the Object Transmission Information for each object, when 537 the object will be available within the session and for how long. 539 The Session Description could be in a form such as SDP as defined in 540 [RFC4566], or XML metadata as defined in [RFC3023], or HTTP/Mime 541 headers as defined in [RFC2616], etc. It might be carried in a 542 session announcement protocol such as SAP as defined in [RFC2974], 543 obtained using a proprietary session control protocol, located on a 544 web page with scheduling information, or conveyed via E-mail or other 545 out-of-band methods. Discussion of Session Description formats and 546 methods for communication of Session Descriptions to receivers is 547 beyond the scope of this document. 549 2.5. Packet authentication building block 551 It is RECOMMENDED that implementors of ALC use some packet 552 authentication scheme to protect the protocol from attacks. Suitable 553 schemes are described in [I-D.ietf-msec-tesla-for-alc-norm] and 555 [I-D.ietf-rmt-simple-auth-for-alc-norm]. 557 3. Conformance Statement 559 This Protocol Instantiation document, in conjunction with the LCT 560 building block [I-D.ietf-rmt-bb-lct-revised], the FEC building block 561 [RFC5052] and [RFC3738] completely specifies a working reliable 562 multicast transport protocol that conforms to the requirements 563 described in [RFC2357]. 565 4. Functionality Definition 567 This section describes the format and functionality of the data 568 packets carried in an ALC session as well as the sender and receiver 569 operations for a session. 571 4.1. Packet format used by ALC 573 The packet format used by ALC is the UDP header followed by the LCT 574 header followed by the FEC Payload ID followed by the packet payload. 575 The LCT header is defined in the LCT building block 576 [I-D.ietf-rmt-bb-lct-revised] and the FEC Payload ID is described in 577 the FEC building block [RFC5052]. The Congestion Control Information 578 field in the LCT header contains the REQUIRED Congestion Control 579 Information that is described in the multiple rate congestion control 580 building block used. The packet payload contains encoding symbols 581 generated from an object. If more than one object is carried in the 582 session then the Transmission Object ID (TOI) within the LCT header 583 MUST be used to identify which object the encoding symbols are 584 generated from. Within the scope of an object, encoding symbols 585 carried in the payload of the packet are identified by the FEC 586 Payload ID as described in the FEC building block. 588 The version number of ALC specified in this document is 1. The 589 version number field of the LCT header MUST be interpreted as the ALC 590 version number field. This version of ALC implicitly makes use of 591 version 1 of the LCT building block defined in 592 [I-D.ietf-rmt-bb-lct-revised]. 594 The overall ALC packet format is depicted in Figure 2. The packet is 595 an IP packet, either IPv4 or IPv6, and the IP header precedes the UDP 596 header. The ALC packet format has no dependencies on the IP version 597 number. 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | UDP header | 603 | | 604 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 605 | LCT header | 606 | | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | FEC Payload ID | 609 | | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Encoding Symbol(s) | 612 | ... | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Figure 2: Overall ALC packet format 617 In some special cases an ALC sender may need to produce ALC packets 618 that do not contain any payload. This may be required, for example, 619 to signal the end of a session or to convey congestion control 620 information. These data-less packets do not contain the FEC Payload 621 ID either, but only the LCT header fields. The total datagram 622 length, conveyed by outer protocol headers (e.g., the IP or UDP 623 header), enables receivers to detect the absence of the ALC payload 624 and FEC Payload ID. 626 For ALC the length of the TSI field within the LCT header is REQUIRED 627 to be non-zero. This implies that the sender MUST NOT set both the 628 LCT flags S and H to zero. 630 4.2. LCT Header-Extension Fields 632 All senders and receivers implementing ALC MUST support the EXT_NOP 633 Header Extension and MUST recognize EXT_AUTH, but are not required be 634 able to parse its content. The EXT_NOP and EXT_AUTH LCT Header 635 Extensions are defined in [I-D.ietf-rmt-bb-lct-revised] 637 This specification defines a new LCT Header Extension, "EXT_FTI", for 638 the purpose of communicating the FEC Object Transmission Information 639 in association with data packets of an object. The LCT Header 640 Extension Type for EXT_FTI is 64. 642 The Header Extension Content (HEC) field of the EXT_FTI LCT Header 643 Extension contains the encoded FEC Object Transmission Information as 644 defined in [RFC5052]. The format of the encoded FEC Object 645 Transmission Information is dependent on the FEC Scheme in use and so 646 is outside the scope of this document. 648 4.3. Sender Operation 650 The sender operation when using ALC includes all the points made 651 about the sender operation when using the LCT building block 652 [I-D.ietf-rmt-bb-lct-revised], the FEC building block [RFC5052] and 653 the multiple rate congestion control building block. 655 A sender using ALC MUST make available the required Session 656 Description as described in Section 2.4. A sender also MUST make 657 available the required FEC Object Transmission Information as 658 described in Section 2.3. 660 Within a session a sender transmits a sequence of packets to the 661 channels associated with the session. The ALC sender MUST obey the 662 rules for filling in the CCI field in the packet headers and MUST 663 send packets at the appropriate rates to the channels associated with 664 the session as dictated by the multiple rate congestion control 665 building block. 667 The ALC sender MUST use the same TSI for all packets in the session. 668 Several objects MAY be delivered within the same ALC session. If 669 more than one object is to be delivered within a session then the 670 sender MUST use the TOI field and each object MUST be identified by a 671 unique TOI within the session, and the sender MUST use corresponding 672 TOI for all packets pertaining to the same object. The FEC Payload 673 ID MUST correspond to the encoding symbol(s) for the object carried 674 in the payload of the packet. 676 It is RECOMMENDED that packet authentication be used. If packet 677 authentication is used then the Header Extensions described in 678 Section 4.2 MAY be used to carry the authentication. 680 4.4. Receiver Operation 682 The receiver operation when using ALC includes all the points made 683 about the receiver operation when using the LCT building block 684 [I-D.ietf-rmt-bb-lct-revised], the FEC building block [RFC5052] and 685 the multiple rate congestion control building block. 687 To be able to participate in a session, a receiver MUST obtain the 688 REQUIRED Session Description as listed in Section 2.4. How receivers 689 obtain a Session Description is outside the scope of this document. 691 As described in Section 2.3, a receiver MUST obtain the required FEC 692 Object Transmission Information for each object for which the 693 receiver receives and processes packets. 695 Upon receipt of each packet the receiver proceeds with the following 696 steps in the order listed. 698 1. The receiver MUST parse the packet header and verify that it is a 699 valid header. If it is not valid then the packet MUST be 700 discarded without further processing. 702 2. The receiver MUST verify that the sender IP address together with 703 the TSI carried in the header matches one of the (sender IP 704 address, TSI) pairs that was received in a Session Description 705 and that the receiver is currently joined to. If there is not a 706 match then the packet MUST be silently discarded without further 707 processing. The remaining steps are performed within the scope 708 of the (sender IP address, TSI) session of the received packet. 710 3. The receiver MUST process and act on the CCI field in accordance 711 with the multiple rate congestion control building block. 713 4. If more than one object is carried in the session, the receiver 714 MUST verify that the TOI carried in the LCT header is valid. If 715 the TOI is not valid, the packet MUST be discarded without 716 further processing. 718 5. The receiver SHOULD process the remainder of the packet, 719 including interpreting the other header fields appropriately, and 720 using the FEC Payload ID and the encoding symbol(s) in the 721 payload to reconstruct the corresponding object. 723 It is RECOMMENDED that packet authentication be used. If packet 724 authentication is used then it is RECOMMENDED that the receiver 725 immediately check the authenticity of a packet before proceeding with 726 step (3) above. If immediate checking is possible and if the packet 727 fails the check then the receiver MUST silently discard the packet. 729 Some packet authentication schemes such as TESLA 730 [I-D.ietf-msec-tesla-for-alc-norm] do not allow an immediate 731 authenticity check. In this case the receiver SHOULD check the 732 authenticity of a packet as soon as possible, and if the packet fails 733 the check then it MUST be silently discarded before step (5) above. 734 It is RECOMMENDED that if receivers detect many packets which fail 735 authentication checks within a session then the above procedure 736 should be modified for this session so that Step 3 is delayed until 737 after the authentication check and only performed if the check 738 succeeds. 740 5. Security Considerations 742 The same security consideration that apply to the LCT, FEC and the 743 multiple rate congestion control building blocks also apply to ALC. 745 ALC is especially vulnerable to denial- of-service attacks by 746 attackers that try to send forged packets to the session which would 747 prevent successful reconstruction or cause inaccurate reconstruction 748 of large portions of the object by receivers. ALC is also 749 particularly affected by such an attack because many receivers may 750 receive the same forged packet. There are two ways to protect 751 against such attacks, one at the application level and one at the 752 packet level. It is RECOMMENDED that prevention be provided at both 753 levels. 755 At the application level, it is RECOMMENDED that an integrity check 756 on the entire received object be done once the object is 757 reconstructed to ensure it is the same as the sent object. Moreover, 758 in order to obtain strong cryptographic integrity protection a 759 digital signature verifiable by the receiver SHOULD be used to 760 provide this application level integrity check. However, if even one 761 corrupted or forged packet is used to reconstruct the object, it is 762 likely that the received object will be reconstructed incorrectly. 763 This will appropriately cause the integrity check to fail and in this 764 case the inaccurately reconstructed object SHOULD be discarded. 765 Thus, the acceptance of a single forged packet can be an effective 766 denial of service attack for distributing objects, but an object 767 integrity check at least prevents inadvertent use of inaccurately 768 reconstructed objects. The specification of an application level 769 integrity check of the received object is outside the scope of this 770 document. 772 At the packet level, it is RECOMMENDED that a packet level 773 authentication be used to ensure that each received packet is an 774 authentic and uncorrupted packet containing data for the object 775 arriving from the specified sender. Packet level authentication has 776 the advantage that corrupt or forged packets can be discarded 777 individually and the received authenticated packets can be used to 778 accurately reconstruct the object. Thus, the effect of a denial of 779 service attack that injects forged packets is proportional only to 780 the number of forged packets, and not to the object size. 781 [I-D.ietf-rmt-simple-auth-for-alc-norm]and 782 [I-D.ietf-msec-tesla-for-alc-norm] described packet level 783 authentication schemes which can be used with the ALC protocol. 785 In addition to providing protection against reconstruction of 786 inaccurate objects, packet level authentication can also provide some 787 protection against denial of service attacks on the multiple rate 788 congestion control. Attackers can try to inject forged packets with 789 incorrect congestion control information into the multicast stream, 790 thereby potentially adversely affecting network elements and 791 receivers downstream of the attack, and much less significantly the 792 rest of the network and other receivers. Thus, it is also 793 RECOMMENDED that packet level authentication be used to protect 794 against such attacks. TESLA [I-D.ietf-msec-tesla-for-alc-norm] can 795 also be used to some extent to limit the damage caused by such 796 attacks. However, with TESLA a receiver can only determine if a 797 packet is authentic several seconds after it is received, and thus an 798 attack against the congestion control protocol can be effective for 799 several seconds before the receiver can react to slow down the 800 session reception rate. 802 Reverse Path Forwarding checks SHOULD be enabled in all network 803 routers and switches along the path from the sender to receivers to 804 limit the possibility of a bad agent injecting forged packets into 805 the multicast tree data path. 807 5.1. Baseline Secure ALC Operation 809 This section describes a baseline mode of secure ALC protocol 810 operation based on application of the IPsec security protocol. This 811 approach is documented here to provide a reference, interoperable 812 secure mode of operation. However, additional approaches to ALC 813 security, including other forms of IPsec application, MAY be 814 specified in the future. For example, the use of the EXT_AUTH header 815 extension could enable ALC-specific authentication or security 816 encapsulation headers similar to those of IPsec to be specified and 817 inserted into the ALC/LCT protocol message headers. This would allow 818 header compression techniques to be applied to IP and ALC protocol 819 headers when needed in a similar fashion to that of RTP [RFC3550] and 820 as preserved in the specification for Secure Real Time Protocol 821 (SRTP) [RFC3711]. 823 The baseline approach described is applicable to ALC operation 824 configured for SSM (or SSM-like) operation where there is a single 825 sender. The receiver set would maintain a single IPSec Security 826 Association (SA) for each ALC sender. 828 5.1.1. IPsec Approach 830 To support this baseline form of secure ALC one-to-many SSM 831 operation, each node SHALL be configured with a transport mode IPsec 832 Security Association and corresponding Security Policy Database (SPD) 833 entry. This entry will be used for sender-to-group multicast packet 834 authentication and optionally encryption. 836 The ALC sender SHALL use an IPsec SA configured for ESP protocol 837 [RFC4303] operation with the option for data origination 838 authentication enabled. It is also RECOMMENDED that this IPsec ESP 839 SA be also configured to provide confidentiality protection for IP 840 packets containing ALC protocol messages. This is suggested to make 841 the realization of complex replay attacks much more difficult. The 842 encryption key for this SA SHALL be preplaced at the sender and 843 receiver(s) prior to ALC protocol operation. Use of automated key 844 management is RECOMMENDED as a rekey SHALL be required prior to 845 expiration of the sequence space for the SA. This is necessary so 846 that receivers may use the built-in IPsec replay attack protection 847 possible for an IPsec SA with a single source (the ALC sender). Thus 848 the receivers SHALL enable replay attack protection for this SA used 849 to secure ALC sender traffic. The sender IPsec SPD entry MUST be 850 configured to process outbound packets to the destination address and 851 UDP port number of the applicable ALC session. 853 The ALC receiver(s) MUST be configured with the SA and SPD entry to 854 properly process the IPsec-secured packets from the sender. Note 855 that use of ESP confidentiality, as RECOMMENDED, for secure ALC 856 protocol operation makes it more difficult for adversaries to conduct 857 effective replay attacks that may mislead receivers on content 858 reception. This baseline approach can be used for ALC protocol 859 sessions with multiple senders if a distinct SA is established for 860 each sender. 862 It is anticipated in early deployments of this baseline approach to 863 ALC security that key management will be conducted out-of-band with 864 respect to ALC protocol operation. For ALC unidirectional operation, 865 it is possible that receivers may retrieve keying information from a 866 central server via out-of-band (with respect to ALC) communication as 867 needed or otherwise conduct group key updates with a similar 868 centralized approach. However, it may be possible with some key 869 management schemes for rekey messages to be transmitted to the group 870 as a message or transport object within the ALC reliable transfer 871 session. Additional specification is necessary to define an in-band 872 key management scheme for ALC sessions perhaps using the mechanisms 873 of the automated group key management specifications cited in this 874 document. 876 5.1.2. IPsec Requirements 878 In order to implement this secure mode of ALC protocol operation, the 879 following IPsec capabilities are required. 881 5.1.2.1. Selectors 883 The implementation MUST be able to use the source address, 884 destination address, protocol (UDP), and UDP port numbers as 885 selectors in the SPD. 887 5.1.2.2. Mode 889 IPsec in transport mode MUST be supported. The use of IPsec 890 [RFC4301] processing for secure ALC traffic SHOULD also be REQUIRED 891 such that unauthenticated packets are not received by the ALC 892 protocol implementation . 894 5.1.2.3. Key Management 896 An automated key management scheme for group key distribution and 897 rekeying such as GDOI [RFC3547], GSAKMP [RFC4535], or MIKEY [RFC3830] 898 SHOULD be used. Relatively short-lived ALC sessions MAY be able to 899 use Manual Keying with a single, preplaced key, particularly if 900 Extended Sequence Numbering (ESN) [RFC4303] is available in the IPsec 901 implementation used. It should also be noted that it may be possible 902 for key update messages (e.g., the GDOI GROUPKEY-PUSH message) to be 903 included in the ALC application reliable data transmission as 904 transport objects if appropriate interfaces were available between 905 the ALC application and the key management daemon. 907 5.1.2.4. Security Policy 909 Receivers SHOULD accept connections only from the designated, 910 authorized sender(s). It is expected that appropriate key management 911 will provide encryption keys only to receivers authorized to 912 participate in a designated session. The approach outlined here 913 allows receiver sets to be controlled on a per-sender basis. 915 5.1.2.5. Authentication and Encryption 917 Large ALC group sizes may necessitate some form of key management 918 that does rely upon shared secrets. The GDOI and GSAKMP protocols 919 mentioned here allow for certificate-based authentication. These 920 certificates SHOULD use IP addresses for authentication. However, it 921 is likely that available group key management implementations will 922 not be ALC-specific. 924 5.1.2.6. Availability 926 The IPsec requirements profile outlined here is commonly available on 927 many potential ALC hosts. The principal issue is that configuration 928 and operation of IPsec typically requires privileged user 929 authorization. Automated key management implementations are 930 typically configured with the privileges necessary to effect system 931 IPsec configuration needed. 933 6. IANA Considerations 935 This specification registers the following LCT Header Extensions 936 Types in namespace ietf:rmt:lct:headerExtensionTypes:variableLength: 938 +-------+---------+--------------------+ 939 | Value | Name | Reference | 940 +-------+---------+--------------------+ 941 | 64 | EXT_FTI | This specification | 942 +-------+---------+--------------------+ 944 7. Acknowledgments 946 This specification is substantially based on RFC3450 [RFC3450] and 947 thus credit for the authorship of this document is primarily due to 948 the authors of RFC3450: Mike Luby, Jim Gemmel, Lorenzo Vicisano, 949 Luigi Rizzo and Jon Crowcroft. Vincent Roca, Justin Chapweske and 950 Roger Kermode also contributed to RFC3450. Additional thanks are due 951 to Vincent Roca and Rod Walsh for contributions to this update to 952 Proposed Standard. 954 8. Changes from RFC3450 956 This section summarises the changes that were made from the 957 Experimental version of this specification published as RFC3450 958 [RFC3450]: 960 o Update all references to the obsoleted RFC 2068 to RFC 2616 962 o Removed the 'Statement of Intent' from the introduction (The 963 statement of intent was meant to clarify the "Experimental" status 964 of RFC3450.) 966 o Removed the 'Intellectual Property Issues' Section and replaced 967 with a standard IPR Statement 969 o Remove material duplicated in LCT 971 o Update references for LCT and FEC Building Block to new versions 972 and align with changes in the FEC Building Block. 974 o Split normative and informative references 976 o Material applicable in a general LCT context, not just for ALC has 977 been moved to LCT 979 o The first bit of the "Protocol Specific Indication" in the LCT 980 Header is defined as a "Source Packet Indication". This is used 981 in the case that an FEC Scheme defines two FEC Payload ID formats, 982 one of which is for packets containing only source symbols which 983 can be processed by receivers that do not support FEC Decoding. 985 o Definition and IANA registration of the EXT_FTI LCT Header 986 Extension 988 9. References 990 9.1. Normative references 992 [I-D.ietf-rmt-bb-lct-revised] 993 Luby, M., Watson, M., and L. Vicisano, "Layered Coding 994 Transport (LCT) Building Block", 995 draft-ietf-rmt-bb-lct-revised-09 (work in progress), 996 March 2009. 998 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 999 August 1980. 1001 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1002 RFC 1112, August 1989. 1004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1005 Requirement Levels", BCP 14, RFC 2119, March 1997. 1007 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1008 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1009 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1011 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1012 Types", RFC 3023, January 2001. 1014 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate 1015 Control (WEBRC) Building Block", RFC 3738, April 2004. 1017 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1018 Internet Protocol", RFC 4301, December 2005. 1020 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1021 RFC 4303, December 2005. 1023 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1024 Description Protocol", RFC 4566, July 2006. 1026 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1027 Correction (FEC) Building Block", RFC 5052, August 2007. 1029 9.2. Informative references 1031 [I-D.ietf-msec-tesla-for-alc-norm] 1032 Roca, V., Francillon, A., and S. Faurite, "Use of TESLA in 1033 the ALC and NORM Protocols", 1034 draft-ietf-msec-tesla-for-alc-norm-07 (work in progress), 1035 December 2008. 1037 [I-D.ietf-rmt-simple-auth-for-alc-norm] 1038 Roca, V., "Simple Authentication Schemes for the ALC and 1039 NORM Protocols", 1040 draft-ietf-rmt-simple-auth-for-alc-norm-01 (work in 1041 progress), March 2009. 1043 [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF 1044 Criteria for Evaluating Reliable Multicast Transport and 1045 Application Protocols", RFC 2357, June 1998. 1047 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1048 Announcement Protocol", RFC 2974, October 2000. 1050 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 1051 Floyd, S., and M. Luby, "Reliable Multicast Transport 1052 Building Blocks for One-to-Many Bulk-Data Transfer", 1053 RFC 3048, January 2001. 1055 [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for 1056 Reliable Multicast Transport (RMT) Building Blocks and 1057 Protocol Instantiation documents", RFC 3269, April 2002. 1059 [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. 1060 Crowcroft, "Asynchronous Layered Coding (ALC) Protocol 1061 Instantiation", RFC 3450, December 2002. 1063 [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 1064 M., and J. Crowcroft, "The Use of Forward Error Correction 1065 (FEC) in Reliable Multicast", RFC 3453, December 2002. 1067 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 1068 Group Domain of Interpretation", RFC 3547, July 2003. 1070 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1071 Jacobson, "RTP: A Transport Protocol for Real-Time 1072 Applications", STD 64, RFC 3550, July 2003. 1074 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1075 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1076 RFC 3711, March 2004. 1078 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1079 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1080 August 2004. 1082 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 1083 "GSAKMP: Group Secure Association Key Management 1084 Protocol", RFC 4535, June 2006. 1086 Authors' Addresses 1088 Michael Luby 1089 Qualcomm Inc. 1090 3165 Kifer Road 1091 Santa Clara, CA 95051 1092 US 1094 Email: luby@qualcomm.com 1096 Mark Watson 1097 Qualcomm Inc. 1098 3165 Kifer Road 1099 Santa Clara, CA 95051 1100 US 1102 Email: watson@qualcomm.com 1104 Lorenzo Vicisano 1105 Qualcomm Inc. 1106 3165 Kifer Road 1107 Santa Clara, CA 95051 1108 US 1110 Email: vicisano@qualcomm.com