RE: User Identity issues

["Blair T. Bullock" <bbullock@ipass.com>]

Sure I'm not telling y'all anything you don't already know, but just to
be clear...

As part of the roaming mediation and RADIUS clearinghouse process, once
the accounting is received by the mediated AAA exchange (routed by the
promiscuous decorations applied by the user or smart client), they are
forwarded/copied through the secure exchange to the Home Authentication
Server.  Part of the mediated roaming and clearing framework is not only
the Authentication events, but also the handling of the resulting
accounting packets for billing and secure forwarding to the Home
network.  Therefore, the AAA streams should take the same route based on
identical decoration as originally presented by the supplicant/peer.
Provisioning default routes, directed realm routes or other such
mechanisms to handle accounting separate from the
authentication/authorization events and NAI context causes event
correlation problems and potentially mis-routes accounting to other
clearinghouses.

If an enterprise uses multiple mediated roaming services, say GoRemote
and iPass, it is the NAI decoration which selects the desire exchange
for authentication and the accounting must follow suit without risk of
authenticating on one exchange and accounting on another.  We currently
rely on the NAI to correlate and handle those disparate events.  It is
not uncommon for one clearinghouse to get the accounting for another's
session due to timeout to one exchange and accounting following the
DEFAULT route to another.  Thankfully, with clear NAI construction
principles in place, we can easily determine whether or not this was
actually a request where we handled the authentication or is a misroute
from another's.  

We enjoy a very high rate of AAA event correlation (around 98%+) due to
our managed NAI construction principles and low-latent local secure
proxies. These are founded on explicit NAI rules which can not change
over the course of the AAA sequence.

I'm not saying this is the only or even the best way.  In fact the
principles we operate on have their shortcomings too.  Only, it has up
to now been the most practical and expedient way to handle the
aggregated network access through mediated AAA to multi-homed RADIUS
clearinghouse model under practical real-world scenarios and legacy
RADIUS technology.  If there is a "better" way, we are all over it.
=^)   Only, it can't break our existing customer base in one fell
swoop....  It must be inclusive and any RADIUS methodology must provide
a migration path to allow everyone to get from here to there without
starting from scratch or knee-jerk fixes due to AP upgrades.

-Blair

-----Original Message-----
From: Nelson, David [mailto:dnelson@enterasys.com] 
Sent: Wednesday, June 16, 2004 7:57 AM
To: radiusext@ops.ietf.org
Subject: RE: User Identity issues

Bernard Aboba writes...

> As Blair notes, there are cases where the Accounting data needs to 
> follow the same path as Authorization, and User-Name rewriting can 
> break that.

I generally understand that the issue is multi-party
brokering/mediation.  There are multiple entities that need to get their
"cut" of the revenue associated with the user's session.  Does that
imply that the accounting requests need to traverse the same path as the
authentication requests?  Does each entity need to maintain their own
accounting logs, or do the entities trust one central clearing house to
give then their fair share of revenue?  If the latter is true, then it
would seem that accounting requests could be sent directly to the
central clearing house, along with some indication of the list of
parties involved, so that the revenue allocation can be calculated and
distributed.

I guess what I'm asking is that the business-domain problem be clearly
defined before we attempt to create a protocol-domain solution that
meets the business requirements.

--  Dave



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



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