On Jul 17, 2013, at 8:58 AM, Karl Gaissmaier <karl.gaissma...@uni-ulm.de> wrote:
> Hello, > > Am 15.07.2013 10:07, schrieb Ralf Paffrath: > ... >> anyway it's a bit proprietary that Radiator ignores the correct identifier >> in an Access-Reject packet. >> >> The Identifier is also part of RFC2865: >> Identifier >> The Identifier field is one octet, and aids in matching requests >> and replies. The RADIUS server can detect a duplicate request if >> it has the same client source IP address and source UDP port and >> Identifier within a short span of time. > > 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. Meanwhile you can put a radsecproxy between your Radiator and let radsecproxy to handle all the request. If the request is local radsecproxy would forward your request to your Radiator. All other requests would be upstreamed. If you want to solve your problem with dead realm, voila. > > Best Regards > Charly > > -- > Karl Gaissmaier > Universität Ulm / Germany -- Verein zur Förderung eines Deutschen Forschungsnetzes e.V. Alexanderplatz 1, D - 10178 Berlin Tel.: 030 88 42 99 23 Fax: 030 88 42 99 70 http://www.dfn.de
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
