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