栏目搜索
 
 
 
 
你的位置:首页 > 协议大全 > RFC4081 - Security Threats for Next Steps in Signaling (NSIS) >
 

RFC4081 - Security Threats for Next Steps in Signaling (NSIS)

发布者:[本站编辑] | 来源:[]

RFC4081 - Security Threats for Next Steps in Signaling (NSIS)_电脑维修资料库

network working group h. tschofenigrequest for comments: 4081 d. kroeselbergcategory: informational siemensjune 2005security threats for next steps in signaling (nsis)status of this memothis memo provides information for the internet community. it doesnot specify an internet standard of any kind. distribution of thismemo is unlimited.copyright noticecopyright (c) the internet society (2005).abstractthis threats document provides a detailed analysis of the securitythreats relevant to the next steps in signaling (nsis) protocolsuite. it calls attention to, and helps with the understanding of,various security considerations in the nsis requirements, framework,and protocol proposals. this document does not describevulnerabilities of specific parts of the nsis protocol suite.table of contents1. introduction ....................................................22. communications models ...........................................33. generic threats .................................................73.1. man-in-the-middle attacks ..................................83.2. replay of signaling messages ..............................113.3. injecting or modifying messages ...........................113.4. insecure parameter exchange and negotiation ...............124. nsis-specific threat scenarios .................................124.1. threats during nsis sa usage ..............................134.2. flooding ..................................................134.3. eavesdropping and traffic analysis ........................154.4. identity spoofing .........................................154.5. unprotected authorization information .....................174.6. missing non-repudiation ...................................184.7. malicious nsis entity .....................................194.8. denial of service attacks .................................204.9. disclosing the network topology ...........................214.10. unprotected session or reservation ownership .............214.11. attacks against the ntlp .................................235. security considerations ........................................236. contributors ...................................................247. acknowledgements ...............................................248. references .....................................................258.1. normative references ......................................258.2. informative references ....................................251. introductionwhenever a new protocol is developed or existing protocols aremodified, threats to their security should be evaluated. to addresssecurity in the nsis working group, a number of steps have beentaken:nsis analysis activities (see and )security threats for nsisnsis requirements (see )nsis framework (see )nsis protocol suite (see gimps , nat/firewall nslp and qos nslp )this document identifies the basic security threats that need to beaddressed during the design of the nsis protocol suite. even if thebase protocol is secure, certain extensions may cause problems whenused in a particular environment.this document cannot provide detailed threats for all possible nsissignaling layer protocols (nslps). qos , nat/firewall, and other nslp documents need to provide a descriptionof their trust models and a threat assessment for their specificapplication domain. this document aims to provide some help for thesubsequent design of the nsis protocol suite. investigations ofsecurity threats in a specific architecture or context are outsidethe scope of this document.we use the nsis terms defined in and in .2. communications modelsthe nsis suite of protocols is envisioned to support varioussignaling applications that need to install and/or manipulate stateat nodes along the data flow path through the network. as such, thensis protocol suite involves the communication between differententities.this section offers terminology for common communication models thatare relevant to securing the nsis protocol suite.an abstract network topology with its administrative domains is shownin figure 1, and in figure 2 the relationship between nsis entitiesalong the path is shown. for illustrative reasons, only end-to-endnsis signaling is depicted, yet it might be used in other variationsas well. signaling can start at any place and might terminate at anyother place within the network. depending on the trust relationshipbetween nsis entities and the traversed network parts, differentsecurity problems arise.the notion of trust and trust relationship used in this document isinformal and can best be captured by the definition provided insection 1.1 of . for completeness we include the definitionof a trust relationship, which denotes a mutual a priori relationshipbetween the involved organizations or parties wherein the partiesbelieve that the other parties will behave correctly even in thefuture.an important observation for nsis is that a certain degree of trusthas to be placed into intermediate nsis nodes along the path betweenan nsis initiator and an nsis responder, specifically so that theyperform message processing and take the necessary actions. acomplete lack of trust between any of the participating entities willcause nsis signaling to fail.note that it is not possible to describe a trust model completelywithout considering the details and behavior of the ntlp, the nslp(e.g., qos nslp), and the deployment environment. for example,securing the communication between an end host (which acts as thensis initiator) and the first nsis node (which might be in theattached network or even a number of networks away) is impacted bythe trust relationships between these entities. in a corporatenetwork environment, a stronger degree of trust typically exists thanin an unmanaged network.figure 1 introduces convenient abbreviations for network parts withsimilar properties: first-peer, last-peer, intra-domain, orinter-domain.+------------------+ +---------------+ +------------------+| | | | | || administrative | | intermediate | | administrative || domain a | | domains | | domain b || | | | | || (inter-domain communication) || +-------->+---+<------------->+---+<--------+ || (intra-domain | | | | (intra-domain || communication) | | | | communication) || | | | | | | || v | | | | v |+--------+---------+ +---------------+ +---------+--------+^ ^| |first peer communication last peer communication| |v v+-----+-----+ +-----+-----+| nsis | | nsis || initiator | | responder |+-----------+ +-----------+figure 1: communication patterns in nsisfirst-peer/last-peer communication:the end-to-end communication scenario depicted in figure 1includes the communication between the end hosts and their nearestnsis hops. first-peer communications refers to the peer-to-peerinteraction between a signaling message originator, the nsisinitiator (ni), and the first nsis-aware entity along the path.this first-peer communications commonly comes with specificsecurity requirements that are especially important for addressingsecurity issues between the end host (and a user) and the networkit is attached to.to illustrate this, in roaming environments, it is difficult toassume the existence of a pre-established security associationdirectly available for nsis peers involved in first-peercommunications, because these peers cannot be assumed to have anypre-existing relationship with each other. in contrast, inenterprise networks usually there is a fairly strong(pre-established) trust relationship between the peers.enterprise network administrators usually have some degree offreedom to select the appropriate security protection and toenforce it. the choice of selecting a security mechanism istherefore often influenced by the infrastructure alreadyavailable, and per-session negotiation of security mechanisms isoften not required (although, in contrast, it is required in aroaming environment).last-peer communication is a variation of first-peer communicationin which the roles are reversed.intra-domain communication:after verification of the nsis signaling message at the border ofan administrative domain, an nsis signaling message traverses thenetwork within the same administrative domain to which the firstpeer belongs. it might not be necessary to repeat theauthorization procedure of the nsis initiator again at every nsisnode within this domain. key management within the administrativedomain might also be simpler.security protection is still required to prevent threats bynon-nsis nodes in this network.inter-domain communication:inter-domain communication deals with the interaction betweenadministrative domains. for some nslps (for example, qos nslp),this interaction is likely to take place between neighboringdomains, whereas in other nslps (such as the nat/firewall nslp),the core network is usually not involved.if signaling messages are conveyed transparently in the corenetwork (i.e., if they are neither intercepted nor processed inthe core network), then the signaling message communicationseffectively takes place between access networks. this might placea burden on authorization handling and on the key managementinfrastructure required between these access networks, which mightnot know of each other in advance.to refine the above differentiation based on the network parts thatnsis signaling may traverse, we subsequently consider relationshipsbetween involved entities. because a number of nsis nodes mightactively participate in a specific protocol exchange, a larger numberof possible relationships need to be analyzed than in otherprotocols. figure 2 illustrates possible relationships between theentities involved in the nsis protocol suite.***************************************** *+----+-----+ +----------+ +----+-----++-----+ nsis +-------+ nsis +--------+ nsis +-----+| | node 1 | | node 2 | | node 3 | || +----------+ +----+-----+ +----------+ || ~ || ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ || ~ |+--+--+-----+ +---------+-+| nsis +//////////////////////////////////////////+ nsis || initiator | | responder |+-----------+ +-----------+legend:-----: peer-to-peer relationship/////: end-to-end relationship*****: middle-to-middle relationship~~~~~: end-to-middle relationshipfigure 2: possible nsis relationshipsend-to-middle communications:the scenario in which one nsis entity involved is an end-entity(initiator or responder) and the other entity is any intermediatehop other than the immediately adjacent peer is typically calledthe end-to-middle scenario (see figure 2). a motivation forincluding this scenario can, for example, be found in sip.an example of end-to-middle interaction might be an explicitauthorization from the nsis initiator to some intermediate node.threats specific to this scenario may be introduced by someintermediate nsis hops that are not allowed to eavesdrop or modifycertain objects.middle-to-middle communications:middle-to-middle communication refers to the exchange ofinformation between two non-neighboring nsis nodes along the path.intermediate nsis hops may have to deal with specific securitythreats that do not involve the nsis initiator or the nsisresponder directly.end-to-end communications:nsis aims to signal information from an initiator to some nsisnodes along the path to a data receiver. in the case ofend-to-end nsis signaling, the last node is the nsis responder, asit is the data receiver. the nsis protocol suite is not anend-to-end protocol used to exchange information purely betweenend hosts.typically, it is not required to protect nsis messagescryptographically between the nsis initiator and the nsisresponder. protecting the entire signaling message end-to-endmight not be feasible since intermediate nsis nodes need to add,inspect, modify, or delete objects from the signaling message.3. generic threatsthis section provides scenarios of threats that are applicable tosignaling protocols in general. note that some of these scenariosuse the term user instead of nsis initiator. this is mainlybecause security protocols allow differentiation between entitiesthat are hosts and those that are users (based on the identifiersused).for the following subsections, we use the general distinction in twocases in which attacks may occur. these are according to theseparate steps, or phases, normally encountered when applyingprotocol security (with, e.g., ipsec, tls, kerberos, or ssh).therefore, this section starts by briefly describing a motivation forthis separation.security protection of protocols is often separated into two steps.the first step primarily provides entity authentication and keyestablishment (which result in a persistent state often called asecurity association), whereas the second step provides messageprotection (some combination of data origin authentication, dataintegrity, confidentiality, and replay protection) using thepreviously established security association. the first step tends tobe more expensive than the second, which is the main reason for theseparation. if messages are transmitted infrequently, then these twosteps may be collapsed into a single and usually rather costly one.one such example is e-mail protection via s/mime. the two steps maybe tightly bound into a single protocol, as in tls, or defined inseparate protocols, as with ike and ipsec. we use this separation tocover the different threats in more detail.3.1. man-in-the-middle attacksthis section describes both security threats that exist if two peersdo not already share a security association or do not use securitymechanisms at all, and threats that are applicable when a securityassociation is already established.attacks during nsis sa establishment:while establishing a security association, an adversary fools thesignaling message initiator with respect to the entity to which ithas to authenticate. the initiator authenticates to the man-in-the-middle adversary, who is then able to modify signalingmessages to mount dos attacks or to steal services that get billedto the initiator. in addition, the adversary may be able toterminate the initiator's nsis messages and to inject messages toa peer itself, thereby acting as the peer to the initiator and asthe initiator to the peer. as a result, the initiator wronglybelieves that it is talking to the real network, whereas it isactually attached to an adversary. for this attack to besuccessful, pre-conditions that are described in the followingthree cases have to hold:missing authentication:in the first case, this threat can be carried out because ofmissing authentication between neighboring peers: withoutauthentication, an ni, nr, or nf is unable to detect anadversary. however, in some practical cases, authenticationmight be difficult to accomplish, either because the next peeris unknown, because there are misbelieved trust relationshipsin parts of the network, or because of the inability toestablish proper security protection (inter-domain signalingmessages, dynamic establishment of a security association,etc.). if one of the communicating endpoints is unknown, thenfor some security mechanisms it is either impossible orimpractical to apply appropriate security protection.sometimes network administrators use intra-domain signalingmessages without proper security. this configuration allows anadversary on a compromised non-nsis-aware node to interferewith nodes running an nsis signaling protocol. note that thistype of threat goes beyond those caused by malicious nsis nodes(described in section 4.7).unilateral authentication:in the case of unilateral authentication, the nsis entity thatdoes not authenticate its peer is unable to discover a man-in-the-middle adversary. although mutual authentication ofsignaling messages should take place between each peerparticipating in the protocol operation, special attention isgiven here to first-peer communications. unilateralauthentication between an end host and the first peer (justauthenticating the end host) is still common today, but itopens up many possibilities for man-in-the-middle attackersimpersonating either the end host or the (administrative domainrepresented by the) first peer.missing or unilateral authentication, as described above, ispart of a general problem of network access with inadequateauthentication, and it should not be considered somethingunique to the nsis signaling protocol. obviously, there is astrong need to address this correctly in a future nsis protocolsuite. the signaling protocols addressed by nsis are differentfrom other protocols in which only two entities are involved.note that first-peer authentication is especially importantbecause a security breach there could impact nodes beyond theentities directly involved (or even beyond a local network).finally, note that the signaling protocol should be considereda peer-to-peer protocol, wherein the roles of initiator andresponder can be reversed at any time. thus, unilateralauthentication is not particularly useful for such a protocol.however, some form of asymmetry might be needed in theauthentication process, whereby one entity uses anauthentication mechanism different from that of the other one.as an example, the combination of symmetric and asymmetriccryptography should be mentioned.weak authentication:in the case of weak authentication, the threat can be carriedout because information transmitted during the nsis saestablishment process may leak passwords or allow offlinedictionary attacks. this threat is applicable to nsis for theprocess of selecting certain security mechanisms.finally, we conclude with a description of a man-in-the-middle (mitm)attack during the discovery phase. this attack benefits from thefact that nsis nodes are likely to be unaware of the networktopology. furthermore, an authorization problem might arise if annsis qos nslp node pretends to be an nsis nat/firewall-specific nodeor vice versa.an adversary might inject a bogus reply message, forcing thediscovery message initiator to start a messaging associationestablishment with either an adversary or with another nsis node thatis not along the path. figure 3 describes the attack in more detailfor peer-to-peer addressed messages with a discovery mechanism. forend-to-end addressed messages, the attack is also applicable,particularly if the adversary is located along the path and able tointercept the discovery message that traverses the adversary. theman-in-the-middle adversary might redirect to another legitimate nsisnode. a malicious nsis node can be detected with the correspondingsecurity mechanisms, but a legitimate nsis node that is not the nextnsis node along the path cannot be detected without topologyknowledge.+-----------+ messaging associationmessage | adversary | establishmentassociation +--->+ +<----------------+establish- | +----+------+ |(4)ment | ipx | |(3)| |discovery reply v| | (ipx) +---+-------+v | (2) | nsis |+------+-----+ | /----------->+ node b +--------| nsis +<--+ / discovery +-----------+| node a +---------/ request ipr+------------+ (1)ipifigure 3: mitm attack during the discovery exchangethis attack assumes that the adversary is able to eavesdrop on theinitial discovery message sent by the sender of the discoverymessage. furthermore, we assume that the discovery reply message bythe adversary returns to the discovery message initiator faster thanthe real response. this represents some race conditioncharacteristics if the next nsis node is very close (in ip-hop terms)to the initiator. note that the problem is self-healing since thediscovery process is periodically repeated. if an adversary isunable to mount this attack with every discovery message, then thecorrect next nsis node along the path will be discovered again. aping-pong behavior might be the consequence.as shown in message step (2) in figure 3, the adversary returns adiscovery reply message with its own ip address as the next nsis-aware node along the path. without any additional information, thediscovery message initiator has to trust this information. then amessaging association is established with an entity at a given ipaddress ipx (i.e., with the adversary) in step (3). the adversarythen establishes a messaging association with a further nsis node andforwards the signaling message. note that the adversary might justmodify the discovery reply message to force nsis node a to establisha messaging association with another nsis node that is not along thepath. this can then be exploited by the adversary. the interworkingwith nsis-unaware nats in particular might cause additionalunexpected problems.as a variant of this attack, an adversary not able to eavesdrop ontransmitted discovery requests could flood a node with bogusdiscovery reply messages. if the discovery message senderaccidentally accepts one of those bogus messages, then a mitm attackas described in figure 3 is possible.3.2. replay of signaling messagesthis threat scenario covers the case in which an adversaryeavesdrops, collects signaling messages, and replays them at a latertime (or at a different place, or uses parts of them at a differentplace or in a different way; e.g., cut-and-paste attacks). withoutproper 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 if there isreplay protection) requires that the adversary crash an nsis-awarenode, causing it to lose state information (sequence numbers,security associations, etc.), and then replay old signaling messages.this attack takes advantage of re-synchronization deficiencies.3.3. injecting or modifying messagesthis type of threat involves integrity violations, whereby anadversary modifies signaling messages (e.g., by acting as aman-in-the-middle) in order to cause unexpected network behavior.possible actions an adversary might consider for its attack arereordering, delaying, dropping, injecting, truncating, and otherwisemodifying messages.an adversary may inject a signaling message requesting a large amountof resources (possibly using a different user's identity). otherresource requests may then be rejected. in combination with identityspoofing, it is possible to carry out fraud. this attack is onlyfeasible in the absence of authentication and signaling messageprotection.some threats directly related to these are described in sections 4.4,4.7, and 4.8.3.4. insecure parameter exchange and negotiationfirst, protocols may be useful in a variety of scenarios withdifferent security requirements. second, different users (e.g., auniversity, a hospital, a commercial enterprise, or a governmentministry) have inherently different security requirements. third,different parts of a network (e.g., within a building, across apublic carrier's network, or over a private microwave link) may needdifferent levels of protection. it is often difficult to meet these(sometimes conflicting) requirements with a single security mechanismor fixed set of security parameters, so often a selection ofmechanisms and parameters is offered. therefore, a protocol isrequired to agree on certain security mechanisms and parameters. aninsecure parameter exchange or security negotiation protocol can helpan adversary to mount a downgrading attack to force selection ofmechanisms weaker than those mutually desired. thus, without bindingthe negotiation process to the legitimate parties and protecting it,an nsis protocol suite might only be as secure as the weakestmechanism provided (e.g., weak authentication), and the benefits ofdefining configuration parameters and a negotiation protocol arelost.4. nsis-specific threat scenariosthis section describes eleven threat scenarios in terms of attacks onand security deficiencies in the nsis signaling protocol. a numberof security deficiencies might enable an attack. fraud is an exampleof an attack that might be enabled by missing replay protection,missing protection of authorization tokens, identity spoofing,missing authentication, and other deficiencies that help an adversarysteal resources. different threat scenarios based on deficienciesthat could enable an attack are addressed in this section.the threat scenarios are not independent. some of them (e.g., denialof service) are well-established security terms and, as such, need tobe addressed, but they are often enabled by one or more deficienciesdescribed under other scenarios.4.1. threats during nsis sa usageonce a security association is established (and used) to protectsignaling messages, many basic attacks are prevented. however, amalicious nsis node is still able to perform various attacks asdescribed in section 4.7. replay attacks may be possible when annsis node crashes, restarts, and performs state re-establishment.proper re-synchronization of the security mechanism must therefore beprovided to address this problem.4.2. floodingthis section describes attacks that allow an adversary to flood annsis node with bogus signaling messages to cause a denial of serviceattack.we will discuss this threat at different layers in the nsis protocolsuite:processing of router alert options:the processing of router alert option (rao) requires that a routerdo some additional processing by intercepting packets with ipoptions, which might lead to additional delay for legitimaterequests, or even rejection of some of them. a router beingflooded with a large number of bogus messages requires resourcesbefore finding out that these messages have to be dropped.if the protocol is based on using interception for messagedelivery, this threat cannot be completely eliminated, but theprotocol design should attempt to limit the processing that has tobe done on the rao-bearing packet so that it is as similar aspossible to that for an arbitrary packet addressed directly to oneof the router interfaces.attacks against the transport layer protocol:certain attacks can be mounted against transport protocols byflooding a node with bogus requests, or even to finish thehandshake phase to establish a transport layer association. thesetypes of threats are also addressed in section 4.11.force ntlp to do more processing:some protocol fields might allow an adversary to force an ntlpnode to perform more processing. additionally it might bepossible to interfere with the flow control or the congestioncontrol procedure. these types of threats are also addressed insection 4.11.furthermore, it might be possible to force the ntlp node toperform some computations or signaling message exchanges byinjecting trigger events (which are unprotected).force nslp to do more processing:an adversary might benefit from flooding an nslp node withmessages that must be stored (e.g., due to fragmentation handling)before verifying the correctness of signaling messages.furthermore, causing memory allocation and computational effortsmight allow an adversary to harm nsis entities. if a signalingmessage contains, for example, a digital signature, then someadditional processing is required for the cryptographicverification. an adversary can easily create a random bitsequence instead of a digital signature to force an nsis node intoheavy computation.idempotent signaling messages are particularly vulnerable to thistype of attack. the term idempotent refers to messages thatcontain the same amount of information as the original message.an example would be a refresh message that is equivalent to acreate message. this property allows a refresh message to createstate along a new path, where no previous state is available. forthis to work, specific classes of cryptographic mechanismssupporting this behavior are needed. an example is a scheme basedon digital signatures, which, however, should be used with caredue to possible denial of service attacks.problems with the usage of public-key-based cryptosystems inprotocols are described in and in .in addition to the threat scenario described above, an incomingsignaling message might trigger communication with third-partynodes such as policy servers, ldap servers, or aaa servers. if anadversary is able to transmit a large number of signaling messages(for example, with qos reservation requests) with invalidcredentials, then the verifying node may not be able to processother reservation messages from legitimate users.4.3. eavesdropping and traffic analysisthis section covers threats whereby an adversary is able to eavesdropon signaling messages. the signaling packets collected may allowtraffic analysis or be used later to mount replay attacks, asdescribed in section 3.2. the eavesdropper might learn qosparameters, communication patterns, policy rules for firewalltraversal, policy information, application identifiers, useridentities, nat bindings, authorization objects, networkconfiguration and performance information, and more.an adversary's capability to eavesdrop on signaling messages mightviolate a user's preference for privacy, particularly if unprotectedauthentication or authorization information (including policies andprofile information) is exchanged.because the nsis protocol signals messages through a number of nodes,it is possible to differentiate between nodes actively participatingin the nsis protocol and those that do not. for certain objects ormessages, it might be desirable to permit actively participatingintermediate nsis nodes to eavesdrop. on the other hand, it might bedesirable that only the intended end points (nsis initiator and nsisresponder) be able to read certain other objects.4.4. identity spoofingidentity spoofing relevant for nsis occurs in three forms: first,identity spoofing can happen during the establishment of a securityassociation based on a weak authentication mechanism. second, anadversary can modify the flow identifier carried within a signalingmessage. third, it can spoof data traffic.in the first case, eve, acting as an adversary, may claim to be theregistered user alice by spoofing alice's identity. eve therebycauses the network to charge alice for the network resourcesconsumed. this type of attack is possible if authentication is basedon a simple username identifier (i.e., in absence of cryptographicauthentication), or if authentication is provided for hosts, andmultiple users have access to a single host. this attack could alsobe classified as theft of service.in the second case, an adversary may be able to exploit theestablished flow identifiers (required for qos and nat/fw nslp).these identifiers are, among others, ip addresses, transport protocoltype (udp, tcp), port numbers, and flow labels (see and). modification of these flow identifiers allowsadversaries to exploit or to render ineffective quality of servicereservations or policy rules at middleboxes. an adversary couldmount an attack by modifying the flow identifier of a signalingmessage.in the third case, an adversary may spoof data traffic. nsissignaling messages contain some sort of flow identifier that isassociated with a specified behavior (e.g., a particular flowexperiences qos treatment or allows packets to traverse a firewall).an adversary might, therefore, use ip spoofing and inject datapackets to benefit from previously installed flow identifiers.we will provide an example of the latter threat. after nsis nodesalong the path between the nsis initiator and the nsis receiverprocesses a properly protected reservation request, transmitted bythe legitimate user alice, a qos reservation is installed at thecorresponding nsis nodes (for example, the edge router). the flowidentifier is used for flow identification and allows data trafficoriginated from a given source to be assigned to this qosreservation. the adversary eve now spoofs alice's ip address. inaddition, alice's host may be crashed by the adversary with a denialof service attack or may lose connectivity (for example, because ofmobility). if eve is able to perform address spoofing, then she isable to receive and transmit data (for example, rtp data traffic)that receives preferential qos treatment based on the previousreservation. depending on the installed flow identifier granularity,eve might have more possibilities to exploit the qos reservation or apin-holed firewall. assuming the soft state paradigm, wherebyperiodic refresh messages are required, alice's absence will not bedetected until a refresh message is required, forcing eve to respondwith a protected signaling message. again, this attack is applicablenot only to qos traffic, but also to a firewall control protocol,with a different consequence.the ability for an adversary to inject data traffic that matches acertain flow identifier established by a legitimate user and to getsome benefit from injecting that traffic often also requires theability to receive the data traffic or to have one's correspondentreceive it. for example, an adversary in an unmanaged networkobserves a nat/firewall signaling message towards a corporatenetwork. after the signaling message exchange was successful, theuser alice is allowed to traverse the company firewall based on theestablish packet filter in order to contact her internal mail server.now, the adversary eve, who was monitoring the signaling exchange, isable to build a data packet towards this mail server that will passthe company firewall. the packet will hit the mail server and causesome actions, and the mail server will reply with some responsemessages. depending on the exact location of the adversary and thedegree of routing asymmetry, the adversary might even see theresponse messages. note that for this attack to work, alice does notneed to participate in the exchange of signaling messages.we could imagine using attributes of a flow identifier that is notrelated to source and destination addresses. for example, we couldthink of a flow identifier for which only the 21-bit flow id is used(without source and destination ip address). identity spoofing andinjecting traffic is much easier since a packet only needs to bemarked and an adversary can use a nearly arbitrary endpointidentifier to achieve the desired result. obviously, though, theendpoint identifiers are not irrelevant, because the messages have tohit some nodes in the network where nsis signaling messages installedstate (in the above example, they would have to hit the samefirewall).data traffic marking based on diffserv is such an example. wheneveran ingress router uses only marked incoming data traffic foradmission control procedures, various attacks are possible. theseproblems have been known in the diffserv community for a long timeand have been documented in various diffserv-related documents. theipsec protection of diffserv code points is described in section 6.2of . related security issues (for example denial of serviceattacks) are described in section 6.1 of the same document.4.5. unprotected authorization informationauthorization is an important criterion for providing resources suchas qos reservations, nat bindings, and pinholes through firewalls.authorization information might be delivered to the nsis-participating entities in a number of ways.typically, the authenticated identity is used to assist during theauthorization procedure (as described in , for example).depending on the chosen authentication protocol, certain threats mayexist. section 3 discusses a number of issues related to thisapproach when the authentication and key exchange protocol is used toestablish session keys for signaling message protection.another approach is to use some sort of authorization token. thefunctionality and structure of such an authorization token for rsvpis described in and .achieving secure interaction between different protocols based onauthorization tokens, however, requires some care. by using such anauthorization token, it is possible to link state information betweendifferent protocols. returning an unprotected authorization token tothe end host might allow an adversary (for example, an eavesdropper)to steal resources. an adversary might also use the token to monitorcommunication patterns. finally, an untrustworthy end host mightalso modify the token content.the session/reservation ownership problem can also be regarded as anauthorization problem. details are described in section 4.10. inenterprise networks, authorization is often coupled with membershipin a particular class of users or groups. this type of informationeither can be delivered as part of the authentication and keyagreement procedure or has to be retrieved via separate protocolsfrom other entities. if an adversary manages to modify informationrelevant to determining authorization or the outcome of theauthorization process itself, then theft of service might bepossible.4.6. missing non-repudiationsignaling for qos often involves three parties: the user, a networkthat offers qos reservations (referred to as service provider) anda third party that guarantees that the party making the reservationactually receives a financial compensation (referred to as trustedthird party).in this context,repudiation refers to a problem where either theuser or the service provider later deny the existence or someparameters (e.g., volume or price) of a qos reservation towards thetrusted third party. problems stemming from a lack of non-repudiation appear in two forms:service provider's point-of-view:a user may deny having issued a reservation request for which itwas charged. the service provider may then want to be able toprove that a particular user issued the reservation request inquestion.user's point-of-view:a service provider may claim to have received a number ofreservation requests from a particular user. the user in questionmay want to show that such reservation requests have never beenissued and may want to see correct service usage records for agiven set of qos parameters.in today's networks, non-repudiation is not provided. therefore, itmight be difficult to introduce with nsis signaling. the user has totrust the network operator to meter the traffic correctly, to collectand merge accounting data, and to ensure that no unforeseen problemsoccur. if a signaling protocol with the non-repudiation property isdesired for establishing qos reservations, then it certainly impactsthe protocol design.non-repudiation functionality places additional requirements on thesecurity mechanisms. thus, a solution would normally increase theoverhead of a security solution. threats related to missing non-repudiation are only considered relevant in certain specificscenarios and for specific nslps.4.7. malicious nsis entitynetwork elements within a domain (intra-domain) experience adifferent trust relationship with regard to the security protectionof signaling messages from that of edge nsis entities. it is assumedthat edge nsis entities are responsible for performing cryptographicprocessing (authentication, integrity and replay protection,authorization, and accounting) for signaling messages arriving fromthe outside. this prevents unprotected signaling messages fromappearing within the internal network. if, however, an adversarymanages to take over an edge router, then the security of the entirenetwork is compromised. an adversary is then able to launch a numberof attacks, including denial of service; integrity violations; replayand reordering of objects and messages; bundling of messages;deletion of data packets; and various others. a rogue firewall canharm other firewalls by modifying policy rules. the chain-of-trustprinciple applied in peer-to-peer security protection cannot protectagainst a malicious nsis node. an adversary with access to an nsisrouter is also able to get access to security associations and totransmit secured signaling messages. note that even non-peer-to-peersecurity protection might not be able to prevent this problem fully.because an nsis node might issue signaling messages on behalf ofsomeone else (by acting as a proxy), additional problems need to beconsidered.an nsis-aware edge router is a critical component that requiresstrong security protection. a strong security policy applied at theedge does not imply that other routers within an intra-domain networkdo not need to verify signaling messages cryptographically. if thechain-of-trust principle is deployed, then the security protection ofthe entire path (in this case, within the network of a singleadministrative domain) is only as strong as the weakest link. in thecase under consideration, the edge router is the most criticalcomponent of this network, and it may also act as a security gatewayor firewall for incoming and outgoing traffic. for outgoing traffic,this device has to implement the security policy of the local domainand to apply the appropriate security protection.for an adversary to mount this attack, either an existing nsis-awarenode along the path has to be attacked successfully, or an adversarymust succeed in convincing another nsis node to make it the next nsispeer (man-in-the-middle attack).4.8. denial of service attacksa number of denial of service (dos) attacks can cause nsis nodes tomalfunction. other attacks that could lead to dos, such as man-in-the-middle attacks, replay attacks, and injection or modification ofsignaling messages, etc., are mentioned throughout this document.path finding:some signaling protocols establish state (e.g., routing state) andperform some actions (e.g., querying resources) at a number ofnsis nodes without requiring authorization (or even properauthentication) based on a single message (e.g., path message inrsvp).an adversary can utilize this fact to transmit a large number ofsignaling messages to allocate state at nodes along the path andto cause resource consumption.an nsis responder might not be able to determine the nsisinitiator and might even tend to respond to such a signalingmessage with a corresponding reservation message.discovery phase:conveying signaling information to a large number of entitiesalong a data path requires some sort of discovery. this discoveryprocess is vulnerable to a number of attacks because it isdifficult to secure. an adversary can use the discoverymechanisms to convince one entity to signal information to anotherentity that is not along the data path, or to cause the discoveryprocess to fail. in the first case, the signaling protocol couldappear to continue correctly, except that policy rules areinstalled at the incorrect firewalls or qos resource reservationstake place at the wrong entities. for an end host, this meansthat the protocol failed for unknown reasons.faked error or response messages:an adversary may be able to inject false error or responsemessages as part of a dos attack. this could be at the signalingmessage protocol layer (ntlp), the layer of each client layerprotocol (e.g., qos nslp or nat/firewall nslp), or the transportprotocol layer. an adversary might cause unexpected protocolbehavior or might succeed with a dos attack. the discoveryprotocol, especially, exhibits vulnerabilities with regard to thisthreat scenario (see the above discussion on discovery). if noseparate discovery protocol is used and signaling messages areaddressed to end hosts only (with a router alert option tointercept message as nsis aware nodes), an error message might beused to indicate a path change. such a design combines adiscovery protocol with a signaling message exchange protocol.4.9. disclosing the network topologyin some organizations or enterprises there is a desire not to revealinternal network structure (or other related information) outside ofa closed community. an adversary might be able to use nsis messagesfor network mapping (e.g., discovering which nodes exist, which usensis, what version, what resources are allocated, what capabilitiesnodes along a path have, etc.). discovery messages, traceroute,diagnostic messages (see for a description of diagnosticmessage functionality for rsvp), and query messages, in addition torecord route and route objects, provide potential assistance to anadversary. thus, the requirement of not disclosing a networktopology might conflict with other requirements to provide means fordiscovering nsis-aware nodes automatically or to provide diagnosticfacilities (used for network monitoring and administration).4.10. unprotected session or reservation ownershipfigure 4 shows an nsis initiator that has established stateinformation at nsis nodes along a path as part of the signalingprocedure. as a result, access router 1, router 3, and router 4 (andother nodes) have stored session-state information, including thesession identifier 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 or reservation ownershipthe session identifier is included in signaling messages to referenceto the established state.if an adversary were able to obtain the session identifier (forexample, by eavesdropping on signaling messages), it would be able toadd the same session identifier sid-x to a new signaling message.when the new signaling message hits router 3 (as shown in figure 4),existing state information can be modified. the adversary can thenmodify or delete the established reservation and cause unexpectedbehavior for the legitimate user.the source of the problem is that router 3 (a cross-over router) isunable to decide whether the new signaling message was initiated fromthe owner of the session or reservation.in addition, nodes other than the initial signaling messageoriginator are allowed to signal information during the lifetime ofan established session. as part of the protocol, any nsis-aware nodealong the path (and the path might change over time) could initiate asignaling message exchange. it might, for example, be necessary toprovide mobility support or to trigger a local repair procedure. ifonly the initial signaling message originator were allowed to triggersignaling message exchanges, some protocol behavior would not bepossible.if this threat scenario is not addressed, an adversary can launchdos, theft of service, and various other attacks.4.11. attacks against the ntlpin <2level>, a two-level architecture is proposed, that would splitan nsis protocol into layers: a signaling message transport-specificlayer and an application-specific layer. this is further developedin the nsis framework . most of the threats described inthis threat analysis are applicable to the nslp application-specificpart (e.g., qos nslp). there are, however, some threats that areapplicable to the ntlp.network and transport layer protocols lacking protection mechanismsare 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 forcensis nodes into a congestion avoidance state.threats that address parts of the ntlp that are not related toattacks against the use of transport layer protocols are covered invarious sections throughout this document, such as section 4.2.if existing transport layer protocols are used for exchanging nsissignaling messages, security vulnerabilities known for theseprotocols need to be considered. a detailed threat description ofthese protocols is outside the scope of this document.5. security considerationsthis entire memo discusses security issues relevant for nsis protocoldesign. it begins by identifying the components of a network runningnsis (initiator, responder, and different administrative domainsbetween them). it then considers five cases in which communicationstake place between these components, and it examines the trustrelationships presumed to exist in each case: first-peercommunications, end-to-middle communications, intra-domaincommunications, inter-domain communications, and end-to-endcommunications. this analysis helps determine the security needs andthe relative seriousness of different threats in the different cases.the document points out the need for different protocol securitymeasures: authentication, key exchange, message integrity, replayprotection, confidentiality, authorization, and some precautionsagainst denial of service. the threats are subdivided into genericones (e.g., man-in-the-middle attacks, replay attacks, tampering andforgery, and attacks on security negotiation protocols) and eleventhreat scenarios that are particularly applicable to the nsisprotocol. denial of service, for example, is covered in thensis-specific section, not because it cannot be carried out againstother protocols, but because the methods used to carry out denial ofservice attacks tend to be protocol specific. numerous illustrativeexamples provide insight into what can happen if these threats arenot mitigated.this document repeatedly points out that not all of the threats areequally serious in every context. it does attempt to identify thescenarios in which security failures may have the highest impact.however, it is difficult for the protocol designer to foresee all theways in which nsis protocols will be used or to anticipate thesecurity concerns of a wide variety of likely users. therefore, theprotocol designer needs to offer a full range of securitycapabilities and ways for users to negotiate and select what theyneed, on a case-by-case basis. to counter these threats, securityrequirements have been listed in .6. contributorswe especially thank richard graveman, who provided text for thesecurity considerations section, as well as a detailed review of thedocument.7. acknowledgementswe would like to thank (in alphabetical order) marcus brunner, jorgecuellar, mehmet ersue, xiaoming fu, and robert hancock for theircomments on an initial version of this document. jorge and robertgave us an extensive list of comments and provided information onadditional threats.jukka manner, martin buechli, roland bless, marcus brunner, michaelthomas, cedric aoun, john loughney, rene soltwisch, cornelia kappler,ted wiederhold, vishal sankhla, mohan parthasarathy, and andrewmcdonald provided comments on more recent versions of this document.their input helped improve the content of this document. rolandbless, michael thomas, joachim kross, and cornelia kappler, inparticular, provided good proposals for regrouping and restructuringthe material.a final review was given by michael richardson. we thank him for hisdetailed comments.8. references8.1. normative references hancock, r., karagiannis, g., loughney, j., and s. vanden bosch, next steps in signaling (nsis): framework,rfc 4080, june 2005. brunner, m., requirements for signaling protocols,rfc 3726, april 2004.8.2. informative references aura, t., leiwo, j., and p. nikander, towards networkdenial of service resistant protocols, in proceedingsof the 15th international information securityconference (ifip/sec 2000), beijing, china,august 2000. aura, t. and p. nikander, stateless connections, inproceedings of the international conference oninformation and communications security (icics'97),lecture notes in computer science 1334, springer,1997.<2level> braden, r. and b. lindell, a two-level architecturefor internet signaling, work in progress,november 2002. rajahalme, j., conta, a., carpenter, b., and s.deering, ipv6 flow label specification, rfc 3697,march 2004. stiemerling, m., a nat/firewall nsis signaling layerprotocol (nslp), work in progress, february 2005. schulzrinne, h., gimps: general internet messagingprotocol for signaling, work in progress,february 2005. bosch, s., karagiannis, g., and a. mcdonald, nslp forquality-of-service signaling, work in progress,february 2005. tschofenig, h., rsvp security properties, work inprogress, february 2005. manner, j. and x. fu, analysis of existing quality-of-service signaling protocols, rfc 4094, may 2005. partridge, c., using the flow label field in ipv6,rfc 1809, june 1995. terzis, a., braden, b., vincent, s., and l. zhang,rsvp diagnostic messages, rfc 2745, january 2000. yadav, s., yavatkar, r., pabbati, r., ford, p., moore,t., herzog, s., and r. hess, identity representationfor rsvp, rfc 3182, october 2001. rosenberg, j., schulzrinne, h., camarillo, g.,johnston, a., peterson, j., sparks, r., handley, m.,and e. schooler, sip: session initiation protocol,rfc 3261, june 2002. hamer, l-n., gage, b., kosinski, b., and h. shieh,session authorization policy element, rfc 3520,april 2003. hamer, l-n., gage, b., and h. shieh, framework forsession set-up with media authorization, rfc 3521,april 2003. nikander, p., kempf, j., and e. nordmark, ipv6neighbor discovery (nd) trust models and threats,rfc 3756, may 2004.authors' addresseshannes tschofenigsiemensotto-hahn-ring 6munich, bavaria 81739germanyemail: hannes.tschofenig@siemens.comdirk kroeselbergsiemensotto-hahn-ring 6munich, bavaria 81739germanyemail: dirk.kroeselberg@siemens.comfull copyright statementcopyright (c) the internet society (2005).this document is subject to the rights, licenses and restrictionscontained in bcp 78, and except as set forth therein, the authorsretain all their rights.this document and the information contained herein are provided on anas is basis and the contributor, the organization he/she representsor is sponsored by (if any), the internet society and the internetengineering task force disclaim all warranties, express or implied,including but not limited to any warranty that the use of theinformation herein will not infringe any rights or any impliedwarranties of merchantability or fitness for a particular purpose.intellectual propertythe ietf takes no position regarding the validity or scope of anyintellectual property rights or other rights that might be claimed topertain to the implementation or use of the technology described inthis document or the extent to which any license under such rightsmight or might not be available; nor does it represent that it hasmade any independent effort to identify any such rights. informationon the procedures with respect to rights in rfc documents can befound in bcp 78 and bcp 79.copies of ipr disclosures made to the ietf secretariat and anyassurances of licenses to be made available, or the result of anattempt made to obtain a general license or permission for the use ofsuch proprietary rights by implementers or users of thisspecification can be obtained from the ietf on-line ipr repository athttp://www.ietf.org/ipr.the ietf invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietaryrights that may cover technology that may be required to implementthis standard. please address the information to the ietf at ietf-ipr@ietf.org.acknowledgementfunding for the rfc editor function is currently provided by theinternet society.</t