idnits 2.17.1 draft-adamson-roca-rmtsec-issues-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 925. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 936. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 943. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 949. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 4, 2006) is 6411 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 843, but no explicit reference was found in the text == Unused Reference: 'RFC3451' is defined on line 853, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 3450 (Obsoleted by RFC 5775) ** Obsolete normative reference: RFC 3451 (Obsoleted by RFC 5651) ** Obsolete normative reference: RFC 3452 (Obsoleted by RFC 5052, RFC 5445) ** Obsolete normative reference: RFC 3926 (Obsoleted by RFC 6726) ** Obsolete normative reference: RFC 3940 (Obsoleted by RFC 5740) Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RMT (TBD) Brian. Adamson 3 Internet-Draft Naval Research Laboratory 4 Intended status: Informational Vincent. Roca 5 Expires: April 7, 2007 INRIA 6 October 4, 2006 8 Security and Reliable Multicast Transport Protocols: Discussions and 9 Guidelines 10 draft-adamson-roca-rmtsec-issues-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 7, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document describes some security risks of the Reliable Multicast 44 Transport (RMT) Working Group set of building blocks and protocols. 45 An emphasis is placed on risks that might be resolved in the scope of 46 transport protocol design. However, relevant security issues related 47 to IP Multicast control-plane and other concerns not strictly within 48 the scope of reliable transport protocol design are also discussed. 50 The document also begins an exploration of approaches that could be 51 embraced to mitigate these risks. The purpose of this document is to 52 provide a consolidated security discussion and provide a basis for 53 further discussion and potential resolution of any significant 54 security issues that may exist in the current set of RMT standards. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Quick Introduction to RMT Protocols and their Use . . . . . . 5 60 2.1. The Two Families of CDP . . . . . . . . . . . . . . . . . 5 61 2.2. RMT Protocol Specificities . . . . . . . . . . . . . . . . 5 62 2.3. Target Use Case Specificities . . . . . . . . . . . . . . 6 63 3. Known Security Threats . . . . . . . . . . . . . . . . . . . . 7 64 3.1. Control-Plane Attacks . . . . . . . . . . . . . . . . . . 8 65 3.1.1. Control Plane Monitoring . . . . . . . . . . . . . . . 8 66 3.1.2. Unauthorized (or Malicious) Group Membership . . . . . 8 67 3.2. Data-Plane Attacks . . . . . . . . . . . . . . . . . . . . 9 68 3.2.1. Rogue Traffic Generation . . . . . . . . . . . . . . . 9 69 3.2.2. Sender Message Spoofing . . . . . . . . . . . . . . . 10 70 3.2.3. Receiver Message Spoofing . . . . . . . . . . . . . . 10 71 3.2.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . 11 72 4. General Security Goals . . . . . . . . . . . . . . . . . . . . 12 73 4.1. Network Protection . . . . . . . . . . . . . . . . . . . . 12 74 4.2. Protocol Protection . . . . . . . . . . . . . . . . . . . 13 75 4.3. Content Protection . . . . . . . . . . . . . . . . . . . . 13 76 5. Elementary Security Services . . . . . . . . . . . . . . . . . 13 77 6. Technological Building Blocks . . . . . . . . . . . . . . . . 15 78 6.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 6.1.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 15 80 6.1.2. Requirements . . . . . . . . . . . . . . . . . . . . . 15 81 6.1.3. Limitations . . . . . . . . . . . . . . . . . . . . . 16 82 6.2. TESLA . . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 6.2.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 16 84 6.2.2. Requirements . . . . . . . . . . . . . . . . . . . . . 16 85 6.2.3. Limitations . . . . . . . . . . . . . . . . . . . . . 17 86 6.3. SSM Multicast Routing . . . . . . . . . . . . . . . . . . 17 87 6.3.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 17 88 6.3.2. Requirements . . . . . . . . . . . . . . . . . . . . . 17 89 6.3.3. Limitations . . . . . . . . . . . . . . . . . . . . . 17 90 7. Global Security Infrastructure . . . . . . . . . . . . . . . . 17 91 7.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 18 92 7.1.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 18 93 7.1.2. Requirements . . . . . . . . . . . . . . . . . . . . . 18 94 7.1.3. Limitations . . . . . . . . . . . . . . . . . . . . . 18 95 7.2. Group Key Management and Re-keying Protocols . . . . . . . 18 96 7.2.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 18 97 7.2.2. Requirements . . . . . . . . . . . . . . . . . . . . . 18 98 7.2.3. Limitations . . . . . . . . . . . . . . . . . . . . . 18 99 8. New Threats Introduced by the Security Scheme Itself . . . . . 18 100 9. Consequences for the RMT and MSEC Working Group . . . . . . . 18 101 9.1. RMT Transport Message Security Encapsulation Header . . . 18 102 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 103 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 104 12. Normative References . . . . . . . . . . . . . . . . . . . . . 19 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 106 Intellectual Property and Copyright Statements . . . . . . . . . . 21 108 1. Introduction 110 The Reliable Multicast Transport (RMT) Working Group has produced a 111 set of building blocks (BB) and protocol instantiation (PI) 112 specifications for reliable multicast data transport. The two PIs 113 defined within the scope of RMT: ALC 114 [RFC3450][draft-ietf-rmt-pi-alc-revised-03] and NORM [RFC3940], as 115 well as the FLUTE application [RFC3926] built on top of ALC, are 116 "Content Delivery Protocols" (CDP). In this document the term CDP 117 will refer indifferently to either ALC or NORM, with their associated 118 BBs. 120 The use of these BBs and PIs raises new security risks. For 121 instance, these protocols share a novel set of Forward Error 122 Correction (FEC) and congestion control building blocks that present 123 some new capabilities for Internet transport, but may also pose some 124 new security risks. Yet some security risks are not related to the 125 particular BBs used by the PIs, but are more general. Reliable 126 multicast transport sessions are expected to involve at least one 127 sender and multiple receivers. Thus, the risk of and avenues to 128 attack are implicitly greater than that of point-to-point (unicast) 129 transport sessions. Also the nature of IP multicast can expose other 130 coexistent network flows and services to risk if malicious users 131 exploit it. The classic any-source multicast (ASM) model of 132 multicast routing allows any host to join an IP multicast group and 133 send traffic to that group. This poses many potential security 134 challenges. And, while the emerging single-source multicast (SSM) 135 model that allows only a single sender to send traffic to a group 136 simplifies some challenges, there remain some specific issues. For 137 instance, possible areas of attack include those against the control 138 plane where malicious hosts join IP multicast groups to cause 139 multicast traffic to be directed to parts of the network where it is 140 not needed or desired. This can indirectly cause denial-of-service 141 (DoS) to other network flows. Also, attackers may transmit erroneous 142 or corrupt messages to the group or employ strategies such as replay 143 attack within the "data plane" of protocol operation. 145 The goals of this document are therefore: 147 1. to define the possible general security goals. Defining what we 148 want to protect, i.e. the network itself, and/or the protocol, 149 and/or the content, is the first step. 151 2. to list the possible elementary security services that will make 152 it possible to fullfil the general security goals. Some of these 153 services are generic (e.g. object and/or packet integrity), while 154 others are specific to RMT protocols (e.g. congestion control 155 specific security schemes). 157 3. to list some technological building blocks and solutions that can 158 provide the desired security services. 160 4. last but not least, to highlight the CDP specificities that will 161 impact security and define some use-cases. Indeed, the set of 162 solutions proposed to fulfill the security goals will greatly be 163 impacted by the target use case. 165 In some cases, the existing RMT documents already discuss the risks 166 and outline approaches to solve them, at least partially. The 167 purpose of this document is to consolidate this content and provide a 168 basis for further discussion and potential resolution of any 169 significant security issues that may exist. 171 2. Quick Introduction to RMT Protocols and their Use 173 2.1. The Two Families of CDP 175 TODO: a quick introduction to the two families of solutions: ALC/LCT 176 and NORM. 178 2.2. RMT Protocol Specificities 180 This section focuses on the RMT protocol specificities that will 181 impact the choice of the technological building blocks, and the way 182 they can be applied. 184 Both ALC and NORM have been designed with scalability in mind (in 185 terms of the number of receivers). Yet if ALC targets massively 186 scalable sessions (e.g. with millions of receivers), NORM is less 187 ambitious, essentially because of the use of feedback messages to the 188 source. Ideally, the use of security mechanisms should not break 189 this scalability feature. 191 The ALC and NORM protocols differ in the communication paths: 193 o sender to receivers: ALC and NORM, for bulk data transfer and 194 signaling messages; 196 o receivers to sender: NORM only, for feedback messages; 198 o receivers to receivers: NORM only for control messages; 200 But the fact that ALC is capable of working on top of purely 201 unidirectional networks does not mean that no back-channel will be 202 available (see Section 2.3). 204 ALC defines an on-demand content delivery model where receivers can 205 arrive at any time, at their own discretion, download the content and 206 leave the session. This delivery model is not supported by NORM The 207 push and streaming content delivery models are supported by both ALC 208 and NORM. 210 2.3. Target Use Case Specificities 212 This section focuses on the target use cases and their specificities. 213 These specificities will impact both the choice of the technological 214 building blocks and the way they can be applied. One can distinguish 215 the following use case features: 217 o Purely unidirectional transport versus symmetric bidirectional 218 transport versus asymmetric bidirectional transport. Most of the 219 time, the amount of traffic flowing to the source is limited, and 220 one can overlook whether the transport channel is symmetric or 221 not. The nature of the underlying transport channel is of 222 paramount importance, since many security building blocks will 223 require a bidirectional communication; 225 o Massively scalable versus moderately scalable session. Here we do 226 not define precisely what the terms "massively scalable" and 227 "moderately scalable" mean. 229 o Known set of receivers versus unknown set of receivers: does the 230 source know at any point of time the set of receivers or not? Of 231 course, knowing the set of receivers is usually not compatible 232 with massively scalable sessions; 234 o Dynamic set of receivers versus fixed set of receivers: does the 235 source know at some point of time the maximum set of receivers or 236 will it evolve dynamically? In case of a dynamic set of 237 receivers, the source might desire to provide 239 o High rate data flow versus small rate data flow: some security 240 building blocks are CPU intensive and are therefore incompatible 241 with high data rate sessions (e.g. this is the case of solutions 242 that digitally sign all the packets sent). 244 o Protocol stack available at both ends: a solution that requires 245 some non-usual features within the protocol stack will not always 246 be usable. Some target environments (e.g. embedded systems) only 247 provide a minimum set of features and extending them (e.g. to add 248 IPsec) is not necessarily realistic; 250 o Multicast routing other layer-3 protocols in use: for instance, 251 SSM multicast routing is often seen as one of the key service to 252 improve the security within multicast sessions, and some security 253 building blocks require specialized versions of layer-3 protocols 254 (e.g. IGMP/MLD with security extensions). Depending on the 255 target use case, these assumptions might or not be realistic; 257 o (TBD) more items? 259 Depending on the target goal and the associated security building 260 block used, other features, related to the use case, might be of 261 importance. For instance TESLA requires a loose time synchronization 262 between the source and the receivers. Several possibilities exist to 263 that purpose, some of them being only feasible if the target use case 264 provide the appropriate features. 266 3. Known Security Threats 268 Reliable multicast transport sessions are expected to involve at 269 least one sender and multiple receivers. Thus, the risk of and 270 avenues to attack are implicitly greater than that of point-to-point 271 (unicast) transport sessions. Also the nature of IP multicast can 272 expose other coexistent network flows and services to risk if 273 malicious users exploit it. The classic any-source multicast (ASM) 274 model of multicast routing allows any host to join an IP multicast 275 group and send traffic to that group. This poses many potential 276 security challenges. And, while the emerging single-source multicast 277 (SSM) model that allows only a single sender to send traffic to a 278 group simplifies some challenges, there remain some specific issues 279 with respect to adopting standard Internet security mechanisms such 280 as IPSec[RFC2401]. Possible areas of attack include those against 281 the control plane where malicious hosts join IP multicast groups to 282 cause multicast traffic to be directed to parts of the network where 283 it is not needed or desired. This can indirectly cause denial-of- 284 service (DoS) to other network flows. Also, attackers may transmit 285 erroneous or corrupt messages to the group or employ strategies such 286 as replay attack within the "data plane" of protocol operation. 288 CDP integrate several BBs. The TCP-Friendly Multicast Congestion 289 Control (TFMCC) [RFC4654] building block specifies protocol 290 mechanisms where senders and receivers exchange messages to manage 291 sender transmission rate. 293 The IP architecture provides common access to notional control and 294 data planes to both end and intermediate systems. For the purposes 295 of discussion here, the "control plane" mechanisms are considered 296 those with message exchanges between end systems (typically 297 computers) and intermediate systems (typically routers) and while the 298 "data plane" encompasses messages exchanged among end systems, 299 usually pertaining to the transfer of application data. 301 3.1. Control-Plane Attacks 303 While control-plane attacks may be considered outside of the scope of 304 the transport protocol specfications discussed here, it is important 305 to understand the potential impact of such attacks with respect to 306 the deployment and operation of these protocols. For example, 307 awareness of possible IP Multicast control-plane manipulation that 308 can lead to unauthorized (or unexpected) monitoring of data plane 309 traffic by malicious users may lead a transport application or 310 protocol implementation to support encryption to ensure data 311 confidentiality and/or privacy. Also, these types of attack also 312 have bearing on assessing the real risks of potentially more complex 313 attacks against the transport mechanisms themselves. In some cases, 314 the solutions to these control-plane risk areas may reduce the impact 315 or possibility of some data-plane attacks that are discussed in this 316 document. 318 3.1.1. Control Plane Monitoring 320 While this may not be a direct attack on the transport system, it may 321 be possible for an attacker to gain useful information in advancing 322 attack goals by monitoring IP Multicast control plane traffic 323 including group membership and multicast routing information. 324 Indentification of hosts and/or routers participating in specific 325 multicast groups may readily identify systems vulnerable to protocol- 326 specific exploitation. And, with regards to user privacy concerns, 327 such "side information" may be relevant to this emerging aspect of 328 network security. 330 3.1.2. Unauthorized (or Malicious) Group Membership 332 One of the simplest attacks is that where a malicious host joins an 333 IP multicast group so that potentially unwanted traffic is routed to 334 the host's network interface. This type of attack can turn a 335 legitimate source of IP traffic into a "attacker" without requiring 336 any access privileges to the source host or routers involved. This 337 type of attack can be used for denial-of-service purposes or for the 338 real attacker (the malicious joiner) to gain access to the 339 information content being sent. Similarly, some routing protocols 340 may permit any sender (whether joined to the specific group or not) 341 to transmit messages to a multicast group. 343 It is possible that malicious hosts could also spoof IGMP messages, 344 joining groups posing as legitimate hosts (or spoof source traffic 345 from legitimate hosts). This may be done at intermediate locations 346 in the network or by hosts co-resident with the authorized hosts on 347 local area networks. Such spoofing could be done by raw packet 348 generation or with replay of previously-recorded control messages. 349 For the sake of completeness, it should be noted that multicast 350 routing protocol control messaging may be subject to similar threats 351 if insufficient protocol security mechanisms are enabled in the 352 routing infrastructure. 354 The presence of these types of attack may necessitate that policy- 355 based controls be emplaced in routers to limit the distribution 356 (including transmission and reception) of multicast traffic (on a 357 group-wise and/or traffic volume basis) to different parts of the 358 network. Such policy-based controls are beyond the scope of the RMT 359 protocol specifications. However, such network protection mechanisms 360 may reduce the opportunities for or effectiveness of of some of the 361 data-plane attacks discussed later. For example, reverse-path checks 362 can significantly limit opportunities for attackers to conduct replay 363 attacks when hosts actually do use IPSec. Also, future IP Multicast 364 control protocols may wish to consider providing security mechanism 365 to prevent unauthorized monitoring or manipulation of messages 366 related to group membership, routing, and activity. 368 3.2. Data-Plane Attacks 370 This section discusses some types of active attacks that might be 371 conducted "in-band" with respect to the reliable multicast transport 372 protocol operating within the data plane of network data transfer. 373 The passive attack of unauthorized data-plan monitoring is discussed 374 above since such activity might be made possible by the 375 vulnerabilities of the IP Multicast control plane. To cover the two 376 classes of RMT protocols, the active data-plane attacks are 377 categorized as 1) those where the attacker generates messages posing 378 as a data sender, and 2) those where the attacker generates messages 379 posing as a receiver providing feedback to the sender(s) or group. 380 Additionally, a common threat to protocol operation is that of brute- 381 force, rogue packet generation. This is discussed briefly below, but 382 the more subtle attacks that might be conducted are given more 383 attention as those fall within the scope of the RMT transport 384 protocol design. Additionally, special consideration is given to 385 that of the "replay attack" [see Section 3.2.4], as it can be applied 386 across these different categories. 388 3.2.1. Rogue Traffic Generation 390 If an attacker is able to successfully inject packets into the 391 multicast distribution tree, the most obvious denial-of-service 392 attack is for the attacker to generate a large volume of apparently 393 authenticate (when authentication mechanisms are used, a "replay" 394 attack strategy might be used and this is discussed in more in detail 395 in ) traffic. The impact of this type of attack can be significant 396 since the potential for routers to relay the traffic to multiple 397 portions of a networks (as compared to a single unicast routing 398 path). However, other than the amplified negative impact to the 399 network, this type of attack is no different than what is possible 400 with rogue unicast packet generation and similar measures used to 401 protect the network from such attacks could be used to contain this 402 type of brute-force attack. Of course, the pragmatic question of 403 whether current implementations of such protection mechanisms support 404 IP Multicast should be considered. 406 3.2.2. Sender Message Spoofing 408 These types of attacks are applicable to both general types of RMT 409 protocols (e.g., ALC (sender-only transmission) and NORM (sender- 410 receiver exhanges)). Without an authentication mechanism, it is 411 easily possible for a computer to generate sender messages that could 412 disrupt a reliable multicast transfer session. And with FEC-based 413 transport mechanisms, a single packet with an apparently-correct FEC 414 payload identifier [RFC3452] but a corrupted FEC payload could 415 potentially render an entire block of transported data invalid. 416 Thus, a modest injection rate of corrupt traffic could cause severe 417 impairment of data transport. Additionallly, such invalid sender 418 packets could convey out-of-bound indices (payload symbol or block 419 identifiers, etc) that could lead to buffer overflow exploits in 420 receivers or other similar issues in implementations with 421 insufficient checks for invalid data. 423 An indirect use of sender message spoofing would be to generate 424 messages that would cause receivers to take inappropriate congestion- 425 control action. In the case of the layered congestion control 426 mechanisms proposed for ALC use, this could lead to the receivers 427 erroneusly leaving groups associated with higher bandwidth transport 428 layers and suffering unnecessarily low transport rates. Similarly, 429 receivers may be misled to join inappropriate groups directing 430 unwanted traffic to their part of the network. Attacks with similar 431 effect could be conducted against the TFMCC approach proposed for 432 NORM operation with spoofing of sender messages carrying congestion 433 control state to receivers. 435 3.2.3. Receiver Message Spoofing 437 These atacks are limited to RMT protocols that use feedback from 438 receivers in the group to influence sender and other receiver 439 operation. In the NORM protocol, this includes negative- 440 acknowledgement (NACK) messages fed back to the sender to achieve 441 reliable transfer, congestion control feedback content, and the 442 optional positive acknowledgement features of the specification. It 443 is also important to note that for ASM operation, NORM receivers pay 444 attention to the messages of other receivers for the purpose of 445 suppression to avoid feedback implosion as group size grows large. 447 An attacker that can generate false feedback can manipulate the NORM 448 sender to unnecessarily transmit repair information and reduce the 449 goodput of the reliable transfer regardless of the sender's transmit 450 rate. Contrived congestion control feedback could also cause the 451 sender to transmit at an unfairly low rate. 453 As mentioned, spoofed receiver messaging may not be directed only at 454 senders, but also at receivers participating in the session. For 455 example, an attacker may direct phony receiver feedback messages to 456 selected receivers in the group causing those receivers to suppress 457 feedback that might have otherwise been transmitted. This attack 458 could compromise the ability of those receivers to achieve reliable 459 transfer. Also, suppressed congestion control feedback could cause 460 the sender to perhaps transmit at a rate unfair to those attacked 461 receivers if their fair congestion control rate were lower than other 462 receivers in the group. 464 3.2.4. Replay Attacks 466 The infamous "replay attack" (injection of a previously transmitted 467 packet (or at least its payload) into the reliable transport group or 468 directly to one or more of its participants) is given special 469 attention here because of the special consequences it can have on RMT 470 protocol operation. Without specific protection mechanisms against 471 replay (e.g. duplicate message detection), it is possible for these 472 attacks to be successful even when security mechanisms such as packet 473 authentication and/or encryption are employed. 475 3.2.4.1. Replay of Sender Messages 477 Generally, replay of recent protocol messages from the sender will 478 not harm transport, and could potentially assist it, unless it is of 479 sufficient volume to result in the same type of impact as the "rogue 480 traffic generation" described above. However, it is possible that 481 replay of sufficiently old messages may cause receivers to think they 482 are "out of sync" with the sender and reset state, compromising the 483 transfer. Also, if sender transport data identifiers are reused 484 (object identifiers, FEC payload identifiers, etc), it is possible 485 that replay of old messages could corrupt data of a current transfer. 487 3.2.4.2. Replay of Receiver Messages 489 Replay of receiver messages are problematic for the NORM protocol, 490 because replay of NACK messages could cause the sender unnecessarily 491 transmit repair information for an FEC coding block. Similarly, the 492 sender transmission rate might be manipulated by replay of congestion 493 control feedback messages from receivers in the group. And the way 494 that NORM senders estimate group round-trip timing (GRTT) could allow 495 a replay attack to manipulate the senders' GRTT estimate to an 496 unnecessarily large value, adding latency to the reliable transport 497 process. 499 4. General Security Goals 501 The term "security" is extremely vast and encompasses many different 502 meanings. The goal of this section is to clarify what "security" 503 means when considering the reliable multicast transport (RMT) 504 protocols being defined in the IETF RMT working group. The scope can 505 also encompass additional group communication applications, for 506 instance streaming applications. This section only focuses on the 507 desired general goals. The following sections will then discuss the 508 possible elementary services that will be required to fulfill these 509 general goals, as well as the underlying technological building 510 blocks. 512 The possible final goals include, in decreasing order of importance: 514 o network protection: the goal is to protect the network from 515 attacks, no matter whether these attacks are voluntary (i.e. 516 launched by one or several attackers) or non voluntary (i.e. 517 caused by a misbehaving system, where "system" can designate a 518 building block, a protocol, an application, or a user); 520 o protocol protection: the goal is to protect the RMT protocol 521 itself, e.g. to avoid that a misbehaving receiver prevents other 522 receivers to get the content, no matter whether this is done 523 intentionally or not; 525 o and content protection: to goal is to protect the content itself, 526 for instance to guaranty the integrity of the content, or to make 527 sure that only authorized clients can access the content. 529 4.1. Network Protection 531 Protecting the network is of course of primary importance. An 532 attacker should not be able to damage the whole infrastructure by 533 exploiting some features of the RMT protocol. Unfortunately, recent 534 past has shown that the multicast routing infrastructure is 535 relatively fragile, as well as the applications built on top of it. 537 (TBD) develop... 539 4.2. Protocol Protection 541 Protecting the protocols is also importance, since the higher the 542 number of clients, the more serious the consequences of an attack. 543 This is all the more true as scalability is often one of the desired 544 goals of RMT protocols. Ideally, receivers should be sufficiently 545 isolated from one another, so that a single misbehaving receiver does 546 not affect others. Similarly, an external attacker should not be 547 able to break the system. 549 (TBD) develop... 551 4.3. Content Protection 553 Finally, the content itself should be protected when meaningful. 554 This level of security is often the concern of the content provider 555 (and its responsibility). For instance, in case of confidential (or 556 non-free) content, the typical solution consists in encrypting the 557 content. It can be done within the upper application, i.e. above the 558 RMT protocol, or within the transport system. 560 But other requirements may exist, like verifying the integrity of a 561 received object, or authenticating the sender of the received 562 packets. To that goal, one can rely on the use of building blocks 563 integrated within, or above, or beneath the RMT protocol. 565 One may also consider that offering the packet sender authentication 566 and content integrity services are basic requirements that should 567 fulfill any RMT system that operates within an open network, where 568 any attacker can easily inject spurious traffic in an ongoing NORM or 569 ALC session. In that case this goal is not the responsibility of the 570 content provider but the responsibility of the administrator who 571 deploys the RMT system itself. 573 5. Elementary Security Services 575 The goals defined in Section 4 will be fulfilled by means of 576 underlying elementary services, provided by one or several 577 technological building blocks. This section only focuses on these 578 elementary services. 580 The services traditionally listed are: 582 o packet source authentication and integrity: the goal is to enable 583 a receiver to verify the source of a packet and that the packet 584 has not been modified in transit; 586 o packet group authentication and integrity: the goal is to enable a 587 receiver to verify that a packet originated within the group and 588 has not been modified by nonmembers in transit; 590 o packet non-repudiation: the goal is to enable any third party to 591 verify the source of a packet. In that case the source cannot 592 repudiate having sent the packet; 594 o packet anti-replay: the goal is to enable a receiver to detect 595 that a given packet has already been received; 597 o object integrity: the goal is to enable a receiver to verify the 598 integrity of the whole object; 600 o object confidentiality: the goal is to enable a source to guaranty 601 that only authorized receivers can access the object data; 603 o (TBD) more items? 605 To this list, one must add the services specific to the RMT 606 protocols: 608 o congestion control security: the goal is to prevent an attacker 609 from modifying the congestion control protocol normal behavior. 610 Possible goals for an attacker can be to reduce the transmission 611 (NORM) and/or reception rate (ALC or NORM) up to a point where no/ 612 little traffic will flow, or on the opposite, to increase this 613 rate up to a point where it will congest the network; 615 o group management: the goal is to make sure that only authorized 616 receivers (as defined by a certain group management policy), join 617 the RMT session and possibly inform the source; 619 o backward group secrecy: the goal is to prevent a new group member 620 to access the information in clear sent to the group before he 621 joined the group; 623 o forward group secrecy: the goal is to prevent a former group 624 member to access the information in clear sent to the group after 625 he left the group; 627 o (TBD) more items? 629 These services are usually achieved by means of one or several 630 technological building blocks. The target use case where the RMT 631 system will be deployed will greatly impact the choice of the 632 technological building block(s) used to provide these services, as 633 explained in Section 2.3. 635 6. Technological Building Blocks 637 Here is a list of techniques and building blocks that are likely to 638 fulfill one or several of the goals listed above: 640 o IPsec; 642 o TESLA; 644 o use of SSM (Source Specific Multicast) multicast routing; 646 o Digital Signature; 648 o (TBD) add other BBs 650 Each of them is now quickly discussed. In particular we identify 651 what service it can offer, its limitations, and its field of 652 application (adequacy W.R.T. the CDP and the target use case). 654 6.1. IPsec 656 6.1.1. Benefits 658 One direct approach using existing standards is to apply IPSec 659 [RFC2401] to achieve the following properties for message 660 transmission: 662 1. Authentication (IPSec AH or ESP) 664 2. Confidentiality (IPSec ESP) 666 6.1.2. Requirements 668 It is expected that the approach to apply IPSec for reliable 669 multicast transport sessions is similar to that described for OSPFv3 670 security[RFC4552]. The following list proposes the IPSec 671 capabilities needed to support a similar approach to RMT protocol 672 security: 674 1. Mode - Transport mode IPSec security is required; 676 2. Selectors - source and destination addresses and ports, protocol. 678 3. For some uses, preplaced manual key support may be required to 679 support application deployment and operation. For automated key 680 management for group communication the Group Secure Association 681 Key Management Protocol (GSAKMP) described in [RFC4535] may be 682 used to emplace the keys for IPSec operation. 684 Note that a periodic rekeying procedure similar to that described in 685 RFC 4552 can also be applied with the additional benefit that the 686 reliable transport aspects of the RMT protocols provide robustness to 687 any message loss that might occur due to ANY timing discrepencies 688 among the participants in the reliable multicast session. 690 6.1.3. Limitations 692 It should be noted that current IPSec implementations may not provide 693 the capability for anti-replay protection for multicast operation. 694 In the case of the NORM protocol, a sequence number is provided for 695 packet loss measurement to support congestion control operation. 696 This sequence number can also be used within a NORM implementation 697 for detecting duplicate (replayed) messages from sources (senders or 698 receivers) within the transport session group. In this way, 699 protection against replay attack can be achieved in conjunction with 700 the authentication and possibly confidentiality properties provided 701 by an IPSec encapsulation of NORM messages. NORM receivers generate 702 a very low volume of feedback traffic and it is expected that the 16- 703 bit sequence space provided by NORM will be sufficient for replay 704 attack protection. When a NORM session is long-lived, the limits of 705 the sender repair window are expected to provide protection from 706 replayed NACKs as they would typically be outside of the sender's 707 current repair window. It is suggested that IPSec implementations 708 that can provide anti-replay protection for IP Multicast traffic, 709 even when there are multiple senders within a group, be adopted. The 710 GSAKMP document has some discussion in this area. 712 6.2. TESLA 714 6.2.1. Benefits 716 TESLA [TESLA_4_ALC_NORM] offers a loss tolerant, lightweight, 717 authentication/integrity service for the packets generated by the 718 session's sender. Depending on the time synchronization method used, 719 TESLA is compatible with massively scalable sessions. TESLA CPU 720 processing remains limited, in particular because it essentially 721 relies on symmetric cryptographic building blocks. 723 6.2.2. Requirements 725 The security offered by TESLA relies heavily on time. Therefore the 726 session's sender and each receiver need to be time synchronized in a 727 secure way. To that purpose, several methods exist, depending on the 728 use case: direct time synchronization (which requires a bidirectional 729 transport channel); using a secure NTP infrastructure (which also 730 requires a bidirectional transport channel); or a GPS or Galileo 731 device; or a clock with a time-drift that is negligible in front of 732 the TESLA time accuracy requirements. So TESLA can be used with both 733 bidirectional and unidirectional transport channels, in the later 734 case on condition an appropriate indirect time synchronization method 735 exists. 737 6.2.3. Limitations 739 TESLA does not consider the packets that will be generated by 740 receivers, for instance the feedback packets of NORM, which must be 741 protected by other means. 743 Another limitation is that TESLA requires some buffering capabilities 744 at the receivers in order to enable the delayed authentication 745 feature. This is not considered though as a major issue in the 746 general case (e.g. FEC decoding of objects within an ALC session 747 already requires some buffering capabilities, that often exceed that 748 of TESLA), but it might be one in case of embedded environments. 750 6.3. SSM Multicast Routing 752 6.3.1. Benefits 754 6.3.2. Requirements 756 6.3.3. Limitations 758 7. Global Security Infrastructure 760 Deploying the elementary technological building blocks often requires 761 that a global security infrastructure exists. This security 762 infrastructure: 764 o can provide a PKI (Public Key Infrastructure): this PKI provides 765 for trusted third party vetting of, and vouching for, user 766 identities. It also allows the binding of public keys to users, 767 usually by means of certificates. 769 o can provide a group key management service: this service usually 770 provides rekeying schemes, either periodic or triggered by some 771 higher level event. It is required in particular when the group 772 is dynamic and forward/backward secrecy are important. This is 773 also required to improve the scalability of the CDP (since key 774 management is done automatically, using a key server topology), or 775 the security provided by the CDP (since the underlying 776 cryptographic keys will be changed frequently). 778 o (TBD): add more... 780 TBD: more information on group key management, etc. 782 7.1. Public Key Infrastructure 784 7.1.1. Benefits 786 7.1.2. Requirements 788 7.1.3. Limitations 790 7.2. Group Key Management and Re-keying Protocols 792 7.2.1. Benefits 794 7.2.2. Requirements 796 7.2.3. Limitations 798 8. New Threats Introduced by the Security Scheme Itself 800 Introducing a security scheme, as a side effect, can sometimes 801 introduce new security threats. For instance, signing all packets 802 with asymmetric cryptographic schemes (to provide a source 803 authentication/content integrity/anti-replay service) opens the door 804 to DoS attacks. Indeed, verifying asymmetric-based cryptographic 805 signatures is a CPU intensive task. Therefore an attacker can easily 806 overload a receiver (or a sender in case of NORM) by injecting a 807 significant number of faked packets. 809 XXX: TODO... 811 9. Consequences for the RMT and MSEC Working Group 813 (TBD) discuss here the possible recommendations for the RMT and MSEC 814 groups... Or remove this section altogether... 816 9.1. RMT Transport Message Security Encapsulation Header 818 An alternative approach to using IPSec to provide the necessary 819 properties to protect RMT protocol operation from the application 820 attacks described earlier, is to extend the RMT protocol message set 821 to include a message encapsulation option. This encapsulation header 822 could be used to provide authentication, confidientiality, and anti- 823 replay protection as needed. Since this would be independent of the 824 IP layer, the header might need to provide a source identifier to be 825 used as a "selector" for recalling security state (including 826 authentication certificate(s), sequence state, etc) for a given 827 message. In the case of the NORM protocol, a NormNodeId field exists 828 that could be used for this purpose. In the case of ALC, the 829 security encapsulation mechanism would need to add this function. 830 The security encapsulation mechanism, although resident "above" the 831 IP layer, could use GSAKMP [RFC4535] or a similar approach for 832 automated key managment. 834 10. Security Considerations 836 Not applicable since this document does not introduce any new 837 technique. 839 11. Acknowledgments 841 12. Normative References 843 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 844 Requirement Levels", BCP 14, RFC 2119, March 1997. 846 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 847 Internet Protocol", RFC 2401, November 1998. 849 [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. 850 Crowcroft, "Asynchronous Layered Coding (ALC) Protocol 851 Instantiation", RFC 3450, December 2002. 853 [RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, 854 M., and J. Crowcroft, "Layered Coding Transport (LCT) 855 Building Block", RFC 3451, December 2002. 857 [RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 858 M., and J. Crowcroft, "Forward Error Correction (FEC) 859 Building Block", RFC 3452, December 2002. 861 [RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, 862 "FLUTE - File Delivery over Unidirectional Transport", 863 RFC 3926, October 2004. 865 [RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker, 866 "Negative-acknowledgment (NACK)-Oriented Reliable 867 Multicast (NORM) Protocol", RFC 3940, November 2004. 869 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 870 "GSAKMP: Group Secure Association Key Management 871 Protocol", RFC 4535, June 2006. 873 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 874 for OSPFv3", RFC 4552, June 2006. 876 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 877 Congestion Control (TFMCC): Protocol Specification", 878 RFC 4654, August 2006. 880 [TESLA_4_ALC_NORM] 881 Roca, V., Francillon, A., and S. Faurite, "The Use of 882 TESLA in the ALC and NORM Protocols", 883 draft-ietf-msec-tesla-for-alc-norm-00.txt (work in 884 progress), June 2006. 886 [draft-ietf-rmt-pi-alc-revised-03] 887 Luby, M., Watson, M., and L. Vicisano, "Asynchronous 888 Layered Coding (ALC) Protocol Instantiation", 889 draft-ietf-rmt-pi-alc-revised-03.txt (work in progress), 890 April 2006. 892 Authors' Addresses 894 Brian Adamson 895 Naval Research Laboratory 896 Washington, DC 20375 897 USA 899 Email: adamson@itd.nrl.navy.mil 900 URI: http://cs.itd.nrl.navy.mil 902 Vincent Roca 903 INRIA 904 655, av. de l'Europe 905 Zirst; Montbonnot, ST ISMIER cedex 38334 906 France 908 Email: vincent.roca@inrialpes.fr 909 URI: http://planete.inrialpes.fr/~roca/ 911 Full Copyright Statement 913 Copyright (C) The Internet Society (2006). 915 This document is subject to the rights, licenses and restrictions 916 contained in BCP 78, and except as set forth therein, the authors 917 retain all their rights. 919 This document and the information contained herein are provided on an 920 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 921 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 922 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 923 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 924 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 925 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 927 Intellectual Property 929 The IETF takes no position regarding the validity or scope of any 930 Intellectual Property Rights or other rights that might be claimed to 931 pertain to the implementation or use of the technology described in 932 this document or the extent to which any license under such rights 933 might or might not be available; nor does it represent that it has 934 made any independent effort to identify any such rights. Information 935 on the procedures with respect to rights in RFC documents can be 936 found in BCP 78 and BCP 79. 938 Copies of IPR disclosures made to the IETF Secretariat and any 939 assurances of licenses to be made available, or the result of an 940 attempt made to obtain a general license or permission for the use of 941 such proprietary rights by implementers or users of this 942 specification can be obtained from the IETF on-line IPR repository at 943 http://www.ietf.org/ipr. 945 The IETF invites any interested party to bring to its attention any 946 copyrights, patents or patent applications, or other proprietary 947 rights that may cover technology that may be required to implement 948 this standard. Please address the information to the IETF at 949 ietf-ipr@ietf.org. 951 Acknowledgment 953 Funding for the RFC Editor function is provided by the IETF 954 Administrative Support Activity (IASA).