[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question about NAI Realm based routing of RADIUS
Dhaval said:
"Hi
Thanks for the detailed response. Much appreciated.
A few more questions:
- how does this realm routing table get populated?
- what are the contents of such a realm routing table, i.e. what do the
entries look like?
- what document describes this realm routing table?
- I understand RADIUS by itself does not support DNS based server discovery,
but can it simply use hostname lookup for the FQDN of the realm and use that
IP address?
- And if I understood your email correctly, even if there is a routing
entry, the RADIUS proxy will only forward the packet if it has a shared
secret with the server just found in the realm routing
table, correct?
Thanks again
Dhaval."
The realm routing table is typically populated by manual configuration of
the RADIUS proxy. The realm routing table typically includes a realm and
the IP addresses of one or more RADIUS servers within that realm. The realm
routing table is often configured at the same time that the proxy itself is
configured, so as to ensure that each entry in the realm routing table has a
corresponding RADIUS shared secret associated with it. That way, every
destination in the realm routing table will be properly configured so that
the proxy can forward RADIUS packets to it.
Using DNS to determine the RADIUS server address from the realm name is not
advisable because there is no guarantee that the RADIUS server will have the
same name as the realm. For example, the RADIUS for "example.com" need not
reside on the machine "example.com"; it could reside at "foo.example.com"
or "balloon.example.com". That is the reason why Diameter adopted a more
sophisticated service discovery model described in RFC 3588.
Material relating to RADIUS proxy forwarding is available in the following
documents:
RFC 2477
RFC 2607
RFC 2865
RFC 4284
Material specific to Diameter forwarding and discovery is provided in RFC
3588.
===================================================
From: "Bernard Aboba" <bernard_aboba@hotmail.com>
To: radiusext@ops.ietf.org
CC: dshah@wichorus.com
Subject: Re: Question about NAI Realm based routing of RADIUS
Date: Wed, 14 Jun 2006 13:53:50 -0700
Daval --
RADIUS clients do not modify the EAP-Response/Identity, but rather they
just insert it as is into the User-Name attribute. RADIUS clients
typically are only configured with primary/secondary RADIUS servers and so
they do not handle routing; this is the responsibility of RADIUS proxies.
The situation is akin to hosts which only point to default gatways; it is
the gateways that typically run routing protocols, rather than hosts.
So in your example, the RADIUS client would send the Access-Request to the
local RADIUS proxy. if a RADIUS proxy received an Access-Request containing
a User-Name of other2.example.net!home.example.net!user@other1.example.net
then it would look in its routing table for the RADIUS server handling the
other1.example.net realm, and route the Access-Request to that server.
RADIUS servers can only be included in the realm routing table if there is
a shared secret configured for communication with that server.
Since RADIUS does not support DNS-based server discovery (this is a
Diameter feature), there is no notion of "resolving" a realm name to an IP
address other than via the realm routing table. If the RADIUS proxy did
not have a realm routing table entry for "other1.example.net" then it would
either drop the packet or perhaps send back an Access-Challenge containing
an EAP-Message/EAP-Request/Identity message containing realm hints as
specified in RFC 4284.
In Diameter, DNS-based discovery is possible. This could allow a Diameter
proxy to discover the IP address of a server within a destination realm,
without that address being configured in the realm routing table. However,
a successful Diameter session would only be set up if appropriate
credentials were available to enable authentication. For example, if
Diameter over TLS were used, then the Diameter proxy would need to be able
to verify the Diameter Server certificate based on its configured trust
anchors.
--------------------------------------------------------------------------------------------------------------------------
Date: Wed, 14 Jun 2006 12:29:13 -0700
From: Dhaval Shah <dshah@wichorus.com>
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Question about NAI Realm based routing of RADIUS
Parts/Attachments:
Hi
I have a question about NAI Realm based routing of AAA RADIUS messages
from say a 802.1x
authenticator to the Home AAA server.
Consider the following example: (I am using the notations from RFC 4282
(Network Access Identifier), section 2.7)
Lets say autheticator received user identity in EAP-Response packet as NAI
formed like
other2.example.net!home.example.net!user@other1.example.net
This NAI will be converted by the RADIUS client of the 802.1x authenticator
as
home.example.net!user@other2.example.net
and forwarded to the IP address of other2.example.net as a RADIUS
Access-Request.
My question is, RADIUS client usually needs to share a "secret" with AAA
server, in the above
case where the client needs to send the message through multiple routing
realms as coded
in the NAI, is it required that the client MUST have a shared "secret" with
the first hop AAA
server/proxy towards the Home AAA server? In the above case, does 802.1x
authenticator
of other1.example.net needs to share a "secret" with AAA server of
other2.example.net and
it MUST use that to prepare the Message Authenticator? And similarly, AAA
server of
other2.example.net MUST share a "secret" with home.example.net's AAA
server?
Also, what (if any) extensions must be added to the RADIUS message
originating at the authenticator to allow such realm based forwarding of
the packet to the Home AAA server?
thanks
Dhaval
--
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/>
--
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/>