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