Subject: Re: REMINDER: RADEXT WG Last Call on Status Server document (part 1)

From: Bernard Aboba <[email-masked]>
Date: Sun, 9 Aug 2009 21:42:52 -0700

Here is my review. 

Abstract
   RFC 2865 defines a Status-Server code for use in RADIUS, but labels
   it as "Experimental" without further discussion.  This document
   describes a practical use for the Status-Server packet code, which is
   to let clients query the status of a RADIUS server.  These queries,
   and responses (if any) enable the client to make more informed
   decisions.  The result is a more stable, and more robust RADIUS
   architecture.

How about something more along the lines of the RFC 5176 abstract?  

   This document describes a deployed extension to the Remote
   Authentication Dial In User Service (RADIUS) protocol, enabling
   clients to query the status of a RADIUS server.  This extension
   utilizes the Status-Server (12) Code, which was reserved for
   experimental use in RFC 2865. 

Section 1

   The RADIUS Working Group was formed in 1995 to document the protocol
   of the same name, and created a number of standards surrounding the
   protocol.  It also defined experimental commands within the protocol,
   without elaborating further on the potential uses of those commands.
   One of the commands so defined was Status-Server ([RFC2865] Section
   3.).

   This document describes how some current implementations are using
   Status-Server packets as a method for querying the status of a RADIUS
   server.  These queries do not otherwise affect the normal operation
   of a server, and do not result in any side effects other than perhaps
   incrementing an internal packet counter.

   These queries are not intended to implement the application-layer
   watchdog messages described in [RFC3539] Section 3.4.  That document
   describes Authentication, Authorization, and Accounting (AAA)
   protocols that run over reliable transports which handle
   retransmissions internally.  Since RADIUS runs over the User Datagram
   Protocol (UDP) rather than Transport Control Protocol (TCP), the full
   watchdog mechanism is not applicable here.

Not sure the history is necessarily correct (e.g. I believe that the RADIUS Working Group was formed earlier).
In any case, it is probably best to focus on the purpose of this document.  How about this? 

   This document specifies a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling
   clients to query the status of a RADIUS server.   While the Status-Server Code (12) was defined as experimental in [RFC2865] 
   Section 3, details of the operation and potential uses of the Code were not provided. 

   As with the core RADIUS protocol, the Status-Server extension is stateless, and queries do not
   otherwise affect the normal operation of a server, nor do they result in any side effects, other
   than perhaps incrementing of an internal packet counter.  Most of the implementations of
   this extension have utilized it alongside implementations of RADIUS as defined in [RFC2865],
   so that this document focuses solely on the use of this extension with UDP transport. 

Network Access Server (NAS)
     The device providing access to the network.  Also known as the
     Authenticator (in IEEE 802.1x terminology) or RADIUS client.

"x" -> "X"

Proxy Server
     A RADIUS server that acts as a Home Server to the NAS, but in turn
     proxies the request to another Proxy Server, or to a Home Server.

I am not sure that the use of the term "Home Server" here adds clarity.  The definition of proxy from
RFC 2607 might be more applicable:

   RADIUS proxy
      In order to provide for the routing of RADIUS authentication and
      accounting requests, a RADIUS proxy can be employed. To the NAS,
      the RADIUS proxy appears to act as a RADIUS server, and to the
      RADIUS server, the proxy appears to act as a RADIUS client.

1.1 Applicability

I think this document needs an applicability section, to explain potential differences between
this specification and existing implementations, as well as why it is being published as Informational,
as opposed to Experimental or Standards Track.  Suggest the following:

1.1.  Applicability

   This protocol is being recommended for publication as an
   Informational RFC rather than as a standards-track RFC because of
   problems that cannot be fixed without creating incompatibilities with
   deployed implementations.  This includes security vulnerabilities.  
   While fixes are recommended, they cannot be made mandatory since 
   this would be incompatible with existing implementations.

   Existing implementations of this protocol do not support the
   Message-Authenticator attribute.  This enables spoofing of
   Status-Server packets.  In order to remedy this problem, 
   this specification recommends the use of the Message-Authenticator
   attribute to provide per-packet authentication and integrity
   protection. 

   With existing implementations of this protocol, the potential
   exists for Status-Server requests to be in conflict with Access-Request
   or Accounting-Requests packets using the same Identifier.  This
   specification recommends techniques to avoid this problem. 

   [Add information on other issues here]

2.  Problem Statement

   It is often useful to know if a RADIUS server is alive and responding
   to requests.  The most accurate way to obtain this information is to
   query the server via application protocol traffic, as other methods
   are either less accurate, or cannot be performed remotely.

   The reasons for wanting to know the status of a server are many.  The
   administrator may simply be curious if the server is responding, and
   may not have access to NAS or traffic data that would give him that
   information.  The queries may also be performed automatically by a
   NAS or proxy server, which is configured to send packets to a RADIUS
   server, and where that server may not be responding.  That is, while
   [RFC2865] Section 2.6 indicates that sending Keep-Alives is harmful,
   it may be useful to send "Are you Alive" queries to a server once it
   has been marked "dead" due to prior unresponsiveness.

   The occasional query to a "dead" server offers little additional load
   on the network or server, and permits clients to more quickly
   discover when the server returns to a responsive state.  Overall,
   status queries can be a useful part of the deployment of a RADIUS
   server.

RFC 2865 Section 2.6 strongly discourages the use of keep-alives.  
>From reading this section, I am unclear whether the intent is to refute the
arguments made there, or to articulate how the uses of Status-Server
defined here go beyond those of the "test RADIUS request" described 
in RFC 2865. 

For example, unlike a RADIUS Access-Request, the Status-Server packet 
cannot be forwarded, and therefore the lack of a response can only be
due either to packet loss or to a problem with the server to whom the 
packet is sent.  In contrast, an Access-Request might not be answered 
because of a problem somewhere along the chain between the sender and 
the RADIUS server.  This difference allows the Status-Server packet to
be used as a diagnostic tool in ways that an Access-Request could not
be. 

Overall, I wonder whether some of the introductory material in Section 4.3
might be removed from that section and instead be revised and presented 
in this section.  For example:

   A common problem in RADIUS client implementations is the
   implementation of a robust fail-over mechanism between proxies.  A
   client may have multiple proxies configured, with one proxy marked
   as primary and another marked as secondary.  If the client does
   not receive a response to a request sent to the primary proxy, 
   it can "fail over" to the secondary, and send requests to the
   secondary instead of to the primary proxy. 

   However, it is possible that the lack of a response to requests
   sent to the primary proxy was due not to a failure within the
   the primary, but to alternative causes such as a failed link 
   along the path to the destination server, or the failure of
   a downstream proxy or server.  In such a situation, it may
   be useful for the client to be able to distinguish between
   failure causes.  For example, if the primary proxy is down,
   then quick failover to the secondary proxy would be prudent,
   whereas if a downstream failure is the cause, then the value
   of failing over to a secondary proxy will depend on whether
   packets forwarded by the secondary will utilize independent links, 
   intermediaries or destination servers.  

   Since the 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 IP address, not due to faults
   in downstream links, proxies or servers.  It therefore 
   provides an unambiguous indication of the status of a 
   proxy or server. 

Sections 2.1-2.2

I find these sections puzzling, because they suggest alternatives to the Status-Server packet
that do not serve the same function.  Given that Status-Server packets are not forwardable, 
they serve a different purpose than the "test RADIUS requests" which RFC 2865 recommends
against.  Given this, talking about "alternatives" in these sections is somewhat confusing. 
What might make more sense is to describe the function that Status-Server packets provide
and why this is not provided by alternatives such as the RADIUS Access-Request packet. 

Section 2.3

   Since the
   packet is otherwise undefined, it does not cause interoperability
   issues to create implementation-specific definitions for it.  The
   difficulty until now has been defining an interoperable method of
   performing these queries.
 
While the Status-Server packet format was not defined in RFC 2865, it was implemented by Ascend and
other vendors.  As far as I know, a number of deployments did use NAS and RADIUS servers from different
vendors so that "implementation-specific definitions" would indeed have resulted in interoperability 
problems.  

In any case, as I understand it, the goal of this work item is to document existing implementations of 
the Status-Server extension, correct?  

Section 2.3.1

   Status-Server SHOULD be used instead of Access-Request to query the
   responsiveness of a server.  In this use case, the protocol exchange
   between client and server is similar to the usual exchange of Access-
   Request and Access-Accept, as shown below.

           NAS                          RADIUS server
           ---                          -------------
           Status-Server/
            Message-Authenticator ->
                                     <- Access-Accept/
                                         Reply-Message

   The Status-Server packet MUST contain a Message-Authenticator
   attribute for security.  The response (if any) to a Status-Server
   packet sent to an authentication port SHOULD be an Access-Accept
   packet.  Other response packet codes are NOT RECOMMENDED.  The list
   of attributes that are permitted in the Access-Accept packet is given
   in the Table of Attributes in Section 6, below.

Given that the Status-Server packet is not forwardable, this section is a bit
confusing.  Also, I'm not clear how useful the diagram is. 
I'd suggest focusing on the basics of the exchange:

Status-Server Exchange

   Status-Server packets are typically sent to the destination address and port 
   of a RADIUS server or proxy.  A Message-Authenticator attribute SHOULD be
   included so as to provide per-packet authentication and integrity protection. 
   A single Status-Server packet MUST be included within a UDP datagram.  RADIUS 
   proxies MUST NOT forward Status-Server packets.  

   A RADIUS server or proxy implementing this specification SHOULD 
   respond to a Status-Server packet with an Access-Accept.  Other response packet
   codes (such as Access-Challenge or Access-Reject) are NOT RECOMMENDED.  The
   list of attributes that are permitted in Status-Server and Access-Accept
   packets responding to Status-Server packets are provided in the Section 6. 
 
BTW, I'm curious as to whether a Status-Server packet can be sent to the address
and port (3799) of a DAS, and if so, what the appropriate response is.  

Section 2.3.2

   The Status-Server packet MUST contain a Message-Authenticator
   attribute for security.  

Given that implementations exist that did not support Message-Authenticator, my suggestion is that this
become a SHOULD. 

Section 3

   This method
   MUST be used to avoid conflicts between Status-Server and other
   packet types.

Given that implementations exist that did not support this, my suggestion is that this
become a SHOULD as well. 

   In addition to the above requirements, all Status-Server packets MUST
   include a Message-Authenticator attribute.  Failure to do so would
   mean that the packets could be trivially spoofed.

Suggest MUST -> SHOULD here. 

=============================
This is a reminder of an ongoing RADEXT WG last call on the Status Server
specification, prior to sending this document on to the IESG for
publication as an Informational RFC.  The document is available for
inspection here:
http://tools.ietf.org/html/draft-ietf-radext-status-server

RADEXT
WG last call will last until August 7, 2009.  Please send comments to
the RADEXT WG mailing list using the format described in the RADEXT
Issues list (http://www.drizzle.com/~aboba/RADEXT/).