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