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]