(RADIATOR) proxy impersonating many NASen :-(

[Neale Banks]

G'day Hugh,

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

Packet dumps coming separately.  I agree that rewriting the NAS-IP-Address
is just "not Cricket" - and rewriting them all to the same value isn't
even Ice Hockey ;-)

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

Yes.  Looking a bit further under the hood at the Radiator (yes, pun
intended ;-) I see that it's actually "$nas_id:$nas_port" that must be
unique and that Radius.pm first tries NAS-IP-Address then NAS-Identifer
when determining $nas_id - fine but for this bit of Radius.pm:

            # Theres no Nas-IP-Address, so try for NAS-Identifier
            my $nas_id = $self->getAttrByNum
                ($Radius::Radius::NAS_IDENTIFIER);
            if ($nas_id =~ /(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/)
            {
                $self->{CachedAttrs}{NasId} = $1;
            }

Not being a perl programmer, I struggle - but that does look mightily like
as if NAS-Identifier will only get into $nas_id if NAS-Identifier looks
like an IP Address in dotted-quad format.  But RFC2865 defines
NAS-Identifer as a string, so it can legitimately take almost any form.
What have I missed?

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

Agreed.  And as I can't find anything unique-to-NAS in the packet, that
leaves manipulation.

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

What a fiendishly clever idea!  Unfortunately there's no convenient SQL
repository right now - but I'll definitely keep that one in mind.

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

No, the Access-Request does include Acct-Session-Id (according to the
RFC2866 it MAY do this: "An Access-Request packet MAY have an
Acct-Session-Id; if it does, then the NAS MUST use the same
Acct-Session-Id in the Accounting- Request packets for that session" -
hopefully it's only an oversight that that last MUST is not currently
being complied with).

I think this whole problem would go away if:

* the proxy did NOT send NAS-IP-Address at all (or we strip it out), and
* the proxy sent NAS-Identifier (with a suitable per-NAS value, or we
  construct this Attribute with a suitable value), and
* Radiator was happy with the format of the NAS-Identifier.

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