[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Request for Review: Status Server Document
Alan,
I have a different view.
This is what the charter says about this work item:
- Documentation of Status-Server usage. A document
describing usage of the Status-Server facility will be
developed.
My understanding from the discussions that preceded the rechartering
approval was that we are indeed documenting current practices based on
implementations and deployment without defining anything new. It's OK
(actually more than OK - required) to put text that makes this
crystal-clear.
If the working group believes that the implementations are wrong it
needs to say it clearly in this document. If the WG believes that there
need to be fixes in the protocol, it needs to recharter this work item.
Actually we can create new RADIUS codes according to the new charter,
but not for this work item.
Dan
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok
> Sent: Saturday, June 14, 2008 6:31 PM
> To: David B. Nelson
> Cc: radiusext@ops.ietf.org
> Subject: Re: Request for Review: Status Server Document
>
> 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/>
>
--
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/>