draft-ietf-radext-status-server-00.txt   draft-ietf-radext-status-server-01.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-00.txt> <draft-ietf-radext-status-server-01.txt>
Expires: December 17, 2008 Expires: February 24, 2008
25 August 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
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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. Status-Server to the RADIUS Accounting port .... 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 ..................................... 10 4. Implementation notes ..................................... 11
4.1. Client Requirements ................................. 11 4.1. Client Requirements ................................. 12
4.2. Server Requirements ................................. 13 4.2. Server Requirements ................................. 13
4.3. More Robust Fail-over with Status-Server ............ 14 4.3. Change of Authorization and Status-Server ........... 15
4.4. Proxy Server handling of Status-Server .............. 15 4.4. More Robust Fail-over with Status-Server ............ 16
4.5. Realm Routing ....................................... 15 4.5. Proxy Server handling of Status-Server .............. 16
4.6. Management Information Base (MIB) Considerations .... 17 4.6. Realm Routing ....................................... 17
4.6.1. Interaction with RADIUS Server MIBs ............ 17 4.7. Management Information Base (MIB) Considerations .... 19
4.6.2. Interaction with RADIUS Client MIBs ............ 18 4.7.1. Interaction with RADIUS Server MIBs ............ 19
5. Additional considerations ................................ 18 4.7.2. Interaction with RADIUS Client MIBs ............ 19
5.1. Local site testing .................................. 18 5. Additional considerations ................................ 20
5.2. RADIUS over reliable transports ..................... 19 5.1. Local site testing .................................. 20
5.3. Other uses for Status-Server ........................ 20 5.2. RADIUS over reliable transports ..................... 21
5.4. Potential Uses for Status-Client .................... 20 5.3. Other uses for Status-Server ........................ 22
6. Table of Attributes ...................................... 20 6. Table of Attributes ...................................... 22
7. Examples ................................................. 21 7. Examples ................................................. 22
7.1. Minimal Query to Authentication Port ................ 21 7.1. Minimal Query to Authentication Port ................ 23
7.2. Minimal Query to Accounting Port .................... 22 7.2. Minimal Query to Accounting Port .................... 23
7.3. Verbose Query and Response .......................... 23 7.3. Verbose Query and Response .......................... 24
8. IANA Considerations ...................................... 23 8. IANA Considerations ...................................... 25
9. Security Considerations .................................. 24 9. Security Considerations .................................. 25
10. References .............................................. 24 10. References .............................................. 25
10.1. Normative references ............................... 24 10.1. Normative references ............................... 26
10.2. Informative references ............................. 24 10.2. Informative references ............................. 26
Intellectual Property Statement .............................. 25 Intellectual Property Statement .............................. 27
Disclaimer of Validity ....................................... 27 Disclaimer of Validity ....................................... 28
Full Copyright Statement ..................................... 27 Full Copyright Statement ..................................... 28
1. Introduction 1. Introduction
The RADIUS Working Group was formed in 1995 to document the protocol The RADIUS Working Group was formed in 1995 to document the protocol
of the same name, and created a number of standards surrounding the of the same name, and created a number of standards surrounding the
protocol. It also defined experimental commands within the protocol, protocol. It also defined experimental commands within the protocol,
without elaborating further on the potential uses of those commands. without elaborating further on the potential uses of those commands.
One of the commands so defined was Status-Server ([RFC2865] Section One of the commands so defined was Status-Server ([RFC2865] Section
3.). 3.).
skipping to change at page 8, line 23 skipping to change at page 8, line 23
--- ------------- --- -------------
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 Accounting-Response packet is empty. A
list of attributes permitted in each type of packet is given in the list of attributes permitted in each type of packet is given in the
Table of attributes in Section 6, below. Table of attributes in Section 6, below.
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
server first boots. This use mirrors the Accounting-Request use of
the Acct-Status-Type attribute with value "Accounting On". This
packet can serve as an indication to the NAS that the server is
available for authentication and accounting requests.
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
below.
RADIUS Server NAS
------------- ---
Status-Server/
Message-Authenticator ->
<- CoA-ACK
The Status-Server packet MUST contain a Message-Authenticator
attribute for security. The CoA-ACK packet is empty. A list of
attributes permitted in each type of 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
skipping to change at page 10, line 28 skipping to change at page 10, line 50
accounting, there is little reason to include other attributes in accounting, there is little reason to include other attributes in
either the query or the corresponding response. either the query or the corresponding response.
Examples of Status-Server packet flows are given below in Section 7. Examples of Status-Server packet flows are given below in Section 7.
3.1. Consistent definition for Status-Server 3.1. Consistent definition for Status-Server
When sent to a RADIUS accounting port, contents of the Status-Server When sent to a RADIUS accounting port, contents of the Status-Server
packets are calculated as described above. That is, even though the packets are calculated as described above. That is, even though the
packets are being sent to an accounting port, they are not created packets are being sent to an accounting port, they are not created
using the same method as Accounting-Request packets. This difference using the same method as for Accounting-Requests. This difference
from the handling of Accounting-Request packets has a number of has a number of benefits.
benefits.
Having one definition for Status-Server packets is simpler than Having one definition for Status-Server packets is simpler than
having different definitions for different destination ports. In having different definitions for different destination ports. In
addition, if we were to define Status-Server as being similar to addition, if we were to define Status-Server as being similar to
Accounting-Request, but containing no attributes, then the packets Accounting-Request or CoA-Request, but containing no attributes, then
could be trivially forged. those packets could be trivially forged.
We therefore define Status-Server consistently, and vary the response We therefore define Status-Server consistently, and vary the response
packets depending on the port to which the request is sent. When packets depending on the port to which the request is sent. When
sent to an authentication port, the response to a Status-Server query sent to an authentication port, the response to a Status-Server query
is an Access-Accept packet. When sent to an accounting port, the is an Access-Accept packet. When sent to an accounting port, the
response to a Status-Server query is an Accounting-Response packet. response to a Status-Server query is an Accounting-Response packet.
When sent to a change of authorization (CoA) port, the response to a
Status-Server query is an CoA-ACK packet
4. Implementation notes 4. Implementation notes
There are a number of considerations to take into account when There are a number of considerations to take into account when
implementing support for Status-Server. This section describes implementing support for Status-Server. This section describes
implementation details and requirements for RADIUS clients and implementation details and requirements for RADIUS clients and
servers that support Status-Server. servers that support Status-Server.
The following text applies to both authentication and accounting The following text applies to the authentication, accounting, and coa
ports. We use the generic terms below to simplify the discussion: ports. We use the generic terms below to simplify the discussion:
* Request packet * Request packet
An Access-Request packet sent to an authentication port, or An Access-Request packet sent to an authentication port, or
an Accounting-Request packet sent to an accounting port. an Accounting-Request packet sent to an accounting port, or
a Change-Of-Authorization packet sent to a CoA port.
* Response packet * Response packet
An Access-Accept, Access-Challenge, or Access-Reject packet sent An Access-Accept, Access-Challenge, or Access-Reject packet sent
from an authentication port, or an Accounting-Response packet from an authentication port, or an Accounting-Response packet
sent from an accounting port. sent from an accounting port, or a CoA-ACK packet sent from a
CoA port.
We also refer to "client" as the originator of the Status-Server
packet, and "server" as the receiver of that packet, and the
originator of the Response packet.
Using generic terms to describe the Status-Server conversations is Using generic terms to describe the Status-Server conversations is
simpler than duplicating the text for both authentication and simpler than duplicating the text for authentication, accounting, and
accounting ports. coa packets.
4.1. Client Requirements 4.1. Client Requirements
Clients SHOULD permit administrators to globally enable or disable Clients SHOULD permit administrators to globally enable or disable
the generation of Status-Server packets. The default SHOULD be that the generation of Status-Server packets. The default SHOULD be that
it is disabled. As it is undesirable to send queries to servers that it is disabled. As it is undesirable to send queries to servers that
do not support Status-Server, clients SHOULD also have a per-server do not support Status-Server, clients SHOULD also have a per-server
configuration indicating whether or not to enable Status-Server for a configuration indicating whether or not to enable Status-Server for a
particular destination. The default SHOULD be that it is disabled. particular destination. The default SHOULD be that it is disabled.
The client SHOULD also have a configurable global timer (Tw) that is The client SHOULD also have a configurable global timer (Tw) that is
used when sending periodic Status-Server queries during server fail- used when sending periodic Status-Server queries during server fail-
over. The default value SHOULD be 30 seconds, and the value MUST NOT over. The default value SHOULD be 30 seconds, and the value MUST NOT
be permitted to be set below 6 seconds. If a response has not been be permitted to be set below 6 seconds. If a response has not been
received within the timeout period, the Status-Server packet is received within the timeout period, the Status-Server packet is
deemed to have received no corresponding Response packet, and MUST be deemed to have received no corresponding Response packet, and MUST be
discarded. discarded.
Clients SHOULD use a jitter of +/- 2 seconds when sending periodic
Status-Server packets, in order to avoid synchronization.
When Status-Server packets are sent from a client, they MUST NOT be When Status-Server packets are sent from a client, they MUST NOT be
retransmitted. Instead, the Identity field MUST be changed every retransmitted. Instead, the Identity field MUST be changed every
time a packet is transmitted. The old packet should be discarded, time a packet is transmitted. The old packet should be discarded,
and a new Status-Server packet should be generated and sent, with new and a new Status-Server packet should be generated and sent, with new
Identity and Authenticator fields. Identity and Authenticator fields.
Clients MUST include the Message-Authenticator attribute in all Clients MUST include the Message-Authenticator attribute in all
Status-Server packets. Failure to do so would mean that the packets Status-Server packets. Failure to do so would mean that the packets
could be trivially spoofed, leading to potential denial of service could be trivially spoofed, leading to potential denial of service
(DoS) attacks. Other attributes SHOULD NOT appear in a Status-Server (DoS) attacks. Other attributes SHOULD NOT appear in a Status-Server
packet, except as outlined below in Section 6. As the intent of the packet, except as outlined below in Section 6. As the intent of the
packet is a simple status query, there is little reason for any packet is a simple status query, there is little reason for any
additional attributes to appear in Status-Server packets. additional attributes to appear in Status-Server packets.
The client MAY increment packet counters as a result of sending a The client MAY increment packet counters as a result of sending a
Status-Server request, or receiving a Response packet. The client Status-Server request, or receiving a Response packet. The client
MUST NOT perform any other action that is normally performed when it MUST NOT perform any other action that is normally performed when it
receives a Response packet, such as permitting a user to have login receives a Response packet, such as permitting a user to have login
access to a port. access to a port.
When a client sends Status-Server packets, those requests SHOULD NOT Clients MAY send Status-Server requests to the RADIUS destination
be sent from a source port that is used to send Access-Request or ports from the same source port used to send normal Request packets.
Accounting-Request packets. Clients MAY send Status-Server requests Other clients MAY choose to send Status-Server requests from a unique
to both authentication and accounting destination ports from the same source port, that is not used to send Request packets.
source port.
The above suggestion for a unique source port for Status-Server The above suggestion for a unique source port for Status-Server
packets aids in matching responses to requests. Since the response packets aids in matching responses to requests. Since the response
to a Status-Server packet is an Access-Accept or Accounting-Response to a Status-Server packet is an Access-Accept, Accounting-Response,
packet, those responses are indistinguishable from other packets sent or CoA-ACK packet, those responses are indistinguishable from other
in response to an Access-Request or Accounting-Request. Therefore, packets sent in response to a Request packet. Therefore, the best
the best way to distinguish them from other traffic is to have a way to distinguish them from other traffic is to have a unique port.
unique port.
A client MAY send a Status-Server packet from a source port also used A client MAY send a Status-Server packet from a source port also used
to send Access-Request or Accounting-Request packets. In that case, to send Request packets. In that case, the Identifer field MUST be
the Identifer field MUST be unique across all outstanding requests unique across all outstanding Request packets for that source port,
for that source port, independent of the value of the RADIUS Code independent of the value of the RADIUS Code field for those
field for those outstanding requests. Once the client has either outstanding requests. Once the client has either received a response
received a response to the Status-Server packet, or has determined to the Status-Server packet, or has determined that the Status-Server
that the Status-Server packet has timed out, it may re-use that packet has timed out, it may re-use that Identifier in another
Identifier in another packet. packet.
When the client receives a response to a Status-Server query, the Robust implementations SHOULD accept any Response packet as a valid
response may be either an Access-Accept packet or an Accounting- response to a Status-Server packet, subject to the validation
Response packet, depending both on the behavior of the server, and requirements defined above for the Response Authenticator. The code
the port to which the query was sent. It may be difficult for the field of the packet matters less than the fact that a valid, signed,
client to know which Response packet to expect. Therefore, a client response has been received.
SHOULD accept either packet code as an acceptable response to a
Status-Server query, subject to the validation requirements defined
above for the Response Authenticator.
That is, prior to accepting the response as valid, the client should That is, prior to accepting the response as valid, the client should
check that the Response packet Code field is either Access-Accept (2) check that the Response packet Code field is either Access-Accept
or Accounting-Response (5). If the code does not match one of those (2), Accounting-Response (5), or CoA-ACK (44). If the code does not
two values, the packet MUST be silently discarded. The client MUST match any of these values, the packet MUST be silently discarded.
then validate the Response Authenticator via the algorithm given The client MUST then validate the Response Authenticator via the
above in Section 3. If the Response Authenticator is not valid, the algorithm given above in Section 3. If the Response Authenticator is
packet MUST be silently discarded. If the Response Authenticator is not valid, the packet MUST be silently discarded. If the Response
valid, then the packet MUST be deemed to be a valid response from the Authenticator is valid, then the packet MUST be deemed to be a valid
server. response from the server.
If the client instead discarded the response because the packet code If the client instead discarded the response because the packet code
did not match what it expected, then it could erroneously discard did not match what it expected, then it could erroneously discard
valid responses from a server, and mark that server as unresponsive. valid responses from a server, and mark that server as unresponsive.
This behavior would affect the stability of a RADIUS network, as This behavior would affect the stability of a RADIUS network, as
responsive servers would erroneously be marked as unresponsive. We responsive servers would erroneously be marked as unresponsive. We
therefore recommend that clients should be liberal in what they therefore recommend that clients should be liberal in what they
accept as responses to Status-Server queries. accept as responses to Status-Server queries.
4.2. Server Requirements 4.2. Server Requirements
skipping to change at page 14, line 13 skipping to change at page 14, line 44
The server MAY prioritize the handling Status-Server queries over the The server MAY prioritize the handling Status-Server queries over the
handling of other requests, subject to the rate limiting described handling of other requests, subject to the rate limiting described
above. above.
The server MAY decide to not respond to a Status-Server, depending on The server MAY decide to not respond to a Status-Server, depending on
local site policy. For example, a server that is running but is local site policy. For example, a server that is running but is
unable to perform it's normal activities MAY silently discard Status- unable to perform it's normal activities MAY silently discard Status-
Server packets. This situation can happen, for example, when a Server packets. This situation can happen, for example, when a
server requires access to a database for normal operation, but the server requires access to a database for normal operation, but the
connection to that database is down. Or, it may happen when the connection to that database is down. Or, it may happen when the
accept load on the server is lower than the offered load. accepted load on the server is lower than the offered load.
Some server implementations require that Access-Request packets are Some server implementations require that Access-Request packets are
accepted only on "authentication" ports, (e.g. 1812/udp), and that accepted only on "authentication" ports, (e.g. 1812/udp), and that
Accounting-Request packets are accepted only on "accounting" ports Accounting-Request packets are accepted only on "accounting" ports
(e.g. 1813/udp). Those implementations SHOULD reply to Status-Server (e.g. 1813/udp). Those implementations SHOULD reply to Status-Server
packets sent to an "authentication" port with an Access-Accept packets sent to an "authentication" port with an Access-Accept
packet. Those implementations SHOULD reply to Status-Server packets packet. Those implementations SHOULD reply to Status-Server packets
sent to an "accounting" port with an Accounting-Response packet. sent to an "accounting" port with an Accounting-Response packet.
Some server implementations accept both Access-Request and Some server implementations accept both Access-Request and
Accounting-Request packets on the same port, and do not distinguish Accounting-Request packets on the same port, and do not distinguish
between "authentication only" ports, and "accounting only" ports. between "authentication only" ports, and "accounting only" ports.
Those implementations SHOULD reply to Status-Server packets with an Those implementations SHOULD reply to Status-Server packets with an
Access-Accept packet. Access-Accept packet.
The server MAY increment packet counters as a result of receiving a The server MAY increment packet counters as a result of receiving a
Status-Server, or sending a Response packet. The server SHOULD NOT Status-Server, or sending a Response packet. The server SHOULD NOT
perform any other action that is normally performed when it receives perform any other action that is normally performed when it receives
a Request packet, other than sending a Response packet. a Request packet, other than sending a Response packet.
4.3. More Robust Fail-over with Status-Server 4.3. Change of Authorization and Status-Server
The use of Status-Server with respect to Change of Authorization
requires some additional discussion.
When a Dynamic Authorization Client ([RFC5176] Section 1.3) reboots,
it SHOULD send a Status-Server packet to a CoA port to IP addresses
that are configured as both Dynamic Authorization Servers and RADIUS
clients. Jitter SHOULD be used to avoid synchronization issues. If
there is no response to a packet, the periodic timer above SHOULD be
used to continue sending packets to that destination until a response
has been received. When a response is received, the Dynamic
Authorization Client MUST NOT send further Status-Server packets to
the CoA port of any Dynamic Authorization until it next reboots.
When a Dynamic Authorization Server receives a Status-Server packet
to it's CoA port, it SHOULD respond with a CoA-ACK packet, as
described above. It MAY use this information to modify it's
authentication and/or accounting behavior, as described below.
If the Status-Server packet came to a NAS CoA port from an IP address
which is also configured as an authentication and/or accounting
server. the NAS MAY decide to mark the RADIUS server as being
responsive. If the RADIUS server had previously been marked as
unresponsive, this change would enable the NAS to start packets to
start sending packets to that RADIUS server again. The NAS MAY
otherwise decide to receive multiple packets to it's CoA port before
marking the RADIUS server as responsive. This behavior is
implementation-defined, and SHOULD be configurable.
Where possible, the Dynamic Authorization Client (usually a RADIUS
server) SHOULD originate the Status-Server packet from the port to
which the NAS would normally send Request packets. For example, a
packet sent from from a RADIUS server with source port 1812 to a NAS
with destination port 3799, would indicate to the NAS that the RADIUS
authentication server at that address is alive.
4.4. More Robust Fail-over with Status-Server
A common problem in RADIUS client implementations is the A common problem in RADIUS client implementations is the
implementation of a robust fail-over mechanism between servers. A implementation of a robust fail-over mechanism between servers. A
client may have multiple servers configured, with one server marked client may have multiple servers configured, with one server marked
as primary and another marked as secondary. If the client determines as primary and another marked as secondary. If the client determines
that the primary is unresponsive, it can "fail over" to the that the primary is unresponsive, it can "fail over" to the
secondary, and send requests to the secondary instead of to the secondary, and send requests to the secondary instead of to the
primary. primary.
However, it is difficult in standard RADIUS for a client to know when However, it is difficult in standard RADIUS for a client to know when
skipping to change at page 15, line 18 skipping to change at page 16, line 38
Once three time periods have passed where Status-Server messages have Once three time periods have passed where Status-Server messages have
been sent and responded to, the server should be deemed responsive been sent and responded to, the server should be deemed responsive
and RADIUS requests may sent to it again. This determination should and RADIUS requests may sent to it again. This determination should
be made separately for each server that the client has a relationship be made separately for each server that the client has a relationship
with. The same algorithm should be used for both authentication and with. The same algorithm should be used for both authentication and
accounting ports. The client MUST treat each destination (ip, port) accounting ports. The client MUST treat each destination (ip, port)
combination as a unique server for the purposes of this combination as a unique server for the purposes of this
determination. determination.
The practice of sending Status-Server packets to CoA ports (where
applicable) can increase the information available in the network,
and further help to stabilize the network, and to lower response
times in the event of network changes.
The above behavior is modelled after [RFC3539] Section 3.4.1. We The above behavior is modelled after [RFC3539] Section 3.4.1. We
note that if a reliable transport is used for RADIUS, then the note that if a reliable transport is used for RADIUS, then the
algorithms specified in [RFC3539] MUST be used in preference to the algorithms specified in [RFC3539] MUST be used in preference to the
ones given here. ones given here.
4.4. Proxy Server handling of Status-Server 4.5. Proxy Server handling of Status-Server
Many RADIUS servers can act as proxy servers, and can forward Many RADIUS servers can act as proxy servers, and can forward
requests to home servers. Such servers MUST NOT proxy Status-Server requests to home servers. Such servers MUST NOT proxy Status-Server
packets. The purpose of Status-Server as specified here is to permit packets. The purpose of Status-Server as specified here is to permit
the client to query the responsiveness of a server that it has a the client to query the responsiveness of a server that it has a
direct relationship with. Proxying Status-Server queries would direct relationship with. Proxying Status-Server queries would
negate any usefulness that may be gained by implementing support for negate any usefulness that may be gained by implementing support for
them. them.
Proxy servers MAY be configured to respond to Status-Server queries Proxy servers MAY be configured to respond to Status-Server queries
from clients, and MAY act as clients sending Status-Server queries to from clients, and MAY act as clients sending Status-Server queries to
other servers. However, those activities MUST be independent of one other servers. However, those activities MUST be independent of one
another. another.
4.5. Realm Routing 4.6. Realm Routing
RADIUS servers are commonly used in an environment where Network RADIUS servers are commonly used in an environment where Network
Access Identifiers (NAIs) are used as routing identifiers [RFC4282]. Access Identifiers (NAIs) are used as routing identifiers [RFC4282].
In this practice, the User-Name attribute is decorated with realm In this practice, the User-Name attribute is decorated with realm
routing information, commonly in the format of "user@realm". Since a routing information, commonly in the format of "user@realm". Since a
particular RADIUS server may act as a proxy for more than one realm, particular RADIUS server may act as a proxy for more than one realm,
the mechanism outlined above may be inadequate. the mechanism outlined above may be inadequate.
The schematic below demonstrates this scenario. The schematic below demonstrates this scenario.
skipping to change at page 17, line 38 skipping to change at page 19, line 16
different places, (i.e. not both links from the NAS), then all different places, (i.e. not both links from the NAS), then all
requests from the NAS will still reach a home server. In many requests from the NAS will still reach a home server. In many
situations where three or more links are broken, then requests from situations where three or more links are broken, then requests from
the NAS may still reach a home server. the NAS may still reach a home server.
It is RECOMMENDED, therefore, that implementations desiring the most It is RECOMMENDED, therefore, that implementations desiring the most
benefit from Status-Server also implement server failover. The benefit from Status-Server also implement server failover. The
combination of these two practices will maximize network reliability combination of these two practices will maximize network reliability
and stability. and stability.
4.6. Management Information Base (MIB) Considerations 4.7. Management Information Base (MIB) Considerations
4.6.1. Interaction with RADIUS Server MIBs 4.7.1. Interaction with RADIUS Server MIBs
Since Status-Server packets are sent to the defined RADIUS ports, Since Status-Server packets are sent to the defined RADIUS ports,
they can affect the [RFC4669] and [RFC4671] RADIUS server MIBs. they can affect the [RFC4669] and [RFC4671] RADIUS server MIBs.
[RFC4669] defines a counter named radiusAuthServTotalUnknownTypes, [RFC4669] defines a counter named radiusAuthServTotalUnknownTypes,
that counts "The number of RADIUS packets of unknown type that were that counts "The number of RADIUS packets of unknown type that were
received". [RFC4671] defines a similar counter named received". [RFC4671] defines a similar counter named
radiusAcctServTotalUnknownTypes. Implementations not supporting radiusAcctServTotalUnknownTypes. Implementations not supporting
Status-Server, or implementations that are configured to not respond Status-Server, or implementations that are configured to not respond
to Status-Server packets MUST use these counters to track received to Status-Server packets MUST use these counters to track received
Status-Server packets. Status-Server packets.
skipping to change at page 18, line 20 skipping to change at page 19, line 45
be unaffected by the transmission or reception of packets relating to be unaffected by the transmission or reception of packets relating to
Status-Server. Status-Server.
If a server supports Status-Server and the [RFC4669] or [RFC4671] If a server supports Status-Server and the [RFC4669] or [RFC4671]
MIBs, then it SHOULD also support vendor-specific MIBs containing MIBs, then it SHOULD also support vendor-specific MIBs containing
similar information as the standard MIBs, but which are instead similar information as the standard MIBs, but which are instead
dedicated solely to tracking Status-Server requests and responses. dedicated solely to tracking Status-Server requests and responses.
Any definition of the server MIBs for Status-Server is outside of the Any definition of the server MIBs for Status-Server is outside of the
scope of this document. scope of this document.
4.6.2. Interaction with RADIUS Client MIBs 4.7.2. Interaction with RADIUS Client MIBs
Clients implementing Status-Server MUST NOT increment [RFC4668] or Clients implementing Status-Server MUST NOT increment [RFC4668] or
[RFC4670] counters upon reception of Response packets to Status- [RFC4670] counters upon reception of Response packets to Status-
Server queries. That is, when a server fully implements Status- Server queries. That is, when a server fully implements Status-
Server, the counters defined in [RFC4668] and [RFC4670] MUST be Server, the counters defined in [RFC4668] and [RFC4670] MUST be
unaffected by the transmission or reception of packets relating to unaffected by the transmission or reception of packets relating to
Status-Server. Status-Server.
If an implementation supports Status-Server and the [RFC4668] or If an implementation supports Status-Server and the [RFC4668] or
[RFC4670] MIBs, then it SHOULD also support vendor-specific MIBs [RFC4670] MIBs, then it SHOULD also support vendor-specific MIBs
skipping to change at page 20, line 33 skipping to change at page 22, line 14
5.3. Other uses for Status-Server 5.3. Other uses for Status-Server
While other uses of Status-Server are possible, uses beyond those While other uses of Status-Server are possible, uses beyond those
specified here are beyond the scope of this document. It may be specified here are beyond the scope of this document. It may be
tempting to increase the utility of Status-Server by having the tempting to increase the utility of Status-Server by having the
responses carry additional information, implementors are warned that responses carry additional information, implementors are warned that
such uses have not been analyzed for potential security issues or such uses have not been analyzed for potential security issues or
network problems. network problems.
5.4. Potential Uses for Status-Client Specifically, it may seem useful to leverage a combination of Status-
Server and CoA ports in order to send realm routing information
RADIUS currently defines an experimental Status-Client packet type, "upstream" from the home servers to the proxy servers, and finally to
in addition to Status-Server. It could be possible to define Status- the NAS. This use of Status-Server is NOT RECOMMENDED, as there has
Client similar to Status-Server, except that it would be applicable been insufficient analysis and deployment experience to know if it is
to Change of Authorization, and Disconnect-Request packets, currently useful, or even if it makes the network less reliable.
sent to a NAS on port 3799 [RFC5176].
We do no more than mention the possibility here. Any definition of
Status-Client is outside of the scope of this document.
6. Table of Attributes 6. Table of Attributes
The following table provide a guide to which attributes may be found The following table provide a guide to which attributes may be found
in Status-Server packets, and in what quantity. No attributes other in Status-Server packets, and in what quantity. No attributes other
than the ones listed below should be found in a Status-Server packet. than the ones listed below should be found in a Status-Server packet.
Status- Access- Accounting- Status- Access- Accounting- CoA-
Server Accept Response # Attribute Server Accept Response ACK # Attribute
0-1 0 0 4 NAS-IP-Address
0 0+ 0 18 Reply-Message 0-1 0 0 0 4 NAS-IP-Address
0+ 0+ 0+ 26 Vendor-Specific 0 0+ 0 0 18 Reply-Message
0+ 0+ 0 31 Calling-Station-Id 0+ 0+ 0+ 0 26 Vendor-Specific
0-1 0 0 32 NAS-Identifier 0+ 0+ 0 0 31 Calling-Station-Id
1 0-1 0-1 80 Message-Authenticator 0-1 0 0 0 32 NAS-Identifier
0-1 0 0 95 NAS-IPv6-Address 1 0-1 0-1 0-1 80 Message-Authenticator
0-1 0 0 0 95 NAS-IPv6-Address
The following table defines the meaning of the above table entries. The following table defines the meaning of the above table entries.
0 This attribute MUST NOT be present in packet. 0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY 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. 0-1 Zero or one instance of this attribute MAY be present in packet.
1 Exactly one instance of this attribute MUST be present in packet. 1 Exactly one instance of this attribute MUST be present in packet.
7. Examples 7. Examples
 End of changes. 28 change blocks. 
97 lines changed or deleted 167 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/