draft-ietf-nsis-threats-06.txt   rfc4081.txt 
NSIS Working Group H. Tschofenig Network Working Group H. Tschofenig
Internet-Draft D. Kroeselberg Request for Comments: 4081 D. Kroeselberg
Expires: April 24, 2005 Siemens Category: Informational Siemens
October 24, 2004 June 2005
Security Threats for NSIS
draft-ietf-nsis-threats-06.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 Security Threats for Next Steps in Signaling (NSIS)
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 24, 2005. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This threats document provides a detailed analysis of the security This threats document provides a detailed analysis of the security
threats relevant to the NSIS protocol suite. It calls attention to, threats relevant to the Next Steps in Signaling (NSIS) protocol
and helps with the understanding of, various security considerations suite. It calls attention to, and helps with the understanding of,
in the NSIS Requirements, Framework, and Protocol proposals. This various security considerations in the NSIS Requirements, Framework,
document does not describe vulnerabilities of specific parts of the and Protocol proposals. This document does not describe
NSIS protocol suite. vulnerabilities of specific parts of the NSIS protocol suite.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Communications Models . . . . . . . . . . . . . . . . . . . 4 2. Communications Models ...........................................3
3. Generic Threats . . . . . . . . . . . . . . . . . . . . . . 9 3. Generic Threats .................................................7
3.1 Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 9 3.1. Man-in-the-Middle Attacks ..................................8
3.2 Replay of Signaling Messages . . . . . . . . . . . . . . . 13 3.2. Replay of Signaling Messages ..............................11
3.3 Injecting or Modifying Messages . . . . . . . . . . . . . 13 3.3. Injecting or Modifying Messages ...........................11
3.4 Insecure Parameter Exchange and Negotiation . . . . . . . 13 3.4. Insecure Parameter Exchange and Negotiation ...............12
4. NSIS-Specific Threat Scenarios . . . . . . . . . . . . . . . 15 4. NSIS-Specific Threat Scenarios .................................12
4.1 Threats during NSIS SA Usage . . . . . . . . . . . . . . . 15 4.1. Threats during NSIS SA Usage ..............................13
4.2 Flooding . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Flooding ..................................................13
4.3 Eavesdropping and Traffic Analysis . . . . . . . . . . . . 17 4.3. Eavesdropping and Traffic Analysis ........................15
4.4 Identity Spoofing . . . . . . . . . . . . . . . . . . . . 17 4.4. Identity Spoofing .........................................15
4.5 Unprotected Authorization Information . . . . . . . . . . 19 4.5. Unprotected Authorization Information .....................17
4.6 Missing Non-Repudiation . . . . . . . . . . . . . . . . . 20 4.6. Missing Non-Repudiation ...................................18
4.7 Malicious NSIS Entity . . . . . . . . . . . . . . . . . . 21 4.7. Malicious NSIS Entity .....................................19
4.8 Denial of Service Attacks . . . . . . . . . . . . . . . . 22 4.8. Denial of Service Attacks .................................20
4.9 Disclosing the Network Topology . . . . . . . . . . . . . 23 4.9. Disclosing the Network Topology ...........................21
4.10 Unprotected Session or Reservation Ownership . . . . . . 23 4.10. Unprotected Session or Reservation Ownership .............21
4.11 Attacks against the NTLP . . . . . . . . . . . . . . . . 25 4.11. Attacks against the NTLP .................................23
5. Security Considerations . . . . . . . . . . . . . . . . . . 26 5. Security Considerations ........................................23
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 6. Contributors ...................................................24
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 28 7. Acknowledgements ...............................................24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. References .....................................................25
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 29 8.1. Normative References ......................................25
8.2 Informative References . . . . . . . . . . . . . . . . . . . 29 8.2. Informative References ....................................25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . 32
1. Introduction 1. Introduction
Whenever a new protocol is developed or existing protocols are Whenever a new protocol is developed or existing protocols are
modified, threats to their security should be evaluated. To address modified, threats to their security should be evaluated. To address
security in the NSIS working group, a number of steps have been security in the NSIS working group, a number of steps have been
taken: taken:
NSIS Analysis Activities (see [I-D.ietf-nsis-rsvp-sec-properties] NSIS Analysis Activities (see [RSVP-SEC] and [SIG-ANAL])
and [I-D.ietf-nsis-signalling-analysis])
Security Threats for NSIS Security Threats for NSIS
NSIS Requirements (see [RFC3726]) NSIS Requirements (see [RFC3726])
NSIS Framework (see [I-D.ietf-nsis-fw]) NSIS Framework (see [RFC4080])
NSIS Protocol Suite (see GIMPS [I-D.ietf-nsis-ntlp], NAT/Firewall NSIS Protocol Suite (see GIMPS [GIMPS], NAT/Firewall NSLP
NSLP [I-D.ietf-nsis-nslp-natfw] and QoS NSLP [NATFW-NSLP] and QoS NSLP [QOS-NSLP])
[I-D.ietf-nsis-qos-nslp])
This document identifies the basic security threats that need to be This document identifies the basic security threats that need to be
addressed during the design of the NSIS protocol suite. Even if the addressed during the design of the NSIS protocol suite. Even if the
base protocol is secure, certain extensions may cause problems when base protocol is secure, certain extensions may cause problems when
used in a particular environment. used in a particular environment.
This document cannot provide detailed threats for all possible NSIS This document cannot provide detailed threats for all possible NSIS
Signaling Layer Protocols (NSLPs). QoS [I-D.ietf-nsis-qos-nslp], Signaling Layer Protocols (NSLPs). QoS [QOS-NSLP], NAT/Firewall
NAT/Firewall and other NSLP documents need to provide a description [NATFW-NSLP], and other NSLP documents need to provide a description
of their trust models and a threat assessment for their specific of their trust models and a threat assessment for their specific
application domain. This document aims to provide some help for the application domain. This document aims to provide some help for the
subsequent design of the NSIS protocol suite. Investigations of subsequent design of the NSIS protocol suite. Investigations of
security threats in a specifc architecture or context are outside the security threats in a specific architecture or context are outside
scope of this document. the scope of this document.
We use the NSIS terms defined in [RFC3726] and in [I-D.ietf-nsis-fw]. We use the NSIS terms defined in [RFC3726] and in [RFC4080].
2. Communications Models 2. Communications Models
The NSIS suite of protocols is envisioned to support various The NSIS suite of protocols is envisioned to support various
signaling applications that need to install and/or manipulate state signaling applications that need to install and/or manipulate state
at nodes along the data flow path through the network. As such, the at nodes along the data flow path through the network. As such, the
NSIS protocol suite involves the communication between different NSIS protocol suite involves the communication between different
entities. entities.
This section offers terminology for common communication models, This section offers terminology for common communication models that
which are relevant to securing the NSIS protocol suite. are relevant to securing the NSIS protocol suite.
An abstract network topology with its administrative domains is shown An abstract network topology with its administrative domains is shown
in Figure 1 and in Figure 2 the relationship between NSIS entities in Figure 1, and in Figure 2 the relationship between NSIS entities
along the path is illustrated. For illustrative reasons only along the path is shown. For illustrative reasons, only end-to-end
end-to-end NSIS signaling is depicted but it might be used in other NSIS signaling is depicted, yet it might be used in other variations
variations as well. Signaling can start at any place and might as well. Signaling can start at any place and might terminate at any
terminate at any other place within the network. Depending on the other place within the network. Depending on the trust relationship
trust relationship between NSIS entities and the traversed network between NSIS entities and the traversed network parts, different
parts different security problems arise. security problems arise.
The notion of trust and trust relationship used in this document is The notion of trust and trust relationship used in this document is
informal and can be best captured by the definition provided in informal and can best be captured by the definition provided in
Section 1.1 of [RFC3756]. For completeness we include the definition Section 1.1 of [RFC3756]. For completeness we include the definition
of a trust relationship which denotes a mutual a priori relationship of a trust relationship, which denotes a mutual a priori relationship
between the involved organizations or parties where the parties between the involved organizations or parties wherein the parties
believe that the other parties will behave correctly even in the believe that the other parties will behave correctly even in the
future. future.
An important observation for NSIS is that a certain degree of trust An important observation for NSIS is that a certain degree of trust
has to be placed into intermediate NSIS nodes along the path between has to be placed into intermediate NSIS nodes along the path between
an NSIS Initiator and an NSIS Responder, specifically that they an NSIS Initiator and an NSIS Responder, specifically so that they
perform message processing and take the necessary actions. A perform message processing and take the necessary actions. A
complete lack of trust between any of the participating entities will complete lack of trust between any of the participating entities will
cause NSIS signaling to fail. cause NSIS signaling to fail.
Please note that it is not possible to completely describe a trust Note that it is not possible to describe a trust model completely
model without considering the details and behavior of the NTLP, the without considering the details and behavior of the NTLP, the NSLP
NSLP (e.g., QoS NSLP) and the deployment environment. For example, (e.g., QoS NSLP), and the deployment environment. For example,
securing the communication between an end host (which acts as the securing the communication between an end host (which acts as the
NSIS Initiator) and the first NSIS node (which might be in the NSIS Initiator) and the first NSIS node (which might be in the
attached network or even a number of networks away) is impacted by attached network or even a number of networks away) is impacted by
the trust relationships between these entities. In a corporate the trust relationships between these entities. In a corporate
network environment a stronger degree of trust typically exists than network environment, a stronger degree of trust typically exists than
in an unmanaged network. in an unmanaged network.
Figure 1 introduces convenient abbreviations for network parts with Figure 1 introduces convenient abbreviations for network parts with
similar properties: first-peer, last-peer, intra-domain, or similar properties: first-peer, last-peer, intra-domain, or
inter-domain. inter-domain.
+------------------+ +---------------+ +------------------+ +------------------+ +---------------+ +------------------+
| | | | | | | | | | | |
| Administrative | | Intermediate | | Administrative | | Administrative | | Intermediate | | Administrative |
| Domain A | | Domains | | Domain B | | Domain A | | Domains | | Domain B |
skipping to change at page 5, line 41 skipping to change at page 4, line 41
The end-to-end communication scenario depicted in Figure 1 The end-to-end communication scenario depicted in Figure 1
includes the communication between the end hosts and their nearest includes the communication between the end hosts and their nearest
NSIS hops. "First-peer communications" refers to the peer-to-peer NSIS hops. "First-peer communications" refers to the peer-to-peer
interaction between a signaling message originator, the NSIS interaction between a signaling message originator, the NSIS
Initiator (NI), and the first NSIS-aware entity along the path. Initiator (NI), and the first NSIS-aware entity along the path.
This "first-peer communications" commonly comes with specific This "first-peer communications" commonly comes with specific
security requirements that are especially important for addressing security requirements that are especially important for addressing
security issues between the end host (and a user) and the network security issues between the end host (and a user) and the network
it is attached to. it is attached to.
To illustrate this, in roaming environments it is difficult to To illustrate this, in roaming environments, it is difficult to
assume the existence of a pre-established security association assume the existence of a pre-established security association
directly available for NSIS peers involved in first-peer directly available for NSIS peers involved in first-peer
communications, because these peers cannot be assumed to have any communications, because these peers cannot be assumed to have any
pre-existing relationship with each other. For enterprise pre-existing relationship with each other. In contrast, in
networks, in contrast, the situation is different. Usually there enterprise networks usually there is a fairly strong
is a fairly strong (pre-established) trust relationship between (pre-established) trust relationship between the peers.
the peers. Enterprise network administrators usually have some Enterprise network administrators usually have some degree of
degree of freedom to select the appropriate security protection freedom to select the appropriate security protection and to
and to enforce it. The choice of selecting a security mechanism enforce it. The choice of selecting a security mechanism is
is therefore often influenced by the already available therefore often influenced by the infrastructure already
infrastructure, and per-session negotiation of security mechanisms available, and per-session negotiation of security mechanisms is
is often not required (which, in contrast, is required in a often not required (although, in contrast, it is required in a
roaming environment). roaming environment).
Last-Peer communication is a variation of First-Peer communication Last-Peer communication is a variation of First-Peer communication
where the roles are reversed. in which the roles are reversed.
Intra-Domain Communication: Intra-Domain Communication:
After verification of the NSIS signaling message at the border of After verification of the NSIS signaling message at the border of
an administrative domain, an NSIS signaling message traverses the an administrative domain, an NSIS signaling message traverses the
network within the same administrative domain to which the first network within the same administrative domain to which the first
peer belongs. It might not be necessary to repeat the peer belongs. It might not be necessary to repeat the
authorization procedure of the NSIS initiator again at every NSIS authorization procedure of the NSIS initiator again at every NSIS
node within this domain. Key management within the administrative node within this domain. Key management within the administrative
domain might also be simpler. domain might also be simpler.
Security protection is still required to prevent threats by Security protection is still required to prevent threats by
non-NSIS nodes in this network. non-NSIS nodes in this network.
Inter-Domain Communication: Inter-Domain Communication:
Inter-Domain communication deals with the interaction between Inter-Domain communication deals with the interaction between
administrative domains. For some NSLPs (for example QoS NSLP) administrative domains. For some NSLPs (for example, QoS NSLP),
this interaction is likely to take place between neighboring this interaction is likely to take place between neighboring
domains whereas in other NSLPs (such as the NAT/Firewall NSLP) the domains, whereas in other NSLPs (such as the NAT/Firewall NSLP),
core network is usually not involved. the core network is usually not involved.
If signaling messages are conveyed transparently in the core If signaling messages are conveyed transparently in the core
network (i.e., they are neither intercepted nor processed in the network (i.e., if they are neither intercepted nor processed in
core network), then the signaling message communications the core network), then the signaling message communications
effectively takes place between access networks. This might place effectively takes place between access networks. This might place
a burden on authorization handling and on the key management a burden on authorization handling and on the key management
infrastructure required between these access networks, which might infrastructure required between these access networks, which might
not know of each other in advance. not know of each other in advance.
To refine the above differentiation based on the network parts that To refine the above differentiation based on the network parts that
NSIS signaling may traverse, we subsequently consider relationships NSIS signaling may traverse, we subsequently consider relationships
between involved entities. Since a number of NSIS nodes might between involved entities. Because a number of NSIS nodes might
actively participate in a specific protocol exchange, a larger number actively participate in a specific protocol exchange, a larger number
of possible relationships need to be analyzed than in other of possible relationships need to be analyzed than in other
protocols. Figure 2 illustrates possible relationships between the protocols. Figure 2 illustrates possible relationships between the
entities involved in the NSIS protocol suite. entities involved in the NSIS protocol suite.
**************************************** ****************************************
* * * *
+----+-----+ +----------+ +----+-----+ +----+-----+ +----------+ +----+-----+
+-----+ NSIS +-------+ NSIS +--------+ NSIS +-----+ +-----+ NSIS +-------+ NSIS +--------+ NSIS +-----+
| | Node 1 | | Node 2 | | Node 3 | | | | Node 1 | | Node 2 | | Node 3 | |
skipping to change at page 7, line 39 skipping to change at page 6, line 39
The scenario in which one NSIS entity involved is an end-entity The scenario in which one NSIS entity involved is an end-entity
(Initiator or Responder) and the other entity is any intermediate (Initiator or Responder) and the other entity is any intermediate
hop other than the immediately adjacent peer is typically called hop other than the immediately adjacent peer is typically called
the end-to-middle scenario (see Figure 2). A motivation for the end-to-middle scenario (see Figure 2). A motivation for
including this scenario can, for example, be found in SIP including this scenario can, for example, be found in SIP
[RFC3261]. [RFC3261].
An example of end-to-middle interaction might be an explicit An example of end-to-middle interaction might be an explicit
authorization from the NSIS Initiator to some intermediate node. authorization from the NSIS Initiator to some intermediate node.
Threats specific to this scenario may be introduced by some Threats specific to this scenario may be introduced by some
intermediate NSIS hops which are not allowed to eavesdrop or intermediate NSIS hops that are not allowed to eavesdrop or modify
modify certain objects. certain objects.
Middle-to-Middle Communications: Middle-to-Middle Communications:
Middle-to-middle communication refers to the exchange of Middle-to-middle communication refers to the exchange of
information between two non-neighboring NSIS nodes along the path. information between two non-neighboring NSIS nodes along the path.
Intermediate NSIS hops may have to deal with specific security Intermediate NSIS hops may have to deal with specific security
threats, which do not directly involve the NSIS Initiator or the threats that do not involve the NSIS Initiator or the NSIS
NSIS Responder. Responder directly.
End-to-End Communications: End-to-End Communications:
NSIS aims to signal information from an Initiator to some NSIS NSIS aims to signal information from an Initiator to some NSIS
nodes along the path to a data receiver. In case of end-to-end nodes along the path to a data receiver. In the case of
NSIS signaling the last node is the NSIS Responder as the data end-to-end NSIS signaling, the last node is the NSIS Responder, as
receiver. The NSIS protocol suite is not an end-to-end protocol it is the data receiver. The NSIS protocol suite is not an
used to exchange information purely between end hosts. end-to-end protocol used to exchange information purely between
end hosts.
Typically, it is not required to cryptographically protect NSIS Typically, it is not required to protect NSIS messages
messages between the NSIS Initiator and the NSIS Responder. cryptographically between the NSIS Initiator and the NSIS
Protecting the entire signaling message end-to-end is not feasible Responder. Protecting the entire signaling message end-to-end
since intermediate NSIS nodes need to add, inspect, modify or might not be feasible since intermediate NSIS nodes need to add,
delete objects from the signaling message. inspect, modify, or delete objects from the signaling message.
3. Generic Threats 3. Generic Threats
This section provides scenarios of threats that are applicable to This section provides scenarios of threats that are applicable to
signaling protocols in general. Note that some of these scenarios signaling protocols in general. Note that some of these scenarios
use the term user instead of NSIS Initiator. This is mainly because use the term "user" instead of "NSIS Initiator". This is mainly
security protocols allow differentiation between entities as hosts because security protocols allow differentiation between entities
and as users (based on the identifiers used). that are hosts and those that are users (based on the identifiers
used).
For the following subsections, we use the general distinction into For the following subsections, we use the general distinction in two
two cases in which attacks may occur. These are according to the cases in which attacks may occur. These are according to the
separate steps, or phases, normally encountered when applying separate steps, or phases, normally encountered when applying
protocol security (with, e.g., IPsec, TLS, Kerberos, or SSH). protocol security (with, e.g., IPsec, TLS, Kerberos, or SSH).
Therefore, this section starts with a brief motivation for this Therefore, this section starts by briefly describing a motivation for
separation. this separation.
Security protection of protocols is often separated into two steps. Security protection of protocols is often separated into two steps.
The first step provides primarily entity authentication and key The first step primarily provides entity authentication and key
establishment (which result in a persistent state often called a establishment (which result in a persistent state often called a
security association), whereas the second step provides message security association), whereas the second step provides message
protection (some combination of data origin authentication, data protection (some combination of data origin authentication, data
integrity, confidentiality, and replay protection) using the integrity, confidentiality, and replay protection) using the
previously established security association. The first step tends to previously established security association. The first step tends to
be more expensive than the second, which is the main reason for the be more expensive than the second, which is the main reason for the
separation. If messages are transmitted infrequently, then these two separation. If messages are transmitted infrequently, then these two
steps may be collapsed into a single and usually rather costly one. steps may be collapsed into a single and usually rather costly one.
One such example is e-mail protection via S/MIME. The two steps may One such example is e-mail protection via S/MIME. The two steps may
be tightly bound into a single protocol, as in TLS, or defined in be tightly bound into a single protocol, as in TLS, or defined in
separate protocols, as with IKE and IPsec. We use this separation to separate protocols, as with IKE and IPsec. We use this separation to
cover the different threats in more detail. cover the different threats in more detail.
3.1 Man-in-the-Middle Attacks 3.1. Man-in-the-Middle Attacks
This section describes both security threats that exist if two peers This section describes both security threats that exist if two peers
do not already share a security association or do not use security do not already share a security association or do not use security
mechanisms at all, and threats that are applicable when a security mechanisms at all, and threats that are applicable when a security
association is already established. association is already established.
Attacks during NSIS SA Establishment: Attacks during NSIS SA Establishment:
While establishing a security association, an adversary fools the While establishing a security association, an adversary fools the
signaling message Initiator with respect to the entity to which it signaling message Initiator with respect to the entity to which it
has to authenticate. The Initiator authenticates to the has to authenticate. The Initiator authenticates to the man-in-
man-in-the-middle adversary, who is then able to modify signaling the-middle adversary, who is then able to modify signaling
messages to mount DoS attacks or steal services that get billed to messages to mount DoS attacks or to steal services that get billed
the Initiator. In addition, it may be able to terminate the to the Initiator. In addition, the adversary may be able to
Initiator's NSIS messages and inject messages to a peer itself, terminate the Initiator's NSIS messages and to inject messages to
therefore acting as the peer to the Initiator and as the Initiator a peer itself, thereby acting as the peer to the Initiator and as
to the peer. This results in the Initiator wrongly believing that the Initiator to the peer. As a result, the Initiator wrongly
it is talking to the "real" network, whereas it is actually believes that it is talking to the "real" network, whereas it is
attached to an adversary. For this attack to be successful, actually attached to an adversary. For this attack to be
pre-conditions have to hold which are described in the following successful, pre-conditions that are described in the following
three cases: three cases have to hold:
Missing Authentication: Missing Authentication:
In the first case, this threat can be carried out because of In the first case, this threat can be carried out because of
missing authentication between neighboring peers: without missing authentication between neighboring peers: without
authentication a NI, NR, or NF is unable to detect an authentication, an NI, NR, or NF is unable to detect an
adversary. However, in some practical cases authentication adversary. However, in some practical cases, authentication
might be difficult to accomplish, either because the next peer might be difficult to accomplish, either because the next peer
is unknown, because of misbelieved trust relationships in parts is unknown, because there are misbelieved trust relationships
of the network, or because of the inability to establish proper in parts of the network, or because of the inability to
security protection (inter-domain signaling messages, dynamic establish proper security protection (inter-domain signaling
establishment of a security association, etc.). If one of the messages, dynamic establishment of a security association,
communicating endpoints is unknown, then for some security etc.). If one of the communicating endpoints is unknown, then
mechanisms it is either impossible, or impractical to apply for some security mechanisms it is either impossible or
appropriate security protection. Sometimes network impractical to apply appropriate security protection.
administrators use intra-domain signaling messages without Sometimes network administrators use intra-domain signaling
proper security. Such a configuration would then allow an messages without proper security. This configuration allows an
adversary on a compromised non-NSIS-aware node to interfere adversary on a compromised non-NSIS-aware node to interfere
with nodes running an NSIS signaling protocol. Note that this with nodes running an NSIS signaling protocol. Note that this
type of threat goes beyond those caused by malicious NSIS nodes type of threat goes beyond those caused by malicious NSIS nodes
(described in Section 4.7). (described in Section 4.7).
Unilateral Authentication: Unilateral Authentication:
In the case of unilateral authentication, the NSIS entity that In the case of unilateral authentication, the NSIS entity that
does not authenticate its peer is unable to discover a does not authenticate its peer is unable to discover a man-in-
man-in-the-middle adversary. Although mutual authentication of the-middle adversary. Although mutual authentication of
signaling messages should take place between each peer signaling messages should take place between each peer
participating in the protocol operation, special attention is participating in the protocol operation, special attention is
given here to first-peer communications. Unilateral given here to first-peer communications. Unilateral
authentication between an end host and the first peer (just authentication between an end host and the first peer (just
authenticating the end host) is still common today, but it authenticating the end host) is still common today, but it
opens up many possibilities for man-in-the-middle attackers opens up many possibilities for man-in-the-middle attackers
impersonating either the end host or the (administrative domain impersonating either the end host or the (administrative domain
represented by the) first peer. represented by the) first peer.
Missing or unilateral authentication, as described above, is Missing or unilateral authentication, as described above, is
part of a general problem of network access with inadequate part of a general problem of network access with inadequate
authentication, and it should not be considered something authentication, and it should not be considered something
unique to the NSIS signaling protocol. Obviously, there is a unique to the NSIS signaling protocol. Obviously, there is a
strong need to correctly address this in a future NSIS protocol strong need to address this correctly in a future NSIS protocol
suite. The signaling protocols addressed by NSIS are different suite. The signaling protocols addressed by NSIS are different
from other protocols, in which only two entities are involved. from other protocols in which only two entities are involved.
Note that first-peer authentication is especially important, Note that first-peer authentication is especially important
because a security breach here could impact nodes beyond the because a security breach there could impact nodes beyond the
entities directly involved (or even beyond a local network). entities directly involved (or even beyond a local network).
Finally it should be noted that the signaling protocol should Finally, note that the signaling protocol should be considered
be considered as a peer-to-peer protocol, where the roles of a peer-to-peer protocol, wherein the roles of Initiator and
Initiator and Responder can be reversed at any time. Hence, Responder can be reversed at any time. Thus, unilateral
unilateral authentication is not particularly useful for such a authentication is not particularly useful for such a protocol.
protocol. However, there might be a need to have some form of However, some form of asymmetry might be needed in the
asymmetry in the authentication process, whereby one entity authentication process, whereby one entity uses an
uses a different authentication mechanism than the other one. authentication mechanism different from that of the other one.
As an example, the combination of symmetric and asymmetric As an example, the combination of symmetric and asymmetric
cryptography should be mentioned. cryptography should be mentioned.
Weak Authentication: Weak Authentication:
In this case, the threat can be carried out because of weak In the case of weak authentication, the threat can be carried
authentication mechanisms whereby information transmitted out because information transmitted during the NSIS SA
during the NSIS SA establishment process may leak passwords or establishment process may leak passwords or allow offline
allow offline dictionary attacks. This threat is applicable to dictionary attacks. This threat is applicable to NSIS for the
NSIS for the process of selecting certain security mechanisms. process of selecting certain security mechanisms.
Finally, we conclude a description of a man-in-the-middle attack Finally, we conclude with a description of a man-in-the-middle (MITM)
during the discovery phase. This attack benefits from the fact that attack during the discovery phase. This attack benefits from the
NSIS nodes are likely to be unaware of the network topology. fact that NSIS nodes are likely to be unaware of the network
Furthermore, an authorization problem might arise if an NSIS QoS NSLP topology. Furthermore, an authorization problem might arise if an
node pretends to be a NSIS NAT/Firewall specific node or vice versa. NSIS QoS NSLP node pretends to be an NSIS NAT/Firewall-specific node
or vice versa.
An adversary might want to inject a bogus reply message forcing the An adversary might inject a bogus reply message, forcing the
discovery message initiator to start a messaging association discovery message initiator to start a messaging association
establishment with either an adversary or with another NSIS node establishment with either an adversary or with another NSIS node that
which is not along the path. Figure 3 describes the attack in more is not along the path. Figure 3 describes the attack in more detail
detail for peer-to-peer addressed messages with a discovery for peer-to-peer addressed messages with a discovery mechanism. For
mechanism. For end-to-end addressed messages the attack is also end-to-end addressed messages, the attack is also applicable,
applicable particularly if the adversary is located along the path particularly if the adversary is located along the path and able to
and able to intercept the discovery message which traverses the intercept the discovery message that traverses the adversary. The
adversary. The man-in-the-middle adversary might redirect to another man-in-the-middle adversary might redirect to another legitimate NSIS
legimimate NSIS node. A malicious NSIS node can be detected with the node. A malicious NSIS node can be detected with the corresponding
corresponding security mechanisms but a legitimate NSIS node which is security mechanisms, but a legitimate NSIS node that is not the next
not the next NSIS node along the path cannot be detected without NSIS node along the path cannot be detected without topology
having topology knowledge. knowledge.
+-----------+ Messaging Association +-----------+ Messaging Association
Message | Adversary | Establishment Message | Adversary | Establishment
Association +--->+ +<----------------+ Association +--->+ +<----------------+
Establish- | +----+------+ |(4) Establish- | +----+------+ |(4)
ment | IPx | | ment | IPx | |
(3)| |Discovery Reply v (3)| |Discovery Reply v
| | (IPx) +---+-------+ | | (IPx) +---+-------+
v | (2) | NSIS | v | (2) | NSIS |
+------+-----+ | /----------->+ Node B +-------- +------+-----+ | /----------->+ Node B +--------
| NSIS +<--+ / Discovery +-----------+ | NSIS +<--+ / Discovery +-----------+
| Node A +---------/ Request IPr | Node A +---------/ Request IPr
+------------+ (1) +------------+ (1)
IPi IPi
Figure 3: MITM Attack during the Discovery Exchange Figure 3: MITM Attack during the Discovery Exchange
This attack assumes that the adversary is able to eavesdrop the This attack assumes that the adversary is able to eavesdrop on the
initial discovery message sent by the sender of the discovery initial discovery message sent by the sender of the discovery
message. Furthermore, we assume that the discovery reply message by message. Furthermore, we assume that the discovery reply message by
the adversary returns to the discovery message initiator faster than the adversary returns to the discovery message initiator faster than
the real response. This represents some race condition the real response. This represents some race condition
characteristics if the next NSIS node is very close (in IP-hop terms) characteristics if the next NSIS node is very close (in IP-hop terms)
to the initiator. It should be noted that the process is to the initiator. Note that the problem is self-healing since the
self-healing since the discovery process is periodically discovery process is periodically repeated. If an adversary is
retransmitted. If an adversary is unable to mount this attack with unable to mount this attack with every discovery message, then the
every discovery message then the correct next NSIS node along the correct next NSIS node along the path will be discovered again. A
path will be discovered again. A ping-pong behavior might be the ping-pong behavior might be the consequence.
consequence.
As shown in message step (2) in Figure 3 the adversary returns a As shown in message step (2) in Figure 3, the adversary returns a
discovery reply message with its own IP address as the next NSIS discovery reply message with its own IP address as the next NSIS-
aware node along the path. Without any additional information the aware node along the path. Without any additional information, the
discovery message initiator has to trust this information. Then a discovery message initiator has to trust this information. Then a
messaging association is established with an entity at a given IP messaging association is established with an entity at a given IP
address IPx (i.e., with the adversary) in step (3). The adversary address IPx (i.e., with the adversary) in step (3). The adversary
then establishes a messaging association with a further NSIS node and then establishes a messaging association with a further NSIS node and
forwards the signaling message. Note that the adversary might just forwards the signaling message. Note that the adversary might just
modify the Disovery Reply message to force NSIS Node A to establish a modify the Discovery Reply message to force NSIS Node A to establish
messaging association with another NSIS node which is not along the a messaging association with another NSIS node that is not along the
path. This can then be exploited by the adversary. Particularly the path. This can then be exploited by the adversary. The interworking
interworking with NSIS unaware NATs might cause additional unexpected with NSIS-unaware NATs in particular might cause additional
problems. unexpected problems.
As a variant of this attack an adversary not able to eavesdrop As a variant of this attack, an adversary not able to eavesdrop on
transmitted discovery requests could flood a node with bogus transmitted discovery requests could flood a node with bogus
discovery reply messages. If the discovery message sender discovery reply messages. If the discovery message sender
accidentally accepts one of those bogus messages then a MITM-attack accidentally accepts one of those bogus messages, then a MITM attack
as described in Figure 3 is possible. as described in Figure 3 is possible.
3.2 Replay of Signaling Messages 3.2. Replay of Signaling Messages
This threat scenario covers the case in which an adversary eavesdrops This threat scenario covers the case in which an adversary
and collects signaling messages and replays them at a later time (or eavesdrops, collects signaling messages, and replays them at a later
at a different place, or uses parts of them at a different place or time (or at a different place, or uses parts of them at a different
in a different way, e.g., cut-and-paste attacks). Without proper place or in a different way; e.g., cut-and-paste attacks). Without
replay protection, an adversary might mount man-in-the-middle, denial proper replay protection, an adversary might mount man-in-the-middle,
of service, and theft of service attacks. denial of service, and theft of service attacks.
A more difficult attack that may cause problems even in case of A more difficult attack (that may cause problems even if there is
replay protection requires the adversary to crash an NSIS-aware node, replay protection) requires that the adversary crash an NSIS-aware
causing it to lose state information (sequence numbers, security node, causing it to lose state information (sequence numbers,
associations, etc.), and then be able to replay old signaling security associations, etc.), and then replay old signaling messages.
messages. This attack takes advantage of re-synchronization This attack takes advantage of re-synchronization deficiencies.
deficiencies.
3.3 Injecting or Modifying Messages 3.3. Injecting or Modifying Messages
This type of threat involves integrity violations, whereby an This type of threat involves integrity violations, whereby an
adversary modifies signaling messages (e.g., by acting as a adversary modifies signaling messages (e.g., by acting as a
man-in-the-middle) to cause unexpected network behavior. Possible man-in-the-middle) in order to cause unexpected network behavior.
actions an adversary might consider for its attack are reordering, Possible actions an adversary might consider for its attack are
delaying, dropping, injecting, truncating, and otherwise modifying reordering, delaying, dropping, injecting, truncating, and otherwise
messages. modifying messages.
An adversary may inject a signaling message requesting a large amount An adversary may inject a signaling message requesting a large amount
of resources (possibly using a different user's identity). Other of resources (possibly using a different user's identity). Other
resource requests may then be rejected. In combination with identity resource requests may then be rejected. In combination with identity
spoofing, it is also possible to carry out fraud. This attack is spoofing, it is possible to carry out fraud. This attack is only
only feasible in the absence of authentication and signaling message feasible in the absence of authentication and signaling message
protection. protection.
Some threats directly related to these are described in Section 4.4, Some threats directly related to these are described in Sections 4.4,
Section 4.7, and Section 4.8. 4.7, and 4.8.
3.4 Insecure Parameter Exchange and Negotiation 3.4. Insecure Parameter Exchange and Negotiation
First, protocols may be useful in a variety of scenarios with First, protocols may be useful in a variety of scenarios with
different security requirements. Second, different users (e.g., a different security requirements. Second, different users (e.g., a
university, a hospital, a commercial enterprise, or a government university, a hospital, a commercial enterprise, or a government
ministry) have inherently different security requirements. Third, ministry) have inherently different security requirements. Third,
different parts of a network (e.g., within a building, across a different parts of a network (e.g., within a building, across a
public carrier's network, or over a private microwave link) may need public carrier's network, or over a private microwave link) may need
different levels of protection. It is often difficult to meet these different levels of protection. It is often difficult to meet these
(sometimes conflicting) requirements with a single security mechanism (sometimes conflicting) requirements with a single security mechanism
or fixed set of security parameters, so often a selection of or fixed set of security parameters, so often a selection of
mechanisms and parameters is offered. Therefore, a protocol is mechanisms and parameters is offered. Therefore, a protocol is
required to agree on certain security mechanisms and parameters. An required to agree on certain security mechanisms and parameters. An
insecure parameter exchange or security negotiation protocol can help insecure parameter exchange or security negotiation protocol can help
an adversary mount a downgrading attack to force selection of weaker an adversary to mount a downgrading attack to force selection of
mechanisms than mutually desired. Hence, without binding the mechanisms weaker than those mutually desired. Thus, without binding
negotiation process to the legitimate parties and protecting it, an the negotiation process to the legitimate parties and protecting it,
NSIS protocol suite might be only as secure as the weakest mechanism an NSIS protocol suite might only be as secure as the weakest
provided (e.g., weak authentication), and the benefits of defining mechanism provided (e.g., weak authentication), and the benefits of
configuration parameters and a negotiation protocol are lost. defining configuration parameters and a negotiation protocol are
lost.
4. NSIS-Specific Threat Scenarios 4. NSIS-Specific Threat Scenarios
This section describes 11 threat scenarios in terms of attacks on and This section describes eleven threat scenarios in terms of attacks on
security deficiencies in the NSIS signaling protocol. A number of and security deficiencies in the NSIS signaling protocol. A number
security deficiencies might enable an attack. Fraud is an example of of security deficiencies might enable an attack. Fraud is an example
an attack that might be enabled by missing replay protection, missing of an attack that might be enabled by missing replay protection,
protection of authorization tokens, identity spoofing, missing missing protection of authorization tokens, identity spoofing,
authentication, and other deficiencies that help an adversary steal missing authentication, and other deficiencies that help an adversary
resources. Different threat scenarios based on deficiencies that steal resources. Different threat scenarios based on deficiencies
could enable an attack are addressed in this section. that could enable an attack are addressed in this section.
The threat scenarios are not independent. Some of them, e.g., denial The threat scenarios are not independent. Some of them (e.g., denial
of service, are well-established security terms and, as such, need to of service) are well-established security terms and, as such, need to
be addressed, but are often enabled by one or more deficiencies be addressed, but they are often enabled by one or more deficiencies
described under other scenarios. described under other scenarios.
4.1 Threats during NSIS SA Usage 4.1. Threats during NSIS SA Usage
Once a security association is established (and used) to protect Once a security association is established (and used) to protect
signaling messages, many basic attacks are prevented. However, a signaling messages, many basic attacks are prevented. However, a
malicious NSIS node is still able to perform various attacks as malicious NSIS node is still able to perform various attacks as
described in Section 4.7. Replay attacks may be possible when an described in Section 4.7. Replay attacks may be possible when an
NSIS node crashes, restarts, and performs state re-establishment. NSIS node crashes, restarts, and performs state re-establishment.
Proper re-synchronization of the security mechanism must therefore be Proper re-synchronization of the security mechanism must therefore be
provided to address this problem. provided to address this problem.
4.2 Flooding 4.2. Flooding
This section describes attacks that allow an adversary to flood an This section describes attacks that allow an adversary to flood an
NSIS node with bogus signaling messages to cause a denial of service NSIS node with bogus signaling messages to cause a denial of service
attack. attack.
We will discuss this threat at different layers in the NSIS protocol We will discuss this threat at different layers in the NSIS protocol
suite: suite:
Processing of Router Alert Options: Processing of Router Alert Options:
The processing of Router Alert Option (RAO) requires a router to The processing of Router Alert Option (RAO) requires that a router
do some additional processing by intercepting packets with IP do some additional processing by intercepting packets with IP
options, which might lead to additional delay for legitimate options, which might lead to additional delay for legitimate
requests, or even to reject some of them. A router being flooded requests, or even rejection of some of them. A router being
with a large number of bogus messages requires resources before flooded with a large number of bogus messages requires resources
finding out that these messages have to be dropped. before finding out that these messages have to be dropped.
If the protocol is based on using interception for message If the protocol is based on using interception for message
delivery this threat cannot be completely eliminated, but the delivery, this threat cannot be completely eliminated, but the
protocol design should attempt to limit the processing that has to protocol design should attempt to limit the processing that has to
be done on the RAO-bearing packet so that it is as similar as be done on the RAO-bearing packet so that it is as similar as
possible to that for an arbitrary packet addressed directly to one possible to that for an arbitrary packet addressed directly to one
of the router interfaces. of the router interfaces.
Attacks against the Transport Layer protocol: Attacks against the Transport Layer Protocol:
Certain attacks can be mounted against transport protocols by Certain attacks can be mounted against transport protocols by
flooding a node with bogus requests or even to finish the flooding a node with bogus requests, or even to finish the
handshake phase to establish a transport layer association. These handshake phase to establish a transport layer association. These
types of threats are also addressed in Section 4.11. types of threats are also addressed in Section 4.11.
Force NTLP to do more processing: Force NTLP to Do More Processing:
Some protocol fields might allow an adversary to force an NTLP Some protocol fields might allow an adversary to force an NTLP
node to perform more processing. Additionally it might be node to perform more processing. Additionally it might be
possible to interfere with the flow control or the congestion possible to interfere with the flow control or the congestion
control procedure. These types of threats are also addressed in control procedure. These types of threats are also addressed in
Section 4.11. Section 4.11.
Furthermore, it might be possible to force the NTLP node to Furthermore, it might be possible to force the NTLP node to
perform some computations or signaling message exchanges by perform some computations or signaling message exchanges by
injecting "trigger" events (which are unprotected). injecting "trigger" events (which are unprotected).
Force NSLP to-do more processing: Force NSLP to Do More Processing:
An adversary might benefit from flooding an NSLP node with An adversary might benefit from flooding an NSLP node with
messages which must be stored (e.g., due to fragmentation messages that must be stored (e.g., due to fragmentation handling)
handling) before verifying the correctness of signaling messages. before verifying the correctness of signaling messages.
Furthermore, causing memory allocation and computational efforts Furthermore, causing memory allocation and computational efforts
might allow an adversary to do harm to NSIS entities. If a might allow an adversary to harm NSIS entities. If a signaling
signaling message contains, for example, a digital signature then message contains, for example, a digital signature, then some
some additional processing is required for the cryptographic additional processing is required for the cryptographic
verification. An adversary can easily create a random bit verification. An adversary can easily create a random bit
sequence instead of a digital signature to force an NSIS node into sequence instead of a digital signature to force an NSIS node into
heavy computation. heavy computation.
Idempotent signaling messages are particularly vulnerable to this Idempotent signaling messages are particularly vulnerable to this
type of attack. Idempotent refers to messages which contain the type of attack. The term "idempotent" refers to messages that
same amount of information as the original message. An example contain the same amount of information as the original message.
would be a refresh message that is equivalent to a create message. An example would be a refresh message that is equivalent to a
This property allows a refresh message to create state along a new create message. This property allows a refresh message to create
path, where no previous state is available. For this to work, state along a new path, where no previous state is available. For
specific classes of cryptographic mechanisms supporting this this to work, specific classes of cryptographic mechanisms
behavior are needed. An example is a scheme based on digital supporting this behavior are needed. An example is a scheme based
signatures, which, however, should be used with care due to on digital signatures, which, however, should be used with care
possible denial of service attacks. due to possible denial of service attacks.
Problems with the usage of public key based cryptosystems in Problems with the usage of public-key-based cryptosystems in
protocols are described in [AN97] and in [ALN00]. protocols are described in [AN97] and in [ALN00].
In addition to the threat scenario described above, an incoming In addition to the threat scenario described above, an incoming
signaling message might trigger communication with third-party signaling message might trigger communication with third-party
nodes such as policy servers, LDAP servers or AAA servers. If an nodes such as policy servers, LDAP servers, or AAA servers. If an
adversary is able to transmit a large number of signaling messages adversary is able to transmit a large number of signaling messages
(for example, with QoS reservation requests) with invalid (for example, with QoS reservation requests) with invalid
credentials, then the verifying node may not be able to process credentials, then the verifying node may not be able to process
other reservation messages from legitimate users. other reservation messages from legitimate users.
4.3 Eavesdropping and Traffic Analysis 4.3. Eavesdropping and Traffic Analysis
This section covers threats whereby an adversary is able to eavesdrop This section covers threats whereby an adversary is able to eavesdrop
on signaling messages. The signaling packets collected may allow on signaling messages. The signaling packets collected may allow
traffic analysis or be used later to mount replay attacks, as traffic analysis or be used later to mount replay attacks, as
described in Section 3.2. The eavesdropper might learn QoS described in Section 3.2. The eavesdropper might learn QoS
parameters, communication patterns, policy rules for firewall parameters, communication patterns, policy rules for firewall
traversal, policy information, application identifiers, user traversal, policy information, application identifiers, user
identities, NAT bindings, authorization objects, network identities, NAT bindings, authorization objects, network
configuration and performance information, and more. configuration and performance information, and more.
An adversary's capability to eavesdrop on signaling messages might An adversary's capability to eavesdrop on signaling messages might
violate a user's preference for privacy, particularly if unprotected violate a user's preference for privacy, particularly if unprotected
authentication or authorization information (including policies and authentication or authorization information (including policies and
profile information) is exchanged. profile information) is exchanged.
Because the NSIS protocol signals messages through a number of nodes, Because the NSIS protocol signals messages through a number of nodes,
it is possible to differentiate between nodes actively participating it is possible to differentiate between nodes actively participating
in the NSIS protocol and others that do not actively participate in in the NSIS protocol and those that do not. For certain objects or
the NSIS protocol. For certain objects or messages it might be messages, it might be desirable to permit actively participating
desirable to permit actively participating intermediate NSIS nodes to intermediate NSIS nodes to eavesdrop. On the other hand, it might be
eavesdrop. On the other hand, it might be desirable that only the desirable that only the intended end points (NSIS Initiator and NSIS
intended end points (NSIS Initiator and NSIS Responder) are able to Responder) be able to read certain other objects.
read certain other objects.
4.4 Identity Spoofing 4.4. Identity Spoofing
Identity spoofing relevant for NSIS occurs in three forms: first, Identity spoofing relevant for NSIS occurs in three forms: First,
identity spoofing can happen during the establishment of a security identity spoofing can happen during the establishment of a security
association based on a weak authentication mechanism. Second, an association based on a weak authentication mechanism. Second, an
adversary can modify the flow identifier carried within a signaling adversary can modify the flow identifier carried within a signaling
message and third, it can spoof data traffic. message. Third, it can spoof data traffic.
In the first case, Eve, acting as an adversary, may claim to be the In the first case, Eve, acting as an adversary, may claim to be the
registered user Alice by spoofing Alice's identity. Eve thereby registered user Alice by spoofing Alice's identity. Eve thereby
causes the network to charge Alice for the network resources causes the network to charge Alice for the network resources
consumed. This type of attack is possible if authentication is based consumed. This type of attack is possible if authentication is based
on a simple username identifier (i.e., in absence of cryptographic on a simple username identifier (i.e., in absence of cryptographic
authentication), or if authentication is provided for hosts, and authentication), or if authentication is provided for hosts, and
multiple users have access to a single host. This attack could also multiple users have access to a single host. This attack could also
be classified as theft of service. be classified as theft of service.
In the second case, an adversary may be able to exploit the In the second case, an adversary may be able to exploit the
established flow identifiers (required for QoS and NAT/FW NSLP). established flow identifiers (required for QoS and NAT/FW NSLP).
These identifiers are, among others, IP addresses, transport protocol These identifiers are, among others, IP addresses, transport protocol
type (UDP, TCP), port numbers, and flow labels (see [RFC1809] and type (UDP, TCP), port numbers, and flow labels (see [RFC1809] and
[I-D.ietf-ipv6-flow-label]). Modification of these flow identifiers [RFC3697]). Modification of these flow identifiers allows
allows adversaries to exploit or to render ineffective quality of adversaries to exploit or to render ineffective quality of service
service reservations or policy rules at middleboxes. An adversary reservations or policy rules at middleboxes. An adversary could
could mount an attack by modifying the flow identifier of a signaling mount an attack by modifying the flow identifier of a signaling
message. message.
In the third case, an adversary may spoof data traffic. NSIS In the third case, an adversary may spoof data traffic. NSIS
signaling messages contain some sort of flow identifier, which is signaling messages contain some sort of flow identifier that is
associated with a specified behavior (e.g., a particular flow associated with a specified behavior (e.g., a particular flow
experiences QoS treatment or allows packets to traverse a firewall). experiences QoS treatment or allows packets to traverse a firewall).
An adversary might, therefore, use IP spoofing and inject data An adversary might, therefore, use IP spoofing and inject data
packets to benefit from previously installed flow identifiers. packets to benefit from previously installed flow identifiers.
We will provide an example of the latter threat. After NSIS nodes We will provide an example of the latter threat. After NSIS nodes
along the path between the NSIS initiator and the NSIS receiver along the path between the NSIS initiator and the NSIS receiver
processes a properly protected reservation request, transmitted by processes a properly protected reservation request, transmitted by
the legitimate user Alice, a QoS reservation is installed at the the legitimate user Alice, a QoS reservation is installed at the
corresponding NSIS nodes (for example, the edge router). The flow corresponding NSIS nodes (for example, the edge router). The flow
identifier is used for flow identification and allows data traffic identifier is used for flow identification and allows data traffic
originated from a given source to be assigned to this QoS originated from a given source to be assigned to this QoS
reservation. The adversary Eve now spoofs the IP address of Alice. reservation. The adversary Eve now spoofs Alice's IP address. In
In addition, Alice's host may be crashed by the adversary with a addition, Alice's host may be crashed by the adversary with a denial
denial of service attack or may lose connectivity, for example, of service attack or may lose connectivity (for example, because of
because of mobility. If Eve is able to perform address spoofing then mobility). If Eve is able to perform address spoofing, then she is
she is able to receive and transmit data (for example RTP data able to receive and transmit data (for example, RTP data traffic)
traffic) that receives preferential QoS treatment based on the that receives preferential QoS treatment based on the previous
previous reservation. Depending on the installed flow identifier reservation. Depending on the installed flow identifier granularity,
granularity, Eve might have more possibilities to exploit the QoS Eve might have more possibilities to exploit the QoS reservation or a
reservation or a pin-holed firewall. Assuming the soft state pin-holed firewall. Assuming the soft state paradigm, whereby
paradigm, whereby periodic refresh messages are required, the absence periodic refresh messages are required, Alice's absence will not be
of Alice will not be detected until a refresh message is required and detected until a refresh message is required, forcing Eve to respond
forces Eve to respond with a protected signaling message. Again, with a protected signaling message. Again, this attack is applicable
this attack is applicable not just to QoS traffic and the same attack not only to QoS traffic, but also to a Firewall control protocol,
is also applicable to a Firewall control protocol, with a different with a different consequence.
consequence.
The ability for an adversary to inject data traffic that matches a The ability for an adversary to inject data traffic that matches a
certain flow identifier established by a legitimate user and to get certain flow identifier established by a legitimate user and to get
some benefit from injecting that traffic often requires the ability some benefit from injecting that traffic often also requires the
also to receive the data traffic or to have one's correspondent ability to receive the data traffic or to have one's correspondent
receive it. For example, an adversary in an unmanaged network receive it. For example, an adversary in an unmanaged network
observes a NAT/Firewall signaling message towards a corporate observes a NAT/Firewall signaling message towards a corporate
network. After the signaling message exchange was successful user network. After the signaling message exchange was successful, the
Alice is allowed to traverse the company firewall based on the user Alice is allowed to traverse the company firewall based on the
establish packet filter to contact her internal mail server. Now, establish packet filter in order to contact her internal mail server.
adversary Eve, which was monitoring the signaling exchange is able to Now, the adversary Eve, who was monitoring the signaling exchange, is
build a data packet towards this mail server which will pass the able to build a data packet towards this mail server that will pass
company firewall. The packet will hit the mail server and cause some the company firewall. The packet will hit the mail server and cause
actions and the mail server will reply with some response messages. some actions, and the mail server will reply with some response
Depending on the exact location of the adversary and the degree of messages. Depending on the exact location of the adversary and the
routing asymmetry the adversary might even see the response messages. degree of routing asymmetry, the adversary might even see the
Note that for this attack to work Alice does not need to participate response messages. Note that for this attack to work, Alice does not
in the exchange of signaling messages. need to participate in the exchange of signaling messages.
If we imagine using attributes of a flow identifier that is not We could imagine using attributes of a flow identifier that is not
related to source and destination addresses. As an example, we could related to source and destination addresses. For example, we could
think of a flow identifier where only the 21-bit Flow ID is used think of a flow identifier for which only the 21-bit Flow ID is used
(without source and destination IP address). Identity spoofing and (without source and destination IP address). Identity spoofing and
injecting traffic is much easier since a packet only needs to be injecting traffic is much easier since a packet only needs to be
marked and an adversary can use a nearly arbitrary endpoint marked and an adversary can use a nearly arbitrary endpoint
identifier to achieve the desired result. Obviously, though, the identifier to achieve the desired result. Obviously, though, the
endpoint identifiers are not irrelevant, because the messages have to endpoint identifiers are not irrelevant, because the messages have to
hit some nodes in the network where NSIS signaling messages installed hit some nodes in the network where NSIS signaling messages installed
state (e.g., in the above example they would have to hit the same state (in the above example, they would have to hit the same
firewall.) firewall).
Data traffic marking based on DiffServ is such an example. Whenever Data traffic marking based on DiffServ is such an example. Whenever
an ingress router uses only marked incoming data traffic for an ingress router uses only marked incoming data traffic for
admission control procedures, then various attacks are possible. admission control procedures, various attacks are possible. These
These problems have been known in the DiffServ community for a long problems have been known in the DiffServ community for a long time
time and have been documented in various DiffServ-related documents. and have been documented in various DiffServ-related documents. The
The IPsec protection of DiffServ Code Points is described in Section IPsec protection of DiffServ Code Points is described in Section 6.2
6.2 of [RFC2745]. Related security issues (for example denial of of [RFC2745]. Related security issues (for example denial of service
service attacks) are described in Section 6.1 of the same document. attacks) are described in Section 6.1 of the same document.
4.5 Unprotected Authorization Information 4.5. Unprotected Authorization Information
Authorization is an important criterion for providing resources such Authorization is an important criterion for providing resources such
as QoS reservations, NAT bindings, and pinholes through firewalls. as QoS reservations, NAT bindings, and pinholes through firewalls.
Authorization information might be delivered to the NSIS Authorization information might be delivered to the NSIS-
participating entities in a number of ways. participating entities in a number of ways.
Typically the authenticated identity is used to assist during the Typically, the authenticated identity is used to assist during the
authorization procedure as, e.g., described in [RFC3182]. Depending authorization procedure (as described in [RFC3182], for example).
on the chosen authentication protocol, certain threats may exist. Depending on the chosen authentication protocol, certain threats may
Section 3 discusses a number of issues related to this approach when exist. Section 3 discusses a number of issues related to this
the authentication and key exchange protocol is used to establish approach when the authentication and key exchange protocol is used to
session keys for signaling message protection. establish session keys for signaling message protection.
Another approach is to use some sort of authorization token. The Another approach is to use some sort of authorization token. The
functionality and structure of such an authorization token for RSVP functionality and structure of such an authorization token for RSVP
is described in [RFC3520] and [RFC3521]. is described in [RFC3520] and [RFC3521].
Achieving secure interaction between different protocols based on Achieving secure interaction between different protocols based on
authorization tokens, however, requires some care. By using such an authorization tokens, however, requires some care. By using such an
authorization token it is possible to link state information between authorization token, it is possible to link state information between
different protocols. Returning an unprotected authorization token to different protocols. Returning an unprotected authorization token to
the end host might allow an adversary (for example an eavesdropper) the end host might allow an adversary (for example, an eavesdropper)
to steal resources. An adversary might also use the token to monitor to steal resources. An adversary might also use the token to monitor
communication patterns. Finally, an untrustworthy end host might communication patterns. Finally, an untrustworthy end host might
also modify the token content. also modify the token content.
The Session/Reservation Ownership problem can also be regarded as an The Session/Reservation Ownership problem can also be regarded as an
authorization problem. Details are described in Section 4.10. In authorization problem. Details are described in Section 4.10. In
enterprise networks, authorization is often coupled with membership enterprise networks, authorization is often coupled with membership
in a particular class of users or groups. This type of information in a particular class of users or groups. This type of information
either can be delivered as part of the authentication and key either can be delivered as part of the authentication and key
agreement procedure or has to be retrieved via separate protocols agreement procedure or has to be retrieved via separate protocols
from other entities. If an adversary manages to modify information from other entities. If an adversary manages to modify information
relevant for determining authorization or the outcome of the relevant to determining authorization or the outcome of the
authorization process itself, then theft of service might be authorization process itself, then theft of service might be
possible. possible.
4.6 Missing Non-Repudiation 4.6. Missing Non-Repudiation
Signaling for QoS often involves three parties: the user, a network Signaling for QoS often involves three parties: the user, a network
that offer QoS reservations (referred as service provider) and a that offers QoS reservations (referred to as "service provider") and
third party which guarantees that the party making the reservation a third party that guarantees that the party making the reservation
actually receives a financial compensation (referred as trusted third actually receives a financial compensation (referred to as "trusted
party). third party").
Repudiation in this context refers to a problem where either the user In this context,"repudiation" refers to a problem where either the
or the service provider later deny about the existence or some user or the service provider later deny the existence or some
parameters (e.g., volume or price) of a QoS reservation towards the parameters (e.g., volume or price) of a QoS reservation towards the
trusted third party. Problems stemming from a lack of trusted third party. Problems stemming from a lack of non-
non-repudiation appear in two forms: repudiation appear in two forms:
Service providers point-of-view: Service provider's point-of-view:
A user may deny having issued a reservation request for which it A user may deny having issued a reservation request for which it
was charged. The service provider may then want to be able to was charged. The service provider may then want to be able to
prove that a particular user issued the reservation request in prove that a particular user issued the reservation request in
question. question.
Users point-of-view: User's point-of-view:
A service provider may claim to have received a number of A service provider may claim to have received a number of
reservation requests from a particular user. The user in question reservation requests from a particular user. The user in question
may want to show that such a reservation requests have never been may want to show that such reservation requests have never been
issued and may want to see correct service usage records for a issued and may want to see correct service usage records for a
given set of QoS parameters. given set of QoS parameters.
In today's networks, non-repudiation is not provided. As such, it In today's networks, non-repudiation is not provided. Therefore, it
might be difficult to introduce with NSIS signaling. The user has to might be difficult to introduce with NSIS signaling. The user has to
trust the network operator to meter the traffic correctly, collect trust the network operator to meter the traffic correctly, to collect
and merge accounting data, and ensure that no unforeseen problems and merge accounting data, and to ensure that no unforeseen problems
occur. If a signaling protocol with the non-repudiation property is occur. If a signaling protocol with the non-repudiation property is
desired for establishing QoS reservations then it certainly impacts desired for establishing QoS reservations, then it certainly impacts
the protocol design. the protocol design.
Non-repudiation functionality additional places requirements on the Non-repudiation functionality places additional requirements on the
security mechanisms. Hence, a solution would normally increase the security mechanisms. Thus, a solution would normally increase the
overhead of a security solution. Threats related to missing overhead of a security solution. Threats related to missing non-
non-repudiation are only considered relevant in certain specific repudiation are only considered relevant in certain specific
scenarios and for specific NSLPs. scenarios and for specific NSLPs.
4.7 Malicious NSIS Entity 4.7. Malicious NSIS Entity
Network elements within a domain (intra-domain) experience a Network elements within a domain (intra-domain) experience a
different trust relationship with regard to the security protection different trust relationship with regard to the security protection
of signaling messages compared with edge NSIS entities. It is of signaling messages from that of edge NSIS entities. It is assumed
assumed that edge NSIS entities are responsible for performing that edge NSIS entities are responsible for performing cryptographic
cryptographic processing (authentication, integrity and replay processing (authentication, integrity and replay protection,
protection, authorization, and accounting) for signaling messages authorization, and accounting) for signaling messages arriving from
arriving from the outside. This prevents unprotected signaling the outside. This prevents unprotected signaling messages from
messages from appearing within the internal network. If, however, an appearing within the internal network. If, however, an adversary
adversary manages to take over an edge router, then the security of manages to take over an edge router, then the security of the entire
the entire network is compromised. An adversary is then able to network is compromised. An adversary is then able to launch a number
launch a number of attacks including denial of service; integrity of attacks, including denial of service; integrity violations; replay
violations; replay, reordering of objects and messages, bundling of and reordering of objects and messages; bundling of messages;
messages, and deletion of data packets; and various others. A rogue deletion of data packets; and various others. A rogue firewall can
firewall can harm other firewalls by modifying policy rules. The harm other firewalls by modifying policy rules. The chain-of-trust
chain-of-trust principle applied in peer-to-peer security protection principle applied in peer-to-peer security protection cannot protect
cannot protect against a malicious NSIS node. An adversary with against a malicious NSIS node. An adversary with access to an NSIS
access to a NSIS router is also able to get access to security router is also able to get access to security associations and to
associations and transmit secured signaling messages. Note that even transmit secured signaling messages. Note that even non-peer-to-peer
non-peer-to-peer security protection might not be able to prevent security protection might not be able to prevent this problem fully.
this problem fully. Because an NSIS node might issue signaling Because an NSIS node might issue signaling messages on behalf of
messages on behalf of someone else (by acting as a proxy), additional someone else (by acting as a proxy), additional problems need to be
problems need to be considered. considered.
An NSIS-aware edge router is a critical component that requires An NSIS-aware edge router is a critical component that requires
strong security protection. A strong security policy applied at the strong security protection. A strong security policy applied at the
edge does not imply that other routers within an intra-domain network edge does not imply that other routers within an intra-domain network
do not need to verify signaling messages cryptographically. If the do not need to verify signaling messages cryptographically. If the
chain-of-trust principle is deployed, then the security protection of chain-of-trust principle is deployed, then the security protection of
the entire path (in this case within the network of a single the entire path (in this case, within the network of a single
administrative domain) is as strong as the weakest link. In the case administrative domain) is only as strong as the weakest link. In the
under consideration, the edge router is the most critical component case under consideration, the edge router is the most critical
of this network, and it may also act as a security gateway or component of this network, and it may also act as a security gateway
firewall for incoming and outgoing traffic. For outgoing traffic or firewall for incoming and outgoing traffic. For outgoing traffic,
this device has to implement the security policy of the local domain this device has to implement the security policy of the local domain
and apply the appropriate security protection. and to apply the appropriate security protection.
For an adversary to mount this attack, either an existing NSIS-aware For an adversary to mount this attack, either an existing NSIS-aware
node along the path has to be attacked successfully, or an adversary node along the path has to be attacked successfully, or an adversary
must succeed in convincing another NSIS node to make it the next NSIS must succeed in convincing another NSIS node to make it the next NSIS
peer (man-in-the-middle attack). peer (man-in-the-middle attack).
4.8 Denial of Service Attacks 4.8. Denial of Service Attacks
A number of denial of service (DoS) attacks can cause NSIS nodes to A number of denial of service (DoS) attacks can cause NSIS nodes to
malfunction. Other attacks that could lead to DoS, such as malfunction. Other attacks that could lead to DoS, such as man-in-
man-in-the-middle attacks, replay attacks, injection or modification the-middle attacks, replay attacks, and injection or modification of
of signaling messages, etc., are mentioned throughout this document. signaling messages, etc., are mentioned throughout this document.
Path Finding: Path Finding:
Some signaling protocols establish state (e.g., routing state) and Some signaling protocols establish state (e.g., routing state) and
perform some actions (e.g., querying resources) at a number of perform some actions (e.g., querying resources) at a number of
NSIS nodes without requiring authorization (or even proper NSIS nodes without requiring authorization (or even proper
authentication) based on a single message (e.g., PATH message in authentication) based on a single message (e.g., PATH message in
RSVP). RSVP).
An adversary can utilize this fact to transmit a large number of An adversary can utilize this fact to transmit a large number of
skipping to change at page 22, line 47 skipping to change at page 20, line 37
to cause resource consumption. to cause resource consumption.
An NSIS responder might not be able to determine the NSIS An NSIS responder might not be able to determine the NSIS
initiator and might even tend to respond to such a signaling initiator and might even tend to respond to such a signaling
message with a corresponding reservation message. message with a corresponding reservation message.
Discovery Phase: Discovery Phase:
Conveying signaling information to a large number of entities Conveying signaling information to a large number of entities
along a data path requires some sort of discovery. This discovery along a data path requires some sort of discovery. This discovery
process is vulnerable to a number of attacks, because it is process is vulnerable to a number of attacks because it is
difficult to secure. An adversary can use the discovery difficult to secure. An adversary can use the discovery
mechanisms to convince one entity to signal information to another mechanisms to convince one entity to signal information to another
entity not along the data path or to cause the discovery process entity that is not along the data path, or to cause the discovery
to fail. In the first case, the signaling protocol could appear process to fail. In the first case, the signaling protocol could
to continue correctly, except that policy rules are installed at appear to continue correctly, except that policy rules are
the incorrect firewalls or QoS resource reservations take place at installed at the incorrect firewalls or QoS resource reservations
the wrong entities. For an end host, this means that the protocol take place at the wrong entities. For an end host, this means
failed for unknown reasons. that the protocol failed for unknown reasons.
Faked Error or Response Messages: Faked Error or Response Messages:
An adversary may be able to inject false error or response An adversary may be able to inject false error or response
messages as part of a DoS attack. This could be either at the messages as part of a DoS attack. This could be at the signaling
signaling message protocol layer (NTLP), at the layer of each message protocol layer (NTLP), the layer of each client layer
client layer protocol (e.g., QoS NSLP or NAT/Firewall NSLP), or at protocol (e.g., QoS NSLP or NAT/Firewall NSLP), or the transport
the transport protocol layer. An adversary might cause unexpected protocol layer. An adversary might cause unexpected protocol
protocol behavior or might succeed with a DoS attack. The behavior or might succeed with a DoS attack. The discovery
discovery protocol, especially, exhibits vulnerabilities with protocol, especially, exhibits vulnerabilities with regard to this
regard to this threat scenario (see the above discussion on threat scenario (see the above discussion on discovery). If no
discovery). In the case in which no separate discovery protocol separate discovery protocol is used and signaling messages are
is used and signaling messages are addressed to end hosts only addressed to end hosts only (with a Router Alert Option to
(with a Router Alert Option to intercept message as NSIS aware intercept message as NSIS aware nodes), an error message might be
nodes), an error message might be used to indicate a path change. used to indicate a path change. Such a design combines a
Such a design combines a discovery protocol together with a discovery protocol with a signaling message exchange protocol.
signaling message exchange protocol.
4.9 Disclosing the Network Topology 4.9. Disclosing the Network Topology
In some organizations or enterprises there is a desire not to reveal In some organizations or enterprises there is a desire not to reveal
internal network structure (or other related information) outside of internal network structure (or other related information) outside of
a closed community. An adversary might be able to use NSIS messages a closed community. An adversary might be able to use NSIS messages
for network mapping (e.g., discovering which nodes exist, which use for network mapping (e.g., discovering which nodes exist, which use
NSIS, what version, what resources are allocated, what capabilities NSIS, what version, what resources are allocated, what capabilities
nodes along a path have, etc.). Discovery messages, traceroute, nodes along a path have, etc.). Discovery messages, traceroute,
diagnostic messages (see [RFC2745] for a description of diagnostic diagnostic messages (see [RFC2745] for a description of diagnostic
message functionality for RSVP), and query messages, in addition to message functionality for RSVP), and query messages, in addition to
record route and route objects, provide potential assistance to an record route and route objects, provide potential assistance to an
adversary. Hence, the requirement of not disclosing a network adversary. Thus, the requirement of not disclosing a network
topology might conflict with other requirements to provide means for topology might conflict with other requirements to provide means for
automatically discovering NSIS-aware nodes or to provide diagnostic discovering NSIS-aware nodes automatically or to provide diagnostic
facilities (used for network monitoring and administration). facilities (used for network monitoring and administration).
4.10 Unprotected Session or Reservation Ownership 4.10. Unprotected Session or Reservation Ownership
Figure 4 shows an NSIS Initiator that has established state Figure 4 shows an NSIS Initiator that has established state
information at NSIS nodes along a path as part of the signaling information at NSIS nodes along a path as part of the signaling
procedure. As a result, Access Router 1, Router 3, and Router 4 (and procedure. As a result, Access Router 1, Router 3, and Router 4 (and
other nodes) have stored session state information including the other nodes) have stored session-state information, including the
Session Identifier SID-x. Session Identifier SID-x.
Session ID(SID-x) Session ID(SID-x)
+--------+ +--------+
+-----------------+ Router +------------> +-----------------+ Router +------------>
Session ID(SID-x)| | 4 | Session ID(SID-x)| | 4 |
+---+----+ +--------+ +---+----+ +--------+
| Router | | Router |
+------+ 3 +******* +------+ 3 +*******
| +---+----+ * | +---+----+ *
skipping to change at page 24, line 32 skipping to change at page 22, line 32
+----+------+ +----+------+ +----+------+ +----+------+
| NSIS | | Adversary | | NSIS | | Adversary |
| Initiator | | | | Initiator | | |
+-----------+ +-----------+ +-----------+ +-----------+
Figure 4: Session or Reservation Ownership Figure 4: Session or Reservation Ownership
The Session Identifier is included in signaling messages to reference The Session Identifier is included in signaling messages to reference
to the established state. to the established state.
If an adversary were able to obtain the Session Identifier, for If an adversary were able to obtain the Session Identifier (for
example by eavesdropping on signaling messages, it would be able to example, by eavesdropping on signaling messages), it would be able to
add the same Session Identifier SID-x to a new signaling message. add the same Session Identifier SID-x to a new signaling message.
When the new signaling message hits Router 3 (as shown in Figure 3), When the new signaling message hits Router 3 (as shown in Figure 4),
existing state information can be modified. The adversary can then existing state information can be modified. The adversary can then
modify or delete the established reservation and cause unexpected modify or delete the established reservation and cause unexpected
behavior for the legitimate user. behavior for the legitimate user.
The source of the problem is that Router 3 (a cross-over router) is The source of the problem is that Router 3 (a cross-over router) is
unable to decide whether the new signaling message was initiated from unable to decide whether the new signaling message was initiated from
the owner of the session or reservation. the owner of the session or reservation.
In addition, nodes other than the initial signaling message In addition, nodes other than the initial signaling message
originator are allowed to signal information during the lifetime of originator are allowed to signal information during the lifetime of
skipping to change at page 25, line 8 skipping to change at page 23, line 8
along the path (and the path might change over time) could initiate a along the path (and the path might change over time) could initiate a
signaling message exchange. It might, for example, be necessary to signaling message exchange. It might, for example, be necessary to
provide mobility support or to trigger a local repair procedure. If provide mobility support or to trigger a local repair procedure. If
only the initial signaling message originator were allowed to trigger only the initial signaling message originator were allowed to trigger
signaling message exchanges, some protocol behavior would not be signaling message exchanges, some protocol behavior would not be
possible. possible.
If this threat scenario is not addressed, an adversary can launch If this threat scenario is not addressed, an adversary can launch
DoS, theft of service, and various other attacks. DoS, theft of service, and various other attacks.
4.11 Attacks against the NTLP 4.11. Attacks against the NTLP
In [I-D.braden-2level-signal-arch] a two-level architecture is In [2LEVEL], a two-level architecture is proposed, that would split
proposed, which suggests splitting an NSIS protocol into layers: a an NSIS protocol into layers: a signaling message transport-specific
signaling message transport-specific layer and an layer and an application-specific layer. This is further developed
application-specific layer. This is further developed in the NSIS in the NSIS Framework [RFC4080]. Most of the threats described in
Framework [I-D.ietf-nsis-fw]. Most of the threats described in this this threat analysis are applicable to the NSLP application-specific
threat analysis are applicable to the NSLP application-specific part part (e.g., QoS NSLP). There are, however, some threats that are
(e.g., QoS NSLP). There are, however, some threats that are
applicable to the NTLP. applicable to the NTLP.
Network and transport layer protocols lacking protection mechanisms Network and transport layer protocols lacking protection mechanisms
are vulnerable to certain attacks such as header manipulation, DoS, are vulnerable to certain attacks, such as header manipulation, DoS,
spoofing of identities, session hijacking, unexpected aborts, etc. spoofing of identities, session hijacking, unexpected aborts, etc.
Malicious nodes can attack the congestion control mechanism to force Malicious nodes can attack the congestion control mechanism to force
NSIS nodes into a congestion avoidance state. NSIS nodes into a congestion avoidance state.
Threats which address parts of the NTLP which are not related to Threats that address parts of the NTLP that are not related to
attacks against the use of transport layer protocols are covered in attacks against the use of transport layer protocols are covered in
various sections throughout this document, such as in Section 4.2. various sections throughout this document, such as Section 4.2.
In the case in which existing transport layer protocols are used for If existing transport layer protocols are used for exchanging NSIS
exchanging NSIS signaling messages, security vulnerabilities known signaling messages, security vulnerabilities known for these
for these protocols need to be considered. A detailed threat protocols need to be considered. A detailed threat description of
description of these protocols is outside the scope of this document. these protocols is outside the scope of this document.
5. Security Considerations 5. Security Considerations
This entire memo discusses security issues relevant for NSIS protocol This entire memo discusses security issues relevant for NSIS protocol
design. It begins by identifying the components of a network running design. It begins by identifying the components of a network running
NSIS (Initiator, Responder, and different Administrative Domains NSIS (Initiator, Responder, and different Administrative Domains
between them). It then considers five cases in which communications between them). It then considers five cases in which communications
take place between these components, and it examines the trust take place between these components, and it examines the trust
relationships presumed to exist in each case: First-Peer relationships presumed to exist in each case: First-Peer
Communications, End-to-Middle Communications, Intra-Domain Communications, End-to-Middle Communications, Intra-Domain
Communications, Inter-Domain Communications, and End-to-End Communications, Inter-Domain Communications, and End-to-End
Communications. This analysis helps determine the security needs and Communications. This analysis helps determine the security needs and
the relative seriousness of different threats in the different cases. the relative seriousness of different threats in the different cases.
The document points out the need for different protocol security The document points out the need for different protocol security
measures: authentication, key exchange, message integrity, replay measures: authentication, key exchange, message integrity, replay
protection, confidentiality, authorization, and some precautions protection, confidentiality, authorization, and some precautions
against denial of service. The threats are subdivided into generic against denial of service. The threats are subdivided into generic
ones (e.g., man-in-the-middle attacks, replay attacks, tampering and ones (e.g., man-in-the-middle attacks, replay attacks, tampering and
forgery, and attacks on security negotiation protocols) and 11 threat forgery, and attacks on security negotiation protocols) and eleven
scenarios particularly applicable to the NSIS protocol. Denial of threat scenarios that are particularly applicable to the NSIS
service, for example, is covered in the NSIS-specific section, not protocol. Denial of service, for example, is covered in the
because it cannot be carried out against other protocols, but because NSIS-specific section, not because it cannot be carried out against
the methods used to carry out denial of service attacks tend to be other protocols, but because the methods used to carry out denial of
protocol specific. Numerous illustrative examples provide insight service attacks tend to be protocol specific. Numerous illustrative
into what can happen if these threats are not mitigated. examples provide insight into what can happen if these threats are
not mitigated.
This document points out repeatedly that not all of the threats are This document repeatedly points out that not all of the threats are
equally serious in every context. It does attempt to identify the equally serious in every context. It does attempt to identify the
scenarios in which security failures may have the highest impact. scenarios in which security failures may have the highest impact.
However, it is difficult for the protocol designer to foresee all the However, it is difficult for the protocol designer to foresee all the
ways in which NSIS protocols will be used or to anticipate the ways in which NSIS protocols will be used or to anticipate the
security concerns of a wide variety of likely users. Therefore, the security concerns of a wide variety of likely users. Therefore, the
protocol designer needs to offer a full range of security protocol designer needs to offer a full range of security
capabilities and ways for users to negotiate and select what they capabilities and ways for users to negotiate and select what they
need, on a case by case basis. To counter these threats, security need, on a case-by-case basis. To counter these threats, security
requirements have been listed in [RFC3726]. requirements have been listed in [RFC3726].
6. Contributors 6. Contributors
We especially thank Richard Graveman, who provided text for the We especially thank Richard Graveman, who provided text for the
security considerations section, besides a detailed review of the security considerations section, as well as a detailed review of the
document. document.
7. Acknowledgments 7. Acknowledgements
We would like to thank (in alphabetical order) Marcus Brunner, Jorge We would like to thank (in alphabetical order) Marcus Brunner, Jorge
Cuellar, Mehmet Ersue, Xiaoming Fu, and Robert Hancock for their Cuellar, Mehmet Ersue, Xiaoming Fu, and Robert Hancock for their
comments on an initial version of this draft. Jorge and Robert gave comments on an initial version of this document. Jorge and Robert
us an extensive list of comments and provided information on gave us an extensive list of comments and provided information on
additional threats. additional threats.
Jukka Manner, Martin Buechli, Roland Bless, Marcus Brunner, Michael Jukka Manner, Martin Buechli, Roland Bless, Marcus Brunner, Michael
Thomas, Cedric Aoun, John Loughney, Rene Soltwisch, Cornelia Kappler, Thomas, Cedric Aoun, John Loughney, Rene Soltwisch, Cornelia Kappler,
Ted Wiederhold, Vishal Sankhla, Mohan Parthasarathy and Andrew Ted Wiederhold, Vishal Sankhla, Mohan Parthasarathy, and Andrew
McDonald provided comments on more recent versions of this draft. McDonald provided comments on more recent versions of this document.
Their input helped improve the content of this document. Roland Their input helped improve the content of this document. Roland
Bless, Michael Thomas, Joachim Kross and Cornelia Kappler, in Bless, Michael Thomas, Joachim Kross, and Cornelia Kappler, in
particular, provided good proposals for regrouping and restructuring particular, provided good proposals for regrouping and restructuring
the material. the material.
A final review was given by Michael Richardson. We thank him for his A final review was given by Michael Richardson. We thank him for his
detailed comments. detailed comments.
8. References 8. References
8.1 Normative References 8.1. Normative References
[I-D.ietf-nsis-fw] [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. van
Hancock, R., "Next Steps in Signaling: Framework", den Bosch, "Next Steps in Signaling (NSIS): Framework",
draft-ietf-nsis-fw-06 (work in progress), July 2004. RFC 4080, June 2005.
[RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC [RFC3726] Brunner, M., "Requirements for Signaling Protocols",
3726, April 2004. RFC 3726, April 2004.
8.2 Informative References 8.2. Informative References
[ALN00] Aura, T., Leiwo, J. and P. Nikander, "Towards Network [ALN00] Aura, T., Leiwo, J., and P. Nikander, "Towards Network
Denial of Service Resistant Protocols, In Proceedings of Denial of Service Resistant Protocols, In Proceedings
the 15th International Information Security Conference of the 15th International Information Security
(IFIP/SEC 2000), Beijing, China", August 2000, <ALN00>. Conference (IFIP/SEC 2000), Beijing, China",
August 2000.
[AN97] Aura, T. and P. Nikander, "Stateless Connections", In [AN97] Aura, T. and P. Nikander, "Stateless Connections", In
Proceedings of the International Conference on Information Proceedings of the International Conference on
and Communications Security (ICICS'97), Lecture Notes in Information and Communications Security (ICICS'97),
Computer Science 1334, Springer", 1997, <AN97>. Lecture Notes in Computer Science 1334, Springer",
1997.
[I-D.braden-2level-signal-arch] [2LEVEL] Braden, R. and B. Lindell, "A Two-Level Architecture
Braden, R. and B. Lindell, "A Two-Level Architecture for for Internet Signaling", Work in Progress,
Internet Signaling", draft-braden-2level-signal-arch-01 November 2002.
(work in progress), November 2002.
[I-D.ietf-ipv6-flow-label] [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S.
Rajahalme, J., Conta, A., Carpenter, B. and S. Deering, Deering, "IPv6 Flow Label Specification", RFC 3697,
"IPv6 Flow Label Specification", March 2004.
draft-ietf-ipv6-flow-label-09 (work in progress), December
2003.
[I-D.ietf-nsis-nslp-natfw] [NATFW-NSLP] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer
Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Work in Progress, February 2005.
Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-03 (work in
progress), July 2004.
[I-D.ietf-nsis-ntlp] [GIMPS] Schulzrinne, H., "GIMPS: General Internet Messaging
Schulzrinne, H., "GIMPS: General Internet Messaging Protocol for Signaling", Work in Progress,
Protocol for Signaling", draft-ietf-nsis-ntlp-03 (work in February 2005.
progress), July 2004.
[I-D.ietf-nsis-qos-nslp] [QOS-NSLP] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for
Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for Quality-of-Service signaling", Work in Progress,
Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-04 February 2005.
(work in progress), July 2004.
[I-D.ietf-nsis-rsvp-sec-properties] [RSVP-SEC] Tschofenig, H., "RSVP Security Properties", Work in
Tschofenig, H., "RSVP Security Properties", Progress, February 2005.
draft-ietf-nsis-rsvp-sec-properties-05 (work in progress),
September 2004.
[I-D.ietf-nsis-signalling-analysis] [SIG-ANAL] Manner, J. and X. Fu, "Analysis of Existing Quality-
Manner, J., "Analysis of Existing Quality of Service of-Service Signaling Protocols", RFC 4094, May 2005.
Signaling Protocols",
draft-ietf-nsis-signalling-analysis-04 (work in progress),
May 2004.
[RFC1809] Partridge, C., "Using the Flow Label Field in IPv6", RFC [RFC1809] Partridge, C., "Using the Flow Label Field in IPv6",
1809, June 1995. RFC 1809, June 1995.
[RFC2745] Terzis, A., Braden, B., Vincent, S. and L. Zhang, "RSVP [RFC2745] Terzis, A., Braden, B., Vincent, S., and L. Zhang,
Diagnostic Messages", RFC 2745, January 2000. "RSVP Diagnostic Messages", RFC 2745, January 2000.
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore,
Herzog, S. and R. Hess, "Identity Representation for T., Herzog, S., and R. Hess, "Identity Representation
RSVP", RFC 3182, October 2001. for RSVP", RFC 3182, October 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, Johnston, A., Peterson, J., Sparks, R., Handley, M.,
"SIP: Session Initiation Protocol", RFC 3261, June 2002. and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3520] Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh,
Authorization Policy Element", RFC 3520, April 2003. "Session Authorization Policy Element", RFC 3520,
April 2003.
[RFC3521] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for
Set-up with Media Authorization", RFC 3521, April 2003. Session Set-up with Media Authorization", RFC 3521,
April 2003.
[RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6
Discovery (ND) Trust Models and Threats", RFC 3756, May Neighbor Discovery (ND) Trust Models and Threats",
2004. RFC 3756, May 2004.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bayern 81739 Munich, Bavaria 81739
Germany Germany
EMail: Hannes.Tschofenig@siemens.com EMail: Hannes.Tschofenig@siemens.com
Dirk Kroeselberg Dirk Kroeselberg
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bayern 81739 Munich, Bavaria 81739
Germany Germany
EMail: Dirk.Kroeselberg@siemens.com EMail: Dirk.Kroeselberg@siemens.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/