[RADIATOR] Issues with Tacacs/Radius and v6 conversion

[Heikki Vatiainen]

On 01/26/2011 03:07 PM, Patrik Forsberg wrote:

> I've recently tried to get a new radiator enviroment working with FreeBSD 8.1, Perl 5.10 and Radiator 4.7 with current patches.
> 
> Most stuff work as expected but I've ran into a small snag with my setup. I need to use a Handler to catch Calling-Station-Id but for some reason all Calling-Station-Id that end up in accounting and level 4 logs begin there ip with "::ffff:". The only IPs that exist on the machine are ipv4.
> For some reason the Calling-Station-Id field becomes to short to handle this and up with something like " ::ffff:111.11.1 " <-- this is the correct number of characters replaced with 1s to protect internal information.
> I've only been able to verify this issue with Tacacs so far.. maybe it's different with Radius calls.

Is this pure RADIUS or something that has been converted from TACACS+?

The ::ffff: prefix belongs to the "IPv4-Mapped IPv6 Address" format.
Socket interfaces can use this format to hand IPv4 addresses to
applications that only know about IPv6.

http://tools.ietf.org/html/rfc4291#section-2.5.5
RFC 4038 and
http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02 tell more.

You may have already known this, but I thought I'd mention it anyways.

> Only place I could find a reference to "::ffff:" is in Util.pm and that was just to figure out if a conversion function were handling a v4 or v6 address..

Yes, this is how Radiator extracts the IPv4 address from a mapped format
when the address looks like IPv6 but what is on the wire is really IPv4.
It is not the cause for the behaviour you report.

> The same issue appear in Level 4 trace with tacacs
> Example
> "
> Wed Jan 11 11:12:13 2011: DEBUG: TacacsplusConnection Authorization REQUEST 6, 15, 1, 1, scrambled, telnet111, ::ffff:111.11.1, 2, service=shell cmd=
> "
> 
> So I'm guessing it has to do with Tacacs not radius ?

Well, it depends :)

This line indicates that the mapped address had been packed in the
incoming Tacacs request that is just being handled. So it looks like
some entity is creating Tacacs requests that contain IPv4-Mapped IPv6
Addresses.

Can you describe your setup and environment a little better. What device
is creating Tacacs messages, please post your configuration (no secrets)
and more complete log entries that show how messages are handled,
especially those that contain the ::ffff: prefix.

> Anyone else seen this or have it working somewhere that doesn't show this ?
> 
> Perhaps a fix ?

A fix might involve checking AI_V4MAPPED related socket options, as
specified by RFC 3493, but if you could provide more information abouth
e.g., the Tacacs message sender, that would help to tell if the fix is
needed by Radiator or something else.

Socket interfaces have implementation specific differences and this is
one of those "interesting" areas :)

So please tell us more, your configuration, log snippet and general
setup would be very useful.

-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.