RE: Clearinghouse/Aggregator Support for CUI

[<john.loughney@nokia.com>]

Blair,

I agree your mail below; re-reading the current CUI draft, most of the information you list is missing, however. I think it would make sense to add a motivation section to the draft - I'd suggest adding some of the content from your mail as part of the motivation section.

John

-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Blair T. Bullock
Sent: 24 October, 2004 23:18
To: Barney Wolff; radiusext@ops.ietf.org
Subject: Clearinghouse/Aggregator Support for CUI


Collegues, 

I wanted to chime in again on the adoption of CUI and summarize where I see the general consensus within the industry on legacy-based work-arounds.  When I say "Industry", I mean from the results of parallel multi-year analysis by WISPr, GSMA, 3GPP,GWDR, Wi-Fi Alliance, IRAP, Intel/IDA IWS and several well-respected RADIUS experts within this organization.  From a Clearinghouse/Aggregator standpoint, I have intimate knowlege of several major RADIUS clearinghouse systems and their supplying networks and know that what I describe here is absolutely crucial to the proper adoption and mediated AAA of Tunneled EAP methods for WPA Public Access.    This problem is very well understood!    Class doesn't work.  NAI modification is bad.  The Outer-Identity is discarded at Authorization and there is no good way to oversee tunneled EAP authentications without Early Termination or reflection in User-Name which modifies the NAI.

CUI is basically designed to close operational loopoles in RADIUS allowed by the original RFCs, but which have impacted roaming network solutions in a negative way, particularly with the introduction of multiple identity tunneled protocols such as PEAP or TTLS.  To concur what was said earlier on this thread, a clearly chargeable user/alias reflecting the home network's authenticated user profile is absolutely neccessary for all parties and *must be transparent*.   

The concern for legacy-based support is valid, but unwarranted.  If presented in a hybrid network, any new attributes should be silently discarded and not dropped or NAKed due to malformation or unsupported attributes.  Besides, the CUI is specifically geared to Multi-Identity EAP authentications which in all honestly, are built with the latest protocols.  An older radius endpoint could trigger CUI by virtue of including the User-Name in its Access-Accepts, but would merely drop the attribute when it arrives in Accounting (assuming that the NAS doesn't change the NAI and route it into neverland)

The loophole RADIUS operations are:

1 - User-Name Overwrite:   Overwriting the User-Name with the User-Name in the Access-Accept.  Ouch!! Whether by chance or choice, this is just *wrong* as an accounting approach.  In a Local or Bi-lateral service, I can see why this would be useful to reflect the authenticated profile from the Access-Accept User-Name (assuming the home network uses an @realm or they won't get Accounting back, even in standard methods).  But with a Tunneled EAP Inner ID being returned in a Home-Based Access-Accept to a network which derives its peering from client-based source decorated NAI?  It is Desastrous!!  Furthermore, willfull lack of decoration for the Inner ID is a clear opportunity for fraud!  Therefore, User-Name is not allowed to be returned in the Access-Accept User-Name so that RADIUS networks can be assured to receive Accounting packets down the same peering path that the Authentication use.  

2 - NAI:  As someone rightfully noted on this reflector, the proprietary Global clearinghouse Prefix-based NAI construction methods which have evolved over the past decade are not represented in the latest drafts.  These methods were designed with business and RADIUS legacy interoperability in mind.  Simple chained suffix-based routing to consumers (@realm@realm) was the only standard that we had.  It allowed for reseller arrangements.  However, in order to deal with the aggregation of networks for supply, another mechanism was needed.  The prefix.  The "/" was initially presented by UUnet and because it was not specifically reserved, allowed the formation of proprietary network aggregation while leveraging the stadards-based realm support for resale of that aggregated service. operator/agregator/user@realm@reseller.  Now it is supported ubiquitously and maintains legacy compat down to livingston 1.16.    Whether good or bad, reality dictates that it is a defacto standard.  Ergo the originally presented NAI held by the NAS must not be changed based on "standard" NAI construction principles...ever...at least for use with these global networks and their partners.   You simply don't know in every case how they have constructed the NAI and must always respect a pre-decorated NAI.  

The disparate NAS support for User-Name overwrite is mitigated by the elimination of User-Name in the A-A, basically breaking CUI too until allowed on a verified CUI functional network which will be the normal oversight for deploying a new WPA service.   Tunneled EAP for Public Access roaming will not be adopted until the User-Name is passed back in the Access Accept for use with the CUI only and never the User-name.  This will only happen after verification that these specific operations have been corrected and CUI fulfills the exposure of the Authenticated Home User Profile without modifying the Accounting User-Name.  Its that simple.  We need the NAI in the User-Name unspoiled to honor our routing and aggregation methods.  A consistent way to expose the actual authenticated profile on a per-user/per-session basis for the purposes of revenue assurance, fraud detection and service oversight is fundamental in a Federated AAA Fabric such as iPass or an aggregated RADIUS peering fabric such as with our many competitors.  

From discussion with WISP global partners deploying WPA, CUI service oversight is also crucial where **no roaming** is even occurring!  Since the OuterID is dropped at the time of authentication, you simply have to know which profile is authorized as exposed in the accounting.

CLASS - The Class Attribute was the initial legacy-based work-around to CUI based on its ability to reflect home data in an accounting stream.  However:
 1 - It is intended to be opaque to all but the home network (which does no good since the whole purpose is to tie specific sessions to distinct authorizations between all parties.)
2 - This is an additive attribute and their value ordering unspecified.  How many classes to we demand support for in a NAS?  One?  Four?  Eight?  Many of these APs don't have that much processing power.

CUI is the correct standards-based approach to fixing the problems which have arisen with multiple-identity RADIUS auth and accounting methods.  While it will not solve all problems (like MSCHAPv2 in TTLS IN TTLS), but it does respond to the readily available EAP supplicants and provides the current global RADIUS networks with the capacity to deploy, bill and oversee WPA networks against fraud.  Without this, other proprietary methods will be done, I assure you.  However, our job would be much easier if there was wide adoption of the CUI attribute.  iPass for instance, would mandate and facilitate its adoption immediately.

CUI is not an overloading of a legacy attribute or arbitrary kludge of existing attributes in order to make these networks work.  It is a necessary correction amongst the others listed above.

Thanks for your time.

Blair Bullock
Systems Arhitect, iPass Inc.

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