RE: Comments/questions on Prepaid-draft-02

[Avi Lior <avi@bridgewatersystems.com>]

Nagi,

Thanx very much for the questions/comments/concerns.  I have answered most
of your questions, hopefully well ;-) --  ( I owe you answers for the first
two)


> Here are the comments/questions on prepaid-draft-02.
> 
> 1) I'm not really convinced with the way *Service Element" 
> work? How can an element sits in between access device and a 
> Prepaid server *disconnect* a session on the access device? I 
> can unserstand it can meter the things but can not disconnect 
> sessions.
> 
> You can argue that Service element asks/updates the quotas. 
> How do you handle the re-authorizations that are supposed to 
> be initiated by access devices.
> 
> Can you explain little further of its significance and how it works?
> 
> 
> 2) Doesn't PP draft *standardize* the servic keys? I would 
> assume that it is really important for interoperation.
> 
> 3) Always, Termination-Action MUST be set to Radius-Request to
>    make sure that access device will ask for another quota rather than
>    disconnecting the session (it is the case if Termination-Action
>    = default).

Not neccesarily.  We don't need to rely on Termination-Action in Prepaid.
The NAS would request additional quota when the threshold has been reached.
The NAS would request additional quota when the quota runs out.
Both of these actions are independent of the setting of Termination-Action.


> 4) Section 4.2 talks about sending User-Password attribute 
> while sending
> 
> the message from HAAA to Prepaid server for more security.
> 
> I disagree with this. What are we doing here? Are we making 
> PP server another authentication server?

What we say in the draft is this:

For added security, the HAAA MAY also set the User-Password(2) attribute 
to the password used between the HAAA and the PrePaid server. 

Note it is NOT the user's password and therefore the PPS is not an
authentication service. It is a password that can be configured between the
Home AAA and the Prepaid Server.  The thought was that it COULD be used to
enhance security.  We can remove this if it adds no value.

> 5) Sections 4.2.1 and  4.4, Ascend-data-filter was mentioned 
> separately.
> 
>      I guess we can remove this.

We are currently investigating the addition of a new RADIUS attribute to
allow us to do Redirects. This is needed for WLAN and other applications.

So we will remove the mention of Ascend Filter.

> 6) Section 4.4, Mid-Session Operation - doesn't consider if 
> there are Broker AAAs in between. For example, You may need 
> to add IP addresses of PP servers to the Access-Requests.

There should be no impact on Broker AAAs in any phase (start of session,
mid-session and end of session).  Broker AAAs will forward the
Access-Requests to the home network based on the user-name attribute.  The
AAA in the home network will then forward the Access Request to the
appropriate PPS by looking in the PPAQ attribute which contains the IP
Address of the serving PP Servers and optionaly delegates.

The design intent is to have no impact on Broker AAA servers.


> 7) Section 4.4, Mid-Session operation:
> 
> Isn't it possible that the operator wants to update his 
> services and wants to notify the access points.

Not sure I follow your question here.  Please clarify.
> 
> 8) Section 4.5.1. says "Each AAA MUST route the Disconnect 
> Request packet. How the routing decision is made is an 
> implementation detail. "
> 
> Can you explain how can a Disconnect message initiated by PP 
> server will reach the Access Device?  I mean what are the 
> attributes involved to make the packet reach its destination 
> through the proxies.

There is a good discussion of this in RFC-3576. 

> 
> 9) what does a PP server do if it receives Disconnect-NAK?
> Does it keep billing?

It would have to stop billing.  You always err on the side of the
subscriber. However, remember that all of these things are covered by
roaming agreements.  So I suppose the event would be recorded and the issue
would be taken up by the operators.

Also note that the revenue loss would be limited to the Quota.  One reason
for a having a quota is to limit liability (in this case revenue loss) when
things go wrong.


> 10) Section 4.5.1
> 
> "Once the Disconnect Request packet reaches AAA that is in the same
>    network as the serving Access Device, if the Access Device supports
>    Disconnect-Request (as per [RFC3576]), it sends the 
> message directly
>    to the Access Device; otherwise it uses other mechanisms such as
>    SNMP or Telnet to command the Access Device to terminate the
>    session."
> 
>   - How does a AAA server know that if the access point supports
>      Disconnect (or) CoA messages?  Is this also out of scope? :)

I think you mean the Visited AAA.  The Visited AAA (which is co-located with
the access point) would be configured to indicate whether the devices
support particular messages.

How the VAAA is configured is out of scope.

> 
>   - How does Telnet/SNMP work in this scenario. Can you 
> further explain?

Some NAS devices out there support the ability to terminate sessions by
either telnet or SNMP.  If we know its telnet then we can start a telnet
session to terminate a session (this is highly vendor specific)  If the
device is not reachable by telnet (for whatever reason - but one common one
is that it is in another adminstrative network) then we would expect that
the Visited network accept a Disconnect message and it would then disconnect
the session using Telnet, SNMP or whatever it has available to disconnect
the session.

 
> 11) Should there be a threshold value always ( with 
> Volume/Time quota).
>       Is it possible that an access device choose not to implement
>       this attribute?

I don't think that we would mandate the Threshold value.  However, there is
a timing issue.  What happens between the time that the counter
(time/volume) has expired and the time where we get more quota?  Is service
disruptted?
Note this is the same issue that exists today with Terminate-Action.  What
happens to the Service when the user is being re-authenticated.

 
> 12) Section 5.3.
> 
> "Sub-Type (=3): Sub-Type for VolumeQuotaOverflow
>    Length: length of VolumeQuotaOverflow attribute (= 4 octets)
>    VolumeQuotaOverflow (VQO):
> 
>       The optional VolumeQuotaOverflow Sub-Type is used to 
> indicate how
>       many times the VolumeQuota counter has wrapped around 2^32 over
>       the course of the service being provided. "
> 
> Is this present in access-request (or) access-accept? Its 
> worth mentioning who sends to whom.

We will clarify.

> 
> Regards
> Nagi.
> 
> PS: Can you tell us what does it take to flatten the 
> attributes. Roughly, how many new attributes are needed? I 
> believe it is really important to debate this topic to make progress.
> 

Lets say we would need 10 attributes.  But as you can see I think this
argument is not relevant.

First the intent is that the subtypes are only used by the two end points.
The prepaid attributes are used by two applications to communicate with each
other.  The two applications are the Prepaid Client which runs on the NAS
and the Prepaid Server which runs in the home AAA.  Broker AAA need not look
inside those attributes.

Second, there is more then enough examples of current attributes in RADIUS
and Diameter that contain more then one piece of information encoded in a
String Attribute.  So I really don't see an issue.

I think the concern is that we don't invent a new RADIUS attribute type
called "SUBTYPE" and I totally agree with that because that would "break"
RADIUS in the sense that Proxy RADIUS servers would have to understand this
new type.  We are not doing that at all.  The attributes that we define are
strings.

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