hi!
you are right that the RFC permits 0-1 occurencies of the User-Name
attribute.
I'm not sure about this but the RFC 2866 also explicitly states that the
proxying should be done in the same manner as with usual RADIUS packets:
RFC2866:
2.1. Proxy
See the "RADIUS" RFC [2] for information on Proxy RADIUS. Proxy
Accounting RADIUS works the same way, as illustrated by the following
example.
and the citation [2] (i.e. RFC 2865) states:
2.3. Proxy
The NAS sends its RADIUS access-request to the "forwarding server"
which forwards it to the "remote server". The remote server sends a
response (Access-Accept, Access-Reject, or Access-Challenge) back to
the forwarding server, which sends it back to the NAS. The User-Name
attribute MAY contain a Network Access Identifier [8] for RADIUS
Proxy operations. The choice of which server receives the forwarded
request SHOULD be based on the authentication "realm". The
authentication realm MAY be the realm part of a Network Access
Identifier (a "named realm"). Alternatively, the choice of which
server receives the forwarded request MAY be based on whatever other
criteria the forwarding server is configured to use, such as Called-
Station-Id (a "numbered realm").
that means to me that User-Name attribute is not mandatory for
forwarding requests in the terms of RADIUS. however, an implementation
can choose a way how to do it (depending on its actual usage, e.g.). so,
in terms of RADIUS you are right.
but there is a practical issue. i think that freeradius proxying is
currently largely based on the User-Name (all the configuration for
proxying and next server is based on realms which are suffixes or
prefixes of the User-Name). so, it is very logical for me to drop the
packet if you don't know where to proxy it to because otherwise FR does
not know what to do about it.
if you want to add another proxying principle, you should probably add
code and extend the config file formats. what do you want to base
proxying decisions on?
perhaps Alan should comment on it.
ciao
artur
"[EMAIL PROTECTED]" wrote:
>
> Hello,
>
> We are trying to use the freeradius as a proxy server for another
> network element but we have the followin issue:
>
> The realm code is the following:
>
> if ((request->proxy != NULL) ||
> (request->username == NULL)) {
> DEBUG2(" rlm_realm: Proxy reply, or no user name.
> Ignoring.");
> return NULL;
>
> That mean that if the accounting request has no User-Name attribute the
> request will be ignored. But if you read the rfc 2866 about radius
> accounting it says that 0 or 1 instance may be present. The nokia gprs
> ggsn that send us the accounting request doesn't include this username
> field, that why it was not working at first. We modified the code of
> rlm_realm.c to remove this condition and add another one setting a
> default user-name if the attribute is not present, and now it works fine.
>
> I would like to know your point of view on this. If you follow this rfc
> you cannot only trust the user-name field for proxying as rfc says: "it
> may be present", but there is maybe another rfc than the 2866 about
> field that should be present in an accounting request. (I m not a radius
> specialist). I hope you can give me an answer on this behaviour.
>
> Thanks,
>
> Arnaud G
--
Artur Hecker
artur[at]hecker.info
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
