[RADIATOR] AuthRADSEC and radsecproxy are incompatible!

[Stefan Winter]

Hi,

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

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.

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 :-)

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
Url : http://www.open.com.au/pipermail/radiator/attachments/20130718/88ec257d/attachment.bin