(RADIATOR) proxy impersonating many NASen :-(

[Neale Banks]

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.