draft-ietf-radext-status-server-07.txt   draft-ietf-radext-status-server-08.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-07.txt> Updates: 2866
Expires: November 27, 2010 <draft-ietf-radext-status-server-08.txt>
26 April 2010 Expires: November 4, 2010
4 May 2010
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
draft-ietf-radext-status-server-07 draft-ietf-radext-status-server-08
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 36
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 November 27, 2010. This Internet-Draft will expire on November 4, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info/) in effect on the date of (http://trustee.ietf.org/license-info/) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 22 skipping to change at page 3, line 22
2.1. Why Access-Request is inappropriate ................. 7 2.1. Why Access-Request is inappropriate ................. 7
2.1.1. Recommendation against Access-Request .......... 8 2.1.1. Recommendation against Access-Request .......... 8
2.2. Why Accounting-Request is inappropriate ............. 8 2.2. Why Accounting-Request is inappropriate ............. 8
2.2.1. Recommendation against Accounting-Request ...... 8 2.2.1. Recommendation against Accounting-Request ...... 8
3. Packet Format ............................................ 9 3. Packet Format ............................................ 9
3.1. Single definition for Status-Server ................. 11 3.1. Single definition for Status-Server ................. 11
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. Fail-over with Status-Server ........................ 15 4.3. Fail-over with Status-Server ........................ 15
4.4. Proxy Server handling of Status-Server .............. 16 4.4. Proxy Server handling of Status-Server .............. 15
4.5. Limitations of Status-Server ........................ 16 4.5. Limitations of Status-Server ........................ 16
4.6. Management Information Base (MIB) Considerations .... 18 4.6. Management Information Base (MIB) Considerations .... 18
4.6.1. Interaction with RADIUS Server MIB modules ..... 18 4.6.1. Interaction with RADIUS Server MIB modules ..... 18
4.6.2. Interaction with RADIUS Client MIB modules ..... 19 4.6.2. Interaction with RADIUS Client MIB modules ..... 18
5. Table of Attributes ...................................... 19 5. Table of Attributes ...................................... 19
6. Examples ................................................. 20 6. Examples ................................................. 19
6.1. Minimal Query to Authentication Port ................ 20 6.1. Minimal Query to Authentication Port ................ 20
6.2. Minimal Query to Accounting Port .................... 21 6.2. Minimal Query to Accounting Port .................... 20
6.3. Verbose Query and Response .......................... 21 6.3. Verbose Query and Response .......................... 21
7. IANA Considerations ...................................... 22 7. IANA Considerations ...................................... 22
8. Security Considerations .................................. 22 8. Security Considerations .................................. 22
9. References ............................................... 23 9. References ............................................... 23
9.1. Normative references ................................ 23 9.1. Normative references ................................ 23
9.2. Informative references .............................. 24 9.2. Informative references .............................. 24
1. Introduction 1. Introduction
This document specifies a deployed extension to the Remote This document specifies a deployed extension to the Remote
skipping to change at page 6, line 8 skipping to change at page 6, line 8
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. The key words "MUST", "MUST NOT", "REQUIRED", of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in and "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
2. Overview 2. Overview
Status-Server packets are sent by a RADIUS client to a RADIUS server Status-Server packets are sent by a RADIUS client to a RADIUS server
in order to test the status of that server. A Message-Authenticator in order to test the status of that server. The destination of a
attribute MUST be included so as to provide per-packet authentication Status-Server packet is set to the IP address and port of the server
and integrity protection. A single Status-Server packet MUST be that is being tested. A single Status-Server packet MUST be included
included within a UDP datagram. RADIUS proxies MUST NOT forward within a UDP datagram. A Message-Authenticator attribute MUST be
Status-Server packets. included so as to provide per-packet authentication and integrity
protection.
Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy RADIUS proxies or servers MUST NOT forward Status-Server packets. A
or server, the destination of a Status-Server packet is set to the IP RADIUS server or proxy implementing this specification SHOULD respond
address of the server which is being tested. As a result, the client to a Status-Server packet with an Access-Accept (authentication port)
is provided with an indication of the status of that server only, or Accounting-Response (accounting port). An Access-Challenge
since no RADIUS proxies are on the path between the RADIUS client and response is NOT RECOMMENDED. An Access-Reject response MAY be used.
server. Since servers respond to a Status-Server packet without The list of attributes that are permitted in Status-Server and
examining the User-Name attribute, the response to a Status-Server Access-Accept packets responding to Status-Server packets are
packet cannot be used to infer any information about the reachability provided in the Section 6.
of specific realms.
A RADIUS server or proxy implementing this specification SHOULD Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy
respond to a Status-Server packet with an Access-Accept or server, the client is provided with an indication of the status of
(authentication port) or Accounting-Message (accounting port). An that server only, since no RADIUS proxies are on the path between the
Access-Challenge response is NOT RECOMMENDED. An Access-Reject RADIUS client and server. As servers respond to a Status-Server
response MAY be used. The list of attributes that are permitted in packet without examining the User-Name attribute, the response to a
Status-Server and Access-Accept packets responding to Status-Server Status-Server packet cannot be used to infer any information about
packets are provided in the Section 6. the reachability of specific realms.
The "hop by hop" functionality of Status-Server packets is useful to The "hop by hop" functionality of Status-Server packets is useful to
RADIUS clients attempting to determine the status of the first RADIUS clients attempting to determine the status of the first
element on the path between the client and a server. Since the element on the path between the client and a server. Since the
Status-Server packet is non-forwardable, lack of a response may only Status-Server packet is non-forwardable, lack of a response may only
be due to packet loss or the failure of the server in the destination be due to packet loss or the failure of the server in the destination
IP address, not due to faults in downstream links, proxies or IP address, not due to faults in downstream links, proxies or
servers. It therefore provides an unambiguous indication of the servers. It therefore provides an unambiguous indication of the
status of a server. status of a server.
skipping to change at page 12, line 22 skipping to change at page 12, line 22
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 use a watchdog timer such as defined in [RFC3539]
used when sending periodic Status-Server queries during server fail- to determine when to send Status-Server packets.
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
received within the timeout period, the Status-Server packet is
deemed to have received no corresponding Response packet, and MUST be
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
skipping to change at page 15, line 31 skipping to change at page 15, line 23
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. Fail-over with Status-Server 4.3. Fail-over with Status-Server
A client may wish to failover from one proxy to another in the event A client may wish to failover from one proxy to another in the event
that it does not receive a response to an Access-Request or that it does not receive a response to an Access-Request or
Accounting-Request. In order to determine whether the lack of Accounting-Request. In order to determine whether the lack of
response is due to a problem with the proxy or a downstream server, response is due to a problem with the proxy or a downstream server,
the client can send periodic Status-Server packets to a proxy after the client can send periodic Status-Server packets to a proxy after
lack of a response. The inter-packet period is Tw, as described in lack of a response.
Section 4.1.
These packets will help the client determine if the failure was due These packets will help the client determine if the failure was due
to an issue on the path between the client and proxy or the proxy to an issue on the path between the client and proxy or the proxy
itself, or whether the issue is occurring downstream. itself, or whether the issue is occurring downstream.
If no response is received to Status-Server packets, the RADIUS If no response is received to Status-Server packets, the RADIUS
client can initiate failover to another proxy. By continuing to send client can initiate failover to another proxy. By continuing to send
Status-Server packets to the original proxy at an interval of Tw, the Status-Server packets to the original proxy, the RADIUS client can
RADIUS client can determine when the original proxy becomes determine when it becomes responsive again.
responsive again.
Once three time periods have passed where Status-Server packets have Once the server has been deemed responsive, normal RADIUS requests
been sent and responded to, the server should be deemed responsive may sent to it again. This determination should be made separately
and RADIUS requests may sent to it again. This determination should for each server that the client has a relationship with. The same
be made separately for each server that the client has a relationship algorithm SHOULD be used for both authentication and accounting
with. The same algorithm should be used for both authentication and ports. The client MUST treat each destination (IP, port) combination
accounting ports. The client MUST treat each destination (IP, port) as a unique server for the purposes of this determination.
combination as a unique server for the purposes of this
determination.
The above behavior is modeled after [RFC3539] Section 3.4.1. We note Clients SHOULD use a watchdog timer mechanism similar to that given
that if a reliable transport is used for RADIUS, then the algorithms in [RFC3539] Section 3.4.1. If a reliable transport is used for
specified in [RFC3539] MUST be used in preference to the ones given RADIUS, then the algorithms specified in [RFC3539] MUST be used.
here.
4.4. Proxy Server handling of Status-Server 4.4. 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 another RADIUS server. Such servers MUST NOT proxy requests to another RADIUS server. Such servers MUST NOT proxy
Status-Server packets. The purpose of Status-Server as specified Status-Server packets. The purpose of Status-Server as specified
here is to permit the client to query the responsiveness of a server here is to permit the client to query the responsiveness of a server
that it has a direct relationship with. Proxying Status-Server that it has a direct relationship with. Proxying Status-Server
queries would negate any usefulness that may be gained by queries would negate any usefulness that may be gained by
implementing support for them. implementing support for them.
skipping to change at page 23, line 36 skipping to change at page 23, line 25
vulnerable to the attacks outlined above. For this reason, vulnerable to the attacks outlined above. For this reason,
implementations of this specification which fail to require use of implementations of this specification which fail to require use of
the Message-Authenticator attribute are NOT RECOMMENDED. the Message-Authenticator attribute are NOT RECOMMENDED.
Where this document differs from [RFC2865] is that it defines a new Where this document differs from [RFC2865] is that it defines a new
request/response method in RADIUS; the Status-Server request. As request/response method in RADIUS; the Status-Server request. As
this use is based on previously described and implemented standards, this use is based on previously described and implemented standards,
we know of no additional security considerations that arise from the we know of no additional security considerations that arise from the
use of Status-Server as defined herein. use of Status-Server as defined herein.
Attacks on cryptographic hashes are well known [RFC4270], and getting
better with time. RADIUS uses the MD5 hash [RFC1321] for packet
authentication and attribute obfuscation. There are ongoing efforts
in the IETF to analyze and address these issues for the RADIUS
protocol.
9. References 9. References
9.1. Normative references 9.1. Normative references
[RFC1321] [RFC1321]
Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, April, Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, April,
1992 1992
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997. Requirement Levels", RFC 2119, March, 1997.
skipping to change at page 24, line 19 skipping to change at page 24, line 16
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3539] Aboba, B., Wood, J., "Authentication, Authorization, and [RFC3539] Aboba, B., Wood, J., "Authentication, Authorization, and
Accounting (AAA) Transport Profile", RFC 3539, June 2003. Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[RFC3579] Aboba, B., Calhoun, P., "RADIUS (Remote Authentication Dial In [RFC3579] Aboba, B., Calhoun, P., "RADIUS (Remote Authentication Dial In
User Service) Support For Extensible Authentication Protocol User Service) Support For Extensible Authentication Protocol
(EAP)", RFC 3579, September 2003. (EAP)", RFC 3579, September 2003.
[RFC4270] Hoffman, P, and Schneier, B, "Attacks on Cryptographic Hashes
in Internet Protocols", RFC 4270, November 2005.
[RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC [RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC
4668, August 2006. 4668, August 2006.
[RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC
4669, August 2006. 4669, August 2006.
[RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670, [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670,
August 2006. August 2006.
[RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671, [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671,
 End of changes. 17 change blocks. 
57 lines changed or deleted 54 lines changed or added

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