idnits 2.17.1 draft-ietf-nsis-threats-06.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1235. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1248. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 24, 2004) is 7123 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-nsis-fw-06 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-fw (ref. 'I-D.ietf-nsis-fw') ** Downref: Normative reference to an Informational RFC: RFC 3726 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-03 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-03 == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-04 == Outdated reference: A later version (-06) exists of draft-ietf-nsis-rsvp-sec-properties-05 == Outdated reference: A later version (-05) exists of draft-ietf-nsis-signalling-analysis-04 Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS Working Group H. Tschofenig 3 Internet-Draft D. Kroeselberg 4 Expires: April 24, 2005 Siemens 5 October 24, 2004 7 Security Threats for NSIS 8 draft-ietf-nsis-threats-06.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 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 22 Internet-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 24, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 This threats document provides a detailed analysis of the security 44 threats relevant to the NSIS protocol suite. It calls attention to, 45 and helps with the understanding of, various security considerations 46 in the NSIS Requirements, Framework, and Protocol proposals. This 47 document does not describe vulnerabilities of specific parts of the 48 NSIS protocol suite. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Communications Models . . . . . . . . . . . . . . . . . . . 4 54 3. Generic Threats . . . . . . . . . . . . . . . . . . . . . . 9 55 3.1 Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 9 56 3.2 Replay of Signaling Messages . . . . . . . . . . . . . . . 13 57 3.3 Injecting or Modifying Messages . . . . . . . . . . . . . 13 58 3.4 Insecure Parameter Exchange and Negotiation . . . . . . . 13 59 4. NSIS-Specific Threat Scenarios . . . . . . . . . . . . . . . 15 60 4.1 Threats during NSIS SA Usage . . . . . . . . . . . . . . . 15 61 4.2 Flooding . . . . . . . . . . . . . . . . . . . . . . . . . 15 62 4.3 Eavesdropping and Traffic Analysis . . . . . . . . . . . . 17 63 4.4 Identity Spoofing . . . . . . . . . . . . . . . . . . . . 17 64 4.5 Unprotected Authorization Information . . . . . . . . . . 19 65 4.6 Missing Non-Repudiation . . . . . . . . . . . . . . . . . 20 66 4.7 Malicious NSIS Entity . . . . . . . . . . . . . . . . . . 21 67 4.8 Denial of Service Attacks . . . . . . . . . . . . . . . . 22 68 4.9 Disclosing the Network Topology . . . . . . . . . . . . . 23 69 4.10 Unprotected Session or Reservation Ownership . . . . . . 23 70 4.11 Attacks against the NTLP . . . . . . . . . . . . . . . . 25 71 5. Security Considerations . . . . . . . . . . . . . . . . . . 26 72 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 73 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 28 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 75 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 29 76 8.2 Informative References . . . . . . . . . . . . . . . . . . . 29 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 78 Intellectual Property and Copyright Statements . . . . . . . 32 80 1. Introduction 82 Whenever a new protocol is developed or existing protocols are 83 modified, threats to their security should be evaluated. To address 84 security in the NSIS working group, a number of steps have been 85 taken: 87 NSIS Analysis Activities (see [I-D.ietf-nsis-rsvp-sec-properties] 88 and [I-D.ietf-nsis-signalling-analysis]) 90 Security Threats for NSIS 92 NSIS Requirements (see [RFC3726]) 94 NSIS Framework (see [I-D.ietf-nsis-fw]) 96 NSIS Protocol Suite (see GIMPS [I-D.ietf-nsis-ntlp], NAT/Firewall 97 NSLP [I-D.ietf-nsis-nslp-natfw] and QoS NSLP 98 [I-D.ietf-nsis-qos-nslp]) 100 This document identifies the basic security threats that need to be 101 addressed during the design of the NSIS protocol suite. Even if the 102 base protocol is secure, certain extensions may cause problems when 103 used in a particular environment. 105 This document cannot provide detailed threats for all possible NSIS 106 Signaling Layer Protocols (NSLPs). QoS [I-D.ietf-nsis-qos-nslp], 107 NAT/Firewall and other NSLP documents need to provide a description 108 of their trust models and a threat assessment for their specific 109 application domain. This document aims to provide some help for the 110 subsequent design of the NSIS protocol suite. Investigations of 111 security threats in a specifc architecture or context are outside the 112 scope of this document. 114 We use the NSIS terms defined in [RFC3726] and in [I-D.ietf-nsis-fw]. 116 2. Communications Models 118 The NSIS suite of protocols is envisioned to support various 119 signaling applications that need to install and/or manipulate state 120 at nodes along the data flow path through the network. As such, the 121 NSIS protocol suite involves the communication between different 122 entities. 124 This section offers terminology for common communication models, 125 which are relevant to securing the NSIS protocol suite. 127 An abstract network topology with its administrative domains is shown 128 in Figure 1 and in Figure 2 the relationship between NSIS entities 129 along the path is illustrated. For illustrative reasons only 130 end-to-end NSIS signaling is depicted but it might be used in other 131 variations as well. Signaling can start at any place and might 132 terminate at any other place within the network. Depending on the 133 trust relationship between NSIS entities and the traversed network 134 parts different security problems arise. 136 The notion of trust and trust relationship used in this document is 137 informal and can be best captured by the definition provided in 138 Section 1.1 of [RFC3756]. For completeness we include the definition 139 of a trust relationship which denotes a mutual a priori relationship 140 between the involved organizations or parties where the parties 141 believe that the other parties will behave correctly even in the 142 future. 144 An important observation for NSIS is that a certain degree of trust 145 has to be placed into intermediate NSIS nodes along the path between 146 an NSIS Initiator and an NSIS Responder, specifically that they 147 perform message processing and take the necessary actions. A 148 complete lack of trust between any of the participating entities will 149 cause NSIS signaling to fail. 151 Please note that it is not possible to completely describe a trust 152 model without considering the details and behavior of the NTLP, the 153 NSLP (e.g., QoS NSLP) and the deployment environment. For example, 154 securing the communication between an end host (which acts as the 155 NSIS Initiator) and the first NSIS node (which might be in the 156 attached network or even a number of networks away) is impacted by 157 the trust relationships between these entities. In a corporate 158 network environment a stronger degree of trust typically exists than 159 in an unmanaged network. 161 Figure 1 introduces convenient abbreviations for network parts with 162 similar properties: first-peer, last-peer, intra-domain, or 163 inter-domain. 165 +------------------+ +---------------+ +------------------+ 166 | | | | | | 167 | Administrative | | Intermediate | | Administrative | 168 | Domain A | | Domains | | Domain B | 169 | | | | | | 170 | (Inter-domain Communication) | 171 | +-------->+---+<------------->+---+<--------+ | 172 | (Intra-domain | | | | (Intra-domain | 173 | Communication) | | | | Communication) | 174 | | | | | | | | 175 | v | | | | v | 176 +--------+---------+ +---------------+ +---------+--------+ 177 ^ ^ 178 | | 179 First Peer Communication Last Peer Communication 180 | | 181 v v 182 +-----+-----+ +-----+-----+ 183 | NSIS | | NSIS | 184 | Initiator | | Responder | 185 +-----------+ +-----------+ 187 Figure 1: Communication patterns in NSIS 189 First-Peer/Last-Peer Communication: 191 The end-to-end communication scenario depicted in Figure 1 192 includes the communication between the end hosts and their nearest 193 NSIS hops. "First-peer communications" refers to the peer-to-peer 194 interaction between a signaling message originator, the NSIS 195 Initiator (NI), and the first NSIS-aware entity along the path. 196 This "first-peer communications" commonly comes with specific 197 security requirements that are especially important for addressing 198 security issues between the end host (and a user) and the network 199 it is attached to. 201 To illustrate this, in roaming environments it is difficult to 202 assume the existence of a pre-established security association 203 directly available for NSIS peers involved in first-peer 204 communications, because these peers cannot be assumed to have any 205 pre-existing relationship with each other. For enterprise 206 networks, in contrast, the situation is different. Usually there 207 is a fairly strong (pre-established) trust relationship between 208 the peers. Enterprise network administrators usually have some 209 degree of freedom to select the appropriate security protection 210 and to enforce it. The choice of selecting a security mechanism 211 is therefore often influenced by the already available 212 infrastructure, and per-session negotiation of security mechanisms 213 is often not required (which, in contrast, is required in a 214 roaming environment). 216 Last-Peer communication is a variation of First-Peer communication 217 where the roles are reversed. 219 Intra-Domain Communication: 221 After verification of the NSIS signaling message at the border of 222 an administrative domain, an NSIS signaling message traverses the 223 network within the same administrative domain to which the first 224 peer belongs. It might not be necessary to repeat the 225 authorization procedure of the NSIS initiator again at every NSIS 226 node within this domain. Key management within the administrative 227 domain might also be simpler. 229 Security protection is still required to prevent threats by 230 non-NSIS nodes in this network. 232 Inter-Domain Communication: 234 Inter-Domain communication deals with the interaction between 235 administrative domains. For some NSLPs (for example QoS NSLP) 236 this interaction is likely to take place between neighboring 237 domains whereas in other NSLPs (such as the NAT/Firewall NSLP) the 238 core network is usually not involved. 240 If signaling messages are conveyed transparently in the core 241 network (i.e., they are neither intercepted nor processed in the 242 core network), then the signaling message communications 243 effectively takes place between access networks. This might place 244 a burden on authorization handling and on the key management 245 infrastructure required between these access networks, which might 246 not know of each other in advance. 248 To refine the above differentiation based on the network parts that 249 NSIS signaling may traverse, we subsequently consider relationships 250 between involved entities. Since a number of NSIS nodes might 251 actively participate in a specific protocol exchange, a larger number 252 of possible relationships need to be analyzed than in other 253 protocols. Figure 2 illustrates possible relationships between the 254 entities involved in the NSIS protocol suite. 256 **************************************** 257 * * 258 +----+-----+ +----------+ +----+-----+ 259 +-----+ NSIS +-------+ NSIS +--------+ NSIS +-----+ 260 | | Node 1 | | Node 2 | | Node 3 | | 261 | +----------+ +----+-----+ +----------+ | 262 | ~ | 263 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 264 | ~ | 265 +--+--+-----+ +---------+-+ 266 | NSIS +//////////////////////////////////////////+ NSIS | 267 | Initiator | | Responder | 268 +-----------+ +-----------+ 270 Legend: 271 -----: Peer-to-Peer Relationship 272 /////: End-to-End Relationship 273 *****: Middle-to-Middle Relationship 274 ~~~~~: End-to-Middle Relationship 276 Figure 2: Possible NSIS Relationships 278 End-to-Middle Communications: 280 The scenario in which one NSIS entity involved is an end-entity 281 (Initiator or Responder) and the other entity is any intermediate 282 hop other than the immediately adjacent peer is typically called 283 the end-to-middle scenario (see Figure 2). A motivation for 284 including this scenario can, for example, be found in SIP 285 [RFC3261]. 287 An example of end-to-middle interaction might be an explicit 288 authorization from the NSIS Initiator to some intermediate node. 289 Threats specific to this scenario may be introduced by some 290 intermediate NSIS hops which are not allowed to eavesdrop or 291 modify certain objects. 293 Middle-to-Middle Communications: 295 Middle-to-middle communication refers to the exchange of 296 information between two non-neighboring NSIS nodes along the path. 297 Intermediate NSIS hops may have to deal with specific security 298 threats, which do not directly involve the NSIS Initiator or the 299 NSIS Responder. 301 End-to-End Communications: 303 NSIS aims to signal information from an Initiator to some NSIS 304 nodes along the path to a data receiver. In case of end-to-end 305 NSIS signaling the last node is the NSIS Responder as the data 306 receiver. The NSIS protocol suite is not an end-to-end protocol 307 used to exchange information purely between end hosts. 309 Typically, it is not required to cryptographically protect NSIS 310 messages between the NSIS Initiator and the NSIS Responder. 311 Protecting the entire signaling message end-to-end is not feasible 312 since intermediate NSIS nodes need to add, inspect, modify or 313 delete objects from the signaling message. 315 3. Generic Threats 317 This section provides scenarios of threats that are applicable to 318 signaling protocols in general. Note that some of these scenarios 319 use the term user instead of NSIS Initiator. This is mainly because 320 security protocols allow differentiation between entities as hosts 321 and as users (based on the identifiers used). 323 For the following subsections, we use the general distinction into 324 two cases in which attacks may occur. These are according to the 325 separate steps, or phases, normally encountered when applying 326 protocol security (with, e.g., IPsec, TLS, Kerberos, or SSH). 327 Therefore, this section starts with a brief motivation for this 328 separation. 330 Security protection of protocols is often separated into two steps. 331 The first step provides primarily entity authentication and key 332 establishment (which result in a persistent state often called a 333 security association), whereas the second step provides message 334 protection (some combination of data origin authentication, data 335 integrity, confidentiality, and replay protection) using the 336 previously established security association. The first step tends to 337 be more expensive than the second, which is the main reason for the 338 separation. If messages are transmitted infrequently, then these two 339 steps may be collapsed into a single and usually rather costly one. 340 One such example is e-mail protection via S/MIME. The two steps may 341 be tightly bound into a single protocol, as in TLS, or defined in 342 separate protocols, as with IKE and IPsec. We use this separation to 343 cover the different threats in more detail. 345 3.1 Man-in-the-Middle Attacks 347 This section describes both security threats that exist if two peers 348 do not already share a security association or do not use security 349 mechanisms at all, and threats that are applicable when a security 350 association is already established. 352 Attacks during NSIS SA Establishment: 354 While establishing a security association, an adversary fools the 355 signaling message Initiator with respect to the entity to which it 356 has to authenticate. The Initiator authenticates to the 357 man-in-the-middle adversary, who is then able to modify signaling 358 messages to mount DoS attacks or steal services that get billed to 359 the Initiator. In addition, it may be able to terminate the 360 Initiator's NSIS messages and inject messages to a peer itself, 361 therefore acting as the peer to the Initiator and as the Initiator 362 to the peer. This results in the Initiator wrongly believing that 363 it is talking to the "real" network, whereas it is actually 364 attached to an adversary. For this attack to be successful, 365 pre-conditions have to hold which are described in the following 366 three cases: 368 Missing Authentication: 370 In the first case, this threat can be carried out because of 371 missing authentication between neighboring peers: without 372 authentication a NI, NR, or NF is unable to detect an 373 adversary. However, in some practical cases authentication 374 might be difficult to accomplish, either because the next peer 375 is unknown, because of misbelieved trust relationships in parts 376 of the network, or because of the inability to establish proper 377 security protection (inter-domain signaling messages, dynamic 378 establishment of a security association, etc.). If one of the 379 communicating endpoints is unknown, then for some security 380 mechanisms it is either impossible, or impractical to apply 381 appropriate security protection. Sometimes network 382 administrators use intra-domain signaling messages without 383 proper security. Such a configuration would then allow an 384 adversary on a compromised non-NSIS-aware node to interfere 385 with nodes running an NSIS signaling protocol. Note that this 386 type of threat goes beyond those caused by malicious NSIS nodes 387 (described in Section 4.7). 389 Unilateral Authentication: 391 In the case of unilateral authentication, the NSIS entity that 392 does not authenticate its peer is unable to discover a 393 man-in-the-middle adversary. Although mutual authentication of 394 signaling messages should take place between each peer 395 participating in the protocol operation, special attention is 396 given here to first-peer communications. Unilateral 397 authentication between an end host and the first peer (just 398 authenticating the end host) is still common today, but it 399 opens up many possibilities for man-in-the-middle attackers 400 impersonating either the end host or the (administrative domain 401 represented by the) first peer. 403 Missing or unilateral authentication, as described above, is 404 part of a general problem of network access with inadequate 405 authentication, and it should not be considered something 406 unique to the NSIS signaling protocol. Obviously, there is a 407 strong need to correctly address this in a future NSIS protocol 408 suite. The signaling protocols addressed by NSIS are different 409 from other protocols, in which only two entities are involved. 410 Note that first-peer authentication is especially important, 411 because a security breach here could impact nodes beyond the 412 entities directly involved (or even beyond a local network). 414 Finally it should be noted that the signaling protocol should 415 be considered as a peer-to-peer protocol, where the roles of 416 Initiator and Responder can be reversed at any time. Hence, 417 unilateral authentication is not particularly useful for such a 418 protocol. However, there might be a need to have some form of 419 asymmetry in the authentication process, whereby one entity 420 uses a different authentication mechanism than the other one. 421 As an example, the combination of symmetric and asymmetric 422 cryptography should be mentioned. 424 Weak Authentication: 426 In this case, the threat can be carried out because of weak 427 authentication mechanisms whereby information transmitted 428 during the NSIS SA establishment process may leak passwords or 429 allow offline dictionary attacks. This threat is applicable to 430 NSIS for the process of selecting certain security mechanisms. 432 Finally, we conclude a description of a man-in-the-middle attack 433 during the discovery phase. This attack benefits from the fact that 434 NSIS nodes are likely to be unaware of the network topology. 435 Furthermore, an authorization problem might arise if an NSIS QoS NSLP 436 node pretends to be a NSIS NAT/Firewall specific node or vice versa. 438 An adversary might want to inject a bogus reply message forcing the 439 discovery message initiator to start a messaging association 440 establishment with either an adversary or with another NSIS node 441 which is not along the path. Figure 3 describes the attack in more 442 detail for peer-to-peer addressed messages with a discovery 443 mechanism. For end-to-end addressed messages the attack is also 444 applicable particularly if the adversary is located along the path 445 and able to intercept the discovery message which traverses the 446 adversary. The man-in-the-middle adversary might redirect to another 447 legimimate NSIS node. A malicious NSIS node can be detected with the 448 corresponding security mechanisms but a legitimate NSIS node which is 449 not the next NSIS node along the path cannot be detected without 450 having topology knowledge. 452 +-----------+ Messaging Association 453 Message | Adversary | Establishment 454 Association +--->+ +<----------------+ 455 Establish- | +----+------+ |(4) 456 ment | IPx | | 457 (3)| |Discovery Reply v 458 | | (IPx) +---+-------+ 459 v | (2) | NSIS | 460 +------+-----+ | /----------->+ Node B +-------- 461 | NSIS +<--+ / Discovery +-----------+ 462 | Node A +---------/ Request IPr 463 +------------+ (1) 464 IPi 466 Figure 3: MITM Attack during the Discovery Exchange 468 This attack assumes that the adversary is able to eavesdrop the 469 initial discovery message sent by the sender of the discovery 470 message. Furthermore, we assume that the discovery reply message by 471 the adversary returns to the discovery message initiator faster than 472 the real response. This represents some race condition 473 characteristics if the next NSIS node is very close (in IP-hop terms) 474 to the initiator. It should be noted that the process is 475 self-healing since the discovery process is periodically 476 retransmitted. If an adversary is unable to mount this attack with 477 every discovery message then the correct next NSIS node along the 478 path will be discovered again. A ping-pong behavior might be the 479 consequence. 481 As shown in message step (2) in Figure 3 the adversary returns a 482 discovery reply message with its own IP address as the next NSIS 483 aware node along the path. Without any additional information the 484 discovery message initiator has to trust this information. Then a 485 messaging association is established with an entity at a given IP 486 address IPx (i.e., with the adversary) in step (3). The adversary 487 then establishes a messaging association with a further NSIS node and 488 forwards the signaling message. Note that the adversary might just 489 modify the Disovery Reply message to force NSIS Node A to establish a 490 messaging association with another NSIS node which is not along the 491 path. This can then be exploited by the adversary. Particularly the 492 interworking with NSIS unaware NATs might cause additional unexpected 493 problems. 495 As a variant of this attack an adversary not able to eavesdrop 496 transmitted discovery requests could flood a node with bogus 497 discovery reply messages. If the discovery message sender 498 accidentally accepts one of those bogus messages then a MITM-attack 499 as described in Figure 3 is possible. 501 3.2 Replay of Signaling Messages 503 This threat scenario covers the case in which an adversary eavesdrops 504 and collects signaling messages and replays them at a later time (or 505 at a different place, or uses parts of them at a different place or 506 in a different way, e.g., cut-and-paste attacks). Without proper 507 replay protection, an adversary might mount man-in-the-middle, denial 508 of service, and theft of service attacks. 510 A more difficult attack that may cause problems even in case of 511 replay protection requires the adversary to crash an NSIS-aware node, 512 causing it to lose state information (sequence numbers, security 513 associations, etc.), and then be able to replay old signaling 514 messages. This attack takes advantage of re-synchronization 515 deficiencies. 517 3.3 Injecting or Modifying Messages 519 This type of threat involves integrity violations, whereby an 520 adversary modifies signaling messages (e.g., by acting as a 521 man-in-the-middle) to cause unexpected network behavior. Possible 522 actions an adversary might consider for its attack are reordering, 523 delaying, dropping, injecting, truncating, and otherwise modifying 524 messages. 526 An adversary may inject a signaling message requesting a large amount 527 of resources (possibly using a different user's identity). Other 528 resource requests may then be rejected. In combination with identity 529 spoofing, it is also possible to carry out fraud. This attack is 530 only feasible in the absence of authentication and signaling message 531 protection. 533 Some threats directly related to these are described in Section 4.4, 534 Section 4.7, and Section 4.8. 536 3.4 Insecure Parameter Exchange and Negotiation 538 First, protocols may be useful in a variety of scenarios with 539 different security requirements. Second, different users (e.g., a 540 university, a hospital, a commercial enterprise, or a government 541 ministry) have inherently different security requirements. Third, 542 different parts of a network (e.g., within a building, across a 543 public carrier's network, or over a private microwave link) may need 544 different levels of protection. It is often difficult to meet these 545 (sometimes conflicting) requirements with a single security mechanism 546 or fixed set of security parameters, so often a selection of 547 mechanisms and parameters is offered. Therefore, a protocol is 548 required to agree on certain security mechanisms and parameters. An 549 insecure parameter exchange or security negotiation protocol can help 550 an adversary mount a downgrading attack to force selection of weaker 551 mechanisms than mutually desired. Hence, without binding the 552 negotiation process to the legitimate parties and protecting it, an 553 NSIS protocol suite might be only as secure as the weakest mechanism 554 provided (e.g., weak authentication), and the benefits of defining 555 configuration parameters and a negotiation protocol are lost. 557 4. NSIS-Specific Threat Scenarios 559 This section describes 11 threat scenarios in terms of attacks on and 560 security deficiencies in the NSIS signaling protocol. A number of 561 security deficiencies might enable an attack. Fraud is an example of 562 an attack that might be enabled by missing replay protection, missing 563 protection of authorization tokens, identity spoofing, missing 564 authentication, and other deficiencies that help an adversary steal 565 resources. Different threat scenarios based on deficiencies that 566 could enable an attack are addressed in this section. 568 The threat scenarios are not independent. Some of them, e.g., denial 569 of service, are well-established security terms and, as such, need to 570 be addressed, but are often enabled by one or more deficiencies 571 described under other scenarios. 573 4.1 Threats during NSIS SA Usage 575 Once a security association is established (and used) to protect 576 signaling messages, many basic attacks are prevented. However, a 577 malicious NSIS node is still able to perform various attacks as 578 described in Section 4.7. Replay attacks may be possible when an 579 NSIS node crashes, restarts, and performs state re-establishment. 580 Proper re-synchronization of the security mechanism must therefore be 581 provided to address this problem. 583 4.2 Flooding 585 This section describes attacks that allow an adversary to flood an 586 NSIS node with bogus signaling messages to cause a denial of service 587 attack. 589 We will discuss this threat at different layers in the NSIS protocol 590 suite: 592 Processing of Router Alert Options: 594 The processing of Router Alert Option (RAO) requires a router to 595 do some additional processing by intercepting packets with IP 596 options, which might lead to additional delay for legitimate 597 requests, or even to reject some of them. A router being flooded 598 with a large number of bogus messages requires resources before 599 finding out that these messages have to be dropped. 601 If the protocol is based on using interception for message 602 delivery this threat cannot be completely eliminated, but the 603 protocol design should attempt to limit the processing that has to 604 be done on the RAO-bearing packet so that it is as similar as 605 possible to that for an arbitrary packet addressed directly to one 606 of the router interfaces. 608 Attacks against the Transport Layer protocol: 610 Certain attacks can be mounted against transport protocols by 611 flooding a node with bogus requests or even to finish the 612 handshake phase to establish a transport layer association. These 613 types of threats are also addressed in Section 4.11. 615 Force NTLP to do more processing: 617 Some protocol fields might allow an adversary to force an NTLP 618 node to perform more processing. Additionally it might be 619 possible to interfere with the flow control or the congestion 620 control procedure. These types of threats are also addressed in 621 Section 4.11. 623 Furthermore, it might be possible to force the NTLP node to 624 perform some computations or signaling message exchanges by 625 injecting "trigger" events (which are unprotected). 627 Force NSLP to-do more processing: 629 An adversary might benefit from flooding an NSLP node with 630 messages which must be stored (e.g., due to fragmentation 631 handling) before verifying the correctness of signaling messages. 633 Furthermore, causing memory allocation and computational efforts 634 might allow an adversary to do harm to NSIS entities. If a 635 signaling message contains, for example, a digital signature then 636 some additional processing is required for the cryptographic 637 verification. An adversary can easily create a random bit 638 sequence instead of a digital signature to force an NSIS node into 639 heavy computation. 641 Idempotent signaling messages are particularly vulnerable to this 642 type of attack. Idempotent refers to messages which contain the 643 same amount of information as the original message. An example 644 would be a refresh message that is equivalent to a create message. 645 This property allows a refresh message to create state along a new 646 path, where no previous state is available. For this to work, 647 specific classes of cryptographic mechanisms supporting this 648 behavior are needed. An example is a scheme based on digital 649 signatures, which, however, should be used with care due to 650 possible denial of service attacks. 652 Problems with the usage of public key based cryptosystems in 653 protocols are described in [AN97] and in [ALN00]. 655 In addition to the threat scenario described above, an incoming 656 signaling message might trigger communication with third-party 657 nodes such as policy servers, LDAP servers or AAA servers. If an 658 adversary is able to transmit a large number of signaling messages 659 (for example, with QoS reservation requests) with invalid 660 credentials, then the verifying node may not be able to process 661 other reservation messages from legitimate users. 663 4.3 Eavesdropping and Traffic Analysis 665 This section covers threats whereby an adversary is able to eavesdrop 666 on signaling messages. The signaling packets collected may allow 667 traffic analysis or be used later to mount replay attacks, as 668 described in Section 3.2. The eavesdropper might learn QoS 669 parameters, communication patterns, policy rules for firewall 670 traversal, policy information, application identifiers, user 671 identities, NAT bindings, authorization objects, network 672 configuration and performance information, and more. 674 An adversary's capability to eavesdrop on signaling messages might 675 violate a user's preference for privacy, particularly if unprotected 676 authentication or authorization information (including policies and 677 profile information) is exchanged. 679 Because the NSIS protocol signals messages through a number of nodes, 680 it is possible to differentiate between nodes actively participating 681 in the NSIS protocol and others that do not actively participate in 682 the NSIS protocol. For certain objects or messages it might be 683 desirable to permit actively participating intermediate NSIS nodes to 684 eavesdrop. On the other hand, it might be desirable that only the 685 intended end points (NSIS Initiator and NSIS Responder) are able to 686 read certain other objects. 688 4.4 Identity Spoofing 690 Identity spoofing relevant for NSIS occurs in three forms: first, 691 identity spoofing can happen during the establishment of a security 692 association based on a weak authentication mechanism. Second, an 693 adversary can modify the flow identifier carried within a signaling 694 message and third, it can spoof data traffic. 696 In the first case, Eve, acting as an adversary, may claim to be the 697 registered user Alice by spoofing Alice's identity. Eve thereby 698 causes the network to charge Alice for the network resources 699 consumed. This type of attack is possible if authentication is based 700 on a simple username identifier (i.e., in absence of cryptographic 701 authentication), or if authentication is provided for hosts, and 702 multiple users have access to a single host. This attack could also 703 be classified as theft of service. 705 In the second case, an adversary may be able to exploit the 706 established flow identifiers (required for QoS and NAT/FW NSLP). 707 These identifiers are, among others, IP addresses, transport protocol 708 type (UDP, TCP), port numbers, and flow labels (see [RFC1809] and 709 [I-D.ietf-ipv6-flow-label]). Modification of these flow identifiers 710 allows adversaries to exploit or to render ineffective quality of 711 service reservations or policy rules at middleboxes. An adversary 712 could mount an attack by modifying the flow identifier of a signaling 713 message. 715 In the third case, an adversary may spoof data traffic. NSIS 716 signaling messages contain some sort of flow identifier, which is 717 associated with a specified behavior (e.g., a particular flow 718 experiences QoS treatment or allows packets to traverse a firewall). 719 An adversary might, therefore, use IP spoofing and inject data 720 packets to benefit from previously installed flow identifiers. 722 We will provide an example of the latter threat. After NSIS nodes 723 along the path between the NSIS initiator and the NSIS receiver 724 processes a properly protected reservation request, transmitted by 725 the legitimate user Alice, a QoS reservation is installed at the 726 corresponding NSIS nodes (for example, the edge router). The flow 727 identifier is used for flow identification and allows data traffic 728 originated from a given source to be assigned to this QoS 729 reservation. The adversary Eve now spoofs the IP address of Alice. 730 In addition, Alice's host may be crashed by the adversary with a 731 denial of service attack or may lose connectivity, for example, 732 because of mobility. If Eve is able to perform address spoofing then 733 she is able to receive and transmit data (for example RTP data 734 traffic) that receives preferential QoS treatment based on the 735 previous reservation. Depending on the installed flow identifier 736 granularity, Eve might have more possibilities to exploit the QoS 737 reservation or a pin-holed firewall. Assuming the soft state 738 paradigm, whereby periodic refresh messages are required, the absence 739 of Alice will not be detected until a refresh message is required and 740 forces Eve to respond with a protected signaling message. Again, 741 this attack is applicable not just to QoS traffic and the same attack 742 is also applicable to a Firewall control protocol, with a different 743 consequence. 745 The ability for an adversary to inject data traffic that matches a 746 certain flow identifier established by a legitimate user and to get 747 some benefit from injecting that traffic often requires the ability 748 also to receive the data traffic or to have one's correspondent 749 receive it. For example, an adversary in an unmanaged network 750 observes a NAT/Firewall signaling message towards a corporate 751 network. After the signaling message exchange was successful user 752 Alice is allowed to traverse the company firewall based on the 753 establish packet filter to contact her internal mail server. Now, 754 adversary Eve, which was monitoring the signaling exchange is able to 755 build a data packet towards this mail server which will pass the 756 company firewall. The packet will hit the mail server and cause some 757 actions and the mail server will reply with some response messages. 758 Depending on the exact location of the adversary and the degree of 759 routing asymmetry the adversary might even see the response messages. 760 Note that for this attack to work Alice does not need to participate 761 in the exchange of signaling messages. 763 If we imagine using attributes of a flow identifier that is not 764 related to source and destination addresses. As an example, we could 765 think of a flow identifier where only the 21-bit Flow ID is used 766 (without source and destination IP address). Identity spoofing and 767 injecting traffic is much easier since a packet only needs to be 768 marked and an adversary can use a nearly arbitrary endpoint 769 identifier to achieve the desired result. Obviously, though, the 770 endpoint identifiers are not irrelevant, because the messages have to 771 hit some nodes in the network where NSIS signaling messages installed 772 state (e.g., in the above example they would have to hit the same 773 firewall.) 775 Data traffic marking based on DiffServ is such an example. Whenever 776 an ingress router uses only marked incoming data traffic for 777 admission control procedures, then various attacks are possible. 778 These problems have been known in the DiffServ community for a long 779 time and have been documented in various DiffServ-related documents. 780 The IPsec protection of DiffServ Code Points is described in Section 781 6.2 of [RFC2745]. Related security issues (for example denial of 782 service attacks) are described in Section 6.1 of the same document. 784 4.5 Unprotected Authorization Information 786 Authorization is an important criterion for providing resources such 787 as QoS reservations, NAT bindings, and pinholes through firewalls. 788 Authorization information might be delivered to the NSIS 789 participating entities in a number of ways. 791 Typically the authenticated identity is used to assist during the 792 authorization procedure as, e.g., described in [RFC3182]. Depending 793 on the chosen authentication protocol, certain threats may exist. 794 Section 3 discusses a number of issues related to this approach when 795 the authentication and key exchange protocol is used to establish 796 session keys for signaling message protection. 798 Another approach is to use some sort of authorization token. The 799 functionality and structure of such an authorization token for RSVP 800 is described in [RFC3520] and [RFC3521]. 802 Achieving secure interaction between different protocols based on 803 authorization tokens, however, requires some care. By using such an 804 authorization token it is possible to link state information between 805 different protocols. Returning an unprotected authorization token to 806 the end host might allow an adversary (for example an eavesdropper) 807 to steal resources. An adversary might also use the token to monitor 808 communication patterns. Finally, an untrustworthy end host might 809 also modify the token content. 811 The Session/Reservation Ownership problem can also be regarded as an 812 authorization problem. Details are described in Section 4.10. In 813 enterprise networks, authorization is often coupled with membership 814 in a particular class of users or groups. This type of information 815 either can be delivered as part of the authentication and key 816 agreement procedure or has to be retrieved via separate protocols 817 from other entities. If an adversary manages to modify information 818 relevant for determining authorization or the outcome of the 819 authorization process itself, then theft of service might be 820 possible. 822 4.6 Missing Non-Repudiation 824 Signaling for QoS often involves three parties: the user, a network 825 that offer QoS reservations (referred as service provider) and a 826 third party which guarantees that the party making the reservation 827 actually receives a financial compensation (referred as trusted third 828 party). 830 Repudiation in this context refers to a problem where either the user 831 or the service provider later deny about the existence or some 832 parameters (e.g., volume or price) of a QoS reservation towards the 833 trusted third party. Problems stemming from a lack of 834 non-repudiation appear in two forms: 836 Service providers point-of-view: 837 A user may deny having issued a reservation request for which it 838 was charged. The service provider may then want to be able to 839 prove that a particular user issued the reservation request in 840 question. 842 Users point-of-view: 843 A service provider may claim to have received a number of 844 reservation requests from a particular user. The user in question 845 may want to show that such a reservation requests have never been 846 issued and may want to see correct service usage records for a 847 given set of QoS parameters. 849 In today's networks, non-repudiation is not provided. As such, it 850 might be difficult to introduce with NSIS signaling. The user has to 851 trust the network operator to meter the traffic correctly, collect 852 and merge accounting data, and ensure that no unforeseen problems 853 occur. If a signaling protocol with the non-repudiation property is 854 desired for establishing QoS reservations then it certainly impacts 855 the protocol design. 857 Non-repudiation functionality additional places requirements on the 858 security mechanisms. Hence, a solution would normally increase the 859 overhead of a security solution. Threats related to missing 860 non-repudiation are only considered relevant in certain specific 861 scenarios and for specific NSLPs. 863 4.7 Malicious NSIS Entity 865 Network elements within a domain (intra-domain) experience a 866 different trust relationship with regard to the security protection 867 of signaling messages compared with edge NSIS entities. It is 868 assumed that edge NSIS entities are responsible for performing 869 cryptographic processing (authentication, integrity and replay 870 protection, authorization, and accounting) for signaling messages 871 arriving from the outside. This prevents unprotected signaling 872 messages from appearing within the internal network. If, however, an 873 adversary manages to take over an edge router, then the security of 874 the entire network is compromised. An adversary is then able to 875 launch a number of attacks including denial of service; integrity 876 violations; replay, reordering of objects and messages, bundling of 877 messages, and deletion of data packets; and various others. A rogue 878 firewall can harm other firewalls by modifying policy rules. The 879 chain-of-trust principle applied in peer-to-peer security protection 880 cannot protect against a malicious NSIS node. An adversary with 881 access to a NSIS router is also able to get access to security 882 associations and transmit secured signaling messages. Note that even 883 non-peer-to-peer security protection might not be able to prevent 884 this problem fully. Because an NSIS node might issue signaling 885 messages on behalf of someone else (by acting as a proxy), additional 886 problems need to be considered. 888 An NSIS-aware edge router is a critical component that requires 889 strong security protection. A strong security policy applied at the 890 edge does not imply that other routers within an intra-domain network 891 do not need to verify signaling messages cryptographically. If the 892 chain-of-trust principle is deployed, then the security protection of 893 the entire path (in this case within the network of a single 894 administrative domain) is as strong as the weakest link. In the case 895 under consideration, the edge router is the most critical component 896 of this network, and it may also act as a security gateway or 897 firewall for incoming and outgoing traffic. For outgoing traffic 898 this device has to implement the security policy of the local domain 899 and apply the appropriate security protection. 901 For an adversary to mount this attack, either an existing NSIS-aware 902 node along the path has to be attacked successfully, or an adversary 903 must succeed in convincing another NSIS node to make it the next NSIS 904 peer (man-in-the-middle attack). 906 4.8 Denial of Service Attacks 908 A number of denial of service (DoS) attacks can cause NSIS nodes to 909 malfunction. Other attacks that could lead to DoS, such as 910 man-in-the-middle attacks, replay attacks, injection or modification 911 of signaling messages, etc., are mentioned throughout this document. 913 Path Finding: 915 Some signaling protocols establish state (e.g., routing state) and 916 perform some actions (e.g., querying resources) at a number of 917 NSIS nodes without requiring authorization (or even proper 918 authentication) based on a single message (e.g., PATH message in 919 RSVP). 921 An adversary can utilize this fact to transmit a large number of 922 signaling messages to allocate state at nodes along the path and 923 to cause resource consumption. 925 An NSIS responder might not be able to determine the NSIS 926 initiator and might even tend to respond to such a signaling 927 message with a corresponding reservation message. 929 Discovery Phase: 931 Conveying signaling information to a large number of entities 932 along a data path requires some sort of discovery. This discovery 933 process is vulnerable to a number of attacks, because it is 934 difficult to secure. An adversary can use the discovery 935 mechanisms to convince one entity to signal information to another 936 entity not along the data path or to cause the discovery process 937 to fail. In the first case, the signaling protocol could appear 938 to continue correctly, except that policy rules are installed at 939 the incorrect firewalls or QoS resource reservations take place at 940 the wrong entities. For an end host, this means that the protocol 941 failed for unknown reasons. 943 Faked Error or Response Messages: 945 An adversary may be able to inject false error or response 946 messages as part of a DoS attack. This could be either at the 947 signaling message protocol layer (NTLP), at the layer of each 948 client layer protocol (e.g., QoS NSLP or NAT/Firewall NSLP), or at 949 the transport protocol layer. An adversary might cause unexpected 950 protocol behavior or might succeed with a DoS attack. The 951 discovery protocol, especially, exhibits vulnerabilities with 952 regard to this threat scenario (see the above discussion on 953 discovery). In the case in which no separate discovery protocol 954 is used and signaling messages are addressed to end hosts only 955 (with a Router Alert Option to intercept message as NSIS aware 956 nodes), an error message might be used to indicate a path change. 957 Such a design combines a discovery protocol together with a 958 signaling message exchange protocol. 960 4.9 Disclosing the Network Topology 962 In some organizations or enterprises there is a desire not to reveal 963 internal network structure (or other related information) outside of 964 a closed community. An adversary might be able to use NSIS messages 965 for network mapping (e.g., discovering which nodes exist, which use 966 NSIS, what version, what resources are allocated, what capabilities 967 nodes along a path have, etc.). Discovery messages, traceroute, 968 diagnostic messages (see [RFC2745] for a description of diagnostic 969 message functionality for RSVP), and query messages, in addition to 970 record route and route objects, provide potential assistance to an 971 adversary. Hence, the requirement of not disclosing a network 972 topology might conflict with other requirements to provide means for 973 automatically discovering NSIS-aware nodes or to provide diagnostic 974 facilities (used for network monitoring and administration). 976 4.10 Unprotected Session or Reservation Ownership 978 Figure 4 shows an NSIS Initiator that has established state 979 information at NSIS nodes along a path as part of the signaling 980 procedure. As a result, Access Router 1, Router 3, and Router 4 (and 981 other nodes) have stored session state information including the 982 Session Identifier SID-x. 984 Session ID(SID-x) 985 +--------+ 986 +-----------------+ Router +------------> 987 Session ID(SID-x)| | 4 | 988 +---+----+ +--------+ 989 | Router | 990 +------+ 3 +******* 991 | +---+----+ * 992 | * 993 | Session ID(SID-x) * Session ID(SID-x) 994 +---+----+ +---+----+ 995 | Access | | Access | 996 | Router | | Router | 997 | 1 | | 2 | 998 +---+----+ +---+----+ 999 | * 1000 | Session ID(SID-x) * Session ID(SID-x) 1001 +----+------+ +----+------+ 1002 | NSIS | | Adversary | 1003 | Initiator | | | 1004 +-----------+ +-----------+ 1006 Figure 4: Session or Reservation Ownership 1008 The Session Identifier is included in signaling messages to reference 1009 to the established state. 1011 If an adversary were able to obtain the Session Identifier, for 1012 example by eavesdropping on signaling messages, it would be able to 1013 add the same Session Identifier SID-x to a new signaling message. 1014 When the new signaling message hits Router 3 (as shown in Figure 3), 1015 existing state information can be modified. The adversary can then 1016 modify or delete the established reservation and cause unexpected 1017 behavior for the legitimate user. 1019 The source of the problem is that Router 3 (a cross-over router) is 1020 unable to decide whether the new signaling message was initiated from 1021 the owner of the session or reservation. 1023 In addition, nodes other than the initial signaling message 1024 originator are allowed to signal information during the lifetime of 1025 an established session. As part of the protocol, any NSIS-aware node 1026 along the path (and the path might change over time) could initiate a 1027 signaling message exchange. It might, for example, be necessary to 1028 provide mobility support or to trigger a local repair procedure. If 1029 only the initial signaling message originator were allowed to trigger 1030 signaling message exchanges, some protocol behavior would not be 1031 possible. 1033 If this threat scenario is not addressed, an adversary can launch 1034 DoS, theft of service, and various other attacks. 1036 4.11 Attacks against the NTLP 1038 In [I-D.braden-2level-signal-arch] a two-level architecture is 1039 proposed, which suggests splitting an NSIS protocol into layers: a 1040 signaling message transport-specific layer and an 1041 application-specific layer. This is further developed in the NSIS 1042 Framework [I-D.ietf-nsis-fw]. Most of the threats described in this 1043 threat analysis are applicable to the NSLP application-specific part 1044 (e.g., QoS NSLP). There are, however, some threats that are 1045 applicable to the NTLP. 1047 Network and transport layer protocols lacking protection mechanisms 1048 are vulnerable to certain attacks such as header manipulation, DoS, 1049 spoofing of identities, session hijacking, unexpected aborts, etc. 1050 Malicious nodes can attack the congestion control mechanism to force 1051 NSIS nodes into a congestion avoidance state. 1053 Threats which address parts of the NTLP which are not related to 1054 attacks against the use of transport layer protocols are covered in 1055 various sections throughout this document, such as in Section 4.2. 1057 In the case in which existing transport layer protocols are used for 1058 exchanging NSIS signaling messages, security vulnerabilities known 1059 for these protocols need to be considered. A detailed threat 1060 description of these protocols is outside the scope of this document. 1062 5. Security Considerations 1064 This entire memo discusses security issues relevant for NSIS protocol 1065 design. It begins by identifying the components of a network running 1066 NSIS (Initiator, Responder, and different Administrative Domains 1067 between them). It then considers five cases in which communications 1068 take place between these components, and it examines the trust 1069 relationships presumed to exist in each case: First-Peer 1070 Communications, End-to-Middle Communications, Intra-Domain 1071 Communications, Inter-Domain Communications, and End-to-End 1072 Communications. This analysis helps determine the security needs and 1073 the relative seriousness of different threats in the different cases. 1075 The document points out the need for different protocol security 1076 measures: authentication, key exchange, message integrity, replay 1077 protection, confidentiality, authorization, and some precautions 1078 against denial of service. The threats are subdivided into generic 1079 ones (e.g., man-in-the-middle attacks, replay attacks, tampering and 1080 forgery, and attacks on security negotiation protocols) and 11 threat 1081 scenarios particularly applicable to the NSIS protocol. Denial of 1082 service, for example, is covered in the NSIS-specific section, not 1083 because it cannot be carried out against other protocols, but because 1084 the methods used to carry out denial of service attacks tend to be 1085 protocol specific. Numerous illustrative examples provide insight 1086 into what can happen if these threats are not mitigated. 1088 This document points out repeatedly that not all of the threats are 1089 equally serious in every context. It does attempt to identify the 1090 scenarios in which security failures may have the highest impact. 1091 However, it is difficult for the protocol designer to foresee all the 1092 ways in which NSIS protocols will be used or to anticipate the 1093 security concerns of a wide variety of likely users. Therefore, the 1094 protocol designer needs to offer a full range of security 1095 capabilities and ways for users to negotiate and select what they 1096 need, on a case by case basis. To counter these threats, security 1097 requirements have been listed in [RFC3726]. 1099 6. Contributors 1101 We especially thank Richard Graveman, who provided text for the 1102 security considerations section, besides a detailed review of the 1103 document. 1105 7. Acknowledgments 1107 We would like to thank (in alphabetical order) Marcus Brunner, Jorge 1108 Cuellar, Mehmet Ersue, Xiaoming Fu, and Robert Hancock for their 1109 comments on an initial version of this draft. Jorge and Robert gave 1110 us an extensive list of comments and provided information on 1111 additional threats. 1113 Jukka Manner, Martin Buechli, Roland Bless, Marcus Brunner, Michael 1114 Thomas, Cedric Aoun, John Loughney, Rene Soltwisch, Cornelia Kappler, 1115 Ted Wiederhold, Vishal Sankhla, Mohan Parthasarathy and Andrew 1116 McDonald provided comments on more recent versions of this draft. 1117 Their input helped improve the content of this document. Roland 1118 Bless, Michael Thomas, Joachim Kross and Cornelia Kappler, in 1119 particular, provided good proposals for regrouping and restructuring 1120 the material. 1122 A final review was given by Michael Richardson. We thank him for his 1123 detailed comments. 1125 8. References 1127 8.1 Normative References 1129 [I-D.ietf-nsis-fw] 1130 Hancock, R., "Next Steps in Signaling: Framework", 1131 draft-ietf-nsis-fw-06 (work in progress), July 2004. 1133 [RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 1134 3726, April 2004. 1136 8.2 Informative References 1138 [ALN00] Aura, T., Leiwo, J. and P. Nikander, "Towards Network 1139 Denial of Service Resistant Protocols, In Proceedings of 1140 the 15th International Information Security Conference 1141 (IFIP/SEC 2000), Beijing, China", August 2000, . 1143 [AN97] Aura, T. and P. Nikander, "Stateless Connections", In 1144 Proceedings of the International Conference on Information 1145 and Communications Security (ICICS'97), Lecture Notes in 1146 Computer Science 1334, Springer", 1997, . 1148 [I-D.braden-2level-signal-arch] 1149 Braden, R. and B. Lindell, "A Two-Level Architecture for 1150 Internet Signaling", draft-braden-2level-signal-arch-01 1151 (work in progress), November 2002. 1153 [I-D.ietf-ipv6-flow-label] 1154 Rajahalme, J., Conta, A., Carpenter, B. and S. Deering, 1155 "IPv6 Flow Label Specification", 1156 draft-ietf-ipv6-flow-label-09 (work in progress), December 1157 2003. 1159 [I-D.ietf-nsis-nslp-natfw] 1160 Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer 1161 Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-03 (work in 1162 progress), July 2004. 1164 [I-D.ietf-nsis-ntlp] 1165 Schulzrinne, H., "GIMPS: General Internet Messaging 1166 Protocol for Signaling", draft-ietf-nsis-ntlp-03 (work in 1167 progress), July 2004. 1169 [I-D.ietf-nsis-qos-nslp] 1170 Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for 1171 Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-04 1172 (work in progress), July 2004. 1174 [I-D.ietf-nsis-rsvp-sec-properties] 1175 Tschofenig, H., "RSVP Security Properties", 1176 draft-ietf-nsis-rsvp-sec-properties-05 (work in progress), 1177 September 2004. 1179 [I-D.ietf-nsis-signalling-analysis] 1180 Manner, J., "Analysis of Existing Quality of Service 1181 Signaling Protocols", 1182 draft-ietf-nsis-signalling-analysis-04 (work in progress), 1183 May 2004. 1185 [RFC1809] Partridge, C., "Using the Flow Label Field in IPv6", RFC 1186 1809, June 1995. 1188 [RFC2745] Terzis, A., Braden, B., Vincent, S. and L. Zhang, "RSVP 1189 Diagnostic Messages", RFC 2745, January 2000. 1191 [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 1192 Herzog, S. and R. Hess, "Identity Representation for 1193 RSVP", RFC 3182, October 2001. 1195 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1196 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 1197 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 1199 [RFC3520] Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session 1200 Authorization Policy Element", RFC 3520, April 2003. 1202 [RFC3521] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session 1203 Set-up with Media Authorization", RFC 3521, April 2003. 1205 [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 1206 Discovery (ND) Trust Models and Threats", RFC 3756, May 1207 2004. 1209 Authors' Addresses 1211 Hannes Tschofenig 1212 Siemens 1213 Otto-Hahn-Ring 6 1214 Munich, Bayern 81739 1215 Germany 1217 EMail: Hannes.Tschofenig@siemens.com 1218 Dirk Kroeselberg 1219 Siemens 1220 Otto-Hahn-Ring 6 1221 Munich, Bayern 81739 1222 Germany 1224 EMail: Dirk.Kroeselberg@siemens.com 1226 Intellectual Property Statement 1228 The IETF takes no position regarding the validity or scope of any 1229 Intellectual Property Rights or other rights that might be claimed to 1230 pertain to the implementation or use of the technology described in 1231 this document or the extent to which any license under such rights 1232 might or might not be available; nor does it represent that it has 1233 made any independent effort to identify any such rights. Information 1234 on the procedures with respect to rights in RFC documents can be 1235 found in BCP 78 and BCP 79. 1237 Copies of IPR disclosures made to the IETF Secretariat and any 1238 assurances of licenses to be made available, or the result of an 1239 attempt made to obtain a general license or permission for the use of 1240 such proprietary rights by implementers or users of this 1241 specification can be obtained from the IETF on-line IPR repository at 1242 http://www.ietf.org/ipr. 1244 The IETF invites any interested party to bring to its attention any 1245 copyrights, patents or patent applications, or other proprietary 1246 rights that may cover technology that may be required to implement 1247 this standard. Please address the information to the IETF at 1248 ietf-ipr@ietf.org. 1250 Disclaimer of Validity 1252 This document and the information contained herein are provided on an 1253 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1254 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1255 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1256 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1257 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1258 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1260 Copyright Statement 1262 Copyright (C) The Internet Society (2004). This document is subject 1263 to the rights, licenses and restrictions contained in BCP 78, and 1264 except as set forth therein, the authors retain all their rights. 1266 Acknowledgment 1268 Funding for the RFC Editor function is currently provided by the 1269 Internet Society.