El 03/02/13 18:02, Alan DeKok escribió:
[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.
Why? I assumed they will ignore the MDP attribute, and generate a
Challenge if they understand the chunk as a valid Access-Request.
From RFC 2865
A RADIUS server MAY ignore Attributes with an unknown Type.
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.
What if the server wants to send a fragmented Challenge *before* sending
the Access-Accept? Then, it will send the More-Data-Pending attribute,
not the Service-Type = AddAuth. Again, the client may ignore the unknown
attribute and try to decode the chunk as a "regular" Access-Challenge.
Clients not
supporting fragmentation will not recognize the Service-Type, and under
RFC 2865 Section 5.6, treat it as Access-Reject.
That's true for Access-Accept, not for Access-Challenge packets.
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.
I agree with this.
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.
And also agree with this.
Alan DeKok.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
