[email protected] wrote: > In order to maintain deal with RADIUS clients and servers that do not > support fragmentation, it would be cleaner to use RADIUS capability > negotiations (draft-halwasia-radext-capability-negotiation) to negotiate > use of More-Data-Pending attribute. This would > allow all RADIUS messages to use More-Data-Pending attribute for > fragmentation with no exception.
The existence of a More-Data-Pending in an Access-Request indicates that the client supports fragmentation. Servers which do not understand that attribute will return an Access-Accept / Reject instead of an Access-Challenge. The client will realize that it has not sent all of the data it wants to send, and will terminate the users session. A server supporting fragmentation will start off by sending an Access-Accept with Service-Type = Additional-Authorization. Clients not supporting fragmentation will not recognize the Service-Type, and under RFC 2865 Section 5.6, treat it as Access-Reject. There is no need for capability negotiation here. If a client needs to send a lot of data, it either sends all of the data, or terminates the users session. If a server needs to send a lot of data, it either sends all of the data, or sends a Service-Type which causes the client to terminate the users session. It would be *nice* to know this prior to terminating the session. Simply rejecting the user unexpectedly is safe, but unfriendly. Any capability negotiation here is a user interface problem. It helps the user or administrator understand why a session was terminated. It doesn't help the RADIUS client or server. Alan DeKok. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
