Internet Engineering Task Force NSIS
Internet Draft H. Tschofenig,M. Buechli
S. Van den Bosch, H. Schulzrinne
Siemens/Alcatel/Alcatel/Columbia
draft-tschofenig-nsis-aaa-issues-00.txt
5 February 2003
Expires: August 2003
NSIS Authentication, Authorization and Accounting Issues
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This document describes the implications of authentication,
authorization and accounting for an NSIS QoS signaling protocol. We try
to show that authorization and charging are very important for the
internal machinery of a signaling protocol and for the security and
trust model behind it. This document only addresses charging aspects for
unicast data traffic.
1 Introduction
When RSVP [1] was designed a few assumptions had to be made. These
assumptions are, however, not described in too much detail. Especially
with regard to accounting and charging a number of white spots have been
left open which make it difficult for providers to create a solution
without considerable effort. This document tries to highlight some of
H. Tschofenig et. al. [Page 1]
Internet Draft 5 February 2003
these issues and explain why NSIS should consider them during the design
phase. This document does not try to introduce a new charging or
accounting infrastructure and does not aim to provide a literature
review of pricing mechanisms or mathematic models. Instead an abstract
view on authentication, authorization and charging is provided as far as
relevant for NSIS and to QoS signaling in particular.
2 Terminology
Accounting terminology used in this document tries to be consistent with
[2]. NSIS terminology is taken from [3]. The term Policy Decision Point
(PDP) refers to the logical entity defined in [4].
Reverse charging denotes charging for the receiver of the data traffic
in contrast to charging for the data traffic transmitter (i.e. sender).
3 The Relationship between Authorization and Accounting
RSVP is currently only deployed in fairly closed environment such as
enterprise networks. In such an environment authorization usually means
role based access control based on some group membership or special
rights to use a service. Users are typically not charged directly for
their generated QoS traffic nor for QoS reservations. If the signaling
messages (and thereby the QoS reservation) travel beyond the
administrative domain then the enterprise network is charged and not the
individual end user directly.
With mobility and telecommunication networks today authorization can (or
should) be seen in an abstract form as "Is one of the signaling
participants able to pay for the reservation?". This abstraction is
supported by the fact that reservations require some form of penalty in
order not reserve too many resources.
It might therefore be correct to say that authorization is strongly
interrelated to the availability of funds/credits and therefore with
charging. Some service provider might use some additionally information
based on the subscriber profile/information stored data to assist in the
authorization process.
4 The two Accounting/Trust Models
4.1 New Jersey Turnpike Model
On the New Jersey Turnpike, motorists pick up a ticket at the toll booth
when entering the highway. At the highway exit the ticket is presented
and payment is made at the toll booth for the distance driven. An
abstract form of this model is given in Figure 1 where security is
provided in a peer-to-peer or network-to-network fashion since the
H. Tschofenig et. al. [Page 2]
Internet Draft 5 February 2003
accounting and charging model is also accomplished in the same fashion.
+--------------------+ +--------------------+ +--------------------+
| Network | | Network | | Network |
| X | | Y | | Z |
| | | | | |
| -----------> -----------> |
| | | | | |
| | | | | |
+--------^-----------+ +--------------------+ +---------+----------+
| .
| .
| v
+--+---+ Data Data +--+---+
| Node | ====================================> | Node |
| A | Sender Receiver | B |
+------+ +------+
Legend:
----> Peering relationship which allows neighboring networks/entities
to charge each other for the QoS reservation and data traffic
====> Data flow
..... Communication to the end host
Figure 1: New Jersey Turnpike Model
The model shown in Figure 1 uses peer-to-peer relationships between
different administrative domains as a basis for accounting and charging.
Based on the peering relationship a chain-of-trust is established. There
are several issues which come in mind when considering this type of
model:
· Since accounting and charging requires some protocol interaction
with the end host it is reasonable to assume that a QoS signaling
protocol is not the first protocol executed between an end host
and the attached network. Typically some network access protocols
are executed which establish a relationship between the user and
his home network (subscription-based scenario). A more detailed
description of this environment is given in Section 6. Using this
H. Tschofenig et. al. [Page 3]
Internet Draft 5 February 2003
assumption a relationship between the visited/access network (the
network where the end host is currently attached) and the user's
home network for the purpose of charging is already established.
Hence generating additional accounting records for QoS
reservations and QoS data traffic does not require a major
change.
· The price for a QoS reservation needs to be determined somehow
and communicated to the charged entity and to the network where
the charged entity is attached. The description of this model
assumes that the data sender is charged. Section 6 addresses the
issue of charging for either one of the two end points.
Section A describes two mechanisms for price distribution: in-
band (or probing) and out-off band price distribution protocols
· This architecture seems to be simple enough to allow a scalable
solution (ignoring reverse charging, multicast issues and the
problem of determining the cost for a reservation along the
entire path).
· Depending on the signaling protocol and the price distribution
protocol (especially in case of an in-band protocol) it might be
possible that a malicious node is able to cause harm by modifying
signaling messages in such a way that the end point is charged
more than intended. (TBD: This issue needs to be elaborated in
more details.)
Charging for the data sender applied to this model simplifies security
handling by demanding only peer-to-peer security protection. Node A
would perform authentication and key establishment. The established
security association (together with the session key) would allow the
user to protect QoS signaling messages. The identity used during the
authentication and key establishment phase would be used by Network X
(see Figure 1) to perform the so-called policy-based admission control
procedure. In our context this user identifier would be used to
establish the necessary infrastructure to provide authorization and
charging. Signaling messages later exchanged between the different
networks are then also subject to authentication and authorization. The
authenticated entity thereby is, however, the neighboring network and
not the end host.
The New Jersey Turnpike model is attracting because of its simplicity.
In [5] S. Schenker et. al. discussed various accounting implications and
introduced the edge pricing model. The edge pricing model is very
similar to this model with the exception that mobility and the security
implications itself are not addressed.
H. Tschofenig et. al. [Page 4]
Internet Draft 5 February 2003
4.2 New Jersey Parkway Model
On the New Jersey Parkway highway, drivers have to deposit 20 or 25
cents every few miles, with toll booths in the middle of the road in
addition to entrance or exit ramps. (With electronic toll tags, each
such toll is deducted individually.)
+--------------------+ +--------------------+ +--------------------+
| Network | | Network | | Network |
| X | | Y | | Z |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
+-------^ -----------+ +----------^---------+ +-----^---+----------+
| | | .
|+-------------------------+ | .
||+-------------------------------------------+ .
||| .
+-+++--+ Data Data +--+---+
| Node | ====================================> | Node |
| A | Sender Receiver | B |
+------+ +------+
Legend:
----> Direct authorization and charging relationship
====> Data flow
..... Communication to the end host
Figure 2: New Jersey Parkway Model
In this model one of the NSIS end points (initiator or responder) is
charged directly by the traversed domains along the path. In other
words, each network charges the end point only for the incurred costs in
its own network. Each network maintains only local pricing information.
Figure 2 shows this model in case that the data sender is charged.
The following list gives some issues caused by the selection of this
model:
H. Tschofenig et. al. [Page 5]
Internet Draft 5 February 2003
· Since the end point probably does not have agreements with all
traversed networks there is a need for a trusted third party for
authentication, authorization and financial settlement. Such a
trusted third party might be a clearing house.
· Authentication and authorization of reservation requests needs to
be done on a per-reservation request basis. As a possible
solution, the signaling messages might carry authorization tokens
from the charged entity which can be verified at the intermediate
domains. Each network might have to contact the clearing house. A
route change might therefore require a new authentication and
authorization of the end point for the purpose of charging.
· There are, however, some concerns related to scalability and
deployment. If the NSIS initiator is located in the end host (and
the NSIS initiator is charged) then the number of end points may
be too large to handle by a clearing house. Therefore, some kind
of proxy in the access network which interacts with the clearing
house on behalf of several end points may be required. Another
approach is to use a distributed clearing house. If this model is
deployed on an Internet-wide scale then there is a need for
multiple clearinghouses that need to communicate with each other.
This introduces additional complexity.
· A route change might require a new end-to-middle
authentication/authorization for the purpose of charging. Hence a
route change might not be handled locally anymore. This has an
impact on the local repair mechanism. In the New Jersey Turnpike
model a route change in the middle of the network does not
require any interaction with nodes other than the involved ones.
The New Jersey Parkway model is different since it might require
an interaction with the end points and thereby destroying the
local repair mechanism.
· To reduce state maintenance, processing and signaling message
exchanges in the core network some sort of aggregation (see [6],
[7], [8] ) is used. Aggregation thereby causes per-flow end-to-
end signaling messages to be hidden in the core network and a
separate signaling message exchange to be used. Because the New
Jersey Parkway model might require some interaction with an
individual end host aggregation in the traditional sense might be
much more difficult to deploy.
5 What should be charged?
In the above-description we assumed that data sender is simply charged
for something. There are, however, some more fine-grained charging
considerations which might affect the complexity of the interaction. In
H. Tschofenig et. al. [Page 6]
Internet Draft 5 February 2003
Section 6 the question is consider which entity to charge. Closely
related is therefore what a user can be charged for:
Signaling messages: Although it is possible to charge signaling
message originators for generated messages it is currently
rarely used. In some cases such a behavior denial of service
attacks could be prevented or the misuse of end-to-end
signaling messages as a subliminal channel.
QoS reservations: Charging on the reservations implies charging on
reserved resources regardless whether they are used or not.
Transmitted data traffic: Charging based on transmitted data
traffic is based on the amount of bytes/packets that have been
send by the data source. This type of charging will constrain
the traffic volume of the data source but not the duration or
amount of the reservation. Therefore, this type of charing can
only be applied for QoS classes that allow for overbooking of
resources (i.e. resources are not provisioned with regard to
their specified peak rate).
Application cost: Finally there are costs associated to the usage
of a particular service such as a video service. This cost
might already include the cost of the above-mentioned costs
for more end user transparency. Costs for applications are
outside the scope of NSIS.
6 Who should be charged?
Which entity is charged is one of the most important set of components
for a AAA framework. To provide the required functionality the following
issues need to be addressed:
· Negotiation which entity is charged for which part of the costs
· Price Distribution
· Authorization of a reservation
· QoS Signaling
These individual steps might be combined and merged with the QoS
signaling messages. As an example, in RSVP the signaling messages PATH
or RESV might be used to piggyback information related to price
distribution and charging. Whether this is possible depends on the
flexibility of the signaling protocol, the number of round-trips
executed by the signaling protocol and the semantic of the messages.
H. Tschofenig et. al. [Page 7]
Internet Draft 5 February 2003
Subsequently the above-described issues are discussed in more detailed:
Negotiation which entity is charged:
First the end points need to negotiate/determine which end
point will be charged for what part of the total cost. Once it
has been decided the networks along the path (Parkway model)
or the access networks have to be informed about this decision
since they finally need to know where to get the money from.
In existing telecommunication networks it is not only possible
to provide this negotiation capability at the beginning of the
session but also during an establish session or even
afterwards. The term session in this context refers to a
telephone call. Because of the stateless principle we assume
that there is no such session concept and hence it is fair to
say that the negotiation is done first (but with the option to
be changed at any time).
In this context it is interesting to mention that ST-II [9]
provides an object to indicate which entity to charge for the
reservation. Such object is not included in the base RSVP
RFCs. We believe that such information should belong to a QoS
signaling protocol since it delivers the necessary information
to the networks in order to setup the accounting and charging
procedures.
In the literature (for example in [5], in [10] and in [11]) an
additional degree of control has been introduced by allowing
the sender and the receiver to share their costs according to
a fractional part. Furthermore it is possible the the two
parties share different types of costs (see Section 5). Hence
it would be possible to charge the sender for the QoS
reservation but to charge the receiver for application
specific costs. It is needless to say that this adds
additional complexity.
Price Distribution:
Aspects of price distribution are discussed in Section A but a
summary of the most important issues is given in this section.
Two problems arise when determining the price of the
reservation. First, the price cannot be immediately referred
from the IP address. Second, the asymmetry of routes at router
and AS level (see [12]) and the possibility of asymmetric
costs for a single link in the uplink or downlink direction
requires that the direction is considered.
H. Tschofenig et. al. [Page 8]
Internet Draft 5 February 2003
The process of price determination, price distribution and
authorization/charging is likely to be periodic since the
duration of the reservation is unknown. The soft-state
principle used in NSIS requires periodic refresh messages to
keep a reservation in place. Hence there is a question whether
the price determination, price distribution and
authorization/charging mechanism should be closely tight to
this refresh interval. There is clearly a tradeoff between
performance (computational and bandwidth requirements) and
accuracy/efficiency. If price determination, price
distribution and authorization/charging mechanism is bound to
the refresh interval and the refresh messages are transmitted
at a very high rate then substance overhead might be caused.
From a user perspective it seems to be important that cost
transparency is provided and that the end host has the ability
to determine the cost of a reservation and has the ability to
perform cost control.
Authorization of a reservation:
Whenever authorization is discussed in this context then the
ability to provide assurance for charging is meant. This is,
however, only of interest where an end host is participating
in the signaling message exchange and depending on the chosen
model which part of the signaling path is considered. For
intra-domain traffic (traffic within an administrative domain)
authorization is much simpler: An incoming signaling message
hitting a router within the domain is authenticated and
verification is required to ensure that the message is
transmitted from a known router within the same domain. This
assumes that the borders are properly protected and discard
unprotected signaling message from other domains.
Authorization for a QoS reservation from an end host to the
attached network requires some guarantee that a particular
entity can be charged for the cost of the reservation. The
charged entity is likely to be one of the end hosts. The
establishment of the necessary infrastructure is either based
on a per-session communication (e.g. micro-macro payment
protocols, authorization tokens) or more traditionally as part
of the network access procedure (e.g. AAA communication).
Depending on the model (NJ Turnpike or NJ Parkway model) and
on the choice for charging of the data sender or the data
receiver per-session established authorization setup might be
required. From a performance perspective the per-session based
approach is less favorable.
H. Tschofenig et. al. [Page 9]
Internet Draft 5 February 2003
QoS Signaling:
Finally there is the question how the above-described steps
should be most efficiently combined with the behaviour of a
QoS signaling protocol.
Principally either the data sender or the data receiver can be charged
for a QoS reservation. Since signaling protocols are typically
characterised as either sender- or receiver-initiated, an answer has to
be provided which approach allows a better integration with various
charging strategies. Unfortunately, it is not possible to consider only
charging for the data sender since charging for the data receiver is
often used in todays telecommunication networks (e.g. 800# numbers,
collect calls).
In this version of the document we mainly focus on the simpler NJ
Turnpike model. Future versions will extend the descriptions to the NJ
Parkway model.
To simplify representation the AAA infrastructure is not shown in Figure
3, 4, 5 and in 6. Hence to get a complete picture the reader has to take
the AAA infrastructure into account. This might involve interaction with
local AAA servers, interaction with a Credit Control Server for the
purpose of real-time cost and credit control as described in [13] or
home AAA servers in case of mobility as depicted in Section 7.
6.1 Sender initiated reservations with charging for the data sender
This model is the simplest in relationship with the NJ Turnpike model
since the data sender S which triggers the reservation is also charged.
The necessary charging infrastructure is likely to be established as
part of network access authentication and the interaction with a AAA
infrastructure. When AS 1 receives a QoS reservation request which asks
for the establishment of a QoS reservation then an authorization check
can immediately be executed. Authorization might not only be based on
credit availablility but also on some information stored with the
subscriber's contract such as contract type or some form of policy which
might also be distributed as part of the initial network access
procedures or on-demand accessible via the AAA infrastructure. The
subscriber's contract is a business relationship between the user and
his home provider.
To provide cost control for the data sender it is likely that additional
communication between AS 1 and the initiator S is necessary to
distribute the necessary information. The initiator S might want to know
the price for the QoS reservation in advance before issuing a QoS
reservation message (RESV message in Figure 3 based on the RSVP
terminology). Hence for in-band price distribution a separate roundtrip
H. Tschofenig et. al. [Page 10]
Internet Draft 5 February 2003
is required. For out-of-band price determination such a roundtrip can be
omitted but some tariff or price information has to be communicated
between the sender S and the access network (AS1 in our case) - if not
already known for some other reason.
For in-band price distribution each network (or even each router) along
the path accumulates cost and AS 1 charges S for the total amount. Based
on the existing peering relationship between neighboring networks each
provider charges its neighboring provider. This procedure might be
comparable with the postal service where a customer gives a letter to a
post post office and delegates responsibility to perform the required
shipping. The post office might itself delegate the responsibility to
other companies to transport the letter to its final destination. The
sender pays for the total amount for the shipment at the post office
which knows the total cost for the entire delivery. Each participating
party receives the monetary amount negotiated with its "peer" based on
the previously agreed price. A similar description is provided in [14].
+----+ RESV +----+ RESV +----+ RESV +----+ RESV +----+
|AS 1|----->|AS 2|----->|AS 3|----->|AS 4|----->|AS 5|
+----+ +----+ +----+ +----+ +----+
^ |RESV
|RESV v
+----+ +----+
| S | | R |
+----+ +----+
Data Traffic
================================================>
Charging (S -> AS1 -> AS2 -> AS3 -> AS4 -> AS5)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>
Legend:
----> Signaling message
====> Data flow
~~~~> Charging direction
Figure 3: Sender-initiated reservation with charging for the data sender
6.2 Sender initiated reservation with charging for the data receiver
H. Tschofenig et. al. [Page 11]
Internet Draft 5 February 2003
Charging for the data receiver is more complex in comparison to charging
for the data sender. The reason is not due to the QoS signaling
machinery - such as sender- or receiver-initiated reservations but
caused by the complicated charging relationships. The following
description tries to describe the problem in more detail which is
depicted in Figure 4:
When AS 1 receives the RESV signaling message from S which indicates
that R is charged for the price of the QoS reservation then AS 1 needs
some assurance that the entity R is willing to pay for the indicated
reservation. Hence a plain identifier containing the identity of R is
insufficient to provide enough assurance.
Hence the sender needs to possess some from of authorization token which
allows AS 1 to establish the necessary association to a party which is
able to provide the financial settlement. Following the idea of such an
authorization token the subsequently described interaction is necessary.
An authorization token previously send from R to S and then transmitted
to AS 1 might allow AS 1 to establish the necessary infrastructure
(possibly to a trusted third party or to R's home network) to execute a
real-time credit check and to be able to charge R via this
infrastructure by AS 1 for a given QoS reservation. Then the QoS
reservation is done in the same way as a sender-initiated reservation
with charging for a data sender. The total cost for the session cannot
be fully determined during the reservation setup because the duration of
a call and other factors are unknown at the beginning. Hence periodic
communication is necessary between AS 1 and a trusted third party or R's
home network. R needs to be given a mechanism to allow the QoS
reservation and therefore the costs to be restricted without always
transmitting authorization tokens to the data sender for periodic re-
authentication and re-authorization procedures.
Note that the sender S communicate the name of the data senders access
network (in this case AS 1) to the receiver R. This allows the data
receiver R to request an authorization token for a specific network with
the indicated QoS parameters to include some additional restrictions in
the token.
It is not very likely that the data receiver R provides direct payment
to S before triggering a QoS reservation. Such an infrastructure is not
likely to be available.
6.3 Receiver initiated reservation with charging for the data receiver
The properties of the sender initiated reservation with charging for the
data receiver described-above are similar to those of a receiver
H. Tschofenig et. al. [Page 12]
Internet Draft 5 February 2003
+----+ RESV +----+ RESV +----+ RESV +----+ RESV +----+
|AS 1|----->|AS 2|----->|AS 3|----->|AS 4|----->|AS 5|
+----+ +----+ +----+ +----+ +----+
^ |RESV
|RESV v
+----+ +----+
| S | | R |
+----+ +----+
Data Traffic
================================================>
Payment (R -> AS1 or R -> S)
<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Charging ([S ->] AS1 -> AS2 -> AS3 -> AS4 -> AS5)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>
Legend:
----> Signaling message
====> Data flow
~~~~> Charging direction
Figure 4: Sender-initiated reservation with charging for the data
receiver
initiated reservation.
When AS 1 receives a PATH signaling message then S has to indicate that
R is willing to pay for the QoS reservation. Unfortunately the PATH
message (with the semantics defined within RSVP) cannot be used to
determine the price of a reservation since the receiver is allowed to
change the QoS parameters. Hence the computed price might only serve to
compute the upper-bound and would therefore only serve R as a hint. AS 5
cannot use an out-of-band price distribution mechanism because of
asymmetric routes. Hence price distribution can only be probing based
(in-band).
Finally after a successful reservation the receiver R (or some party
associated with R) has to provide a financial settlement with AS 1 to
transfer the desired QoS costs.
A major question is therefore whether it is possible for R to provide
financial settlement with AS5 although the reservation price is
H. Tschofenig et. al. [Page 13]
Internet Draft 5 February 2003
determined from S to R (data flow direction).
AS 1 therefore has to determine the price for the reservation and
communicate the accumulated price along the path to AS 5 and to R.
TBD: Is it possible for R establish a financial settlement with AS5 to
provide peer-to-peer charging in the reverse direction(R -> AS 5 -> AS 4
-> AS 3 -> AS 2 -> AS 1) although authorization for the RESV message
would be required at AS 1?
+----+ PATH +----+ PATH +----+ PATH +----+ PATH +----+
|AS1 |.....>|AS2 |.....>|AS3 |.....>|AS4 |.....>|AS5 |
| |<-----| |<-----| |<-----| |<-----| |
+----+ RESV +----+ RESV +----+ RESV +----+ RESV +----+
^ | . ^RESV
PATH. v RESV PATH v |
+----+ +----+
| S | | R |
+----+ +----+
Data Traffic
================================================>
Charging (R -> AS1 or R -> S)
<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Charging ([S ->] AS1 -> AS2 -> AS3 -> AS4 -> AS5)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>
Legend:
----> Signaling message
====> Data flow
~~~~> Charging direction
Figure 5: Receiver-initiated reservation with charging for the data
receiver
6.4 Receiver initiated reservation with charging for the data sender
When the sender S transmits a PATH message neither S nor AS 1 are able
to determine the cost for the reservation solely based on the semantic
of the PATH message. The PATH message is forwarded towards the data
receiver. R then finally decides about the reservation and its
H. Tschofenig et. al. [Page 14]
Internet Draft 5 February 2003
parameters but S is charged for the reservation.
It seems to be difficult for the sender S to restrict the QoS parameters
selected by the receiver R when transmitting the RESV message. It would
therefore be better if either a double roundtrip is used or if the
semantics of the PATH message is changed.
+----+ PATH +----+ PATH +----+ PATH +----+ PATH +----+
|AS1 |.....>|AS2 |.....>|AS3 |.....>|AS4 |.....>|AS5 |
| |<-----| |<-----| |<-----| |<-----| |
+----+ RESV +----+ RESV +----+ RESV +----+ RESV +----+
^ | . ^RESV
PATH. v RESV PATH v |
+----+ +----+
| S | | R |
+----+ +----+
Data Traffic
================================================>
Charging (S -> AS1 -> AS2 -> AS3 -> AS4 -> AS5)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>
Legend:
----> Signaling message
====> Data flow
~~~~> Charging direction
Figure 6: Receiver-initiated reservation with charging for the data
sender
6.5 NJ Parkway Model Example
The following example shows the implications for a sender initiated
reservations with charging for the data sender based on the NJ Parkway
model.
The sender needs some mechanisms to provide information to all
intermediate domains which request independent charging from the data
sender (i.e. from S). This mechanism can be provided by the following
procedures:
H. Tschofenig et. al. [Page 15]
Internet Draft 5 February 2003
· Information carried within the NSIS protocol (e.g. OSP tokens)
which immediately allow the intermediate domain to contact some
trusted third party (such as a clearing house).
· The possibility for an intermediate network to request
authentication / authorization from the data sender S via NSIS.
Such a mechanism might therefore be similar to SIP.
· An out-of-band mechanism which is triggered by intermediate
networks to request authentication and authorization from
intermediate networks.
In-band price distribution (or probing) is difficult to use since the
data sender is not aware of the QoS reservation costs along the entire
path (without a previous query). Out-of-band price distribution might
provide this functionality but a separate interaction with each domain
to the end host is required. When transmitting some sort of
authorization tokens it might be useful for the data sender S to have
information about the QoS reservation costs of all individual
intermediate domains along the path.
7 Implication of Mobility
This section addresses some of the implications of mobility. Starting
with a simple model at the beginning which allows limited mobility in
the same administrative domain some basic observations are made.
Extending the basic model to support to mobility to support mobility
where both users are registered at the same home network but roam to
different access networks (different from the home network). Finally
even this restriction is abolished.
7.1 Simple model without mobility
In Figure 7 two nodes are attached to a single administrative domain
either in a non-mobile environment (traditional enterprise network) or
with limited mobility in this network. No roaming agreements are
necessary and even authentication during network access might be
simplified due to a larger degree of freedom for selecting the proper
security infrastructure (for example Kerberos everywhere). To provide
authorization of a QoS reservation request role based access control
might be used since momentary authorization might not be applicable in
an enterprise network. Instead users or groups with specific rights
might be allowed to trigger QoS reservations. In this case it might not
even be necessary to communicate information who is charged for which
information to the network elements. Inter-domain communication for QoS
signaling messages and for AAA communication is not required.
H. Tschofenig et. al. [Page 16]
Internet Draft 5 February 2003
+------------------------------------------------------------------+
| |
| +------+ Network |
| -+ AAA/ +-- X |
| --- | PDP | ---- |
| --- +------+ ----- |
| --- ----- |
| --- ---- |
| ----- --- |
| +---+----+ +---+----+ |
| | Router | | Router | |
+------| 1 |--------------------------------------| n |--+
+---+----+ +---+----+
| |
+--+---+ +--+---+
| Node | | Node |
| A | | B |
+------+ +------+
Figure 7: Simple model without mobility
7.2 Split between access and home network(s)
With Figure 8 the basic environment described in Figure 7 is extended by
allowing end hosts to roam to networks (denoted as access network)
beyond their home networks. As part of the network access authentication
the end host is authenticated to its home network involving entities
(such as the local AAA server in the access network). AAA inter-domain
communication is required. The QoS signaling messages stay within the
same access network which is different than the home network.
Additionally the user might be registered at different home networks.
These networks primarily serve the purpose of providing a guarantee that
the indicated user requesting resources (and network access) is able to
pay. This functionality can be provided by a traditional
telecommunication network, by a credit card company or by something
similar.
In comparison to the previous model it is likely that role-based access
control is not sufficient for the purpose of QoS reservation request
authorization. Hence it might be necessary for the end hosts to decide
which entity (user A at node A or user B at node B) has to be charged
for which resource (QoS reservation, QoS data traffic, etc.). The access
network then collects accounting records and transmits bills to the
indicated home network of the authenticated user. Since the QoS
H. Tschofenig et. al. [Page 17]
Internet Draft 5 February 2003
signaling messages travel only within a single administrative domain it
is not necessary to address issues raised in Section 4.
+----------------------+ +----------------------+
| +------+ | | +------+ |
| | AAA | Home | | | AAA | Home |
| | | Network | | | | Network |
| +--+---+ (User A)| | +--+---+ (User B)|
| | | | | |
| | | | | |
+----+-----------------+ +----+-----------------+
| |
+---------------------------+-----------------+
|
+--------------------------------+-----------------------------------+
| +--+---+ Access Network |
| | AAA/ | |
| | PDP | |
| +--+---+ |
| +---------------------+-----------------------+ |
| | | |
| +---+----+ +---+----+ |
| | Router | | Router | |
+------| x |------------------------------------| y |------+
+---+----+ +---+----+
| |
+--+---+ +--+---+
| Node | | Node |
| A | | B |
+------+ +------+
Figure 8: Split between access and home network(s)
7.3 Global mobility
As an extension of the previous model global mobility is considered
where users are subscribed at different home networks and they roam in
different networks. The networks between the two access networks (X and
Y), which are traversed by the QoS signaling message, are omitted. This
scenario addresses issues discussed in Section 4 and 6. Note that the
AAA Broker is not necessarily required if the two home networks (of user
H. Tschofenig et. al. [Page 18]
Internet Draft 5 February 2003
A and B) share a business and trust relationship (and consequently a
security association).
+----------+
| AAA |
+-----------------------+ Broker +----------+
| +----------+ |
+----+-----------------+ +----+-----------------+
| +--+---+ | | +--+---+ |
| | AAA | Home | | | AAA | Home |
| | | Network | | | | Network |
| +--+---+ (User A)| | +--+---+ (User B)|
| | | | | |
| +----+ | | +----+ |
| | | | | |
+---------+------------+ +---------+------------+
| |
+---------+------------+ +---------+------------+
| | | | | |
| +--+---+ | | +--+---+ |
| | AAA/ | | | | AAA/ | |
| | PDP | | | | PDP | |
| +---+--+ | | +---+--+ |
| | | | | |
| Access Network X | | Access Network Y |
| | | | | |
| +---+----+ | | +---+----+ |
| | Router | | | | Router | |
+------| x |------+ +------| y |------+
+---+----+ +---+----+
| |
+--+---+ +--+---+
| Node | | Node |
| A | | B |
+------+ +------+
Figure 9: Global mobility
8 Security Considerations
This document describes the implications of two accounting and charging
models (i.e. the New Jersey Turnpike and the New Jersey Parkway model)
for NSIS QoS signaling. As excepted, there are implications for the
H. Tschofenig et. al. [Page 19]
Internet Draft 5 February 2003
security architecture. The New Jersey Turnpike model is based on the
peer-to-peer security and the chain-of-trust. This model, although often
criticised, serves as the basis for RSVP and some of its mechanisms such
as local repair and the aggregation mechanism. The second model, the New
Jersey Parkway model, relaxes the assumption of the first model. The
introduced end-to-middle authentication adds additional complexity.
This document does not discuss concrete security mechanisms for both
models, instead the implications are presented at an abstract level.
Hence it is not useful to give detailed security requirements and
threats.
Based on the topics discussed in this draft the NSIS working group
should decide on which model QoS signaling should be based. Additionally
it is necessary to discuss sender- and receiver-initiated signaling and
finally the impacts of price distribution need to be addressed.
9 Open Issues
· Non-repudiation is a security property where one party is later
unable to deny the execution of a specific action. For QoS
signaling this might be a desirable property. When added to a
signaling protocol this property, unfortunately, is not for free.
Hence it is an open question whether real-world applications and
architectures demand this property.
10 Acknowledgements
Place you name here.
A Price Distribution
How much an entity is charged for individual parts of a QoS reservation
(see Section 5) is mainly a matter of business/marketing decisions and
will not be discussed in this document and is outside the scope of NSIS.
The task of determining the price is called pricing. Unfortunately the
price of a QoS reservation cannot easily determined based on the
structure of the IP address unlike with E.164 phone numbers. Depending
on the chosen price distribution mechanism implications for an NSIS
signaling protocol exist.
Principally, two ways of price distributions can be identified:
Out-of-band price distribution: Using this approach the inter-
domain prices for certain destinations a distributed by
mechanisms executed separate from a NSIS in-path signaling
protocol. In case of out-of-band price distribution it is
required that the price is determined based on destination AS
H. Tschofenig et. al. [Page 20]
Internet Draft 5 February 2003
and the ASes along the path to this network. If the price for
one or more networks along this path then some additional
signaling is required. The main assumption of this scheme is
that the information obtained by the BGP-based sink tree
mechanism provides a good approximation to the path
subsequently taken by the later data packets.
In-band probing: The signaling messages enable some functions to
query the costs along the path to determine the costs between
the source and the destination. To discover the networks along
the path is fairly simple if a signaling protocol used used
(in-band probing). As a disadvantage a signaling protocol
needs to carry new objects and additional processing is
required at each network along the path. Hence it is required
that each network understands and processes these objects.
In the past a number of price distribution protocols have been proposed
which have a strong relationship to the signaling machinery, since they
share common properties:
· The determined price depends on the route between source network
and destination network. Protocols which allow their objects to
be embedded into the signaling protocol (in-band probing) are
able to more accurately determine the path and therefore the
associated costs.
· Some flexibility and extensibility is required to allow
autonomous systems to determine the price for a QoS reservation
independently of other domains.
· Signaling price information between various networks suffers from
the same signaling protocol requires (such as scalability, "in-
path" discovery, etc.) as QoS signaling protocols. To tackle
scalability similar mechanisms for aggregation are therefore
considered such as those used in [7].
· Unfortunately none of the proposals cares about the issues
described in Section 4 introduced by the two different models.
In [11] an in-band probing approach is presented which allows price
information to be communicated. The pricing object is updated along the
path to reflect costs. The idea of the Simple RSVP protocol [15] also
seems to follow a similar strategy.
RNAP [10] is a proposal which allows both in-band probing and out-of-
band price distribution. The out-of-band price distribution mechanism is
modeled according to the same principles as BGRP's aggregation and
protocol mechanism [7]. The aggregation mechanism of BGRP is inspired by
H. Tschofenig et. al. [Page 21]
Internet Draft 5 February 2003
BGP [16]. A very similar idea was chosen by the Border Pricing Protocol
(BPP) [17], which uses the same aggregation mechanism but only allows
out-of-band price distribution.
The Tariff Distribution Protocol (TDP) [18] is an attempt to define
message formats (using XML, HTML, plain text or even in a binary format
e.g. JAVA classes) and attributes for exchanging tariff information
either in an in-band (for example with RSVP) or out-of-band fashion.
Instead of exchanging price information in [18] tariff are communicated.
The term tariff is thereby defined as: "A tariff is a set of rules for
calculating the charge advices for session of one service" (see Section
2 of[18]). The difference between charge and charge advice is also
described in Section 2 of [18]. Unlike in other proposals aggregation is
not considered.
In the Billing Information Protocol (BIP) [19] only attributes used to
deliver price information are described (in BNF notation). The current
specification mainly addresses SIP as a transport mechanism but can be
used for other protocols as well.
Related to the work described above is the Open Settlement Protocol [20]
which is mainly focused on charging and not on price distribution. Hence
it should be seen as complementary to the above schemes which could be
used to support the New Jersey Parkway Model described in Section 4.
The work in the Internet Open Trading Protocol (IOTP) working group (see
[21] for the IOTP Version 1.0 specification) aims to map real world
transactions to the internet and is as such a superset of the
functionality described in this document.
B Authors' Addresses
Sven Van den Bosch
Alcatel
Francis Wellesplein 1
B-2018
Antwerpen
Phone: 32-3-240-8103
EMail: sven.van_den_bosch@alcatel.be
Maarten Büchli
Alcatel
Francis Wellesplein 1
B-2018
Antwerpen
EMail: maarten.buchli@alcatel.be
H. Tschofenig et. al. [Page 22]
Internet Draft 5 February 2003
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
EMail: schulzrinne@cs.columbia.edu
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
EMail: Hannes.Tschofenig@siemens.com
C Bibliography
[1] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, and S. Jamin,
"Resource ReSerVation protocol (RSVP) -- version 1 functional
specification," RFC 2205, Internet Engineering Task Force, Sept. 1997.
[2] B. Aboba, P. Calhoun, S. Glass, T. Hiller, P. McCann, H. Shiino, G.
Zorn, G. Dommety, C. Perkins, B. Patil, D. Mitton, S. Manning, M.
Beadles, P. Walsh, X. Chen, S. Sivalingham, A. Hameed, M. Munson, S.
Jacobs, B. Lim, B. Hirschman, R. Hsu, Y. Xu, E. Campbell, S. Baba, and
E. Jaques, "Criteria for evaluating AAA protocols for network access,"
RFC 2989, Internet Engineering Task Force, Nov. 2000.
[3] R. Hancock, I. Freytsis, G. Karagiannis, J. Loughney, and S. V. den
Bosch, "Next steps in signaling: Framework," Internet Draft, Internet
Engineering Task Force, 2002. Work in progress.
[4] R. Yavatkar, D. Pendarakis, and R. Guerin, "A framework for policy-
based admission control," RFC 2753, Internet Engineering Task Force,
Jan. 2000.
[5] S. Shenker, D. Clark, D. Estrin, and S. Herzog, "Pricing in computer
networks: Reshaping the research agenda," in Proc. of TPRC 1995 , 1995.
[6] F. Baker, C. Iturralde, F. L. Faucheur, and B. Davie, "Aggregation
of RSVP for IPv4 and IPv6 reservations," RFC 3175, Internet Engineering
Task Force, Sept. 2001.
[7] P. Pan, E. Hahne, and H. Schulzrinne, "Bgrp: Sink-tree-based
aggregation for inter-domain reservations," in Journal of Communications
and Networks, Vol. 2, No. 2, pp. 157-167, http://www.cs.columbia.edu/
pingpan/papers/bgrp.pdf , 2000.
H. Tschofenig et. al. [Page 23]
Internet Draft 5 February 2003
[8] Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M. Speer, R.
Braden, B. Davie, J. Wroclawski, and E. Felstaine, "A framework for
integrated services operation over diffserv networks," RFC 2998,
Internet Engineering Task Force, Nov. 2000.
[9] C. Topolcic, "Experimental internet stream protocol: Version 2 (ST-
II)," RFC 1190, Internet Engineering Task Force, Oct. 1990.
[10] X. Wang and H. Schulzrinne, "Rnap: A resource negotiation and
pricing protocol," in International Workshop on Network and Operating
Systems Support for Digital Audio and Video (NOSSDAV'99), pages 77--93,
Basking Ridge, New Jersey
[11] M. Karsten, J. Schmitt, and R. Steinmetz, "An embedded charging
approach for rsvp," in International Workshop on Quality of Service '98,
Napa, California, USA , May 1998.
[12] L. Amini and H. Schulzrinne, "Observations from router-level
internet traces," in DIMACS Workshop on Internet and WWW Measurement,
Mapping and Modeling, (Piscataway, New Jersey) , Feb. 2002.
[13] H. Hakala et al. , "Diameter credit control application," Internet
Draft, Internet Engineering Task Force, June 2002. Work in progress.
[14] J. Gerke, H. Ritter, J. Schiller, and K. Wehrle, "Elements of an
open framework for pricing in the future internet," in Proceedings of
the Conference on Quality of future Internet Services (QofIS 2000),
pages 300--311, Berlin
[15] K. Fujikawa and Y. Goto, "Simple resource ReSerVation protocol
(SRSVP)," Internet Draft, Internet Engineering Task Force, Feb. 2000.
Work in progress.
[16] Y. Rekhter and T. Li, "A border gateway protocol 4 (BGP-4)," RFC
1771, Internet Engineering Task Force, Mar. 1995.
[17] V. Oberle, H. Ritter, and K. Wehrle, "Bpp: A protocol for
exchanging pricing information between autonomous systems," in
Proceedings of HPSR 2001 (IEEE Workshop on High-Performance Switching
and Routing), Dallas (USA) , May 2001.
[18] O. Heckmann et al. , "Tariff distribution protocol (TDP),"
Internet Draft, Internet Engineering Task Force, Mar. 2002. Work in
progress.
[19] R. Prasanna, "Bip: Billing information protocol," Internet Draft,
Internet Engineering Task Force, 2002. Work in progress.
H. Tschofenig et. al. [Page 24]
Internet Draft 5 February 2003
[20] E. T. S. Institute, "Telecommunications and internet protocol
harmonization over networks (tiphon); open settlement protocol (osp) for
inter- domain pricing, authorization, and usage exchange, technical
specification 101 321. version 2.1.0."
[21] D. Burdett, "Internet open trading protocol - IOTP version 1.0,"
RFC 2801, Internet Engineering Task Force, Apr. 2000.
H. Tschofenig et. al. [Page 25]