Subject: Request for Review: Status Server Document

From: Bernard Aboba <[email-masked]>
Date: Mon, 2 Jun 2008 19:35:04 -0700

This is a request for review of the Status Server document for the purposes of considering it for adoption as a RADEXT WG work item.  The document is available for inspection here:http://www.ietf.org/internet-drafts/draft-dekok-radius-status-server-02.txt Please respond to the mailing list, indicating whether your are IN FAVOR or AGAINST adoption of the document as a RADEXT WG work item.  If you have comments on the document, please post these to the mailing list as well, in the format described in the RADEXT WG Issues page: http://www.drizzle.com/~aboba/RADEXT/ This request for review will conclude on June 16, 2008.

---

From: Stefan Winter <[email-masked]>
Date: Tue, 10 Jun 2008 07:29:20 +0200

Hi,

|     This is a request for review of the Status Server document for the
|     purposes of considering it for adoption as a RADEXT WG work item.

I'm in favour of adoption.

Stefan Winter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 13 Jun 2008 17:44:19 -0400

I have a "big picture" question to ask before I delve into further levels of
detailed review and questions.

Why is the Server-Status "query" packet responded to by an Access-Accept
"reply" packet?  It seems to me that were over-loading the semantics of
Access-Accept by using it in this way.  Maybe that's not particularly
harmful -- I don't know for sure -- but over-loading always seems like a Bad
Idea (tm) to me.

Wouldn't it have been possible to use the same Command Code (Server-Status)
for *both* the query and response, with the context coming from who's doing
the receiving?  I think that would be preferable, in a number of ways.

I did see the not-so-subtle hint that this document is describing *existing*
implementations, much as we did in the original RADIUS WG.  The inference I
draw is that redesign (i.e. helpful suggestions for alternate choices, such
as the one my question raises) is not solicited or welcomed.  Of course,
maybe I'm simply reading too much into that wording. 

Anyway, why couldn't Server-Status be the RADIUS Command Code used for both
queries and replies?

Regards,

Dave Nelson

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 13 Jun 2008 15:30:01 -0700

>implementations, much as we did in the original RADIUS WG.  

The goal of the Status-Server specification is to document an existing 
protocol, much as RFC 5176 documented an existing protocol for dynamic
authorization.  

That said, if there are improvements that can be made within the protocol
while maintaining backward compatibility, then they should be considered.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 14 Jun 2008 10:26:59 +0200

> harmful -- I don't know for sure -- but over-loading always seems like a Bad

  Yes it's not ideal.  It's a historical practice.

> the receiving?  I think that would be preferable, in a number of ways.

  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.

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Sat, 14 Jun 2008 09:56:40 -0400

Alan DeKok writes...

>   Yes it's not ideal.  It's a historical practice.

Yes, so Bernard has explained.

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.

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.

Bernard raises the example of RFC 5176, which was a "bis" revision of 
RFC 3576.  The former was not the product of any working group, AFAICT, 
and was not labeled as such when it was published.  The RADIUS WG had 
closed and the RADEXT WG had not yet been conceived.  I'm not sure 
that's an appropriate analogy.

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.

> overloading Access-Accept.

I think you're probably right.  Sigh.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 14 Jun 2008 17:30:42 +0200

> 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.

> 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.

> 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.

> 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.

---

From: "David B. Nelson" <[email-masked]>
Date: Sat, 14 Jun 2008 11:50:06 -0400

Alan DeKok wrote:

>   I'll add some text to the document to this effect.  "Overloading

That would help to put the base protocol around Server-Status into 
historical perspective.

>   And the charter prevents us from creating more RADIUS codes...

Not anymore!  :-)  Here are the only restrictions in the *revised* charter:

In order to enable interoperation of heterogeneous RADIUS/Diameter
deployments, all RADEXT WG work items MUST contain a Diameter
compatibility section, outlining how interoperability with
Diameter will be maintained.

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
the following restrictions are imposed on extensions considered by the
RADEXT WG:

- All documents produced MUST specify means of interoperation with
legacy RADIUS and, if possible, be backward
compatible with existing RADIUS RFCs, including RFCs 2865-2869,
3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090 and 5176.
Transport profiles should, if possible, be compatible with RFC 3539.

- All RADIUS work MUST be compatible with equivalent facilities in
Diameter. Where possible, new attributes should be defined so that
the same attribute can be used in both RADIUS and Diameter without
translation. In other cases a translation considerations
section should be included in the specification.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 14 Jun 2008 19:24:07 +0200

> Not anymore!  :-)  Here are the only restrictions in the *revised* charter:

  Temptation...

  Adding Ping-Check and Ping-Ack would be nice in theory.  But given
existing implementations, I'm not sure there's any benefit in doing so.

  Alan DeKok.

---

From: Mike McCauley <[email-masked]>
Date: Sun, 15 Jun 2008 09:05:43 +1000

> know which was first, because I don't have access to the Radiator CVS tree.

Radiator had support for Status-Server from version 1.9 on 20/1/98.

-- 
Mike McCauley                               [email-masked]
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP, TNC, WiMAX etc on Unix, Windows, MacOS, NetWare etc.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 15 Jun 2008 14:38:34 +0700

> existing implementations, I'm not sure there's any benefit in doing so.

Existing implementations or not, RADIUS "ping" is just as wasteful of
processing power & bandwidth as it was 10 years ago.  A far better idea IMHO
is to have the server tell its clients when it recovers from a failure/admin
reboot/etc.

...

---

From: Alan DeKok <[email-masked]>
Date: Sun, 15 Jun 2008 09:47:11 +0200

Glen Zorn wrote:
> processing power & bandwidth as it was 10 years ago.

  It's not a "keep-alive".  That's bad.  It is the watchdog timer
recommended in RFC 3539.  The draft discusses why using existing RADIUS
codes such as Access-Request is not a good idea.  It also discusses why
it's useful, and why it's not a "keep-alive".

>  A far better idea IMHO

  I agree, mostly.  Some complications:

- clients don't historically listen on a port for unsolicited RADIUS
packets (RFC 5176 is not widely deployed)

- clients may be behind NATs or firewalls.   The forward path is well
tested, deployed, with firewall traversal rules.  The backwards path is not.

- this would involve defining a new port (maybe), new packet codes
(could we re-use Status-Server?), and new behavior.  The existing
practice has multiple implementations, is widely used, and meets most of
the needs for client to server status checking.

  Alan DeKok.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 15 Jun 2008 11:28:36 +0200

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Saturday, June 14, 2008 6:31 PM
> To: David B. Nelson
> Cc: [email-masked]
> Subject: Re: Request for Review: Status Server Document
> 
> David B. Nelson wrote:
> > 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.
> 
>  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.
> 
> > 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.
> 
>   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 
>   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.
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 15 Jun 2008 21:39:19 +0200

> (actually more than OK - required) to put text that makes this

  The only part of the Status-Server behavior that does not go back to
2001 is the suggestion that it contain a Message-Authenticator
attribute.  That requirement was added to FreeRADIUS in Feb 2007, before
the RADEXT WG discussion on re-chartering.

  This appears to fall with the "documenting current practices" guidelines.

  Alan DeKok.

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 15 Jun 2008 18:06:28 -0700

Alan DeKok said:

"  The only part of the Status-Server behavior that does not go back to
2001 is the suggestion that it contain a Message-Authenticator
attribute.  That requirement was added to FreeRADIUS in Feb 2007, before
the RADEXT WG discussion on re-chartering."

Wasn't Status-Server first implemented by Ascend Communications in the
mid-1990s?

---

From: Alan DeKok <[email-masked]>
Date: Mon, 16 Jun 2008 07:08:36 +0200

> Wasn't Status-Server first implemented by Ascend Communications in the

  It's certainly possible.  I don't recall, and I don't have access to a
source tree to check.

  Alan DeKok.