[RADIATOR] AuthRADSEC and radsecproxy are incompatible!

[Heikki Vatiainen]

On 07/18/2013 09:08 AM, Stefan Winter wrote:

>> in case of connection oriented RADSEC/TCP proxying, it's problem to
>> decide on client addresses and client ports, It's always the same peer
>> socket and 8 bits can be very soon to short on a heavy used proxy
>> connection.

Commenting on Charly's message here, I agree. Radiator enables exteded
IDs, using Proxy-State, for RadSec connections. It supports them for UDP
transport too.

>> RADSEC/TCP or RADIUS/TCP came after RFC-2865, maybe we should make
>> an RFC addendum, that Proxy-State MUST ALWAYS be replied, even in
>> Status-Server requests.

Yes that would be worth considering. If there are two proxies talking to
each other, why should the Proxy-State attribute suddenly be forbidden
for one message type? If a NAS adds Proxy-State, that may not be useful,
but proxy <--> proxy is a bit different.

Please see below for more why Radiator uses Proxy-State with RadSec.

>> Meanwhile we could/should add a config flag in radsecproxy to allow
>> this.
> 
> You only send Status-Server once in a long while, meaning you'll only
> have one packet in flight. You also send it only to servers from which
> you haven't heard from in a while, so the number of packet identifiers
> which are currently in use on the socket is always very near 0.

Sending is not the problem, mapping the responses back to outstanding
request is why Radiator uses Proxy-State :)

It would be much more robust if all responses could be looked up based
on the same method. Status-Server does not have its own response message
type, so an Access-Accept for Status-Server is very much in-band and can
not be identified as a management related message based on e.g., message
type.

> Independently of this, it remains a bit unclear to me why Radiator needs
> the extended-IDs in Proxy-State anyway; if you run out of packet IDs on
> a given src/dest port/ip combination: you can choose a new source port
> to send your request from there! There's plenty of source ports.

Radiator uses Proxy-State for RadSec where the TCP connection fixes the
source and destination address and port. Since RFC 2865 provides
Proxy-State, Radiator uses this for working around the 8 bit Identifier.

Also, there is no requirement by Radiator or by the RFC that the
Proxy-State is actually sent anywhere by the next hop. The only thing
the next hop proxy needs to do is to add the unmodified Proxy-State
value in the response. This means there is no extra burden for the
proxies further down in the chain since handling Proxy-State can be kept
a local thing between the two proxies.

If Proxy-State is dropped from Status-Server messages, Radiator could
consider the Access-Accepts without Proxy-State as responses to
Status-Server requests. This requires separate bookkeeping: one for
plain Status-Server Identifiers and the other for extended-ID
identifiers for the other message types.

As mentioned above: A thing to note about Status-Server is that their
responses are very much in-band. The response is an Access-Accept so
unfortunately it is not possible to catch them with e.g., based on their
own message type.

In summary: handling Status-Server responses without Proxy-State is
doable. It does complicate the code since more logic is needed to handle
the two cases: instead of just doing a lookup based on the received
Proxy-State for all responses to find the matching request,
Access-Accepts without Proxy-State need to be considered as
Status-Server responses with their own lookup.

Sending Status-Servers from their own source port or using a different
RadSec connection for them sort of defeats the purpose of figuring out
if the next hop is still reachable with the current communication
parameters (ports and addresses).

> The only reason why identifiers really could run out is if you've used
> up all your source ports * 256 identifiers for one single destination
> server. And if you are that busy, you don't need Status-Server :-)

Yes, that's true with UDP. For TCP, the idea is to use the other means
the RADIUS RFC provides.

For UDP extended identifier space can also be useful. For example, when
there are strict firewall rules that restrict what the source ports can be.

Thanks,
Heikki

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