AAA Working Group Bernard Aboba INTERNET-DRAFT Microsoft Category: Informational 17 November 2000 AAA Transport Issues 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 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. 1. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 2. Abstract Protocols for Authentication, Authorization and Accounting (AAA) have been designed to run over a variety of transports. For example, RADIUS runs over UDP, TACACS+ runs over TCP, and DIAMETER runs over SCTP. However, while the pros and cons of various AAA transport layers has been endlessly debated, AAA transport behavior has never been thoroughly analyzed. This document analyzes the behavior of AAA protocols running over UDP, TCP and SCTP. Expected behavior of AAA protocols over these transports is discussed, and current research proposals that may affect this behavior are reviewed. 3. Introduction Protocols for Authentication, Authorization and Accounting (AAA) have been designed to run over a variety of transports. For example, RADIUS Aboba Informational [Page 1] INTERNET-DRAFT AAA Transport Issues 17 November 2000 [2],[3] runs over UDP, TACACS+ runs over TCP [5], and DIAMETER [4] runs over SCTP [6]. However, while the pros and cons of various AAA transport layers has been endlessly debated, AAA transport behavior has never been thoroughly analyzed. This document analyzes the behavior of AAA protocols running over UDP, TCP and SCTP. Expected behavior of AAA protocols over these transports is discussed, and current research proposals that may affect this behavior are reviewed. 3.1. Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [1]. 3.2. Terminology Accounting The act of collecting information on resource usage for the purpose of trend analysis, auditing, billing, or cost allocation. Administrative Domain An internet, or a collection of networks, computers, and databases under a common administration. Computer entities operating in a common administration may be assumed to share administratively created security associations. Attendant A node designed to provide the service interface between a client and the local domain. Authentication The act of verifying a claimed identity, in the form of a pre- existing label from a mutually known name space, as the originator of a message (message authentication) or as the end-point of a channel (entity authentication). Authorization The act of determining if a particular right, such as access to some resource, can be granted to the presenter of a particular credential. Billing The act of preparing an invoice. Broker A Broker is an entity that is in a different administrative domain from both the home AAA server and the local ISP, and Aboba Informational [Page 2] INTERNET-DRAFT AAA Transport Issues 17 November 2000 which provides services, such as facilitating payments between the local ISP and home administrative entities. There are two different types of brokers; proxy and routing. Client A node wishing to obtain service from an attendant within an administrative domain. End-to-End End-to-End is the security model that requires that security information be able to traverse, and be validated even when an AAA message is processed by intermediate nodes such as proxies, brokers, etc. Foreign Domain An administrative domain, visited by a Mobile IP client, and containing the AAA infrastructure needed to carry out the necessary operations enabling Mobile IP registrations. From the point of view of the foreign agent, the foreign domain is the local domain. Home Domain An administrative domain, containing the network whose prefix matches that of a mobile node's home address, and containing the AAA infrastructure needed to carry out the necessary operations enabling Mobile IP registrations. From the point of view of the home agent, the home domain is the local domain. Hop-by-hop Hop-by-hop is the security model that requires that each direct set of peers in a proxy network share a security association, and the security information does not traverse a AAA entity. Inter-domain Accounting Inter-domain accounting is the collection of information on resource usage of an entity within an administrative domain, for use within another administrative domain. In inter-domain accounting, accounting packets and session records will typically cross administrative boundaries. Intra-domain Accounting Intra-domain accounting is the collection of information on resource within an administrative domain, for use within that domain. In intra-domain accounting, accounting packets and session records typically do not cross administrative boundaries. Aboba Informational [Page 3] INTERNET-DRAFT AAA Transport Issues 17 November 2000 Local Domain An administrative domain containing the AAA infrastructure of immediate interest to a Mobile IP client when it is away from home. Proxy A AAA proxy is an entity that acts as both a client and a server. When a request is received from a client, the proxy acts as a AAA server. When the same request needs to be forwarded to another AAA entity, the proxy acts as a AAA client. Local Proxy A Local Proxy is a AAA server that satisfies the definition of a Proxy, and exists within the same administrative domain as the network device (e.g. NAS) that issued the AAA request. Typically, a local proxy will enforce local policies prior to forwarding responses to the network devices, and are generally used to multiplex AAA messages from a large number of network devices. Network Access Identifier The Network Access Identifier (NAI) is the userID submitted by the client during network access authentication. In roaming, the purpose of the NAI is to identify the user as well as to assist in the routing of the authentication request. The NAI may not necessarily be the same as the user's e-mail address or the user-ID submitted in an application layer authentication. Routing Broker A Routing Broker is a AAA entity that satisfies the definition of a Broker, but is NOT in the transmission path of AAA messages between the local ISP and the home domain's AAA servers. When a request is received by a Routing Broker, information is returned to the AAA requester that includes the information necessary for it to be able to contact the Home AAA server directly. Certain organizations providing Routing Broker services MAY also act as a Certificate Authority, allowing the Routing Broker to return the certificates necessary for the local ISP and the home AAA servers to communicate securely. Non-Proxy Broker A Routing Broker is occasionally referred to as a Non-Proxy Broker. Proxy Broker A Proxy Broker is a AAA entity that satisfies the definition Aboba Informational [Page 4] INTERNET-DRAFT AAA Transport Issues 17 November 2000 of a Broker, and acts as a Transparent Proxy by acting as the forwarding agent for all AAA messages between the local ISP and the home domain's AAA servers. Real-time Accounting Real-time accounting involves the processing of information on resource usage within a defined time window. Time constraints are typically imposed in order to limit financial risk. Roaming Capability Roaming capability can be loosely defined as the ability to use any one of multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confederations" and ISP- provided corporate network access support. Transparent Proxy A Transparent Proxy is a AAA server that satisfies the definition of a Proxy, but does not enforce any local policies (meaning that it does not add, delete or modify attributes or modify information within messages it forwards). 4. Overview While AAA protocols such as RADIUS [2],[3], TACACS+ and DIAMETER [4] differ in their functionality, from the point of view of transport layer behavior, similarities exist. With the exception of the unsolicited server messages supported in DIAMETER [4], AAA protocols can be characterized as a request made by a client, followed by a server response. Where EAP [10] is supported, multiple request/response sequences may occur, as described in [11]. Multiple authentication/authorization transactions per session may also occur if re-authorization is required. Multiple accounting messages per session may occur due to interim accounting, as described in [11]. In both cases, the time between messages is generally substantial. Steady state AAA transport behavior is typically application rather than network driven. For example, a 48-port NAS with an average session time of 20 minutes will on average send only 144 authentication/authorization requests/hour, and an equivalent number of accounting requests. This translates to an average inter-packet spacing of 25 seconds. Even on much larger NAS devices, the inter-packet spacing is often larger than the Round Trip Time (RTT). For example, a 2048-port NAS with an average session time of 10 minutes will on average send 3.4 authentication/authorization requests/second, and an equivalent number Aboba Informational [Page 5] INTERNET-DRAFT AAA Transport Issues 17 November 2000 of accounting requests. This translates to an average inter-packet spacing of 293 ms. Note that transient behavior can result in much lower inter-packet spacing. For example, after a NAS reboot previously stored accounting records may be sent to the accounting server in rapid succession. Similarly, after recovery from a power failure, users may respond with a large number of simultaneous logins. Thus while application-driven AAA transport behavior is the norm, there are situations in which behavior may be network driven. Note that even with high inter-packet spacings as seen by the NAS, it is possible for AAA clients and servers to experience congestion, even in the absence of any other traffic. For example, while a given AAA client may not send substantial traffic, many AAA clients may interact with a given AAA proxy or server. Thus routers close to a heavily loaded proxy or server may experience congestion, even though traffic close to the client is very light. For example, if 10,000 48-ports NASes were to use the same AAA proxy or server, that proxy or server would receive 400 authentication/authorization requests/second and an equivalent number of accounting requests. For 1000 octet requests, this could generate as much as 6.4 Mbps of incoming traffic at the AAA proxy or server. While such a transaction rate is within the capabilities of the fastest AAA servers and proxies, implementations exist that cannot handle such a high load, and thus high queuing delays and/or dropped packets may be experienced at the server, even if the routers on the path are not congested. Thus, a well designed AAA protocol needs to be able to handle congestion occurring at the AAA server, as well as congestion experienced within the network. 4.1. Proxy behavior As described in [2],[7] proxies have become a common feature of the AAA landscape in order to support services such as roaming and shared use networks. Such proxies are used both for authentication/authorization, as well as accounting [8]. As described in [7], two types of proxies exist: conventional proxies and store and forward proxies. A conventional proxy operates as shown below: (request) (request) NAS ----------> Proxy ----------> Server (reply) (reply) <--------- <--------- The sequence of events is as follows: Aboba Informational [Page 6] INTERNET-DRAFT AAA Transport Issues 17 November 2000 1. The NAS sends a request to the proxy. 2. The proxy forwards the request to the server. 3. The server sends a reply back to the proxy. 4. The proxy sends the reply to the NAS. With a store and forward proxy, the proxy may send a reply to the NAS prior to forwarding the request to the server. While store and forward proxies are most frequently deployed for accounting [8], they also can be used to implement authentication/authorization policy, as described in [7]. With a store and forward proxy, the sequence of events is as follows: 1. The NAS sends a request to the proxy. 2. The proxy sends a reply to the NAS. 3. The proxy forwards the request to the home server. 4. The home server sends a reply back to the proxy. As noted in [8], store and forward proxies can have a negative effect on accounting reliability. By sending a reply to the NAS without receiving one from the accounting server, store and forward proxies fool the NAS into thinking that the accounting request had been accepted by the accounting server when this is not the case. As a result, the NAS can delete the accounting packet from non-volatile storage before it has been accepted by the accounting server. The leaves the proxy responsible for delivering accounting packets. If the proxy involves moving parts (e.g. a disk drive) while the NAS does not, overall system reliability can be reduced. As a result, it is recommended that store and forward proxies not be used. While conventional proxies do not compromise accounting reliability, even the best proxy implementations can have a negative impact on congestion control. In AAA deployments involving proxies, proxy buffer handling determines whether the NAS and server will self-clock, limiting the rate of packets sent to that which can be supported by the bottleneck bandwidth. In general, self-clocking in proxy systems should not be taken for granted, even if the underlying transport supports this. Since buffer handling behavior is typically not described within the AAA protocol specification, end-to-end transport behavior of AAA protocols can be undefined even where reliable transport is specified. For example, let us examine the behavior of a conventional proxy forwarding packets between a NAS and a AAA server. In this case, let us assume that the bottleneck occurs between the proxy and the home server or on the home server itself. (request) (request) NAS ----------> Proxy ----------> Server (reply) (reply) Aboba Informational [Page 7] INTERNET-DRAFT AAA Transport Issues 17 November 2000 <--------- <--------- Bottleneck As a baseline for comparison, let us first examine the performance of the system in the case where the proxy is absent, allowing the NAS and server to communicate directly. Let us further assume that packets travel the same route between the NAS and Server with and without a a proxy. In this case, if the AAA protocol is run over a reliable transport such as TCP or SCTP, then communication between the NAS and home server will "self-clock", limiting the rate at which packets can be sent by the NAS to the rate at which they are received (and ACK'd) by the home server. Thus, the NAS is able to sense the bottleneck and respond by limiting the send rate. The situation changes considerably when a proxy is placed in the path. Where the Proxy does not limit the rate at which packets are received from the NAS to the rate at which they can be sent to the home server, the receive queue can build up, resulting in high delays and packet loss at the proxy. Thus, a proxy inserted between the NAS and home server can prevent "self-clocking" between the endpoints. However, even if the proxy maintains "back pressure", limiting the overall rate at which receive buffers are emptied to the overall rate at which packets can be sent, self-clocking may not be achieved. This is because self-clocking requires equilibrium between the receiving and sending rates between each client-server pair. This is only achievable if the intermediary maintains individual receive and send buffers for each client-server flow, or operates as a TCP or SCTP proxy. Application layer proxies typically do not do this, and as a result, congestion control may not be achievable in systems involving application layer proxies, even where the application-layer protocol operates over reliable transport. 5. AAA transport behavior In understanding the transport behavior of AAA protocols it is useful to understand the implications of operating within the application-driven regime. Potential effects are observed in several areas: Congestion control Fast re-transmit and fast recovery Nagle algorithm Delayed ACKs Aboba Informational [Page 8] INTERNET-DRAFT AAA Transport Issues 17 November 2000 5.1. Congestion control Congestion control principles [16] require the ability of a transport protocol to respond effectively to congestion, as sensed via increasing delays, packet loss, or explicit congestion notification. With network- driven applications, it is possible to respond to congestion on a timescale comparable to the round-trip time (RTT). However, with application-driven AAA protocols, the time between sends may be considerably larger than the RTT, so that the network conditions can not be assumed to persist between sends. For example, the congestion window may grow during a period in which congestion is being experienced, because few packets are sent, limiting the opportunity for feedback. Similarly, after congestion is detected, the congestion window may remain small, even though the network conditions that existed at the time of congestion no longer apply by the time when the next packets are sent. Several studies have addressed this issue. For example, [13] suggests that it may be appropriate to validate the congestion window. 5.2. Fast re-transmit and fast recovery When congestion window validation is implemented, the result is that AAA protocols operate much of the time in slow-start with an initial congestion window set to 1 or 2, depending on the implementation [20]. This implies that AAA protocols gain little benefit from the windowing features of reliable transport. Since the congestion window is so small, it is generally not possible to receive enough duplicate ACKs (3) to trigger fast re-transmit. As a result, dropped packets will require a retransmission timeout (RTO). A solution to this problem is proposed in [21]. Rather than reducing the number of duplicate ACKs required for triggering fast recovery, which would increase the number of inappropriate re-transmissions, it is proposed that the window size be increased, thus enabling the sending of additional packets which in turn may trigger fast re-transmit without a change to the algorithm. However, if congestion window validation is implemented, this proposal will have little effect on AAA protocol implementations, since additional packets will typically not be available for sending so as to take advantage of the increased window size. As a result, AAA protocols will typically operate with the lowest possible congestion window size, resulting in a re-transmission timeout for every lost packet. Aboba Informational [Page 9] INTERNET-DRAFT AAA Transport Issues 17 November 2000 5.3. Nagle algorithm At first glance, AAA protocols appear to be a good candidate for application of the Nagle algorithm [13], since AAA protocol messages are often smaller than the maximum segment size (MSS). While exceptions occur when certificate-based authentication issued or where a low path MTU is found, typically AAA protocol messages are less than 1000 octets. Therefore, the total packet count, and associated network overhead could be reduced by combining multiple AAA messages within a single packet. While this does not reduce the work required by the application in parsing packets and responding to the messages, it does reduce the number of packets processed by routers along the path. However, within the application-driven regime, the NAS will typically receive a reply from the home server prior to having another request to send. This implies, for example, that accounting requests will typically be sent individually rather than being batched by the transport layer. As a result, the Nagle algorithm [12] is ineffective. 5.4. Delayed ACKs Since the Nagle algorithm is typically not triggered in AAA exchanges, the typical behavior of a AAA protocol operating over TCP transport within the application-driven regime is show below. Time NAS Proxy Home Server ------ --- ----- ----------- 0 Request -------> OTTnp + Tpr Request -------> OTTnp + TdA Delayed ACK <------- OTTnp + OTTph + Reply/ACK Tpr + Tsr <------- OTTnp + OTTph + Tpr + Tsr + Reply OTThp + TpR <------- OTTnp + OTTph + Tpr + Tsr + Delayed ACK OTThp + TdA -------> OTTnp + OTTph + Aboba Informational [Page 10] INTERNET-DRAFT AAA Transport Issues 17 November 2000 OTThp + OTTpn + Tpr + Tsr + Delayed ACK TpR + TdA -------> Key --- OTT = One-way Trip Time OTTnp = One-way trip time (NAS to Proxy) OTTpn = One-way trip time (Proxy to NAS) OTTph = One-way trip time (Proxy to Home server) OTThp = One-way trip time (Home Server to Proxy) TdA = Delayed ACK timer Tpr = Proxy request processing time TpR = Proxy reply processing time Tsr = Server request processing time The first thing to notice about this trace is that ACKs may comprise as much as half of the traffic generated by the NAS and Proxy. This occurs because ACK parameters (such as the value of the delayed ACK timer) is typically fixed by the TCP implementation and is not tunable by the application. Since AAA traffic is application-driven, there is frequently not enough traffic to enable ACK piggybacking. Thus, the use of TCP transport by AAA protocols may result in as much as a doubling of traffic over what would be experienced with UDP transport. A detailed examination of the trace reveals the conditions under which this may occur. At time 0, the NAS sends a request to the proxy. Ignoring the serialization time, the request arrives at the proxy at time OTTnp, and the proxy takes an additional Tpr in order to forward the request toward the home server. At time TdA after receiving the request, the proxy sends a delayed ACK. The delayed ACK is sent, rather than being piggybacked on the reply, as long as TdA < OTTph + OTThp + Tpr + Tsr + TpR. Typically Tpr < TdA, so that the delayed ACK is sent after the proxy forwards the request toward the home server, but before the proxy receives the reply from the server. However, depending on the TCP implementation on the proxy and when the request is received, it is also possible for the delayed ACK to be sent prior to forwarding the request. At time OTTnp + OTTph + Tpr, the server receives the request, and Tsr later it generates the reply. Where Tsr < TdA, the reply will contain a piggybacked ACK. However, depending on the responsiveness of the AAA server and the server's TCP implementation, it is conceivable that the ACK and reply will be sent separately. This may be the case, for example, where a slow database or filestore must be consulted by the server prior to sending the reply. Aboba Informational [Page 11] INTERNET-DRAFT AAA Transport Issues 17 November 2000 At time OTTnp + OTTph + OTThp + Tpr + Tsr the reply/ACK reaches the proxy, which then takes TpR additional time to forward the reply to the NAS. At TdA after receiving the reply, the proxy generates a delayed ACK. Typically TpR < TdA so that the delayed ACK is sent to the server after the proxy forwards the reply to the NAS. However, depending on the circumstances and the proxy TCP implementation, the delayed ACK may be sent first. As in the case of the delayed ACK sent in response to a request, which may be piggybacked if the reply can be received quickly enough, piggybacking of the ACK sent in response to a reply from the server is only possible if additional request traffic is available to piggyback on. However, due to the high inter-packet spacings in typical AAA scenarios, this is unlikely unless the AAA protocol supports a reply ACK. At time OTTnp + OTTph + OTThp + OTTpn + Tpr + Tsr + TpR the NAS receives the reply. TdA later, a delayed ACK is generated. 6. TCP behavior [This section will describe other aspects of TCP behavior not described above] 7. SCTP behavior [This section will describe how SCTP will behave in the application- driven regime.]. 8. Server selection and failover In order to provide for improved reliability, it is typical for multiple AAA servers and/or proxies to be deployed. This then begs the question of how AAA clients should balance load between proxies/servers, and how they may failover to another proxy/server should the current choice fail. In approaching this issue, it is important to keep in mind the law of "conservation of packets" as articulated in [9]. The law of conservation of packets suggests that a client should not send another packet into the network until it can be reasonably sure that a packet has exited the network on the same path. In the case of a AAA client, the law suggests that it should not retransmit to the same server or choose another server until it can be reasonably sure that a packet has exited the network on the same path. If the client advances the window as responses arrive, then the client will "self clock", adjusting its transmission rate to the available bandwidth. How can a client determine whether a packet has left the network? If the client receives a response to a query to a server, then it can assume Aboba Informational [Page 12] INTERNET-DRAFT AAA Transport Issues 17 November 2000 that the server received that query. Another way is for the client to estimate RTT as well as its variation and use this to compute a retransmission timeout (RTO). Assuming that the RTO value represents an upper bound on the RTT then when the RTO timer expires it is reasonble for the client to assume that the request has left the network and that a reponse will not be forthcoming. In order to understand fully specify AAA failover on any given transport, the following elements need to be defined: a. RTT and RTO estimation procedures. For TCP and SCTP transports, this is defined as part of the transport; for UDP transport these algorithms need to be specified as part of the AAA transport mapping. b. The retransmission time-out (RTO), or the interval at which the client will re-transmit to the same server. This value is defined as part of the TCP [24] and SCTP [6] protocols, or in the case of UDP, as part of the AAA transport mapping. Note that even with a good RTO estimator, RTT distributions are typically heavy-tailed so that there will be some number of false re-transmits. As a result, AAA servers should be prepared to receive duplicate requests, and it is typical for server implementations to cache responses so as to make it possible respond to such duplicate requests more efficiently. c. The failover interval, or the interval at which the client will resend the query to an alternate server. This value is not determined by the transport, but is defined by the AAA protocol. In general, it is wise for this value to be at least double the RTO, so as to give the client the opportunity to re-transmit once to the same server prior to failing over. If the failover interval is less than RTO, then the client could have two packets in flight, one to each server, which would violate conservation of packets. If the failover interval is more than RTO, but less than 2RTO, then the re-transmission to the original server may be in flight when the client decides to failover, sending another packet to the alternate server. This also violates conservation of packets. To prevent the client having two packets in flight, one to each server, it is necessary for the client to stop re-transmitting to the original server prior to Aboba Informational [Page 13] INTERNET-DRAFT AAA Transport Issues 17 November 2000 failing over. This is typically not possible with TCP, but can be accomplished with UDP or SCTP [6]. d. Behavior in response to congestion. In general, congestion is signalled by packet loss or increases in the RTT. Increases in the RTT will tend to increase the re-transmission timer, as well as reducing the maximum rate at which packets may be sent into the network due to "self-clocking." However, since AAA protocols are typically application-driven, the time between packets may exceed the RTT. In such circumstances, AAA protocols cannot be said to "self-clock" and thus the rate at which AAA packets are sent will typically not be affected by congestion until packet loss occurs. However, even packet loss will not have an effect unless the inter-packet spacing is less than RTO! Note that where congestion window validation is applied, in AAA protocols the congestion window will typically remain at the minimum value most of the time, due to the large inter-packet spacings. Thus where congestion window validation is applied, responding to congestion by entering into "slow start" has no meaning because the AAA protocol is typically operating with the minimum congestion window anyway. Thus the notion of a congestion window only has meaning where validation is not applied, and where it may be desirable to operate with a congestion window larger than the minimum value. 9. Applicability of current research [This section will describe how current research proposals may address the issues described above]. 10. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Aboba Informational [Page 14] INTERNET-DRAFT AAA Transport Issues 17 November 2000 [2] Rigney, C., Willens, S., Rubens, A., Simpson, W., "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [3] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [4] Calhoun, P., Rubens, A., Akhtar, H., Guttman, E., "DIAMETER Base Protocol", Internet draft (work in progress), draft-calhoun- diameter-16.txt, July 2000. [5] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [6] R. Stewart et al., "Simple Control Transmission Protocol", Internet draft (work in progress), draft-ietf-sigtran-sctp-10.txt, June 2000. [7] Aboba, B., Vollbrecht, J., "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [8] Aboba, B., Arkko, J., "Introduction to Accounting Management", Internet draft (work in progress), RFC 2985, June 2000. [9] Jacobson, V., "Congestion Avoidance and Control", Computer Communications Review, ACM SIGCOMM, [10] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [11] Rigney, C., Willats, W., Calhoun, P., "RADIUS Extensions", RFC 2869, June 2000. [12] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1984. [13] Handley, M., Padhye, J., Floyd, S., "TCP Congestion Window Validation", RFC 2861, June 2000. [14] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999. [15] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, J., Heavens, I., Lahey, K., Semke, J. and B. Volz, "Known TCP Implementation Problems", RFC 2525, March 1999. [16] Floyd, S., "Congestion Control Principles", RFC 2914, September 2000. Aboba Informational [Page 15] INTERNET-DRAFT AAA Transport Issues 17 November 2000 [17] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-to-end Performance Implications of Slow Links", Internet draft (work in progress), draft-ietf-pilc-slow-04.txt, July 2000. [18] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [19] Braden, R., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K.K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998. [20] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998. [21] Allman, M., Balakrishnan H., Floyd, S., "Enhancing TCP's Loss Recovery Using Early Duplicate Acknowledgment Response", Internet draft (work in progress), draft-allman-tcp-lossrec-00.txt, June 2000. [22] Matt Mathis, Jamshid Mahdavi, Sally Floyd, Allyn Romanow. "TCP Selective Acknowledgment Options", RFC 2018, October 1996. [23] Floyd, S., Henderson, T., "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999. [24] Paxson, V., Allman, M., "Computing TCP's Retransmission Timer", Internet-Draft (work in progress), draft-paxson-tcp-rto-01.txt April 2000. [25] Floyd, S., Mahdavi, J., Mathis, M., Podolsky, M., Romanow, A., "An Extension to the Selective Acknowledgment (SACK) Option for TCP", Internet draft (work in progress), draft-floyd-sack-00.txt, August 1999. [26] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., Vaidya, N., "Long Thin Networks", RFC 2757, January 2000. [27] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997. 11. Security Considerations General security considerations concerning TCP congestion control are discussed in RFC 2581 [6]. Aboba Informational [Page 16] INTERNET-DRAFT AAA Transport Issues 17 November 2000 12. IANA Considerations This draft does not create any new number spaces for IANA administration. 13. Acknowledgments Thanks to the members of the AAA working group who have discussed and commented on AAA transport issues. 14. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 (425) 936-6605 Fax: +1 (425) 936-7329 Email: bernarda@microsoft.com 15. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 16. Full Copyright Statement Copyright (C) The Internet Society (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 Aboba Informational [Page 17] INTERNET-DRAFT AAA Transport Issues 17 November 2000 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." 17. Expiration Date This memo is filed as , and expires June 1, 2001. Aboba Informational [Page 18]