[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> 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
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
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
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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.