idnits 2.17.1 draft-ietf-rmt-sec-discussion-07.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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 30, 2012) is 4164 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 1087, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) Summary: 2 errors (**), 0 flaws (~~), 2 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: June 3, 2013 INRIA 6 H. Asaeda 7 Keio University 8 November 30, 2012 10 Security and Reliable Multicast Transport Protocols: Discussions and 11 Guidelines 12 draft-ietf-rmt-sec-discussion-07 14 Abstract 16 This document describes general security considerations for Reliable 17 Multicast Transport (RMT) building blocks and protocols. An emphasis 18 is placed on risks that might be resolved in the scope of transport 19 protocol design. However, relevant security issues related to IP 20 Multicast control-plane and other concerns not strictly within the 21 scope of reliable transport protocol design are also discussed. The 22 document also begins an exploration of approaches that could be 23 embraced to mitigate these risks. The purpose of this document is to 24 provide a consolidated security discussion and provide a basis for 25 further discussions and potential resolution of any significant 26 security issues that may exist in the current set of RMT standards. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 3, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 2. Quick Introduction to RMT Protocols and their Use . . . . . . 6 76 2.1. ALC and NORM Overview . . . . . . . . . . . . . . . . . . 6 77 2.2. RMT Protocol Characteristics . . . . . . . . . . . . . . . 7 78 2.3. Target Use Case Characteristics . . . . . . . . . . . . . 7 79 3. Some Security Threats . . . . . . . . . . . . . . . . . . . . 8 80 3.1. Control-Plane Attacks . . . . . . . . . . . . . . . . . . 9 81 3.1.1. Control Plane Monitoring . . . . . . . . . . . . . . . 9 82 3.1.2. Unauthorized (or Malicious) Group Membership . . . . . 10 83 3.2. Data-Plane Attacks . . . . . . . . . . . . . . . . . . . . 10 84 3.2.1. Rogue Traffic Generation . . . . . . . . . . . . . . . 11 85 3.2.2. Sender Message Spoofing . . . . . . . . . . . . . . . 11 86 3.2.3. Receiver Message Spoofing . . . . . . . . . . . . . . 12 87 3.2.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . 12 88 4. General Security Goals . . . . . . . . . . . . . . . . . . . . 13 89 4.1. Network Protection . . . . . . . . . . . . . . . . . . . . 14 90 4.2. Protocol Protection . . . . . . . . . . . . . . . . . . . 14 91 4.3. Content Protection . . . . . . . . . . . . . . . . . . . . 14 92 4.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 5. Elementary Security Techniques . . . . . . . . . . . . . . . . 15 94 6. Technological Building Blocks . . . . . . . . . . . . . . . . 17 95 6.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 6.1.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 17 97 6.1.2. Requirements . . . . . . . . . . . . . . . . . . . . . 18 98 6.1.3. Limitations . . . . . . . . . . . . . . . . . . . . . 18 99 6.2. Group MAC . . . . . . . . . . . . . . . . . . . . . . . . 19 100 6.2.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 19 101 6.2.2. Requirements . . . . . . . . . . . . . . . . . . . . . 19 102 6.2.3. Limitations . . . . . . . . . . . . . . . . . . . . . 19 103 6.3. Digital Signatures . . . . . . . . . . . . . . . . . . . . 19 104 6.3.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 19 105 6.3.2. Requirements . . . . . . . . . . . . . . . . . . . . . 20 106 6.3.3. Limitations . . . . . . . . . . . . . . . . . . . . . 20 107 6.4. TESLA . . . . . . . . . . . . . . . . . . . . . . . . . . 20 108 6.4.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 21 109 6.4.2. Requirements . . . . . . . . . . . . . . . . . . . . . 21 110 6.4.3. Limitations . . . . . . . . . . . . . . . . . . . . . 21 111 6.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 22 112 6.5.1. Requirements . . . . . . . . . . . . . . . . . . . . . 22 113 6.5.2. Limitations . . . . . . . . . . . . . . . . . . . . . 22 114 6.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 22 115 7. Security Infrastructure . . . . . . . . . . . . . . . . . . . 23 116 8. New Threats Introduced by the Security Scheme Itself . . . . . 24 117 9. Future IETF Considerations . . . . . . . . . . . . . . . . . . 24 118 9.1. RMT Transport Message Security Encapsulation Header . . . 24 119 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 120 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 121 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 122 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 125 1. Introduction 127 The IETF has produces a set of Reliable Multicast Transport (RMT) 128 protocol building block (BB) and protocol instantiation (PI) 129 specifications for reliable multicast data transport. Some present 130 PIs defined within the scope of RMT include Asynchronous Layered 131 Coding (ALC) [RFC5775], NACK-Oriented Reliable Multicast (NORM) 132 [RFC5740], and the File Delivery over Unidirectional Transport 133 (FLUTE) [RFC6726] application that is built on top of ALC. These can 134 be considered "Content Delivery Protocols" as described in 135 [Neumann05]. 137 The use of these BBs and PIs raises some new security risks. For 138 instance, these protocols share a novel set of Forward Error 139 Correction (FEC) and congestion control building blocks that present 140 some new capabilities for Internet transport, but may also pose some 141 new security risks. Yet some security risks are not related to the 142 particular BBs used by the PIs, but are more general. Reliable 143 multicast transport sessions are expected to involve at least one 144 sender and multiple receivers. Thus, the risk of and avenues to 145 attack are implicitly greater than that of point-to-point (unicast) 146 transport sessions. Also the nature of IP multicast can expose other 147 coexistent network flows and services to risk if malicious users 148 exploit it. The classic Any-Source Multicast (ASM) [RFC1112] model 149 of multicast routing allows any host to join an IP multicast group 150 and send traffic to that group. This poses many potential security 151 challenges. And, while the emerging Source-Specific Multicast (SSM) 152 [RFC3569], [RFC4607] model that enables users to receive multicast 153 data sent only from specified sender(s) simplifies some challenges, 154 there are still specific issues. For instance, possible areas of 155 attack include those against the control plane where malicious hosts 156 join IP multicast groups to cause multicast traffic to be directed to 157 parts of the network where it is not needed or desired. This may 158 indirectly cause denial-of-service (DoS) to other network flows. 159 Also, attackers may transmit erroneous or corrupt messages to the 160 group or employ strategies such as replay attack within the "data 161 plane" of protocol operation. 163 The goals of this document are therefore to: 165 1. Define the possible general security goals: protecting the 166 network infrastructure, and/or the protocol, and/or the content, 167 and/or the user (e.g., its privacy); 169 2. List the possible elementary security services that will make it 170 possible to fulfill the general security goals. Some of these 171 services are generic (e.g., object and/or packet integrity), 172 while others are specific to RMT protocols (e.g., congestion 173 control specific security schemes); 175 3. List some technological building blocks and solutions that can 176 provide the desired security services; 178 4. Highlight the reliable multicast protocol and the use-case 179 specificities that will impact security. Indeed, the set of 180 solutions proposed to fulfill the security goals will greatly be 181 impacted by these considerations; 183 In some cases, the existing RMT documents already discuss the risks 184 and outline approaches to solve them, at least partially. The 185 purpose of this document is to consolidate this content and provide a 186 basis for further discussion and potential resolution of any 187 significant security issues that may exist. 189 2. Quick Introduction to RMT Protocols and their Use 191 2.1. ALC and NORM Overview 193 The ALC and NORM classes of reliable multicast transport are designed 194 to reliably deliver content to a group of multicast receivers. 195 However, ALC and NORM have a different set of features and 196 limitations. ALC supports a unidirectional delivery model where 197 there is no feedback from the receivers to senders. Reliability is 198 achieved by the joint use of carousel-based transmission techniques 199 associated to FEC encoding to recover from missing (erased) packets. 201 On the opposite, NORM achieves reliability by means of FEC encoding 202 (as with ALC) and feedback from the receivers. More specifically, 203 NORM leverages Negative Acknowledgement techniques to control the 204 senders' transmission of content. The advantage is that the sender 205 need not transmit any more information than necessary to satisfy the 206 receivers' need for fully reliable transfers. However, while NORM 207 specifies feedback control techniques to allow it to scale to large 208 group sizes, it is not as massively scalable as ALC. Additionally, 209 the NORM feedback control mechanisms add some header content and 210 protocol implementation complexity. 212 The appropriate choice of a reliable multicast transport protocol 213 depends upon application needs, deployment constraints, and network 214 connectivity considerations. And while there are many common 215 security considerations for these two types of protocols, there are 216 also some unique considerations for each. 218 2.2. RMT Protocol Characteristics 220 This section focuses on the RMT protocol characteristics that impact 221 the choice of the technological building blocks, and the way they can 222 be applied. Both ALC and NORM have been designed with receiver group 223 size scalability. While ALC targets massively scalable sessions 224 (e.g., millions of receivers), NORM is less ambitious, essentially 225 because of the use of feedback messages. 227 The ALC and NORM protocols also differ in the communication paths: 229 o sender to receivers: ALC and NORM, for bulk data transfer and 230 signaling messages; 232 o receivers to sender: NORM only, for feedback messages; 234 o receivers to receivers: NORM only for control messages; 236 Note that the fact ALC is capable of working on top of purely 237 unidirectional networks does not mean that no back-channel is 238 available (Section 2.3). 240 The NORM and ALC protocols support a variety of content delivery 241 models where transport may be carefully coordinated among the sender 242 and receivers or with looser coordination and interaction. This 243 leads to a number of different use cases for these protocols. 245 2.3. Target Use Case Characteristics 247 This section focuses on the target use cases and their special 248 characteristics. These details will impact both the choice of the 249 technological building blocks and the way they can be applied. One 250 can distinguish the following use case features: 252 o Purely unidirectional transport versus symmetric bidirectional 253 transport versus asymmetric bidirectional transport. Most of the 254 time, the amount of traffic flowing to the source is limited, and 255 one can overlook whether the transport channel is symmetric or 256 not. The nature of the underlying transport channel is of 257 paramount importance, since many security building blocks will 258 require a bidirectional communication; 260 o Massively scalable versus moderately scalable session. Here we do 261 not define precisely what the terms "massively scalable" and 262 "moderately scalable" mean. 264 o Known set of receivers versus unknown set of receivers: I.e., does 265 the source know at any point of time the set of receivers or not? 266 Of course, knowing the set of receivers is usually not compatible 267 with massively scalable sessions; 269 o Dynamic set of receivers versus fixed set of receivers: I.e., does 270 the source know at some point of time the maximum set of receivers 271 or will it evolve dynamically? 273 o High rate data flow versus small rate data flow: Some security 274 building blocks are CPU-intensive and are therefore incompatible 275 with high data rate sessions (e.g., solutions that digitally sign 276 all packets sent). 278 o Protocol stack available at both ends: A solution that requires 279 some specific features within the protocol stack will not always 280 be usable. Some target environments (e.g., embedded systems) 281 provide a minimum set of features and extending them (e.g., to add 282 IPsec) is not necessarily realistic; 284 o Multicast routing and other layer-3 protocols in use: E.g., SSM 285 routing [RFC4607] is often seen as one of the key ways to improve 286 security within multicast sessions, and some security building 287 blocks require specialized versions of layer-3 protocols (e.g., 288 Internet Group Management Protocol (IGMP) or Multicast Listener 289 Discovery (MLD) protocol with security extensions). In some cases 290 these assumptions might not be realistic. 292 Depending on the target goal and the associated security building 293 block used, other features might be of importance. For instance, the 294 Timed Efficient Stream Loss-Tolerant Authentication (TESLA) security 295 protocol as described in [RFC4082] requires a loose time 296 synchronization between the source and the receivers. Several 297 possible techniques are available to provide this, but some of them 298 may be feasible only if the target use case has the appropriate 299 characteristics. 301 3. Some Security Threats 303 The IP architecture provides common access to notional control and 304 data planes to both end and intermediate systems. For the purposes 305 of discussion here, the "control plane" mechanisms are considered 306 those with message exchanges between end systems (typically 307 computers) and intermediate systems (typically routers) (or among 308 intermediate systems) while the "data plane" encompasses messages 309 exchanged among end systems, usually pertaining to the transfer of 310 application data. The security threats described here are introduced 311 within the taxonomy of control plane and data plane IP mechanisms. 313 3.1. Control-Plane Attacks 315 In this discussion, "control-plane" in the context of Internet 316 Protocol systems refers to signaling among end systems and 317 intermediate systems to facilitate routing and forwarding of packets. 318 For IP multicast, this notably includes Internet Group Management 319 Protocol (IGMP), Multicast Listener Discovery protocol (MLD), and 320 routing protocol messaging[Baltatu00]. While control-plane attacks 321 may be considered outside of the scope of the transport protocol 322 specifications discussed here, it is important to understand the 323 potential impact of such attacks with respect to the deployment and 324 operation of these protocols. For example, awareness of possible IP 325 Multicast control-plane manipulation that can lead to unauthorized 326 (or unexpected) monitoring of data plane traffic by malicious users 327 may lead a transport application or protocol implementation to 328 support encryption to ensure data confidentiality and/or privacy. 329 Also, these types of attack also have bearing on assessing the real 330 risks of potentially more complex attacks against the transport 331 mechanisms themselves. In some cases, the solutions to these 332 control-plane risk areas may reduce the impact or possibility of some 333 data-plane attacks that are discussed in this document. 335 The presence of these types of attack may necessitate that policy- 336 based controls be embedded in routers to limit the distribution 337 (including transmission and reception) of multicast traffic (on a 338 group-wise and/or traffic volume basis) to different parts of the 339 network. Such policy-based controls are beyond the scope of the RMT 340 protocol specifications. However, such network protection mechanisms 341 may reduce the opportunities for or effectiveness of some of the 342 data-plane attacks discussed later. For example, reverse-path checks 343 can significantly limit opportunities for attackers to conduct replay 344 attacks as described in Section 3.2.4. Also, future IP Multicast 345 control protocols may wish to consider providing a security mechanism 346 to prevent unauthorized monitoring or manipulation of messages 347 related to group membership, routing, and activity. The sections 348 below describe some variants of control-plane attacks. 350 3.1.1. Control Plane Monitoring 352 While this may not be a direct attack on the transport system, it may 353 be possible for an attacker to gain useful information in advancing 354 attack goals by monitoring IP Multicast control plane traffic 355 including group membership and multicast routing information. 356 Identification of hosts and/or routers participating in specific 357 multicast groups may readily identify systems vulnerable to protocol- 358 specific exploitation. And, with regards to user privacy concerns, 359 such "side information" may be relevant to this emerging aspect of 360 network security as described in Section 4.4. Use of multicast 361 security extensions such as those as described in [RFC5374] can help 362 prevent control plane monitoring. 364 3.1.2. Unauthorized (or Malicious) Group Membership 366 One of the simplest attacks is that where a malicious host joins an 367 IP multicast group so that potentially unwanted traffic is routed to 368 the host's network interface. This type of attack can turn a 369 legitimate source of IP traffic into a "attacker" without requiring 370 any access privileges to the source host or routers involved. This 371 type of attack can be used for denial-of-service purposes or for the 372 real attacker (the malicious joiner) to gain access to the 373 information content being sent. Similarly, some routing protocols 374 may permit any sender (whether joined to the specific group or not) 375 to transmit messages to a multicast group. 377 It is possible that malicious hosts could also spoof IGMP/MLD 378 messages, joining groups posing as legitimate hosts (or spoof source 379 traffic from legitimate hosts). For example, this may be done by 380 hosts co-resident with the authorized hosts on local area networks. 381 Such spoofing could be done by raw packet generation or with replay 382 of previously-recorded control messages. 384 For the sake of completeness, it should be noted that multicast 385 routing protocol control messaging may be subject to similar threats 386 if sufficient protocol security mechanisms are not enabled in the 387 routing infrastructure. [RFC4609] describes security threats to the 388 PIM-SM multicast routing infrastructures. 390 3.2. Data-Plane Attacks 392 This section discusses some types of active attacks that might be 393 conducted "in-band" with respect to the reliable multicast transport 394 protocol operating within the data plane of network data transfer. 395 I.e., the "data-plane" here refers to IP packets containing end-to- 396 end transport content to support the reliable multicast transfer. 397 The passive attack of unauthorized data-plan monitoring is discussed 398 above since such activity might be made possible by the 399 vulnerabilities of the IP Multicast control plane. To cover the two 400 classes of RMT protocols, the active data-plane attacks are 401 categorized as 1) those where the attacker generates messages posing 402 as a data sender, and 2) those where the attacker generates messages 403 posing as a receiver providing feedback to the sender(s) or group. 404 Additionally, a common threat to protocol operation is that of brute- 405 force, rogue packet generation. This is discussed briefly below, but 406 the more subtle attacks that might be conducted are given more 407 attention as those fall within the scope of the RMT transport 408 protocol design. Additionally, special consideration is given to 409 that of the "replay attack" [see Section 3.2.4], as it can be applied 410 across these different categories. 412 3.2.1. Rogue Traffic Generation 414 If an attacker is able to successfully inject packets into the 415 multicast distribution tree, one obvious denial-of-service attack is 416 for the attacker to generate a large volume of apparently 417 authenticate traffic (and if authentication mechanisms are used, a 418 "replay" attack strategy might be used). The impact of this type of 419 attack can be significant since the potential for routers to relay 420 the traffic to multiple portions of a networks (as compared to a 421 single unicast routing path). However, other than the amplified 422 negative impact to the network, this type of attack is no different 423 than to that possible with rogue unicast packet generation and 424 similar measures (e.g., as described in [RFC4732]) used to protect 425 the network from such attacks could be used to contain this type of 426 brute-force attack. Of course, the pragmatic question of whether 427 current implementations of such protection mechanisms support IP 428 Multicast should be considered. 430 3.2.2. Sender Message Spoofing 432 Sender message spoofing attacks are relevant for both of the current 433 reliable multicast transport protocols: ALC (sender-only 434 transmission) and NORM (sender-receiver exchanges). Without an 435 authentication mechanism, an attacker can generate sender messages 436 that could disrupt a reliable multicast transfer session. With FEC- 437 based transport mechanisms, a single packet with an apparently- 438 correct FEC payload identifier[RFC5052] but a corrupted FEC payload 439 would render an entire block of transported data invalid. Thus, a 440 modest injection rate of corrupt traffic could cause severe 441 impairment of data transport. Additionally, such invalid sender 442 packets could convey out-of-bound indices (e.g., bad symbol or block 443 identifiers) that can lead to buffer overflow exploits or similar 444 issues in implementations that insufficiently check for invalid data. 446 An indirect use of sender message spoofing would be to generate 447 messages that would cause receivers to take inappropriate congestion- 448 control action. In the case of the layered congestion control 449 mechanisms proposed for ALC use, this could lead to the receivers 450 erroneously leaving groups associated with higher bandwidth transport 451 layers and suffering unnecessarily low transport rates although this 452 would be safe from a network operation perspective. Similarly, 453 receivers may be misled to join inappropriate groups and cause 454 unwanted traffic to be directed to their part of the network. 455 Attacks with similar effect could be conducted against the TCP- 456 Friendly Multicast Congestion Control (TFMCC) [RFC4654] approach 457 proposed for NORM operation with spoofing of sender messages carrying 458 congestion control state to receivers. Packet source authentication 459 techniques such as those described in Section 6 can be used to 460 mitigate sender message spoofing. 462 3.2.3. Receiver Message Spoofing 464 These attacks are limited to reliable multicast protocols that use 465 feedback from receivers in the group to influence sender and other 466 receiver operation. In the NORM protocol, this includes negative- 467 acknowledgement (NACK) messages fed back to the sender to achieve 468 reliable transfer, congestion control feedback content, and the 469 optional positive acknowledgement features of the specification. It 470 is also important to note that for ASM operation, NORM receivers pay 471 attention to the messages of other receivers for the purpose of 472 suppression to avoid feedback implosion as group size grows large. 474 An attacker that can generate false feedback can manipulate the NORM 475 sender to unnecessarily transmit repair information and reduce the 476 goodput of the reliable transfer regardless of the sender's transmit 477 rate. Contrived congestion control feedback could also cause the 478 sender to transmit at an unfairly low rate. 480 As mentioned, spoofed receiver messaging may not be directed only at 481 senders, but also at receivers participating in the session. For 482 example, an attacker may direct phony receiver feedback messages to 483 selected receivers in the group causing those receivers to suppress 484 feedback that might have otherwise been transmitted. This attack 485 could compromise the ability of those receivers to achieve reliable 486 transfer. Also, suppressed congestion control feedback could cause 487 the sender to transmit at a rate unfair to those attacked receivers 488 if their fair congestion control rate were lower. 490 3.2.4. Replay Attacks 492 The "replay attack" (injection of a previously transmitted packet to 493 one or more participants) is given special attention here because of 494 the special consequences it can have on RMT protocol operation. 495 Without specific protection mechanisms against replay (e.g., 496 duplicate message detection), it is possible for these attacks to be 497 successful even when security mechanisms such as packet 498 authentication and/or encryption are employed. 500 3.2.4.1. Replay of Sender Messages 502 Generally, replay of recent protocol messages from the sender will 503 not harm transport, and could potentially assist it, unless it is of 504 sufficient volume to result in the same type of impact as the "rogue 505 traffic generation" described above. However, it is possible that 506 replay of sufficiently old messages may cause receivers to think they 507 are "out of sync" with the sender and reset state, compromising the 508 transfer. Also, if sender transport data identifiers are reused 509 (object identifiers, FEC payload identifiers, etc), it is possible 510 that replay of old messages could corrupt data of a current transfer. 512 3.2.4.2. Replay of Receiver Messages 514 Replay of receiver messages are problematic for the NORM protocol, 515 because replay of NACK messages could cause the sender to 516 unnecessarily transmit repair information for an FEC coding block. 517 Similarly, the sender transmission rate might be manipulated by 518 replay of congestion control feedback messages from receivers in the 519 group. And the way that NORM senders estimate group round-trip 520 timing (GRTT) could allow a replay attack to manipulate the senders' 521 GRTT estimate to an unnecessarily large value, adding latency to the 522 reliable transport process. 524 4. General Security Goals 526 The term "security" is extremely vast and encompasses many different 527 meanings. The goal of this section is to clarify what "security" 528 means when considering the protocols defined by the IETF for reliable 529 multicast transport. However, the scope can also encompass 530 additional applications, like streaming applications. This section 531 only focuses on the desired general goals. It should be noted that 532 many of these goals also apply to IP unicast and/or IP multicast 533 infrastructure and not necessarily specific to RMT protocols. The 534 following sections will then discuss the possible elementary services 535 that will be required to fulfill these general goals, as well as the 536 underlying technological building blocks. 538 The possible final goals include, in decreasing order of importance: 540 o network protection: the goal is to protect the network from 541 attacks, no matter whether these attacks are voluntary (i.e., 542 launched by one or several attackers) or non voluntary (i.e., 543 caused by a misbehaving system, where "system" can designate a 544 building block, a protocol, an application, or a user); 546 o protocol protection: the goal is to protect the operation of the 547 RMT protocol itself, e.g., to avoid that a misbehaving receiver 548 prevents other receivers to get the content, no matter whether 549 this is done intentionally or not; 551 o content protection: to goal is to protect the content itself, for 552 instance to guaranty the integrity of the content, or to make sure 553 that only authorized clients can access the content; 555 o and user protection: the goal is often to protect the user 556 privacy. 558 4.1. Network Protection 560 Protecting the network is of course of primary importance. An 561 attacker should not be able to damage the infrastructure by 562 exploiting some features of the RMT protocol. Since the RMT 563 protocols use congestion control mechanisms to regulate sender 564 transmission rate, the protocol security features should ensure that 565 the sender may not be manipulated to transmit at incorrect rates 566 (most importantly not at an excessive rate) to any parts of the 567 receiver group. In the case of NORM, the security mechanisms should 568 ensure that the feedback suppression mechanisms are protected to 569 prevent badly-behaving network nodes from purposefully causing 570 feedback implosion. In the case of ALC, where layered congestion 571 control may be used via dynamic grou/layer membership, this extends 572 to considerations of excessive manipulation of the multicast router 573 control plane. 575 4.2. Protocol Protection 577 Protecting the operation of the protocols is also of importance, 578 since the higher the number of clients, the more serious the 579 consequences of an attack. This is all the more true as scalability 580 is often one of the desired goals of reliable multicast transport. 581 Ideally, receivers should be sufficiently isolated from one another, 582 so that a single misbehaving receiver does not affect others. 583 Similarly, an external attacker should not be able to break the 584 system, i.e., resulting in unreliable operation or delivery of 585 incorrect content. As the RMT protocols often use UDP encapsulation, 586 much of the guidance described in [RFC5405] applies. 588 4.3. Content Protection 590 The content itself should be protected when meaningful. This level 591 of security is often the concern of the content provider (and its 592 responsibility). For instance, in case of confidential (or non-free) 593 content, the typical solution consists in encrypting the content. It 594 can be done within the upper application, i.e., above the RMT 595 protocol, or within the transport system. But other requirements may 596 exist, like verifying the integrity of a received object, or 597 authenticating the sender of the received packets. To that goal, one 598 can rely on the use of building blocks integrated within, or above, 599 or beneath the RMT protocol. For example, packet sender 600 authentication and content integrity services can be used for RMT 601 systems that are deployed within an open network, where any attacker 602 can inject spurious traffic in an ongoing NORM or ALC session. 604 4.4. Privacy 606 Finally the user should be protected, and more specifically their 607 privacy. In general, there is not a privacy issue for the data 608 sender. I.e., the data sender's address is announced to all 609 prospective receivers prior to their joins. Moreover receivers need 610 to specify the source address(es) as well as the IP multicast address 611 in SSM communication upon their subscription. The situation is 612 different if we consider receivers since their addresses do not need 613 to be disclosed publicly. 615 Data receivers use IGMP or MLD protocols to notify their upstream 616 routers to join or leave an IP multicast session. The recent IGMPv3 617 [RFC3376] and MLDv2 [RFC3810] do not adopt the "report suppression 618 mechanism". Report suppression makes the receiver host withdraw its 619 own report when the host hears a report scheduled to be sent from 620 other host joining the same group. Eliminating the report 621 suppression mechanism does not contribute to minimizing the number of 622 responses, but enables the router to explicitly track of host 623 membership status on a local network. Due to this specification, 624 operators who maintain upstream routers that attach multicast data 625 receiver can recognize data receivers' addresses by tracing IGMP/MLD 626 report messages. Although such traced data may be useful for 627 capacity planning or accounting from operator's perspective, the 628 detail information including receivers' IP addresses should be 629 carefully treated. 631 As described in Section 3.1.2, unauthorized users may spoof IGMP/MLD 632 query messages and trace receivers' addresses that are shared by the 633 same Layer 2 infrastructure (e.g., LAN). Currently, IGMP/MLD 634 protocols do not protect this attack. It is desired for these 635 protocols to ignore invalid query messages and provide receiver's 636 privacy by some means. 638 5. Elementary Security Techniques 640 The goals defined in Section 4 will be fulfilled by means of 641 underlying security techniques, provided by one or several 642 technological building blocks. This section only focuses on these 643 elementary security techniques. Some general techniques 644 traditionally available are: 646 +-----------------+-------------------------------------------------+ 647 | Technique | Goal | 648 +-----------------+-------------------------------------------------+ 649 | packet | Enable session participants to verify that a | 650 | integrity | packet has not been inappropriately modified in | 651 | | transit. | 652 | packet source | Enable a receiver to verify the source of a | 653 | authentication | packet. | 654 | packet group | Enable a receiver to verify that a packet | 655 | authentication | originated or was modified only within the | 656 | | group and has not been modified by nonmembers | 657 | | in transit; Additionally, if attribution of any | 658 | | modifications by the group is required, certain | 659 | | group authentication mechanisms may provide | 660 | | this capability. | 661 | packet | Enable any third party to verify the source of | 662 | non-repudiation | a packet such that the source cannot repudiate | 663 | | having sent the packet. | 664 | packet | Enable a receiver to detect that a packet is | 665 | anti-replay | the same as a previously-received packet | 666 | object | Enable a receiver to verify the integrity of a | 667 | integrity | whole object. Such object integrity | 668 | | verification should be possible for any | 669 | | singular object or any composition of | 670 | | sub-objects which together constitute a larger | 671 | | object structure. | 672 | object source | Enable a receiver to verify the source of an | 673 | authentication | object. | 674 | object | Enable a source to guarantee that only | 675 | confidentiality | authorized receivers can access the object | 676 | | data. | 677 +-----------------+-------------------------------------------------+ 679 General Security Techniques 681 Some additional techniques are specific to the RMT protocols: 683 +---------------+---------------------------------------------------+ 684 | Technique | Goal | 685 +---------------+---------------------------------------------------+ 686 | congestion | Prevent an attacker from modifying the congestion | 687 | control | control protocol normal behavior (e.g., by | 688 | security | reducing the transmission (NORM) or reception | 689 | | (ALC) rate, or on the opposite increasing this | 690 | | rate up to a point where congestion occurs) | 691 | group | Ensure that only authorized receivers (as defined | 692 | management | by a certain group management policy) join the | 693 | | RMT session and possibly inform the source | 694 | backward | Prevent a new group member to access the | 695 | group secrecy | information in clear sent to the group before he | 696 | | joined the group | 697 | forward group | Prevent a former group member to access the | 698 | secrecy | information in clear sent to the group after he | 699 | | left the group | 700 +---------------+---------------------------------------------------+ 702 RMT-Specific Security Techniques 704 These techniques are usually achieved by means of one or several 705 technological building blocks. The target use case where the RMT 706 system will be deployed will greatly impact the choice of the 707 technological building block(s) used to provide these services, as 708 explained in Section 2.3. 710 6. Technological Building Blocks 712 Here is a list of techniques and building blocks that are likely to 713 fulfill one or several of the goals listed above: 715 o IPsec; 717 o Group MAC; 719 o Digital signatures; 721 o TESLA; 723 o SSM communication model; 725 Each of them is briefly discussed below. In particular we identify 726 the services it offers, its limitations, and its field of application 727 (adequacy with respect to the RMT protocol and the target use case). 729 6.1. IPsec 731 6.1.1. Benefits 733 One direct approach using existing standards is to apply IPsec 734 [RFC4301] to achieve the following properties: 736 o source authentication and packet integrity (IPsec AH or ESP) 738 o confidentiality by means of encryption (IPsec ESP) 740 6.1.2. Requirements 742 It is expected that the approach to apply IPsec for reliable 743 multicast transport sessions is similar to that described for OSPFv3 744 security[RFC4552]. The following list proposes the IPsec 745 capabilities needed to support a similar approach to RMT protocol 746 security: 748 o Mode - Transport mode IPsec security is required; 750 o Selectors - source and destination addresses and ports, protocol. 752 o For some uses, preplaced, manual key support may be required to 753 support application deployment and operation. For automated key 754 management for group communication the Group Secure Association 755 Key Management Protocol (GSAKMP) described in [RFC4535] may be 756 used to emplace the keys for IPsec operation. 758 Note that a periodic rekeying procedure similar to that described in 759 RFC 4552 can also be applied with the additional benefit that the 760 reliable multicast transport provides robustness to any message loss 761 that might occur due to ANY timing discrepancies among the session 762 participants. 764 6.1.3. Limitations 766 It should be noted that current IPsec implementations may not provide 767 the capability for anti-replay protection for multicast operation. 768 In the case of the NORM protocol, a sequence number is provided for 769 packet loss measurement to support congestion control operation. 770 This sequence number can also be used within a NORM implementation 771 for detecting duplicate (replayed) messages from sources (senders or 772 receivers) within the transport session group. In this way, 773 protection against replay attack can be achieved in conjunction with 774 the authentication and possibly confidentiality properties provided 775 by an IPsec encapsulation of NORM messages. NORM receivers generate 776 a very low volume of feedback traffic and it is expected that the 16- 777 bit sequence space provided by NORM will be sufficient for replay 778 attack protection. When a NORM session is long-lived, the limits of 779 the sender repair window are expected to provide protection from 780 replayed NACKs as they would typically be outside of the sender's 781 current repair window. It is suggested that IPsec implementations 782 that can provide anti-replay protection for IP Multicast traffic, 783 even when there are multiple senders within a group, be adopted. The 784 GSAKMP document has some discussion in this area. 786 6.2. Group MAC 788 6.2.1. Benefits 790 The use of Group MAC (Message Authentication Codes) within Simple 791 Authentication Schemes for the ALC and NORM Protocols [RFC6584] is a 792 simple solution to provide a loss tolerant group authentication/ 793 integrity service for all the packets exchanged within a session 794 (i.e., the packets generated by the session's sender and the 795 session's receivers). This scheme is easy to deploy since it only 796 requires that all the group members share a common secret key. 797 Because Group MAC heavily relies on fast symmetric cryptographic 798 building blocks, CPU processing remains limited both at the sender 799 and receiver sides, which makes it suitable for high data rate 800 transmissions, and/or lightweight terminals. Finally, the 801 transmission overhead remains limited. 803 6.2.2. Requirements 805 This scheme only requires that all the group members share a common 806 secret key, possibly associated to a re-keying mechanism (e.g., each 807 time the group membership changes, or on a periodic basis). 809 6.2.3. Limitations 811 This scheme cannot protect against attacks coming from inside the 812 group, where a group member impersonates the sender and sends forged 813 messages to other receivers. It only provides a group-level 814 authentication/integrity service, unlike the TESLA and Digital 815 Signature schemes. Note that the Group MAC and Digital Signature 816 schemes can be advantageously used together, as explained in Simple 817 Authentication Schemes for the ALC and NORM Protocols [RFC6584]. 819 6.3. Digital Signatures 821 6.3.1. Benefits 823 The use of Digital Signatures within Simple Authentication Schemes 824 for the ALC and NORM Protocols [RFC6584] is a simple solution to 825 provide a loss-tolerant authentication/integrity service for all the 826 packets exchanged within a session (i.e., the packets generated by 827 the session's sender and the session's receivers). This scheme is 828 easy to deploy since it only requires that the participants know the 829 packet sender's public key, which can be achieved with either Public 830 Key Infrastructure (PKI) or by preplacement of these keys. 832 6.3.2. Requirements 834 This scheme is simple to deploy since it requires only that the 835 participants know the packet sender's public key, which can be 836 achieved with either PKI or by preplacement of these keys. 838 6.3.3. Limitations 840 When RSA [RsaPaper] asymmetric cryptography is used, the digital 841 signatures approach has two major shortcomings: 843 o high computational costs, especially at the sender, and 845 o high transmission overhead. 847 This scheme is well suited to low data rate flows, when transmission 848 overheads are not a major issue. For instance it can be used as a 849 complement to TESLA for the feedback traffic coming from the 850 session's receivers. The use of ECC ("Elliptic Curve Cryptography") 851 significantly relaxes these constraints, especially when seeking for 852 higher security levels. For instance, the following key size provide 853 equivalent security: 855 +--------------------+--------------+--------------+ 856 | Symmetric Key Size | RSA Key Size | ECC Key Size | 857 +--------------------+--------------+--------------+ 858 | 80 bits | 1024 bits | 160 bits | 859 | 112 bits | 2048 bits | 224 bits | 860 +--------------------+--------------+--------------+ 862 However in some cases, the Intellectual Property Rights (IPR) 863 considerations for ECC may limit its use, so the other techniques are 864 presented here as well. Note that the Group MAC and Digital 865 Signature schemes can be advantageously used together, as explained 866 in Simple Authentication Schemes for the ALC and NORM Protocols 867 [RFC6584]. 869 6.4. TESLA 871 The Timed Efficient Stream Loss-tolerant Authentication (TESLA) 872 protocol allows multicast receivers to check the integrity and 873 authenticate the source of each packet in multicast or broadcast data 874 streams with low-cost computational operations. TESLA is also 875 tolerant of packet loss, thus making it suitable as an underlying 876 security mechanism for RMT protocols. 878 6.4.1. Benefits 880 The use of TESLA [RFC5776] within reliable multicast transport offers 881 a loss tolerant, lightweight, authentication/integrity service for 882 the packets generated by the session's sender. Depending on the time 883 synchronization and bootstrap methods used, TESLA can be compatible 884 with massively scalable sessions. Because TESLA heavily relies on 885 fast symmetric cryptographic building blocks, CPU processing remains 886 limited both at the sender and receiver sides, which makes it 887 suitable for high data rate transmissions, and/or lightweight 888 terminals. Finally, the transmission overhead remains limited. 890 6.4.2. Requirements 892 The security offered by TESLA relies heavily on time. Therefore the 893 session's sender and each receiver need to be loosely synchronized in 894 a secure way. To that purpose, several methods exist, depending on 895 the use case: direct time synchronization (which requires a 896 bidirectional transport channel), using a secure Network Time 897 Protocol (NTP) [RFC5905] infrastructure (which also requires a 898 bidirectional transport channel), a common, central time reference 899 (e.g., Global Positioning System (GPS) device), or a clock with a 900 time-drift that is negligible in front of the TESLA time accuracy 901 requirements. 903 The various bootstrap parameters must also be communicated to the 904 receivers, using either an in-band or out-of-band mechanism, 905 sometimes requiring bidirectional communications. So, depending on 906 the time synchronization scheme and the bootstrap mechanism method, 907 TESLA can be used with either bidirectional or unidirectional 908 transport channels. 910 6.4.3. Limitations 912 One limitation is that TESLA does not protect the packets that are 913 generated by receivers, for instance the feedback packets of NORM. 914 These packets must be protected by other means. 916 Another limitation is that TESLA requires some buffering capabilities 917 at the receivers in order to enable the delayed authentication 918 feature. This is not considered though as a major issue in the 919 general case (e.g., FEC decoding of objects within an ALC session 920 already requires some buffering capabilities, that often exceed that 921 of TESLA), but it might be one in case of embedded environments. 923 6.5. Source-Specific Multicast 925 Source-Specific Multicast (SSM) [RFC3569], [RFC4607] amends the 926 classical Any-Source Multicast (ASM) model by creating logical IP 927 multicast "channels" that are defined by the multicast destination 928 address _and_ the specific source address(es). Thus for a given 929 "channel", only the specific source(s) can inject packets that are 930 distributed to the receivers. This form of multicast has group 931 management benefits since a source can independently control the 932 "channels" it creates and the need for globally coordinated group 933 address management is reduced. The security considerations for SSM 934 multicast are described in [RFC4609]. 936 6.5.1. Requirements 938 Use of SSM requires that the network intermediate systems explicitly 939 support it. For RMT protocol participants, it is necessary that the 940 source address as well as the group address is available as part of 941 session description information. Additionally, hosts operating 942 systems are required to support the IGMPv3/MLDv2 extensions for SSM, 943 and the reliable multicast transport implementations need to support 944 the IGMPv3/MLDv2 API, including management of the "channel" identifiers. It should be noted that the SSM 946 paradigm can also be logically implemented where receivers explicitly 947 filter data transfer packets to be only allowed from the expected 948 source. 950 6.5.2. Limitations 952 Reliable multicast transport protocols such as NORM that use 953 signaling from receivers to multicast senders will need to use 954 unicast addressing for feedback messages. In the case of NORM, its 955 timer-based feedback suppression requires support of the sender 956 NORM_CMD(REPAIR_ADV) message to control receiver feedback. In some 957 topologies, use of unicast feedback may require some additional 958 latency (increased backoff factor) for safe operation. The security 959 of the unicast feedback from the receivers to sender will need to be 960 addressed separately since the IP multicast model, including SSM, 961 does not provide the sender knowledge of authorized group members. 963 6.6. Summary 965 The following table summarizes the pros/cons of each authentication/ 966 integrity scheme used at application/transport level (where "-" means 967 bad, "0" means neutral, and "+" means good): 969 +------------------+-------------+-------------+------------+-------+ 970 | | RSA Digital | ECC Digital | Group MAC | TESLA | 971 | | Signature | Signature | | | 972 +------------------+-------------+-------------+------------+-------+ 973 | True | Yes | Yes | No (group | Yes | 974 | authentication | | | security) | | 975 | and integrity | | | | | 976 | Immediate | Yes | Yes | Yes | No | 977 | authentication | | | | | 978 | Processing load | - | 0 | + | + | 979 | Transmission | - | 0 | + | + | 980 | overhead | | | | | 981 | Complexity | + | + | + | - | 982 +------------------+-------------+-------------+------------+-------+ 984 7. Security Infrastructure 986 Deploying the elementary technological building blocks often requires 987 that a security infrastructure exists. Such security infrastructure 988 can provide: 990 o Public Key Infrastructure (PKI) for trusted third party vetting 991 of, and vouching for, user identities. PKI also allows the 992 binding of public keys to users, usually by means of certificates. 994 o Group Key Management with rekeying schemes that are either 995 periodic or triggered by some higher level event. It is required 996 in particular when the group is dynamic and forward/backward 997 secrecy are important. This is also required to improve the 998 scalability of the reliable multicast transport protocol (since 999 key management is done automatically, using a key server 1000 topology), or the security provided (since the underlying 1001 cryptographic keys will be changed frequently) 1003 It is expected that some reliable multicast deployments may use 1004 existing client-server security infrastructure models so that 1005 receivers may acquire any necessary security material and be 1006 authenticated or validated as needed for group participation. Then, 1007 the reliable delivery of session data content will be provided via 1008 the applicable RMT protocols. Note that in this case the security 1009 infrastructure itself may limit the scalability of the group size or 1010 other aspects of reliable multicast transfer. The IETF has developed 1011 some Multicast Security (MSEC) protocols that can be applied to 1012 achieve more scalable and effective group communication security 1013 infrastructure[RFC4046]. It is encouraged that these mechanisms be 1014 considered in the development of security for reliable multicast 1015 transport protocol. 1017 8. New Threats Introduced by the Security Scheme Itself 1019 Introducing a security scheme, as a side effect, can sometimes 1020 introduce new security threats. For instance, signing all packets 1021 with asymmetric cryptographic schemes (to provide a source 1022 authentication/content integrity/anti-replay service) opens the door 1023 to DoS attacks. Indeed, verifying asymmetric-based cryptographic 1024 signatures is a CPU intensive task. Therefore an attacker can 1025 overload a receiver (or a sender in case of NORM) by injecting a 1026 significant number of faked packets. 1028 9. Future IETF Considerations 1030 To meet all of the goals outlined in this document, it is expected 1031 that the IETF may need to develop some additional supporting protocol 1032 security mechanisms. This can include some extensions to the 1033 existing RMT protocols that feature extensible header fields. As an 1034 example, some considerations for an RMT security encapsulation 1035 extension are described below. 1037 9.1. RMT Transport Message Security Encapsulation Header 1039 An alternative approach to using IPsec to provide the necessary 1040 properties to protect RMT protocol operation from the application 1041 attacks described earlier, is to extend the RMT protocol message set 1042 to include a message encapsulation option. This encapsulation header 1043 could be used to provide authentication, confidentiality, and anti- 1044 replay protection as needed. Since this would be independent of the 1045 IP layer, the header might need to provide a source identifier to be 1046 used as a "selector" for recalling security state (including 1047 authentication certificate(s), sequence state, etc) for a given 1048 message. In the case of the NORM protocol, a "NormNodeId" field 1049 exists that could be used for this purpose. In the case of ALC, the 1050 security encapsulation mechanism would need to add this function. 1051 The security encapsulation mechanism, although resident "above" the 1052 IP layer, could use GSAKMP [RFC4535] or a similar approach for 1053 automated key management. 1055 10. IANA Considerations 1057 This document has no actions for IANA. 1059 11. Security Considerations 1061 This document is a general discussion of security for the RMT 1062 protocol family. But specific security considerations are not 1063 applicable as this document does not introduce any new techniques. 1065 12. Acknowledgments 1067 The authors would like acknowledge Magnus Westerlund for stimulating 1068 the working group activity in this area. Additionally George Gross 1069 and Ran Atkinson contributed many ideas to the discussion here. 1071 13. References 1073 [Baltatu00] 1074 Baltatu, M., Loy, A., Maino, F., and D. Mazzocchi, 1075 "Security Issues in Control, Management and Routing 1076 Protocols", Elsevier Computer Networks pp. 881-894, 1077 May 2000. 1079 [Neumann05] 1080 Neumann, C., Roca, V., and R. Walsh, "Large Scale Content 1081 Distribution Protocols", ACM Computer Communications 1082 Review (CCR) Vol. 35 No. 5, October 2005. 1084 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1085 RFC 1112, August 1989. 1087 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1088 Requirement Levels", BCP 14, RFC 2119, March 1997. 1090 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1091 Thyagarajan, "Internet Group Management Protocol, Version 1092 3", RFC 3376, October 2002. 1094 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 1095 Multicast (SSM)", RFC 3569, July 2003. 1097 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1098 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1100 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 1101 "Multicast Security (MSEC) Group Key Management 1102 Architecture", RFC 4046, April 2005. 1104 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 1105 Briscoe, "Timed Efficient Stream Loss-Tolerant 1106 Authentication (TESLA): Multicast Source Authentication 1107 Transform Introduction", RFC 4082, June 2005. 1109 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1110 Internet Protocol", RFC 4301, December 2005. 1112 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 1113 "GSAKMP: Group Secure Association Key Management 1114 Protocol", RFC 4535, June 2006. 1116 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 1117 for OSPFv3", RFC 4552, June 2006. 1119 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1120 IP", RFC 4607, August 2006. 1122 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 1123 Independent Multicast - Sparse Mode (PIM-SM) Multicast 1124 Routing Security Issues and Enhancements", RFC 4609, 1125 October 2006. 1127 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 1128 Congestion Control (TFMCC): Protocol Specification", 1129 RFC 4654, August 2006. 1131 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 1132 Service Considerations", RFC 4732, December 2006. 1134 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1135 Correction (FEC) Building Block", RFC 5052, August 2007. 1137 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 1138 Extensions to the Security Architecture for the Internet 1139 Protocol", RFC 5374, November 2008. 1141 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1142 for Application Designers", BCP 145, RFC 5405, 1143 November 2008. 1145 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 1146 "NACK-Oriented Reliable Multicast (NORM) Transport 1147 Protocol", RFC 5740, November 2009. 1149 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 1150 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 1151 April 2010. 1153 [RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed 1154 Efficient Stream Loss-Tolerant Authentication (TESLA) in 1155 the Asynchronous Layered Coding (ALC) and NACK-Oriented 1156 Reliable Multicast (NORM) Protocols", RFC 5776, 1157 April 2010. 1159 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1160 Time Protocol Version 4: Protocol and Algorithms 1161 Specification", RFC 5905, June 2010. 1163 [RFC6584] Roca, V., "Simple Authentication Schemes for the 1164 Asynchronous Layered Coding (ALC) and NACK-Oriented 1165 Reliable Multicast (NORM) Protocols", RFC 6584, 1166 April 2012. 1168 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 1169 "FLUTE - File Delivery over Unidirectional Transport", 1170 RFC 6726, November 2012. 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/ 1195 Hitoshi Asaeda 1196 Keio University 1197 5322 Endo 1198 Fujisawa, Kanagawa 252-8520 1199 Japan 1201 Email: asaeda@wide.ad.jp 1202 URI: http://www.sfc.wide.ad.jp/~asaeda/