This also impacts the user’s privacy policy.
In general, the user may not want to distribute much of this
policy information. Furthermore, the lack of a standardized
authorization data format may create interoperability problems
when exchanging policy information. Hence, we can assume that
the policy decision point may use information from an initial
authentication and key agreement protocol (which may have already
required cross-realm communication with the user’s home domain,
if only to show that the home domain knows the user and that the
user is entitled to roam), to forward accounting messages to this
domain. This represents the traditional subscriber-based
accounting scenario. Non-traditional or alternative means of
access might be deployed in the near future that do not require
any type of inter-domain communication.
Additional discussions are required to determine the expected
authorization procedures. [34] and [35] discuss authorization
issues for QoS signaling protocols. Furthermore, a number of
mobility implications for policy handling in RSVP are described
in [36].
(6) Performance
If Kerberos is used for user authentication, then a Kerberos
ticket must be included in the CREDENTIAL Section of the
AUTH_DATA element. The Kerberos ticket has a size larger than
500 bytes, but it only needs to be sent once because a
performance optimization allows the session key to be cached as
noted in Section 7.1 of [1]. It is assumed that subsequent RSVP
messages only include the POLICY_DATA INTEGRITY object with a
keyed message digest that uses the Kerberos session key.
However, this assumes that the security association required for
the POLICY_DATA INTEGRITY object is created (or modified) to
allow the selection of the correct key. Otherwise, it difficult
to say which identifier is used to index the security
association.
If Kerberos is used as an authentication system then, from a
performance perspective, the message exchange to obtain the
session key needs to be considered, although the exchange only
needs to be done once in the lifetime of the session ticket.
This is particularly true in a mobile environment with a fast
roaming user’s host.
Public-key-based authentication usually provides the best
scalability characteristics for key distribution, but the
protocols are performance demanding. A major disadvantage of the
public-key-based user authentication in RSVP is the lack of a
method to derive a session key. Hence, every RSVP PATH or RESV
message includes the certificate and a digital signature, which
is a huge performance and bandwidth penalty. For a mobile
environment with low power devices, high latency, channel noise,
and low-bandwidth links, this seems to be less encouraging. Note
that a public key infrastructure is required to allow the PDP (or
the first-hop router) to verify the digital signature and the
certificate. To check for revoked certificates, certificate
revocation lists or protocols like the Online Certificate Status
Protocol [27] and the Simple Certificate Validation Protocol [28]
are needed. Then the integrity of the AUTH_DATA object can be
verified via the digital signature.
4.4. Communication between RSVP-Aware Routers
(1) Authentication
RSVP signaling messages have data origin authentication and are
protected against modification and replay with the RSVP INTEGRITY
object. The RSVP message flow between routers is protected based
on the chain of trust, and hence each router needs only a
security association with its neighboring routers. This
assumption was made because of performance advantages and because
of special security characteristics of the core network to which
no user hosts are directly attached. In the core network the
network structure does not change frequently and the manual
distribution of shared secrets for the RSVP INTEGRITY object may
be acceptable. The shared secrets may be either manually
configured or distributed by using appropriately secured network
management protocols like SNMPv3.
Independent of the key distribution mechanism, host
authentication with built-in RSVP mechanisms is accomplished
using the keyed message digest in the RSVP INTEGRITY object,
computed using the previously exchanged symmetric key.
(2) Integrity Protection
Integrity protection is accomplished with the RSVP INTEGRITY
object with the variable length Keyed Message Digest field.
(3) Replay Protection
Replay protection with the RSVP INTEGRITY object is extensively
described in previous sections. To enable crashed hosts to learn
the latest sequence number used, the Integrity Handshake
mechanism is provided in RSVP.
(4) Confidentiality
Confidentiality is not provided by RSVP.
(5) Authorization
Depending on the RSVP network, QoS resource authorization at
different routers may need to contact the PDP again. Because the
PDP is allowed to modify the policy element, a token may be added
to the policy element to increase the efficiency of the re-
authorization procedure. This token is used to refer to an
already computed policy decision. The communications interface
from the PEP to the PDP must be properly secured.
(6) Performance
The performance characteristics for the protection of the RSVP
signaling messages is largely determined by the key exchange
protocol, because the RSVP INTEGRITY object is only used to
compute a keyed message digest of the transmitted signaling
messages.
The security associations within the core network, that is,
between individual routers (in comparison with the security
association between the user’s host and the first-hop router or
with the attached network in general), can be established more
easily because of the normally strong trust assumptions.
Furthermore, it is possible to use security associations with an
increased lifetime to avoid frequent rekeying. Hence, there is
less impact on the performance compared with the user-to-network
interface. The security association storage requirements are
also less problematic.
5. Miscellaneous Issues
This section describes a number of issues that illustrate some of the
shortcomings of RSVP with respect to security.
5.1. First-Hop Issue
In case of end-to-end signaling, an end host starts signaling to its
attached network. The first-hop communication is often more
difficult to secure because of the different requirements and a
missing trust relationship. An end host must therefore obtain some
information to start RSVP signaling:
o Does this network support RSVP signaling?
o Which node supports RSVP signaling?
o To which node is authentication required?
o Which security mechanisms are used for authentication?
o Which algorithms are required?
o Where should the keys and security associations come from?
o Should a security association be established?
RSVP, as specified today, is used as a building block. Hence, these
questions have to be answered as part of overall architectural
considerations. Without answers to these questions, ad hoc RSVP
communication by an end host roaming to an unknown network is not
possible. A negotiation of security mechanisms and algorithms is not
supported for RSVP.
5.2. Next-Hop Problem
Throughout the document it was assumed that the next RSVP node along
the path is always known. Knowing the next hop is important to be
able to select the correct key for the RSVP Integrity object and to
apply the proper protection. In the case in which an RSVP node
assumes it knows which node is the next hop, the following protocol
exchange can occur:
Integrity
(A<->C) +------+
(3) | RSVP |
+------------->+ Node |
| | B |
Integrity | +--+---+
(A<->C) | |
+------+ (2) +--+----+ |
(1) | RSVP +----------->+Router | | Error
----->| Node | | or +<-----------+ (I am B)
| A +<-----------+Network| (4)
+------+ (5) +--+----+
Error .
(I am B) . +------+
. | RSVP |
...............+ Node |
| C |
+------+
Figure 6: Next-Hop Issue.
When RSVP node A in Figure 6 receives an incoming RSVP Path message,
standard RSVP message processing takes place. Node A then has to
decide which key to select to protect the signaling message. We
assume that some unspecified mechanism is used to make this decision.
In this example, node A assumes that the message will travel to RSVP
node C. However, for some reasons (e.g., a route change, inability
to learn the next RSVP hop along the path, etc.) the message travels
to node B via a non-RSVP supporting router that cannot verify the
integrity of the message (or cannot decrypt the Kerberos service
ticket). The processing failure causes a PathErr message to be
returned to the originating sender of the Path message. This error
message also contains information about the node that recognized the
error. In many cases, a security association might not be available.
Node A receiving the PathErr message might use the information
returned with the PathErr message to select a different security
association (or to establish one).
Figure 6 describes a behavior that might help node A learn that an
error occurred. However, the description in Section 4.2 of [1]
states in step (5) that a signaling message is silently discarded if
the receiving host cannot properly verify the message: "If the
calculated digest does not match the received digest, the message is
discarded without further processing." For RSVP Path and similar
messages, this functionality is not really helpful.
The RSVP Path message therefore provides a number of functions: path
discovery, detecting route changes, discovery of QoS capabilities
along the path using the Adspec object (with some interpretation),
next-hop discovery, and possibly security association establishment
(for example, in the case of Kerberos).
From a security point of view, there are conflicts between:
o Idempotent message delivery and efficiency
The RSVP Path message especially performs a number of functions.
Supporting idempotent message delivery somehow contradicts with
security association establishment, efficient message delivery,
and message size. For example, a "real" idempotent signaling
message would contain enough information to perform security
processing without depending on a previously executed message
exchange. Adding a Kerberos ticket with every signaling message
is, however, inefficient. Using public-key-based mechanisms is
even more inefficient when included in every signaling message.
With public-key-based protection for idempotent messages, there is
the additional risk of introducing denial-of-service attacks.
o RSVP Path message functionality and next-hop discovery
To protect an RSVP signaling message (and an RSVP Path message in
particular) it is necessary to know the identity of the next
RSVP-aware node (and some other parameters). Without a mechanism
for next-hop discovery, an RSVP Path message is also responsible
for this task. Without knowing the identity of the next hop, the
Kerberos principal name is also unknown. The so-called Kerberos
user-to-user authentication mechanism, which would allow the
receiver to trigger the process of establishing Kerberos
authentication, is not supported. This issue will again be
discussed in relationship with the last-hop problem.
It is fair to assume that an RSVP-supporting node might not have
security associations with all immediately neighboring RSVP nodes.
Especially for inter-domain signaling, IntServ over DiffServ, or
some new applications such as firewall signaling, the next RSVP-
aware node might not be known in advance. The number of next RSVP
nodes might be considerably large if they are separated by a large
number of non-RSVP aware nodes. Hence, a node transmitting an
RSVP Path message might experience difficulties in properly
protecting the message if it serves as a mechanism to detect both
the next RSVP node (i.e., Router Alert Option added to the
signaling message and addressed to the destination address) and to
detect route changes. It is fair to note that, in the intra-
domain case with a dense distribution of RSVP nodes, protection
might be possible with manual configuration.
Nothing prevents an adversary from continuously flooding an RSVP
node with bogus PathErr messages, although it might be possible to
protect the PathErr message with an existing, available security
association. A legitimate RSVP node would believe that a change
in the path took place. Hence, this node might try to select a
different security association or try to create one with the
indicated node. If an adversary is located somewhere along the
path, and either authentication or authorization is not performed
with the necessary strength and accuracy, then it might also be
possible to act as a man-in-the-middle. One method of reducing
susceptibility to this attack is as follows: when a PathErr
message is received from a node with which no security association
exists, attempt to establish a security association and then
repeat the action that led to the PathErr message.
5.3. Last-Hop Issue
This section tries to address practical difficulties when
authentication and key establishment are accomplished with a two-
party protocol that shows some asymmetry in message processing.
Kerberos is such a protocol and also the only supported protocol that
provides dynamic session key establishment for RSVP. For first-hop
communication, authentication is typically done between a user and
some router (for example the access router). Especially in a mobile
environment, it is not feasible to authenticate end hosts based on
their IP or MAC address. To illustrate this problem, the typical
processing steps for Kerberos are shown for first-hop communication:
(1) The end host A learns the identity (i.e., Kerberos principal
name) of some entity B. This entity B is either the next RSVP
node, a PDP, or the next policy-aware RSVP node.
(2) Entity A then requests a ticket granting ticket for the network
domain. This assumes that the identity of the network domain is
known.
(3) Entity A then requests a service ticket for entity B, whose name
was learned in step (1).
(4) Entity A includes the service ticket with the RSVP signaling
message (inside the policy object). The Kerberos session key is
used to protect the integrity of the entire RSVP signaling
message.
For last-hop communication, this processing theoretically has to be
reversed: entity A is then a node in the network (for example, the
access router) and entity B is the other end host (under the
assumption that RSVP signaling is accomplished between two end hosts
and not between an end host and an application server). However, the
access router in step (1) might not be able to learn the user’s
principal name because this information might not be available.
Entity A could reverse the process by triggering an IAKERB exchange.
This would cause entity B to request a service ticket for A as
described above. However, IAKERB is not supported in RSVP.
5.4. RSVP- and IPsec-Protected Data Traffic
QoS signaling requires flow information to be established at routers
along a path. This flow identifier installed at each device tells
the router which data packets should receive QoS treatment. RSVP
typically establishes a flow identifier based on the 5-tuple (source
IP address, destination IP address, transport protocol type, source
port, and destination port). If this 5-tuple information is not
available, then other identifiers have to be used. ESP-encrypted
data traffic is such an example where the transport protocol and the
port numbers are not accessible. Hence, the IPsec SPI is used as a
substitute for them. [12] considers these IPsec implications for RSVP
and is based on three assumptions:
(1) An end host that initiates the RSVP signaling message exchange
has to be able to retrieve the SPI for a given flow. This
requires some interaction with the IPsec security association
database (SAD) and security policy database (SPD) [3]. An
application usually does not know the SPI of the protected flow
and cannot provide the desired values. It can provide the
signaling protocol daemon with flow identifiers. The signaling
daemon would then need to query the SAD by providing the flow
identifiers as input parameters and receiving the SPI as an
output parameter.
(2) [12] assumes end-to-end IPsec protection of the data traffic. If
IPsec is applied in a nested fashion, then parts of the path do
not experience QoS treatment. This can be treated as a problem
of tunneling that is initiated by the end host. The following
figure better illustrates the problem in the case of enforcing
secure network access:
+------+ +---------------+ +--------+ +-----+
| Host | | Security | | Router | | Host|
| A | | Gateway (SGW) | | Rx | | B |
+--+---+ +-------+-------+ +----+---+ +--+--+
| | | |
|IPsec-Data( | | |
| OuterSrc=A, | | |
| OuterDst=SGW, | | |
| SPI=SPI1, | | |
| InnerSrc=A, | | |
| InnerDst=B, | | |
| Protocol=X, |IPsec-Data( | |
| SrcPort=Y, | SrcIP=A, | |
| DstPort=Z) | DstIP=B, | |
|=====================>| Protocol=X, |IPsec-Data( |
| | SrcPort=Y, | SrcIP=A, |
| --IPsec protected-> | DstPort=Z) | DstIP=B, |
| data traffic |------------------>| Protocol=X, |
| | | SrcPort=Y, |
| | | DstPort=Z) |
| | |---------------->|
| | | |
| | --Unprotected data traffic---> |
| | | |
Figure 7: RSVP and IPsec protected data traffic.
Host A, transmitting data traffic, would either indicate a 3-
tuple <A, SGW, SPI1> or a 5-tuple <A, B, X, Y, Z>. In any case,
it is not possible to make a QoS reservation for the entire path.
Two similar examples are remote access using a VPN and protection
of data traffic between a home agent (or a security gateway in
the home network) and a mobile node. The same problem occurs
with a nested application of IPsec (for example, IPsec between A