Hi Alan,
Alejandro Perez Mendez wrote:
We propose the following:
1) Extended flag attributes are used to fragment big RADIUS attributes,
as specified in draft-ietf-radext-radius-extensions.
That should be possible.
2) If a fragmented attribute cannot be completely included into the
remaining space of a 4KB RADIUS packet, it is truncated, that is, only
the fragments that fit into the free space of the packet to be sent are
included. It is also included a new RADIUS attribute, called
"More-Data-Pending". The presence of this attribute indicates to the
receiver that the RADIUS packet is not complete, and more data MUST be
received from the sender before processing any of the received attributes.
I've had similar discussions with people off-list.
that's good
Note that it is possible (and very likely), that the last fragment of a
truncated attribute in a RADIUS packet has the M flag set. This case
would be against what it is stated in
draft-ietf-radext-radius-extensions. Nevertheless, we think this
restriction can be easily relaxed when using the more-data-pending
attribute. If it is present, it is allowed that the last fragment have
the bit M set, which means the attribute is truncated. A good side
effect of this is that if a server does not understand
more-data-pending and its semantics, a truncated attribute will be shown
as an invalid attribute, and not taking the truncated portion as the whole.
I'm wary of that, but it's a good start. There may be additional
minor fixes which could make the fragmentation explicit rather than
implicit.
We also thought that a new flag "T" could indicate the attribute is
truncated across several packets.
I think this proposal would require a new document at minimum. The
document would discuss how to implement the above proposal. That means
that others could use this specification, even if they don't need
attributes longer than 4K.
Indeed, this proposal is not only for attributes longer than 4K, but to
support that an attribute is fragmented across different packets,
because the total length of the packet is longer than 4K.
That could happen even when the attribute is not very long, but it is
placed at the end of the package.
A separate document could document the>4K attributes.
IMO support for attributes > 4K is a logic consequence of the
fragmentation support given by our proposal.
I'll see if I can write a short proposal to the radext list. If it's
acceptable to the WG, I can put a draft together.
Precisely we were about to modify our document to reflect this, if the
idea was reasonable. That was the intention of sending it first to the
list, to see if there were objections before starting writing a new draft.
Regards,
Alejandro
Alan DeKok.
_______________________________________________
radext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/radext
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
