draft-ietf-nsis-threats-00.txt   draft-ietf-nsis-threats-01.txt 
NSIS Working Group Internet Engineering Task Force NSIS
Internet Draft Hannes Tschofenig Internet Draft H. Tschofenig, D. Kroeselberg
Document: draft-ietf-nsis-threats-00.txt Siemens AG Siemens AG
Expires: April 2003 October 2002 draft-ietf-nsis-threats-01.txt
23 January 2003
Expires: August 2003
NSIS Threats Security Threats for NSIS
<draft-ietf-nsis-threats-00.txt>
Status of this Memo STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance with
with all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering Task
Task Force (IETF), its areas, and its working groups. Note that Force (IETF), its areas, and its working groups. Note that other groups
other groups may also distribute working documents as Internet- may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference material
material or to cite them other than as "work in progress". or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Informational - Expires April 2003 1 To view the list Internet-Draft Shadow Directories, see
NSIS Threats October 2002 http://www.ietf.org/shadow.html.
Abstract Abstract
This threats document provides a starting point to security This threats document provides a detailed analysis of the security
discussions at the NSIS working group. It therefore tries to help the threats relevant for the NSIS working group. It motivates and helps to
NSIS interested reader to understand various security considerations understand various security considerations in the NSIS Requirements,
in the NSIS Requirements, Framework and Protocol proposals. This Framework and Protocol proposals. This document does not describe
document does not describe vulnerabilities of specific NSIS related vulnerabilities of specific NSIS protocols.
protocols.
1 Introduction 1 Introduction
Section 1.1 tries to introduce the reader into the overall process of Section 1.1 introduces the overall process of addressing the security
addressing the security of work done in the NSIS working group. work done in the NSIS working group. Section 1.2 gives a high-level
Section 1.2 gives a big picture about the different network parts picture of the different network parts, which are traversed by NSIS
which are traversed by a signaling protocol. Each part is signaling. Each part is characterized by a different set of requirements
characterized by a different set of requirements and different trust and different trust relationships. The threats described in Section 2
relationships. The threats described in Section 2 can be assigned to can be assigned to these individual parts.
the individual parts.
Note that this document tries to use the terminology introduced and
used in the NSIS Framework document [5]. Some of the terms which
demand additional clarifications are briefly explained introduced in
Section 1.3
1.1 NSIS Security Process 1.1 NSIS Security Process
Whenever a new protocol has to be developed or existing protocols Whenever a new protocol has to be developed or existing protocols have
have to be modified potential security threats should be evaluated. to be modified their security threats should be evaluated. The process
The process of securing protocols in separated into individual steps. of securing protocols in separated into individual steps. To address
To address security in the NSIS working group a number of documents security in the NSIS working group a number of documents have been
have been produced: produced:
+----------------------------------------------+ +----------------------------------------------+
| NSIS Analysis Activities | | NSIS Analysis Activities |
| (e.g. RSVP Security Properties) | | (e.g. RSVP Security Properties) |
+----------------------------------------------+ +----------------------------------------------+
+----------------------------------------------+ +----------------------------------------------+
| NSIS Threats | | Security Threats for NSIS |
| | | |
+----------------------------------------------+ +----------------------------------------------+
+----------------------------------------------+ +----------------------------------------------+
| NSIS Requirements | | NSIS Requirements |
| | | |
+----------------------------------------------+ +----------------------------------------------+
+----------------------------------------------+ +----------------------------------------------+
| NSIS Framework Activities | | NSIS Framework |
| | | |
+----------------------------------------------+ +----------------------------------------------+
+----------------------------------------------+ +----------------------------------------------+
| Published | | |
| NSIS Protocol Proposals | | NSIS Protocol Proposals |
+----------------------------------------------+ +----------------------------------------------+
Figure 1: NSIS Security related Documents Figure 1: NSIS Security related Documents
Tschofenig Informational - Expires April 2003 2 All the documents depicted in Figure 1 contribute to the NSIS security
NSIS Threats October 2002 approach. The purpose of each of these documents is briefly described
below to give the reader insight into the development process.
In order to reach a satisfactory security protection for a NSIS NSIS Analysis Activities:
protocol a number of steps are necessary. The relevant information is
distributed over a number of documents as depicted in Figure 1. The
purpose of each of these documents is briefly described below to give
the reader a more insights into the development process.
The primary goal of the NSIS analysis activity is the investigation The primary goal of the NSIS analysis activity is the
of existing approaches in the area of quality of service signaling investigation of existing approaches in the area of quality of
protocols. Several of the published approaches contain directly service signaling protocols. Several of the published
security relevant descriptions whereas other requirements can be approaches directly identify security threats and
derived from different protocol behavior or different scenarios in requirements, whereas other threats and requirements can be
which such a protocol is used. Document [8] points to the reduced derived from the different scenarios in which these protocols
complexity if RSVP is used without multicast support. This are used. For instance, [1] points to the reduced complexity
modification also comes with some simplifications for security if RSVP is used without multicast support. This modification
handling. In [10] security issues raised by some example also results in simplified security requirements. In [2],
configurations are given. In [9] the security properties of RSVP are security issues in some example configurations are given. In
described. There are, however, a number of other analysis documents [3], the security properties of RSVP are described.
available but they do not directly address security issues. Furthermore an analysis of the interaction between RSVP and
Mobile IP is provided by Michael Thomas in [4] and an analysis
of existing QoS protocols is described in [5].
Threats relevant for NSIS are discussed in this document. NSIS Requirements:
To address threats described in this document requirements were To address the security threats relevant for NSIS described in
specified in the NSIS Requirements document [1]. In addition to the this document, security requirements have been specified as
requirements the document describes some basic scenarios where a QoS part of the NSIS Requirements document [6]. In addition to
signaling protocol might be deployed. these requirements [6] describes basic scenarios where the
NSIS signaling protocol might be deployed.
Signaling information to a number of devices located in different NSIS Framework:
parts in the network with different trust assumptions and possible
interactions with a large number of other protocols require some
framework thoughts. A few proposals were submitted and a few authors
cooperatively produced a NSIS framework document [5], which also
address security issues.
Finally there are documents describing concrete protocol proposals. Signaling information to a number of devices located in
These proposals either rely on existing security mechanisms or different parts in the network with different trust
develop their own if the existing mechanisms cannot be solve all assumptions and possible interactions with a large number of
security threats or if they are inappropriate for other reasons. In other protocols require some framework thoughts, which is
practice a protocol proposal might use existing security mechanisms especially true for security. In [7] a security framework is
but is likely to require some additional protection mechanisms or to provided for NSIS.
combine them in a specific manner.
Note that the process of developing the above-mentioned documents is NSIS Protocol:
not linear. Instead various iterations are required to reach a
satisfactory final status.
This document tries to identify the basic threats that need to be Finally there are documents describing concrete protocol
addressed by the NSIS signaling protocol design. Although the base proposals. These proposals either rely on existing security
protocol might be secure, some extensions may cause problems when mechanisms or develop their own if the existing mechanisms
used in a particular environment. Furthermore it is necessary to cannot counter all relevant security threats or if they are
investigate the context in which a signaling protocol is used and the inappropriate for other reasons. In practice, a protocol
architecture where it is integrated. As an example of such an proposal might use established security mechanisms or
interaction accounting and charging is often mentioned in protocols for basic protection, but is likely to require some
relationship with QoS signaling protocols. Without an appropriate additional protection mechanisms, or a combination of both for
integration of the two there is no good incentive for network enhanced security.
Tschofenig Informational - Expires April 2003 3 Note that the process of developing the above-mentioned
NSIS Threats October 2002 documents is not linear. Instead it takes various iterations
to reach a satisfactory NSIS security solution.
operators to deploy QoS signaling protocols. This interaction is Security Threats for NSIS:
subject of a framework and some aspects are discussed in [5].
1.2 Involved Network Parts This document identifies the basic threats that need to be
addressed by the NSIS signaling protocol design. In addition,
although the base protocol might be secure, some extensions
may cause problems when used in a particular environment.
Furthermore it is necessary to investigate the context in
which a signaling protocol is used and the architecture where
it is integrated. As an example of such interaction accounting
and charging are taken into account in this document, since
without an appropriate integration of the two it is difficult
to deploy any NSIS solution. This interaction is also subject
of the NSIS framework and some aspects are discussed in [7].
Independent of the threat scenarios described in Section 2 end-to-end 1.2 Relevant communication models
signaling messages traverse different network parts, which demand
different security mechanisms caused by the difference in trust
relationships. The sub-parts are: access network part, intra and
inter-domain part, and finally end-to-end communication. These parts
are briefly described in this section and the threat scenarios of
Section 2 can be assigned to the individual parts.
a) Access Network (or First-Peer) Communication Independent of the threat scenarios described in Section 2 signaling
messages traverse different network parts, which demand different
security means. The difference in security protection is mainly caused
by the fact that the NSIS signaling messages cross trust boundaries
where different trust relationships are prevalent. Often a
categorization into first-peer/last-peer, intra-domain and inter-domain
communication is applicable (see Figure 2). Depending on the concrete
security requirements end-to-end security protection across trust
boundaries might be required for certain scenarios but is usually not
easily addressable by standard means. The main properties of the listed
network parts are briefly described in this section and the threat
scenarios of Section 2 are classified accordingly. Figure 2 depicts a
typical end-to-end communication scenario including an access part
between the NSIS end entities and the nearest NSIS hops, respectively.
This "first-peer communication" commonly comes with specific security
requirements, especially important for properly addressing security in
mobile scenarios. Differences in the trust relationship and the required
security for first-peer communication, compared to other parts of the
signaling path, might exist.
The term access network is fuzzy but in this context we refer to the If signaling messages are not exchanged end-to-end and only parts of the
communication between an end host and the first NSIS aware entity in signaling path are affected, some threats may not be relevant.
the network to which this host is attached. Therefore threats are
addressed where an NSIS Initiator (NI) transmits and receives
signaling messages to some entity in the access network. In many
mobility environments it is difficult to assume the existence of a
pre-established trust relationship between a user and the access
network.
Threat scenarios dealing with initial security association setup, To further refine the above differentiation based on network parts that
replay attacks, lack of confidentiality, denial of service, integrity NSIS signaling may traverse, we consider trust relationships between
violation, identity spoofing and fraud are applicable. From a +------------------+ +---------------+ +------------------+
security point of view this part of the network causes the largest | | | | | |
number of problems. | Administrative | | Intermediate | | Administrative |
| Domain A | | Domains | | Domain B |
| | | | | |
| (Inter-domain Communication) |
| +---------+---+---------------+---+---------+ |
| (Intra-domain | | | | (Intra-domain |
| Communication) | | | | Communication) |
| | | | | | | |
| | | | | | | |
+--------+---------+ +---------------+ +---------+--------+
^ v
| |
First Peer Communication Last Peer Communication
| |
+-----+-----+ +-----+-----+
| NSIS | | NSIS |
| Initiator | | Responder |
+-----------+ +-----------+
b) Intra-Domain Communication Figure 2: Involved Network Parts
After receiving a NSIS signaling message and verifying the request NSIS hops. Additional threats may apply to NSIS communication where one
somewhere in the access network the signaling message traverses the entity involved is an end-entity (initiator or responder) and the other
network within the same administrative domain. Since the request has entity is any intermediate hop not being the first peer. This is
already been authenticated and authorized threats are different typically called end-to-middle scenario. The motivation for including
compared to those described in the previous section. To differentiate this configuration stems for example from the SIP [8] protocol. Any
the end-node-to-access network interface with the intra-domain intermediate SIP proxy may request a SIP end entity (UA) to
communication we assume that no user hosts are logically attached to authenticate, countering a number of specific security threats. Such
the core-network. (That is: the interface between any host and the functionality in general seems to be useful for intermediaries at the
first router is part of the access network). We furthermore assume borders of trust domains that signaling messages need to traverse.
that nodes within one administrative domain have a stronger trust Intermediate NSIS hops as well may have to deal with specific security
relationship between each other. threats that do not (directly) relate to end-entities. Between such
intermediate hops, other such NSIS hops will typically be in the
signaling path. This scenario is called middle-to-middle. A generic
example are two NSIS hops at the border of their respective trust
domains with some form of trust relation. NSIS messages between these
hops may have to traverse one or more intermediate untrusted hops.
Figure 3 illustrates these additional scenarios. The first-peer case
discussed further above is covered by the peer-to-peer trust
relationships between end entity and closest hop, respectively.
c) Inter-Domain Communication ****************************************
* *
+----+-----+ +----------+ +----+-----+
+-----+ NSIS +-------+ NSIS +--------+ NSIS +-----+
| | Node 1 | | Node 2 | | Node 3 | |
| +----------+ +----+-----+ +----------+ |
| ~ |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| ~ |
+--+--+-----+ +---------+-+
| NSIS +//////////////////////////////////////////+ NSIS |
| Initiator | | Responder |
+-----------+ +-----------+
The threat assumptions between the borders of different Legend:
administrative domains largely depends on how accounting is done. If -----: Peer-to-Peer Trust Relationship
one domain transmits forged QoS reservations to next domain then it /////: End-to-End Trust Relationship
is likely that the originating network domain has also has to pay for *****: Middle-to-Middle Trust Relationship
the reservation. Hence in this case, there is no real benefit for the ~~~~~: End-to-Middle Trust Relationship
first network domain to forge a QoS reservation. But if an end-node
is directly charged by intermediate domains then this kind of attack
may be reasonable. Security protection of messages transmitted
Tschofenig Informational - Expires April 2003 4 Figure 3: Trust Relationships
NSIS Threats October 2002
between different administrative domains is still necessary to tackle First-Peer Communication:
attacks like spoofing, integrity violation, denial of service etc.
The lower number of networks and higher trust relationship (compared
in the access network case), the fewer problems for key management
arise.
d) End-to-End Communication First peer communication refers to the peer-to-peer
interaction between a signaling message originator, the NSIS
Initiator (NI), and the first NSIS aware entity along the
path. Assumptions about the threats, security requirements and
the available trust relationships may be difficult here. To
illustrate this, in many mobility environments it is difficult
to assume the existence of a pre-established security
association directly available for NSIS peers involved in
first-peer communication, as these peers cannot be assumed to
have any relation between each other in advance. For
enterprise networks, in contrast, the situation is different.
Usually there is a fairly strong (pre-established) trust
relationship between the peers. Enterprise network
administrators usually have some degree of freedom to select
the appropriate security protection and to enforce it. The
choice of selecting a security mechanism is therefore often
influenced by the already available infrastructure. Per-
session negotiation of security mechanisms is therefore often
not required (which, in contrast, is required for the mobility
case).
In our opinion end-to-end security for NSIS signaling messages (in For first-peer communication, especially threats related to
addition to hop-by-hop security) is rarely required if we assume that initial security association setup, replay attacks, lack of
end-to-end issues like charging and the selection which user has to confidentiality, denial of service, integrity violation,
pay for a reservation is already securely negotiated by preceding identity spoofing and fraud are applicable.
upper layer protocols (for example SIP). Information carried within a
NSIS signaling protocol for the purpose of charging is therefore
assumed opaque to the NSIS protocol itself and appropriately
protected as part of the AAA interaction. Note however that this
assumption strongly depends on the chosen solution of a protocol
interaction with AAA, QoS and application layer protocol. It is
however possible to select a charging solution that requires end-to-
end protection of information delivered within the QoS signaling
protocol.
The following example requires some sort of end-to-end protection: End-to-Middle Communication:
Alice wants Bob to pay for the QoS reservation (reverse charging).
Bob wants to be assured that the QoS signaling message he receives
was transmitted by Alice because he is only willing to pay for
particular users and not for everyone. Hence Bob requires Alice to
protect the reservation request.
Regarding end-to-end security one additional issue needs to be End-to-middle interaction in signaling may be required to e.g.
clarified. Whenever a signaling protocol travels end-to-end and a grant end-entities access to, or specific services in trust
node along the path acts on behalf of the other endpoint then further domains different from the one the first peer belongs to.
investigation is required how to solve this issues. Threats, in addition to these already discussed for first-hop
communication, may be untrusted intermediate NSIS hops that
maliciously alter NSIS signaling. These threats are still
relevant if security mechanisms are in place between the NSIS
hops, but terminate at each hop (e.g. IPsec hop-by-hop
protection).
1.3 Clarification Intra-Domain Communication:
Some threat scenarios in this document use the term user instead of After having been verified at the first peer, an NSIS
NSIS Initiator. This is mainly due to the fact that security signaling message traverses the network within the same
protocols allow a differentiation between entities being hosts and administrative domain the first peer belongs to. Since the
users (based on the identities used). Since the NSIS Initiator as request has already been authenticated and authorized threats
used in [5] also allows to act on behalf of various entities are different to those described above in a). To differentiate
including a network it is reasonable to distinguish between these first-peer communication with the intra-domain communication
identities. (i.e. communication internally within one administrative
domain) we assume that no end hosts have direct access to the
internal network nodes, except the first peer. We furthermore
assume that NSIS peers within the same administrative domain
have at least some sort of trust relationship.
The term access network is used for networks to which a mobile node Inter-Domain Communication:
is attached. Other terms often used in this context are foreign or
visited network. The missing direct trust relationship between the
mobile node and the access network complicates authentication and key
agreement. Usually AAA protocols (like Radius or Diameter) are used
to provide the initial authentication and key establishment. These
protocols take advantage of the AAA infrastructure (AAAL, AAAH,
Broker, etc.) and trust relationships between the access network and
the users home network. This trust relationship is usually based on
some sort of business contract. The trust relationship between the
Tschofenig Informational - Expires April 2003 5 The threat assumptions between the borders of different
NSIS Threats October 2002 administrative domains largely depend on accounting procedures
(and therefore business relationships) in case of QoS
signaling, which is an important example application of NSIS
signaling. If one domain transmits forged QoS reservations
(for example stating a higher QoS reservation than a
aggregated number of user did) to the next domain then the
originating domain may also have to pay for the reservation.
Hence in this case, there is no real benefit for the first
network domain to forge a QoS reservation. If an end host is
directly charged by domains different to the first peer's
domain, then such an attack may be quite a reasonable threat.
However, security protection of messages transmitted between
different administrative domains is still necessary to tackle
attacks like spoofing, integrity violation, or denial of
service between these domains, e.g. to allow for proper
accounting. In case of securing signaling messages between
administrative domains, the number of domains is usually
rather limited (compared to first-peer communication) which
causes fewer problems for the key management.
two networks is considered to be symmetric (network A trusts network Signaling information other than QoS service parameters such
B and vice versa) whereas the dynamically established trust as policy rules in case of middlebox communication demands
relationship between the mobile node and the access network is often different assumptions for inter-domain communication. Trust
asymmetric. In today's network a mobile node has to trust the access assumptions and business relationships are of particular
network with regard to collection and processing of accounting data. importance for their communication.
The access network usually does not trust attached end-hosts.
The term security association is used to describe established If signaling messages are transparent in the core network
security-relevant data structure between two entities. This data (i.e. the are not intercepted and processed in the core
structure consists of keys, algorithms including their parameters, network) then the signaling message communication effectively
values used for replay protection etc. Using this information two (or takes place between access networks. This might place a burden
more) nodes are able to protect signaling messages. on the key management infrastructure because of the global PKI
requirements. Hence this can be seen as a serious deployment
threat since it might be unacceptable for an access network
service provider to perform processing (QoS reservations,
policy rule installation at firewalls) due to unprotected
incoming signaling messages.
End-to-End Communication:
Providing end-to-end signaling message protection for NSIS
would cause difficulties for authentication and key
establishment procedures. It would furthermore limit the
flexibility of a signaling protocol in general. Functionality
such as terminating at an arbitrary location along the path,
delegating a signaling message exchange to other nodes, etc.
would be difficult to achieve in a secure fashion. Protecting
signaling messages end-to-end (in addition to peer-to-peer
security) is in our opinion rarely required. This is based on
the observation that end-to-end issues like charging and
payment selection (i.e. which user has to pay for which part
of a QoS reservation) are already securely negotiated by
preceding upper layer protocols (for example SIP). Information
carried within an NSIS signaling protocol for the purpose of
charging is therefore assumed opaque to the NSIS protocol
itself. Note that this observation makes some assumptions
about the charging model and about the existence of a protocol
interaction with AAA, QoS and an application layer protocol.
It is however possible to imagine a charging solution that
requires end-to-end protection of information delivered within
the NSIS signaling protocol. The following example requires
some sort of end-to-end protection: Alice wants Bob to pay for
a QoS reservation (reverse charging). Bob wants to be assured
that the QoS signaling message he receives was transmitted by
Alice because he is only willing to pay for particular users
and not for everyone. Hence Bob requires Alice to protect the
reservation request.
Regarding end-to-end security one additional issue needs to be
addressed - delegation. Whenever a signaling is addressed end-
to-end and an arbitrary node along the path acts as a proxy on
behalf of the other endpoint a delegation mechanism is
required to provide secure interaction. This obviously leads
to additional complexity in the area of end-to-end security,
as an additional set of threats becomes relevant.
Middle-to-middle:
We do not explicitly consider the middle-to-middle case here,
as this is already covered by either intra- or inter-domain
communication depending on the location of the involved
entities.
2 Threat Scenarios 2 Threat Scenarios
This section provides threat scenarios that are applicable to This section provides threat scenarios that are applicable to signaling
signaling protocols. protocols. Note that some threat scenarios use the term user instead of
NSIS Initiator. This is mainly because security protocols allow a
differentiation between entities being hosts and users (based on the
identities used).
2.1 Lack of Authentication and Man-in-the-Middle Attacks 2.1 MITM Attacks
This section describes man-in-the-middle attacks of the following Security protection of protocols is often separated into two steps. The
type: During the process of establishing a security association an first step provides entity authentication and key establishment whereas
adversary fools the signaling message initiator with respect to the the second step provides message protection using the previously
entity to which it has to authenticate. The man-in-the-middle established security association. The first step usually tends to be
adversary is able to modify signaling messages to mount DoS attacks. more expensive than the second which is also the main reason for
The signaling message initiator wrongly believes that it talks to the separation. If messages are transmitted very infrequently then these two
˘real÷ network whereas it is actually attached to an adversary. steps are collapsed into a single and usually rather costly step. One
For this attack to be successful, pre-conditions have to hold which such example is e-mail protection via S/MIME. A good example for an
are described with the following two cases: efficient two-step approach is provided by IPsec [9]. We use this
a) Missing Authentication separation to cover the different threats in more detail. The first
paragraph describes security threats where two peers do not already
share a security association, or do not use security mechanisms at all.
The next paragraph describes threats which are applicable when a
security association is already established. Finally a denial of service
attack is described which is applicable to a signaling message when no
The first case addresses missing authentication between the separation between SA establishment and signaling protection takes
neighboring peers: Without authentication a NI, NR or NF is unable to place.
detect an adversary. However in some cases protection available might
be difficult to accomplish in a practical environment either because
the other peer of the communication is unknown or because of
misbelieved trust relationships in parts of the network. If one of
the communication endpoints is unknown then for some security
protocols it is not possible or difficult to select the appropriate
security association. Sometimes network administrators refuse to
consider security protection of intra-domain signaling messages. Such
a configuration would then allow an adversary at a compromised node
to cause security problems. Even if there was no intention that this
compromised node actively participates in the signaling message
exchange its interference cannot be prevented.
b) Unilateral Authentication Various security threat are caused by a protocol performing dynamic node
discovery. These threats include Denial of Service attacks, which are
among other threats described in Section 2.9. Note that the threats are
largely independently of the discovery procedure (path discovery, next
peer discovery or topology discovery).
In case of only unilateral authentication the NI is not able to 1. Attacks during NSIS SA Establishment
discover the man-in-the-middle adversary. Although authentication of
signaling message should take place between each peer participating
in the protocol operation special focus is given to the communication
in the end host and the access network.
Tschofenig Informational - Expires April 2003 6 During the process of establishing a security association an
NSIS Threats October 2002 adversary fools the signaling message initiator with respect
to the entity to which it has to authenticate. The man-in-the-
middle adversary is able to modify signaling messages to mount
e.g. DoS attacks. In addition, it may be able to terminate
NSIS messages of the Initiator and inject messages to a peer
itself, therefore acting as the peer to the initiator and as
the initiator to the peer. This results in the initiator
wrongly believing that it talks to the "real" network whereas
it is actually attached to an adversary. For this attack to
be successful, pre-conditions have to hold which are described
with the following two cases:
The two threats described above are a general problem of network - Missing Authentication
access without appropriate authentication, not only for an NSIS
signaling protocol. Obviously there is a strong need to correctly
address them in a future NSIS protocol. The signaling protocols
addressed by NSIS are different to other protocols where only two
entities are involved. The impacts of a security breach likely reach
beyond the directly involved entities (or even beyond a local
network).
Finally it should be noted that the signaling protocol should be The first case addresses missing authentication between the
considered as a peer-to-peer protocol where the roles of initiator neighboring peers: Without authentication a NI, NR or NF is
and responder can be reversed at any time. This leads to the unable to detect an adversary. However in some cases
conclusion that unilateral authentication is not very useful for such protection available might be difficult to accomplish in a
a protocol. However there might be a need to have some form of practical environment either because the next peer is
asymmetry in the authentication process whereby one entity uses a unknown, because of misbelieved trust relationships in parts
different authentication mechanism than the other one. As an example of the network or because of the inability to establish
the combination of symmetric and asymmetric cryptography should be proper security protection (inter-domain signaling messages,
mentioned. dynamic establishment of a security association, etc.). If
one of the communication endpoints is unknown then for some
security mechanisms it is either not possible or very
difficult to apply appropriate security protection.
Sometimes network administrators use intra-domain signaling
messages without proper security. Such a configuration would
then allow an adversary on a compromised non-NSIS aware node
to interfere with nodes running an NSIS signaling protocol.
Note that this type of threat goes beyond a threat caused by
malicious NSIS nodes (described in Section 2.8).
2.2 Missing Authorization - Unilateral Authentication
In case of a unilateral authentication the NSIS entity that
does not authenticate its peer is unable to discover the
man-in-the-middle adversary. Although authentication of
signaling messages should take place between each peer
participating in the protocol operation special attention is
given here to first-peer communication. Unilateral
authentication between end hosts and the first peer is still
common today, but certainly opens up many possibilities for
MITM attackers impersonating either the end host or the
(administrative domain represented by the) first peer.
Authentication as described in Section 2.1 is a very important step The two threats described above are a general problem of
for providing the foundation for authorization and accounting. Unlike network access without appropriate authentication, not only
some other protocols where authorization can be verified without huge for an NSIS signaling protocol. Obviously there is a strong
difficulties NSIS protocols might experience some difficulties. First need to correctly address them in a future NSIS protocol.
there is the question what authorization means in the context of NSIS The signaling protocols addressed by NSIS are different to
signaling and particularly for quality of service and middlebox other protocols where only two entities are involved. Note,
communication. The possible range is broad and could range from pure that especially first-peer authentication is important, as
monetary policies to traditional role-based access control policies. the impacts of a security breach likely reach beyond the
Second there is a question where this authorization data can be directly involved entities (or even beyond a local network).
retrieved. Especially in a mobile environment this might be more
complicated to securely exchange this information between different
network domains. Finally there is an issue of representing
authorization information if it has to be shared between a number of
network domains.
Currently the above-mentioned issues have not been appropriately Finally it should be noted that the signaling protocol
addressed and might cause obstacles for deployment. should be considered as a peer-to-peer protocol where the
In a discovery phase an additional issue of authorization was raised. roles of initiator and responder can be reversed at any
Whenever a node wants to discover the next NSIS aware node then time. This leads to the conclusion that unilateral
authentication might not be sufficient. In many cases the IP address authentication is not very useful for such a protocol.
or FQDN of a particular router in an unknown network does not add too However there might be a need to have some form of asymmetry
much trust. An end host for example might want some assurance that in the authentication process whereby one entity uses a
this node belongs to a network with which some sort of business different authentication mechanism than the other one. As an
relationship (directly or indirectly) is available. example the combination of symmetric and asymmetric
cryptography should be mentioned.
2.3 Missing Cost Control - Weak Authentication
This type of threat addresses a deployment problem of QoS signaling This threat addresses weak authentication mechanisms whereby
in a real-world environment. It is not a particular attack. A large information transmitted during the NSIS SA establishment
number of service providers with complex roaming agreements create a process may leak passwords and/or may allow offline
non-transparent cost-structure. Using AAA protocols in a dictionary attacks. This threat is not specific to NSIS
subscription-based scenario. In a traditional subscription-based signaling protocols but may also be applicable and
countermeasures must be taken.
Tschofenig Informational - Expires April 2003 7 2. Attacks during NSIS SA Usage
NSIS Threats October 2002
scenario users are registered with their home networks and use this Once a security association is establish (and used to protect
trust relationship to dynamically establish other security signaling messages) basic attacks are prevented. However, a
associations. In these scenarios users do not learn the identity of malicious NSIS node is still able to perform various attacks
the access network as part of a regular message exchange. The user is as described in Section 2.8. Replay attacks, which can be a
therefore only authenticated to the home network (and hopefully vice problem when a NSIS node crashes, restarts and performs state
versa). The identity of the access network is possibly not revealed. re-establishment. Proper re-synchronization capability of the
When issuing a reservation request to an entity in the access network security mechanism must therefore address this problem.
the end-user does not know the cost of such a reservation.
Furthermore due to mobility and route changes along the path the
costs for an end-to-end QoS reservation might not be transparent or
unacceptable.
Today there is no protocol available which allows users to 3. Combining Signaling and SA Establishment
communicate cost limits, to request costs for network resources or to
learn the currently accumulated costs for a particular reservation.
Especially in mobility environments where many networks might be This threat covers an attack which allows an adversary to
contacted in a short period of time cost control is even more flood an NSIS node with bogus signaling messages to cause a
complicated. denial of service attack.
Some proposals which try to merge mobility protocols with QoS When a signaling message arrives at a NSIS aware network
signaling probe the access network (towards the cross-over router or element some processing is required. If this message contains
the MAP) for the possibility making a QoS reservation (without security objects such as digital signatures and not security
actually making the reservation itself). Without a query mechanism a association is already available then some processing is
user cannot take reservation costs into account when choosing between required for the cryptographic verification. Since NSIS
different access networks. Hence the user might not be unable to signaling should not require several roundtrips between two
refuse the more expensive service provider. To allow a user to choose NSIS peers it is difficult to provide DoS protection
different providers might be required not only because of the mechanisms commonly found in authentication and key agreement
availability of different access technologies (either using a WLAN protocols. If signaling messages furthermore aim to be
card to access the local network or to use UMTS/UTRAN based idempotent and no security association should be created then
technology) and the different service quality offered but also for some cryptographic mechanisms should be used with precaution
cost reasons. (for example public key cryptography).
Although real-time notifications of quality of service reservation Additionally to the threat described above an incoming
costs (cost control) to the user are outside the scope of a quality signaling message might require time consuming processing
of service signaling protocol itself some interactions might be (computations, state maintenance, timer setting, etc) and
required. Note that payment issues should be discussed independently communication with third-party nodes including policy servers,
of cost-control since other mechanisms are required to negotiate LDAP servers, etc. If an adversary is able to transmit a large
which involved party actually has to pay the costs (and how). number of signaling message (for example with QoS reservation
requests) with invalid credentials then the verifying node may
not be able to process further reservation messages by
legitimate users.
2.4 Eavesdropping and Traffic Analysis 2.2 Eavesdropping and Traffic Analysis
This section covers two threats: The first is related to privacy This threat cases covers adversaries which are able to eavesdrop
concerns whereas the second addresses problems caused by weak signaling messages but are unable to actively participate in signaling
authentication mechanisms and the increased risk of eavesdropping on message exchange (i.e. passive adversary). The collected signaling
the wireless link in absence of appropriate confidentiality packets may serve for the purpose of traffic analysis or to later mount
protection. replay attacks as described in the Section 2.3. The eavesdropper might
learn QoS parameters, communication patterns, policy rules for firewall
traversal, policy information, application identifiers, user identities,
NAT bindings and more.
The first threat case covers adversaries which are able to eavesdrop 2.3 Adversary being able to replay signaling messages
signaling messages but are unable to actively participate in the QoS
signaling (i.e. passive adversary). The collected signaling packets
may serve for the purpose of traffic analysis or to later mount
replay attacks as described in the next section. By eavesdropping an
adversary might violate a user's privacy preference. Especially QoS
Tschofenig Informational - Expires April 2003 8 This threat scenario covers the case where an adversary eavesdrops and
NSIS Threats October 2002 collects signaling messages and replays them at a latter point in time
(or at a different place, or uses parts of them at a different place or
signaling messages provide information that may be interesting for an in a different way - e.g. cut and paste attacks). Without proper replay
adversary since the messages reveal user and/or application protection an adversary might mount man-in-the-middle, denial of service
identities, policy information, information about the desired QoS and theft of service attacks.
reservation, etc. The information gathered by an adversary can be
used to learn communication patterns of users requesting resources
(QoS, firewall, NAT, etc.).
An adversary might be able to use the signaling protocol to discover A more difficult attack that may cause problems even in case of replay
the topology of a network (e.g. using record route). Additionally it protection requires the adversary to crash an NSIS aware node to loose
might be possible to obtain diagnostic information usually used for state information (sequence numbers, security associations, etc.) and to
network monitoring and administration. Other options might allow an be able to replay old signaling messages. This attack addresses re-
adversary to route signaling messages specifically along a particular synchronization deficiencies.
route similar to source routing.
The second threat case addresses weak authentication mechanisms 2.4 Missing Protection of Authorization Information
whereby information transmitted within the QoS signaling protocol may
leak passwords and may allow offline dictionary attacks. This threat
is not specific to QoS signaling protocols but may also be applicable
and countermeasures must be taken.
2.5 Adversary being able to replay signaling messages Authorization is an important step for providing resources such as QoS
reservations, NAT bindings and pin-holed firewalls. Authorization
information might be delivered to the NSIS participating entities in a
number of ways.
This threat scenario covers the case where an adversary eavesdrops One such approach is to use a successful authorization step done by a
and collects signaling messages and replays them at a latter point in different protocol in a later NSIS signaling message by providing some
time (or at a different place, or uses parts of them at a different sort of token. The functionality and structure of such an authorization
place or in a different way ű e.g. cut and paste attacks). Without token for RSVP is described in [10] and in [11].
proper replay protection an adversary might be able to mount denial
and/or theft of service attacks.
A more difficult attack that may cause problems even in case of The interaction between different protocols based on authorization
replay protection requires the adversary to crash a NSIS aware node tokens, however, requires some care. Using such an authorization token
to loose state information (sequence numbers, security associations, it is possible to link state information between different protocols.
etc.) and to be able to replay old signaling messages. Returning an unprotected authorization token to the end host might allow
an adversary (for example an eavesdropper) to steal resources. An
adversary might also use the token to learn communication patters. An
untrustworthy end host might also modify the token content.
Additionally it should be mentioned that the interaction between Other authorization mechanisms might depend on availability of
different protocols based on authorization tokens requires some care. sufficient funds and therefore real-time information. Deployment threats
Using such an authorization token it is possible to link state of this kind are described in Section 2.14. The Session/Reservation
information between different protocols. Returning an authorization Ownership problem can also be considered as an authorization problem.
token to the end host might allow an adversary to steal resources Details are described in Section 2.11. In enterprise networks
without proper protection of the token delivery or without proper authorization is often coupled with membership to a particular class
verification of the hopefully protected content of the token. The user of users/groups. This type of information can either be delivered
functionality and structure of such an authorization token for RSVP as part of the authentication and key agreement procedure or has to be
is described in [3] and in [4]. retrieved via separate protocols from other entities. If an adversary
manages to modify information relevant for determining authorization or
the outcome of the authorization process itself then theft of service
might be the consequence.
2.6 Identity Spoofing 2.5 Identity Spoofing
The following paragraph gives an example of an adversary using Identity spoofing relevant for NSIS appears in two flavors: First,
identity spoofing: identity spoofing can appear during the establishment of a security
association if based on a weak authentication mechanism.
Eve, acting as an adversary, claims to be the registered user Alice Eve, acting as an adversary, claims to be the registered user Alice by
by spoofing the identity of Alice. Thereby Eve causes the network to spoofing the identity of Alice. Thereby Eve causes the network to charge
charge Alice for the consumed network resources. Using unprotected Alice for the consumed network resources. This type of attack is
signaling messages Eve may experience no particular problems in possible if authentication is done based on a simple username identifier
succeeding. This attack can be classified as theft of service. (i.e. in absence of cryptographic authentication) or if authentication
is provided for hosts and multiple users have access to a single host.
This attack could also be classified as theft of service.
Tschofenig Informational - Expires April 2003 9 Second, an adversary is able to perform identity spoofing on transmitted
NSIS Threats October 2002 data packets. This type of attack is often labeled as IP spoofing. Since
most NSIS signaling messages contain some sort of flow identifier for
which a certain behavior is performed (e.g. particular flow experiences
QoS treatment or is allowed to bypass a firewall, etc.) an adversary
could mount an attack by modifying the flow identifier of a signaling
message. The following example tries to show an adversary using identity
spoofing of the first category:
If a signaling message is properly protected the adversary is unlike An adversary is able to exploit the established flow identifiers
to succeed. (required for QoS and Midcom specific signaling protocols). Some
identifiers such as IP addresses, transport protocol identifiers, port
numbers, flow labels (see [12] and [13]) and others are communicated in
these protocols. Modification of these flow identifiers cause quality of
service reservations or policy rules at middleboxes to be either
ineffective or beneficial for adversaries.
A non-traditional identity spoofing attack exploits flow The following paragraph describes a possible threat caused by identity
classification (required for QoS and Midcom specific signaling spoofing of transmitted data traffic. The spoofed identity is thereby
protocols). Some identifiers such as IP addresses, transport protocol the source IP addresses. For this attack to be successful accounting
identifiers, port numbers, flow labels [6, 7] and others are records are collected based on the source IP address and not on a SPI
communicated in these protocols and represent an attractive target due to IPSec protection. After the network receives a properly protected
for an adversary. Modification of these flow identifiers cause reservation request, transmitted by the legitimate user Alice, Traffic
quality of service reservations or policy rules at middleboxes to be Selectors are installed at the corresponding devices (for example edge
either ineffective or beneficial for adversaries. router). These Traffic Selectors are used for flow identification and
allow to match data traffic originated from a given source address to be
assigned to a particular QoS reservation. The adversary Eve now spoofs
the IP address of the Alice. Additionally Alice's host may be crashed by
the adversary as a result of a denial of service attack or lost
connectivity for example because of mobility reasons. If both nodes are
located at the same link and use the same IP address then obviously a
duplicate IP address will be detected. Assuming that only Eve is present
at the link then she is able to receive and transmit data (for example
RTP data traffic), which receives preferential QoS treatment based on
the previous reservation. Depending on the installed Traffic Selector
granularity Eve might have more possibilities to exploit the QoS
reservation or a pin-holed firewall. Assuming the soft state paradigm,
where periodical refresh messages are required, the absence of Alice
will not be detected until the next signaling message appears and forces
Eve to respond with a protected signaling message. Again this issue is
Additional concerns might occur if end hosts perform traffic marking not only applicable to QoS traffic but the existence of QoS reservation
(for example by using a DSCP). Whenever an ingress router uses only causes more difficulties since this type of traffic is more expensive.
marked incoming data traffic for admission control procedures then The same procedure is also applicable to a Middlebox communication
various attacks are possible. These problems are known in the protocol.
DiffServ community for a long time and documented in various DiffServ
related documents. The IPSec protection of DiffServ Code Points is
described in Section 6.2 of [11]. Related security issues (for
example denial of service attacks) are described in Section 6.1 of
the same document.
The following paragraph describes a possible threat caused by The ability for an adversary to inject data traffic which matches a
identity spoofing of transmitted data traffic. The spoofed identity certain Traffic Selector established by a legitimate user often requires
is thereby the source IP addresses. Assume that accounting records the ability to also receive the data traffic. This is, however, only
are collected based on the source IP address and not on a SPI due to true if the Traffic Selector consists of values which contain addresses
IPSec protection. After the network receives a properly protected used for routing. If we imagine to use attributes for a Traffic Selector
reservation request, transmitted by the legitimate user Alice, where such a property is not required then identity spoofing and
Traffic Selectors are installed at the corresponding devices (for injecting traffic is much easier. An adversary can use a nearly
example edge router). These Traffic Selectors are used for flow arbitrary endpoint identifier to experience the desired result.
identification and allow to match data traffic originated from a Obviously the endpoint identifiers are still not irrelevant since the
given source address to be assigned to a particular QoS reservation. messages have to travel the same path through the network. DiffServ
The adversary Eve now spoofs the IP address of the Alice. marking of IP packets is such an example and others can be constructed
Additionally AliceĂs host may be subject of a DoS attack by and by very easily.
the adversary. If both nodes are located at the same link and use the
same IP address then obviously a duplicate IP address will be
detected. Assuming that only Eve is present at the link then she is
able to receive and transmit data (for example RTP data traffic),
which receives preferential QoS treatment based on the previous
reservation. Depending on the installed Traffic Selector granularity
Eve might have more possibilities to exploit the QoS reservation or a
pin-holed firewall. Assuming the soft state paradigm, where
periodical refresh messages are required, the absence of Alice will
not be detected until the next signaling message appears and forces
Eve to respond with a protected signaling message. Again this issue
is not only applicable to QoS traffic but the existence of QoS
reservation causes more difficulties since this type of traffic is
more expensive. The same procedure is also applicable to a Middlebox
communication protocol.
2.7 Adversary being able to inject/modify messages Data traffic marking based on DiffServ is such an example. Whenever an
ingress router uses only marked incoming data traffic for admission
control procedures then various attacks are possible. These problems are
known in the DiffServ community for a long time and documented in
various DiffServ related documents. The IPSec protection of DiffServ
Code Points is described in Section 6.2 of [14]. Related security issues
(for example denial of service attacks) are described in Section 6.1 of
the same document.
Tschofenig Informational - Expires April 2003 10 2.6 Adversary being able to inject/modify messages
NSIS Threats October 2002
The next type of threat addresses an integrity violations: An This type of threat addresses integrity violations whereby an adversary
adversary modifies signaling messages (e.g. by acting as a man-in- modifies signaling messages (e.g. by acting as a man-in-the-middle
the-middle) to cause an unexpected network behavior with a bogus attacker) to cause an unexpected network behavior. Possible actions an
signaling message. Possible actions are reordering, delaying, adversary might consider for its attack are reordering, delaying,
dropping, injecting and modifying. dropping, injecting and modifying.
An adversary may inject a signaling message requesting a large amount An adversary may inject a signaling message requesting a large amount of
of resources (using a different user identity). If granted it causes resources (possibly using a different user identity). Other resource
other user's resource-request not to be successful and a different requests could then be rejected. In combination with identity spoofing
initiator (for example a user) to pay for the QoS reservation. This it is also possible accomplish fraud. This attack is only successful in
attack is only successful in absence of signaling message protection. absence of signaling message protection.
2.8 Missing Non-Repudiation Some directly related threats are described in Section 2.8, 2.5, 2.8 and
2.9.
2.7 Missing Non-Repudiation
Repudiation in this context refers to a problem where one party later Repudiation in this context refers to a problem where one party later
denies to have made a reservation. This issue comes in two flavors: denies to have requested a certain action (such as a QoS reservation).
From a service provider point-of-view the following threat may be The problem of a missing non-repudiation property appears in two
worth an investigation. A user may deny to have issued reservation flavors:
request for which it was charged. A service provider may then like to
prove that a particular user issued reservation requests. >From a service provider point-of-view the following threat may be worth
an investigation. A user may deny to have issued reservation request for
which it was charged. A service provider may then like to prove that a
particular user issued reservation requests.
The same threat can be interpreted from the users point-of-view. A The same threat can be interpreted from the users point-of-view. A
service provider claims to have received a number of reservation service provider claims to have received a number of reservation
requests. The user in question thinks that he never issued those requests. The user in question thinks that he never issued those
requests and wants to have a proof for correct service usage for a requests and wants to have a proof for correct service usage for a given
given set of QoS parameters. set of QoS parameters.
In today's telecommunication networks non-repudiation is not
provided. The user has to trust the network operator to correctly
meter the traffic, collect and merge accounting data and that no
unforeseen problems occur. If a signaling protocol is used to
establish QoS reservations with a higher volume (for example service
level agreements) then it might impact protocol design.
2.9 Malicious NSIS Entity In today's telecommunication networks non-repudiation is not provided.
The user has to trust the network operator to correctly meter the
traffic, collect and merge accounting data and that no unforeseen
problems occur. If a signaling protocol is used to establish QoS
reservations with a higher volume (for example service level agreements)
then it might impact protocol design.
Network elements within a domain (intra-domain) experience a Looking at threats based on missing non-repudiation it must be carefully
different trust relationship with regard to the security protection considered whether non-repudiation is needed. Non-repudiation poses
of signaling messages compared to edge routers. We assume that edge additional requirements on the security mechanisms as it can only be
routers have the responsibility to perform cryptographic processing provided through public-key cryptography. As this would often increase
(authentication, integrity verification, replay protection, the overall cost for security, threats related to missing non-
authorization, etc.). Depending on the protocol functionality every repudiation are only considered relevant for certain specific scenarios
NSIS aware router should be able to issue signaling messages. If but not for the general NSIS scenario.
however an adversary manages to take over an edge router then the
security of the entire network is affected. An adversary is then able
to launch a number of attacks including denial of service, integrity
violation, replay attacks etc. Note that this problem is not only
restricted to QoS signaling protocols. In case of policy rule
installation a rogue firewall can cause harm to other firewalls by
modifying the policy rules accordingly.
The chain-of-trust principle applied in the peer-to-peer security 2.8 Malicious NSIS Entity
protection cannot provide proper protection. An adversary with full
Tschofenig Informational - Expires April 2003 11 Network elements within a domain (intra-domain) experience a different
NSIS Threats October 2002 trust relationship with regard to the security protection of signaling
messages compared to edge routers. We assume that edge routers have the
responsibility to perform cryptographic processing (authentication,
integrity and replay protection, authorization and accounting) for
signaling message arriving from outside. This prevents signaling
messages to appear unprotected within the internal network. If however
an adversary manages to take over an edge router then the security of
the entire network is affected. An adversary is then able to launch a
number of attacks including denial of service, integrity violation,
replay attacks etc. In case of policy rule installation a rogue firewall
can cause harm to other firewalls by modifying the policy rules
accordingly. The chain-of-trust principle applied in the peer-to-peer
security protection cannot provide protection against a malicious NSIS
node. An adversary with access an NSIS router is then also able to get
access to security associations to transmit secured signaling messages.
Note that even non peer-to-peer security protection might not be able to
access to the edge router is then also able to retrieve security fully prevent this problem. Since an NSIS node might issue signaling
associations to secure signaling messages. Note that even non-peer- message on behalf of someone else (by acting as a proxy) additional
to-peer security protection might not be able to fully prevent this problems are the consequence.
problem.
Thus the edge router is a critical component that requires strong An NSIS aware edge router is a critical component that requires strong
security protection. Strong security policy applied at edge routers security protection. A strong security policy applied at edge does not
does not imply that intra-domain routers do not need to imply that all routers within an intra-domain network do not need to
cryptographically verify signaling messages. If the chain-of-trust cryptographically verify signaling messages. If the chain-of-trust
principle is deployed then the security protection of the path (in principle is deployed then the security protection of the entire path
this case within the network of a single administrative domain) is as (in this case within the network of a single administrative domain) is
strong as the weakest link. In our case the edge router is the most as strong as the weakest link. In our case the edge router is the most
critical component of this network that may also act as a security critical component of this network that may also act as a security
gateway/firewall for incoming/outgoing traffic. For outgoing traffic gateway/firewall for incoming/outgoing traffic. For outgoing traffic
this device has to act according to the security policy of the local this device has to act according to the security policy of the local
domain to apply the appropriate security protection. domain to apply the appropriate security protection.
2.10 Denial of Service in a two phase reservation For an adversary to mount this attack either an existing NSIS aware node
along the path has to be successfully attacked or an adversary succeeds
to convince another NSIS node to be the next NSIS peer (man-in-the-
middle attack).
This threat tries to address potential denial of service attacks when 2.9 Denial of Service Attacks
the reservation setup is split into two phases path discovery/path
pinning and reservation (as for example used in a receiver-initiated
reservation). For this example we assume that the node transmitting
the path message is not charged for the path message itself and is
able to issue a high number of reservation request (possibly in a
distributed fashion). Charging is activated only after successful
verification of the reservation request. The reservations are however
never intended to be successful because of various reasons: the
destination node cannot be reached; it is not responding or simply
rejects the reservation. An adversary can benefit from the fact that
resources are already consumed along the path for various processing
tasks including path pinning.
2.11 Denial of Service with a bogus signaling request A number of denial of service attacks can cause NSIS nodes to
malfunction. Other attacks that could lead to DoS, such as man-in-the-
middle attacks, replay attacks, injection or modification of signaling
messages etc., are mentioned throughout this document.
With a resource reservation request received at a network element 1. Path Finding
(for example by the first NSIS aware router) processing is required
for authentication and authorization. Processing by other nodes
including policy servers, LDAP servers, etc. is also possible
depending on the network infrastructure. Verification requires
cryptographic computations, state maintenance, setting timers,
transmitting messages and other processing actions. If an adversary
is able to transmit a large number of reservation request with bogus
credentials (and assuming that the verification is expensive in terms
of resource consumption) then the verifying node may not be able to
process further reservation messages by legitimate users. This
assumes that verification is expensive (especially cryptographic
computations).
2.12 DoS Attack at the Discovery Phase This threat tries to address potential denial of service
attacks when the reservation setup is split into two phases
i.e. path and reservation (as for example used in receiver
based reservation setup). For this example we assume that the
node transmitting the path message is not charged for the path
message itself and is able to issue a high number of
reservation request (possibly in a distributed fashion).
Charging is activated only after successful verification of
the reservation request. The reservations are however never
intended to be successful because of various reasons: the
destination node cannot be reached; it is not responding or
simply rejects the reservation. An adversary can benefit from
the fact that resources are already consumed along the path
for various processing tasks including path pinning.
Signaling information to a large number of entities along a data path 2. Discovery Phase
requires some sort of discovery. This discovery process is vulnerable Signaling information to a large number of entities along a
to a number of attacks since it is difficult to secure. An adversary data path requires some sort of discovery. This discovery
process is vulnerable to a number of attacks since it is
difficult to secure. An adversary can use the discovery
mechanisms to convince an entity to signal information to
another entity which is not along the data path or to cause
the discovery process to fail. In the first case the signaling
protocol could be correctly continued with the problem that
policy rules are installed at incorrect firewalls or QoS
resource reservations take place at the wrong entities. For an
end host this means that the protocol failed for unknown
reasons.
Tschofenig Informational - Expires April 2003 12 3. Faked Error/Response messages
NSIS Threats October 2002
can use the discovery mechanisms to convince an entity to signal An adversary may be able to use false error/response messages
information to another entity which is not along the data path or to as part of a denial of service attack. This could be either at
cause the discovery process to fail. In the first case the signaling the message signaling protocol level, at the level of each
protocol could be correctly continued with the problem that policy client layer protocol (QoS, Midcom, etc.) or at the transport
rules are installed at incorrect firewalls or QoS resource level protocol. An adversary might cause unexpected protocol
reservations take place at the wrong entities. For an end host this behavior or produce denial of service attacks. Especially the
means that the protocol failed for unknown reasons. discovery protocol shows vulnerabilities with regard to this
threat. In case that no separate discovery protocol is used by
addressing signaling messages to end hosts only (with a Router
Alert Option to intercept message as NSIS aware nodes) then an
error message might be used to indicate a path change. Such a
design is a combination of a discovery protocol together with
a signaling message exchange protocol.
2.13 Disclosing the networking structure 2.10 Disclosing the network topology
In some architectures there is a desire not to reveal the internal In some architectures there is a desire not to reveal the internal
network structure (or other related information) to the outside network structure (or other related information) to the outside world.
world. An adversary might be able to use NSIS messages for network An adversary might be able to use NSIS messages for network mapping
mapping (e.g. discovering which nodes exist, which use NSIS, what (e.g. discovering which nodes exist, which use NSIS, what version, what
version, what resources are allocated, capabilities of nodes along a resources are allocated, capabilities of nodes along a paths etc.).
paths etc.). A requirement of not disclosing a network structure Discovery messages, traceroute, diagnostic messages (see [14] for a
might conflict with another requirement to provide means for description of diagnostic message functionality for RSVP), query
automatically discovering NSIS aware nodes and to provide diagnostic messages in addition to record route and route objects provide the
facilities. potential to assist an adversary. Hence the requirement of not
disclosing a network topology might conflict with another requirement to
provide means for automatically discovering NSIS aware nodes or to
provide diagnostic facilities (used for network monitoring and
administration).
2.14 Modification of Session State Information 2.11 Session/Reservation Ownership
An adversary might be able to modify an existing reservation which Figure 4 shows an NSIS Initiator which established state information at
has already been established within the network as a result of a NSIS nodes along the path as part of the signaling procedure. As a
previous signaling message exchange. result the Access Router1 Router 3 and Router 4 (and other nodes) store
Hence it might be necessary to provide assurance for a secure binding session state information including the Session Identifier SID-x.
between an owner of the established session state and the session
state information distributed at various entities along the data Session ID(SID-x)
path. The state information created at nodes along the path created +--------+
by signaling messages is the uniquely identified Session ID as +-----------------+ Router +------------>
described in [5]. Whenever a signaling message has to refer to Session ID(SID-x)| | 4 |
existing state information (for a refresh, modify or delete +---+----+ +--------+
operation) then the existing session identifier is used. Hence there | Router |
is a requirement that it must not be possible for someone to use an +------+ 3 +*******
existing session identifier to modify state information of someone | +---+----+ *
else. An adversary might have learned a session identifier by | *
eavesdropping the signaling messages. Especially in a roaming | Session ID(SID-x) * Session ID(SID-x)
scenario where a mobile node retransmits signaling messages from a +---+----+ +---+----+
different point of attachment it must be assured that the routers | Access | | Access |
along the path are able to verify whether the entity transmitting the | Router | | Router |
signaling messages is allowed to modify the established state. | 1 | | 2 |
+---+----+ +---+----+
| *
| Session ID(SID-x) * Session ID(SID-x)
+----+------+ +----+------+
| NSIS | | Adversary |
| Initiator | | |
+-----------+ +-----------+
Figure 4: Session/Reservation Ownership
The Session Identifier is included in signaling messages to reference to
the established state.
If an adversary was able to obtain the Session Identifier for example by
eavesdropping signaling messages it is able to add the same Session
Identifier SID-x to a new a signaling message. When the signaling
message hits Router3 (as shown in Figure 3) then existing state
information can be modified. The adversary can then modify or delete the
established reservation causing unexpected behavior for the legitimate
user.
The source of the problem is that Router3 (cross-over router) is unable
to decide whether the new signaling message was initiated from the owner
of the session/reservation.
To make processing even more difficult it must be mentioned that not To make processing even more difficult it must be mentioned that not
only the initial signaling message originator is allowed to signal only the initial signaling message originator is allowed to signal
information during the lifetime of an established session. As part of information during the lifetime of an established session. As part of
the protocol any node along the path (and the path might change over the protocol any NSIS aware node along the path (and the path might
time) could be involved in the signaling message exchange and it change over time) could be involved in the signaling message exchange
might be necessary to provide mobility support or to trigger a local and it might be necessary to provide mobility support or to trigger a
repair procedure. Hence if only the initial signaling message local repair procedure. Hence if only the initial signaling message
originator is allowed to trigger signaling message exchange some originator is allowed to trigger signaling message exchange some
protocol behavior will not be possible. protocol behavior will not be possible.
In case that this threat is not addressed an adversary can launch In case that this threat is not addressed an adversary can launch denial
denial of service, theft of service, and various other attacks. of service, theft of service, and various other attacks.
Tschofenig Informational - Expires April 2003 13 2.12 Security Parameter Exchange/Negotiation
NSIS Threats October 2002
2.15 Faked Error/Response messages Protocols, which should be useful for a variety of scenarios, tend to
have different security requirements. It is often difficult to meet
these (sometimes conflicting requirements) with a single security
mechanism or a fixed security parameter. Hence often a few selected
mechanisms/parameters are supported. Therefore some protocol exchange is
required to agree on some security mechanisms/parameters. This protocol
exchanged can be the misused by an adversary to mount a downgrading
attack by selecting weaker mechanisms than desired. Hence without
protecting the negotiation process the security of an NSIS protocol
might be as secure as the weakest mechanism if no configuration
parameters (for example a security policy disallowing the weakest
mechanism, etc.) are used otherwise.
An adversary may be able to use false error/response messages as part 2.13 Attacks against the signaling message transport mechanism
of a denial of service attack. This could be either at the message
signaling protocol level, at the level of each client layer protocol
(QoS, Midcom, etc.) or at the transport level protocol. An adversary
might cause unexpected protocol behavior or produce denial of service
attacks. Especially the discovery protocol shows vulnerabilities with
regard to this threat. In case that no separate discovery protocol is
used by addressing signaling messages to end hosts only (with a
Router Alert Option to intercept message as NSIS aware nodes) then an
error message might be used to indicate a path change. Such a design
is a combination of a discovery protocol together with a signaling
message exchange protocol.
3 Security Considerations In [15] a two-level architecture is proposed which suggests to split an
NSIS protocol into layers: a signaling message transport specific layer
and an application specific layer. This architectural assumptions is
also considered within the NSIS framework [7]. Most of the threats
described in this document are applicable to the application specific
part for signaling QoS or middlebox specific information. There are,
however, some threats which are applicable to the transport of signaling
messages.
This entire memo discusses security issues in the context of NSIS. Network or transport layer protocols which experience no protected are
Some additional threats are applicable for a framework where an NSIS vulnerable to certain attacks such as header manipulation, DoS, spoofing
protocol is used. Some other relevant threats especially for end of identities, session hijacking, unexpected aborts etc.
hosts to access network communication described in [2].
4 Open Issues In case that an existing protocol is used for exchanging NSIS signaling
messages then threats known from these protocols are relevant.
A future version of this draft will experience a minor restructuring 2.14 Deployment Threats
to add deployment threats, to separation between attacks during
security association setup and attacks which aim to attack the
signaling messages itself, middlebox communication specific threats
and a discussion of threats applicable to the transport level vs. the
application level (according to a 2-level-architecture).
5 References This section addresses problems which could appear during the deployment
of an NSIS protocol in a real-world environment. Although these problems
are theoretically not an obstacle for practical reasons they can
represent threats worth a consideration.
[1] Brunner, M., "Requirements for QoS Signaling Protocols", Missing Authorization:
<draft-ietf-nsis-req-04.txt>, (work in progress), August, 2002.
[2] Kempf, J., Nordmark, E.: ˘Threat Analysis for IPv6 Public Authentication is a very important step for providing the
Multi-Access Links÷, <draft-kempf-ipng-netaccess-threats-02.txt>, foundation of authorization and accounting. Unlike some other
(work in progress), December, 2002. protocols (for example HTTPS) where an authorization
verification step is fairly easy (and efficient) QoS and
middlebox communication requires more care. First, there is
the question what authorization means in the context of NSIS
signaling. For quality of service signaling the possible range
is broad and could range from pure monetary policies to
traditional role-based access control policies. Second, there
is a question where this authorization data can be retrieved.
Especially in a mobile environment this might be more
complicated to securely exchange this information between
different network domains. Finally there is an issue of
authorization representation (i.e. a language describing
authorization policies). If authorization information is
exchanged between a large number of networks then this issue
deserves further consideration.
[3] Hamer, L-N., Gage, B., Broda, M., Kosinski, B., Shieh, H.: In the discovery phase an additional issue of authorization
˘Session Authorization for RSVP÷, <draft-ietf-rap-rsvp-authsession- was raised. Whenever a node wants to discover the next NSIS
04.txt>, (work in progress), October, 2002. aware node then authentication might not be sufficient. In
many cases the IP address or FQDN of a particular router in an
unknown network does not add too much trust. An end host for
example might want some assurance that this node belongs to a
network which has some sort of business relationship which is
known and acceptable (from an accounting, charging, security
and privacy point of view).
[4] Hamer, L-N., Gage, B., Shieh, H.: ˘Framework for session set-up Missing Cost Control:
with media authorization÷, <draft-ietf-rap-session-auth-04.txt>,
(work in progress), June, 2002.
[5] Freytsis, I., Hancock, R., Karagiannis, G., Loughney, J., Van There is a risk that a large number of service providers with
den Bosch, S.: ˘Next Steps in Signaling: A Framework Proposal÷, complex roaming agreements create a non-transparent cost-
<draft-ietf-nsis-fw-00.txt>, (work in progress), October, 2002. structure. In a traditional subscription-based scenario users
are registered with their home networks and use this trust
relationship to dynamically establishment other security
associations. This is the typical AAA deployment scenario. In
these scenarios users do not learn the identity of the access
network as part of a regular authentication and key exchange
protocol message exchange. The identity of the access network
is possibly never revealed (in a secure fashion). The user is
therefore only authenticated to the home network (and
hopefully vice versa). When issuing a QoS reservation request
to the next NSIS peer (for example in the access network) the
end host is typically unaware of the cost of such a
reservation. Due to mobility and route changes along the path
the cost for an end-to-end QoS reservation might not be
transparent for the end host or even become unacceptable.
Tschofenig Informational - Expires April 2003 14 Today there is no standarized protocol available which allows
NSIS Threats October 2002 users to communicate cost limits, to request cost information
for network resources or to learn already accumulated costs
for a particular reservation.
[6] Partridge, C.: "Using the Flow Label Field in IPv6", RFC Especially in mobility environments where an end host is
1809, June, 1995. likely to have access to a large number of networks within a
short time period cost control is even more complicated.
[7] Rajahalme, J., Conta, A., Carpenter, B., Deering, S.: "IPv6 Some mobility/QoS protocol proposals try to merge existing
Flow Label Specification", <draft-ietf-ipv6-flow-label-02.txt>, (work mobility protocols with QoS signaling (i.e. to apply in-band
in progress), September, 2002. signaling). Thereby the access network is queried (towards the
cross-over router or the MAP) for the possibility making a QoS
reservation (without actually making the reservation itself).
Without a query mechanism a user cannot take reservation costs
into account when choosing between different access networks
(or different access routers). Hence the user might not be
unable to refuse a more expensive service provider. To allow a
user to choose between different providers might be required
not only because of the availability of different access
technologies (e.g. IEEE 802.1x, Bluetooth, UTRAN) and the
different service quality offered but also for cost reasons.
[8] Fu, S., Kappler, C., Tschofenig, H.: "Analysis on RSVP Although real-time notifications of quality of service
Regarding Multicast", <draft-fu-rsvp-multicast-analysis-01.txt>, reservation costs (cost control) to the user are outside the
(work in progress), October, 2002. scope of NSIS some interaction might be required.
[9] Tschofenig, H.: "RSVP Security Properties", <draft-tschofenig- 3 Security Considerations
rsvp-sec-properties-01.txt>, (work in progress), October, 2002.
[10] de Meer, H., Feher, G., Blefari-Melazzi, N., Tschofenig, H., This entire memo discusses security issues relevant for NSIS. To counter
Karagiannis, G., Partain, D., Rexhepi, V., Westberg, L.: "Analysis of these threats security requirements have been defined and the framework
Existing QoS Solutions", <draft-demeer-nsis-analysis-03.txt>, (work relevant topics have been described. Some additional threats applicable
in progress), October, 2002. for first peer communication in mobile environments are described in
[16].
[11] Terzis, A., Braden, B., Vincent, S., Zhang, L.: "RSVP 4 Acknowledgements
Diagnostic Messages", RFC 2745, January, 2000.
6 Acknowledgments We would like to thank (in alphabetical order) Marcus Brunner, Jorge
Cuellar, Mehmet Ersue, Xiaoming Fu and Robert Hancock for their comments
I would like to thank (in alphabetical order) Marcus Brunner, Jorge to this draft. Jorge and Robert gave us an extensive list of comments
Cuellar, Mehmet Ersue, Xiaoming Fu and Robert Hancock for their and provided information on additional threats.
comments to this draft. Jorge and Robert gave me an extensive list of
comments and provided information on additional threats.
7 Author's Addresses 5 Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Siemens AG Siemens AG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
81739 Munich 81739 Munich
Germany Germany
Email: Hannes.Tschofenig@siemens.com EMail: Hannes.Tschofenig@siemens.com
Tschofenig Informational - Expires April 2003 15 Dirk Kroeselberg
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
EMail: Dirk.Kroeselberg@siemens.com
6 Bibliography
[1] X. Fu, C. Kappler, and H. Tschofenig, "Analysis on RSVP regarding
multicast," Internet Draft, Internet Engineering Task Force, June 2002.
Work in progress.
[2] H. D. Meer et al. , "Analysis of existing qos solutions," Internet
Draft, Internet Engineering Task Force, July 2002. Work in progress.
[3] H. Tschofenig, "Rsvp security properties," Internet Draft, Internet
Engineering Task Force, 2002. Work in progress.
[4] M. Thomas, "Analysis of mobile ip and rsvp interactions," Internet
Draft, Internet Engineering Task Force, 2002. Work in progress.
[5] J. Manner and X. Fu, "Analysis of existing quality of service
signaling protocols," Internet Draft, Internet Engineering Task Force,
2002. Work in progress.
[6] M. Brunner, "Requirements for QoS signaling protocols," Internet
Draft, Internet Engineering Task Force, July 2002. Work in progress.
[7] R. Hancock, I. Freytsis, G. Karagiannis, J. Loughney, and S. V. den
Bosch, "Next steps in signaling: Framework," Internet Draft, Internet
Engineering Task Force, 2002. Work in progress.
[8] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002.
[9] S. Kent and R. Atkinson, "Security architecture for the internet
protocol," RFC 2401, Internet Engineering Task Force, Nov. 1998.
[10] L. Hamer, B. Gage, M. Broda, B. Kosinski, and H. Shieh, "Session
authorization for RSVP," Internet Draft, Internet Engineering Task
Force, July 2002. Work in progress.
[11] L. Hamer, B. Gage, and H. Shieh, "Framework for session set-up with
media authorization," Internet Draft, Internet Engineering Task Force,
July 2002. Work in progress.
[12] C. Partridge, "Using the flow label field in IPv6," RFC 1809,
Internet Engineering Task Force, June 1995.
[13] J. Rajahalme, A. Conta, B. Carpenter, and S. Deering, "IPv6 flow
label specification," Internet Draft, Internet Engineering Task Force,
June 2002. Work in progress.
[14] A. Terzis, B. Braden, S. Vincent, and L. Zhang, "RSVP diagnostic
messages," RFC 2745, Internet Engineering Task Force, Jan. 2000.
[15] B. Braden and B. Lindell, "A two-level architecture for internet
signaling," Internet Draft, Internet Engineering Task Force, Nov. 2001.
Work in progress.
[16] J. Kempf and E. Nordmark, "Threat analysis for IPv6 public multi-
access links," Internet Draft, Internet Engineering Task Force, June
2002. Work in progress.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . 2
1.1 NSIS Security Process . . . . . . . . . . . . . . . . . . 2
1.2 Relevant communication models . . . . . . . . . . . . . . 4
2 Threat Scenarios . . . . . . . . . . . . . . . . . . . . 9
2.1 MITM Attacks . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Eavesdropping and Traffic Analysis . . . . . . . . . . . 12
2.3 Adversary being able to replay signaling messages . . . . 12
2.4 Missing Protection of Authorization Information . . . . . 13
2.5 Identity Spoofing . . . . . . . . . . . . . . . . . . . . 13
2.6 Adversary being able to inject/modify messages . . . . . 15
2.7 Missing Non-Repudiation . . . . . . . . . . . . . . . . . 15
2.8 Malicious NSIS Entity . . . . . . . . . . . . . . . . . . 16
2.9 Denial of Service Attacks . . . . . . . . . . . . . . . . 17
2.10 Disclosing the network topology . . . . . . . . . . . . . 18
2.11 Session/Reservation Ownership . . . . . . . . . . . . . . 18
2.12 Security Parameter Exchange/Negotiation . . . . . . . . . 20
2.13 Attacks against the signaling message transport
mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.14 Deployment Threats . . . . . . . . . . . . . . . . . . . 21
3 Security Considerations . . . . . . . . . . . . . . . . . 22
4 Acknowledgements . . . . . . . . . . . . . . . . . . . . 22
5 Authors' Addresses . . . . . . . . . . . . . . . . . . . 23
6 Bibliography . . . . . . . . . . . . . . . . . . . . . . 23
 End of changes. 

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