Hello, > Maybe someone can trigger the authors of radsecproxy too, to start > implementing Proxy-State RFC 2865 conform when *generating* responses. > Seems it makes everthing right on proxying but not on generating > packets.
Status-Server is defined in RFC5997. It uses a distinct command-code - it's not an Access-Request, it's Status-Server. So all the "rules" of an Access-Request and corresponding responses are not relevant. In particular, the attribute Proxy-State is not expected to be in there. See section 5 of that RFC. Adding to that, there is also no reason to use Proxy-State at all because Radiator does not act as proxy - it's acting as a simple RADIUS Client, sending an initial request to some other server. Proxy-State (in Access-Requests) only comes into play when a server *receives* a packet from downstream, then sees that it needs to be sent elsewhere still, and then *forwards* it. Only then does it add Proxy-State. None of this is true with Status-Server; and proxying Status-Server packets is prohibited in section 4.4 of that same RFC. If Radiator generates a Proxy-State (even though it is not acting as a proxy - so why would it do that?), then it's at fault itself. It should not have any expectations of getting it back unharmed. 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
