One document matched: draft-ietf-aaa-transport-00.txt
AAA Working Group Bernard Aboba
INTERNET-DRAFT Microsoft
Category: Informational
<draft-ietf-aaa-transport-00.txt>
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 <draft-ietf-aaa-transport-00.txt>, and expires
June 1, 2001.
Aboba Informational [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-21 19:50:25 |