My comments are inline.
But let me summarize here.
To use Termination-Action for a general prepaid solution is risky. We agree
that it could work however, the specifications are ambiguious (as per our
exchanges below). RFC3580 tightens the standard but it is only applicable
to WLAN.
The use of accounting messages also introduce risk (see our exchanges
below). Prepaid solution that relies on accounting messages would require
that Proxies provide real-time delivery of accounting message. Otherwise as
we show the operators will incure revenue leakages. Note: you could
elliminate the need for accounting.
We don't think we are re-inventing the wheel. If you read the I-D we
address issues that go beyond just how you replenish quotas etc....
> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com]
> Sent: Thursday, September 11, 2003 5:50 PM
> To: Avi Lior
> Cc: 'gwz@cisco.com'; 'Randy Bush'; 'radius list'
> Subject: RE: minneapolis
>
Avi writes:
>What we see in the dial world is the session go away. That is the user is
gone.
Bernard writes:
> If the session goes away, why would it make sense to send a
> RADIUS Access-Request after the user is no longer present?
According to the words in 2865
5.24 State Attribute:
"This Attribute is available to be sent by the server to the client
in an Access-Accept that also includes a Termination-Action
Attribute with the value of RADIUS-Request. If the NAS performs
the Termination-Action by sending a new Access-Request upon
termination of the current session, it MUST include the State
attribute unchanged in that Access-Request."
Key word here is session. Termination of a session means the user goes away
right?
One reason for firing back the Access Request after the user is gone
(session is terminated) is so that a RADIUS server that is tracking sessions
but not receiving accounting messages can be notified that the session went
away.
> 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?
The difference is at the NAS.
>
> 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.
I can not derive that from 2865.
Do you interpret the user hanging (ie, termination of their session) as a
termination of a service as well? If yes, then according to 2865
" If the Value is set to RADIUS-Request, upon termination of the
specified service the NAS MAY send a new Access-Request to the
RADIUS server, including the State attribute if any.
"
RFC3580 is much cleaner than 2865. 3580 implies that you can only send the
Termination-Action = RADIUS-Request(1) if Session-Timeout is sent as well.
"The value RADIUS-Request (1) indicates that re-authentication should occur
on expiration of the Session-Time. The value Default (0) indicates that the
session should terminate."
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.
For WIFI yes. WIFI defines the behavior explicitly. For other deployments
we are not sure. If you look at 2865 the definition of Session Timeout is:
"The field is 4 octets, containing a 32-bit unsigned integer with
the maximum number of seconds this user should be allowed to
remain connected by the NAS."
How do you interpert "connected"?
> > 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?
Changing the model may not prevent leakage but it can certainly reduce it
(which is what I said originally).
> > 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.
Agreed. But for prepaid it depends on the model you use. Our model does
not require the use of accounting messages.
> > 1- It does not rely on accounting messages.
>
> Inventing something new to avoid depending on existing
> functionality does not make much sense.
We are not avoiding using existing functionality. Where do I say this?
Accounting message do not have to be real-time (RFC 2866). Our model allows
us to deploy a Prepaid solution that does not require any changes in
Proxy-Chains.
> > 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".
>
Agreed.
> > 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.
>
They only "hurt" the client and the end server -- not the proxy chains. I
agree with the avoidance of sub-attributes.
--
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/>