[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AAA Routing with EAP-ER
Hi Bernhard,
Bernard Aboba wrote:
I think this makes the assumption that every Diameter agent advertising
support for the ERX application understands ERX.
That's not really desirable.
While Diameter auth
servers do need to understand the application to advertise it, Diameter agents
may only be able to forward the messages.
Correct.
This could become an issue if there is an expectation that the "local server"
will process a packet whose NAI realm is not the local realm.
Based on my understanding this seems to be the case with EAP-ER.
Instead of
processing the packet, the Diameter agent would forward the packet to
the server corresponding to the NAI realm (e.g. the home server).
The issue is that there is no equivalent of the "router alert" option for
AAA.
I know.
It seems that you are saying that a new Diameter application would be
necessary to accomplish the required functionality in a reasonable way.
Ciao
Hannes
Date: Fri, 4 Jan 2008 11:56:35 +0100> From: Hannes.Tschofenig@gmx.net> To: Bernard_Aboba@hotmail.com> CC: radiusext@ops.ietf.org; hokey@ietf.org> Subject: AAA Routing with EAP-ER> > Working on> http://tools.ietf.org/wg/dime/draft-dondeti-dime-erp-diameter-01.txt> the question of defining AVPs vs. defining a new Diameter application > showed up.> > I wrote a section about this into that draft and I wonder whether my > assumptions are reasonable:> > 3. Assumptions> > This document defines additional optional AVPs for usage with the> Diameter EAP application. Routing of these messages is therefore> provided via the Diameter Application Identifier (among other> elements), as specified by the Diameter Base protocol [4]. Based on> the deployment of ERP, a local Diameter server (the same entity> serves as a Diameter proxy during the full EAP authentication) may> play the role of the ER server for future re-authentication attempts.> As such, the local Diameter server requesting the DSRK needs to be in> the path of the current EAP exchange between the peer and the EAP> server and also along the path in the future. The Diameter client is > furthermore assumed to be able to route the re-authentication > messages to the ER server.> > > Depending on some of the answers to the questions raised in this > discussion it might be necessary to define a new Diameter application > rather than just defining new AVPs.> > Ciao> Hannes> > > Bernard_Aboba@hotmail.com wrote:> >> When the peer, the local domain and the AAA-Home also> >> support ERP, a DSRK (DSRK1) may be requested by the local ER server A at> >> the time of the EAP exchange.> >> > Some questions:> >> > 1. Is the "Local ER server" always a RADIUS client? The ERX > > document seems to> > indicate that this might not always be the case.> >> > 2. How is the request for the DSRK made by the "local ER server"? > > Is the> > request authenticated with user credentials? How does the RADIUS server> > determine if the Request is valid?> >> > 3. How does the RADIUS server know how to reach the "Local ER server"?> > The ERX document talks about a "Domain Identity". How does the RADIUS > > server> > use the "Domain Identity" to determine what RADIUS client to send a > > packet to?> > Is there an assumption that the "Local ER server" is one hop away from > > the> > home RADIUS server? What attributes need to be placed within an > > Access-Accept> > to ensure that the packet is routed to the "local server"?> >> > 4. In Figure 1, the ERX document shows the following flow:> >> > [<-- EAP-Request/ ------> > Identity]> > [<-- EAP Initiate/ ------> > Reauth-Start]> >> > Is this a typo? The figure shows that the EAP-Request/Identity isn't > > being responded> > to by the peer. If the peer implements RFC 3748, won't it send an > > EAP-Response,> > which will be passed to the RADIUS server, which will then initiate > > EAP? Figure 1> > seems to show the EAP peer ignoring the EAP-Request, which> > implies that it needs to wait for some period of time for another > > message, which> > might or might not arrive. How long should it wait?> >> > If the peer doesn't respond to the EAP-Request/Identity, according to > > RFC 3748> > and RFC 4137, the NAS will retransmit. So we'll have two EAP > > conversations> > going on at once?> >> > 5. In Figure 2, the peer is initiating what would appear to be a > > standard> > RADIUS/EAP conversation via the EAP-Response/Identity. However, it> > would appear that the EAP Response/Identity is being "augmented" by> > the local server. It's hard for me to tell from the figure whether the> > [DSRK Req, Domain Identity] is being inserted within the > > EAP-Response/Identity,> > or whether it represents separate RADIUS attributes. Can you clarify?> >> > 6. If the "local 'server" isn't on the path between the NAS and the > > home server> > (as it might not be, because of failover), what happens? Does each > > proxy> > also need to host a "local server" to make sure that doesn't occur?> > If the "local server" is not on the path, then it seems like two > > distinct messages> > would be required. Is there an expectation that the RADIUS > > Access-Accept> > will be multicast, or that two distinct RADIUS Access-Accept packets will> > be sent?> >> >> >> >> >> >> > -- > > 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/>