Internet Engineering Task Force NSIS Internet Draft H.
Tschofenig,Tschofenig D. Kroeselberg Siemens AG draft-ietf-nsis-threats-01.txt 23 January 2003Document: draft-ietf-nsis-threats-02.txt Expires: AugustDecember 2003 June 2003 Security Threats for NSIS STATUS OF THIS MEMO<draft-ietf-nsis-threats-02.txt> Status of this Memo This document is an Internet-Draft and is in full conformance withsubject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress".progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view thehttp://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html.Directories can be accessed at http://www.ietf.org/shadow.html Abstract This threats document provides a detailed analysis of the security threats relevant for the NSIS working group. It motivates and helps to understand various security considerations in the NSIS Requirements, Framework and Protocol proposals. This document does not describe vulnerabilities of specific NSIS protocols. 1 Introduction Section 1.1 introduces the overall processTable of addressing the security work done in theContents 1. Introduction...................................................2 2. Terminology....................................................3 3. Relevant communication models..................................3 3.1 First-Peer Communication...................................5 3.2 End-to-Middle Communication................................6 3.3 Intra-Domain Communication.................................6 3.4 Inter-Domain Communication.................................6 3.5 End-to-End Communication...................................7 3.6 Middle-to-middle Communication.............................8 4. Generic Threats................................................8 4.1 Man-in-the-middle attacks..................................8 4.2 Adversary being able to replay signaling messages.........10 4.3 Adversary being able to inject/modify messages............10 4.4 Security Parameter Exchange/Negotiation...................11 5. Signaling specific Threats....................................11 5.1 Attacks during NSIS working group. Section 1.2 gives a high-level pictureSA Usage..............................11 5.2 Combining Signaling and SA Establishment..................11 5.3 Eavesdropping and Traffic Analysis........................12 5.4 Identity Spoofing.........................................12 5.5 Missing Protection of the different network parts, which are traversed byAuthorization Information...........14 5.6 Missing Non-Repudiation...................................15 5.7 Malicious NSIS signaling. Each part is characterized by a different setEntity.....................................15 5.8 Denial of requirements and different trust relationships. The threats described in Section 2 can be assigned to these individual parts. 1.1 NSISService Attacks.................................16 5.9 Disclosing the network topology...........................17 5.10 Session/Reservation Ownership............................18 5.11 Attacks against the signaling message transport mechanism19 6. Security ProcessConsiderations.......................................19 7. Normative References..........................................19 8. Informative References........................................20 Acknowledgments..................................................20 Author's Addresses...............................................21 Full Copyright Statement.........................................21 1. Introduction Whenever a new protocol has to be developed or existing protocols have to be modified their security threats should be evaluated. The process of securing protocols inis separated into individual steps. To address security in the NSIS working group a number of documentssteps have been produced:taken: +----------------------------------------------+ | NSIS Analysis Activities | | (e.g. RSVP Security Properties) | +----------------------------------------------+ +----------------------------------------------+ | Security Threats for NSIS | | | +----------------------------------------------+ +----------------------------------------------+ | NSIS Requirements | | | +----------------------------------------------+ +----------------------------------------------+ | NSIS Framework | | | +----------------------------------------------+ +----------------------------------------------+ | | | NSIS Protocol Proposals | +----------------------------------------------+ Figure 1: NSIS Security related Documents All the documents depicted in Figure 1 contribute toSteps This document identifies the NSISbasic security approach. The purpose of each of these documents is briefly described belowthreats that need to give the reader insight into the development process. NSIS Analysis Activities: The primary goal ofbe addressed by the NSIS analysis activity is the investigation of existing approaches in the area of quality of servicesignaling protocols. Several ofprotocol design. In addition, although the published approaches directly identify security threats and requirements, whereas other threats and requirements canbase protocol might be derived from the different scenariossecure, some extensions may cause problems when used in which these protocols are used. For instance,  pointsa particular environment. Furthermore it is necessary to investigate the reduced complexity if RSVPcontext in which a signaling protocol is used without multicast support. This modification also results in simplified security requirements. In , security issues in some example configurations are given. In , the security properties of RSVP are described. Furthermore an analysis of the interaction between RSVP and Mobile IP is provided by Michael Thomas in  and an analysis of existing QoS protocols is described in . NSIS Requirements: To address the security threats relevant for NSIS described in this document, security requirements have been specified as part of the NSIS Requirements document . In addition to these requirements  describes basic scenarios where the NSIS signaling protocol might be deployed. NSIS Framework: Signaling information to a number of devices located in different parts in the network with different trust assumptions and possible interactions with a large number of other protocols require some framework thoughts, which is especially true for security. In  a security framework is provided for NSIS. NSIS Protocol: Finally there are documents describing concrete protocol proposals. These proposals either rely on existing security mechanisms or develop their own if the existing mechanisms cannot counter all relevant security threats or if they are inappropriate for other reasons. In practice, a protocol proposal might use established security mechanisms or protocols for basic protection, but is likely to require some additional protection mechanisms, or a combination of both for enhanced security. Note that the process of developing the above-mentioned documents is not linear. Instead it takes various iterations to reach a satisfactory NSIS security solution. Security Threats for NSIS: This document identifies the basic threats that need to be addressed by the NSIS signaling protocol design. In addition, although the base protocol might be secure, some extensions may cause problems when used in a particular environment. Furthermore it is necessary to investigate the context in which a signaling protocol is used andand the architecture where it is integrated. As an example of such interaction accounting and charging are taken into account in this document, since without an appropriate integration of the two it is difficult to deploy any NSIS solution. This interaction is also subject ofto discussion within the NSIS framework and some aspects are discussed in . 1.2 Relevant communication models Independent of the threat scenarios describedframework. 2. Terminology This document uses NSIS terms defined in Section 2 signaling[Bru03]. 3. Relevant communication models Signaling messages traverse different network parts, which demand different security means.protection and raise different security problems. The difference in security protection is mainly caused by the fact that the NSIS signaling messages cross trust boundaries where different trust relationships are prevalent. Often a categorization into first-peer/last-peer, intra-domain and inter-domain communication is applicable (see Figure 2). Depending on the concrete security requirements end-to-end security protection across trust boundaries might be required for certain scenarios but is usually not easily addressable by standard means.The main properties of the listed network parts are briefly described in this section and the threat scenariosthreats of Section 2 are classified accordingly.4 and Section 5 classify them to generic threats and signaling specific threats. Figure 2 depicts a typical end-to-end communication scenario including an access part between the NSIS end entities and the nearest NSIS hops, respectively. This "first-peer communication" commonly comes with specific security requirements,requirements (as described below), especially important for properly addressing security in mobile scenarios. Differences in the trust relationship and the required security for first-peer communication, compared to other parts of the signaling path, might exist. If signaling messages are not exchanged end-to-end and only parts of the signaling path are affected, some threats may not be relevant. To further refine the above differentiation based on network parts that NSIS signaling may traverse, we consider trust relationships between+------------------+ +---------------+ +------------------+ | | | | | | | Administrative | | Intermediate | | Administrative | | Domain A | | Domains | | Domain B | | | | | | | | (Inter-domain Communication) | | +---------+---+---------------+---+---------+ | | (Intra-domain | | | | (Intra-domain | | Communication) | | | | Communication) | | | | | | | | | | | | | | | | | +--------+---------+ +---------------+ +---------+--------+ ^ v | | First Peer Communication Last Peer Communication | | +-----+-----+ +-----+-----+ | NSIS | | NSIS | | Initiator | | Responder | +-----------+ +-----------+ Figure 2: Involved Network Parts To further refine the above differentiation based on network parts that NSIS signaling may traverse, we consider trust relationships between NSIS hops. Additional threats may apply to NSIS communication where one entity involved is an end-entity (initiator or responder) and the other entity is any intermediate hop not being the first peer. This is typically called end-to-middle scenario. The motivation for including this configuration stems for example from the SIP [RFC3261] protocol. Any intermediate SIP proxyhop may request a SIP end entity (UA) to authenticate, countering a number of specific security threats. Such functionality in general seems to be useful for intermediaries at the borders of trust domains that signaling messages need to traverse. Intermediate NSIS hops as well may have to deal with specific security threats that do not (directly) relate to end-entities. Between such intermediate hops, other such NSIS hops will typically be in the signaling path.This scenario is called middle-to-middle. A generictypical example areof middle-to- middle communication is between two NSIS hops at the border of their respective trust domains with some form of trust relation.(i.e. inter-domain communication). NSIS messages between these hopsmay have to traverse one or more intermediateuntrusted hops.hops between these NSIS entities. Figure 3 illustrates these additional scenarios. The first-peer case discussed further above is covered by the peer-to-peer trust relationships between end entity and closest hop, respectively. **************************************** * * +----+-----+ +----------+ +----+-----+ +-----+ NSIS +-------+ NSIS +--------+ NSIS +-----+ | | Node 1 | | Node 2 | | Node 3 | | | +----------+ +----+-----+ +----------+ | | ~ | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | ~ | +--+--+-----+ +---------+-+ | NSIS +//////////////////////////////////////////+ NSIS | | Initiator | | Responder | +-----------+ +-----------+ Legend: -----: Peer-to-Peer Trust Relationship /////: End-to-End Trust Relationship *****: Middle-to-Middle Trust Relationship ~~~~~: End-to-Middle Trust Relationship Figure 3: Trust Relationships 3.1 First-Peer Communication:Communication First peer communication refers to the peer-to-peer interaction between a signaling message originator, the NSIS Initiator (NI), and the first NSIS aware entity along the path. Assumptions about the threats, security requirements and the available trust relationships may be difficult here. To illustrate this, in many mobility environments it is difficult to assume the existence of a pre-established security association directly available for NSIS peers involved in first-peer communication, as these peers cannot be assumed to have any relation between each other in advance. For enterprise networks, in contrast, the situation is different. Usually there is a fairly strong (pre-established)(pre- established) trust relationship between the peers. Enterprise network administrators usually have some degree of freedom to select the appropriate security protection and to enforce it. The choice of selecting a security mechanism is therefore often influenced by the already available infrastructure. Per- sessionPer-session negotiation of security mechanisms is therefore often not required (which, in contrast, is required for the mobility case). For first-peer communication, especially threats related to initial security association setup, replay attacks, lack of confidentiality, denial of service, integrity violation, identity spoofingspoofing, theft of service and fraud are applicable. 3.2 End-to-Middle Communication:Communication End-to-middle interaction in signaling may be required to e.g. grant end-entities access to, or specific services in trust domains different from the one the first peer belongs to. Threats, in addition to these already discussed for first-hop communication, may be untrusted intermediate NSIS hops that maliciously alter NSIS signaling. These threats are still relevant if security mechanisms are in place between the NSIS hops, but terminate at each hop (e.g. IPsec hop-by-hop protection). 3.3 Intra-Domain Communication:Communication After having been verified at the first peer, an NSIS signaling message traverses the network within the same administrative domain the first peer belongs to. Since the request has already been authenticated and authorized threats are different to those described above in a). To differentiate first-peer communication with the intra-domain communication (i.e. communication internally within one administrative domain) we assume that no end hosts have direct access to the internal network nodes, except the first peer. We furthermore assume that NSIS peers within the same administrative domain have at least some sort of trust relationship. 3.4 Inter-Domain Communication:Communication The threat assumptions between the borders of different administrative domains largely depend on accounting procedures (and therefore business relationships) in case of QoS signaling, which is an important example application of NSIS signaling.the authorization procedures. If one domain transmits forgedforges QoS reservations (for example stating a higher QoS reservation than a aggregated number of user did) to the next domainthen the originatingthis domain may also have to pay for the reservation. Hence in this case, there is no real benefit for the first networkthis domain to forge a QoS reservation. If an end host is directly charged by intermediate domains (i.e. by a domain different tofrom the first peer's domain, thenmalicious domain) such an attack may be quite a reasonable threat. However, security protection of messages transmitted between different administrative domains is still necessary to tackle attacks like spoofing, integrity violation, or denial of service between these domains, e.g. to allow for proper accounting. In case of securing signaling messages between adjacent administrative domains, the number of domains is usually rather limited (compared to first-peerfirst- peer communication) which causes fewer problems for the key management. Signaling information other than QoS service parameters such as policy rules in case of middlebox communication demands different assumptions for inter-domain communication. Trust assumptions and business relationships are of particular importance for their communication. If signaling messages are transparentconveyed transparently in the core network (i.e. thethey are not intercepted and processed in the core network) then the signaling message communication effectively takes place between access networks. This might place a burden on the key management infrastructure because of the global PKI requirements. Hence this can be seen as a serious deployment threat since it might be unacceptable for an access network service provider to perform processing (QoS reservations, policy rule installation at firewalls) due totriggered by unprotected incoming signaling messages. 3.5 End-to-End Communication: Providing end-to-end signaling message protection forCommunication NSIS would cause difficulties for authenticationaims to signal information between the initiator and key establishment procedures. It would furthermore limit the flexibility of a signaling protocol in general. Functionality such as terminating at an arbitrary location alongthe path, delegating a signaling message exchange to other nodes, etc. would be difficultresponder. This section refers to achievethe trust relationships required between the end points in a secure fashion. Protecting signaling messages end-to-end (in addition to peer-to-peer security)cases where security protection is in our opinion rarelyrequired. This is based on the observationNote that end-to-end issues like charging and payment selection (i.e. which user hasthis security protection is likely to pay for which part of a QoS reservation) are already securely negotiated by preceding upper layer protocols (for example SIP). Information carried within an NSIS signaling protocolbe required only for the purpose ofcertain objects such as pricing and charging is therefore assumed opaque torelated information. Protecting the entire signaling message is not possible since intermediate NSIS protocol itself. Note that this observation makes some assumptions about the charging modelnodes need to (a) inspect various objects and about(b) need to add, modify or delete objects from the existence of a protocol interaction with AAA, QoS and an application layer protocol. It is however possiblesignaling message. The following example tries to imagineillustrate a charging solution that requirespossible application of end-to-end protection of information deliveredfor objects carried within the NSIS signaling protocol. The following example requires some sort of end-to-end protection: AliceAlice, the data sender, wants BobBob, the data receiver, to pay for a QoS reservation (reverse charging). Bob wants to be assured that the QoS signaling message he receives was indeed transmitted by Alice because he is only willing to pay for particular users and not for everyone. Hence Bob requires Alicewants to protectverify that the reservation request. Regarding end-to-end security one additional issue needs to be addressed - delegation. Whenever a signaling is addressed end- to-endrequest came from Alice (authentication) and an arbitrary node along the path acts as a proxy on behalf ofthat the other endpoint a delegation mechanism is requiredincluded parameters are unmodified. Additionally it might be necessary to providesecure interaction. This obviously leadsa negotiation step and to secure deliver authorization information to additional complexity inthe areainvolved parties. Information which is required to compute an authorization decision (such as prices or QoS objects) also needs proper security protection. Typical threats in such a scenario range from modification of QoS objects or price information (i.e. Bob has to pay more), fraud (i.e. to force Bob always to pay for the reservations) to identity spoofing (i.e. the adversary claims to be Alice). Regarding end-to-end security, as ansecurity one additional setissue needs to be addressed - delegation. Whenever a signaling is addressed end-to-end and an arbitrary node along the path acts as a proxy on behalf of threats becomes relevant. Middle-to-middle:the other endpoint a delegation mechanism is required to provide secure interaction. This might lead to additional complexity. 3.6 Middle-to-middle Communication We do not explicitly consider the middle-to-middle case here, as thisalthough it is important, since it is already covered by either intra- or inter-domain communication depending on the location of the involved entities. 2 Threat Scenarios4. Generic Threats This section provides threat scenarios that are applicable to signaling protocols. Note that some threat scenarios use the term user instead of NSIS Initiator. This is mainly because security protocols allow a differentiation between entities being hosts and users (based on the identities used). 2.1 MITM Attacks4.1 Man-in-the-middle attacks Security protection of protocols is often separated into two steps. The first step provides entity authentication and key establishment whereas the second step provides message protection using the previously established security association. The first step usually tends to be more expensive than the second which is also the main reason for separation. If messages are transmitted very infrequently then these two steps are collapsed into a single and usually rather costly step. One such example is e-mail protection via S/MIME. A goodAn example for an efficienta two-step approach is provided by IPsec .IKE/IPsec. We use this separation to cover the different threats in more detail. The first paragraph describes security threats where two peers do not already share a security association, or do not use security mechanisms at all. The next paragraph describes threats which are applicable when a security association is already established. Finally a denial of service attack is described which is applicable to a signaling message when no separation between SA establishment and signaling protection takes place. Various security threat are caused by a protocol performing dynamic node discovery. These threats include Denial of Service attacks, which are among other threats described in Section 2.9. Note that the threats are largely independently ofParticularly the discovery procedure (path discovery, next peer discovery or topology discovery). 1.is vulnerable against a number of attacks. - Attacks during NSIS SA Establishment During the process of establishing a security association an adversary fools the signaling message initiator with respect to the entity to which it has to authenticate. The man-in-the- middleman-in-the-middle adversary is able to modify signaling messages to mount e.g. DoS attacks. In addition, it may be able to terminate NSIS messages of the Initiator and inject messages to a peer itself, therefore acting as the peer to the initiator and as the initiator to the peer. This results in the initiator wrongly believing that it talks to the "real" network whereas it is actually attached to an adversary. For this attack to be successful, pre-conditions have to hold which are described with the following two cases: - Missing Authentication The first case addresses missing authentication between the neighboring peers: Without authentication a NI, NR or NF is unable to detect an adversary. However in some cases protection available might be difficult to accomplish in a practical environment either because the next peer is unknown, because of misbelieved trust relationships in parts of the network or because of the inability to establish proper security protection (inter-domain signaling messages, dynamic establishment of a security association, etc.). If one of the communication endpoints is unknown then for some security mechanisms it is either not possible or very difficult to apply appropriate security protection. Sometimes network administrators use intra-domainintra- domain signaling messages without proper security. Such a configuration would then allow an adversary on a compromised non-NSIS aware node to interfere with nodes running an NSIS signaling protocol. Note that this type of threat goes beyond a threat caused by malicious NSIS nodes (described in Section 2.8).5.7). - Unilateral Authentication In case of a unilateral authentication the NSIS entity that does not authenticate its peer is unable to discover the man-in-the-middle adversary. Although authentication of signaling messages should take place between each peer participating in the protocol operation special attention is given here to first-peer communication. Unilateral authentication between an end hostshost and the first peer (just authenticating the end host) is still common today, but certainly opens up many possibilities for MITM attackers impersonating either the end host or the (administrative domain represented by the) first peer. The two threats described above are a general problem of network access without appropriate authentication, not only for an NSIS signaling protocol. Obviously there is a strong need to correctly address them in a future NSIS protocol. The signaling protocols addressed by NSIS are different to other protocols where only two entities are involved. Note, that especially first-peer authentication is important, as the impacts of a security breach likely reach beyond the directly involved entities (or even beyond a local network). Finally it should be noted that the signaling protocol should be considered as a peer-to-peer protocol where the roles of initiator and responder can be reversed at any time. This leads to the conclusion that unilateral authentication is not very useful for such a protocol. However there might be a need to have some form of asymmetry in the authentication process whereby one entity uses a different authentication mechanism than the other one. As an example the combination of symmetric and asymmetric cryptography should be mentioned. - Weak Authentication This threat addresses weak authentication mechanisms whereby information transmitted during the NSIS SA establishment process may leak passwords and/or may allow offline dictionary attacks. This threat is not specific to NSIS signaling protocols but may also beapplicable and countermeasures must be taken. 2. Attacks duringto NSIS SA Usage Once afor the process of selecting certain security association is establish (and usedmechanisms. 4.2 Adversary being able to protectreplay signaling messages) basic attacks are prevented. However,messages This threat scenario covers the case where an adversary eavesdrops and collects signaling messages and replays them at a malicious NSIS node is still able to perform various attacks as describedlater point in Section 2.8. Replay attacks, which can betime (or at a problem whendifferent place, or uses parts of them at a NSIS node crashes, restartsdifferent place or in a different way - e.g. cut and performs state re-establishment. Proper re-synchronization capabilitypaste attacks). Without proper replay protection an adversary might mount man-in-the-middle, denial of the security mechanism must therefore address this problem. 3. Combining Signalingservice and SA Establishment This threat covers antheft of service attacks. A more difficult attack which allows anthat may cause problems even in case of replay protection requires the adversary to floodcrash an NSIS aware node with bogusto loose state information (sequence numbers, security associations, etc.) and to be able to replay old signaling messages. This attack addresses re-synchronization deficiencies. 4.3 Adversary being able to inject/modify messages This type of threat addresses integrity violations whereby an adversary modifies signaling messages (e.g. by acting as a man-in- the-middle attacker) to cause a denial of service attack. Whenan unexpected network behavior. Possible actions an adversary might consider for its attack are reordering, delaying, dropping, injecting and modifying. An adversary may inject a signaling message arrives atrequesting a NSIS aware network element some processing is required. If this message contains security objects such as digital signatures and not security association is already availablelarge amount of resources (possibly using a different user identity). Other resource requests could then some processing is required for the cryptographic verification. Since NSIS signaling should not require several roundtrips between two NSIS peersbe rejected. In combination with identity spoofing it is difficult to provide DoS protection mechanisms commonly foundalso possible accomplish fraud. This attack is only successful in authentication and key agreement protocols. Ifabsence of signaling messages furthermore aim to be idempotentmessage protection. Some directly related threats are described in Section 5.7, 5.4 and no security association should be created then some cryptographic mechanisms5.8. 4.4 Security Parameter Exchange/Negotiation Protocols, which should be used with precaution (for example public key cryptography). Additionallyuseful for a variety of scenarios, tend to the threat described above an incoming signaling message might require time consuming processing (computations, state maintenance, timer setting, etc) and communicationhave different security requirements. It is often difficult to meet these (sometimes conflicting requirements) with third-party nodes including policy servers, LDAP servers, etc. Ifa single security mechanism or a fixed security parameter. Hence often a few selected mechanisms/parameters are supported. Therefore some protocol exchange is required to agree on some security mechanisms/parameters. This protocol exchanged can be misused by an adversary is ableto transmitmount a large numberdowngrading attack by selecting weaker mechanisms than desired. Hence without protecting the negotiation process the security of signaling messagean NSIS protocol might be as secure as the weakest mechanism if no configuration parameters (for example with QoS reservation requests) with invalid credentials thena security policy disallowing the verifying node may not be able to process further reservation messages by legitimate users. 2.2 Eavesdropping and Traffic Analysis This threat cases covers adversaries whichweakest mechanism, etc.) are ableused otherwise. 5. Signaling specific Threats 5.1 Attacks during NSIS SA Usage Once a security association is established (and used to eavesdropprotect signaling messages butmessages) basic attacks are unable to actively participate in signaling message exchange (i.e. passive adversary). The collected signaling packets may serve for the purpose of traffic analysis orprevented. However, a malicious NSIS node is still able to later mount replayperform various attacks as described in theSection 2.3. The eavesdropper might learn QoS parameters, communication patterns, policy rules for firewall traversal, policy information, application identifiers, user identities, NAT bindings5.7. Replay attacks, which can be a problem when a NSIS node crashes, restarts and more. 2.3 Adversary being able to replay signaling messagesperforms state re-establishment. Proper re- synchronization capability of the security mechanism must therefore address this problem. 5.2 Combining Signaling and SA Establishment This threat scenariocovers the case wherean attack which allows an adversary eavesdrops and collectsto flood an NSIS node with bogus signaling messages and replays them at a latter point in time (or at a different place, or uses parts of them at a different place or into cause a different way - e.g. cut and paste attacks). Without proper replay protection an adversary might mount man-in-the-middle,denial of service and theft of service attacks. A more difficult attack that may cause problems even in case of replay protection requires the adversary to crash anattack. When a signaling message arrives at a NSIS aware node to loose state information (sequence numbers, security associations, etc.) and to be able to replay old signaling messages. This attack addresses re- synchronization deficiencies. 2.4 Missing Protection of Authorization Information Authorizationnetwork element some processing is an important step for providing resourcesrequired. If this message contains security objects such as QoS reservations, NAT bindingsdigital signatures and pin-holed firewalls. Authorization information might be delivered to the NSIS participating entities in a number of ways. One such approachno security association is to use a successful authorization step done by a different protocol in a later NSIS signaling message by providingalready available then some sort of token. The functionality and structure of such an authorization token for RSVPprocessing is described in  and in . The interactionrequired for the cryptographic verification. Since NSIS signaling should not require several roundtrips between different protocols based on authorization tokens, however, requires some care. Using such an authorization tokentwo NSIS peers it is possibledifficult to link state information between differentprovide DoS protection mechanisms commonly found in authentication and key agreement protocols. Returning an unprotected authorization tokenIf signaling messages furthermore aim to be idempotent and no security association should be created then some cryptographic mechanisms should be used with precaution (for example public key cryptography). Additionally to the end hostthreat described above an incoming signaling message might allowrequire time consuming processing (computations, state maintenance, timer setting, etc) and communication with third-party nodes including policy servers, LDAP servers, etc. If an adversary is able to transmit a large number of signaling messages (for example an eavesdropper)with QoS reservation requests) with invalid credentials then the verifying node may not be able to steal resources. Anprocess further reservation messages by legitimate users. Further threats could be introduced by allowing an adversary might also use the tokento learn communication patters. An untrustworthy end host might also modifygain additional information by injecting error messages or by forcing the token content. Other authorization mechanisms might depend on availabilitycreation of sufficient fundserror messages. 5.3 Eavesdropping and therefore real-time information. DeploymentTraffic Analysis This section covers threats of this kind are described in Section 2.14.whereby an adversary is able to eavesdrop signaling messages. The Session/Reservation Ownership problem can also be consideredcollected signaling packets may serve for the purpose of traffic analysis or to later mount replay attacks as an authorization problem. Details aredescribed in the Section 2.11. In enterprise networks4.2. The eavesdropper might learn QoS parameters, communication patterns, policy rules for firewall traversal, policy information, application identifiers, user identities, NAT bindings, authorization objects and more. Note, that such a threat is also applicable if the messages are integrity protected which is often coupled with membership toconsidered sufficient for signaling protocols. Since the NSIS protocol signals messages through a particular class user of users/groups. This type of information can either be delivered as partnumber of nodes it is possible to differentiate between nodes actively participating in the authenticationNSIS protocol and key agreement procedureothers who do not actively participate in the NSIS protocol. For certain objects or has tomessages it might be retrieved via separate protocols from other entities. If an adversary managesdesirable to modify information relevant for determining authorization or the outcome of the authorization process itself then theft of servicepermit actively participating intermediate NSIS nodes to eavesdrop. As a further extension it might be desired that only the consequence. 2.5intended end points (NSIS initiator and NSIS responder) are able to read certain objects. 5.4 Identity Spoofing Identity spoofing relevant for NSIS appears in two flavors: First, identity spoofing can appear during the establishment of a security association if based on a weak authentication mechanism. Eve, acting as an adversary, claims to be the registered user Alice by spoofing the identity of Alice. Thereby Eve causes the network to charge Alice for the consumed network resources. This type of attack is possible if authentication is done based on a simple username identifier (i.e. in absence of cryptographic authentication) or if authentication is provided for hosts and multiple users have access to a single host. This attack could also be classified as theft of service. Second, anAn adversary is able to perform identity spoofing on transmitted data packets. This type of attack is often labeled as IP spoofing. Since most NSIS signaling messages contain some sort ofexploit the established flow identifier for which a certain behavior is performed (e.g. particular flow experiences QoS treatment or is allowed to bypass a firewall, etc.) an adversary could mount an attack by modifying the flow identifier of a signaling message. The following example tries to show an adversary using identity spoofing of the first category: An adversary is able to exploit the established flow identifiers (requiredidentifiers (required for QoS and Midcom specific signaling protocols). Some identifiers such as IP addresses, transport protocol identifiers, port numbers, flow labels (see [RFC1809] and )[RC+03]) and others are communicated in these protocols. Modification of these flow identifiers causecauses quality of service reservations or policy rules at middleboxes to be either ineffective or beneficialexploidable for adversaries. An adversary could mount an attack by modifying the flow identifier of a signaling message. NSIS signaling messages contain some sort of flow identifier, which is associated with a specified behavior (e.g. a particular flow experiences QoS treatment or allows packets to traverse a firewall, etc.). An adversary might therefore use IP spoofing and inject data packets to benefit from previously installed flow identifiers. The following paragraph describes a possiblethreat caused by identity spoofing of transmitted data traffic. The spoofed identity is thereby the source IP addresses. For this attack to be successful accounting records are collected based on the source IP address and not on a SPI due to IPSec protection. After the network receives a properly protected reservation request, transmitted by the legitimate user Alice, Traffic Selectors are installed at the corresponding devices (for example edge router). These Traffic Selectors are used for flow identification and allow to match data traffic originated from a given source address to be assigned to a particular QoS reservation. The adversary Eve now spoofs the IP address of the Alice. Additionally Alice's host may be crashed by the adversary as a result of a denial of service attack or lost connectivity for example because of mobility reasons. If both nodes are located at the same link and use the same IP address then obviously a duplicate IP address will be detected. Assuming that only Eve is present at the link then she is able to receive and transmit data (for example RTP data traffic), which receives preferential QoS treatment based on the previous reservation. Depending on the installed Traffic Selector granularity Eve might have more possibilities to exploit the QoS reservation or a pin-holed firewall. Assuming the soft state paradigm, where periodical refresh messages are required, the absence of Alice will not be detected until the next signaling message appears and forces Eve to respond with a protected signaling message. Again this issue is not only applicable to QoS traffic but the existence of QoS reservation causes more difficulties since this type of traffic is more expensive. The same procedure is also applicable to a Middlebox communication protocol. The ability for an adversary to inject data traffic which matches a certain Traffic Selectorflow identifier established by a legitimate user often requires the ability to also receive the data traffic. This is, however, only true if the Traffic Selectorflow identifier consists of values which contain addresses used for routing. If we imagine to use attributes for a Traffic Selectorflow identifier where such a property is not required then identity spoofing and injecting traffic is much easier. An adversary can use a nearly arbitrary endpoint identifier to experience the desired result. Obviously the endpoint identifiers are still not irrelevant since the messages have to travel the same path through the network. DiffServ marking of IP packets is such an example and others can be constructed very easily.Data traffic marking based on DiffServ is such an example. Whenever an ingress router uses only marked incoming data traffic for admission control procedures then various attacks are possible. These problems are known in the DiffServ community for a long time and documented in various DiffServ related documents. The IPSec protection of DiffServ Code Points is described in Section 6.2 of .[RFC2745]. Related security issues (for example denial of service attacks) are described in Section 6.1 of the same document. 2.6 Adversary being able to inject/modify messages This type5.5 Missing Protection of threat addresses integrity violations wherebyAuthorization Information Authorization is an adversary modifies signaling messages (e.g. by actingimportant step for providing resources such as QoS reservations, NAT bindings and pin-holed firewalls. Authorization information might be delivered to the NSIS participating entities in a man-in-the-middle attacker)number of ways. Typically the authenticated identity is used to cause an unexpected network behavior. Possible actions an adversary might considerassist during the authorization procedure ass for its attackexample described in [RFC3812]. Depending on the chosen authentication protocol certain attacks are reordering, delaying, dropping, injecting and modifying. An adversary may injectpossible. Section 4 discusses a number of issues related to this approach when the authentication and key exchange protocol is used to establish session keys for signaling message requesting a large amount of resources (possibly using aprotection. Another approach is to use some sort of authorization token. The functionality and structure of such an authorization token for RSVP is described in [RFC3520] and in [RFC3521]. The interaction between different user identity). Other resource requests could then be rejected. In combination with identity spoofingprotocols based on authorization tokens, however, requires some care. Using such an authorization token it is alsopossible accomplish fraud. This attack is only successful in absenceto link state information between different protocols. Returning an unprotected authorization token to the end host might allow an adversary (for example an eavesdropper) to steal resources. An adversary might also use the token to learn communication patterns. An untrustworthy end host might also modify the token content. Other authorization mechanisms might depend on availability of signaling message protection. Some directly related threatssufficient funds and therefore real-time information. The Session/Reservation Ownership problem can also be considered as an authorization problem. Details are described in Section 2.8, 2.5, 2.85.10. In enterprise networks authorization is often coupled with membership to a particular class user of users/groups. This type of information can either be delivered as part of the authentication and 2.9. 2.7key agreement procedure or has to be retrieved via separate protocols from other entities. If an adversary manages to modify information relevant for determining authorization or the outcome of the authorization process itself then theft of service might be the consequence. 5.6 Missing Non-Repudiation Repudiation in this context refers to a problem where one party later denies to have requested a certain action (such as a QoS reservation). The problem of a missing non-repudiation property appears in two flavors: >FromFrom a service provider point-of-view the following threat may be worth an investigation. A user may deny to have issued reservation request for which it was charged. A service provider may then like to prove that a particular user issued reservation requests. The same threat can be interpreted from the usersuser's point-of-view. A service provider claims to have received a number of reservation requests. The user in question thinks that he never issued those requests and wants to have a proof for correct service usage for a given set of QoS parameters. In today's telecommunication networks non-repudiation is not provided. The user has to trust the network operator to correctly meter the traffic, collect and merge accounting data and that no unforeseen problems occur. If a signaling protocol is used to establish QoS reservations with a higher volume (for example service level agreements)the non-repudiation property for the authorized resources then it mighthas an impact on the protocol design. Looking at threats based on missing non-repudiation it must be carefully considered whether non-repudiation is needed.Non-repudiation poses additional requirements on the security mechanisms as it can only be provided through public-key cryptography. As this would often increase the overall cost for security, threats related to missing non- repudiationnon-repudiation are only considered relevant for certain specific scenarios but not for the(e.g. specific authorization mechanisms) and not for general NSIS scenario. 2.8signaling. 5.7 Malicious NSIS Entity Network elements within a domain (intra-domain) experience a different trust relationship with regard to the security protection of signaling messages compared to the edge routers.NSIS entity. We assume that edge routersNSIS entity have the responsibility to perform cryptographic processing (authentication, integrity and replay protection, authorization and accounting) for signaling message arriving from the outside. This prevents signaling messages to appear unprotected within the internal network. If however an adversary manages to take over an edge router then the security of the entire network is affected. An adversary is then able to launch a number of attacks including denial of service, integrity violation, replay attacks etc. In case of policy rule installation a rogue firewall can cause harm to other firewalls by modifying the policy rules accordingly. The chain-of-trust principle applied in the peer-to-peer security protection cannot provide protection against a malicious NSIS node. An adversary with access to an NSIS router is then also able to get access to security associations to transmit secured signaling messages. Note that even non peer-to-peer security protection might not be able to fully prevent this problem. Since an NSIS node might issue signaling messagemessages on behalf of someone else (by acting as a proxy) additional problems are the consequence. An NSIS aware edge router is a critical component that requires strong security protection. A strong security policy applied at edge does not imply that all routers within an intra-domain network do not need to cryptographically verify signaling messages. If the chain-of-trustchain-of- trust principle is deployed then the security protection of the entire path (in this case within the network of a single administrative domain) is as strong as the weakest link. In our case the edge router is the most critical component of this network that may also act as a security gateway/firewall for incoming/outgoing traffic. For outgoing traffic this device has to act according to the security policy of the local domain to apply the appropriate security protection. For an adversary to mount this attack either an existing NSIS aware node along the path has to be successfully attacked or an adversary succeeds to convince another NSIS node to be the next NSIS peer (man-in-the- middle(man- in-the-middle attack). 2.95.8 Denial of Service Attacks A number of denial of service attacks can cause NSIS nodes to malfunction. Other attacks that could lead to DoS, such as man-in-the- middleman-in- the-middle attacks, replay attacks, injection or modification of signaling messages etc., are mentioned throughout this document. 1.- Path Finding This threat tries to address potential denial of service attacks when the reservation setup is split into two phases i.e. path and reservation (as for example used in receiver based reservation setup). For this example we assume that the node transmitting the path message is not charged for the path message itself and is able to issue a high number of reservation requestrequests (possibly in a distributed fashion). Charging is activated only after successful verification of the reservation request. The reservations are however never intended to be successful because of various reasons: the destination node cannot be reached; it is not responding or simply rejects the reservation. An adversary can benefit from the fact that resources arestate has already consumedbeen allocated along the path for various processing tasks including path pinning. 2.- Discovery Phase Signaling information to a large number of entities along a data path requires some sort of discovery. This discovery process is vulnerable to a number of attacks since it is difficult to secure. An adversary can use the discovery mechanisms to convince an entity to signal information to another entity which is not along the data path or to cause the discovery process to fail. In the first case the signaling protocol could be correctly continued with the problem that policy rules are installed at incorrect firewalls or QoS resource reservations take place at the wrong entities. For an end host this means that the protocol failed for unknown reasons. 3.- Faked Error/Response messages An adversary may be able to use false error/response messages as part of a denial of service attack. This could be either at the message signaling protocol level, at the level of each client layer protocol (QoS, Midcom, etc.) or at the transport level protocol. An adversary might cause unexpected protocol behavior or produce denial of service attacks. Especially the discovery protocol shows vulnerabilities with regard to this threat. In case that no separate discovery protocol is used by addressing signaling messages to end hosts only (with a Router Alert Option to intercept message as NSIS aware nodes) then an error message might be used to indicate a path change. Such a design is a combination of a discovery protocol together with a signaling message exchange protocol. 2.105.9 Disclosing the network topology In some architectures there is a desire not to reveal the internal network structure (or other related information) to the outside world. An adversary might be able to use NSIS messages for network mapping (e.g. discovering which nodes exist, which use NSIS, what version, what resources are allocated, capabilities of nodes along a paths etc.). Discovery messages, traceroute, diagnostic messages (see [RFC2745] for a description of diagnostic message functionality for RSVP), query messages in addition to record route and route objects provide the potential to assist an adversary. Hence the requirement of not disclosing a network topology might conflict with another requirement to provide means for automatically discovering NSIS aware nodes or to provide diagnostic facilities (used for network monitoring and administration). 2.115.10 Session/Reservation Ownership Figure 4 shows an NSIS Initiator which established state information at NSIS nodes along the path as part of the signaling procedure. As a result the Access Router1 Router 3 and Router 4 (and other nodes) store session state information including the Session Identifier SID-x.SID- x. Session ID(SID-x) +--------+ +-----------------+ Router +------------> Session ID(SID-x)| | 4 | +---+----+ +--------+ | Router | +------+ 3 +******* | +---+----+ * | * | Session ID(SID-x) * Session ID(SID-x) +---+----+ +---+----+ | Access | | Access | | Router | | Router | | 1 | | 2 | +---+----+ +---+----+ | * | Session ID(SID-x) * Session ID(SID-x) +----+------+ +----+------+ | NSIS | | Adversary | | Initiator | | | +-----------+ +-----------+ Figure 4: Session/Reservation Ownership The Session Identifier is included in signaling messages to reference to the established state. If an adversary was able to obtain the Session Identifier for example by eavesdropping signaling messages it is able to add the same Session Identifier SID-x to a new a signaling message. When the signaling message hits Router3 (as shown in Figure 3) then existing state information can be modified. The adversary can then modify or delete the established reservation causing unexpected behavior for the legitimate user. The source of the problem is that Router3 (cross-over router) is unable to decide whether the new signaling message was initiated from the owner of the session/reservation. To make processing even more difficult it must be mentioned that not only the initial signaling message originator is allowed to signal information during the lifetime of an established session. As part of the protocol any NSIS aware node along the path (and the path might change over time) could be involved in the signaling message exchange and it might be necessary to provide mobility support or to trigger a local repair procedure. Hence if only the initial signaling message originator is allowed to trigger signaling message exchange some protocol behavior will not be possible. In case that this threat is not addressed an adversary can launch denial of service, theft of service, and various other attacks. 2.12 Security Parameter Exchange/Negotiation Protocols, which should be useful for a variety of scenarios, tend to have different security requirements. It is often difficult to meet these (sometimes conflicting requirements) with a single security mechanism or a fixed security parameter. Hence often a few selected mechanisms/parameters are supported. Therefore some protocol exchange is required to agree on some security mechanisms/parameters. This protocol exchanged can be the misused by an adversary to mount a downgrading attack by selecting weaker mechanisms than desired. Hence without protecting the negotiation process the security of an NSIS protocol might be as secure as the weakest mechanism if no configuration parameters (for example a security policy disallowing the weakest mechanism, etc.) are used otherwise. 2.135.11 Attacks against the signaling message transport mechanism In [BL01] a two-level architecture is proposed which suggests to split an NSIS protocol into layers: a signaling message transport specific layer and an application specific layer. This architectural assumptionsassumption is also considered within the NSIS framework .[HF+03]. Most of the threats described in this document are applicable to the application specific part for signaling QoS or middlebox specific information. There are, however, some threats which are applicable to the transport of signaling messages. Network or transport layer protocols which experience no protectedprotection are vulnerable to certain attacks such as header manipulation, DoS, spoofing of identities, session hijacking, unexpected aborts etc. Malicious nodes can attack the congestion control mechanism to force NSIS nodes into a congestion avoidance state. In case that an existing protocol is used for exchanging NSIS signaling messages then threats known from these protocols are relevant. 2.14 Deployment Threats6. Security Considerations This section addresses problems which could appear during the deployment of an NSIS protocol in a real-world environment. Although these problems are theoretically not an obstacleentire memo discusses security issues relevant for practical reasons they can representNSIS. To counter these threats worth a consideration. Missing Authorization: Authentication is a very important step for providing the foundation of authorization and accounting. Unlike some other protocols (for example HTTPS) where an authorization verification step is fairly easy (and efficient) QoS and middlebox communication requires more care. First, there is the question what authorization means in the context of NSIS signaling. For quality of service signaling the possible range is broad and could range from pure monetary policies to traditional role-based access control policies. Second, there is a question where this authorization data can be retrieved. Especially in a mobile environment this might be more complicated to securely exchange this information between different network domains. Finally there is an issue of authorization representation (i.e. a language describing authorization policies). If authorization information is exchanged between a large number of networks then this issue deserves further consideration. In the discovery phase an additional issue of authorization was raised. Whenever a node wants to discover the next NSIS aware node then authentication might not be sufficient. In many cases the IP address or FQDN of a particular router in an unknown network does not add too much trust. An end host for example might want some assurance that this node belongs to a network which has some sort of business relationship which is known and acceptable (from an accounting, charging, security and privacy point of view). Missing Cost Control: There is a risk that a large number of service providers with complex roaming agreements create a non-transparent cost- structure. In a traditional subscription-based scenario users are registered with their home networks and use this trust relationship to dynamically establishment other security associations. This is the typical AAA deployment scenario. In these scenarios users do not learn the identity of the access network as part of a regular authentication and key exchange protocol message exchange. The identity of the access network is possibly never revealed (in a secure fashion). The user is therefore only authenticated to the home network (and hopefully vice versa). When issuing a QoS reservation request to the next NSIS peer (for example in the access network) the end host is typically unaware of the cost of such a reservation. Due to mobility and route changes along the path the cost for an end-to-end QoS reservation might not be transparent for the end host or even become unacceptable. Today there is no standarized protocol available which allows users to communicate cost limits, to request cost information for network resources or to learn already accumulated costs for a particular reservation. Especially in mobility environments where an end host is likely to have access to a large number of networks within a short time period cost control is even more complicated. Some mobility/QoS protocol proposals try to merge existing mobility protocols with QoS signaling (i.e. to apply in-band signaling). Thereby the access network is queried (towards the cross-over router or the MAP) for the possibility making a QoS reservation (without actually making the reservation itself). Without a query mechanism a user cannot take reservation costs into account when choosing between different access networks (or different access routers). Hence the user might not be unable to refuse a more expensive service provider. To allow a user to choose between different providers might be required not only because of the availability of different access technologies (e.g. IEEE 802.1x, Bluetooth, UTRAN) and the different service quality offered but also for cost reasons. Although real-time notifications of quality of service reservation costs (cost control) to the user are outside the scope of NSIS some interaction might be required. 3 Security Considerations This entire memo discusses security issues relevant for NSIS. To counter these threats security requirements have been defined and the framework relevant topics have been described. Some additional threats applicable for first peer communication in mobile environments are described in . 4 Acknowledgements We would like to thank (in alphabetical order) Marcus Brunner, Jorge Cuellar, Mehmet Ersue, Xiaoming Fu and Robert Hancock for their comments to this draft. Jorge and Robert gave us an extensive list of comments and provided information on additional threats. 5 Authors' Addresses Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 81739 Munich Germany EMail: Hannes.Tschofenig@siemens.com Dirk Kroeselberg Siemens AG Otto-Hahn-Ring 6 81739 Munich Germany EMail: Dirk.Kroeselberg@siemens.com 6 Bibliography  X. Fu, C. Kappler, and H. Tschofenig, "Analysis on RSVP regarding multicast," Internet Draft, Internet Engineering Task Force, June 2002. Work in progress.  H. D. Meer et al. , "Analysis of existing qos solutions," Internet Draft, Internet Engineering Task Force, July 2002. Work in progress.  H. Tschofenig, "Rsvp security properties," Internet Draft, Internet Engineering Task Force, 2002. Work in progress.  M. Thomas, "Analysis of mobile ip and rsvp interactions," Internet Draft, Internet Engineering Task Force, 2002. Work in progress.  J. Manner and X. Fu, "Analysis of existing quality of service signaling protocols," Internet Draft, Internet Engineering Task Force, 2002. Work in progress.  M. Brunner, "Requirementssecurity requirements have been listed in [Brun03]. Framework relevant topics have been incorporated into [HF+03]. 7. Normative References [Brun03] M. Brunner, "Requirements for QoS signaling protocols," Internet Draft, Internet Engineering Task Force, July 2002.June 2003. Work in progress. [HF+03] R. Hancock, I. Freytsis, G. Karagiannis, J. Loughney, and S. V. den Bosch, "Next steps in signaling: Framework," Internet Draft, Internet Engineering Task Force, 2002.March 2003. Work in progress. 8. Informative References [RFC1809] C. Partridge, "Using the flow label field in IPv6," RFC 1809, Internet Engineering Task Force, June 1995. [RFC2745] A. Terzis, B. Braden, S. Vincent, and L. Zhang, "RSVP Diagnostic Messages," RFC 2745, Internet Engineering Task Force, Jan. 2000. [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., Hess, R.: "Identity Representation for RSVP", RFC 3182, October, 2001. [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session initiation protocol," RFC 3261, Internet Engineering Task Force, June 2002.  S. Kent[RFC3521] L. Hamer, B. Gage, and R. Atkinson, "Security architectureH. Shieh, "Framework for the internet protocol,"session set-up with media authorization," RFC 2401,3521, Internet Engineering Task Force, Nov. 1998. April 2003. [RFC3520] L. Hamer, B. Gage, M. Broda,B. Kosinski, and H. Shieh, "Session authorization for RSVP,"Authorization Policy Element", RFC 3520, Internet Engineering Task Force, April 2003. [RC+03] J. Rajahalme, A. Conta, B. Carpenter, and S. Deering, "IPv6 Flow Label Specification," Internet Draft, Internet Engineering Task Force, July 2002.April 2003. Work in progress.  L. Hamer,[BL01] B. Gage,Braden and H. Shieh, "FrameworkB. Lindell, "A two-level architecture for session set-up with media authorization,"internet signaling," Internet Draft, Internet Engineering Task Force, July 2002.Nov. 2001. Work in progress.  C. Partridge, "UsingAcknowledgments We would like to thank (in alphabetical order) Marcus Brunner, Jorge Cuellar, Mehmet Ersue, Xiaoming Fu and Robert Hancock for their comments to an initial version of this draft. Jorge and Robert gave us an extensive list of comments and provided information on additional threats. Jukka Manner, Martin Buechli, Roland Bless, Marcus Brunner, Michael Thomas and Mohan Parthasarathy provided comments to a recent version of this draft. Their input helped to improve the flow label fieldcontent of this document. Particularly Roland Bless and Michael Thomas provided proposals for regrouping and restructuring. Author's Addresses Hannes Tschofenig Siemens AG Corporate Technology CT IC 3 Otto-Hahn-Ring 6 81739 Munich Germany EMail: Hannes.Tschofenig@siemens.com Dirk Kroeselberg Siemens AG Otto-Hahn-Ring 6 81739 Munich Germany EMail: Dirk.Kroeselberg@siemens.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in IPv6," RFC 1809, Internet Engineering Task Force, June 1995.  J. Rajahalme, A. Conta, B. Carpenter,its implementation may be prepared, copied, published and S. Deering, "IPv6 flow label specification," Internet Draft, Internet Engineering Task Force, June 2002. Workdistributed, in progress.  A. Terzis, B. Braden, S. Vincent,whole or in part, without restriction of any kind, provided that the above copyright notice and L. Zhang, "RSVP diagnostic messages," RFC 2745, Internet Engineering Task Force, Jan. 2000.  B. Bradenthis paragraph are included on all such copies and B. Lindell, "A two-level architecture for internet signaling,"derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Draft,Society or other Internet Engineering Task Force, Nov. 2001. Workorganizations, except as needed for the purpose of developing Internet standards in progress.  J. Kempf and E. Nordmark, "Threat analysiswhich case the procedures for IPv6 public multi- access links,"copyrights defined in the Internet Draft,Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Engineering Task Force, June 2002. Work in progress. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 2 1.1 NSIS Security Process . . . . . . . . . . . . . . . . . . 2 1.2 Relevant communication models . . . . . . . . . . . . . . 4 2 Threat Scenarios . . . . . . . . . . . . . . . . . . . . 9 2.1 MITM Attacks . . . . . . . . . . . . . . . . . . . . . . 9 2.2 EavesdroppingSociety or its successors or assignees. This document and Traffic Analysis . . . . . . . . . . . 12 2.3 Adversary being able to replay signaling messages . . . . 12 2.4 Missing Protection of Authorization Information . . . . . 13 2.5 Identity Spoofing . . . . . . . . . . . . . . . . . . . . 13 2.6 Adversary being able to inject/modify messages . . . . . 15 2.7 Missing Non-Repudiation . . . . . . . . . . . . . . . . . 15 2.8 Malicious NSIS Entity . . . . . . . . . . . . . . . . . . 16 2.9 Denial of Service Attacks . . . . . . . . . . . . . . . . 17 2.10 Disclosingthe network topology . . . . . . . . . . . . . 18 2.11 Session/Reservation Ownership . . . . . . . . . . . . . . 18 2.12 Security Parameter Exchange/Negotiation . . . . . . . . . 20 2.13 Attacks againstinformation contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the signaling message transport mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.14 Deployment Threats . . . . . . . . . . . . . . . . . . . 21 3 Security Considerations . . . . . . . . . . . . . . . . . 22 4 Acknowledgements . . . . . . . . . . . . . . . . . . . . 22 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . 23 6 Bibliography . . . . . . . . . . . . . . . . . . . . . . 23RFC Editor function is currently provided by the Internet Society.