idnits 2.17.1 draft-tschofenig-nsis-threats-01.txt: -(194): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(292): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(318): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(370): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(377): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(552): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(555): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-tschofenig-nsis-threats-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-tschofenig-nsis-threats-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-tschofenig-nsis-threats-', but the file name used is 'draft-tschofenig-nsis-threats-01' == There are 12 instances of lines with non-ascii characters in the document. == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 2002) is 7957 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 (-09) exists of draft-ietf-nsis-req-02 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-req (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 1809 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 7 errors (**), 1 flaw (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS Working Group 3 Internet Draft Hannes Tschofenig 4 Document: draft-tschofenig-nsis-threats- Siemens AG 5 01.txt 6 Expires: December 2002 July 2002 8 NSIS Threats 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 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 Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference 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 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 As the work in the NSIS working has begun to describe requirements 34 and the framework people started thinking about possible security 35 implication. This document should provide a starting point for the 36 discussion at the NSIS working group mailing list regarding the 37 security issues that have to be addressed by a protocol or within 38 the framework. This document does not describe vulnerabilities of a 39 particular protocol or threats of published NSIS framework 40 proposals. This memo is furthermore meant to create awareness for 41 security issues within the NSIS group. Security requirements related 42 to the threat scenarios are described in [1]. 44 1 Introduction 46 It is often argued that QoS signaling protocols are similar to other 47 signaling protocols and one might re-use their security mechanisms 48 for avoiding reengineering overhead. This is true up to some point: 49 A QoS signaling protocol might borrow many security mechanisms from 50 other protocols but different trust assumptions, and different 51 protocol processing may demand different solutions or adaptations. 52 This document tries to show threats that need to be addressed by the 53 designers of a QoS signaling protocol. Although the base protocol 54 might be sure, some extensions may cause problems when used in a 55 particular environment. We think that it is necessary to investigate 56 the context in which a QoS protocol is integrated and in which 57 sequence protocols are executed (when combined together with other 58 protocols). A particular focus of QoS signaling protocols should be 59 given to the interaction with accounting and charging solutions: 60 Without an appropriate integration of QoS and accounting protocols 61 there is no good incentive for network operators to deploy them. The 62 interaction between the protocols is subject of a framework. Some of 63 these issues are therefore found in [5]. 65 Independent of the threat scenarios described in Section 3 we 66 identify the following structural pieces, which require different 67 security protection because of different trust relationships. The 68 sub-parts are: access network part, intra and inter-domain part, and 69 finally end-to-end communication between the two signaling end- 70 points. These parts are briefly described. The threat scenarios in 71 Section 3 can be assigned to the individual parts. 73 a) Access Network 75 This section addresses threats that arise when the QoS Initiator 76 (QI) is attached to access network and transmits and receives QoS 77 signaling messages. In many mobility environments it is difficult to 78 assume the existence of a pre-established trust relationship between 79 a user and the access network. 81 Threat scenarios dealing with initial QoS security association 82 setup, replay attacks, lack of confidentiality, denial of service, 83 integrity violation, identity spoofing and fraud are applicable. 85 From a security point of view this part of the network causes the 86 most problems. 88 b) Intra-Domain 90 After receiving a QoS signaling message and verifying the request 91 somewhere in the access network the signaling messages traverse the 92 network within the same administrative domain. Since the request has 93 already been authenticated and authorized threats might likely be 94 different compared to those described in the previous section. To 95 differentiate the end-node-to-access network interface with the 96 intra-domain communication (i.e. communication internally within one 97 administrative domain) we assume that no user hosts are attached to 98 the core-network. (That is: the interface between any host and the 99 first router is part of the access network). We furthermore assume 100 that nodes within one administrative domain have a stronger trust 101 relationship between each other. 103 c) Inter-Domain 105 The security protection between the borders of different 106 administrative domains largely depends on how accounting is done. If 107 one domain transmits forged QoS reservations (for example stating a 108 higher QoS reservation than a aggregated number of user did) to next 109 domain then it is likely that the originating network domain has 110 also has to pay for the reservation. Hence in this case, there is no 111 real benefit for the first network domain to forge a QoS 112 reservation. But if an end-node is directly charged by intermediate 113 domains then this kind of attack may be reasonable. Security 114 protection of messages transmitted between different administrative 115 domains is still necessary to tackle attacks like spoofing, 116 integrity violation, denial of service etc. The lower number of 117 networks and higher trust relationship (compared in the access 118 network case) usually causes fewer problems for the key management. 120 d) End-to-End 122 In our opinion end-to-end security for QoS signaling messages (in 123 addition to hop-by-hop security) is rarely required if we assume 124 that end-to-end issues like charging and the selection which user 125 has to pay for a reservation is already securely negotiated by 126 preceding upper layer protocols (for example SIP). Information 127 carried within a QoS signaling protocol for the purpose of charging 128 is therefore assumed opaque to the QoS protocol itself and 129 appropriately protected as part of the AAA interaction. For 130 accounting data, the QoS signaling protocol is therefore only used 131 as a transport mechanism. Note however that this assumption strongly 132 depends on the chosen solution of a protocol interaction with AAA, 133 QoS and application layer protocol. It is however possible to select 134 a charging solution that requires end-to-end protection of 135 information delivered within the QoS signaling protocol. The 136 following example requires some sort of end-to-end protection: Alice 137 wants Bob to pay for the QoS reservation (reverse charging). Bob 138 wants to be assured that the QoS signaling message he receives was 139 transmitted by Alice because he is only willing to pay for 140 particular users and not for everyone. Hence Bob requires Alice to 141 protect the reservation request. 143 Regarding end-to-end security one additional issue needs to be 144 clarified. Whenever a signaling protocol travels end-to-end and a 145 node along the path acts on behalf of the other endpoint then 146 further investigation is required how to solve this delegation 147 issue. 149 2 Terminology 151 Some threat scenarios in this document use the entity user instead 152 of the QoS Initiator (as introduced in [1]). This is mainly due to 153 the fact that security protocols allow a differentiation between 154 entities being hosts or users (based on the identities used). Since 155 the QoS Initiator as used in [1] also allows to act on behalf of 156 various entities including a network it is reasonable to distinguish 157 between these identities. 159 We use the term access network for a network to which a mobile node 160 is attached. Other terms often used in this context are foreign or 161 visited network. The missing direct trust relationship between the 162 mobile node and the access network is characteristic for such an 163 interface and complicates authentication and key agreement. Usually 164 AAA protocols (like Radius or Diameter) are used to provide the 165 initial authentication and key establishment. These protocols take 166 advantage of the infrastructure (AAAL, AAAH, Broker, etc.) and trust 167 relationships between the access network and the user's home 168 network. This trust relationship is usually based on some sort of 169 contract and hence it can be seen as symmetric whereas the 170 dynamically established trust relationship between the mobile node 171 and the access network is asymmetric. The mobile node has to trust 172 the access network in many regards. The access network usually does 173 not trust attached end-hosts. 175 The term security association is used to describe established 176 security-relevant data structure between two entities. This data 177 structure consists of keys, algorithms including their parameters, 178 values used for replay protection etc. Using this information two 179 (or more) nodes are able to protect QoS signaling messages. 181 3 Threat Scenarios 183 This section provides threat scenarios that are applicable to the 184 quality of service signaling protocols. 186 3.1 Man-in-the-Middle Attacks 188 This Section describes man-in-the-middle attacks of the following 189 type: During the process of establishing a security association an 190 adversary fools the QI with respect to the entity to which it has to 191 authenticate. The man-in-the-middle adversary is able to modify 192 signaling messages transmitted to the real network requesting 193 different QoS parameters. The QI wrongly believes that it talks to 194 the �real� network whereas it is actually attached to an adversary. 195 Note that a solution for protecting QoS signaling messages does not 196 necessarily need to establish a "long-lasting" security association. 197 Performance reasons may however require to create one. 199 For this attack to be successful, pre-conditions have to hold which 200 are described with the two scenarios below: 202 a) No authentication 204 The first case considers the case that no authentication between the 205 QI and other entity (access network, other networks, a single node) 206 takes places: Without authentication the QI is unable to detect an 207 adversary. It may seem to be strange why someone does not consider 208 to protect QoS signaling messages. However in some cases protection 209 available might be difficult to accomplish in a practical 210 environment either because the other end-point of the communication 211 is unknown, because of a failure in the network configuration or 212 because of misbelieved trust relationships in parts of the network. 213 If one of the communication endpoints is unknown then for some 214 security protocols it is not possible or difficult to select the 215 appropriate key. Regarding an assumed trust relationship, which is 216 not present in some environments, some network administrators refuse 217 to consider security protection of intra-domain signaling messages 218 because of various reasons. Such a configuration sometimes allows a 219 compromised node in the network to interfere the communication of 220 other nodes although it was never intended to actively participate 221 in the signaling. 223 b) Unilateral authentication 225 In case of only unilateral authentication (that is, a missing 226 authentication of the access network to the QI) the QI is not able 227 to discover the man-in-the-middle adversary. In the 228 telecommunication world this type of attack is known as the false 229 base-station attacks (if the unilateral authentication is executed 230 between a user and the access network). 232 The two threats described above are a general problem of network 233 access without appropriate authentication, not only for QoS 234 signaling protocol. Still these issues need to be correctly 235 addressed in a proposed protocol since the impacts may reach beyond 236 the local network. No authentication or unilateral authentication is 237 not only applicable for signaling messages transmitted between a QI 238 and the access network but also between all other nodes. 240 3.2 Missing real-time notifications of QoS reservation costs (cost 241 control) 243 This type of threat is addresses a deployment problem when using QoS 244 signaling in a real-world environment. It is not a particular 245 attack. A large number of service providers with complex roaming 246 agreements create a non-transparent cost-structure. Using AAA 247 protocols in a subscription-based scenario (i.e. user is registered 248 with his home service provider) the user does not learn the identity 249 of the network using a regular message exchange. The user is only 250 authenticated to the home network (and possibly vice versa). The 251 identity of the access network is possibly not revealed. When 252 issuing a reservation request to the network the end-user does not 253 know the cost of such a reservation. Furthermore due to mobility and 254 route changes along the path the costs for a reservation and for 255 transmitted data packets might not be acceptable for the end-user. 256 However a missing protocol between the user and the network and 257 without the possibility for the user to interact with the network to 258 commit the credit withdrawal costs can reach unexpected amounts. 260 When selecting a new point of attachment in case of roaming the end- 261 host does not currently have an option to query the network for a 262 reservation cost. Some proposals which try to merge mobility 263 protocols with QoS signaling probe the access network up to the 264 cross-over router for the possibility making a QoS reservation 265 (without actually making the reservation itself). Without such a 266 mechanism to provide network providers a user cannot take reservation 267 costs into consideration when choosing between different networks. 268 Hence the user is unable to refuse the more expensive service 269 provider. The choice for selecting different providers might be 270 available not only because of overlapping frequency ranges but also 271 because of different access technologies (either using a WLAN card to 272 access the local network or to use UMTS/UTRAN based technology). 274 Although real-time notifications of quality of service reservation 275 costs (cost control) to the user are outside the scope of a quality 276 of service signaling protocol itself some interactions might be 277 required. 279 3.3 Eavesdropping and Traffic Analysis 281 This Section covers two threats: The first scenario is related to 282 privacy concerns whereas the second addresses problems caused by 283 weak authentication mechanisms and the increased risk of 284 eavesdropping on the wireless link in absence of appropriate 285 confidentiality protection. 287 The first threat case covers adversaries that are unable to actively 288 participate in the QoS signaling (passive adversary) but eavesdrop 289 messages. The collected signaling packets may serve for the purpose 290 of traffic analysis or to later mount replay attacks as described in 291 the next Section. By eavesdropping an adversary might violate a 292 user�s privacy preference. Especially QoS signaling messages provide 293 information that may be interesting for an adversary since the 294 messages include user and/or application identities, policy 295 information, information about the desired QoS reservation, etc. The 296 information gathered by an adversary can be to learn usage patterns 297 of users requesting resources and track QoS reservations. 299 An adversary who is able to actively participate in the signaling 300 might be able to use the signaling protocol to discover the topology 301 of a network (e.g. using record route). Additionally it might be 302 possible to obtain diagnostic information usually used for network 303 monitoring and administration. Other options might allow an 304 adversary to route signaling messages specifically along a 305 particular route similar to source routing. 307 The second threat case addresses weak authentication mechanisms 308 whereby information transmitted within the QoS signaling protocol 309 may leak passwords and may allow offline dictionary attacks. This 310 threat is not specific to QoS signaling protocols by may also be 311 applicable and countermeasures must be taken. 313 3.4 Adversary being able to replay signaling messages 315 This threat scenario covers the case where an adversary eavesdrops 316 and collects signaling messages and replays them at a latter point 317 in time (or at a different place, or uses parts of them at a 318 different place or in a different way � e.g. cut and paste attacks). 319 The adversary may use this technique in absence of appropriately 320 protected messages to mount denial of service attacks. Furthermore 321 also theft of service is possible. 323 A more difficult attack that may cause problems even in case of 324 replay protection requires the adversary to crash a QoS aware node 325 (router, broker, etc.) to lose synchronization and to be able to 326 replay old QoS signaling messages. 328 Additionally it should be mentioned that the interaction between 329 different protocols based on authorization tokens requires some 330 care. Using such an authorization token it is possible to link state 331 information between different protocols. When returning an 332 authorization token to the end-host based for example on a SIP 333 message exchange eavesdropping an replay could allow an adversary to 334 steal resources without proper protection of the token delivery and 335 without verification of the hopefully protected content of the 336 token. The functionality and structure of such an authorization 337 token for RSVP is described in [3] and in [4]. 339 3.5 Identity Spoofing 341 An adversary with the capability to spoof the identity may mount the 342 following attacks: 344 Eve, acting as an adversary, claims to be the registered user Alice 345 by spoofing the identity of Alice. Thereby Eve causes the network to 346 charge Alice for the consumed network resources. Using unprotected 347 signaling messages Eve may experience no particular problems in 348 succeeding. This attack can be classified as theft of service. 350 In case that the signaling request is properly protected the 351 adversary has to spent considerable more effort. This threat tries 352 to address possible problems with traffic classification based on 353 some identifiers (IP addresses, transport protocol id, ports, flow 354 label [6] and [7], etc.). Additionally concerns might occur if the 355 end-host performs the traffic marking for example by using a DSCP. 356 When the ingress router uses the DSCP of the incoming data traffic 357 then the situation might be worse since this field is not protected 358 by IPSec AH (and also by IPSec ESP). Issues of DiffServ and IPSec 359 protection are described in Section 6.2 of [RFC2745]. Other security 360 issues related to denial of service attacks are described in Section 361 6.1 of [RFC2745]. 363 The following paragraph describes a possible threat caused by 364 identity spoofing of transmitted data traffic. After the network 365 receives a properly protected reservation request, transmitted by 366 the legitimate user Alice, traffic filters are installed at edge 367 devices. These traffic filters allow data traffic originated from a 368 given address to be assigned to a particular QoS class. The 369 adversary Eve now spoofs the IP address of the Alice (or whatever 370 identifier is used in the flow classification). Additionally Alice�s 371 host may be crashed by the adversary as a result of a denial of 372 service attack or lost connectivity for a variety of other reasons. 373 If both nodes are located at the same link and use the same IP 374 address then obviously the usage of a duplicate IP address will be 375 detected. Assuming that only Eve is available at the link then she 376 is now able to receive and transmit data (for example RTP data 377 traffic), that receives preferential QoS treatment, using Alice�s IP 378 address (or whatever identifier is used in the flow classification). 379 Assuming the soft state paradigm where periodical refresh messages 380 are required the absence of Alice will not be detected until the 381 next signaling message appears and forces Eve to respond with a 382 protected signaling message. Again this issue is not only applicable 383 to QoS traffic but the existence of QoS reservation causes more 384 difficulties since this type of traffic is more expensive. 386 3.6 Adversary being able to inject/modify messages 388 The next type of threat is caused by an integrity violation: An 389 adversary modifies signaling messages (e.g. by acting as a man-in- 390 the-middle) to achieve an unexpected network behavior with the bogus 391 request. Possible actions are reordering, delaying, dropping, 392 injecting and modifying. 394 Using a different identity the adversary may forward a modified a 395 QoS signaling message requesting a large amount of resources (using 396 a different identity). If granted it causes other user's resource- 397 request not to be successful and a different initiator (for example 398 a user) to pay for the QoS reservation. This attack is only 399 successful in absence of signaling message protection. 401 3.7 Missing Non-Repudiation Property 403 Repudiation in this context refers to a problem where one party 404 later denies to have made a reservation. This issue comes in two 405 flavors: 407 From a service provider point-of-view the following threat may be 408 worth an investigation because a user may deny to have issued 409 reservation requests for which it was charged. A service provider 410 may then like to prove that a particular user issued the reservation 411 request. 413 The same threat can be interpreted from the users point-of-view. A 414 service provider claims to have received a number of reservation 415 requests. The user in question thinks that he never issued those 416 requests and wants to have a proof for correct service usage for a 417 given set of QoS parameters. 419 In today�s telecommunication networks non-repudiation is not 420 provided. The user has to trust the network operator to correctly 421 meter the traffic, collect and merge accounting data and that no 422 unforeseen problems occur. If a signaling protocol is used to 423 establish QoS reservations with a higher volume (for example service 424 level agreements) then this issue might have a major impact on the 425 design of a protocol. 427 3.8 Malicious Edge-Router 429 Network elements within a domain (intra-domain) experience a 430 different trust relationship with regard to the security protection 431 of signaling messages compared to edge routers. We assume that edge 432 routers have the responsibility to perform cryptographic processing 433 (authentication, integrity and replay protection, authorization and 434 accounting). If however an adversary manages to take over an edge 435 router then the security of the entire network is affected. An 436 adversary is then able to launch a number of attacks including 437 denial of service, integrity violation, replay attacks etc. Note 438 that this problem is not only restricted to QoS signaling protocols. 439 The chain-of-trust principle applied in the hop-by-hop security 440 protection does not prevent the network from being vulnerable. An 441 adversary with full access to the edge router is then also able to 442 access the keys used to secure messages to other nodes. 444 Thus the edge router is a critical component that requires strong 445 security protection. This does not necessarily imply that all 446 routers within the core network do not need to cryptographically 447 verify signaling messages and that these routers cannot cause 448 security problems when acting maliciously. If the chain-of-trust 449 principle is deployed then the security protection of the path (in 450 this case within the network of a single administrative domain) is 451 as strong as the weakest link. In our case the edge router is the 452 most critical component of this network that may also act as a 453 security gateway/firewall for incoming/outgoing traffic. For 454 outgoing traffic this device has to act according to the security 455 policy of the local domain to apply the appropriate security 456 protection. 458 3.9 Denial of Service in a two phase reservation 460 This threat tries to address potential denial of service attacks 461 when the reservation setup is split into two phases i.e. path and 462 reservation (as for example used in receiver based reservation 463 setup). For this example we assume that the node transmitting the 464 path message is not charged for the path message itself (only for a 465 reservation) and is able to issue a high number of reservation 466 request (possibly in a distributed fashion). The reservations are 467 however never intended to be successful because of various reasons: 468 the destination node cannot be reached; it is not responding node or 469 simply rejects the reservation. An adversary can benefit from the 470 fact that resources are already consumed along the path for various 471 processing tasks including path pinning. 473 3.10 Denial of Service with a bogus signaling request 475 With a resource reservation request received at a network element 476 (for example by the first QoS aware router) processing is required 477 for authentication and authorization. Processing by other nodes 478 including policy servers, LDAP servers, etc. is also possible 479 depending on the network configuration. The verification of the 480 provided credentials requires computations and resources to be 481 allocated for state maintenance, setting timers, additional messages 482 transmitted to other nodes, cryptographic computations). If an 483 adversary is able to transmit a large number of reservation request 484 (flooding) with bogus credentials and assuming that the verification 485 is expensive in terms of resource consumption then the verifying 486 node may not be able to process further reservation messages by 487 legitimate user. 489 3.11 Disclosing the networking structure 491 In some architectural environments there is a desire by the network 492 provider not to reveal the internal network structure (or other 493 related information) to the outside world. An adversary might be 494 able to use NSIS messages for network mapping (e.g. discovering 495 which nodes exist, which use NSIS, what version, what resources are 496 allocated, capabilities of nodes along a paths etc.). This 497 requirement might conflict with a protocol solution that provides a 498 mean to automatically discover NSIS aware nodes and their identity. 500 3.12 Modification of subsequent reservation request 502 An adversary might be able to modify an existing reservation which 503 had already been established within the network as a result of a 504 previous QoS signaling message. This means that a QoS signaling 505 message that modifies established state must be subject to security 506 protection comparable to the original signaling message setting up 507 the reservation. 509 Furthermore it might be necessary to provide assurance for a correct 510 binding to a specific reservation state. Such a property can be 511 designated as reservation ownership. This threat addresses 512 operations for the reservation state established along the path. The 513 reservation state at routers which is created by signaling messages 514 is identified by a Reservation ID. The concept of the Reservation ID 515 is described in [5]. Whenever a signaling message has to refresh, 516 modify or delete a reservation it is necessary to process previously 517 created state. Therefore the newly transmitted signaling messages 518 have to be associated with an existing reservation. Hence there is a 519 requirement that it must not be possible for someone to use an 520 arbitrary Reservation ID to modify state where no ownership exits. 521 Especially in a roaming scenario where a mobile node retransmits 522 signaling messages from a different point of attachment it must be 523 assured that the routers along the path are able to verify whether 524 the entity transmitting the signaling messages is allowed to modify 525 the established state. 527 Potential problems caused by this threat are denial of service, 528 theft of service, service disruption, etc. 530 3.13 Faked Error/Response messages 532 An adversary may be able to use false error/response messages as part 533 of a denial of service attack. This could be either at the 534 reservation level or at the protocol level. 536 4 Security Considerations 538 This entire memo discusses security issues. Some additional threats 539 are applicable for a framework where a NSIS protocol is used. Some 540 of these threats are described in [2]. 542 5 References 544 [1] Brunner, M., "Requirements for QoS Signaling Protocols", draft- 545 ietf-nsis-req-02.txt, Work In Progress, May 2002. 547 [2] Kempf, J., Nordmark, E.: �Threat Analysis for IPv6 Public 548 Multi-Access Links�, , 549 (work in progress), December, 2002. 551 [3] Hamer, L-N., Gage, B., Broda, M., Kosinski, B., Shieh, H.: 552 �Session Authorization for RSVP�, , (work in progress), February, 2002. 555 [4] Hamer, L-N., Gage, B., Shieh, H.: �Framework for session set-up 556 with media authorization�, , 557 (work in progress), February, 2002. 559 [5] Freytsis, I., Hancock, R., Karagiannis, G., Loughney, J., Van 560 den Bosch, S.: �Next Steps in Signaling: A Framework Proposal�, 561 , (work in progress), June, 2002. 562 [RFC2745] 564 [6] Partridge, C.: "Using the Flow Label Field in IPv6", RFC 565 1809, June, 1995. 567 [7] Rajahalme, J., Conta, A., Carpenter, B., Deering, S.: "IPv6 568 Flow Label Specification", , (work 569 in progress), June, 2002. 571 6 Acknowledgments 573 I would like to thank (in alphabetical order) Marcus Brunner, Jorge 574 Cuellar, Mehmet Ersue, Xiaoming Fu and Robert Hancock for their 575 comments to this draft. Jorge and Robert gave me an extensive list 576 of comments and provided information on additional threats. 578 7 Author's Addresses 580 Hannes Tschofenig 581 Siemens AG 582 Otto-Hahn-Ring 6 583 81739 Munich 584 Germany 585 Email: Hannes.Tschofenig@mchp.siemens.de