Hi Alan, all,
we have been thinking on this topic and we realized that a different
approach could be more convenient to handle inter-packet fragmentation
than our first proposal.
Taking draft-ietf-radext-radius-extensions as a base, we can assume that
intra-packet fragmentation is already handled via the M flag. We can
also assume that order between fragments is preserved when following
draft-ietf-radext-radius-extensions. This may not be true now with the
current spec (as Peter pointed out), but we can assume this will be
solved somehow in the future (e.g. including offset field).
We propose the following:
1) Extended flag attributes are used to fragment big RADIUS attributes,
as specified in draft-ietf-radext-radius-extensions.
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.
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.
The rest of the attribute fragments will be sent in successive packets,
following the same procedure, using as many RADIUS packets as needed to
transmit the required information.
Let me illustrate this with an example, where a RADIUS client sends a
packet with a size > 4 KB (to make it simpler, we assume each RADIUS
packet can include 8 RADIUS attributes/fragments, instead of using
bytes). Flag M is indicated as [M]. Data1, Data2, Data3... indicate
successive fragments of the attribute Data.
The RADIUS client wants to send the following RADIUS packet:
Access-Request = User-Name, Calling-Station-Id, Data1[M], Data2[M],
Data3[M], Data4[M], Data5[M], Data6[M], Data7[M], Data8[M], Data9[M],
Data10, Other1[M], Other2[M], Other3
As only 8 attributes can be included in the packet, the RADIUS client
truncates "Data" to fit into the packet, and includes the
More-Data-Pending attribute:
Acess-Request1 = User-Name, Calling-Station-Id, Data1[M], Data2[M],
Data3[M], Data4[M], Data5[M], More-Data-Pending
When the server receives the RADIUS packet containing the
More-Data-Pending attribute, the processing of the packet is left until
all the pending data is received. The pending data is requested by means
of an Access-Challenge packet, using the State attribute to tie together
this response with the subsequent request from the client.
Access-Challenge1 = State1
The client continues sending the data until another RADIUS packet is
completed, including again the attribute More-Data-Pending
Acess-Request2 = State1, Data6[M], Data7[M], Data8[M], Data9[M], Data10,
Other1[M], More-Data-Pending
The server stores the attributes into the state associated to State1 and
replies:
Access-Challenge1 = State2
Finally, the client sends the last fragments of the original packet:
Access-Request3 = State2, Other2[M], Other3
The server now can process the totality of the received attributes as if
they all had been received into a single RADIUS packet of more than 4 KB
The case where the server sends a fragmented packet to the client is
very similar and makes no sense to expli
Best regards,
Alejandro
El 09/01/12 12:20, Alejandro Perez Mendez escribió:
Hi Alan,
thanks for the clarifications and hints. We will think about them and
their implications, and try to modify the proposal to make it address
all the requirements.
Regards,
Alejandro
El 09/01/12 10:58, Alan DeKok escribió:
DIEGO LOPEZ GARCIA wrote:
Ordering constraints here are applied to related attributes.
RADIUS doesn't work that way.
There are hundreds of thousands of deployments which assume that
ordering constraints do NOT apply to related attributes. Changing such
a fundamental part of the protocol is impossible.
I don't see why this would go beyond the requirements imposed by the
current document on extended attributes, as the recent discussion on
it shows.
I pointed you to RFC 2865, and explained why that restriction is
impossible. Please go read those messages again.
It relies in the usage of an specific attribute that defines the
interpretation of the values of another attribute. Ordering rules
probably could be relaxed, but at the price of more complicated
processing rules.
It relies on behavior which is mandated as NOT being part of RADIUS.
I gave comments on your approach. Do you have any comments on my
proposed alternative? It would seem to (a) solve the same problem,
and
(b) have none of the limitations.
One of the main goals of the proposal was to be compatible with
current mechanisms for attribute encoding inside the packet
(EAP-style, extended attributes…) and deal only with values spanning
more than one packet. Using your alternative would break this
compatibility.
Nonsense.
It is incompatible with existing methods like EAP-Message. Those
*already* have semantics defined. Changing them by adding a "Chunked
Attribute" is impossible. The extended format hasn't been deployed, so
compatibility with it is impossible.
My proposal was to allow *new* attributes to span multiple packets.
Changing the rules on attribute ordering is impossible. Don't
even try.
Changing the meaning of existing attributes to allow more than 253
octets of data is impossible. Don't even try.
Alan DeKok.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
