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