Re: Request for Review: Status Server Document

[Alan DeKok <aland@deployingradius.com>]

David B. Nelson wrote:
> That makes review of this document in RADEXT a little bit challenging.
> We can, of course, polish the prose and make sure that the descriptions
> are self-consistent and clear and that the organization is logical.  I
> guess only those who have access to the "historical implementation" can
> discern whether the descriptions are accurate and correct.

  See ftp://ftp.cistron.nl/pub/radius.  Open Source == full access.

  Version 1.6.5 has the first public implementation of Status-Server.
CVS indicates that the change was January 21, by Miquel Van Smoorenburg.
 FreeRADIUS added support for Status-Server on Oct 17, 2002, "stolen
shamelessly from Cistron", according to the commit message.

  I believe that Radiator also added it around the same time.  I don't
know which was first, because I don't have access to the Radiator CVS tree.

  The intent of the document is most definitely *not* to document
historical implementations... and leave it at that.  The original
implementation in Cistron did NOT validate Status-Server packets, so
they could be trivially forged.

  As a result, the document is rather longer than I had originally
intended.  I expected that simply documenting the practice would be 3-4
pages, at most.  Upon writing it, there were a number of loose ends that
had to be cleared up, such as security.  Hence the additional text.

> The IESG, and the IETF at large, hold the WG, in general, and the WG
> Chairs and/or Document Shepherd, in particular, accountable to assert
> that the submitted draft meets certain protocol quality standards.  Now,
> I suppose that the quality of protocols is somewhat subjective.
> Nonetheless, its uncomfortable to be held accountable for the quality of
> a design that you are not able to affect in any way.

  I expect the WG to complain loudly if there are any problems.  This
seems to be historical practice in RADEXT. :)

  Much of the text in the document discusses security issues around the
use of Status-Server, and recommended practices.  I expect full review
of both the security implications and recommended practices.

  The document is partly about historical implementations.  But if those
implementations are wrong, the standard should reflect that, and should
standardize the correct behavior.  e.g. It recommends adding
Message-Authenticator to Status-Server, which Cistron did not enforce in
2001, and which FreeRADIUS did not enforce until a few years ago.

> I think that we need to be clear in publishing this draft and an RFC
> that the *protocol* it documents was *not* the work product of the
> RADEXT WG, but rather of various historic implementors.  Truth in
> advertising.  There are some hints at that already.  I'll propose some
> more explicit text as a formal RADEXT Issue.

  Thanks.  The choice of (some) contents, response packet codes, and use
of Status-Server as a "ping" are historical.  Much of the rest of the
document is discussion surrounding the topic.

>>   RADIUS has traditionally used separate status codes for requests and
>> replies.  Using the same code for both is about as bad (IMHO) as
>> overloading Access-Accept.
> 
> I think you're probably right.  Sigh.

  I'll add some test to the document to this effect.  "Overloading
Access-Accept is horrible.  RADIUS would normally use something like
Ping-Check and Ping-Ack, but implementations exist..."

  And the charter prevents us from creating more RADIUS codes, so it
would have been problematic to create Ping-Check and Ping-Ack now.
Overloading Access-Accept seems to make the best of a bad situation.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>