INTERNET-DRAFT David Mitton
AAA Working Group Nortel Networks
Expires April 2001 November 2000
Proxy Nodes in AAA Configurations
draft-ietf-aaa-proxies-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
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
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document is a product of the AAA Working Group of the Internet
Engineering Task Force (IETF). Comments should be submitted to the
mailing list aaa-wg@merit.edu.
Abstract
This document describes the issues and gives examples of typical proxy
systems in AAA applications. The purpose of this effort is to set the
reference space evaluating and improving AAA protocols, such as the
Diameter protocol, currently being reviewed in this WG. This first
version sets out some of the issues and requirements. The next version
will add some solution proposals.
Mitton Informational, Expires April 2001 [Page 1]
Internet-Draft AAA Proxies Oct 2000
Table of Contents
1. INTRODUCTION.......................................................3
1.1 What are Proxies? ...............................................3
1.2 Why are there Proxies? ..........................................3
2. EXAMPLES OF PROXY CONFIGURATIONS...................................3
2.1 Routing Proxies .................................................3
2.2 Policy Proxies ..................................................4
2.3 Broker Proxies ..................................................4
2.4 Translation Proxies .............................................5
3. PROBLEMS CREATED BY PROXIES........................................5
3.1 Reliability of Request Transactions .............................5
3.2 Failover and backup message paths ...............................6
3.3 Graceful shutdown and system restart ............................6
3.4 Security/Visibility of information end-to-end ...................6
3.5 Integrity of Accounting information .............................6
3.6 Message Filtering and Editing between Administrative Domains ....7
3.7 Potential for Aggregation and Server Congestion .................7
4. SUMMARY............................................................8
Mitton Informational, Expires March 2001 [Page 2]
Internet-Draft AAA Proxies Oct 2000
1. Introduction
Proxy systems are used in AAA implementations to solve a number of
real-world problems. Their use is not arbitrary, but driven by
practical information management problems that are not obvious at first
pass.
1.1 What are Proxies?
Proxies are systems that behave like servers, yet pass the work on to
other network systems using the same protocol. They appear to be a
server to their client, and as a client to their upstream server.
1.2 Why are there Proxies?
Proxies are useful for several reasons:
- They distribute administration of systems to a configurable grouping,
including security associations,
- They can be used for concentration of requests from an number of NAS
equipment to a set of like user groups
- They can do value-added processing to the requests or responses
- They can used for load balancing,
- A complex network will have multiple authentication sources, they can
sort requests and forward towards the correct target
2. Examples of proxy configurations
Types of proxies
- Routing Proxies
- Policy Proxies
- Broker Servers
- Translation gateways
2.1 Routing Proxies
Routing Proxies servers take requests, examine the identifying
information (e.g. User-Name with NAI, Called-Number, Calling-Number)
and decide which authentication server to forward the request to. This
"decision" process is usually a lookup list with domain and server
information.
No other part of the message is examined or altered. This server can
service a number of NASes, perhaps in a common geographical area (POP),
and thus becomes a service and maintenance aggregation point.
The local NASes only have to be configured to know the proxies systems
in their POP. And they don't have to be configured to know the
security information of all the possible AAA servers. Only the routing
proxy needs that information. Likewise the AAA servers do not need to
know about all of the individual NASes and their security info.
Note that all security association information is mutual. Every system
that can contact another, that system must know about it, or have a way
to know it.
Dynamic security resolution has two problems in AAA systems. One is the
latency to lookup and resolve the security credentials. The amount of
Mitton Informational, Expires March 2001 [Page 3]
Internet-Draft AAA Proxies Oct 2000
time allowed to authenticate the user is on the order of seconds.
Secondly, there are the administrative limits desired. Just because
it's possible from a security protocol aspect, doesn't mean that it's
allowed from an access standpoint.
Being able to authenticate is not enough, the AAA capability must be
allowed by management.
Because of the simplicity of the decision, a routing proxies does not
need to "care" (save state) about the request, or it's eventual outcome
(accepted or denied), and are often considered "stateless" with respect
to the protocol.
2.2 Policy Proxies
Policy proxies are intermediate systems that implement policy
enforcement over a set of systems by keeping the state of the access
devices and it's resource usage and controlling admission and
provisioning.
These type of systems provide a value-add function on the NAS or group
of NASes using the existing protocols and authentication servers.
Often used in call control centers or access ISPs that provide
outsourced connections, they can monitor the number and types of ports
in use, and make allocation and admission decisions according to their
configuration.
With the use of request messages at call arrival time, even call pickup
or busy determinations can be made, before going off-hook.
(Note that this use of "policy" may be different than other group's
technical terms)
2.3 Broker Proxies
Broker proxies are intermediate systems that act as go-betweens for
different administrative domains and protocols. Typically a broker
provides routing between a local access ISP and a target corporate or
remote ISP account.
Brokers can provide roaming access to the a user's internet account in
geographically diverse POPs. This access is provided as a service, and
an service agreement (SLA) is made between the broker and the target
networks, as well as between the broker and the access network.
While the broker does not need to know the authenticating particulars,
it does need to be able to enforce the SLA service allowed. It may
also have to translate between various AAA protocols and administrative
differences.
Depending on the accounting relationship, the Broker may be entrusted
to get the correct information from the access network for billing to
the user's network.
Mitton Informational, Expires March 2001 [Page 4]
Internet-Draft AAA Proxies Oct 2000
Brokers must support a diverse and homogenous set of vendor's equipment
and must deal with the vagaries of this customer base.
2.4 Translation Proxies
As we phase-in a new AAA protocol to replace RADIUS, it will be typical
that host software will be updated before existing NASes with embedded
code are upgraded or replaced with new equipment.
It will expected to see NASes continuing to speak RADIUS to their
nearest proxy, which will then interface with a Diameter server or
infrastructure.
This will allow the network to move forward, while capital costs of
equipment are preserved.
3. Problems created by proxies
Once an intermediary is involved in the protocol, some issues solved in
point-to-point protocols become more complex. Some past AAA protocols
have used UDP as an unreliable datagram service, thus had to be
conscious about reliability issues. However, in a proxy environment, a
reliable transport is insufficient, as intermediate systems may suffer
problems that need to be compensated for.
3.1 Reliability of Request Transactions
The end goal is for the transaction to be processed by the target
system, and a response be returned. To this end, the NAS system will
attempt to retransmit or find alternate paths. Since it needs to
satisfy the incoming access process, it ultimately "owns" this problem.
The issues arise in how to handle the progress of the request up-the-
chain.
In UDP, you do not get an indication of receipt. But even a transport
that can, does not get any advantage on the next step, of whether the
proxy can successfully transmit to the upstream host.
This is a multi-step problem. The proxies can attempt to move the
request forward, and if any hop has a failure, engage failover
mechanisms. But if the proxy has no backup, or fails altogether, it
should have a way to signal the originating NAS (if possible) so the
originator can attempt it's own failover.
The detection of a lost link or a lost packet comes down to same issue,
timers. The traditional problem with TCP/IP is that the link level
timers are too long for real-time applications. By the time they
expire, the initial access event has timed out. A transport (or
protocol) which can give positive feedback on the success of a per-hop
transmission, lets us adjust toward an application level timeout
instead of a link level timeout. Failure to be able to move forward in
the chain has be detected as soon as possible, so that alternatives can
be tried.
Mitton Informational, Expires March 2001 [Page 5]
Internet-Draft AAA Proxies Oct 2000
The feature of the protocol would be to give either quick negative and
positive feedback to real progress vs delays for processing. This
feedback would allow the NAS source to choose a recovery mechanism.
3.2 Failover and backup message paths
In the case of primary failure, an alternate path can be attempted.
But the protocol should also provide for the detection of the
resumption of service on a previously failed path. This could be via a
poll message or an explicit restart indicator message. Such messages
must be defined, and the reception and processing understood by both
parties.
3.3 Graceful shutdown and system restart
If the administration of the system can afford a graceful shutdown,
then the protocol MUST have a way to signal to it's peer, that it is
about to leave the network. Then the peer can engage it's alternate
path immediately.
Likewise when a system rejoins the network, if it has fixed
relationships it can tell it's peer's it's back on-line. Otherwise it
may have to wait for a recovery poll message.
In accounting networks, where the true event record is desired, the
event of the start and stop of service should be recorded.
3.4 Security/Visibility of information end-to-end
In outsourced and wireless networks there is a strong desire to hide
any user-specific information not necessary for the routing of the
message. Such as the desire to conceal the exact personal name of
subscribers. Perhaps by the use of device or account numbers
accounting can be performed without direct knowledge of the user.
Clearly, only the authenticating system needs to see the complete
authenticating information. And therefore it is desirable to hide
sensitive user attributes values end-to-end.
However, in most cases, the NAS is supported by the access network, and
implements the link level authentication protocol (e.g. PPP) as
standardized. This gives the NAS system full access to the
information. Only challenge/response systems (like CHAP), or one-time
passwords (like SecurID) or a multi-exchange protocol (like EAP) can
factor out the NAS having access to a password equivalent.
3.5 Integrity of Accounting information
It's fairly straight forward for the accessed network to accurately
account for the usage at the NAS. It's harder for the subscriber
network to trust information remotely generated, unless there are ways
to correlate it with it's own records.
Mitton Informational, Expires March 2001 [Page 6]
Internet-Draft AAA Proxies Oct 2000
We need to be able to receive and record accounting information in a
way that cannot be easily faked or altered, and provides straight
forward correlation with events visible in the target network.
3.6 Message Filtering and Editing between Administrative Domains
There are several sets of requirements that come in to play with
providing a service over several Administrative domains.
Access networks must make sure authorization parameters fit their
network configuration and capabilities.
Subscriber networks must allow authorization of only provisioned
services, but must allow for varied network implementations.
Due to the flow, the access network is closest to the NAS and gets the
final say. The access network proxy may examine the return message for
attributes that are not implemented by its equipment, parameters that
would affect local network configuration (e.g. static routes or
addresses), or services not provided. It could modify the message, by
changing values or removing attributes, or even decide to deny service.
Broker networks may add value by editing return information, and
providing a full service template. (filling in for consistency, adding
for referral service) They can alleviate some of the issues just
mentioned above by only providing standard service templates and
screening subscriber specific data in their server.
If the authorization service is stateful, it will want to know about
these downstream changes. A Service-Start message should be added to
the protocol to convey this information back upstream.
3.7 Potential for Aggregation and Server Congestion
Server flow control issues
In general, the amount of traffic from a given NAS will be determined
by it's call rate, which is typically not that high for real-world
servers. (and will be much less than it's data rate) However, with
multiple NASes being serviced by the same server, it's possible that
AAA traffic will converge on a server and overload it.
Servers also may have local throughput limitations based on the service
characteristics of the protocol. For example, in RADIUS the server
does not get an acknowledgement for it's replies. To detect a
retransmitted request message, the original reply must be held for some
period of time, until it's believed to have gotten though. The output
throughput is then limited by the number of active message buffers
configured in the queue, times the holding time. Additional requests
are discarded silently (there's no rexmit later message either). This
type of overflow should be analyzed for, and, if possible, designed to
have minimal effect.
Mitton Informational, Expires March 2001 [Page 7]
Internet-Draft AAA Proxies Oct 2000
4. Summary
There are a number of different ways to solve the proxy problems. As
we propose some solutions in this space, we will look at and evaluate
each for tradeoffs.
Mitton Informational, Expires March 2001 [Page 8]