RE: minneapolis

[Avi Lior <avi@bridgewatersystems.com>]

See inline.

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Thursday, September 11, 2003 1:27 PM
> To: Avi Lior
> Cc: 'gwz@cisco.com'; 'Randy Bush'; 'radius list'
> Subject: RE: minneapolis
> 
> 
> > You can assign Session-Timeout a portion of X but then the 
> NAS would 
> > boot the user off.  Terminate-Action is not usable since it is sent 
> > after the NAS kicks the user off.
> >
> > 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."
> >
> >
> > In WLAN its different.
> 
> How is it different?  The above paragraph in RFC 2865 refers 
> to re-authentication.

It is different in WLAN because 3850 specifies precisely how to do
re-authentication when these attributes are sent back in an access accept.

In 2865 its not so clear.  The exact wording in 2865:

This Attribute indicates what action the NAS should take when the
specified service is completed.  It is only used in Access-Accept
packets.

The key words are "is completed".

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.

What do other similar devices do when this occurs?  Do they hold the
session.  Does the user see a continous service.  If not this is a poor (at
best) mechanism to use for prepaid in a general context.  IMHO, I think the
mechanims in 2865 raises more questions then answers. For instance where
does the NAS get the credentials for the subsequent authentication request?

From 2865 Session-Timeout:

  This Attribute sets the maximum number of seconds of service to be
      provided to the user before termination of the session or prompt.

Whats a prompt?

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


I would question the need for reauthencation 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.

> > In other words, it appears that in WLAN there is a reauthentication 
> > mechanism that we can use to get another quota.
> 
> This is just the mechanism described in RFC 2865.
> 
> > If what is meant by simple prepaid solution is a solution 
> that works 
> > with existing deployements then this is not a simple 
> prepaid solution 
> > that works without changes.
> 
> Actually, it sounds like you've just shown that a prepaid 
> solution can be implemented based on RFC 2865 with no changes 
> at all -- and no revenue leakage, without even requiring a 
> dependency on RFC 3576.

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.

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?


> > Hope this clears things up.
> 
> Actually, this makes things even more unclear.  Not only does 
> the prepaid draft invent a new RADIUS attribute format for 
> "sub-attributes" but now it appears that it is also 
> reinventing functionality already supported in RFC 2865.

What is being reinvented?

Our draft is useful:

1- It does not rely on accounting messages.
2- Prepaid using existing RFC can only be based on time and not Volume.  You
need to support either or both.
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. 




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