NSIS Working Group Internet Draft Hannes Tschofenig Document: draft-ietf-nsis-threats-00.txt Siemens AG Expires: April 2003 October 2002NSIS Threats
<draft-ietf-nsis-threats-00.txt>
Status of this Memo This document is an Internet-Draft and is in full conformance with 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 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". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Informational - Expires April 2003 1 NSIS Threats October 2002 Abstract This threats document provides a starting point to security discussions at the NSIS working group. It therefore tries to help the NSIS interested reader to understand various security considerations in the NSIS Requirements, Framework and Protocol proposals. This document does not describe vulnerabilities of specific NSIS related protocols.1 Introduction
Section 1.1 tries to introduce the reader into the overall process of addressing the security of work done in the NSIS working group. Section 1.2 gives a big picture about the different network parts which are traversed by a signaling protocol. Each part is characterized by a different set of requirements and different trust relationships. The threats described in Section 2 can be assigned to the individual parts. Note that this document tries to use the terminology introduced and used in the NSIS Framework document [5]. Some of the terms which demand additional clarifications are briefly explained introduced in Section 1.31.1 NSIS Security Process
Whenever a new protocol has to be developed or existing protocols have to be modified potential security threats should be evaluated. The process of securing protocols in separated into individual steps. To address security in the NSIS working group a number of documents have been produced: +----------------------------------------------+ | NSIS Analysis Activities | | (e.g. RSVP Security Properties) | +----------------------------------------------+ +----------------------------------------------+ | NSIS Threats | | | +----------------------------------------------+ +----------------------------------------------+ | NSIS Requirements | | | +----------------------------------------------+ +----------------------------------------------+ | NSIS Framework Activities | | | +----------------------------------------------+ +----------------------------------------------+ | Published | | NSIS Protocol Proposals | +----------------------------------------------+ Figure 1: NSIS Security related Documents Tschofenig Informational - Expires April 2003 2 NSIS Threats October 2002 In order to reach a satisfactory security protection for a NSIS protocol a number of steps are necessary. The relevant information is distributed over a number of documents as depicted in Figure 1. The purpose of each of these documents is briefly described below to give the reader a more insights into the development process. The primary goal of the NSIS analysis activity is the investigation of existing approaches in the area of quality of service signaling protocols. Several of the published approaches contain directly security relevant descriptions whereas other requirements can be derived from different protocol behavior or different scenarios in which such a protocol is used. Document [8] points to the reduced complexity if RSVP is used without multicast support. This modification also comes with some simplifications for security handling. In [10] security issues raised by some example configurations are given. In [9] the security properties of RSVP are described. There are, however, a number of other analysis documents available but they do not directly address security issues. Threats relevant for NSIS are discussed in this document. To address threats described in this document requirements were specified in the NSIS Requirements document [1]. In addition to the requirements the document describes some basic scenarios where a QoS signaling protocol might be deployed. 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. A few proposals were submitted and a few authors cooperatively produced a NSIS framework document [5], which also address security issues. 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 be solve all security threats or if they are inappropriate for other reasons. In practice a protocol proposal might use existing security mechanisms but is likely to require some additional protection mechanisms or to combine them in a specific manner. Note that the process of developing the above-mentioned documents is not linear. Instead various iterations are required to reach a satisfactory final status. This document tries to identify the basic threats that need to be addressed by the NSIS signaling protocol design. 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 and the architecture where it is integrated. As an example of such an interaction accounting and charging is often mentioned in relationship with QoS signaling protocols. Without an appropriate integration of the two there is no good incentive for network Tschofenig Informational - Expires April 2003 3 NSIS Threats October 2002 operators to deploy QoS signaling protocols. This interaction is subject of a framework and some aspects are discussed in [5].1.2 Involved Network Parts
Independent of the threat scenarios described in Section 2 end-to-end signaling messages traverse different network parts, which demand different security mechanisms caused by the difference in trust relationships. The sub-parts are: access network part, intra and inter-domain part, and finally end-to-end communication. These parts are briefly described in this section and the threat scenarios of Section 2 can be assigned to the individual parts. a) Access Network (or First-Peer) Communication The term access network is fuzzy but in this context we refer to the communication between an end host and the first NSIS aware entity in the network to which this host is attached. Therefore threats are addressed where an NSIS Initiator (NI) transmits and receives signaling messages to some entity in the access network. In many mobility environments it is difficult to assume the existence of a pre-established trust relationship between a user and the access network. Threat scenarios dealing with initial security association setup, replay attacks, lack of confidentiality, denial of service, integrity violation, identity spoofing and fraud are applicable. From a security point of view this part of the network causes the largest number of problems. b) Intra-Domain Communication After receiving a NSIS signaling message and verifying the request somewhere in the access network the signaling message traverses the network within the same administrative domain. Since the request has already been authenticated and authorized threats are different compared to those described in the previous section. To differentiate the end-node-to-access network interface with the intra-domain communication we assume that no user hosts are logically attached to the core-network. (That is: the interface between any host and the first router is part of the access network). We furthermore assume that nodes within one administrative domain have a stronger trust relationship between each other. c) Inter-Domain Communication The threat assumptions between the borders of different administrative domains largely depends on how accounting is done. If one domain transmits forged QoS reservations to next domain then it is likely that the originating network domain has also has to pay for the reservation. Hence in this case, there is no real benefit for the first network domain to forge a QoS reservation. But if an end-node is directly charged by intermediate domains then this kind of attack may be reasonable. Security protection of messages transmitted Tschofenig Informational - Expires April 2003 4 NSIS Threats October 2002 between different administrative domains is still necessary to tackle attacks like spoofing, integrity violation, denial of service etc. The lower number of networks and higher trust relationship (compared in the access network case), the fewer problems for key management arise. d) End-to-End Communication In our opinion end-to-end security for NSIS signaling messages (in addition to hop-by-hop security) is rarely required if we assume that end-to-end issues like charging and the selection which user has to pay for a reservation is already securely negotiated by preceding upper layer protocols (for example SIP). Information carried within a NSIS signaling protocol for the purpose of charging is therefore assumed opaque to the NSIS protocol itself and appropriately protected as part of the AAA interaction. Note however that this assumption strongly depends on the chosen solution of a protocol interaction with AAA, QoS and application layer protocol. It is however possible to select a charging solution that requires end-to- end protection of information delivered within the QoS signaling protocol. The following example requires some sort of end-to-end protection: Alice wants Bob to pay for the QoS reservation (reverse charging). Bob wants to be assured that the QoS signaling message he receives was transmitted by Alice because he is only willing to pay for particular users and not for everyone. Hence Bob requires Alice to protect the reservation request. Regarding end-to-end security one additional issue needs to be clarified. Whenever a signaling protocol travels end-to-end and a node along the path acts on behalf of the other endpoint then further investigation is required how to solve this issues.1.3 Clarification
Some threat scenarios in this document use the term user instead of NSIS Initiator. This is mainly due to the fact that security protocols allow a differentiation between entities being hosts and users (based on the identities used). Since the NSIS Initiator as used in [5] also allows to act on behalf of various entities including a network it is reasonable to distinguish between these identities. The term access network is used for networks to which a mobile node is attached. Other terms often used in this context are foreign or visited network. The missing direct trust relationship between the mobile node and the access network complicates authentication and key agreement. Usually AAA protocols (like Radius or Diameter) are used to provide the initial authentication and key establishment. These protocols take advantage of the AAA infrastructure (AAAL, AAAH, Broker, etc.) and trust relationships between the access network and the users home network. This trust relationship is usually based on some sort of business contract. The trust relationship between the Tschofenig Informational - Expires April 2003 5 NSIS Threats October 2002 two networks is considered to be symmetric (network A trusts network B and vice versa) whereas the dynamically established trust relationship between the mobile node and the access network is often asymmetric. In today's network a mobile node has to trust the access network with regard to collection and processing of accounting data. The access network usually does not trust attached end-hosts. The term security association is used to describe established security-relevant data structure between two entities. This data structure consists of keys, algorithms including their parameters, values used for replay protection etc. Using this information two (or more) nodes are able to protect signaling messages.2 Threat Scenarios
This section provides threat scenarios that are applicable to signaling protocols.2.1 Lack of Authentication and Man-in-the-Middle Attacks
This section describes man-in-the-middle attacks of the following type: 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-middle adversary is able to modify signaling messages to mount DoS attacks. The signaling message initiator wrongly believes 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: a) 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 other peer of the communication is unknown or because of misbelieved trust relationships in parts of the network. If one of the communication endpoints is unknown then for some security protocols it is not possible or difficult to select the appropriate security association. Sometimes network administrators refuse to consider security protection of intra-domain signaling messages. Such a configuration would then allow an adversary at a compromised node to cause security problems. Even if there was no intention that this compromised node actively participates in the signaling message exchange its interference cannot be prevented. b) Unilateral Authentication In case of only unilateral authentication the NI is not able to discover the man-in-the-middle adversary. Although authentication of signaling message should take place between each peer participating in the protocol operation special focus is given to the communication in the end host and the access network. Tschofenig Informational - Expires April 2003 6 NSIS Threats October 2002 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. 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.2.2 Missing Authorization
Authentication as described in Section 2.1 is a very important step for providing the foundation for authorization and accounting. Unlike some other protocols where authorization can be verified without huge difficulties NSIS protocols might experience some difficulties. First there is the question what authorization means in the context of NSIS signaling and particularly for quality of service and middlebox communication. 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 representing authorization information if it has to be shared between a number of network domains. Currently the above-mentioned issues have not been appropriately addressed and might cause obstacles for deployment. In a 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 with which some sort of business relationship (directly or indirectly) is available.2.3 Missing Cost Control
This type of threat addresses a deployment problem of QoS signaling in a real-world environment. It is not a particular attack. A large number of service providers with complex roaming agreements create a non-transparent cost-structure. Using AAA protocols in a subscription-based scenario. In a traditional subscription-based Tschofenig Informational - Expires April 2003 7 NSIS Threats October 2002 scenario users are registered with their home networks and use this trust relationship to dynamically establish other security associations. In these scenarios users do not learn the identity of the access network as part of a regular message exchange. The user is therefore only authenticated to the home network (and hopefully vice versa). The identity of the access network is possibly not revealed. When issuing a reservation request to an entity in the access network the end-user does not know the cost of such a reservation. Furthermore due to mobility and route changes along the path the costs for an end-to-end QoS reservation might not be transparent or unacceptable. Today there is no protocol available which allows users to communicate cost limits, to request costs for network resources or to learn the currently accumulated costs for a particular reservation. Especially in mobility environments where many networks might be contacted in a short period of time cost control is even more complicated. Some proposals which try to merge mobility protocols with QoS signaling probe the access network (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. Hence the user might not be unable to refuse the more expensive service provider. To allow a user to choose different providers might be required not only because of the availability of different access technologies (either using a WLAN card to access the local network or to use UMTS/UTRAN based technology) 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 a quality of service signaling protocol itself some interactions might be required. Note that payment issues should be discussed independently of cost-control since other mechanisms are required to negotiate which involved party actually has to pay the costs (and how).2.4 Eavesdropping and Traffic Analysis
This section covers two threats: The first is related to privacy concerns whereas the second addresses problems caused by weak authentication mechanisms and the increased risk of eavesdropping on the wireless link in absence of appropriate confidentiality protection. The first threat case covers adversaries which are able to eavesdrop signaling messages but are unable to actively participate in the QoS signaling (i.e. passive adversary). The collected signaling packets may serve for the purpose of traffic analysis or to later mount replay attacks as described in the next section. By eavesdropping an adversary might violate a user's privacy preference. Especially QoS Tschofenig Informational - Expires April 2003 8 NSIS Threats October 2002 signaling messages provide information that may be interesting for an adversary since the messages reveal user and/or application identities, policy information, information about the desired QoS reservation, etc. The information gathered by an adversary can be used to learn communication patterns of users requesting resources (QoS, firewall, NAT, etc.). An adversary might be able to use the signaling protocol to discover the topology of a network (e.g. using record route). Additionally it might be possible to obtain diagnostic information usually used for network monitoring and administration. Other options might allow an adversary to route signaling messages specifically along a particular route similar to source routing. The second threat case addresses weak authentication mechanisms whereby information transmitted within the QoS signaling protocol may leak passwords and may allow offline dictionary attacks. This threat is not specific to QoS signaling protocols but may also be applicable and countermeasures must be taken.2.5 Adversary being able to replay signaling messages
This threat scenario covers the case where an adversary eavesdrops and collects 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 in a different way û e.g. cut and paste attacks). Without proper replay protection an adversary might be able to mount denial and/or theft of service attacks. A more difficult attack that may cause problems even in case of replay protection requires the adversary to crash a NSIS aware node to loose state information (sequence numbers, security associations, etc.) and to be able to replay old signaling messages. Additionally it should be mentioned that the interaction between different protocols based on authorization tokens requires some care. Using such an authorization token it is possible to link state information between different protocols. Returning an authorization token to the end host might allow an adversary to steal resources without proper protection of the token delivery or without proper verification of the hopefully protected content of the token. The functionality and structure of such an authorization token for RSVP is described in [3] and in [4].2.6 Identity Spoofing
The following paragraph gives an example of an adversary using identity spoofing: 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. Using unprotected signaling messages Eve may experience no particular problems in succeeding. This attack can be classified as theft of service. Tschofenig Informational - Expires April 2003 9 NSIS Threats October 2002 If a signaling message is properly protected the adversary is unlike to succeed. A non-traditional identity spoofing attack exploits flow classification (required for QoS and Midcom specific signaling protocols). Some identifiers such as IP addresses, transport protocol identifiers, port numbers, flow labels [6, 7] and others are communicated in these protocols and represent an attractive target for an adversary. Modification of these flow identifiers cause quality of service reservations or policy rules at middleboxes to be either ineffective or beneficial for adversaries. Additional concerns might occur if end hosts perform traffic marking (for example by using a DSCP). 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 [11]. Related security issues (for example denial of service attacks) are described in Section 6.1 of the same document. The following paragraph describes a possible threat caused by identity spoofing of transmitted data traffic. The spoofed identity is thereby the source IP addresses. Assume that 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 subject of a DoS attack by and by the adversary. 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.2.7 Adversary being able to inject/modify messages
Tschofenig Informational - Expires April 2003 10 NSIS Threats October 2002 The next type of threat addresses an integrity violations: An adversary modifies signaling messages (e.g. by acting as a man-in- the-middle) to cause an unexpected network behavior with a bogus signaling message. Possible actions are reordering, delaying, dropping, injecting and modifying. An adversary may inject a signaling message requesting a large amount of resources (using a different user identity). If granted it causes other user's resource-request not to be successful and a different initiator (for example a user) to pay for the QoS reservation. This attack is only successful in absence of signaling message protection.2.8 Missing Non-Repudiation
Repudiation in this context refers to a problem where one party later denies to have made a reservation. This issue comes in two flavors: From 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 users 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) then it might impact protocol design.2.9 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 edge routers. We assume that edge routers have the responsibility to perform cryptographic processing (authentication, integrity verification, replay protection, authorization, etc.). Depending on the protocol functionality every NSIS aware router should be able to issue signaling messages. 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. Note that this problem is not only restricted to QoS signaling protocols. 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 proper protection. An adversary with full Tschofenig Informational - Expires April 2003 11 NSIS Threats October 2002 access to the edge router is then also able to retrieve security associations to secure signaling messages. Note that even non-peer- to-peer security protection might not be able to fully prevent this problem. Thus the edge router is a critical component that requires strong security protection. Strong security policy applied at edge routers does not imply that intra-domain routers do not need to cryptographically verify signaling messages. If the chain-of-trust principle is deployed then the security protection of the 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.2.10 Denial of Service in a two phase reservation
This threat tries to address potential denial of service attacks when the reservation setup is split into two phases path discovery/path pinning and reservation (as for example used in a receiver-initiated reservation). 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 request (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 are already consumed along the path for various processing tasks including path pinning.2.11 Denial of Service with a bogus signaling request
With a resource reservation request received at a network element (for example by the first NSIS aware router) processing is required for authentication and authorization. Processing by other nodes including policy servers, LDAP servers, etc. is also possible depending on the network infrastructure. Verification requires cryptographic computations, state maintenance, setting timers, transmitting messages and other processing actions. If an adversary is able to transmit a large number of reservation request with bogus credentials (and assuming that the verification is expensive in terms of resource consumption) then the verifying node may not be able to process further reservation messages by legitimate users. This assumes that verification is expensive (especially cryptographic computations).2.12 DoS Attack at the 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 Tschofenig Informational - Expires April 2003 12 NSIS Threats October 2002 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.2.13 Disclosing the networking structure
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.). A requirement of not disclosing a network structure might conflict with another requirement to provide means for automatically discovering NSIS aware nodes and to provide diagnostic facilities.2.14 Modification of Session State Information
An adversary might be able to modify an existing reservation which has already been established within the network as a result of a previous signaling message exchange. Hence it might be necessary to provide assurance for a secure binding between an owner of the established session state and the session state information distributed at various entities along the data path. The state information created at nodes along the path created by signaling messages is the uniquely identified Session ID as described in [5]. Whenever a signaling message has to refer to existing state information (for a refresh, modify or delete operation) then the existing session identifier is used. Hence there is a requirement that it must not be possible for someone to use an existing session identifier to modify state information of someone else. An adversary might have learned a session identifier by eavesdropping the signaling messages. Especially in a roaming scenario where a mobile node retransmits signaling messages from a different point of attachment it must be assured that the routers along the path are able to verify whether the entity transmitting the signaling messages is allowed to modify the established state. 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 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. Tschofenig Informational - Expires April 2003 13 NSIS Threats October 20022.15 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.3 Security Considerations
This entire memo discusses security issues in the context of NSIS. Some additional threats are applicable for a framework where an NSIS protocol is used. Some other relevant threats especially for end hosts to access network communication described in [2].4 Open Issues
A future version of this draft will experience a minor restructuring to add deployment threats, to separation between attacks during security association setup and attacks which aim to attack the signaling messages itself, middlebox communication specific threats and a discussion of threats applicable to the transport level vs. the application level (according to a 2-level-architecture).5 References
[1] Brunner, M., "Requirements for QoS Signaling Protocols", <draft-ietf-nsis-req-04.txt>, (work in progress), August, 2002. [2] Kempf, J., Nordmark, E.: ôThreat Analysis for IPv6 Public Multi-Access Linksö, <draft-kempf-ipng-netaccess-threats-02.txt>, (work in progress), December, 2002. [3] Hamer, L-N., Gage, B., Broda, M., Kosinski, B., Shieh, H.: ôSession Authorization for RSVPö, <draft-ietf-rap-rsvp-authsession- 04.txt>, (work in progress), October, 2002. [4] Hamer, L-N., Gage, B., Shieh, H.: ôFramework for session set-up with media authorizationö, <draft-ietf-rap-session-auth-04.txt>, (work in progress), June, 2002. [5] Freytsis, I., Hancock, R., Karagiannis, G., Loughney, J., Van den Bosch, S.: ôNext Steps in Signaling: A Framework Proposalö, <draft-ietf-nsis-fw-00.txt>, (work in progress), October, 2002. Tschofenig Informational - Expires April 2003 14 NSIS Threats October 2002 [6] Partridge, C.: "Using the Flow Label Field in IPv6", RFC 1809, June, 1995. [7] Rajahalme, J., Conta, A., Carpenter, B., Deering, S.: "IPv6 Flow Label Specification", <draft-ietf-ipv6-flow-label-02.txt>, (work in progress), September, 2002. [8] Fu, S., Kappler, C., Tschofenig, H.: "Analysis on RSVP Regarding Multicast", <draft-fu-rsvp-multicast-analysis-01.txt>, (work in progress), October, 2002. [9] Tschofenig, H.: "RSVP Security Properties", <draft-tschofenig- rsvp-sec-properties-01.txt>, (work in progress), October, 2002. [10] de Meer, H., Feher, G., Blefari-Melazzi, N., Tschofenig, H., Karagiannis, G., Partain, D., Rexhepi, V., Westberg, L.: "Analysis of Existing QoS Solutions", <draft-demeer-nsis-analysis-03.txt>, (work in progress), October, 2002. [11] Terzis, A., Braden, B., Vincent, S., Zhang, L.: "RSVP Diagnostic Messages", RFC 2745, January, 2000.6 Acknowledgments
I 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 me an extensive list of comments and provided information on additional threats.7 Author's Addresses
Hannes Tschofenig Siemens AG Otto-Hahn-Ring 681739 Munich
Germany Email: Hannes.Tschofenig@siemens.com Tschofenig Informational - Expires April 2003 15
Datatracker
draft-ietf-nsis-threats-00
This is an older version of an Internet-Draft that was ultimately published as RFC 4081.
