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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
