idnits 2.17.1 draft-ietf-rmt-sec-discussion-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1197. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1208. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1215. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1221. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (November 3, 2008) is 5653 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-msec-tesla-for-alc-norm-06 == Outdated reference: A later version (-16) exists of draft-ietf-rmt-flute-revised-06 == Outdated reference: A later version (-10) exists of draft-ietf-rmt-pi-alc-revised-06 == Outdated reference: A later version (-14) exists of draft-ietf-rmt-pi-norm-revised-07 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) -- No information found for draft-ietf-rmt-simple_auth-for-alc-norm - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RMT B. Adamson 3 Internet-Draft Naval Research Laboratory 4 Intended status: Informational V. Roca 5 Expires: May 7, 2009 INRIA 6 H. Asaeda 7 Keio University 8 November 3, 2008 10 Security and Reliable Multicast Transport Protocols: Discussions and 11 Guidelines 12 draft-ietf-rmt-sec-discussion-03 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 7, 2009. 39 Abstract 41 This document describes general security considerations for the 42 Reliable Multicast Transport (RMT) Working Group set of building 43 blocks and protocols. An emphasis is placed on risks that might be 44 resolved in the scope of transport protocol design. However, 45 relevant security issues related to IP Multicast control-plane and 46 other concerns not strictly within the scope of reliable transport 47 protocol design are also discussed. The document also begins an 48 exploration of approaches that could be embraced to mitigate these 49 risks. The purpose of this document is to provide a consolidated 50 security discussion and provide a basis for further discussions and 51 potential resolution of any significant security issues that may 52 exist in the current set of RMT standards. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Conventions Used in this Document . . . . . . . . . . . . 5 58 2. Quick Introduction to RMT Protocols and their Use . . . . . . 5 59 2.1. The Two Families of CDP . . . . . . . . . . . . . . . . . 5 60 2.2. RMT Protocol Characteristics . . . . . . . . . . . . . . . 6 61 2.3. Target Use Case Characteristics . . . . . . . . . . . . . 6 62 3. Some Security Threats . . . . . . . . . . . . . . . . . . . . 7 63 3.1. Control-Plane Attacks . . . . . . . . . . . . . . . . . . 8 64 3.1.1. Control Plane Monitoring . . . . . . . . . . . . . . . 8 65 3.1.2. Unauthorized (or Malicious) Group Membership . . . . . 9 66 3.2. Data-Plane Attacks . . . . . . . . . . . . . . . . . . . . 9 67 3.2.1. Rogue Traffic Generation . . . . . . . . . . . . . . . 10 68 3.2.2. Sender Message Spoofing . . . . . . . . . . . . . . . 10 69 3.2.3. Receiver Message Spoofing . . . . . . . . . . . . . . 11 70 3.2.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . 11 71 4. General Security Goals . . . . . . . . . . . . . . . . . . . . 12 72 4.1. Network Protection . . . . . . . . . . . . . . . . . . . . 13 73 4.2. Protocol Protection . . . . . . . . . . . . . . . . . . . 13 74 4.3. Content Protection . . . . . . . . . . . . . . . . . . . . 13 75 4.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 5. Elementary Security Techniques . . . . . . . . . . . . . . . . 14 77 6. Technological Building Blocks . . . . . . . . . . . . . . . . 16 78 6.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 6.1.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 16 80 6.1.2. Requirements . . . . . . . . . . . . . . . . . . . . . 17 81 6.1.3. Limitations . . . . . . . . . . . . . . . . . . . . . 17 82 6.2. Group MAC . . . . . . . . . . . . . . . . . . . . . . . . 18 83 6.2.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 18 84 6.2.2. Requirements . . . . . . . . . . . . . . . . . . . . . 18 85 6.2.3. Limitations . . . . . . . . . . . . . . . . . . . . . 18 86 6.3. Digital Signatures . . . . . . . . . . . . . . . . . . . . 18 87 6.3.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 18 88 6.3.2. Requirements . . . . . . . . . . . . . . . . . . . . . 19 89 6.3.3. Limitations . . . . . . . . . . . . . . . . . . . . . 19 90 6.4. TESLA . . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 6.4.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 19 92 6.4.2. Requirements . . . . . . . . . . . . . . . . . . . . . 20 93 6.4.3. Limitations . . . . . . . . . . . . . . . . . . . . . 20 94 6.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 20 95 6.5.1. Requirements . . . . . . . . . . . . . . . . . . . . . 21 96 6.5.2. Limitations . . . . . . . . . . . . . . . . . . . . . 21 97 6.5.3. Source-Based and Receiver-Based Attacks . . . . . . . 21 98 6.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 7. Security Infrastructure . . . . . . . . . . . . . . . . . . . 22 100 8. New Threats Introduced by the Security Scheme Itself . . . . . 23 101 9. Consequences for the RMT and MSEC Working Group . . . . . . . 23 102 9.1. RMT Transport Message Security Encapsulation Header . . . 23 103 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 104 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 105 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 106 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 107 12.2. Informative References . . . . . . . . . . . . . . . . . . 26 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 109 Intellectual Property and Copyright Statements . . . . . . . . . . 27 111 1. Introduction 113 The Reliable Multicast Transport (RMT) Working Group has produced a 114 set of building block (BB) and protocol instantiation (PI) 115 specifications for reliable multicast data transport. Some present 116 PIs defined within the scope of RMT include Asynchronous Layered 117 Coding (ALC) [I-D.ietf-rmt-pi-alc-revised], NACK-Oriented Reliable 118 Multicast (NORM) [I-D.ietf-rmt-pi-norm-revised], and the File 119 Delivery over Unidirectional Transport (FLUTE) 120 [I-D.ietf-rmt-flute-revised] application that is built on top of ALC. 121 These can be considered "Content Delivery Protocols" (CDP) as 122 described in [Neumann05]. In this document, the term CDP will refer 123 indifferently to either ALC or NORM, with their associated BBs. 125 The use of these BBs and PIs raises some new security risks. For 126 instance, these protocols share a novel set of Forward Error 127 Correction (FEC) and congestion control building blocks that present 128 some new capabilities for Internet transport, but may also pose some 129 new security risks. Yet some security risks are not related to the 130 particular BBs used by the PIs, but are more general. Reliable 131 multicast transport sessions are expected to involve at least one 132 sender and multiple receivers. Thus, the risk of and avenues to 133 attack are implicitly greater than that of point-to-point (unicast) 134 transport sessions. Also the nature of IP multicast can expose other 135 coexistent network flows and services to risk if malicious users 136 exploit it. The classic Any-Source Multicast (ASM) [RFC1112] model 137 of multicast routing allows any host to join an IP multicast group 138 and send traffic to that group. This poses many potential security 139 challenges. And, while the emerging Source-Specific Multicast (SSM) 140 [RFC3569], [RFC4607] model that enables users to receive multicast 141 data sent only from specified sender(s) simplifies some challenges, 142 there are still specific issues. For instance, possible areas of 143 attack include those against the control plane where malicious hosts 144 join IP multicast groups to cause multicast traffic to be directed to 145 parts of the network where it is not needed or desired. This may 146 indirectly cause denial-of-service (DoS) to other network flows. 147 Also, attackers may transmit erroneous or corrupt messages to the 148 group or employ strategies such as replay attack within the "data 149 plane" of protocol operation. 151 The goals of this document are therefore to: 153 1. Define the possible general security goals: protecting the 154 network infrastructure, and/or the protocol, and/or the content, 155 and/or the user (e.g., its privacy); 157 2. List the possible elementary security services that will make it 158 possible to fulfill the general security goals. Some of these 159 services are generic (e.g., object and/or packet integrity), 160 while others are specific to RMT protocols (e.g., congestion 161 control specific security schemes); 163 3. List some technological building blocks and solutions that can 164 provide the desired security services; 166 4. Highlight the CDP and the use-case specificities that will impact 167 security. Indeed, the set of solutions proposed to fulfill the 168 security goals will greatly be impacted by these considerations; 170 In some cases, the existing RMT documents already discuss the risks 171 and outline approaches to solve them, at least partially. The 172 purpose of this document is to consolidate this content and provide a 173 basis for further discussion and potential resolution of any 174 significant security issues that may exist. 176 1.1. Conventions Used in this Document 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 2. Quick Introduction to RMT Protocols and their Use 184 2.1. The Two Families of CDP 186 The ALC and NORM classes of CDP are designed to reliably deliver 187 content to a group of multicast receivers. However, ALC and NORM 188 have a different set of features and limitations. ALC supports a 189 unidirectional delivery model where there is no feedback from the 190 receivers to senders. Reliability is achieved by the joint use of 191 carousel-based transmission techniques associated to FEC encoding to 192 recover from missing (erased) packets. 194 On the opposite, NORM achieves reliability by means of FEC encoding 195 (as with ALC) and feedback from the receivers. More specifically, 196 NORM leverages Negative Acknowledgement techniques to control the 197 senders' transmission of content. The advantage is that the sender 198 need not transmit any more information than necessary to satisfy the 199 receivers' need for fully reliable transfers. However, while NORM 200 specifies feedback control techniques to allow it to scale to large 201 group sizes, it is not as massively scalable as ALC. Additionally, 202 the NORM feedback control mechanisms add some header content and 203 protocol implementation complexity. 205 The appropriate choice of a CDP depends upon application needs, 206 deployment constraints, and network connectivity considerations. And 207 while there are many common security considerations for these two 208 classes of CDP, there are also some unique considerations for each. 210 2.2. RMT Protocol Characteristics 212 This section focuses on the RMT protocol characteristics that impact 213 the choice of the technological building blocks, and the way they can 214 be applied. Both ALC and NORM have been designed with receiver group 215 size scalability. While ALC targets massively scalable sessions 216 (e.g., millions of receivers), NORM is less ambitious, essentially 217 because of the use of feedback messages. 219 The ALC and NORM protocols also differ in the communication paths: 221 o sender to receivers: ALC and NORM, for bulk data transfer and 222 signaling messages; 224 o receivers to sender: NORM only, for feedback messages; 226 o receivers to receivers: NORM only for control messages; 228 Note that the fact ALC is capable of working on top of purely 229 unidirectional networks does not mean that no back-channel is 230 available (Section 2.3). 232 The NORM and ALC protocols support a variety of content delivery 233 models where transport may be carefully coordinated among the sender 234 and receivers or with looser coordination and interaction. This 235 leads to a number of different use cases for these protocols. 237 2.3. Target Use Case Characteristics 239 This section focuses on the target use cases and their special 240 characteristics. These details will impact both the choice of the 241 technological building blocks and the way they can be applied. One 242 can distinguish the following use case features: 244 o Purely unidirectional transport versus symmetric bidirectional 245 transport versus asymmetric bidirectional transport. Most of the 246 time, the amount of traffic flowing to the source is limited, and 247 one can overlook whether the transport channel is symmetric or 248 not. The nature of the underlying transport channel is of 249 paramount importance, since many security building blocks will 250 require a bidirectional communication; 252 o Massively scalable versus moderately scalable session. Here we do 253 not define precisely what the terms "massively scalable" and 254 "moderately scalable" mean. 256 o Known set of receivers versus unknown set of receivers: I.e., does 257 the source know at any point of time the set of receivers or not? 258 Of course, knowing the set of receivers is usually not compatible 259 with massively scalable sessions; 261 o Dynamic set of receivers versus fixed set of receivers: I.e., does 262 the source know at some point of time the maximum set of receivers 263 or will it evolve dynamically? 265 o High rate data flow versus small rate data flow: Some security 266 building blocks are CPU-intensive and are therefore incompatible 267 with high data rate sessions (e.g., solutions that digitally sign 268 all packets sent). 270 o Protocol stack available at both ends: A solution that requires 271 some unusual features within the protocol stack will not always be 272 usable. Some target environments (e.g., embedded systems) provide 273 a minimum set of features and extending them (e.g., to add IPsec) 274 is not necessarily realistic; 276 o Multicast routing and other layer-3 protocols in use: E.g., SSM 277 routing is often seen as one of the key service to improve the 278 security within multicast sessions, and some security building 279 blocks require specialized versions of layer-3 protocols (e.g., 280 IGMP/MLD with security extensions). In some cases these 281 assumptions might not be realistic. 283 Depending on the target goal and the associated security building 284 block used, other features might be of importance. For instance 285 TESLA requires a loose time synchronization between the source and 286 the receivers. Several possible techniques are available to provide 287 this, but some of them may be feasible only if the target use case 288 has the appropriate characteristics. 290 3. Some Security Threats 292 The IP architecture provides common access to notional control and 293 data planes to both end and intermediate systems. For the purposes 294 of discussion here, the "control plane" mechanisms are considered 295 those with message exchanges between end systems (typically 296 computers) and intermediate systems (typically routers) (or among 297 intermediate systems) while the "data plane" encompasses messages 298 exchanged among end systems, usually pertaining to the transfer of 299 application data. The security threats described here are introduced 300 within the taxonomy of control plane and data plane IP mechanisms. 302 3.1. Control-Plane Attacks 304 In this discussion, "control-plane" in the context of Internet 305 Protocol systems refers to signaling among end systems and 306 intermediate systems to facilitate routing and forwarding of packets. 307 For IP multicast, this notably includes Internet Group Management 308 Protocol (IGMP), Multicast Listener Discovery protocol (MLD), and 309 multicast routing protocol messaging. While control-plane attacks 310 may be considered outside of the scope of the transport protocol 311 specifications discussed here, it is important to understand the 312 potential impact of such attacks with respect to the deployment and 313 operation of these protocols. For example, awareness of possible IP 314 Multicast control-plane manipulation that can lead to unauthorized 315 (or unexpected) monitoring of data plane traffic by malicious users 316 may lead a transport application or protocol implementation to 317 support encryption to ensure data confidentiality and/or privacy. 318 Also, these types of attack also have bearing on assessing the real 319 risks of potentially more complex attacks against the transport 320 mechanisms themselves. In some cases, the solutions to these 321 control-plane risk areas may reduce the impact or possibility of some 322 data-plane attacks that are discussed in this document. 324 The presence of these types of attack may necessitate that policy- 325 based controls be embedded in routers to limit the distribution 326 (including transmission and reception) of multicast traffic (on a 327 group-wise and/or traffic volume basis) to different parts of the 328 network. Such policy-based controls are beyond the scope of the RMT 329 protocol specifications. However, such network protection mechanisms 330 may reduce the opportunities for or effectiveness of some of the 331 data-plane attacks discussed later. For example, reverse-path checks 332 can significantly limit opportunities for attackers to conduct replay 333 attacks when hosts actually do use IPsec. Also, future IP Multicast 334 control protocols may wish to consider providing security mechanism 335 to prevent unauthorized monitoring or manipulation of messages 336 related to group membership, routing, and activity. The sections 337 below describe some variants of control-plane attacks. 339 3.1.1. Control Plane Monitoring 341 While this may not be a direct attack on the transport system, it may 342 be possible for an attacker to gain useful information in advancing 343 attack goals by monitoring IP Multicast control plane traffic 344 including group membership and multicast routing information. 345 Identification of hosts and/or routers participating in specific 346 multicast groups may readily identify systems vulnerable to protocol- 347 specific exploitation. And, with regards to user privacy concerns, 348 such "side information" may be relevant to this emerging aspect of 349 network security as described in Section 4.4. 351 3.1.2. Unauthorized (or Malicious) Group Membership 353 One of the simplest attacks is that where a malicious host joins an 354 IP multicast group so that potentially unwanted traffic is routed to 355 the host's network interface. This type of attack can turn a 356 legitimate source of IP traffic into a "attacker" without requiring 357 any access privileges to the source host or routers involved. This 358 type of attack can be used for denial-of-service purposes or for the 359 real attacker (the malicious joiner) to gain access to the 360 information content being sent. Similarly, some routing protocols 361 may permit any sender (whether joined to the specific group or not) 362 to transmit messages to a multicast group. 364 It is possible that malicious hosts could also spoof IGMP/MLD 365 messages, joining groups posing as legitimate hosts (or spoof source 366 traffic from legitimate hosts). This may be done at intermediate 367 locations in the network or by hosts co-resident with the authorized 368 hosts on local area networks. Such spoofing could be done by raw 369 packet generation or with replay of previously-recorded control 370 messages. 372 For the sake of completeness, it should be noted that multicast 373 routing protocol control messaging may be subject to similar threats 374 if sufficient protocol security mechanisms are not enabled in the 375 routing infrastructure. [RFC4609] describes security threats to the 376 PIM-SM multicast routing infrastructures. 378 3.2. Data-Plane Attacks 380 This section discusses some types of active attacks that might be 381 conducted "in-band" with respect to the reliable multicast transport 382 protocol operating within the data plane of network data transfer. 383 I.e., the "data-plane" here refers to IP packets containing end-to- 384 end transport content to support the reliable multicast transfer. 385 The passive attack of unauthorized data-plan monitoring is discussed 386 above since such activity might be made possible by the 387 vulnerabilities of the IP Multicast control plane. To cover the two 388 classes of RMT protocols, the active data-plane attacks are 389 categorized as 1) those where the attacker generates messages posing 390 as a data sender, and 2) those where the attacker generates messages 391 posing as a receiver providing feedback to the sender(s) or group. 392 Additionally, a common threat to protocol operation is that of brute- 393 force, rogue packet generation. This is discussed briefly below, but 394 the more subtle attacks that might be conducted are given more 395 attention as those fall within the scope of the RMT transport 396 protocol design. Additionally, special consideration is given to 397 that of the "replay attack" [see Section 3.2.4], as it can be applied 398 across these different categories. 400 3.2.1. Rogue Traffic Generation 402 If an attacker is able to successfully inject packets into the 403 multicast distribution tree, one obvious denial-of-service attack is 404 for the attacker to generate a large volume of apparently 405 authenticate traffic (and if authentication mechanisms are used, a 406 "replay" attack strategy might be used). The impact of this type of 407 attack can be significant since the potential for routers to relay 408 the traffic to multiple portions of a networks (as compared to a 409 single unicast routing path). However, other than the amplified 410 negative impact to the network, this type of attack is no different 411 than what is possible with rogue unicast packet generation and 412 similar measures used to protect the network from such attacks could 413 be used to contain this type of brute-force attack. Of course, the 414 pragmatic question of whether current implementations of such 415 protection mechanisms support IP Multicast SHOULD be considered. 417 3.2.2. Sender Message Spoofing 419 Sender message spoofing attacks are applicable to both CDP: ALC 420 (sender-only transmission) and NORM (sender-receiver exchanges). 421 Without an authentication mechanism, an attacker can easily generate 422 sender messages that could disrupt a reliable multicast transfer 423 session. And with FEC-based transport mechanisms, a single packet 424 with an apparently-correct FEC payload identifier[RFC5052] but a 425 corrupted FEC payload could potentially render an entire block of 426 transported data invalid. Thus, a modest injection rate of corrupt 427 traffic could cause severe impairment of data transport. 428 Additionally, such invalid sender packets could convey out-of-bound 429 indices (e.g., bad symbol or block identifiers) that can lead to 430 buffer overflow exploits or similar issues in implementations that 431 insufficiently check for invalid data. 433 An indirect use of sender message spoofing would be to generate 434 messages that would cause receivers to take inappropriate congestion- 435 control action. In the case of the layered congestion control 436 mechanisms proposed for ALC use, this could lead to the receivers 437 erroneously leaving groups associated with higher bandwidth transport 438 layers and suffering unnecessarily low transport rates. Similarly, 439 receivers may be misled to join inappropriate groups directing 440 unwanted traffic to their part of the network. Attacks with similar 441 effect could be conducted against the TCP-Friendly Multicast 442 Congestion Control (TFMCC) [RFC4654] approach proposed for NORM 443 operation with spoofing of sender messages carrying congestion 444 control state to receivers. 446 3.2.3. Receiver Message Spoofing 448 These attacks are limited to CDP that use feedback from receivers in 449 the group to influence sender and other receiver operation. In the 450 NORM protocol, this includes negative-acknowledgement (NACK) messages 451 fed back to the sender to achieve reliable transfer, congestion 452 control feedback content, and the optional positive acknowledgement 453 features of the specification. It is also important to note that for 454 ASM operation, NORM receivers pay attention to the messages of other 455 receivers for the purpose of suppression to avoid feedback implosion 456 as group size grows large. 458 An attacker that can generate false feedback can manipulate the NORM 459 sender to unnecessarily transmit repair information and reduce the 460 goodput of the reliable transfer regardless of the sender's transmit 461 rate. Contrived congestion control feedback could also cause the 462 sender to transmit at an unfairly low rate. 464 As mentioned, spoofed receiver messaging may not be directed only at 465 senders, but also at receivers participating in the session. For 466 example, an attacker may direct phony receiver feedback messages to 467 selected receivers in the group causing those receivers to suppress 468 feedback that might have otherwise been transmitted. This attack 469 could compromise the ability of those receivers to achieve reliable 470 transfer. Also, suppressed congestion control feedback could cause 471 the sender to transmit at a rate unfair to those attacked receivers 472 if their fair congestion control rate were lower. 474 3.2.4. Replay Attacks 476 The infamous "replay attack" (injection of a previously transmitted 477 packet to one or more participants) is given special attention here 478 because of the special consequences it can have on RMT protocol 479 operation. Without specific protection mechanisms against replay 480 (e.g., duplicate message detection), it is possible for these attacks 481 to be successful even when security mechanisms such as packet 482 authentication and/or encryption are employed. 484 3.2.4.1. Replay of Sender Messages 486 Generally, replay of recent protocol messages from the sender will 487 not harm transport, and could potentially assist it, unless it is of 488 sufficient volume to result in the same type of impact as the "rogue 489 traffic generation" described above. However, it is possible that 490 replay of sufficiently old messages may cause receivers to think they 491 are "out of sync" with the sender and reset state, compromising the 492 transfer. Also, if sender transport data identifiers are reused 493 (object identifiers, FEC payload identifiers, etc), it is possible 494 that replay of old messages could corrupt data of a current transfer. 496 3.2.4.2. Replay of Receiver Messages 498 Replay of receiver messages are problematic for the NORM protocol, 499 because replay of NACK messages could cause the sender to 500 unnecessarily transmit repair information for an FEC coding block. 501 Similarly, the sender transmission rate might be manipulated by 502 replay of congestion control feedback messages from receivers in the 503 group. And the way that NORM senders estimate group round-trip 504 timing (GRTT) could allow a replay attack to manipulate the senders' 505 GRTT estimate to an unnecessarily large value, adding latency to the 506 reliable transport process. 508 4. General Security Goals 510 The term "security" is extremely vast and encompasses many different 511 meanings. The goal of this section is to clarify what "security" 512 means when considering the CDP defined in the IETF RMT working group. 513 However, the scope can also encompass additional applications, like 514 streaming applications. This section only focuses on the desired 515 general goals. The following sections will then discuss the possible 516 elementary services that will be required to fulfill these general 517 goals, as well as the underlying technological building blocks. 519 The possible final goals include, in decreasing order of importance: 521 o network protection: the goal is to protect the network from 522 attacks, no matter whether these attacks are voluntary (i.e., 523 launched by one or several attackers) or non voluntary (i.e., 524 caused by a misbehaving system, where "system" can designate a 525 building block, a protocol, an application, or a user); 527 o protocol protection: the goal is to protect the RMT protocol 528 itself, e.g., to avoid that a misbehaving receiver prevents other 529 receivers to get the content, no matter whether this is done 530 intentionally or not; 532 o content protection: to goal is to protect the content itself, for 533 instance to guaranty the integrity of the content, or to make sure 534 that only authorized clients can access the content; 536 o and user protection: the goal is often to protect the user 537 privacy. 539 4.1. Network Protection 541 Protecting the network is of course of primary importance. An 542 attacker should not be able to damage the whole infrastructure by 543 exploiting some features of the RMT protocol. Unfortunately, recent 544 past has shown that the multicast routing infrastructure is 545 relatively fragile, as well as the applications built on top of it. 546 Since the RMT protocols may use congestion control mechanisms to 547 regulate sender transmission rate, the protocol security features 548 should ensure that the sender may not be manipulated to transmit at 549 incorrect rates (most importantly not at an excessive rate) to any 550 parts of the receiver group. In the case of NORM, the security 551 mechanisms should ensure that the feedback suppression mechanisms are 552 protected to prevent badly-behaving network nodes from purposefully 553 causing feedback implosion. In the case of ALC, where layered 554 congestion control may be used via dynamic grou/layer membership, 555 this extends to considerations of excessive manipulation of the 556 multicast router control plane. 558 4.2. Protocol Protection 560 Protecting the protocols is also of importance, since the higher the 561 number of clients, the more serious the consequences of an attack. 562 This is all the more true as scalability is often one of the desired 563 goals of CDP. Ideally, receivers should be sufficiently isolated 564 from one another, so that a single misbehaving receiver does not 565 affect others. Similarly, an external attacker should not be able to 566 break the system, i.e., resulting in unreliable operation or delivery 567 of incorrect content. 569 4.3. Content Protection 571 The content itself should be protected when meaningful. This level 572 of security is often the concern of the content provider (and its 573 responsibility). For instance, in case of confidential (or non-free) 574 content, the typical solution consists in encrypting the content. It 575 can be done within the upper application, i.e., above the RMT 576 protocol, or within the transport system. 578 But other requirements may exist, like verifying the integrity of a 579 received object, or authenticating the sender of the received 580 packets. To that goal, one can rely on the use of building blocks 581 integrated within, or above, or beneath the RMT protocol. 583 One may also consider that offering the packet sender authentication 584 and content integrity services are basic requirements that should 585 fulfill any RMT system that operates within an open network, where 586 any attacker can easily inject spurious traffic in an ongoing NORM or 587 ALC session. In that case this goal is not the responsibility of the 588 content provider but the responsibility of the administrator who 589 deploys the RMT system itself. 591 4.4. Privacy 593 Finally the user should be protected, and more specifically its 594 privacy. In general, there is no privacy issue for data sender: the 595 data sender's address is announced to all prospective receivers prior 596 to their joins. Moreover receivers need to specify the source 597 address(es) as well as the IP multicast address in SSM communication 598 upon their subscription. The situation is different if we consider 599 receivers since their address should not be disclosed publicly. 601 Data receivers use IGMP or MLD protocols to notify their upstream 602 routers to join or leave IP multicast session. The recent IGMPv3 603 [RFC3376] and MLDv2 [RFC3810] do not adopt the "report suppression 604 mechanism". Report suppression makes the receiver host withdraw its 605 own report when the host hears a report scheduled to be sent from 606 other host joining the same group. Eliminating the report 607 suppression mechanism does not contribute to minimizing the number of 608 responses, but enables the router to keep track of host membership 609 status on a link. Due to this specification, operators who maintain 610 upstream routers that attach multicast data receiver can recognize 611 data receivers' addresses by tracing IGMP/MLD report messages. 612 Although such traced data may be useful for capacity planning or 613 accounting from operator's perspective, the detail information 614 including receivers' IP addresses should be carefully treated. 616 As described in Section 3.1.2, unauthorized users may spoof IGMP/MLD 617 query messages and trace receivers' addresses on the same LAN. 618 Currently, IGMP/MLD protocols do not protect this attack. It is 619 desired for these protocols to ignore invalid query messages and 620 provide receiver's privacy by some means. 622 5. Elementary Security Techniques 624 The goals defined in Section 4 will be fulfilled by means of 625 underlying security techniques, provided by one or several 626 technological building blocks. This section only focuses on these 627 elementary security techniques. Some general techniques 628 traditionally available are: 630 +-----------------+-------------------------------------------------+ 631 | Technique | Goal | 632 +-----------------+-------------------------------------------------+ 633 | packet | Enable session participants to verify that a | 634 | integrity | packet has not been inappropriately modified in | 635 | | transit. | 636 | packet source | Enable a receiver to verify the source of a | 637 | authentication | packet. | 638 | packet group | Enable a receiver to verify that a packet | 639 | authentication | originated or was modified only within the | 640 | | group and has not been modified by nonmembers | 641 | | in transit; Additionally, if attribution of any | 642 | | modifications by the group is required, certain | 643 | | group authentication mechanisms may provide | 644 | | this capability. | 645 | packet | Enable any third party to verify the source of | 646 | non-repudiation | a packet such that the source cannot repudiate | 647 | | having sent the packet. | 648 | packet | Enable a receiver to detect that a packet is | 649 | anti-replay | the same as a previously-received packet | 650 | object | Enable a receiver to verify the integrity of a | 651 | integrity | whole object. Such object integrity | 652 | | verification should be possible for any | 653 | | singular object or any composition of | 654 | | sub-objects which together constitute a larger | 655 | | object structure. | 656 | object source | Enable a receiver to verify the source of an | 657 | authentication | object. | 658 | object | Enable a source to guarantee that only | 659 | confidentiality | authorized receivers can access the object | 660 | | data. | 661 +-----------------+-------------------------------------------------+ 663 General Security Techniques 665 Some additional techniques are specific to the RMT protocols: 667 +---------------+---------------------------------------------------+ 668 | Technique | Goal | 669 +---------------+---------------------------------------------------+ 670 | congestion | Prevent an attacker from modifying the congestion | 671 | control | control protocol normal behavior (e.g., by | 672 | security | reducing the transmission (NORM) or reception | 673 | | (ALC) rate, or on the opposite increasing this | 674 | | rate up to a point where congestion occurs) | 675 | group | Ensure that only authorized receivers (as defined | 676 | management | by a certain group management policy) join the | 677 | | RMT session and possibly inform the source | 678 | backward | Prevent a new group member to access the | 679 | group secrecy | information in clear sent to the group before he | 680 | | joined the group | 681 | forward group | Prevent a former group member to access the | 682 | secrecy | information in clear sent to the group after he | 683 | | left the group | 684 +---------------+---------------------------------------------------+ 686 RMT-Specific Security Techniques 688 These techniques are usually achieved by means of one or several 689 technological building blocks. The target use case where the RMT 690 system will be deployed will greatly impact the choice of the 691 technological building block(s) used to provide these services, as 692 explained in Section 2.3. 694 6. Technological Building Blocks 696 Here is a list of techniques and building blocks that are likely to 697 fulfill one or several of the goals listed above: 699 o IPsec; 701 o Group MAC; 703 o Digital signatures; 705 o TESLA; 707 o SSM communication model; 709 Each of them is now quickly discussed. In particular we identify 710 what service it can offer, its limitations, and its field of 711 application (adequacy with respect to the CDP and the target use 712 case). 714 6.1. IPsec 716 6.1.1. Benefits 718 One direct approach using existing standards is to apply IPsec 719 [RFC2401] to achieve the following properties: 721 o source authentication and packet integrity (IPsec AH or ESP) 723 o confidentiality by means of encryption (IPsec ESP) 725 6.1.2. Requirements 727 It is expected that the approach to apply IPsec for reliable 728 multicast transport sessions is similar to that described for OSPFv3 729 security[RFC4552]. The following list proposes the IPsec 730 capabilities needed to support a similar approach to RMT protocol 731 security: 733 o Mode - Transport mode IPsec security is required; 735 o Selectors - source and destination addresses and ports, protocol. 737 o For some uses, preplaced, manual key support may be required to 738 support application deployment and operation. For automated key 739 management for group communication the Group Secure Association 740 Key Management Protocol (GSAKMP) described in [RFC4535] may be 741 used to emplace the keys for IPsec operation. 743 Note that a periodic rekeying procedure similar to that described in 744 RFC 4552 can also be applied with the additional benefit that the 745 reliable transport aspects of the CDP provide robustness to any 746 message loss that might occur due to ANY timing discrepancies among 747 the participants in the reliable multicast session. 749 6.1.3. Limitations 751 It should be noted that current IPsec implementations may not provide 752 the capability for anti-replay protection for multicast operation. 753 In the case of the NORM protocol, a sequence number is provided for 754 packet loss measurement to support congestion control operation. 755 This sequence number can also be used within a NORM implementation 756 for detecting duplicate (replayed) messages from sources (senders or 757 receivers) within the transport session group. In this way, 758 protection against replay attack can be achieved in conjunction with 759 the authentication and possibly confidentiality properties provided 760 by an IPsec encapsulation of NORM messages. NORM receivers generate 761 a very low volume of feedback traffic and it is expected that the 16- 762 bit sequence space provided by NORM will be sufficient for replay 763 attack protection. When a NORM session is long-lived, the limits of 764 the sender repair window are expected to provide protection from 765 replayed NACKs as they would typically be outside of the sender's 766 current repair window. It is suggested that IPsec implementations 767 that can provide anti-replay protection for IP Multicast traffic, 768 even when there are multiple senders within a group, be adopted. The 769 GSAKMP document has some discussion in this area. 771 6.2. Group MAC 773 6.2.1. Benefits 775 The use of Group MAC (Message Authentication Codes) within the CDP 776 [SimpleAuth] is a simple solution to provide a loss tolerant group 777 authentication/integrity service for all the packets exchanged within 778 a session (i.e., the packets generated by the session's sender and 779 the session's receivers). This scheme is easy to deploy since it 780 only requires that all the group members share a common secret key. 781 Because Group MAC heavily relies on fast symmetric cryptographic 782 building blocks, CPU processing remains limited both at the sender 783 and receiver sides, which makes it suitable for high data rate 784 transmissions, and/or lightweight terminals. Finally, the 785 transmission overhead remains limited. 787 6.2.2. Requirements 789 This scheme only requires that all the group members share a common 790 secret key, possibly associated to a re-keying mechanism (e.g., each 791 time the group membership changes, or on a periodic basis). 793 6.2.3. Limitations 795 This scheme cannot protect against attacks coming from inside the 796 group, where a group member impersonates the sender and sends forged 797 messages to other receivers. It only provides a group-level 798 authentication/integrity service, unlike the TESLA and Digital 799 Signature schemes. Note that the Group MAC and Digital Signature 800 schemes can be advantageously used together, as explained in 801 [SimpleAuth]. 803 6.3. Digital Signatures 805 6.3.1. Benefits 807 The use of Digital Signatures within the CDP [SimpleAuth] is a simple 808 solution to provide a loss-tolerant authentication/integrity service 809 for all the packets exchanged within a session (i.e., the packets 810 generated by the session's sender and the session's receivers). This 811 scheme is easy to deploy since it only requires that the participants 812 know the packet sender's public key, which can be achieved with 813 either Public Key Infrastructure (PKI) or by preplacement of these 814 keys. 816 6.3.2. Requirements 818 This scheme is easy to deploy since it requires only that the 819 participants know the packet sender's public key, which can be 820 achieved with either PKI or by preplacement of these keys. 822 6.3.3. Limitations 824 When RSA [RsaPaper] asymmetric cryptography is used, the digital 825 signatures approach has two major shortcomings: 827 o it is limited by high computational costs, especially at the 828 sender, and 830 o it is limited by high transmission overheads. 832 This scheme is well suited to low data rate flows, when transmission 833 overheads are not a major issue. For instance it can be used as a 834 complement to TESLA for the feedback traffic coming from the 835 session's receivers. The use of ECC ("Elliptic Curve Cryptography") 836 significantly relaxes these constraints, especially when seeking for 837 higher security levels. For instance, the following key size provide 838 equivalent security: 840 +--------------------+--------------+--------------+ 841 | Symmetric Key Size | RSA Key Size | ECC Key Size | 842 +--------------------+--------------+--------------+ 843 | 80 bits | 1024 bits | 160 bits | 844 | 112 bits | 2048 bits | 224 bits | 845 +--------------------+--------------+--------------+ 847 However in some cases, the Intellectual Property Rights (IPR) 848 considerations for ECC may limit its use, so the other techniques are 849 presented here as well. Note that the Group MAC and Digital 850 Signature schemes can be advantageously used together, as explained 851 in [SimpleAuth]. 853 6.4. TESLA 855 6.4.1. Benefits 857 The use of TESLA [I-D.ietf-msec-tesla-for-alc-norm] within the CDP 858 offers a loss tolerant, lightweight, authentication/integrity service 859 for the packets generated by the session's sender. Depending on the 860 time synchronization and bootstrap methods used, TESLA can be 861 compatible with massively scalable sessions. Because TESLA heavily 862 relies on fast symmetric cryptographic building blocks, CPU 863 processing remains limited both at the sender and receiver sides, 864 which makes it suitable for high data rate transmissions, and/or 865 lightweight terminals. Finally, the transmission overhead remains 866 limited. 868 6.4.2. Requirements 870 The security offered by TESLA relies heavily on time. Therefore the 871 session's sender and each receiver need to be loosely synchronized in 872 a secure way. To that purpose, several methods exist, depending on 873 the use case: direct time synchronization (which requires a 874 bidirectional transport channel), using a secure Network Time 875 Protocol (NTP) [RFC1305] infrastructure (which also requires a 876 bidirectional transport channel), or a Global Positioning System 877 (GPS) device, or a clock with a time-drift that is negligible in 878 front of the TESLA time accuracy requirements. 880 The various bootstrap parameters must also be communicated to the 881 receivers, using either an in-band or out-of-band mechanism, 882 sometimes requiring bidirectional communications. So, depending on 883 the time synchronization scheme and the bootstrap mechanism method, 884 TESLA can be used with either bidirectional or unidirectional 885 transport channels. 887 6.4.3. Limitations 889 One limitation is that TESLA does not protect the packets that are 890 generated by receivers, for instance the feedback packets of NORM. 891 These packets must be protected by other means. 893 Another limitation is that TESLA requires some buffering capabilities 894 at the receivers in order to enable the delayed authentication 895 feature. This is not considered though as a major issue in the 896 general case (e.g., FEC decoding of objects within an ALC session 897 already requires some buffering capabilities, that often exceed that 898 of TESLA), but it might be one in case of embedded environments. 900 6.5. Source-Specific Multicast 902 Source-Specific Multicast (SSM) [RFC3569], [RFC4607] amends the 903 classical Any-Source Multicast (ASM) model by creating logical IP 904 multicast "channels" that are defined by the multicast destination 905 address _and_ the specific source address(es). Thus for a given 906 "channel", only the specific source(s) can inject packets that are 907 distributed to the receivers. This form of multicast has group 908 management benefits since a source can independently control the 909 "channels" it creates. 911 6.5.1. Requirements 913 Use of SSM requires that the network intermediate systems explicitly 914 support it. Additionally, hosts operating systems are required to 915 support the IGMPv3/MLDv2 extensions for SSM, and the CDP 916 implementations need to support the IGMPv3/MLDv2 API, including 917 management of the "channel" identifiers. 919 6.5.2. Limitations 921 CDP such as NORM that use signaling from receivers to multicast 922 senders will need to use unicast addressing for feedback messages. 923 In the case of NORM, its timer-based feedback suppression requires 924 support of the sender NORM_CMD(REPAIR_ADV) message to control 925 receiver feedback. In some topologies, use of unicast feedback may 926 require some additional latency (increased backoff factor) for safe 927 operation. The security of the unicast feedback from the receivers 928 to sender will need to be addressed separately since the IP multicast 929 model, including SSM, does not provide the sender knowledge of 930 authorized group members. 932 6.5.3. Source-Based and Receiver-Based Attacks 934 The security threats are categorized into "source-based" and 935 "receiver-based" attacks [RFC4609]. In short, the former is a DoS 936 attack against the multicast networks, in which data is sent to 937 numerous and random group addresses, and the latter is a DoS attack 938 against multicast routers, in which innumerable IGMP/MLD joins are 939 sent from a client. 941 Regarding source-based attack, there are some security benefits in 942 SSM. Since data-plane traffic for an SSM "channel" is limited to 943 that of a single, specific source address, it is possible that 944 network intermediate systems may impose mechanism that prevent 945 injection of traffic to the group from inappropriate (perhaps 946 malicious) nodes. This can reduce the risk for denial-of-service and 947 some of the other attacks described in this document. While SSM 948 alone is not a complete security solution, it can simplify secure RMT 949 operation. 951 On the contrary, SSM is not robust against receiver-based attack. An 952 SSM capable router constructs a Shortest-Path Tree (SPT) with no 953 shared tree coordination. Therefore, even if a host triggers invalid 954 or unavailable channel subscriptions, the upstream router starts 955 establishing all SPTs with no intellectual decision. What is worse 956 is that these multicast routers cannot recognize the original router 957 that is attacked and cannot stop the attack itself. 959 6.6. Summary 961 The following table summarizes the pros/cons of each authentication/ 962 integrity scheme used at application/transport level (where "-" means 963 bad, "0" means neutral, and "+" means good): 965 +------------------+-------------+-------------+------------+-------+ 966 | | RSA Digital | ECC Digital | Group MAC | TESLA | 967 | | Signature | Signature | | | 968 +------------------+-------------+-------------+------------+-------+ 969 | True | Yes | Yes | No (group | Yes | 970 | authentication | | | security) | | 971 | and integrity | | | | | 972 | Immediate | Yes | Yes | Yes | No | 973 | authentication | | | | | 974 | Processing load | - | 0 | + | + | 975 | Transmission | - | 0 | + | + | 976 | overhead | | | | | 977 | Complexity | + | + | + | - | 978 +------------------+-------------+-------------+------------+-------+ 980 7. Security Infrastructure 982 Deploying the elementary technological building blocks often requires 983 that a security infrastructure exists. Such security infrastructure 984 can provide: 986 o Public Key Infrastructure (PKI) for trusted third party vetting 987 of, and vouching for, user identities. PKI also allows the 988 binding of public keys to users, usually by means of certificates. 990 o Group Key Management with rekeying schemes that are either 991 periodic or triggered by some higher level event. It is required 992 in particular when the group is dynamic and forward/backward 993 secrecy are important. This is also required to improve the 994 scalability of the CDP (since key management is done 995 automatically, using a key server topology), or the security 996 provided by the CDP (since the underlying cryptographic keys will 997 be changed frequently) 999 It is expected that some CDP deployments may use existing client- 1000 server security infrastructure models so that receivers may acquire 1001 any necessary security material and be authenticated or validated as 1002 needed for group participation. Then, the reliable delivery of 1003 session data content will be provided via the applicable RMT 1004 protocols. Note that in this case the security infrastructure itself 1005 may limit the scalability of the group size or other aspects of 1006 reliable multicast transfer. The IETF Multicast Security (MSEC) 1007 Working Group has developed some protocols that can be applied to 1008 achieve more scalable and effective group communication security 1009 infrastructure[RFC4046]. It is encouraged that these mechanisms be 1010 considered in the development of security for CDP. 1012 8. New Threats Introduced by the Security Scheme Itself 1014 Introducing a security scheme, as a side effect, can sometimes 1015 introduce new security threats. For instance, signing all packets 1016 with asymmetric cryptographic schemes (to provide a source 1017 authentication/content integrity/anti-replay service) opens the door 1018 to DoS attacks. Indeed, verifying asymmetric-based cryptographic 1019 signatures is a CPU intensive task. Therefore an attacker can easily 1020 overload a receiver (or a sender in case of NORM) by injecting a 1021 significant number of faked packets. 1023 9. Consequences for the RMT and MSEC Working Group 1025 To meet the goals outlined in this document, it is expected that the 1026 RMT and MSEC Working Groups may need to develop some supporting 1027 protocol security mechanisms. It is also possible to cooperate with 1028 the Multicast Backbone (MBONE) Deployment (MBONED) Working Group for 1029 defining operational considerations. 1031 9.1. RMT Transport Message Security Encapsulation Header 1033 An alternative approach to using IPsec to provide the necessary 1034 properties to protect RMT protocol operation from the application 1035 attacks described earlier, is to extend the RMT protocol message set 1036 to include a message encapsulation option. This encapsulation header 1037 could be used to provide authentication, confidentiality, and anti- 1038 replay protection as needed. Since this would be independent of the 1039 IP layer, the header might need to provide a source identifier to be 1040 used as a "selector" for recalling security state (including 1041 authentication certificate(s), sequence state, etc) for a given 1042 message. In the case of the NORM protocol, a "NormNodeId" field 1043 exists that could be used for this purpose. In the case of ALC, the 1044 security encapsulation mechanism would need to add this function. 1045 The security encapsulation mechanism, although resident "above" the 1046 IP layer, could use GSAKMP [RFC4535] or a similar approach for 1047 automated key management. 1049 10. Security Considerations 1051 This document is a general discussion of security for the RMT 1052 protocol family. But specific security considerations are not 1053 applicable as this document does not introduce any new techniques. 1055 11. Acknowledgments 1057 The authors would like acknowledge Magnus Westerlund for stimulating 1058 the working group activity in this area. Additionally George Gross 1059 and Ran Atkinson contributed many ideas to the discussion here. 1061 12. References 1063 12.1. Normative References 1065 [I-D.ietf-msec-tesla-for-alc-norm] 1066 Roca, V., Francillon, A., and S. Faurite, "Use of TESLA in 1067 the ALC and NORM Protocols", 1068 draft-ietf-msec-tesla-for-alc-norm-06 (work in progress), 1069 October 2008. 1071 [I-D.ietf-rmt-flute-revised] 1072 Luby, M., Lehtonen, R., Roca, V., and T. Paila, "FLUTE - 1073 File Delivery over Unidirectional Transport", 1074 draft-ietf-rmt-flute-revised-06 (work in progress), 1075 September 2008. 1077 [I-D.ietf-rmt-pi-alc-revised] 1078 Luby, M., Watson, M., and L. Vicisano, "Asynchronous 1079 Layered Coding (ALC) Protocol Instantiation", 1080 draft-ietf-rmt-pi-alc-revised-06 (work in progress), 1081 November 2008. 1083 [I-D.ietf-rmt-pi-norm-revised] 1084 Adamson, B., Bormann, C., London, U., and J. Macker, 1085 "NACK-Oriented Reliable Multicast Protocol", 1086 draft-ietf-rmt-pi-norm-revised-07 (work in progress), 1087 October 2008. 1089 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1090 RFC 1112, August 1989. 1092 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1093 Requirement Levels", BCP 14, RFC 2119, March 1997. 1095 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1096 Internet Protocol", RFC 2401, November 1998. 1098 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1099 Thyagarajan, "Internet Group Management Protocol, Version 1100 3", RFC 3376, October 2002. 1102 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 1103 Multicast (SSM)", RFC 3569, July 2003. 1105 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1106 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1108 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 1109 "Multicast Security (MSEC) Group Key Management 1110 Architecture", RFC 4046, April 2005. 1112 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 1113 "GSAKMP: Group Secure Association Key Management 1114 Protocol", RFC 4535, June 2006. 1116 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 1117 for OSPFv3", RFC 4552, June 2006. 1119 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1120 IP", RFC 4607, August 2006. 1122 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 1123 Independent Multicast - Sparse Mode (PIM-SM) Multicast 1124 Routing Security Issues and Enhancements", RFC 4609, 1125 October 2006. 1127 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 1128 Congestion Control (TFMCC): Protocol Specification", 1129 RFC 4654, August 2006. 1131 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1132 Correction (FEC) Building Block", RFC 5052, August 2007. 1134 [SimpleAuth] 1135 Roca, V., "Simple Authentication Schemes for the ALC and 1136 NORM Protocols", Internet 1137 Draft draft-ietf-rmt-simple_auth-for-alc-norm-00.txt (work 1138 in progress), October 2008. 1140 12.2. Informative References 1142 [Neumann05] 1143 Neumann, C., Roca, V., and R. Walsh, "Large Scale Content 1144 Distribution Protocols", ACM Computer Communications 1145 Review (CCR) Vol. 35 No. 5, October 2005. 1147 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1148 Specification, Implementation", RFC 1305, March 1992. 1150 [RsaPaper] 1151 Rivest, R., Shamir, A., and L. Adleman, "A Method for 1152 Obtaining Digital Signatures and Public-Key 1153 Cryptosystems", Communications of the ACM 21, pp. 120-126, 1154 1978. 1156 Authors' Addresses 1158 Brian Adamson 1159 Naval Research Laboratory 1160 Washington, DC 20375 1161 USA 1163 Email: adamson@itd.nrl.navy.mil 1164 URI: http://cs.itd.nrl.navy.mil 1166 Vincent Roca 1167 INRIA 1168 Montbonnot 38334 1169 France 1171 Email: vincent.roca@inria.fr 1172 URI: http://planete.inrialpes.fr/~roca/ 1174 Hitoshi Asaeda 1175 Keio University 1176 5322 Endo 1177 Fujisawa, Kanagawa 252-8520 1178 Japan 1180 Email: asaeda@wide.ad.jp 1181 URI: http://www.sfc.wide.ad.jp/~asaeda/ 1183 Full Copyright Statement 1185 Copyright (C) The IETF Trust (2008). 1187 This document is subject to the rights, licenses and restrictions 1188 contained in BCP 78, and except as set forth therein, the authors 1189 retain all their rights. 1191 This document and the information contained herein are provided on an 1192 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1193 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1194 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1195 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1196 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1197 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1199 Intellectual Property 1201 The IETF takes no position regarding the validity or scope of any 1202 Intellectual Property Rights or other rights that might be claimed to 1203 pertain to the implementation or use of the technology described in 1204 this document or the extent to which any license under such rights 1205 might or might not be available; nor does it represent that it has 1206 made any independent effort to identify any such rights. Information 1207 on the procedures with respect to rights in RFC documents can be 1208 found in BCP 78 and BCP 79. 1210 Copies of IPR disclosures made to the IETF Secretariat and any 1211 assurances of licenses to be made available, or the result of an 1212 attempt made to obtain a general license or permission for the use of 1213 such proprietary rights by implementers or users of this 1214 specification can be obtained from the IETF on-line IPR repository at 1215 http://www.ietf.org/ipr. 1217 The IETF invites any interested party to bring to its attention any 1218 copyrights, patents or patent applications, or other proprietary 1219 rights that may cover technology that may be required to implement 1220 this standard. Please address the information to the IETF at 1221 ietf-ipr@ietf.org.