RE: minneapolis

[Bernard Aboba <aboba@internaut.com>]

> The session is complete and therefore the above refers to authentication and
> not reauthentication and certainly not re-authorization.  What we see in the
> dial world is the session go away.  That is the user is gone.

If the session goes away,  why would it make sense to send a RADIUS
Access-Request after the user is no longer present?  There is nothing in
RFC 2865 that says that Termination-Action=RADIUS refers to authentication
only.  Your interpretation seems to imply that Termination-Action=RADIUS
yields exactly the same result as Termination-Action=Default.  If so, why
did RFC 2865 include two separate values if they mean the same thing?

> What do other similar devices do when this occurs?  Do they hold the
> session.

There are two values for Termination-Action.  The value Default means to
terminate the session.  The value RADIUS means to keep the user online and
do a conventional RADIUS Access-Request.  The Service-Type value is used
to indicate whether this is authentication-only or not; this is not
implied by default.

> Does the user see a continous service.

If Termination-Action=RADIUS, yes.

> Where does the NAS get the credentials for the subsequent authentication
> request?

The same place it got the original ones.  Most link-layers (PPP, IEEE
802.1X) support re-authentication.

> Whats a prompt?

A "prompt" refers to Service-Type="NAS Prompt" or "Callback NAS Prompt"

> Why would I "prompt" when the quota needs replenishment?

You'd do this if the Service-Type required that, otherwise not.

> I would question the need for reauthentication in the first place.  Why
> go through that expense when all that is really needed is re-authorization (and
> hence at least AUTHORIZE-ONLY message from 3576).  Why does the client have
> to be involved.

If you don't re-authenticate, then it may not be clear that the user
remains the same.  If you only want to re-authorize, just use an alternate
Service-Type in the Access-Request (e.g. Authorize-Only).

> The revenue leakage comes from the fact that a subsequent login may occur
> before the arrival of the Accounting Stop record.  o my point was (is) that
> you can do it using the RFC but you have issues such as revenue leakage.

How does changing the model prevent leakage?

> The other issue relates to the use of Accounting messages.  The simple
> prepaid solution requires Accounting messages.  Accounting messages are not
> real-time.  Do all access points support accounting messages?

It seems quite reasonable to say that access Points that wish to support
accounting (including prepaid) need to support accounting messages.

> 1- It does not rely on accounting messages.

Inventing something new to avoid depending on existing functionality does
not make much sense.

> 2- Prepaid using existing RFC can only be based on time and not Volume.  You
> need to support either or both.

This can be done by adding one more attributes.  No need for "sub-types".

> 3- It also introduces a threshold parameter that allows us to negotiate a
> quota before the quota runs out.
>
> 4- It can be extended to provide other types of prepaid features such as
> tarrif switching (supported by 3GPP2 and 3GPP).
>
> As for sub-attribute refers to earlier conversation regarding Attribute
> Extension. I would be okay without the use of sub-atttributes (but 3GPP2 did
> it that way -- so we have to figure something out).  Sub-attributes don't
> hurt they don't create incompatibilities.

Yes, they do "hurt" -- because sub-attributes require RADIUS code changes,
which is why RFC 2865 invented the dictionary and has well defined
attribute types.

If sub-attributes are required for 3GPP2 backward compatibility, then
I'd agree with Glen that the best thing would be to leave this in 3GPP2,
rather than standardizing such a radical change to an existing protocol.


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