man-in-the-middle adversary might redirect to another legitimate NSIS
node. A malicious NSIS node can be detected with the corresponding
security mechanisms, but a legitimate NSIS node that is not the next
NSIS node along the path cannot be detected without 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 on 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. Note that the problem is self-healing since the
discovery process is periodically repeated. 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 Discovery Reply message to force NSIS Node A to establish
a messaging association with another NSIS node that is not along the
path. This can then be exploited by the adversary. The interworking
with NSIS-unaware NATs in particular might cause additional
unexpected problems.
As a variant of this attack, an adversary not able to eavesdrop on
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
This threat scenario covers the case in which an adversary
eavesdrops, collects signaling messages, and replays them at a later
time (or at a different place, or uses parts of them at a different
place or in a different way; e.g., cut-and-paste attacks). Without
proper replay protection, an adversary might mount man-in-the-middle,
denial of service, and theft of service attacks.
A more difficult attack (that may cause problems even if there is
replay protection) requires that the adversary crash an NSIS-aware
node, causing it to lose state information (sequence numbers,
security associations, etc.), and then replay old signaling messages.
This attack takes advantage of re-synchronization deficiencies.
3.3. Injecting or Modifying Messages
This type of threat involves integrity violations, whereby an
adversary modifies signaling messages (e.g., by acting as a
man-in-the-middle) in order to cause unexpected network behavior.
Possible actions an adversary might consider for its attack are
reordering, delaying, dropping, injecting, truncating, and otherwise
modifying messages.
An adversary may inject a signaling message requesting a large amount
of resources (possibly using a different user’s identity). Other
resource requests may then be rejected. In combination with identity
spoofing, it is possible to carry out fraud. This attack is only
feasible in the absence of authentication and signaling message
protection.
Some threats directly related to these are described in Sections 4.4,
4.7, and 4.8.
3.4. Insecure Parameter Exchange and Negotiation
First, protocols may be useful in a variety of scenarios with
different security requirements. Second, different users (e.g., a
university, a hospital, a commercial enterprise, or a government
ministry) have inherently different security requirements. Third,
different parts of a network (e.g., within a building, across a
public carrier’s network, or over a private microwave link) may need
different levels of protection. It is often difficult to meet these
(sometimes conflicting) requirements with a single security mechanism
or fixed set of security parameters, so often a selection of
mechanisms and parameters is offered. Therefore, a protocol is
required to agree on certain security mechanisms and parameters. An
insecure parameter exchange or security negotiation protocol can help
an adversary to mount a downgrading attack to force selection of
mechanisms weaker than those mutually desired. Thus, without binding
the negotiation process to the legitimate parties and protecting it,
an NSIS protocol suite might only be as secure as the weakest
mechanism provided (e.g., weak authentication), and the benefits of
defining configuration parameters and a negotiation protocol are
lost.
4. NSIS-Specific Threat Scenarios
This section describes eleven threat scenarios in terms of attacks on
and security deficiencies in the NSIS signaling protocol. A number
of security deficiencies might enable an attack. Fraud is an example
of an attack that might be enabled by missing replay protection,
missing protection of authorization tokens, identity spoofing,
missing authentication, and other deficiencies that help an adversary
steal resources. Different threat scenarios based on deficiencies
that could enable an attack are addressed in this section.
The threat scenarios are not independent. Some of them (e.g., denial
of service) are well-established security terms and, as such, need to
be addressed, but they are often enabled by one or more deficiencies
described under other scenarios.
4.1. Threats during NSIS SA Usage
Once a security association is established (and used) to protect
signaling messages, many basic attacks are prevented. However, a
malicious NSIS node is still able to perform various attacks as
described in Section 4.7. Replay attacks may be possible when an
NSIS node crashes, restarts, and performs state re-establishment.
Proper re-synchronization of the security mechanism must therefore be
provided to address this problem.
4.2. Flooding
This section describes attacks that allow an adversary to flood an
NSIS node with bogus signaling messages to cause a denial of service
attack.
We will discuss this threat at different layers in the NSIS protocol
suite:
Processing of Router Alert Options:
The processing of Router Alert Option (RAO) requires that a router
do some additional processing by intercepting packets with IP
options, which might lead to additional delay for legitimate
requests, or even rejection of 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 that 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 harm 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. The term "idempotent" refers to messages that
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
This section covers threats whereby an adversary is able to eavesdrop
on signaling messages. The signaling packets collected may allow
traffic analysis or be used later to mount replay attacks, as
described in Section 3.2. The eavesdropper might learn QoS
parameters, communication patterns, policy rules for firewall
traversal, policy information, application identifiers, user
identities, NAT bindings, authorization objects, network
configuration and performance information, and more.
An adversary’s capability to eavesdrop on signaling messages might
violate a user’s preference for privacy, particularly if unprotected
authentication or authorization information (including policies and
profile information) is exchanged.
Because the NSIS protocol signals messages through a number of nodes,
it is possible to differentiate between nodes actively participating
in the NSIS protocol and those that do not. For certain objects or
messages, it 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) be able to read certain other objects.
4.4. Identity Spoofing
Identity spoofing relevant for NSIS occurs in three forms: First,
identity spoofing can happen during the establishment of a security
association based on a weak authentication mechanism. Second, an
adversary can modify the flow identifier carried within a signaling
message. Third, it can spoof data traffic.
In the first case, Eve, acting as an adversary, may claim to be the
registered user Alice by spoofing Alice’s identity. Eve thereby
causes the network to charge Alice for the network resources
consumed. This type of attack is possible if authentication is based
on a simple username identifier (i.e., in absence of cryptographic
authentication), or if authentication is provided for hosts, and
multiple users have access to a single host. This attack could also
be classified as theft of service.
In the second case, an adversary may be able to exploit the
established flow identifiers (required for QoS and NAT/FW NSLP).
These identifiers are, among others, IP addresses, transport protocol
type (UDP, TCP), port numbers, and flow labels (see [RFC1809] and
[RFC3697]). Modification of these flow identifiers allows
adversaries to exploit or to render ineffective quality of service
reservations or policy rules at middleboxes. An adversary could
mount an attack by modifying the flow identifier of a signaling
message.
In the third case, an adversary may spoof data traffic. NSIS
signaling messages contain some sort of flow identifier that is
associated with a specified behavior (e.g., a particular flow
experiences QoS treatment or allows packets to traverse a firewall).
An adversary might, therefore, use IP spoofing and inject data
packets to benefit from previously installed flow identifiers.
We will provide an example of the latter threat. After NSIS nodes
along the path between the NSIS initiator and the NSIS receiver
processes a properly protected reservation request, transmitted by
the legitimate user Alice, a QoS reservation is installed at the
corresponding NSIS nodes (for example, the edge router). The flow
identifier is used for flow identification and allows data traffic
originated from a given source to be assigned to this QoS
reservation. The adversary Eve now spoofs Alice’s IP address. In
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). If Eve is able to perform address spoofing, then she is
able to receive and transmit data (for example, RTP data traffic)
that receives preferential QoS treatment based on the previous
reservation. Depending on the installed flow identifier granularity,
Eve might have more possibilities to exploit the QoS reservation or a
pin-holed firewall. Assuming the soft state paradigm, whereby
periodic refresh messages are required, Alice’s absence will not be
detected until a refresh message is required, forcing Eve to respond
with a protected signaling message. Again, this attack is applicable
not only to QoS traffic, but also to a Firewall control protocol,
with a different consequence.
The ability for an adversary to inject data traffic that matches a
certain flow identifier established by a legitimate user and to get
some benefit from injecting that traffic often also requires the
ability to receive the data traffic or to have one’s correspondent
receive it. For example, an adversary in an unmanaged network
observes a NAT/Firewall signaling message towards a corporate
network. After the signaling message exchange was successful, the
user Alice is allowed to traverse the company firewall based on the
establish packet filter in order to contact her internal mail server.
Now, the adversary Eve, who was monitoring the signaling exchange, is
able to build a data packet towards this mail server that 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.
We could imagine using attributes of a flow identifier that is not
related to source and destination addresses. For example, we could
think of a flow identifier for which 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 (in the above example, they would have to hit the same
firewall).
Data traffic marking based on DiffServ is such an example. Whenever
an ingress router uses only marked incoming data traffic for
admission control procedures, various attacks are possible. These
problems have been known in the DiffServ community for a long time
and have been documented in various DiffServ-related documents. The
IPsec protection of DiffServ Code Points is described in Section 6.2
of [RFC2745]. Related security issues (for example denial of service
attacks) are described in Section 6.1 of the same document.
4.5. Unprotected Authorization Information
Authorization is an important criterion for providing resources such
as QoS reservations, NAT bindings, and pinholes through firewalls.
Authorization information might be delivered to the NSIS-
participating entities in a number of ways.
Typically, the authenticated identity is used to assist during the
authorization procedure (as described in [RFC3182], for example).
Depending on the chosen authentication protocol, certain threats may
exist. Section 3 discusses a number of issues related to this
approach when the authentication and key exchange protocol is used to
establish session keys for signaling message protection.
Another approach is to use some sort of authorization token. The
functionality and structure of such an authorization token for RSVP
is described in [RFC3520] and [RFC3521].
Achieving secure interaction between different protocols based on
authorization tokens, however, requires some care. By using such an
authorization token, it is possible to link state information between
different protocols. Returning an unprotected authorization token to
the end host might allow an adversary (for example, an eavesdropper)
to steal resources. An adversary might also use the token to monitor
communication patterns. Finally, an untrustworthy end host might
also modify the token content.
The Session/Reservation Ownership problem can also be regarded as an
authorization problem. Details are described in Section 4.10. In
enterprise networks, authorization is often coupled with membership
in a particular class of users or groups. This type of information
either can be delivered as part of the authentication and key
agreement procedure or has to be retrieved via separate protocols
from other entities. If an adversary manages to modify information
relevant to determining authorization or the outcome of the
authorization process itself, then theft of service might be
possible.
4.6. Missing Non-Repudiation
Signaling for QoS often involves three parties: the user, a network
that offers QoS reservations (referred to as "service provider") and
a third party that guarantees that the party making the reservation
actually receives a financial compensation (referred to as "trusted
third party").
In this context,"repudiation" refers to a problem where either the
user or the service provider later deny the existence or some
parameters (e.g., volume or price) of a QoS reservation towards the
trusted third party. Problems stemming from a lack of non-
repudiation appear in two forms:
Service provider’s point-of-view:
A user may deny having issued a reservation request for which it
was charged. The service provider may then want to be able to
prove that a particular user issued the reservation request in
question.
User’s point-of-view:
A service provider may claim to have received a number of
reservation requests from a particular user. The user in question
may want to show that such reservation requests have never been
issued and may want to see correct service usage records for a
given set of QoS parameters.
In today’s networks, non-repudiation is not provided. Therefore, it
might be difficult to introduce with NSIS signaling. The user has to
trust the network operator to meter the traffic correctly, to collect
and merge accounting data, and to ensure that no unforeseen problems
occur. If a signaling protocol with the non-repudiation property is
desired for establishing QoS reservations, then it certainly impacts
the protocol design.
Non-repudiation functionality places additional requirements on the
security mechanisms. Thus, a solution would normally increase the
overhead of a security solution. Threats related to missing non-
repudiation are only considered relevant in certain specific
scenarios and for specific NSLPs.
4.7. Malicious NSIS Entity
Network elements within a domain (intra-domain) experience a
different trust relationship with regard to the security protection
of signaling messages from that of edge NSIS entities. It is assumed
that edge NSIS entities are responsible for performing cryptographic
processing (authentication, integrity and replay protection,
authorization, and accounting) for signaling messages arriving from
the outside. This prevents unprotected signaling messages from
appearing within the internal network. If, however, an adversary
manages to take over an edge router, then the security of the entire
network is compromised. An adversary is then able to launch a number
of attacks, including denial of service; integrity violations; replay
and reordering of objects and messages; bundling of messages;
deletion of data packets; and various others. A rogue firewall can
harm other firewalls by modifying policy rules. The chain-of-trust
principle applied in peer-to-peer security protection cannot protect
against a malicious NSIS node. An adversary with access to an NSIS
router is also able to get access to security associations and to
transmit secured signaling messages. Note that even non-peer-to-peer
security protection might not be able to prevent this problem fully.
Because an NSIS node might issue signaling 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
strong security protection. A strong security policy applied at the
edge does not imply that other routers within an intra-domain network
do not need to verify signaling messages cryptographically. If the
chain-of-trust principle is deployed, then the security protection of
the entire path (in this case, within the network of a single
administrative domain) is only as strong as the weakest link. In the
case under consideration, the edge router is the most critical
component of this network, and it may also act as a security gateway
or firewall for incoming and outgoing traffic. For outgoing traffic,
this device has to implement the security policy of the local domain
and to apply the appropriate security protection.
For an adversary to mount this attack, either an existing NSIS-aware
node along the path has to be attacked successfully, or an adversary
must succeed in convincing another NSIS node to make it the next NSIS
peer (man-in-the-middle attack).
4.8. Denial of Service Attacks
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-