(RADIATOR) proxy impersonating many NASen :-(

[Hugh Irvine]

Hello Neale -

I would like to see some packet dumps from this proxy, as rewriting the 
NAS-IP-Address is completely bogus.

In any case, as you rightly point out, the standard Radiator behaviour is 
based on a unique NAS-IP-Address/NAS-Port tuple, and if this is not unique 
then you will have problems.

You basically have two options. The first is to find something in the packet 
that is unique and use that. And the second is to do some manipulation of the 
contents of one or more attributes to generate something unique.

In either case, I would use an SQL session database and set up your own 
queries in the SessionDatabase SQL clause, which avoids having to mess around 
with the standard Radiator code.

One note on your hack-around below - by definition the Access-Request's will 
not contain an Acct-Session-Id (at least I would be surprised if they did), 
so I doubt that you will be able to do what you describe.

regards

Hugh

On Wednesday 30 May 2001 11:24, Neale Banks wrote:
> I have yet another, er, "challenge".
>
> My main questions:
>
> 1) Has anyone seen (or better still tackled) anything like this?
>
> 2) Can anyone see any problems with my proposed hack-around?
>
> The issue...
>
> Radiator is receiving RADIUS requests from a proxy which is rewriting the
> NAS-IP-Address (for *all* NASen) with the IP Address of the proxy.  There
> is no observed accurance of the Attribute NAS-Identifier.  As I see it,
> the RADIUS proxy looks to us like a big NAS, but with non-unique port
> numbers.
>
> Unsurprisingly, this somewhat stuffs the Session Database and consequently
> any attempt at simultaneous-use control :-(
>
> Short-term, there is one hope: the requests include a prefix on the
> Acct-Session-Id (a 2-3-digit number (followed by a literal [] then a
> 9-digit number)).  Making the *assumption* that this prefix identifies a
> particular NAS, it _should_ be possible to combine it with the NAS-Port to
> uniquely identify the port.
>
> According to rfc2865, NAS-Port is a four-octet field, implying that we
> should treat as an integer rather than a string and hence do any
> prefix+NAS-Port combining arithmetically.
>
> Making the further assumptions that NAS-Port will always be < 2**16
> (highest value seen so far is 20232) and that the prefix is an integer <
> 2**16, we should be able to construct a unique port# by upshifting the
> "prefix" by 16 bits (i.e. multiply by 2**16) and add to the the supplied
> NAS-Port.  Presumably one would only want to do this only in the session
> database (in particular, taking care to reply to the RADIUS proxy with the
> original NAS-Port).
>
> As the SessionDB is DBM, it appears that the obvious place to try such
> ugly hackery is in SessDBM.pm.
>
> Any comments/suggestions/etc gratefully accepted.
>
> Regards,
> Neale.
>
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.

-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.