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 <h...@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. _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator