Internet DRAFT - draft-beadles-aaa-referral
draft-beadles-aaa-referral
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 22:45:47 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 25 Jun 1999 16:24:16 GMT
ETag: "2e6bcc-43b4-3773ad30"
Accept-Ranges: bytes
Content-Length: 17332
Connection: close
Content-Type: text/plain
Network Working Group M. Beadles
INTERNET-DRAFT UUNET Technologies
Category: Standards Track
<draft-beadles-aaa-referral-00.txt>
24 June 1999
AAA Referral
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing 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 mate-
rial 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.
The distribution of this draft is unlimited. It is filed as
<draft-beadles-aaa-referral-00.txt> and expires December 24, 1999.
Please send comments to the author.
2. Copyright Statement
Copyright (C) The Internet Society 1999. All Rights Reserved.
3. Abstract
This document describes a mechanism whereby, in response to a AAA
request, a AAA server may refer a client to another server, which will
then directly handle requests from that client. This is in contrast
to a proxy mechanism, where one AAA server acts as an intermediary,
communicating with another AAA server on behalf of the AAA client. An
implementation of this mechanism for Dial Access AAA is presented
using the RADIUS protocol.
Beadles Category: Informational [Page 1]
INTERNET-DRAFT AAA Referral 24 June 1999
4. 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 [KEYWORDS].
5. Description of General Mechanism
This document describes a mechanism whereby, in response to a AAA
request, a AAA server may refer a client to another server, which will
then directly handle requests from that client. This is in contrast
to a proxy mechanism, where one AAA server acts as an intermediary,
communicating with another AAA server on behalf of the AAA client.
It is envisioned that this mechanism would be of general utility as a
means of directing AAA services from a home server to an external
server. However, this document concentrates on using AAA referral for
dial access, keyed off of dialed number identification. One scenario
for using this mechanism is described as follows.
A user dials an Internet Service Provider Point of Presence (ISP POP),
which results in a telephony signal (ring) being sent to a modem
attached to the ISP's Network Access Server (NAS). On receipt of the
ring signal, but before going off hook, the NAS makes a request to its
home AAA server, identifying the dialed number where the ring is
arriving. The AAA server examines its database and determines to
which AAA server further requests for this session should be directed.
It returns the address of this server, called the Referred Server, to
the NAS. The NAS then answers the ring and begins PPP negotiation as
normal. During the authentication phase of PPP, when AAA requests are
originated by that NAS, they are directed not to the first AAA server,
but to the Referred Server, which acts as if it were the home server
for all AAA services.
This relationship between the NAS and the Referred Server is dynamic
and short-lived, is tied to a single user session context, and ends
when the user session ends. Concurrent or future user sessions
through that NAS will have their own AAA server relationships, possi-
bly including AAA Referral. Referral for Accounting may occur sepa-
rately from referral for Authentication/Authorization.
The Referred Server information may also include attributes directing
the NAS to make future AAA reequests using a different AAA protocol
than the initial request. For example, the first (default) AAA
request could be made using the RADIUS protocol, but the home server
could direct the NAS to communicate with the Referred Server using
the TACACS+ protocol.
Motivations for this mechanism includes the desire to avoid AAA prox-
ies, the desire to enable multiple AAA protocols through a single dial
access network, and the desire to be able to upgrade a AAA
Beadles Category: Informational [Page 2]
INTERNET-DRAFT AAA Referral 24 June 1999
infrastructure incrementally.
6. Sample Implementation Using RADIUS
This mechanism can be implemented in RADIUS, using the attributes
defined below, in the following manner.
A user dials an ISP POP, which results in a ring being sent to a modem
attached to the ISP's NAS. On receipt of the ring signal, but before
going off hook, the NAS sends a RADIUS Access-Request to its home
RADIUS server. This Access Request contains the dialed number in the
RADIUS Called-Station-Id Attribute, but it does NOT contain any user
authentication attributes such as User-Name or User-Password. The
RADIUS server examines its database and determines to which RADIUS
server further requests for this session should be directed. It
returns the IP address of this server to the NAS using the Referred-
Server-Address Attribute defined below. The NAS then answers the ring
and begins PPP negotiation as normal. During the authentication phase
of PPP, when RADIUS Access-Requests are originated by that NAS, they
are directed not to the first RADIUS server, but to the designated
Referred Server.
7. RADIUS Attribute Definitions
7.1. Referred-Server-Address Attribute
Description
This Attribute contains the IP address of the Referred RADIUS
Server. It MAY be included in Access-Accept packets.
A summary of the Referred-Server-Address Attribute format is shown
below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
? for Referred-Server-Address
Length
6
Address
Beadles Category: Informational [Page 3]
INTERNET-DRAFT AAA Referral 24 June 1999
The Address field is four octets. This field MUST contain the
IP Address of the Referred RADIUS Server.
Discussion
To enable RADIUS Referral, the home RADIUS server MUST include at
least one Referred-Server-Address. In the absence of this
attribute, normal RADIUS packet flows would occur by default.
Multiple Referred-Server-Address attributes MAY be returned in
order to provide a fail-over mechanism. If the first Referred
Server is unavailable, the NAS can fail over to the next
Referred-Server-Address returned. Note that if failover is used,
failover times SHOULD be quick and the list of servers SHOULD be
short. Referral takes place after ring but before PPP negotation
begins, so there is limited time to perform Referral before a
user believes that a ring-no-answer has occured.
7.2. Referred-Acct-Server-Address Attribute
Description
This Attribute contains the IP address of the Referred RADIUS
Accounting Server. It MAY be included in Access-Accept packets.
A summary of the Referred-Acct-Server-Address Attribute format is
shown below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
? for Referred-Acct-Server-Address
Length
6
Address
The Address field is four octets. This field MUST contain the
IP Address of the Referred RADIUS Accounting Server.
Discussion
To enable RADIUS Accounting Referral, the home RADIUS server MUST
include at least one Referred-Acct-Server-Address. In the
absence of this attribute, normal RADIUS Accounting packet flows
would occur by default. Multiple Referred-Acct-Server-Address
attributes MAY be returned in order to provide a fail-over mecha-
nism. If the first Referred Server is unavailable, the NAS can
fail over to the next Referred-Acct-Server-Address returned.
Beadles Category: Informational [Page 4]
INTERNET-DRAFT AAA Referral 24 June 1999
Note that if failover is used, failover times SHOULD be quick and
the list of servers SHOULD be short. Referral takes place after
ring but before PPP negotation begins, so there is limited time
to perform Referral before a user believes that a ring-no-answer
has occured. RADIUS Accounting referral MAY take place sepa-
rately from RADIUS Referral for authentication.
7.3. Referred-Server-Protocol Attribute
Description
This Attribute indicates the AAA protocol used by the Referred
RADIUS Server. It MAY be included in Access-Accept packets.
A summary of the Referred-Server-Protocol Attribute format is
shown below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Protocol
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol(cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
? for Referred-Server-Protocol
Length
6
Address
The Protocol field is four octets. This field MUST contain the
Protocol used by the Referred RADIUS Server, as defined by the
following enumeration:
Code Protocol
------ --------
0 RADIUS (default)
1 TACACS+
2 Diameter
Discussion
This attribute is used when the Referred Server uses an AAA pro-
tocol other than RADIUS. It directs the RADIUS client to use a
different protocol for subsequent AAA conversations. Note that
use of this attribute assumes that the Home AAA Server must
"know" that the RADIUS Client is capable of supporting the speci-
fied protocol. If the RADIUS Client does not support the speci-
fied protocol, then the RADIUS Client MUST ignore the attribute
and continue with normal AAA processing. In the absence of a
Beadles Category: Informational [Page 5]
INTERNET-DRAFT AAA Referral 24 June 1999
Referred-Server-Protocol attribute, the protocol is assumed to be
the default value (RADIUS)
8. Table of Attributes
The following table provides a guide to which of the above
attributes may be found in which kinds of packets, and in what quan-
tity.
Request Accept Reject Challenge Acct-Request # Attribute
0 0+ 0 0 0 ? Referred-Server-Address
0 0+ 0 0 0 ? Referred-Acct-Server-Address
0 0+ 0 0 0 ? Referred-Server-Protocol
The following table defines the meaning of the above table entries.
0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY be present in packet.
0-1 Zero or one instance of this attribute MAY be present in packet.
9. IANA Considerations
IANA should allocate 3 numbers from the RADIUS attribute name space
for the attributes listed above.
IANA should create a new name space for Referred-Server-Protocol.
This name space should initially be populated with the values
described above. The size of this name space is four octets; since it
is unlikely that there will ever be this many different AAA protocols,
the name space is in no danger of exhaustion. IANA can assign numbers
from this name space directly. Following the policies outlined in
[IANA-CONSIDERATIONS], the criteria for allocation from the space is
"specification required". The requestor must document their use of
the Referred-Server-Protocol value in an RFC or other permanent refer-
ence. Review is not required, as there is little danger of the name
space becoming polluted.
10. References
[KEYWORDS] S. Bradner. "Key words for use in RFCs to Indicate
Requirement Levels." RFC 2119, Harvard University, March 1997.
[RADIUS] C. Rigney, et. al. "Remote Access Dial In User Service",
RFC 2138, Livingston, Merit, Daydreamer, April 1997.
[RADIUS-ACCT] C. Rigney. "RADIUS Accounting", RFC 2139, Livingston,
April 1997.
Beadles Category: Informational [Page 6]
INTERNET-DRAFT AAA Referral 24 June 1999
[IANA-CONSIDERATIONS] T. Narten, H. Alvestrand. "Guidelines for Writ-
ing an IANA Considerations Section in RFCs." BCP 26, RFC 2434, IBM,
Maxware, October 1998.
11. Author's Address
Mark Anthony Beadles
UUNET, an MCI WorldCom Company
5000 Britton Rd.
Hilliard, OH 43026
Phone: 614-723-1941
EMail: mbeadles@wcom.net
12. Full Copyright Statement
Copyright (C) The Internet Society (1999). 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 implmentation 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 docu-
ment itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other Inter-
net 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 permis-
sions 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 WAR-
RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
13. Expiration Date
This document is filed as <draft-ietf-beadles-aaa-referral-00.txt>,
and expires December 24, 1999.
Beadles Category: Informational [Page 7]
