Subject: [AAA-WG]: Issue 37: Home State Blob

From: Pat Calhoun <[email-masked]>
Date: Fri, 15 Jun 2001 07:20:15 -0700

All,

After a discussion yesterday, we were able to recover the original issue, and the
following is the issue submission. I'd like comments on the proposed text.

Thanks,

PatC
----

Issue 37: Home State Blob 
Submitter name: Pat Calhoun 
Submitter email address: [email-masked] 
Date first submitted: June 15 20001 
Reference: 
Document: Base 
Comment Type: Technical 
Priority: 2 
Section: new section 10.16 
Rationale/Explanation of issue: 
The RADIUS protocol defines the Class attribute, which allows for home 
servers to return some state information to the NAS. The Class attribute 
must be present in subsequent messages for the session. 

Requested change: 
Add following text in section 10: 
10.16 Class AVP 

The Class AVP (AVP Code 25) is of type OctetString and is used to by 
Diameter servers to return state information to the access device. 
When one or more Class AVPs are present in application-specific 
authorization answer messages, they MUST be present in subsequent 
re-authorization and accounting messages. Class AVPs found in a re- 
authorization answer message override the ones found in any previous 
authorization answer message.

---

From: Barney Wolff <[email-masked]>
Date: Fri, 15 Jun 2001 14:12:29 -0400

Would it not be reasonable to apply some limit on the total size
of Class attributes?  With 24-bit lengths, the client otherwise
has to be prepared to store megabytes of state.

Barney

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 15 Jun 2001 11:20:05 -0700

> has to be prepared to store megabytes of state.

well it would probably make sense to limit the size. Could we
restrict it to the max size of a RADIUS attribute? That would make
gateway functions much simpler, but would limit the Diameter protocol.

Any other ideas of the max length?

Thanks,

PatC

---

From: Barney Wolff <[email-masked]>
Date: Fri, 15 Jun 2001 15:10:39 -0400

Even RADIUS allows multiple Class attributes, but is saved by the
4096-byte PDU limit.  I'd be happy with 1024 as the total Class
limit and would accept 512.  Anything much more leads one to have
to specify what the client MUST do if it cannot store the state.
I've never actually tried to stess a NAS with lots of Class to
see if I can crash it.
Barney

---

From: Paul Funk <[email-masked]>
Date: Fri, 15 Jun 2001 23:11:10 -0400

I'd vote not to specify a maximum length. Maybe just a warning to 
be economical with the amount of Class information you burden 
the NAS with.

A NAS implementation can define its own behavior if it doesn't have 
the memory to store the Class information; maybe it just drops the 
session. But it's unlikely in practice that Diameter servers will be 
overloading NASes with this kind of stuff, and it doesn't make sense 
to impose an arbitrary limit when there may be cases where a 
larger amount of Class information is necessary and the NAS is known 
to be able to handle it.

Plus, what's a Diameter server supposed to do if it must send back 
a certain amount of Class information and it's over the limit? Reject?

Paul

>> > > authorization answer message. 

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: Barney Wolff <[email-masked]>
Date: Sat, 16 Jun 2001 13:23:01 -0400

The idea of a fixed limit is to guide the designers of the NAS and
server.  Without a limit, the NAS may accomodate a huge Class for
one session and then be unable to handle even a minimal Class for
another.  The server needs to be able to count on a reasonably
sized Class being accepted.  In return, the server designer must
not use a scheme that ever requires an unreasonably large Class.

Barney

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 18 Jun 2001 07:10:03 -0700

Allright, given the discussions between Paul and Barney, would the following
work?

10.16  Class AVP

   The Class AVP (AVP Code 25) is of type OctetString and is used to by
   Diameter servers to return state information to the access device.
   When one or more Class AVPs are present in application-specific
   authorization answer messages, they MUST be present in subsequent
   re-authorization and accounting messages. Class AVPs found in a re-
   authorization answer message override the ones found in any previous
   authorization answer message. Diameter server implementations SHOULD
   NOT return Class AVPs that require more than 4096 bytes of storage on
   the Diameter client. A Diameter client that receives Class AVPs whose
   size exceeds local available storage MUST terminate the session.