Subject: Issue with Guidelines document

From: Alan DeKok <[email-masked]>
Date: Sat, 13 Dec 2008 10:16:53 +0100

This might be a little late, but it may be worth adding one more note:

---
    Accounting-Response packets SHOULD contain only Proxy-State.

  State changes in the RADIUS client based on Accounting-Response
packets are NOT RECOMMENDED.  They do not fit within the traditional
RADIUS operational model.  Despite the text in [RFC2866] Section 5.13
saying that "possibly" Vendor-Specific is permitted, such use is NOT
RECOMMENDED.
---

  Is it too late for this?  Do we have Area Director agreement that this
is a good idea?

  The background is a growing number of NAS equipment that I'm seeing
which *does* look for attributes in an Accounting-Response.  It's not
clear what the NAS does with those attributes, but internal state
changes are a logical conclusion.

  Alan DeKok.

--
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: Bernard Aboba <[email-masked]>
Date: Sun, 14 Dec 2008 07:32:45 -0800

In gerneral, the purpose of the Design Guidelines document is to provide
guidelines compatible with existing RADIUS RFCs.  As a result, RADIUS
operational model issues discussed in Section 3.3 contain citations
to existing RFCs. 
 
In this particular case, while RFC 2866 indicates that there are no
required attributes in an Accounting-Response, it doesn't prohibit
them.  So is the issue the inclusion of attributes, or is it the use
of those attributes?
 
>From Section 4.2:
 
4.2.  Accounting-Response   Description      Accounting-Response packets are sent by the RADIUS accounting      server to the client to acknowledge that the Accounting-Request      has been received and recorded successfully.  If the Accounting-      Request was recorded successfully then the RADIUS accounting      server MUST transmit a packet with the Code field set to 5      (Accounting-Response).  On reception of an Accounting-Response by      the client, the Identifier field is matched with a pending      Accounting-Request.  The Response Authenticator field MUST contain      the correct response for the pending Accounting-Request.  Invalid      packets are silently discarded.      A RADIUS Accounting-Response is not required to have any      attributes in it.   A summary of the Accounting-Response packet format is shown below.   The fields are transmitted from left to right.    0                   1                   2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |     Code      |  Identifier   |            Length             |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                                                               |   |                     Response Authenticator                    |   |                                                               |   |                                                               |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |  Attributes ...   +-+-+-+-+-+-+-+-+-+-+-+-+-   Code      5 for Accounting-Response.   Identifier      The Identifier field is a copy of the Identifier field of the      Accounting-Request which caused this Accounting-Response.   Response Authenticator      The Response Authenticator of an Accounting-Response contains a      16-octet MD5 hash value calculated according to the method      described in "Response Authenticator" above.   Attributes      The Attributes field is variable in length, and contains a list of      zero or more Attributes.

 EMAILING FOR THE GREATER GOODJoin me> Date: Sat, 13 Dec 2008 10:16:53 +0100> From: [email-masked]> To: [email-masked]> Subject: Issue with Guidelines document> > This might be a little late, but it may be worth adding one more note:> > ---> Accounting-Response packets SHOULD contain only Proxy-State.> > State changes in the RADIUS client based on Accounting-Response> packets are NOT RECOMMENDED. They do not fit within the traditional> RADIUS operational model. Despite the text in [RFC2866] Section 5.13> saying that "possibly" Vendor-Specific is permitted, such use is NOT> RECOMMENDED.> ---> > > Is it too late for this? Do we have Area Director agreement that this> is a good idea?> > The background is a growing number of NAS equipment that I'm seeing> which *does* look for attributes in an Accounting-Response. It's not> clear what the NAS does with those attributes, but internal state> changes are a logical conclusion.> > Alan DeKok.> > --> 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: Alan DeKok <[email-masked]>
Date: Sun, 14 Dec 2008 18:53:30 +0100

Bernard Aboba wrote:
> them.

  Hmm...

5.13.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in Accounting-Request packets.  No attributes should be found in
   Accounting-Response packets except Proxy-State and possibly Vendor-
   Specific.

  That seems pretty clear.  Nothing but Proxy-State && VSA's.

>  So is the issue the inclusion of attributes, or is it the use
> of those attributes?

  I would like to know what it *means* to have VSA's in an
Accounting-Response.  What does the NAS do with them?  Log them?  Ignore
them?  Change it's behavior?

  I'm seeing people who insist that they have to put attributes in an
Accounting-Response.  Sometimes they claim their NAS requires it.  But I
can't get an explanation as to *why*.

  Alan DeKok.

---

From: "Greg Weber" <[email-masked]>
Date: Sun, 14 Dec 2008 14:09:03 -0500

> them?  Change it's behavior?

This can be used to communicate server load or pending planned downtime
information back to the NAS which then can be used in server selection
algorithms.  I believe there's a commercial server in the PacketCable space
doing this (for voice gateway RADIUS clients).  Also have heard some
discussion about a server being able to dynamically adjust the interim
accounting
record interval by setting a VSA in the accounting response (mimicking a
Diameter feature), but I'm not sure if that's implemented by any servers.

But it sounds like you're talking about static attribute values below.
Anyway, I don't think we should try to prohibit VSAs in accounting responses.

Greg

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 14 Dec 2008 13:55:42 -0800

> That seems pretty clear.  Nothing but Proxy-State && VSA's.

Yes.   VSAs are allowed  Presumably this would also include

Extended Attributes? 

> accounting record interval by setting a VSA in the accounting response (mimicking a

Since this document is a BCP, not an update to RFC 2866, it can quote from
existing RFCs, but shouldn't modify them. 

So it's ok to add an item to Section 3.3 about not including standard RADIUS
attributes beyond Proxy-State in Accounting-Responses, using a quote
from RFC 2866 Section 5.13 for justification.  Since RFC 2866 allows VSAs,
I don't think they can or should be prohibited in this document. 

It also probably makes sense to log an issue against the Extended Attributes
document for clarification on whether they can be included in Accounting-Responses.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 15 Dec 2008 08:39:45 +0100

Greg Weber wrote:
> algorithms.

  That sounds like a bit of a hack to me.  "Yes I've stored the
accounting data for bob, and by the way, I'm rebooting in 5 minutes".

>  I believe there's a commercial server in the PacketCable space

  I would suggest that CoA might be a better choice for that.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 15 Dec 2008 11:21:59 +0100

> Yes.   VSAs are allowed  Presumably this would also include 

  Likely, yes.

> I don't think they can or should be prohibited in this document.

  Maybe make them NOT RECOMMENDED?

  Ongoing discussion indicates that people are using them to implement
CoA behavior.  i.e. changes to billing, bandwidth, etc.  Because "doing
CoA is too hard".

  Also, making changes to user sessions as a result of VSA's in an
Accounting-Response should be NOT RECOMMENDED.  Implementors SHOULD use
CoA instead.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 15 Dec 2008 18:40:12 +0700

> accounting data for bob, and by the way, I'm rebooting in 5 minutes".

Perhaps you could suggest a better way to accomplish this?  Maybe it's
really not needed: much more efficient to just wait till the server goes
away then retry a few times.

>   I would suggest that CoA might be a better choice for that.

Excellent suggestion: it's not like the semantics of the CoA exchange bind
it to a specific session, while the Accounting-Response is a generic
accounting-related ACK.  

...

---

From: Alan DeKok <[email-masked]>
Date: Mon, 15 Dec 2008 14:20:24 +0100

> away then retry a few times.

  I have no good suggestions here.  Traditionally, yes, the server just
"goes away".

  I'm not even aware of *which* NASes support this behavior.  This
behavior is new to me, and I've been doing this for well over a decade.

> it to a specific session, while the Accounting-Response is a generic

 ... which is sent in response to an Accounting-Request for a particular
user session.

  Just like CoA.

  If the NAS vendors need this functionality, CoA seems to be a better
fit than Accounting-Response.  Few RADIUS servers have traditionally
implemented CoA, so I understand why using Accounting-Response is tempting.

  Now that we have the potential for Status-Server, it is much safer for
the RADIUS server to just "go away".

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 15 Dec 2008 08:00:27 -0800

> away then retry a few times.

I don't think there is a better way to accomplish this in RADIUS at this point. 

SIP, Diameter and HTTP all have a "redirect" error message.  RADIUS does
not.  This means that the RADIUS accounting server either stores the 
accounting packet and returns an Accounting-Response, or it drops the 
packet, and then has to deal with a retry. 

Given this, about the best that can be done is for the server to process the
Accounting-Request and then send whatever load shedding info it has in
a VSA.  

If the NAS doesn't understand the VSA, then it will ignore it, and
things will be no worse off than had the server not sent the VSA at all. 

> it to a specific session, while the Accounting-Response is a generic

TheCoA-Request also requires the NAS (and Dynamic Authorization Client)
to implement RFC 5176.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 15 Dec 2008 13:33:18 -0500

Bernard Aboba writes...

> > The following table provides a guide to which attributes may be 
> > found in Accounting-Request packets. No attributes should be found
> > in Accounting-Response packets except Proxy-State and possibly
> > Vendor-Specific.
> >
> Yes.   VSAs are allowed.  Presumably this would also include
> Extended Attributes? 

Uh...  No.  Extended Attributes leverage the VSA _format_ for extensibility
reasons but they are not [inherently] vendor specific.  VSA traditionally
implied "proprietary secret sauce" that other vendors could safely ignore.
That is certainly not the case with Extended Attributes, which could be
Standards Track.

If this is a common misunderstanding -- i.e. the traditional usage rules for
VSAs apply to Extended Attributes -- we should indeed clear up that
confusion immediately.  Perhaps in the Extended Attributes draft itself.

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 15 Dec 2008 14:33:26 -0800

David Nelson said:

"If this is a common misunderstanding -- i.e. the traditional usage rules
for
VSAs apply to Extended Attributes -- we should indeed clear up that
confusion immediately.  Perhaps in the Extended Attributes draft itself."

It would be good for the Extended Attributes draft to clear this up
(I've filed on issue on this).  However, a number of existing
Documents (including RFC 2866 and RFC 5176) make statements about
the allowable uses of Attribute 26.  Since Extended Attribute
use Attribute 26, those statements will by default apply.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 15 Dec 2008 17:47:19 -0500

Bernard Aboba writes...

> use Attribute 26, those statements will by default apply.

Well... yes.  That's a logical inference.  I wonder, however, if it's the
inference that we desire.  I think if we fail to separate the restrictions
of the "classic" VSA from the intended use model of the Extended Attributes,
we will have failed in some significant way.  Yes, the Extended Attributes
"overload" the use of the VSA type code, but IMHO they are not VSAs, as we
know them.  Another way of saying this is that all the current references to
type code 26 and/or VSA in the RFCs are in the context of "classic" VSAs,
i.e. "proprietary secret sauce" attributes.

Is it possible to make a meaningful and logical distinction between Extended
Attribute and Vendor Specific Attribute?  If not, I think that the utility
of Extended Attributes will be substantially lessened.

---

From: "Greg Weber" <[email-masked]>
Date: Tue, 16 Dec 2008 02:46:04 -0500

> accounting data for bob, and by the way, I'm rebooting in 5 minutes".

I think this was used with the client's own accounting session id,
not a user's (bob's) session id.  In other words, when the client booted
or was configured for accounting, it sent an Accounting-Request with
Acct-Status-Type = Accounting-On and Acct-Session-Id = "I am foo client".
Then it sent periodic Accounting-Requests (Acct-Status-Type=Interim-Update)
using the same Acct-Session-Id.  The server could send responses to
these interims with the load or potentially planned downtime schedule info.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 16 Dec 2008 10:35:18 +0100

David B. Nelson wrote:
> Attribute and Vendor Specific Attribute? 

  Yes.  I suggest that the Extended attributes draft (and maybe even the
guidelines document) contain text that says "Extended attributes with
Vendor-Id of zero (0) are not to be interpreted as VSA's within the
meaning of the other drafts".

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Dec 2008 09:11:30 -0800

> meaning of the other drafts".

You might be able to make that recommendation with respect to implementations
that understand Extended Attributes (e.g. implementations of the Extended
Attribute specification). But how can we say that with respect to existing 
implementations?  This implies that legacy implementations will treat
Extended Attributes like VSAs (e.g. ignore them if they don't understand
them).

---

From: Alan DeKok <[email-masked]>
Date: Wed, 17 Dec 2008 15:26:09 +0100

> Extended Attributes like VSAs (e.g. ignore them if they don't understand

  I think that's what will happen.

  We can't change the behavior of legacy implementations.  We just have
to be careful about how we use the extended attributes.

  Alan DeKok.