instruct the foreign provider about the desired accounting record
type and report frequency, the home AAA server sends an accounting
policy indication to the foreign AAA server. The indication contains
the accounting policy. Instead of sending an indication, the
accounting policies could also be piggy backed onto an authorization
reply. If the foreign AAA server is able to configure devices in a
way to enforce the desired policy (e.g. the meters are capable of
metering the requested attributes) the accounting policy indication
is acknowledged. In case the requested policy cannot be enforced,
the accounting service is denied. Reasons to deny the enforcement of
a specific accounting policy could be, e.g. because the meter is not
capable of measuring the requested attributes or the frequency of
records cannot be provided, or the home provider is not authorized to
get the requested detailed data. In this case procedures would be
useful to negotiate the smallest common denominator for the involved
AAA servers regarding the provisioning of accounting data.
8. Accounting with different Authorization Models
The AAA authorization framework [RFC2904] introduces different
message sequences for authorization. The integration of configurable
accounting services for the message sequences can be done as
described in the following sections.
8.1 Agent Sequence
The appropriate accounting policy for the authorized service is
either stored together with the authorization policy or in a separate
repository. The configuration of the accounting infrastructure can
be done together with the user configuration of the service equipment
(messages 2 and 3 in Figure 9). User-specific configuration of the
service equipment and the accounting infrastructure configuration
might involve the transfer of configuration data to multiple entities
in the network (e.g. to different routers for setting up QoS
provisioning or to dedicated accounting meters).
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 4 | +-------------------+ |
| User | | | ^ ^ |
| | | |2 |3 |AcctRec |
| | | V | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
+------+ | |
+-------------------------+
Figure 9: Accounting and Agent Sequence
In the agent sequence, it is possible to allow the user to send
accounting policies (e.g. for accounting indications) together with
the authorization request to the AAA server. Figure 9 shows the
agent sequence authorization and accounting messages.
8.2 Pull Sequence
The configuration of the accounting infrastructure can be done
similar to the agent sequence during the user configuration of the
service equipment. Since the pull sequence does not involve the
sending of a specific authorization request (e.g. if the service
equipment is a Network Access Server (NAS) and the authorization
sequence simply starts with the dial-in process), it would need
additional communication to support accounting policy indications
from users.
+-------------------------+
+------+ | Service Provider |
| |AccPolInd +-------------------+ |
| |.........>| AAA Server | |
| |<.........| | |
| | | +-------------------+ |
| User | | ^ | ^ |
| | | |2 |3 |AcctRec |
| | | | V | |
| | 1 | +-------------------+ |
| |-------+->| Service | |
| |<------+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
Figure 10: Accounting and Pull Sequence
This can be, for instance, achieved by a hybrid model of agent and
pull sequence where the user sends an accounting policy indication to
the AAA server in addition to the messages exchange for the pull
sequence. Figure 10 shows the pull sequence authorization and
accounting messages.
8.3 Push Sequence
In the push sequence, there is no direct connection between the AAA
server and the service equipment. In this sequence there are three
possibilities for setting up the accounting infrastructure:
a) A standard fixed accounting procedure that has been assigned in
advance for the specific combination of authorized user and service
is used.
b) The ticket (message 3 in Figure 11) contains information about the
accounting policies used (e.g. different tickets for the same service
with different accounting policies).
c) The ticket acts as a kind of digital coin and no further
accounting is needed. This model also supports the anonymous usage
of a service.
Figure 11 shows push sequence authorization and accounting messages.
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 2 | +-------------------+ |
| User | | ^ |
| | | | AcctRec |
| | | | |
| | 3 | +-------------------+ |
| |------+->| Service | |
| |<-----+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
Figure 11: Accounting and Push Sequence
8.4 Roaming
If the provisioning of the service and the final authentication/
authorization process is done by different organizations, accounting
is rather coupled to the service provisioning process than to the
authentication/authorization process. Since the data doesn't have to
traverse the home providers network, the home provider has no
possibility of collecting data about the resource consumption.
Therefore, accounting will usually take place in the foreign provider
domain (i.e. in the domain that does the service provisioning).
Nevertheless, in order to ensure consistency of the authentication,
authorization and accounting processes (e.g. allocation of user IDs
to accounting records) and the production of a bill, a connection
between the accounting process in the service provisioning domain and
the deciding authentication/authorization process (e.g. at the home
provider) is needed.
A possible way of doing this is if the foreign provider gets the
accounting policies from the home provider and sets up the accounting
architecture in accordance to the given policies, the foreign
provider can generate accounting records and send them back to the
home provider. The home provider then can apply charging and can
produce a bill. An example for this is given in section 9.2. This
scenario requires a prior agreement between the involved providers
about the possible policies and parameters that are allowed to be
set.
9. Examples
The following examples illustrate the use of policy-based accounting.
Please note that the services used in the examples are used only for
illustration purposes and their use in reality requires different
messages and parameters.
9.1 Printing Service Example
The Internet Printing Protocol (IPP) [RFC2566], and especially the
"print-by-reference" model, provides a very interesting example
scenario for accounting and the interaction between authorization and
accounting. We will describe possible solutions for the accounting
of this service and how the accounting is triggered by the
authorization. We will show how the model presented above can be
used for this example.
IPP "print-by-reference" allows a user to request a print service to
print a particular file. The file to be printed is not on the client
system but rather on a public server. That is, the clients print
request can contain a reference, or pointer, to the document instead
of the actual document itself. The print service must then read the
file to a file server (used for spooling) prior to the printing.
There are two possible setups: The file and print server either
belong to a single organization (Intra-Domain Accounting) or to two
different organizations (Inter-Domain Accounting). In the first
case, the user must be authorized by a single service provider for
service usage. In the second case, two different possibilities for
establishing a trust relationships between the involved entities have
to be distinguished [RFC2905].
9.1.1 Intra-Domain Accounting
In the case of a single organization, the file and print service is
provided by a single service provider. The service subscriber and
user role are either one entity (e.g. private home user) or different
entities (e.g. company as subscriber, employee as user). For data
transport via the underlying network, the transportation service of a
network provider is used. In this case, the AAA server of the
provider controls the access to the file and the print server. This
means the AAA server enforces the accounting policies and collects
accounting data for both servers.
9.1.2 Inter-Domain Accounting
If two different organizations are involved there are two
possibilities for trust relationships as shown in [RFC2905]:
1. The user has an agreement with the print server; the print
server has an agreement with the file server.
2. The user has agreements with both print and file server.
In case 1, the user is first authorized by the print service and the
request is forwarded to the file server. The file server authorizes
the print server and determines if the printer is allowed to access
the file. In this case which is shown in Figure 12, the accounting
policies from the user arrive at the print service AAA server.
USER DOMAIN PRINT SERVICE DOMAIN FILE SERVICE DOMAIN
| |
+------+ | |
| | | |
| | | |
| | | +--------------------+ | +-------------------+
| User |---1-->| Print Service |---1-->| File Service |
| |<--2---| AAA Server |<--2---| AAA Server |
| | | +--------------------+ | +-------------------+
| | | | Print Server | | | File Server |
| | | | and Printer | | | |
+------+ | +--------------------+ | +-------------------+
1: AccPolInd, 2: AccPolConf
Figure 12: Inter-Domain Accounting and Printing Service
The print service AAA server has to decide which policies can be
enforced locally and which must be passed further to the file service
AAA server. The print service can add additional accounting
policies. In case the file server does not support the desired
accounting policies, the print server must notify the user's AAA
server and some policy conflict resolution must occur. After the
file server has transferred the file to the print service, it
generates an accounting record according to the accounting policy and
passes it to the print service. The print service generates the
final accounting record for the service session based on its own and
the file service data after finishing printing. This record will be
used for the later billing process. Additionally, the print server
can send the final record to the user's AAA server. There it can be
used for later authorization decisions based on used resources, i.e.
if the customer is a company and the user is an employee.
In case 2, the customer AAA server has an agreement with file and
print server. In this case, the user's AAA server sends accounting
policies to the file and the print server. After finishing the
service, both servers generate accounting records for the delivered
services which are used for later billing. As in the former case,
the accounting data can be sent to the user's AAA server for use in
later authorization decisions. The user's AAA server can tie both
accounting records together and assign them to the user using audited
session information (authorization and accounting messages for a
particular session could be coupled via a session ID) and policies
that define which activities a certain session is composed of.
9.1.3 User Accounting Indication
For the printing service, there are a number of possible options for
sending accounting indications to the user. Accounting indications
give the user an indication of how much resources have been used
until the time of the indication. A user can receive accounting
indications or not depending on the accounting policy for the user.
For Internet printing with the "print-by-reference" model, such
indications would be very helpful for the user. Since the file is
not on the clients site, the user might not have information on the
file size or the number of pages that will be printed. This means
the user has no idea of the costs of the service usage. If user and
subscriber are a single entity, accounting indications would help
users to avoid exceeding their spending limit. Additionally,
accounting indications give the user a hint as to which resource
usage has caused the charges. This can be compared to an itemized
telephony bill where not only the monetary sum per month is printed
but, in addition, information for every call (start time, duration,
distance etc.) and its corresponding charge.
9.2 Mobile/Roaming Example
In this section, the "Dial-in with Roaming" example from the
authorization examples [RFC2905], [RFC2002] is used to show how
accounting functions could interact with authorization functions.
The accounting modules (e.g. collectors and meters) are seen here as
part of the service equipment which is, in this example, located at
the visited ISP premises. The basic configuration of the accounting
modules is probably done by the visited ISP itself, but the visited
ISP can allow the home ISP to influence certain parameters (like
report interval or accounting record format). This is useful if the
home provider generates the invoice and therefore needs appropriate
accounting records to calculate the prices.
User | Visited ISP | Home ISP
| |
| | +-----------+ ..........
<--------------------12-------------------| Charging, |<-:charging:
| | | Billing | :policies:
| | +-----------+ :........:
| | ^
| | |
| | +-----------+
| | | ASM |
| | +-----------+
| | ^
| | |11
| | |
| +------------+ | +-------------+
| | | | | |
| | |---10---->| |
| | | | | |
Acct. Records | AAAF Server|----3---->| AAAH Server |
<-----------------| |<---4-----| |
| | | | | |
| | | | | |
| +------------+ | +-------------+
| ^ | ^ |
| | | | |
| | 5 9 |
| | | | |
| | V | |
| | +----------------+|
| | | ASM ||
| 2 | ||
| | +----------------+|
| | | ^ |
| | | | |
| | 6 8 |
| | | | |
| +------------+------+-------+ |
7 | | Service | | | |
<--------| Equipment | +----------+| |
1 | | |->|Accounting|| |
-------->| | +----------+| |
| | config | | | |
| | | +---------+ | |
| | +->| Meters | | |
| | +---------+ | |
| +---------------------------+ |
| |
Figure 13: Roaming Example
The exchange of authorization data corresponds to the example in
[RFC2905]. As an additional component, we introduce an ASM between
home AAA and service equipment for the user configuration which
happens after successful authorization. The extended roaming example
is shown in Figure 13. Steps (1), (2) and (3) describe the
forwarding of an authentication/authorization request from the user
via the AAA sever of the visited ISP to the home AAA server. In step
(4), user specific service parameters are given to the visited ISP's
AAA server and are forwarded to the service equipment (5) where the
user configuration is done. The user-specific service parameters
could additionally include the desired policies for the configuration
of the accounting infrastructure of the visited ISP. An accounting
policy could be, for instance, "for user X one accounting record of
type Y has to be generated every 30 seconds". This accounting policy
is used by the visited ISP to configure his modules (e.g. metering,
data collection).
User-dependent service parameters are converted by the ASM into the
appropriate configuration information (6). Then the user is informed
about the completed authentication/authorization process (7). The
accounting architecture starts metering the resource usage and sends
metering records to the ASM (8). The ASM uses the metered data to
fill the required accounting records and sends them to the visited
ISP's AAA server (9). The visited ISP can either post-process the
data or directly forward them to the home ISP (10). With this data
as input, an invoice is generated by the charging and billing modules
within the home providers domain (11) by using charging policies
(tariff formulas), and then sent to the user/customer (12).
As an additional option, accounting records can also be offered to
the user (accounting indication) as a special service. For this
special service a separate authorization is required.
9.3 Diffserv Example
This example explains how integrated accounting is configured via
policies for a Diffserv service [RFC2475] based on bandwidth brokers
[I2-BB]. The service is the transport of packets with a higher
priority and the service includes accounting and QoS auditing.
Figure 14 shows the service setup. The user issues a Service Request
(SR) for a Diffserv service to the AAA server. The request contains
a user ID and the parameter for the desired service class.
User->AAA: user-x@nw-a, service=diffserv, class=gold,
amount=2Mbit, dest= nw-b
In this example, user-x is located at network A (nw-a) and requests a
gold class service for all flows from this network to the destination
network B (nw-b). After authentication and authorization has been
completed successfully, the AAA server extracts the ASI from the
request and passes them to the ASM of the Diffserv service.
AAA->ASM: service=diffserv, class=gold, amount=2Mbit, src=nw-a
dest=nw-b
The ASM takes over the task of translating the application specific
information into appropriate user configuration information for the
service equipment. For the given Diffserv example, the service
equipment consists of three components: accounting equipment, the QoS
auditing equipment and the bandwidth broker architecture. The ASM
has to address all three components to set up the requested service
for the user. The translation of the ASI into configuration
information for the components can be done by evaluating service
provisioning policies. For example, the ASM could have the following
service provisioning policy:
if class==gold {
set bw-request.class = gold
set accounting.type = comprehensive
set qos-audit.metric = one-way-delay
...
}
This results in sending a bandwidth request to the BB which asks for
a gold service with the given parameters. Furthermore, the ASM
issues a request to the accounting equipment for comprehensive
accounting and a request to the QoS auditing equipment for a one-
way-delay measurement between the given networks.
ASM->BB: BW-request(gold, src=nw-a, dest=nw-b, amount=2Mbit)
ASM->Acct: Acct-request(comprehensive, src=nw-a)
ASM->QoS: QoS-audit-request(one-way-delay, src=nw-a, dest=nw-b)
The bandwidth broker then sets up the Diffserv infrastructure to
provide the prioritized forwarding according to the definition of a
gold class. This is done in accordance with the actual bandwidth
broker's architecture and is not further considered here. For the
Accounting Configuration and the QoS Audit Control, local
configuration policies exist for setting up the service.
Accounting-Policy:
if type==comprehensive {
set meter-location = access-point(nw-a)
set record type =detailed
set report interval = 120 s
set report target = 193.175.12.8
^ indent of last two lines
}
QoS-Measurement-Policy:
if metric==one-way-delay {
set method = passive
set timestampsize = 48 bit
set ingress-meter-location = access-point(nw-a)
set egress-meter-location = access-point(nw-b)
}
In this case, the local accounting policy sets the meter location to
the network access point of network A. It states that for
comprehensive accounting, a detailed record type is required with a
report interval of 120 s. The resulting records have to be sent to
the given report target. The QoS measurement policy sets the
measurement method to passive measurement. It sets the size used for
timestamp representation to 48 bits. As meter locations, the meters
at the access points of network A and network B are used.
After evaluating these policies, the instructions for the meter
configuration are passed down to the measurement infrastructure. In
our example, the accounting configuration instructs the meter at the
first measurement point (MP1) to add a new rule with the given flow
attributes and settings for storage and reporting of results.
Acct->MI: MP1: add rule dscp=23, src=a.a.a/24, dest=b.b.b.b/24
save volume
set report interval = 120 s
set report target = 193.175.12.8
SR +-------+
User ----------------->| AAA |
+-------+
|
| ASI
V
+-------+
+-----------------| ASM |--------------+--------------+
| Policy +-------+ Policy | BW Request |
| Parameters Parameters | |
| | |
-----|----------------------------------------|--------------|-----
| Service Equipment | |
V V V
+---------------+ .............. +-----------+ +-----------+
| Accounting |<-->: Local :<-->| QoS | | Bandwidth |
| | : Policies : | Auditing | | Broker |
+---------------+ :............: +-----------+ +-----------+
| |
| Meter Instructions | Measurement Setup
V V
+--------------------------------------------------+
| Measurement |
| Infrastructure |
+--------------------------------------------------+
Figure 14: Diffserv Service Provision Setup
The QoS audit control instructs two meters (at MP1 and MP2) to set up
a passive one-way-delay measurement.
QoS->MI: MP1: add rule dscp=23, src=a.a.a.a/24 dest=b.b.b.b/24,
save timestamp-48
MP2: add rule dscp=23, src=a.a.a.a/24, dest=b.b.b.b/24,
save timestamp-48
9.4 User Accounting Indication Example
This example explains how discrete accounting can be used to provide
accounting indications for the user. Accounting indications are sent
to the user in order to inform the user about current resource
consumption. The accounting indication is a special accounting
service that can be provided in addition to the standard accounting
performed by the provider. Like for any other service, an
authorization should take place before the accounting indication
service provisioning. Therefore, the accounting here is seen as a
separate service. That means the accounting service is independent
of the main service and therefore can be applied to different
services. It might be used as an addition to an integrated
accounting that is part of the service. The authorization process
for the accounting service is out of the scope of this document and
therefore is not further explained here.
Figure 15 illustrates the configuration message sequence for setting
up the accounting service. First, the user sends an Accounting
Service Request (ASR) to the AAA server which includes desired
parameters for the provisioning of the accounting service (e.g.
report interval).
user->AAA: user-x@nw-a, service= accounting indications,
report interval= 60 s
The AAA server passes the ASI to the ASM of the accounting service
after the user has been authenticated and authorized for the service
usage.
AAA->ASM: user-x@nw-a, service=accounting indications,
report interval= 60 s
The ASM generates an accounting policy based on the ASI and passes
this policy to the Accounting Configuration.
ASM->Acct: If src=a.a.a.x {
acc-indication = on
report interval = 60s
report target= a.a.a.x
}
ASR +-------+
User --------------->| AAA |
+-------+
|
| ASI
V
+-------+
| ASM |
+-------+
|
-------------------------|---------------------------
Service Equipment | Accounting Policy
V
+-----------------+ ..............
| Accounting |<---->: Local Acct :
| | : Policies :
+-----------------+ :............:
|
| Meter Instructions
V
+-----------------+
| Measurement |
| Infrastructure |
+-----------------+
Figure 15: Accounting Indication Configuration
The Accounting Configuration generates meter instructions according
to the accounting policies from the ASM and local accounting policies
and passes them to the measurement infrastructure.
local Acct-Policy: if acc-indication {
record type = compact
}
Acct->MI: MP1: set report interval = 60 s
add report target = a.a.a.x
10. Security Considerations
Accounting services provide the basis for billing. Therefore, the
incentives (mainly saving money) and potential for fraud is extremely
high in the field of configuration of the accounting architecture and
the collection of accounting data. In the presented framework, two
types of data communications are required, the exchange of accounting
policies and the collection of accounting records. Both
communications introduce potential security hazards.
The following potential security hazards can be identified:
- Forgery of accounting policies and accounting record information
Both accounting policies and accounting records can be the target of
forgery of information. Accounting policies contain configuration
information. Modifying this information can lead to a mal-configured
accounting and metering system which either allows data to traverse
the accounting system undetected (without being accounted for, e.g.
by changing the classification rules of a meter) or produces bogus
accounting records. Accounting records contain data about resource
consumption and provide the basis for billing. Modifying accounting
records may lead to erroneous bills. Furthermore, it is important
that policies or accounting records are not redirected or removed and
that forged policies or records are not inserted.
- Eavesdropping
It may be required to keep accounting policies and accounting records
confidential between the involved parties.
- Denial of Service (DoS) attacks
Both the AAA server and the accounting/metering subsystem can be the
target of denial of service attacks. A denial of service attack
against the AAA server may lead to malfunction and even breakdown of
the server. This means the server will not be able to provide proper
authentication, authorization and accounting functionality. The
service provided by the AAA server will become unavailable or
unusable. An attack to the server can be worse than an attack to the
service equipment itself, especially if multiple services use one AAA
server. An attack against the accounting/metering system will cause
loss of metering data and/or loss of accounting records.
This leads to the following security requirements:
- Secrecy of accounting policies and accounting data
Unauthorized entities should not be able to read or modify accounting
policies or accounting records. This can be achieved with standard
encryption methods.
- Authentication of accounting data and accounting policy sources
It should be ensured that the data is originated by the original
source. Source-authentication can be achieved by using digital
signatures.
- Protection of the integrity of accounting policies and records
It should be ensured that the data was not modified on the way from
sender to receiver. Data-authentication can also be achieved with
digital signatures.
- Verify correctness of generated accounting data
It must be ensured that the accounting data generated by the service
provider is correct. A provider may generate incorrect accounting
records either deliberately (i.e. forging) or unintentionally (e.g.
faulty configuration). These incorrect accounting records probably
have the consequence of incorrect bills. Customers can verify the
correctness of the accounting data through their measurements and/or
through data collected by a trusted third party. A trusted third
party can be an independent accounting service provider as described
in section 7.2 or a more general entity providing an auditing
service.
- Prevention and protection against Denial of Service attacks
The AAA protocol and all building blocks should be designed and
implemented in a way as resistant as possible to denial of service
attacks. An additional strategy to defend against DoS attacks is to
add a component to the meter system that is able to detect suspicious
traffic patterns. Upon detection, further actions can be taken
according to a pre-defined policy.
The prevention of these hazards has to be considered for the
protocols used for accounting policy exchange and the transportation
of accounting records. Since the security requirements for
authentication, transmission level security, data object
confidentiality and integrity are addressed in the criteria for AAA
protocol evaluation [RFC2989], we assume that the future AAA
protocol(s) will be suited for secure accounting record transfer and
probably also for secure accounting policy transport. Furthermore,
we assume that existing or upcoming solutions for secure
transportation and enforcement of policies can be used. Real
prevention of DoS attacks is quite difficult. A selective dropping
of the attackers packets is impossible if the malicious packets
cannot be separated from the valid customer traffic. Dropping of all
packets of a certain type may prevent authorized customers from using
the service and therefore help the attacker to achieve her goal.
11. References
[I2-BB] Internet2-QBone Bandwidth Broker,
http://www.merit.edu/working.groups/i2-qbone-bb
[NetFlow] NetFlow Services and Applications, White Paper, Cisco
Systems, 1999
[RFC2002] Perkins, C., "IP Mobility Support", RFC3220, October
1996.
[RFC2123] Brownlee, N., "Traffic Flow Measurement: Experiences with
NeTraMet", RFC2123, March 1997.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC2475, December 1998.
[RFC2566] DeBry, R., "Internet Printing Protocol/1.0: Model and
Semantics", RFC2911, April 1999.
[RFC2722] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow
Measurement: Architecture", RFC2722, October 1999.
[RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J. and
D. Spence, "Generic AAA Architecture", RFC2903, August
2000.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and
D. Spence, "AAA Authorization Framework", RFC2904,
August 2000.
[RFC2905] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and
D. Spence, "AAA Authorization Application Examples", RFC
2905, August 2000.
[RFC2924] Brownlee, N. and A. Blount, "Accounting Attributes and
Record Formats", RFC2924, September 2000.
[RFC2975] Aboba, B., Arkko, J. and D. Harrington, "Introduction to
Accounting Management", RFC2975, October 2000.
[RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann,
P., Shiino, H., Walsh, P., Zorn, G., Dommety, G.,
Perkins, C., Patil, B., Mitton, D., Manning, S.,
Beadles, M., Chen, X., Sivalingham, S., Hameed, A.,
Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu, R.,
Koo, H., Lipford, M., Campbell, E., Xu, Y., Baba, S. and
E. Jaques, "Criteria for Evaluating AAA Protocols for
Network Access", RFC2989, November 2000.
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
J. and S. Waldbusser, "Terminology for Policy-Based
Management", RFC3198, November 2001.
12. Acknowledgments
The authors would like to thank the members of the AAAARCH research
group and in particular, the chairs, John Vollbrecht and Cees de
Laat, for the fruitful discussions and comments. Special thanks are
to Bernard Aboba, Nevil Brownlee and Ed Ellesson for their review and
valuable input to this document.
Author's Addresses
Tanja Zseby
Fraunhofer Institute for Open Communication Systems
Kaiserin-Augusta-Allee 31
10589 Berlin
Germany
Phone: +49-30-34 63 7153
Fax: +49-30-34 53 8153
EMail: zseby@fokus.fhg.de
Sebastian Zander
Fraunhofer Institute for Open Communication Systems
Kaiserin-Augusta-Allee 31
10589 Berlin
Germany
Phone: +49-30-34 63 7287
Fax: +49-30-34 63 8287
EMail: zander@fokus.fhg.de
Georg Carle
Fraunhofer Institute for Open Communication Systems
Kaiserin-Augusta-Allee 31
10589 Berlin
Germany
Phone: +49-30-34 63 7149
Fax: +49-30-34 63 8149
EMail: carle@fokus.fhg.de
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.