Re: User Alias Identity (Was: Re: comments on draft-adrangi-radius-attributes-extension-00.tx)

["Alan DeKok" <aland@ox.org>]

Bernard Aboba <aboba@internaut.com> wrote:
> The User-Name attribute is optional in an Access-Accept according to
> both RFC 2865 and 3579.  As has been noted by Barney Wolff, a
> proxy-state attribute can be used to enable proper routing of the
> Access-Accept, ...

  I understood the original comment to be discussing a problem with
accounting packets, as mentioned in RFC 3579, Section 3.

  e.g.

  Access-Request ("user@decorated", with inner tunnel of "user")
  Access-Accept  (returns "user")
  Accounting-Request (accounting for "user")

  Requests containing "user@decorated" can be routed, as a result of
the decorations.  The Accounting-Request, therefore, cannot.  It needs
additional information.  While the Class attribute could be used here,
but it may already be used for other purposes, and some
implementations may get confused with multiple Class attributes.

  The authentication server can't tell the NAS to send accounting
information with "user@decorated", because that may be
"anonymous@...", and used for many sessions.

  I'm not offering a solution, just an alternate presentation of the
original post.

  Alan DeKok.

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