idnits 2.17.1 draft-ietf-rmt-sec-discussion-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document 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 (May 10, 2010) is 5097 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-rmt-flute-revised-11 -- 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: 0 errors (**), 0 flaws (~~), 2 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: November 11, 2010 INRIA 6 H. Asaeda 7 Keio University 8 May 10, 2010 10 Security and Reliable Multicast Transport Protocols: Discussions and 11 Guidelines 12 draft-ietf-rmt-sec-discussion-05 14 Abstract 16 This document describes general security considerations for the 17 Reliable Multicast Transport (RMT) Working Group set of building 18 blocks and protocols. An emphasis is placed on risks that might be 19 resolved in the scope of transport protocol design. However, 20 relevant security issues related to IP Multicast control-plane and 21 other concerns not strictly within the scope of reliable transport 22 protocol design are also discussed. The document also begins an 23 exploration of approaches that could be embraced to mitigate these 24 risks. The purpose of this document is to provide a consolidated 25 security discussion and provide a basis for further discussions and 26 potential resolution of any significant security issues that may 27 exist in the current set of RMT standards. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 11, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 1.1. Conventions Used in this Document . . . . . . . . . . . . 6 77 2. Quick Introduction to RMT Protocols and their Use . . . . . . 6 78 2.1. The Two Families of CDP . . . . . . . . . . . . . . . . . 6 79 2.2. RMT Protocol Characteristics . . . . . . . . . . . . . . . 7 80 2.3. Target Use Case Characteristics . . . . . . . . . . . . . 7 81 3. Some Security Threats . . . . . . . . . . . . . . . . . . . . 8 82 3.1. Control-Plane Attacks . . . . . . . . . . . . . . . . . . 9 83 3.1.1. Control Plane Monitoring . . . . . . . . . . . . . . . 9 84 3.1.2. Unauthorized (or Malicious) Group Membership . . . . . 10 85 3.2. Data-Plane Attacks . . . . . . . . . . . . . . . . . . . . 10 86 3.2.1. Rogue Traffic Generation . . . . . . . . . . . . . . . 11 87 3.2.2. Sender Message Spoofing . . . . . . . . . . . . . . . 11 88 3.2.3. Receiver Message Spoofing . . . . . . . . . . . . . . 12 89 3.2.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . 12 90 4. General Security Goals . . . . . . . . . . . . . . . . . . . . 13 91 4.1. Network Protection . . . . . . . . . . . . . . . . . . . . 14 92 4.2. Protocol Protection . . . . . . . . . . . . . . . . . . . 14 93 4.3. Content Protection . . . . . . . . . . . . . . . . . . . . 14 94 4.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 5. Elementary Security Techniques . . . . . . . . . . . . . . . . 15 96 6. Technological Building Blocks . . . . . . . . . . . . . . . . 17 97 6.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 6.1.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 17 99 6.1.2. Requirements . . . . . . . . . . . . . . . . . . . . . 18 100 6.1.3. Limitations . . . . . . . . . . . . . . . . . . . . . 18 101 6.2. Group MAC . . . . . . . . . . . . . . . . . . . . . . . . 19 102 6.2.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 19 103 6.2.2. Requirements . . . . . . . . . . . . . . . . . . . . . 19 104 6.2.3. Limitations . . . . . . . . . . . . . . . . . . . . . 19 105 6.3. Digital Signatures . . . . . . . . . . . . . . . . . . . . 19 106 6.3.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 19 107 6.3.2. Requirements . . . . . . . . . . . . . . . . . . . . . 20 108 6.3.3. Limitations . . . . . . . . . . . . . . . . . . . . . 20 109 6.4. TESLA . . . . . . . . . . . . . . . . . . . . . . . . . . 20 110 6.4.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 20 111 6.4.2. Requirements . . . . . . . . . . . . . . . . . . . . . 21 112 6.4.3. Limitations . . . . . . . . . . . . . . . . . . . . . 21 113 6.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 21 114 6.5.1. Requirements . . . . . . . . . . . . . . . . . . . . . 22 115 6.5.2. Limitations . . . . . . . . . . . . . . . . . . . . . 22 116 6.5.3. Source-Based and Receiver-Based Attacks . . . . . . . 22 117 6.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23 118 7. Security Infrastructure . . . . . . . . . . . . . . . . . . . 23 119 8. New Threats Introduced by the Security Scheme Itself . . . . . 24 120 9. Consequences for the RMT and MSEC Working Group . . . . . . . 24 121 9.1. RMT Transport Message Security Encapsulation Header . . . 24 122 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 123 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 124 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 125 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 126 13.1. Normative References . . . . . . . . . . . . . . . . . . . 25 127 13.2. Informative References . . . . . . . . . . . . . . . . . . 27 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 130 1. Introduction 132 The Reliable Multicast Transport (RMT) Working Group has produced a 133 set of building block (BB) and protocol instantiation (PI) 134 specifications for reliable multicast data transport. Some present 135 PIs defined within the scope of RMT include Asynchronous Layered 136 Coding (ALC) [RFC5775], NACK-Oriented Reliable Multicast (NORM) 137 [RFC5740], and the File Delivery over Unidirectional Transport 138 (FLUTE) [I-D.ietf-rmt-flute-revised] application that is built on top 139 of ALC. These can be considered "Content Delivery Protocols" (CDP) 140 as described in [Neumann05]. In this document, the term CDP will 141 refer indifferently to either ALC or NORM, with their associated BBs. 143 The use of these BBs and PIs raises some new security risks. For 144 instance, these protocols share a novel set of Forward Error 145 Correction (FEC) and congestion control building blocks that present 146 some new capabilities for Internet transport, but may also pose some 147 new security risks. Yet some security risks are not related to the 148 particular BBs used by the PIs, but are more general. Reliable 149 multicast transport sessions are expected to involve at least one 150 sender and multiple receivers. Thus, the risk of and avenues to 151 attack are implicitly greater than that of point-to-point (unicast) 152 transport sessions. Also the nature of IP multicast can expose other 153 coexistent network flows and services to risk if malicious users 154 exploit it. The classic Any-Source Multicast (ASM) [RFC1112] model 155 of multicast routing allows any host to join an IP multicast group 156 and send traffic to that group. This poses many potential security 157 challenges. And, while the emerging Source-Specific Multicast (SSM) 158 [RFC3569], [RFC4607] model that enables users to receive multicast 159 data sent only from specified sender(s) simplifies some challenges, 160 there are still specific issues. For instance, possible areas of 161 attack include those against the control plane where malicious hosts 162 join IP multicast groups to cause multicast traffic to be directed to 163 parts of the network where it is not needed or desired. This may 164 indirectly cause denial-of-service (DoS) to other network flows. 165 Also, attackers may transmit erroneous or corrupt messages to the 166 group or employ strategies such as replay attack within the "data 167 plane" of protocol operation. 169 The goals of this document are therefore to: 171 1. Define the possible general security goals: protecting the 172 network infrastructure, and/or the protocol, and/or the content, 173 and/or the user (e.g., its privacy); 175 2. List the possible elementary security services that will make it 176 possible to fulfill the general security goals. Some of these 177 services are generic (e.g., object and/or packet integrity), 178 while others are specific to RMT protocols (e.g., congestion 179 control specific security schemes); 181 3. List some technological building blocks and solutions that can 182 provide the desired security services; 184 4. Highlight the CDP and the use-case specificities that will impact 185 security. Indeed, the set of solutions proposed to fulfill the 186 security goals will greatly be impacted by these considerations; 188 In some cases, the existing RMT documents already discuss the risks 189 and outline approaches to solve them, at least partially. The 190 purpose of this document is to consolidate this content and provide a 191 basis for further discussion and potential resolution of any 192 significant security issues that may exist. 194 1.1. Conventions Used in this Document 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 198 document are to be interpreted as described in [RFC2119]. 200 2. Quick Introduction to RMT Protocols and their Use 202 2.1. The Two Families of CDP 204 The ALC and NORM classes of CDP are designed to reliably deliver 205 content to a group of multicast receivers. However, ALC and NORM 206 have a different set of features and limitations. ALC supports a 207 unidirectional delivery model where there is no feedback from the 208 receivers to senders. Reliability is achieved by the joint use of 209 carousel-based transmission techniques associated to FEC encoding to 210 recover from missing (erased) packets. 212 On the opposite, NORM achieves reliability by means of FEC encoding 213 (as with ALC) and feedback from the receivers. More specifically, 214 NORM leverages Negative Acknowledgement techniques to control the 215 senders' transmission of content. The advantage is that the sender 216 need not transmit any more information than necessary to satisfy the 217 receivers' need for fully reliable transfers. However, while NORM 218 specifies feedback control techniques to allow it to scale to large 219 group sizes, it is not as massively scalable as ALC. Additionally, 220 the NORM feedback control mechanisms add some header content and 221 protocol implementation complexity. 223 The appropriate choice of a CDP depends upon application needs, 224 deployment constraints, and network connectivity considerations. And 225 while there are many common security considerations for these two 226 classes of CDP, there are also some unique considerations for each. 228 2.2. RMT Protocol Characteristics 230 This section focuses on the RMT protocol characteristics that impact 231 the choice of the technological building blocks, and the way they can 232 be applied. Both ALC and NORM have been designed with receiver group 233 size scalability. While ALC targets massively scalable sessions 234 (e.g., millions of receivers), NORM is less ambitious, essentially 235 because of the use of feedback messages. 237 The ALC and NORM protocols also differ in the communication paths: 239 o sender to receivers: ALC and NORM, for bulk data transfer and 240 signaling messages; 242 o receivers to sender: NORM only, for feedback messages; 244 o receivers to receivers: NORM only for control messages; 246 Note that the fact ALC is capable of working on top of purely 247 unidirectional networks does not mean that no back-channel is 248 available (Section 2.3). 250 The NORM and ALC protocols support a variety of content delivery 251 models where transport may be carefully coordinated among the sender 252 and receivers or with looser coordination and interaction. This 253 leads to a number of different use cases for these protocols. 255 2.3. Target Use Case Characteristics 257 This section focuses on the target use cases and their special 258 characteristics. These details will impact both the choice of the 259 technological building blocks and the way they can be applied. One 260 can distinguish the following use case features: 262 o Purely unidirectional transport versus symmetric bidirectional 263 transport versus asymmetric bidirectional transport. Most of the 264 time, the amount of traffic flowing to the source is limited, and 265 one can overlook whether the transport channel is symmetric or 266 not. The nature of the underlying transport channel is of 267 paramount importance, since many security building blocks will 268 require a bidirectional communication; 270 o Massively scalable versus moderately scalable session. Here we do 271 not define precisely what the terms "massively scalable" and 272 "moderately scalable" mean. 274 o Known set of receivers versus unknown set of receivers: I.e., does 275 the source know at any point of time the set of receivers or not? 276 Of course, knowing the set of receivers is usually not compatible 277 with massively scalable sessions; 279 o Dynamic set of receivers versus fixed set of receivers: I.e., does 280 the source know at some point of time the maximum set of receivers 281 or will it evolve dynamically? 283 o High rate data flow versus small rate data flow: Some security 284 building blocks are CPU-intensive and are therefore incompatible 285 with high data rate sessions (e.g., solutions that digitally sign 286 all packets sent). 288 o Protocol stack available at both ends: A solution that requires 289 some unusual features within the protocol stack will not always be 290 usable. Some target environments (e.g., embedded systems) provide 291 a minimum set of features and extending them (e.g., to add IPsec) 292 is not necessarily realistic; 294 o Multicast routing and other layer-3 protocols in use: E.g., SSM 295 routing is often seen as one of the key service to improve the 296 security within multicast sessions, and some security building 297 blocks require specialized versions of layer-3 protocols (e.g., 298 IGMP/MLD with security extensions). In some cases these 299 assumptions might not be realistic. 301 Depending on the target goal and the associated security building 302 block used, other features might be of importance. For instance 303 TESLA requires a loose time synchronization between the source and 304 the receivers. Several possible techniques are available to provide 305 this, but some of them may be feasible only if the target use case 306 has the appropriate characteristics. 308 3. Some Security Threats 310 The IP architecture provides common access to notional control and 311 data planes to both end and intermediate systems. For the purposes 312 of discussion here, the "control plane" mechanisms are considered 313 those with message exchanges between end systems (typically 314 computers) and intermediate systems (typically routers) (or among 315 intermediate systems) while the "data plane" encompasses messages 316 exchanged among end systems, usually pertaining to the transfer of 317 application data. The security threats described here are introduced 318 within the taxonomy of control plane and data plane IP mechanisms. 320 3.1. Control-Plane Attacks 322 In this discussion, "control-plane" in the context of Internet 323 Protocol systems refers to signaling among end systems and 324 intermediate systems to facilitate routing and forwarding of packets. 325 For IP multicast, this notably includes Internet Group Management 326 Protocol (IGMP), Multicast Listener Discovery protocol (MLD), and 327 multicast routing protocol messaging. While control-plane attacks 328 may be considered outside of the scope of the transport protocol 329 specifications discussed here, it is important to understand the 330 potential impact of such attacks with respect to the deployment and 331 operation of these protocols. For example, awareness of possible IP 332 Multicast control-plane manipulation that can lead to unauthorized 333 (or unexpected) monitoring of data plane traffic by malicious users 334 may lead a transport application or protocol implementation to 335 support encryption to ensure data confidentiality and/or privacy. 336 Also, these types of attack also have bearing on assessing the real 337 risks of potentially more complex attacks against the transport 338 mechanisms themselves. In some cases, the solutions to these 339 control-plane risk areas may reduce the impact or possibility of some 340 data-plane attacks that are discussed in this document. 342 The presence of these types of attack may necessitate that policy- 343 based controls be embedded in routers to limit the distribution 344 (including transmission and reception) of multicast traffic (on a 345 group-wise and/or traffic volume basis) to different parts of the 346 network. Such policy-based controls are beyond the scope of the RMT 347 protocol specifications. However, such network protection mechanisms 348 may reduce the opportunities for or effectiveness of some of the 349 data-plane attacks discussed later. For example, reverse-path checks 350 can significantly limit opportunities for attackers to conduct replay 351 attacks when hosts actually do use IPsec. Also, future IP Multicast 352 control protocols may wish to consider providing security mechanism 353 to prevent unauthorized monitoring or manipulation of messages 354 related to group membership, routing, and activity. The sections 355 below describe some variants of control-plane attacks. 357 3.1.1. Control Plane Monitoring 359 While this may not be a direct attack on the transport system, it may 360 be possible for an attacker to gain useful information in advancing 361 attack goals by monitoring IP Multicast control plane traffic 362 including group membership and multicast routing information. 363 Identification of hosts and/or routers participating in specific 364 multicast groups may readily identify systems vulnerable to protocol- 365 specific exploitation. And, with regards to user privacy concerns, 366 such "side information" may be relevant to this emerging aspect of 367 network security as described in Section 4.4. 369 3.1.2. Unauthorized (or Malicious) Group Membership 371 One of the simplest attacks is that where a malicious host joins an 372 IP multicast group so that potentially unwanted traffic is routed to 373 the host's network interface. This type of attack can turn a 374 legitimate source of IP traffic into a "attacker" without requiring 375 any access privileges to the source host or routers involved. This 376 type of attack can be used for denial-of-service purposes or for the 377 real attacker (the malicious joiner) to gain access to the 378 information content being sent. Similarly, some routing protocols 379 may permit any sender (whether joined to the specific group or not) 380 to transmit messages to a multicast group. 382 It is possible that malicious hosts could also spoof IGMP/MLD 383 messages, joining groups posing as legitimate hosts (or spoof source 384 traffic from legitimate hosts). This may be done at intermediate 385 locations in the network or by hosts co-resident with the authorized 386 hosts on local area networks. Such spoofing could be done by raw 387 packet generation or with replay of previously-recorded control 388 messages. 390 For the sake of completeness, it should be noted that multicast 391 routing protocol control messaging may be subject to similar threats 392 if sufficient protocol security mechanisms are not enabled in the 393 routing infrastructure. [RFC4609] describes security threats to the 394 PIM-SM multicast routing infrastructures. 396 3.2. Data-Plane Attacks 398 This section discusses some types of active attacks that might be 399 conducted "in-band" with respect to the reliable multicast transport 400 protocol operating within the data plane of network data transfer. 401 I.e., the "data-plane" here refers to IP packets containing end-to- 402 end transport content to support the reliable multicast transfer. 403 The passive attack of unauthorized data-plan monitoring is discussed 404 above since such activity might be made possible by the 405 vulnerabilities of the IP Multicast control plane. To cover the two 406 classes of RMT protocols, the active data-plane attacks are 407 categorized as 1) those where the attacker generates messages posing 408 as a data sender, and 2) those where the attacker generates messages 409 posing as a receiver providing feedback to the sender(s) or group. 410 Additionally, a common threat to protocol operation is that of brute- 411 force, rogue packet generation. This is discussed briefly below, but 412 the more subtle attacks that might be conducted are given more 413 attention as those fall within the scope of the RMT transport 414 protocol design. Additionally, special consideration is given to 415 that of the "replay attack" [see Section 3.2.4], as it can be applied 416 across these different categories. 418 3.2.1. Rogue Traffic Generation 420 If an attacker is able to successfully inject packets into the 421 multicast distribution tree, one obvious denial-of-service attack is 422 for the attacker to generate a large volume of apparently 423 authenticate traffic (and if authentication mechanisms are used, a 424 "replay" attack strategy might be used). The impact of this type of 425 attack can be significant since the potential for routers to relay 426 the traffic to multiple portions of a networks (as compared to a 427 single unicast routing path). However, other than the amplified 428 negative impact to the network, this type of attack is no different 429 than what is possible with rogue unicast packet generation and 430 similar measures used to protect the network from such attacks could 431 be used to contain this type of brute-force attack. Of course, the 432 pragmatic question of whether current implementations of such 433 protection mechanisms support IP Multicast SHOULD be considered. 435 3.2.2. Sender Message Spoofing 437 Sender message spoofing attacks are applicable to both CDP: ALC 438 (sender-only transmission) and NORM (sender-receiver exchanges). 439 Without an authentication mechanism, an attacker can easily generate 440 sender messages that could disrupt a reliable multicast transfer 441 session. And with FEC-based transport mechanisms, a single packet 442 with an apparently-correct FEC payload identifier[RFC5052] but a 443 corrupted FEC payload could potentially render an entire block of 444 transported data invalid. Thus, a modest injection rate of corrupt 445 traffic could cause severe impairment of data transport. 446 Additionally, such invalid sender packets could convey out-of-bound 447 indices (e.g., bad symbol or block identifiers) that can lead to 448 buffer overflow exploits or similar issues in implementations that 449 insufficiently check for invalid data. 451 An indirect use of sender message spoofing would be to generate 452 messages that would cause receivers to take inappropriate congestion- 453 control action. In the case of the layered congestion control 454 mechanisms proposed for ALC use, this could lead to the receivers 455 erroneously leaving groups associated with higher bandwidth transport 456 layers and suffering unnecessarily low transport rates. Similarly, 457 receivers may be misled to join inappropriate groups directing 458 unwanted traffic to their part of the network. Attacks with similar 459 effect could be conducted against the TCP-Friendly Multicast 460 Congestion Control (TFMCC) [RFC4654] approach proposed for NORM 461 operation with spoofing of sender messages carrying congestion 462 control state to receivers. 464 3.2.3. Receiver Message Spoofing 466 These attacks are limited to CDP that use feedback from receivers in 467 the group to influence sender and other receiver operation. In the 468 NORM protocol, this includes negative-acknowledgement (NACK) messages 469 fed back to the sender to achieve reliable transfer, congestion 470 control feedback content, and the optional positive acknowledgement 471 features of the specification. It is also important to note that for 472 ASM operation, NORM receivers pay attention to the messages of other 473 receivers for the purpose of suppression to avoid feedback implosion 474 as group size grows large. 476 An attacker that can generate false feedback can manipulate the NORM 477 sender to unnecessarily transmit repair information and reduce the 478 goodput of the reliable transfer regardless of the sender's transmit 479 rate. Contrived congestion control feedback could also cause the 480 sender to transmit at an unfairly low rate. 482 As mentioned, spoofed receiver messaging may not be directed only at 483 senders, but also at receivers participating in the session. For 484 example, an attacker may direct phony receiver feedback messages to 485 selected receivers in the group causing those receivers to suppress 486 feedback that might have otherwise been transmitted. This attack 487 could compromise the ability of those receivers to achieve reliable 488 transfer. Also, suppressed congestion control feedback could cause 489 the sender to transmit at a rate unfair to those attacked receivers 490 if their fair congestion control rate were lower. 492 3.2.4. Replay Attacks 494 The infamous "replay attack" (injection of a previously transmitted 495 packet to one or more participants) is given special attention here 496 because of the special consequences it can have on RMT protocol 497 operation. Without specific protection mechanisms against replay 498 (e.g., duplicate message detection), it is possible for these attacks 499 to be successful even when security mechanisms such as packet 500 authentication and/or encryption are employed. 502 3.2.4.1. Replay of Sender Messages 504 Generally, replay of recent protocol messages from the sender will 505 not harm transport, and could potentially assist it, unless it is of 506 sufficient volume to result in the same type of impact as the "rogue 507 traffic generation" described above. However, it is possible that 508 replay of sufficiently old messages may cause receivers to think they 509 are "out of sync" with the sender and reset state, compromising the 510 transfer. Also, if sender transport data identifiers are reused 511 (object identifiers, FEC payload identifiers, etc), it is possible 512 that replay of old messages could corrupt data of a current transfer. 514 3.2.4.2. Replay of Receiver Messages 516 Replay of receiver messages are problematic for the NORM protocol, 517 because replay of NACK messages could cause the sender to 518 unnecessarily transmit repair information for an FEC coding block. 519 Similarly, the sender transmission rate might be manipulated by 520 replay of congestion control feedback messages from receivers in the 521 group. And the way that NORM senders estimate group round-trip 522 timing (GRTT) could allow a replay attack to manipulate the senders' 523 GRTT estimate to an unnecessarily large value, adding latency to the 524 reliable transport process. 526 4. General Security Goals 528 The term "security" is extremely vast and encompasses many different 529 meanings. The goal of this section is to clarify what "security" 530 means when considering the CDP defined in the IETF RMT working group. 531 However, the scope can also encompass additional applications, like 532 streaming applications. This section only focuses on the desired 533 general goals. The following sections will then discuss the possible 534 elementary services that will be required to fulfill these general 535 goals, as well as the underlying technological building blocks. 537 The possible final goals include, in decreasing order of importance: 539 o network protection: the goal is to protect the network from 540 attacks, no matter whether these attacks are voluntary (i.e., 541 launched by one or several attackers) or non voluntary (i.e., 542 caused by a misbehaving system, where "system" can designate a 543 building block, a protocol, an application, or a user); 545 o protocol protection: the goal is to protect the RMT protocol 546 itself, e.g., to avoid that a misbehaving receiver prevents other 547 receivers to get the content, no matter whether this is done 548 intentionally or not; 550 o content protection: to goal is to protect the content itself, for 551 instance to guaranty the integrity of the content, or to make sure 552 that only authorized clients can access the content; 554 o and user protection: the goal is often to protect the user 555 privacy. 557 4.1. Network Protection 559 Protecting the network is of course of primary importance. An 560 attacker should not be able to damage the whole infrastructure by 561 exploiting some features of the RMT protocol. Unfortunately, recent 562 past has shown that the multicast routing infrastructure is 563 relatively fragile, as well as the applications built on top of it. 564 Since the RMT protocols may use congestion control mechanisms to 565 regulate sender transmission rate, the protocol security features 566 should ensure that the sender may not be manipulated to transmit at 567 incorrect rates (most importantly not at an excessive rate) to any 568 parts of the receiver group. In the case of NORM, the security 569 mechanisms should ensure that the feedback suppression mechanisms are 570 protected to prevent badly-behaving network nodes from purposefully 571 causing feedback implosion. In the case of ALC, where layered 572 congestion control may be used via dynamic grou/layer membership, 573 this extends to considerations of excessive manipulation of the 574 multicast router control plane. 576 4.2. Protocol Protection 578 Protecting the protocols is also of importance, since the higher the 579 number of clients, the more serious the consequences of an attack. 580 This is all the more true as scalability is often one of the desired 581 goals of CDP. Ideally, receivers should be sufficiently isolated 582 from one another, so that a single misbehaving receiver does not 583 affect others. Similarly, an external attacker should not be able to 584 break the system, i.e., resulting in unreliable operation or delivery 585 of incorrect content. 587 4.3. Content Protection 589 The content itself should be protected when meaningful. This level 590 of security is often the concern of the content provider (and its 591 responsibility). For instance, in case of confidential (or non-free) 592 content, the typical solution consists in encrypting the content. It 593 can be done within the upper application, i.e., above the RMT 594 protocol, or within the transport system. 596 But other requirements may exist, like verifying the integrity of a 597 received object, or authenticating the sender of the received 598 packets. To that goal, one can rely on the use of building blocks 599 integrated within, or above, or beneath the RMT protocol. 601 One may also consider that offering the packet sender authentication 602 and content integrity services are basic requirements that should 603 fulfill any RMT system that operates within an open network, where 604 any attacker can easily inject spurious traffic in an ongoing NORM or 605 ALC session. In that case this goal is not the responsibility of the 606 content provider but the responsibility of the administrator who 607 deploys the RMT system itself. 609 4.4. Privacy 611 Finally the user should be protected, and more specifically its 612 privacy. In general, there is no privacy issue for data sender: the 613 data sender's address is announced to all prospective receivers prior 614 to their joins. Moreover receivers need to specify the source 615 address(es) as well as the IP multicast address in SSM communication 616 upon their subscription. The situation is different if we consider 617 receivers since their address should not be disclosed publicly. 619 Data receivers use IGMP or MLD protocols to notify their upstream 620 routers to join or leave IP multicast session. The recent IGMPv3 621 [RFC3376] and MLDv2 [RFC3810] do not adopt the "report suppression 622 mechanism". Report suppression makes the receiver host withdraw its 623 own report when the host hears a report scheduled to be sent from 624 other host joining the same group. Eliminating the report 625 suppression mechanism does not contribute to minimizing the number of 626 responses, but enables the router to keep track of host membership 627 status on a link. Due to this specification, operators who maintain 628 upstream routers that attach multicast data receiver can recognize 629 data receivers' addresses by tracing IGMP/MLD report messages. 630 Although such traced data may be useful for capacity planning or 631 accounting from operator's perspective, the detail information 632 including receivers' IP addresses should be carefully treated. 634 As described in Section 3.1.2, unauthorized users may spoof IGMP/MLD 635 query messages and trace receivers' addresses on the same LAN. 636 Currently, IGMP/MLD protocols do not protect this attack. It is 637 desired for these protocols to ignore invalid query messages and 638 provide receiver's privacy by some means. 640 5. Elementary Security Techniques 642 The goals defined in Section 4 will be fulfilled by means of 643 underlying security techniques, provided by one or several 644 technological building blocks. This section only focuses on these 645 elementary security techniques. Some general techniques 646 traditionally available are: 648 +-----------------+-------------------------------------------------+ 649 | Technique | Goal | 650 +-----------------+-------------------------------------------------+ 651 | packet | Enable session participants to verify that a | 652 | integrity | packet has not been inappropriately modified in | 653 | | transit. | 654 | packet source | Enable a receiver to verify the source of a | 655 | authentication | packet. | 656 | packet group | Enable a receiver to verify that a packet | 657 | authentication | originated or was modified only within the | 658 | | group and has not been modified by nonmembers | 659 | | in transit; Additionally, if attribution of any | 660 | | modifications by the group is required, certain | 661 | | group authentication mechanisms may provide | 662 | | this capability. | 663 | packet | Enable any third party to verify the source of | 664 | non-repudiation | a packet such that the source cannot repudiate | 665 | | having sent the packet. | 666 | packet | Enable a receiver to detect that a packet is | 667 | anti-replay | the same as a previously-received packet | 668 | object | Enable a receiver to verify the integrity of a | 669 | integrity | whole object. Such object integrity | 670 | | verification should be possible for any | 671 | | singular object or any composition of | 672 | | sub-objects which together constitute a larger | 673 | | object structure. | 674 | object source | Enable a receiver to verify the source of an | 675 | authentication | object. | 676 | object | Enable a source to guarantee that only | 677 | confidentiality | authorized receivers can access the object | 678 | | data. | 679 +-----------------+-------------------------------------------------+ 681 General Security Techniques 683 Some additional techniques are specific to the RMT protocols: 685 +---------------+---------------------------------------------------+ 686 | Technique | Goal | 687 +---------------+---------------------------------------------------+ 688 | congestion | Prevent an attacker from modifying the congestion | 689 | control | control protocol normal behavior (e.g., by | 690 | security | reducing the transmission (NORM) or reception | 691 | | (ALC) rate, or on the opposite increasing this | 692 | | rate up to a point where congestion occurs) | 693 | group | Ensure that only authorized receivers (as defined | 694 | management | by a certain group management policy) join the | 695 | | RMT session and possibly inform the source | 696 | backward | Prevent a new group member to access the | 697 | group secrecy | information in clear sent to the group before he | 698 | | joined the group | 699 | forward group | Prevent a former group member to access the | 700 | secrecy | information in clear sent to the group after he | 701 | | left the group | 702 +---------------+---------------------------------------------------+ 704 RMT-Specific Security Techniques 706 These techniques are usually achieved by means of one or several 707 technological building blocks. The target use case where the RMT 708 system will be deployed will greatly impact the choice of the 709 technological building block(s) used to provide these services, as 710 explained in Section 2.3. 712 6. Technological Building Blocks 714 Here is a list of techniques and building blocks that are likely to 715 fulfill one or several of the goals listed above: 717 o IPsec; 719 o Group MAC; 721 o Digital signatures; 723 o TESLA; 725 o SSM communication model; 727 Each of them is now quickly discussed. In particular we identify 728 what service it can offer, its limitations, and its field of 729 application (adequacy with respect to the CDP and the target use 730 case). 732 6.1. IPsec 734 6.1.1. Benefits 736 One direct approach using existing standards is to apply IPsec 737 [RFC4301] to achieve the following properties: 739 o source authentication and packet integrity (IPsec AH or ESP) 741 o confidentiality by means of encryption (IPsec ESP) 743 6.1.2. Requirements 745 It is expected that the approach to apply IPsec for reliable 746 multicast transport sessions is similar to that described for OSPFv3 747 security[RFC4552]. The following list proposes the IPsec 748 capabilities needed to support a similar approach to RMT protocol 749 security: 751 o Mode - Transport mode IPsec security is required; 753 o Selectors - source and destination addresses and ports, protocol. 755 o For some uses, preplaced, manual key support may be required to 756 support application deployment and operation. For automated key 757 management for group communication the Group Secure Association 758 Key Management Protocol (GSAKMP) described in [RFC4535] may be 759 used to emplace the keys for IPsec operation. 761 Note that a periodic rekeying procedure similar to that described in 762 RFC 4552 can also be applied with the additional benefit that the 763 reliable transport aspects of the CDP provide robustness to any 764 message loss that might occur due to ANY timing discrepancies among 765 the participants in the reliable multicast session. 767 6.1.3. Limitations 769 It should be noted that current IPsec implementations may not provide 770 the capability for anti-replay protection for multicast operation. 771 In the case of the NORM protocol, a sequence number is provided for 772 packet loss measurement to support congestion control operation. 773 This sequence number can also be used within a NORM implementation 774 for detecting duplicate (replayed) messages from sources (senders or 775 receivers) within the transport session group. In this way, 776 protection against replay attack can be achieved in conjunction with 777 the authentication and possibly confidentiality properties provided 778 by an IPsec encapsulation of NORM messages. NORM receivers generate 779 a very low volume of feedback traffic and it is expected that the 16- 780 bit sequence space provided by NORM will be sufficient for replay 781 attack protection. When a NORM session is long-lived, the limits of 782 the sender repair window are expected to provide protection from 783 replayed NACKs as they would typically be outside of the sender's 784 current repair window. It is suggested that IPsec implementations 785 that can provide anti-replay protection for IP Multicast traffic, 786 even when there are multiple senders within a group, be adopted. The 787 GSAKMP document has some discussion in this area. 789 6.2. Group MAC 791 6.2.1. Benefits 793 The use of Group MAC (Message Authentication Codes) within the CDP 794 [SimpleAuth] is a simple solution to provide a loss tolerant group 795 authentication/integrity service for all the packets exchanged within 796 a session (i.e., the packets generated by the session's sender and 797 the session's receivers). This scheme is easy to deploy since it 798 only requires that all the group members share a common secret key. 799 Because Group MAC heavily relies on fast symmetric cryptographic 800 building blocks, CPU processing remains limited both at the sender 801 and receiver sides, which makes it suitable for high data rate 802 transmissions, and/or lightweight terminals. Finally, the 803 transmission overhead remains limited. 805 6.2.2. Requirements 807 This scheme only requires that all the group members share a common 808 secret key, possibly associated to a re-keying mechanism (e.g., each 809 time the group membership changes, or on a periodic basis). 811 6.2.3. Limitations 813 This scheme cannot protect against attacks coming from inside the 814 group, where a group member impersonates the sender and sends forged 815 messages to other receivers. It only provides a group-level 816 authentication/integrity service, unlike the TESLA and Digital 817 Signature schemes. Note that the Group MAC and Digital Signature 818 schemes can be advantageously used together, as explained in 819 [SimpleAuth]. 821 6.3. Digital Signatures 823 6.3.1. Benefits 825 The use of Digital Signatures within the CDP [SimpleAuth] is a simple 826 solution to provide a loss-tolerant authentication/integrity service 827 for all the packets exchanged within a session (i.e., the packets 828 generated by the session's sender and the session's receivers). This 829 scheme is easy to deploy since it only requires that the participants 830 know the packet sender's public key, which can be achieved with 831 either Public Key Infrastructure (PKI) or by preplacement of these 832 keys. 834 6.3.2. Requirements 836 This scheme is easy to deploy since it requires only that the 837 participants know the packet sender's public key, which can be 838 achieved with either PKI or by preplacement of these keys. 840 6.3.3. Limitations 842 When RSA [RsaPaper] asymmetric cryptography is used, the digital 843 signatures approach has two major shortcomings: 845 o it is limited by high computational costs, especially at the 846 sender, and 848 o it is limited by high transmission overheads. 850 This scheme is well suited to low data rate flows, when transmission 851 overheads are not a major issue. For instance it can be used as a 852 complement to TESLA for the feedback traffic coming from the 853 session's receivers. The use of ECC ("Elliptic Curve Cryptography") 854 significantly relaxes these constraints, especially when seeking for 855 higher security levels. For instance, the following key size provide 856 equivalent security: 858 +--------------------+--------------+--------------+ 859 | Symmetric Key Size | RSA Key Size | ECC Key Size | 860 +--------------------+--------------+--------------+ 861 | 80 bits | 1024 bits | 160 bits | 862 | 112 bits | 2048 bits | 224 bits | 863 +--------------------+--------------+--------------+ 865 However in some cases, the Intellectual Property Rights (IPR) 866 considerations for ECC may limit its use, so the other techniques are 867 presented here as well. Note that the Group MAC and Digital 868 Signature schemes can be advantageously used together, as explained 869 in [SimpleAuth]. 871 6.4. TESLA 873 6.4.1. Benefits 875 The use of TESLA [RFC5776] within the CDP offers a loss tolerant, 876 lightweight, authentication/integrity service for the packets 877 generated by the session's sender. Depending on the time 878 synchronization and bootstrap methods used, TESLA can be compatible 879 with massively scalable sessions. Because TESLA heavily relies on 880 fast symmetric cryptographic building blocks, CPU processing remains 881 limited both at the sender and receiver sides, which makes it 882 suitable for high data rate transmissions, and/or lightweight 883 terminals. Finally, the transmission overhead remains 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. IANA Considerations 1068 This document has no actions for IANA. 1070 11. Security Considerations 1072 This document is a general discussion of security for the RMT 1073 protocol family. But specific security considerations are not 1074 applicable as this document does not introduce any new techniques. 1076 12. Acknowledgments 1078 The authors would like acknowledge Magnus Westerlund for stimulating 1079 the working group activity in this area. Additionally George Gross 1080 and Ran Atkinson contributed many ideas to the discussion here. 1082 13. References 1084 13.1. Normative References 1086 [I-D.ietf-rmt-flute-revised] 1087 Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 1088 "FLUTE - File Delivery over Unidirectional Transport", 1089 draft-ietf-rmt-flute-revised-11 (work in progress), 1090 March 2010. 1092 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1093 RFC 1112, August 1989. 1095 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1096 Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1113 Internet Protocol", RFC 4301, December 2005. 1115 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 1116 "GSAKMP: Group Secure Association Key Management 1117 Protocol", RFC 4535, June 2006. 1119 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 1120 for OSPFv3", RFC 4552, June 2006. 1122 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1123 IP", RFC 4607, August 2006. 1125 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 1126 Independent Multicast - Sparse Mode (PIM-SM) Multicast 1127 Routing Security Issues and Enhancements", RFC 4609, 1128 October 2006. 1130 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 1131 Congestion Control (TFMCC): Protocol Specification", 1132 RFC 4654, August 2006. 1134 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1135 Correction (FEC) Building Block", RFC 5052, August 2007. 1137 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 1138 "NACK-Oriented Reliable Multicast (NORM) Transport 1139 Protocol", RFC 5740, November 2009. 1141 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 1142 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 1143 April 2010. 1145 [RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed 1146 Efficient Stream Loss-Tolerant Authentication (TESLA) in 1147 the Asynchronous Layered Coding (ALC) and NACK-Oriented 1148 Reliable Multicast (NORM) Protocols", RFC 5776, 1149 April 2010. 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-02.txt (work 1155 in progress), October 2009. 1157 13.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/