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