[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
NAIbis effects (Was: Re: NAI decoration: User Identity issues)
Bernard Aboba wrote:
And then a question from your NAIbis draft editor: does
this resolve the issue that Farid raised earlier about
suffix-based decoration being rewritten by proxies and
then returned in an Access-Accept, causing problems for
the accounting requests? I think it does, but it seems
that we may have to, in addition, publish an RFC 3579 errata
to indicate that returned User-Name attributes should not
be used for accounting requests. Comments?
I'd say that it is at the descretion of the RADIUS server whether to
return the User-Name in the Access-Accept or not. If it is returned, the
NAS includes it in accounting requests. If not, it uses the original
User-Name, + Class + Billable Identity if those are available. I don't
think there's any need for an RFC 3579 errata.
Fair enough (and the document to change would be RFC 2865 as it
specified the general behavior). But don't you think the reader
should be alerted to this potential feature interaction in some
document? Maybe in the naibis document? In fact, we have two
choices:
1) Warn the reader about this interaction, and suggest not
using returned user name and routing syntax at the same
time.
2) Require intermediaries to redo the routing syntax
when the user name comes back in an Access-Accept.
I think the latter makes more sense. Here's the new text
in 2486bis (7th paragraph):
http://www.arkko.com/publications/nai/naibis.html#realmcons
--Jari
--
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/>