[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: User Alias Identity (Was: Re: comments on draft-adrangi-radius-attributes-extension-00.tx)
> > So, presumably the NASes were not prepared for the
> > possibility that the User-Name attribute might change.
> > Do they actually break, or is it just that they ignore
> > the User-Name attribute when it comes back?
>
> It will break the billing functionality according to the information
> that we got from GSMA vendors.
Can you explain what this means? Does the NAS crash? Send an accounting
record with the User-Name sent in the Access-Request instead? Do
something else? Perhaps we should hear directly from the vendors in
question about how they handle this.
Remember that RFC 2865 enables inclusion of the User-Name attribute in an
Access-Accept, so that compliant RADIUS client implementations need to be
able to deal with this:
Request Accept Reject Challenge # Attribute
0-1 0-1 0 0 1 User-Name
> It applies to all scenarios where user's real or billable identity is
> not revealed to the NAS by the user.
RFC 3579 contains the same entry as RFC 2865 with respect to User-Name:
Request Accept Reject Challenge # Attribute
0-1 0-1 0 0 1 User-Name
> RFC3579 does not mandate supporting user-name(1) rewrite so in my mind
> it won't make it uncompliant. No?
Here is what RFC 3579 says:
"In order to permit forwarding of the Access-Reply by EAP-unaware proxies,
if a User-Name attribute was included in an Access-Request, the RADIUS
server MUST include the User-Name attribute in subsequent Access-Accept
packets. Without the User-Name attribute, accounting and billing becomes
difficult to manage. The User-Name attribute within the Access-Accept packet
need not be the same as the User-Name attribute in the Access-Request."
So in effect, handling of a User-Name attribute within an Access-Accept is
mandatory. RFC 3579 also warns RADIUS client implementations not to
assume that the User-Name attribute will not necessarily be the same in a
response as in a request.
So I'd say that a RADIUS client needs to support User-Name in an
Access-Accept and also needs to be prepared for user-name rewrite.
> The difference in the amount of code changes required by these two
> methods is not the core issue. The main goal is to provide a solution
> that can be deployment without any changes to NAS, and without
> disturbing the current use of User-Name(1) -- i.e., GSMA
> vendors/operators don't want to overload the use of UserName(1) or
> create conflicts/incompatibilities.
This seems like one of several areas in which there are interoperability
issues with current RADIUS implementations. Where there are
interoperability problems, it is typically required for *some*
implementation to change. The purpose of the "RADIUS Implementation
Errors and Fixes" document is to document these problems and propose
solutions.
> > ensure that the above NAS-need-not-be-changed properties can
> > be achieved if we move into this separation. That is, I'd like
> > to understand how this works in a backwards compatible manner
> > without requiring updates to the NASes.
I don't see how this can possibly be implemented without changing NASes.
Since this is an interoperability issue, the problem isn't "does someone
have to change" -- but rather "what should change" and "how".
--
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/>