INTERNET-DRAFT David Mitton AAA Working Group Nortel Networks Expires April 2001 November 2000 Proxy Nodes in AAA Configurations draft-ietf-aaa-proxies-01.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 interim version begins to address solutions to some of the issues raised earlier. This document will evolve into an explanation of the issues we are concerned with and the recommended solutions. Mitton Informational, Expires April 2001 [Page 1] Internet-Draft AAA Proxies Nov. 2000 Table of Contents 1.0 INTRODUCTION......................................................3 1.1 What are Proxies? ...............................................3 1.2 Why are there Proxies? ..........................................3 2.0 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.0 PROBLEMS CREATED BY PROXIES.......................................5 3.1 Message, Transaction, and Session State .........................5 3.2 Reliability of Request Transactions .............................5 3.2.1 Positive Feedback Scheme .....................................6 3.2.2 Negative Feedback Scheme .....................................7 3.2.3 Exception Feedback Scheme ....................................7 3.3 Failover and backup message paths ...............................7 3.4 Graceful shutdown and system restart ............................7 1.1 Security/Visibility of information end-to-end ...................8 1.2 Integrity of Accounting information .............................8 3.5 Message Filtering and Editing between Administrative Domains ....9 3.6 Potential for Aggregation and Server Congestion ................10 4.0 SUMMARY..........................................................10 5.0 SECURITY CONSIDERATIONS..........................................10 6.0 RELATED DOCUMENTS:...............................................11 7.0 AUTHOR'S INFORMATION:............................................11 8.0 FULL COPYRIGHT STATEMENT.........................................12 Mitton Informational, Expires April 2001 [Page 2] Internet-Draft AAA Proxies Nov. 2000 1.0 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 can distribute administration of systems to a configurable grouping, including the maintenance of security associations, - They can be used for concentration of requests from an number of co- located or distributed NAS equipment sets 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.0 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 within 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. Mitton Informational, Expires April 2001 [Page 3] Internet-Draft AAA Proxies Nov. 2000 Dynamic security resolution has two problems in AAA systems. One is the latency to lookup and resolve the security credentials. The amount of 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 ultimate resolution of 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 April 2001 [Page 4] Internet-Draft AAA Proxies Nov. 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 the capital costs of equipment are preserved. 3.0 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 point-to-point reliable transport is insufficient, as intermediate systems may encounter problems that need to be compensated for. 3.1 Message, Transaction, and Session State Previously we mentioned "stateless" proxies. Well there really isn't such a thing. All proxies must carry some state to function with the protocol. The amount of state is key. a) Message State - the amount of state necessary to know if the message was transferred correctly to the next peer. For a UDP oriented message, this could include several retries. For a session oriented transport, this requires a transport acknowledgement. When the message has been reliably forwarded, this state is discarded. b) Transaction State - the amount of state to know if the transaction completed. That is we got a response from the target server and we have to forward that response back to it's client. The state information may help it recognize and remember the request and any further potential processing. When the response is forwarded to the client, this state is discarded. (In RADIUS it's possible to put the transaction state into a Proxy-State attribute value, and make the message carry the storage) c) Session State - the state used to remember the session being authenticated or authorized. If the proxy wishes to track sessions, it may keep state about the session and it's progress. This state is initialized for new sessions and discarded when the session terminates. 3.2 Reliability of Request Transactions Mitton Informational, Expires April 2001 [Page 5] Internet-Draft AAA Proxies Nov. 2000 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 mechanism, it ultimately "owns" this problem. The more sticky issues arise in how to best manage the progress of the request up-the-chain. In UDP, you do not get an indication of successful delivery. But even a transport that can, does not get any advantage with the next step, that is 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, they must engage failover mechanisms. But if the proxy has no backup, or fails altogether, it must have a way to signal the originating NAS (if possible) so that the originator can attempt it's own failover. The detection of a lost link or a lost packet comes down to the use of the same mechanism, timers. The traditional problem with TCP/IP is that the session level timers are much too long for real-time applications and they give no indication of trouble until it's too late. By the time they expire, the incoming access event in most cases timed out. The originating system must have sufficient notice of failure to attempt a failover operation. A set of possible timers in ascending value would be: T1 - time to confirm one hop T2 - time to confirm hops to authentication server T3 - time to confirm authentication & authorization T4 - time to complete authentication by accessing method 3.2.1 Positive Feedback Scheme A transport (or protocol) which can give positive feedback on the success of a per-hop transmission, lets the client adjust an application level timeout instead of a link level timeout. If a failure to move forward in the chain is detected as soon as possible, then the client can try alternatives. The feature of the AAA protocol would be to give either quick negative and positive feedback to real progress at each hops, instead of just silently forwarding. This feedback would allow the NAS source to choose a recovery mechanism in a timely manner. When a system decides that it will forward a request instead of processing itself, it MUST send a AAR to the client with the result code of PROXY-Forwarded. If the attempt to forward fails, it MUST send an AAR with an PROXY-Failed result code. (sub error code for failure type) As the message progressed up the proxy chain, the client would receive informational Response messages, until it receives a success or hard failure. The intermediate proxies would forward all of response back downstream. If it were keeping just message state, it could close that state upon receiving the first response. It would have to open another message state to forward the result down to the client. If it were Mitton Informational, Expires April 2001 [Page 6] Internet-Draft AAA Proxies Nov. 2000 keeping transaction state, it would only close that state when the final result was received and forwarded. 3.2.2 Negative Feedback Scheme The previous method would entail many messages that for the most part would be not useful in a network with little loss or latency. A scheme with less overhead would be to only feedback in failure situations. This is not that much different than the actual current design, and therefore has the same problems. However, we should add error codes to distinguish a proxy forward failure from an authentication failure. The client implementation should still recognize the difference, and given forwarding problems try a different path. 3.2.3 Exception Feedback Scheme A compromise or mixed scheme could attempt to add the least overhead but solve the most typical problems. In principle, acknowledgements should be sent to signal progress at the points of the transaction that indicate to the client that significant progress is being made, that would exclude premature recovery actions. Simple forwarding progress is mostly silent, but crossing administrative boundaries, arriving at a broker or remote server would be candidates for positive acknowledgements. A subsequent failure of processing would be more significant than a transient network communication problem. 3.3 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. With session oriented transports, part of the solution would be in re- establishing a connection. The ability to do this, would indicate a functional server. The connection should be attempted periodically after a failure, However given that connections are only established upon request traffic, if there is no outstanding state to that server, this is not strictly necessary. 3.4 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. Diameter provides for this by use of the Device Reboot Indicator message. The system shutting down SHOULD send this message with the Mitton Informational, Expires April 2001 [Page 7] Internet-Draft AAA Proxies Nov. 2000 shutdown value before disconnecting from the network. The peer acknowledges this message with a DRR response. If the peer has active state, it will have to retry those requests on it's backup system. In accounting networks, where the true event record is desired, the event of the start and stop of service should be recorded by the accounting server, based on the connection status logic, not driven by a message exchange. 1.1 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 identifiers or account numbers, accounting can be performed without direct exposure of the user identity. 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. PAP has been depreciated and it's use should be discouraged. CHAP authentication does not disclose the information to the intermediate systems. But this type of system could be prone to replay attacks as the NAS system gets to pick the challenge. EAP authentication suffers from the latency, and in some cases inability to do multiple round-trips over an partially opened channel. Technical problems remain with designing a lightweight mechanism where a random NAS could hide information from it's own infrastructure and in a way that a given remote server could decode it. Perhaps we need to look back upstream at the access protocol authentication methods. 1.2 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. 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. Message authenticators (hash codes) that cover a timestamp would make it difficult to tamper with accounting messages in flight. Event Mitton Informational, Expires April 2001 [Page 8] Internet-Draft AAA Proxies Nov. 2000 sequence numbers would also add a context that would have to be meshed with. Ultimately, some information or secret would have to be used which is known to the accounting source and the server to verify. A public key certificate would be an obvious choice, but this again begs the NAS overhead issue. It would make more sense to use a PKI-based encryption or signature on a provider's proxy server to sign accounting packets leaving an administrative domain. 3.5 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 AAA protocol message flow, the access network is closest to the NAS and gets the final say to that equipment. The access network proxy may examine the return authentication/authorization message for attributes that are not implemented by its equipment, parameters that would adversely affect local network configuration (e.g. static routes or addresses), or services not available. It could modify the message, by removing attributes or changing values, or even deciding to deny service. Broker networks may add value in their go-between position, by editing return information, and providing a service template. (filling in attributes for consistency, adding some identifying referral service) They can alleviate some of the issues just mentioned above by only providing standard service templates (as part of their brokering service) 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 the NAS provided service information back upstream. This also gives the authorization server the potential to shut off a service not being provided as requested. Some people want to argue about what various proxy servers can and cannot do. This seems to be the wrong direction. It is not possible for the AAA server to make the NAS do exactly what it said (particularly if it cannot due to implementation or configuration restrictions), and there are many reasons to want the instructions to be massaged. We should be talking about what the protocol requires to interoperate with some degree of consistency and expectation. There will be countless examples of valued added processing and service provisioning, that will all want to do clever things with AAA messages in the future. Mitton Informational, Expires April 2001 [Page 9] Internet-Draft AAA Proxies Nov. 2000 3.6 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 capability otherwise you are already under provisioned) However, with multiple NASes being serviced by the same server, it's possible that AAA traffic will converge on a server and overload it's processing capability. 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). These type of bottlenecks should be analyzed for, and, if possible, designed out or be minimized with be documented parameters. 4.0 Summary There are a number of different ways to solve the proxy problems. I have proposed some possible solutions in this space to get some discussion going. We must look at and evaluate each for tradeoffs. 5.0 Security Considerations AAA Protocols are an access security mechanism and must be analyzed as such. This document shows some of the operational issues that must be worked out to properly secure candidate protocols, such as Diameter. Mitton Informational, Expires April 2001 [Page 10] Internet-Draft AAA Proxies Nov. 2000 6.0 Related Documents: [1] B. Aboba, J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [2] D. Mitton, M. Beadles. "Network Access Server Requirements Next Generation (NASREQNG) NAS Model." draft-ietf-nasreq-nas-model- 01.txt, Work in progress. [3] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work in progress, June 2000. [4] B. Aboba, et.al. "Criteria for Evaluating AAA Protocols for Network Access" RFC 2989, Nov 2000. [5] D. Mitton, et.al. "AAA Protocol Evaluation", draft-ietf-aaa-proto- eval-01.txt, IETF work in progress, Oct 2000. [6] P. Calhoun et al. "AAA Protocol Issues" draft-ietf-aaa-issues- 04.txt, IETF work in progress, Nov 2000. [7] P. Calhoun, et al. "AAA WG Solutions" draft-ietf-aaa-solutions- 01.txt, IETF work in progress, Nov 2000. [8] C. Rigney, et.al. "Remote Authentication Dial In User Service (RADIUS)" RFC 2865, June 2000. [9] C. Rigney, et.al. "RADIUS Accounting", RFC 2866, June 2000. [10] P. Calhoun "Diameter Base Protocol", draft-calhoun-diameter- 16.txt, June 2000. [11] Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft-calhoun- diameter-framework-08.txt, IETF work in progress, July 2000. [12] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, W. Bulley, J. Haag, "DIAMETER Implementation Guidelines", draft-calhoun-diameter-impl- guide-04.txt, IETF work in progress, July 2000. 7.0 Author's Information: David Mitton Nortel Networks 880 Technology Park Dr. Billerica, MA 01821 Phone: 978-288-4570 Email: dmitton@nortelnetworks.com Mitton Informational, Expires April 2001 [Page 11] Internet-Draft AAA Proxies Nov. 2000 8.0 Full Copyright Statement Copyright (C) The Internet Society (Nov 2000). 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." Mitton Informational, Expires April 2001 [Page 12]