draft-ietf-radext-status-server-01.txt   draft-ietf-radext-status-server-02.txt 
Network Working Group Alan DeKok Network Working Group Alan DeKok
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Category: Informational Category: Informational
<draft-ietf-radext-status-server-01.txt> <draft-ietf-radext-status-server-02.txt>
Expires: February 24, 2008 Expires: May 2, 2009
25 August 2008 2 November 2008
Use of Status-Server Packets in the Use of Status-Server Packets in the
Remote Authentication Dial In User Service (RADIUS) Protocol Remote Authentication Dial In User Service (RADIUS) Protocol
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 20, 2008. This Internet-Draft will expire on May 2, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
RFC 2865 defines a Status-Server code for use in RADIUS, but labels RFC 2865 defines a Status-Server code for use in RADIUS, but labels
it as "Experimental" without further discussion. This document it as "Experimental" without further discussion. This document
describes a practical use for the Status-Server packet code, which is describes a practical use for the Status-Server packet code, which is
skipping to change at page 2, line 17 skipping to change at page 2, line 17
1. Introduction ............................................. 3 1. Introduction ............................................. 3
1.1. Terminology ......................................... 3 1.1. Terminology ......................................... 3
1.2. Requirements Language ............................... 4 1.2. Requirements Language ............................... 4
2. Problem Statement ........................................ 5 2. Problem Statement ........................................ 5
2.1. Overloading Access-Request .......................... 5 2.1. Overloading Access-Request .......................... 5
2.1.1. Recommendation against Access-Request .......... 6 2.1.1. Recommendation against Access-Request .......... 6
2.2. Overloading Accounting-Request ...................... 6 2.2. Overloading Accounting-Request ...................... 6
2.2.1. Recommendation against Accounting-Request ...... 7 2.2.1. Recommendation against Accounting-Request ...... 7
2.3. Status-Server as a Solution ......................... 7 2.3. Status-Server as a Solution ......................... 7
2.3.1. Status-Server to the RADIUS Authentication port 7 2.3.1. Status-Server to the RADIUS Authentication port 7
2.3.2. Status-Server to the RADIUS Accounting port .... 8 2.3.2. ....................................................... 8
2.3.3. Status-Server to the RADIUS Change-of-Authorizat 8 2.3.3. Status-Server to the RADIUS Change-of-Authorizat 8
3. Packet Format ............................................ 8 3. Packet Format ............................................ 8
3.1. Consistent definition for Status-Server ............. 10 3.1. Consistent definition for Status-Server ............. 10
4. Implementation notes ..................................... 11 4. Implementation notes ..................................... 11
4.1. Client Requirements ................................. 12 4.1. Client Requirements ................................. 12
4.2. Server Requirements ................................. 13 4.2. Server Requirements ................................. 13
4.3. Change of Authorization and Status-Server ........... 15 4.3. Change of Authorization and Status-Server ........... 15
4.4. More Robust Fail-over with Status-Server ............ 16 4.4. More Robust Fail-over with Status-Server ............ 16
4.5. Proxy Server handling of Status-Server .............. 16 4.5. Proxy Server handling of Status-Server .............. 16
4.6. Realm Routing ....................................... 17 4.6. Realm Routing ....................................... 17
skipping to change at page 7, line 45 skipping to change at page 7, line 45
Request and Access-Accept, as shown below. Request and Access-Accept, as shown below.
NAS RADIUS server NAS RADIUS server
--- ------------- --- -------------
Status-Server/ Status-Server/
Message-Authenticator -> Message-Authenticator ->
<- Access-Accept/ <- Access-Accept/
Reply-Message Reply-Message
The Status-Server packet MUST contain a Message-Authenticator The Status-Server packet MUST contain a Message-Authenticator
attribute for security. The Access-Accept packet can optionally attribute for security. The response (if any) to a Status-Server
contain an informational Reply-Message attribute. A list of packet sent to an authentication port MUST be an Access-Accept
attributes permitted in each type of packet is given in the Table of packet. The list of attributes that are permitted in the Access-
attributes in Section 6, below. Accept packet is given in the Table of Attributes in Section 6,
below.
2.3.2. Status-Server to the RADIUS Accounting port 2.3.2.
Status-Server may be used instead of Accounting-Request to query the Status-Server may be used instead of Accounting-Request to query the
responsiveness of a server. In this use-case, the protocol exchange responsiveness of a server. In this use-case, the protocol exchange
between client and server is similar to the usual exchange of between client and server is similar to the usual exchange of
Accounting-Request and Accounting-Response, as shown below. Accounting-Request and Accounting-Response, as shown below.
NAS RADIUS server NAS RADIUS server
--- ------------- --- -------------
Status-Server/ Status-Server/
Message-Authenticator -> Message-Authenticator ->
<- Accounting-Response <- Accounting-Response
The Status-Server packet MUST contain a Message-Authenticator The Status-Server packet MUST contain a Message-Authenticator
attribute for security. The Accounting-Response packet is empty. A attribute for security. The response (if any) to a Status-Server
list of attributes permitted in each type of packet is given in the packet sent to an accounting port MUST be an Accounting-Response
Table of attributes in Section 6, below. packet. The list of attributes that are permitted in the Accounting-
Response packet is given in the Table of Attributes in Section 6,
below.
2.3.3. Status-Server to the RADIUS Change-of-Authorization port 2.3.3. Status-Server to the RADIUS Change-of-Authorization port
Status-Server may be pro-actively sent by a server to a NAS when the Status-Server may be pro-actively sent by a server to a NAS when the
server first boots. This use mirrors the Accounting-Request use of server first boots. This use mirrors the Accounting-Request use of
the Acct-Status-Type attribute with value "Accounting On". This the Acct-Status-Type attribute with value "Accounting On". This
packet can serve as an indication to the NAS that the server is packet can serve as an indication to the NAS that the server is
available for authentication and accounting requests. available for authentication and accounting requests.
In this use-case, the protocol exchange between client and server is In this use-case, the protocol exchange between client and server is
similar to the usual exchange of CoA-Request and CoA-ACK, as shown similar to the usual exchange of CoA-Request and CoA-ACK, as shown
below. below.
RADIUS Server NAS RADIUS Server NAS
------------- --- ------------- ---
Status-Server/ Status-Server/
Message-Authenticator -> Message-Authenticator ->
<- CoA-ACK <- CoA-ACK
The Status-Server packet MUST contain a Message-Authenticator The Status-Server packet MUST contain a Message-Authenticator
attribute for security. The CoA-ACK packet is empty. A list of attribute for security. The response (if any) to a Status-Server
attributes permitted in each type of packet is given in the Table of packet sent to a Change-of-Authorization port MUST be a CoA-ACK
attributes in Section 6, below. packet. The list of attributes that are permitted in the CoA-ACK
packet is given in the Table of Attributes in Section 6, below.
3. Packet Format 3. Packet Format
Status-Server packets re-use the RADIUS packet format, with the Status-Server packets re-use the RADIUS packet format, with the
fields and values for those fields as defined [RFC2865] Section 3. fields and values for those fields as defined [RFC2865] Section 3.
We do not include all of the text or diagrams of that section here, We do not include all of the text or diagrams of that section here,
but instead explain the differences required to implement Status- but instead explain the differences required to implement Status-
Server. Server.
The Authenticator field of Status-Server packets MUST be generated The Authenticator field of Status-Server packets MUST be generated
using the same method as that used for the Request Authenticator using the same method as that used for the Request Authenticator
field of Access-Request packets, as given below. field of Access-Request packets, as given below.
The role of the Identifier field is the same for Status-Server as for The role of the Identifier field is the same for Status-Server as for
other packets. However, as Status-Server is taking the role of other packets. However, as Status-Server is taking the role of
 End of changes. 8 change blocks. 
16 lines changed or deleted 21 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/