Question about Radius Server Arrangement in Recpriocal ISP Roaming Agreements

Question about Radius Server Arrangement in Recpriocal ISP Roaming Agreements

Post by <Noesis Strategy> » Fri, 20 Jun 2003 23:13:29



In basic, high level terms, how would two ISP's allow for roaming between
their networks?   Would each have a proxy radius for the other ISP located
within its own network?  Or rather, could the radius servers of each be
somehow interlinked without the database of each being replicated?

If we scale this scenario up to five ISP's with reciprocity agreements
amongst all of them, how would this be arrange.  Some vendors are
advertising "Roaming Servers", which I assume implies some table to redirect
incoming requests.  If not, could each [roaming] request be sequentially
checked against the five other databases.   I would assume this would be
very inneficient.

thanks in advance,

Scott

pspope at noesis-strategy.com

 
 
 

Question about Radius Server Arrangement in Recpriocal ISP Roaming Agreements

Post by Tony » Fri, 20 Jun 2003 23:54:34


The user's account/password is usually hosted by 1 of the isps.  The rest
just proxy that user's realm (ex. ford.com) to the hosted isp.

The real problem occurs when the customer has separate contracts with each
ISP for the same realm.  Then the three parties need to work out some sort
of deal.  Though typically when a customer has separate contracts, they are
a "large enterprise" (like ford).  In which case, there is a very good
chance that they (ford) host their own user store with a connected RADIUS
server.  In that case, all of the ISPs just proxy the requests to Ford for
authentication and/or accounting.  If the ISP needs to inject "special"
attributes into the packets (to support weird NAS features like filters,
etc.), they can do so with their (the ISP's) proxies.

--
Tony


> In basic, high level terms, how would two ISP's allow for roaming between
> their networks?   Would each have a proxy radius for the other ISP located
> within its own network?  Or rather, could the radius servers of each be
> somehow interlinked without the database of each being replicated?

> If we scale this scenario up to five ISP's with reciprocity agreements
> amongst all of them, how would this be arrange.  Some vendors are
> advertising "Roaming Servers", which I assume implies some table to
redirect
> incoming requests.  If not, could each [roaming] request be sequentially
> checked against the five other databases.   I would assume this would be
> very inneficient.

> thanks in advance,

> Scott

> pspope at noesis-strategy.com


 
 
 

Question about Radius Server Arrangement in Recpriocal ISP Roaming Agreements

Post by Sam Salhi [MSFT » Sat, 21 Jun 2003 01:27:12


Thanks Tony, that was great,
Allow me to rephrase this information a little bit

The way to have roaming enabled between 2 ISP's is to enable conditional

username is ISP2\User) then forward to ISP2
to scale this to 5 ISP's it's the same thing,
If ISP1 gets a request for


    ISP4 he forwards to ISP4 ..

Now for larger deployments, the architecture might want to be modified a
little bit, but this is basically the way to do it.
You might want to have a central server which will make all the decisions or
as follows
ISP1 gets the access request, checks if it doesn't include any additional
domain info then it's his and makes a decision
    If it does contain domain info, and it's not his info, he can just
forward it to a Central Server
Central Server gets the request, and determines if the domain info is for
one of the domains he serves, and forwards it if that is true. Else, Central
Server rejects the request
Second ISP gets the request, evaluates it, (accepts or rejects) And sends
the request back to central server which will forward the response to ISP.

In the second approach you have all your forwarding logic done in one place,
so it might be easier to manage

Lastly, Cross Domain and Cross Forest authentication
This is off the original topic, but related....
If you have a company that manages 2 domains, then you don't even need to
forward requests between the 2 domains IAS can look up the users in both
domains if there is a trust between them

New for WS2003, if you have 2 Forests, with Multiple domains in each, then
again, IAS can look up users anywhere in both forests just by establishing
the new WS2003 Forest trust. (You might want to add IAS to the RAS and IAS
servers group on the GC of the forest)

--
===========================================================
This posting is provided "AS IS" with no warranties and confers no rights
===========================================================


> The user's account/password is usually hosted by 1 of the isps.  The rest
> just proxy that user's realm (ex. ford.com) to the hosted isp.

> The real problem occurs when the customer has separate contracts with each
> ISP for the same realm.  Then the three parties need to work out some sort
> of deal.  Though typically when a customer has separate contracts, they
are
> a "large enterprise" (like ford).  In which case, there is a very good
> chance that they (ford) host their own user store with a connected RADIUS
> server.  In that case, all of the ISPs just proxy the requests to Ford for
> authentication and/or accounting.  If the ISP needs to inject "special"
> attributes into the packets (to support weird NAS features like filters,
> etc.), they can do so with their (the ISP's) proxies.

> --
> Tony

> > In basic, high level terms, how would two ISP's allow for roaming
between
> > their networks?   Would each have a proxy radius for the other ISP
located
> > within its own network?  Or rather, could the radius servers of each be
> > somehow interlinked without the database of each being replicated?

> > If we scale this scenario up to five ISP's with reciprocity agreements
> > amongst all of them, how would this be arrange.  Some vendors are
> > advertising "Roaming Servers", which I assume implies some table to
> redirect
> > incoming requests.  If not, could each [roaming] request be sequentially
> > checked against the five other databases.   I would assume this would be
> > very inneficient.

> > thanks in advance,

> > Scott

> > pspope at noesis-strategy.com

 
 
 

1. Question about Roaming/Un-roaming on Sprint PCS

The other day, I was driving on I-5 in far northern California,
returning from Oregon to San Francisco. My cellphone is a Samsung
SCH-3500 on Sprint PCS, and Sprint has a major gap in coverage between
Ashland OR and Redding CA. Since I was expecting an important incoming
call, I put the phone into "Automatic" roaming mode, which can roam on
analog or digital networks. There was a stretch around Dunsmuir where
I couldn't even get a signal on any compatible roaming network, but
then I picked up an analog signal and locked onto it.

The part that got me wondering the most, though, was when I got into
Redding. I was into the city of Redding itself, which has good
coverage on the Sprint PCS network. However, the phone stayed locked
onto the analog roaming signal, even though there was no inbound or
outbound activity. I finally had to switch the phone back to
Sprint-only mode to get it to re-test for a signal; it then promptly
latched onto a solid signal and registered with the system, picking up
a voicemail that had been left earlier when I was off the air.

So my question is, if a cellphone is in standby mode and has locked
onto a roaming signal, what is the protocol for trying again to lock
onto the preferred carrier? I would guess that I was in roaming mode
in Sprint coverage territory for at least about 10 minutes without
ever detecting that I could and should switch back to the Sprint
network.

I could understand that the phone would stick with the analog roaming
carrier if I had a call in progress, but it seems like it should be a
bit more diligent about detecting that it no longer needs to roam.

2. How to typeset "Player A"

3. Can ISP Dial-ins Really Cause Blocking in the CO?

4. Terminal emulator wanted

5. Line breaks in bibliography citations

6. newbie question: Global Roaming Server

7. Principal payment

8. Cisco radius attributes with Funk Steel-Belted Radius Server

9. roaming dial-back with radius

10. Radius Console Login Authentication if Radius Servers are not accessible

11. radius ppp authentication onto Netware radius server

12. Use WIN-NT-Option-Pack RADIUS-Server for CISCO-RADIUS-Authentication