idnits 2.17.1 draft-ietf-rmt-sec-discussion-06.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 (March 14, 2011) is 4793 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-12 == Outdated reference: A later version (-06) exists of draft-ietf-rmt-simple-auth-for-alc-norm-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: September 15, 2011 INRIA 6 H. Asaeda 7 Keio University 8 March 14, 2011 10 Security and Reliable Multicast Transport Protocols: Discussions and 11 Guidelines 12 draft-ietf-rmt-sec-discussion-06 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 September 15, 2011. 46 Copyright Notice 48 Copyright (c) 2011 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 Simple Authentication Schemes for the ALC and NORM Protocols 795 [I-D.ietf-rmt-simple-auth-for-alc-norm] is a simple solution to 796 provide a loss tolerant group authentication/integrity service for 797 all the packets exchanged within a session (i.e., the packets 798 generated by the session's sender and the session's receivers). This 799 scheme is easy to deploy since it only requires that all the group 800 members share a common secret key. Because Group MAC heavily relies 801 on fast symmetric cryptographic building blocks, CPU processing 802 remains limited both at the sender and receiver sides, which makes it 803 suitable for high data rate transmissions, and/or lightweight 804 terminals. Finally, the transmission overhead remains limited. 806 6.2.2. Requirements 808 This scheme only requires that all the group members share a common 809 secret key, possibly associated to a re-keying mechanism (e.g., each 810 time the group membership changes, or on a periodic basis). 812 6.2.3. Limitations 814 This scheme cannot protect against attacks coming from inside the 815 group, where a group member impersonates the sender and sends forged 816 messages to other receivers. It only provides a group-level 817 authentication/integrity service, unlike the TESLA and Digital 818 Signature schemes. Note that the Group MAC and Digital Signature 819 schemes can be advantageously used together, as explained in Simple 820 Authentication Schemes for the ALC and NORM Protocols 821 [I-D.ietf-rmt-simple-auth-for-alc-norm]. 823 6.3. Digital Signatures 825 6.3.1. Benefits 827 The use of Digital Signatures within the CDP Simple Authentication 828 Schemes for the ALC and NORM Protocols 829 [I-D.ietf-rmt-simple-auth-for-alc-norm] is a simple solution to 830 provide a loss-tolerant authentication/integrity service for all the 831 packets exchanged within a session (i.e., the packets generated by 832 the session's sender and the session's receivers). This scheme is 833 easy to deploy since it only requires that the participants know the 834 packet sender's public key, which can be achieved with either Public 835 Key Infrastructure (PKI) or by preplacement of these keys. 837 6.3.2. Requirements 839 This scheme is easy to deploy since it requires only that the 840 participants know the packet sender's public key, which can be 841 achieved with either PKI or by preplacement of these keys. 843 6.3.3. Limitations 845 When RSA [RsaPaper] asymmetric cryptography is used, the digital 846 signatures approach has two major shortcomings: 848 o it is limited by high computational costs, especially at the 849 sender, and 851 o it is limited by high transmission overheads. 853 This scheme is well suited to low data rate flows, when transmission 854 overheads are not a major issue. For instance it can be used as a 855 complement to TESLA for the feedback traffic coming from the 856 session's receivers. The use of ECC ("Elliptic Curve Cryptography") 857 significantly relaxes these constraints, especially when seeking for 858 higher security levels. For instance, the following key size provide 859 equivalent security: 861 +--------------------+--------------+--------------+ 862 | Symmetric Key Size | RSA Key Size | ECC Key Size | 863 +--------------------+--------------+--------------+ 864 | 80 bits | 1024 bits | 160 bits | 865 | 112 bits | 2048 bits | 224 bits | 866 +--------------------+--------------+--------------+ 868 However in some cases, the Intellectual Property Rights (IPR) 869 considerations for ECC may limit its use, so the other techniques are 870 presented here as well. Note that the Group MAC and Digital 871 Signature schemes can be advantageously used together, as explained 872 in Simple Authentication Schemes for the ALC and NORM Protocols 873 [I-D.ietf-rmt-simple-auth-for-alc-norm]. 875 6.4. TESLA 877 6.4.1. Benefits 879 The use of TESLA [RFC5776] within the CDP offers a loss tolerant, 880 lightweight, authentication/integrity service for the packets 881 generated by the session's sender. Depending on the time 882 synchronization and bootstrap methods used, TESLA can be compatible 883 with massively scalable sessions. Because TESLA heavily relies on 884 fast symmetric cryptographic building blocks, CPU processing remains 885 limited both at the sender and receiver sides, which makes it 886 suitable for high data rate transmissions, and/or lightweight 887 terminals. Finally, the transmission overhead remains limited. 889 6.4.2. Requirements 891 The security offered by TESLA relies heavily on time. Therefore the 892 session's sender and each receiver need to be loosely synchronized in 893 a secure way. To that purpose, several methods exist, depending on 894 the use case: direct time synchronization (which requires a 895 bidirectional transport channel), using a secure Network Time 896 Protocol (NTP) [RFC5905] infrastructure (which also requires a 897 bidirectional transport channel), or a Global Positioning System 898 (GPS) device, or a clock with a time-drift that is negligible in 899 front of the TESLA time accuracy requirements. 901 The various bootstrap parameters must also be communicated to the 902 receivers, using either an in-band or out-of-band mechanism, 903 sometimes requiring bidirectional communications. So, depending on 904 the time synchronization scheme and the bootstrap mechanism method, 905 TESLA can be used with either bidirectional or unidirectional 906 transport channels. 908 6.4.3. Limitations 910 One limitation is that TESLA does not protect the packets that are 911 generated by receivers, for instance the feedback packets of NORM. 912 These packets must be protected by other means. 914 Another limitation is that TESLA requires some buffering capabilities 915 at the receivers in order to enable the delayed authentication 916 feature. This is not considered though as a major issue in the 917 general case (e.g., FEC decoding of objects within an ALC session 918 already requires some buffering capabilities, that often exceed that 919 of TESLA), but it might be one in case of embedded environments. 921 6.5. Source-Specific Multicast 923 Source-Specific Multicast (SSM) [RFC3569], [RFC4607] amends the 924 classical Any-Source Multicast (ASM) model by creating logical IP 925 multicast "channels" that are defined by the multicast destination 926 address _and_ the specific source address(es). Thus for a given 927 "channel", only the specific source(s) can inject packets that are 928 distributed to the receivers. This form of multicast has group 929 management benefits since a source can independently control the 930 "channels" it creates. 932 6.5.1. Requirements 934 Use of SSM requires that the network intermediate systems explicitly 935 support it. Additionally, hosts operating systems are required to 936 support the IGMPv3/MLDv2 extensions for SSM, and the CDP 937 implementations need to support the IGMPv3/MLDv2 API, including 938 management of the "channel" identifiers. 940 6.5.2. Limitations 942 CDP such as NORM that use signaling from receivers to multicast 943 senders will need to use unicast addressing for feedback messages. 944 In the case of NORM, its timer-based feedback suppression requires 945 support of the sender NORM_CMD(REPAIR_ADV) message to control 946 receiver feedback. In some topologies, use of unicast feedback may 947 require some additional latency (increased backoff factor) for safe 948 operation. The security of the unicast feedback from the receivers 949 to sender will need to be addressed separately since the IP multicast 950 model, including SSM, does not provide the sender knowledge of 951 authorized group members. 953 6.5.3. Source-Based and Receiver-Based Attacks 955 The security threats are categorized into "source-based" and 956 "receiver-based" attacks [RFC4609]. In short, the former is a DoS 957 attack against the multicast networks, in which data is sent to 958 numerous and random group addresses, and the latter is a DoS attack 959 against multicast routers, in which innumerable IGMP/MLD joins are 960 sent from a client. 962 Regarding source-based attack, there are some security benefits in 963 SSM. Since data-plane traffic for an SSM "channel" is limited to 964 that of a single, specific source address, it is possible that 965 network intermediate systems may impose mechanism that prevent 966 injection of traffic to the group from inappropriate (perhaps 967 malicious) nodes. This can reduce the risk for denial-of-service and 968 some of the other attacks described in this document. While SSM 969 alone is not a complete security solution, it can simplify secure RMT 970 operation. 972 On the contrary, SSM is not robust against receiver-based attack. An 973 SSM capable router constructs a Shortest-Path Tree (SPT) with no 974 shared tree coordination. Therefore, even if a host triggers invalid 975 or unavailable channel subscriptions, the upstream router starts 976 establishing all SPTs with no intellectual decision. What is worse 977 is that these multicast routers cannot recognize the original router 978 that is attacked and cannot stop the attack itself. 980 6.6. Summary 982 The following table summarizes the pros/cons of each authentication/ 983 integrity scheme used at application/transport level (where "-" means 984 bad, "0" means neutral, and "+" means good): 986 +------------------+-------------+-------------+------------+-------+ 987 | | RSA Digital | ECC Digital | Group MAC | TESLA | 988 | | Signature | Signature | | | 989 +------------------+-------------+-------------+------------+-------+ 990 | True | Yes | Yes | No (group | Yes | 991 | authentication | | | security) | | 992 | and integrity | | | | | 993 | Immediate | Yes | Yes | Yes | No | 994 | authentication | | | | | 995 | Processing load | - | 0 | + | + | 996 | Transmission | - | 0 | + | + | 997 | overhead | | | | | 998 | Complexity | + | + | + | - | 999 +------------------+-------------+-------------+------------+-------+ 1001 7. Security Infrastructure 1003 Deploying the elementary technological building blocks often requires 1004 that a security infrastructure exists. Such security infrastructure 1005 can provide: 1007 o Public Key Infrastructure (PKI) for trusted third party vetting 1008 of, and vouching for, user identities. PKI also allows the 1009 binding of public keys to users, usually by means of certificates. 1011 o Group Key Management with rekeying schemes that are either 1012 periodic or triggered by some higher level event. It is required 1013 in particular when the group is dynamic and forward/backward 1014 secrecy are important. This is also required to improve the 1015 scalability of the CDP (since key management is done 1016 automatically, using a key server topology), or the security 1017 provided by the CDP (since the underlying cryptographic keys will 1018 be changed frequently) 1020 It is expected that some CDP deployments may use existing client- 1021 server security infrastructure models so that receivers may acquire 1022 any necessary security material and be authenticated or validated as 1023 needed for group participation. Then, the reliable delivery of 1024 session data content will be provided via the applicable RMT 1025 protocols. Note that in this case the security infrastructure itself 1026 may limit the scalability of the group size or other aspects of 1027 reliable multicast transfer. The IETF Multicast Security (MSEC) 1028 Working Group has developed some protocols that can be applied to 1029 achieve more scalable and effective group communication security 1030 infrastructure[RFC4046]. It is encouraged that these mechanisms be 1031 considered in the development of security for CDP. 1033 8. New Threats Introduced by the Security Scheme Itself 1035 Introducing a security scheme, as a side effect, can sometimes 1036 introduce new security threats. For instance, signing all packets 1037 with asymmetric cryptographic schemes (to provide a source 1038 authentication/content integrity/anti-replay service) opens the door 1039 to DoS attacks. Indeed, verifying asymmetric-based cryptographic 1040 signatures is a CPU intensive task. Therefore an attacker can easily 1041 overload a receiver (or a sender in case of NORM) by injecting a 1042 significant number of faked packets. 1044 9. Consequences for the RMT and MSEC Working Group 1046 To meet the goals outlined in this document, it is expected that the 1047 RMT and MSEC Working Groups may need to develop some supporting 1048 protocol security mechanisms. It is also possible to cooperate with 1049 the Multicast Backbone (MBONE) Deployment (MBONED) Working Group for 1050 defining operational considerations. 1052 9.1. RMT Transport Message Security Encapsulation Header 1054 An alternative approach to using IPsec to provide the necessary 1055 properties to protect RMT protocol operation from the application 1056 attacks described earlier, is to extend the RMT protocol message set 1057 to include a message encapsulation option. This encapsulation header 1058 could be used to provide authentication, confidentiality, and anti- 1059 replay protection as needed. Since this would be independent of the 1060 IP layer, the header might need to provide a source identifier to be 1061 used as a "selector" for recalling security state (including 1062 authentication certificate(s), sequence state, etc) for a given 1063 message. In the case of the NORM protocol, a "NormNodeId" field 1064 exists that could be used for this purpose. In the case of ALC, the 1065 security encapsulation mechanism would need to add this function. 1066 The security encapsulation mechanism, although resident "above" the 1067 IP layer, could use GSAKMP [RFC4535] or a similar approach for 1068 automated key management. 1070 10. IANA Considerations 1072 This document has no actions for IANA. 1074 11. Security Considerations 1076 This document is a general discussion of security for the RMT 1077 protocol family. But specific security considerations are not 1078 applicable as this document does not introduce any new techniques. 1080 12. Acknowledgments 1082 The authors would like acknowledge Magnus Westerlund for stimulating 1083 the working group activity in this area. Additionally George Gross 1084 and Ran Atkinson contributed many ideas to the discussion here. 1086 13. References 1088 13.1. Normative References 1090 [I-D.ietf-rmt-flute-revised] 1091 Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 1092 "FLUTE - File Delivery over Unidirectional Transport", 1093 draft-ietf-rmt-flute-revised-12 (work in progress), 1094 February 2011. 1096 [I-D.ietf-rmt-simple-auth-for-alc-norm] 1097 Roca, V., "Simple Authentication Schemes for the ALC and 1098 NORM Protocols", 1099 draft-ietf-rmt-simple-auth-for-alc-norm-03 (work in 1100 progress), July 2010. 1102 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1103 RFC 1112, August 1989. 1105 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1106 Requirement Levels", BCP 14, RFC 2119, March 1997. 1108 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1109 Thyagarajan, "Internet Group Management Protocol, Version 1110 3", RFC 3376, October 2002. 1112 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 1113 Multicast (SSM)", RFC 3569, July 2003. 1115 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1116 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1118 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 1119 "Multicast Security (MSEC) Group Key Management 1120 Architecture", RFC 4046, April 2005. 1122 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1123 Internet Protocol", RFC 4301, December 2005. 1125 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 1126 "GSAKMP: Group Secure Association Key Management 1127 Protocol", RFC 4535, June 2006. 1129 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 1130 for OSPFv3", RFC 4552, June 2006. 1132 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1133 IP", RFC 4607, August 2006. 1135 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 1136 Independent Multicast - Sparse Mode (PIM-SM) Multicast 1137 Routing Security Issues and Enhancements", RFC 4609, 1138 October 2006. 1140 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 1141 Congestion Control (TFMCC): Protocol Specification", 1142 RFC 4654, August 2006. 1144 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1145 Correction (FEC) Building Block", RFC 5052, August 2007. 1147 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 1148 "NACK-Oriented Reliable Multicast (NORM) Transport 1149 Protocol", RFC 5740, November 2009. 1151 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 1152 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 1153 April 2010. 1155 [RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed 1156 Efficient Stream Loss-Tolerant Authentication (TESLA) in 1157 the Asynchronous Layered Coding (ALC) and NACK-Oriented 1158 Reliable Multicast (NORM) Protocols", RFC 5776, 1159 April 2010. 1161 13.2. Informative References 1163 [Neumann05] 1164 Neumann, C., Roca, V., and R. Walsh, "Large Scale Content 1165 Distribution Protocols", ACM Computer Communications 1166 Review (CCR) Vol. 35 No. 5, October 2005. 1168 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1169 Time Protocol Version 4: Protocol and Algorithms 1170 Specification", RFC 5905, June 2010. 1172 [RsaPaper] 1173 Rivest, R., Shamir, A., and L. Adleman, "A Method for 1174 Obtaining Digital Signatures and Public-Key 1175 Cryptosystems", Communications of the ACM 21, pp. 120-126, 1176 1978. 1178 Authors' Addresses 1180 Brian Adamson 1181 Naval Research Laboratory 1182 Washington, DC 20375 1183 USA 1185 Email: adamson@itd.nrl.navy.mil 1186 URI: http://cs.itd.nrl.navy.mil 1188 Vincent Roca 1189 INRIA 1190 Montbonnot 38334 1191 France 1193 Email: vincent.roca@inria.fr 1194 URI: http://planete.inrialpes.fr/~roca/ 1196 Hitoshi Asaeda 1197 Keio University 1198 5322 Endo 1199 Fujisawa, Kanagawa 252-8520 1200 Japan 1202 Email: asaeda@wide.ad.jp 1203 URI: http://www.sfc.wide.ad.jp/~asaeda/