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

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