(RADIATOR) proxy impersonating many NASen :-(

[Mariano Absatz]

El 30 May 2001, a las 14:44, Hugh Irvine escribió:

> 
> 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.
Hugh, FYS (For Your Surprise :-)

A Nortel Shasta generates the following packet (names, IPs and passwords were 
scrambled to protect the inocent :-)


*** Received from 1.2.3.4 port 22334 ....
Code:       Access-Request
Identifier: 234
Authentic:  <0><0>Y<247><0><0><9><30><0><0>E<200><0><0>:S
Attributes:
        User-Name = "joe.d.user at somewhere"
        User-Password = "S<1>E<20>C<300>R<4>E<50><66>T<77><88>"
        Acct-Session-Id = "b500f5e8"
        NAS-IP-Address = 4.3.2.1
        Shasta-SGROUP = "Shasta 5000: iSOS (tm), 2.1-V(3)"
        Service-Type = Framed-User
        Framed-Protocol = PPP



As you can see, it's an Access-Request WITH an Acct-Session-Id... thankfully, 
since, as you can also see, it DOES NOT have NAS-Port or any other singular 
attribute.

I've been told that since software version 2.1, it can generate a NAS-Port-Id 
which has roughly the same semantics as a NAS-Port, but it's a string instead 
of a number.

Neale, 

if you are fiddling with the values of a couple of attributes to generate a 
unique attribute, it might be far easier to (in the context you describe) 
generate a NAS-Port-Id (RFC 2869, section 5.17, page 37) or, if all Access-
Request DO have an Acct-Session-Id (despite Hugh's surprise), use that.

In ANY case you are not using NAS-Port, be aware that you can't double-check 
Simultaneous-Use against the NAS if your SessionDatabase says it's exceeded. 
If you need to do this, take a look at the patch I sent a few days ago.

> 
> 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.


Mariano Absatz
El Baby
----------------------------------------------------------
Justify my text? I'm sorry but it has no excuse. 

===
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.