Hi Alejandro, 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.
Yoshihiro Ohba From: [email protected] [mailto:[email protected]] On Behalf Of Alejandro Perez Mendez Sent: Wednesday, January 30, 2013 5:46 PM To: [email protected] Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.txt Hello Yoshi, Rafa, see some comments inline: Dear all, we have received additional comments from Yoshihiro Ohba (many thanks) that we share with you. Please, see some comments inline. "Here is my review of draft-perez-radext-radius-fragmentation-04. Section 1: "Each RADIUS packet can transport several RADIUS attributes, to convey the necessary information to the other peer, up to a maximum size of 4 KB of total data (including RADIUS packet headers)." [YO] I suggest to replace "4 KB" with "4096 bytes" throughout the document since "KB" can mean 4000 bytes in some cases. [Rafa] OK. "A reference-based mechanism is also proposed in [RFC6158], where attributes can be obtained through an out-of-band protocol." [YO} Meaning of this sentence is unclear. Does this mean RADIUS attributes are obtained through some other protocol instead of RADIUS? Or does this mean the actual format of the Value field of a RADIUS Attribute is defined in other protocol specification? In the latter case, it should be also mentioned that RADIUS-EAP is categorized as the mechanism defined in RFC 6158. [Rafa] It is referring the value of the attributes can be obtained by other protocol instead of RADIUS. This is coming from a previous comment related with SAML transport. Instead of transporting the real SAML messages an URL is set as attribute value. We can try to clarify a little bit more. "However, there are no proposals to deal with fragmentation at a packet level, when the total size exceeds the 4 KB limit imposed by the RADIUS specification." [YO] Meaning of "at a packet level" is unclear. Suggested change: "However, there are no proposals to fragement a large-sized RADIUS packet into multiple small-sized RADIUS packets, where the length of the original (unfragmented) RADIUS packet exceeds the 4096-octet limit imposed by the RADIUS specification." [Rafa] This sounds good. Section 2: [YO] I am not sure if "T" flag is needed. In other words, it should be possible to change [I-D.ietf-radext-radius-extensions] to simply allow a fragment with the M-flag cleared not to be included in a non-last chunk. [Rafa] Yes, that may be possible. It is worth noting that we wanted to keep unmodified any existing I-D by the time being. Moreover, [I-D.ietf-radext-radius-extensions] has not considered that fragmentation at packet level may occur for obvious reasons. Moreover, that I-D is in a mature state now. In any case, we may ask authors of [I-D.ietf-radext-radius-extensions]. Section 3.3: [YO] Access-Accept fragmentation scheme looks odd compared to Access-Request and Access-Challenge fragmentation schemes. There are several questions related to this: (1) Why multiple chunks of Access-Accept cannot be sent without having an Access-Challange to be sent in between? (2) Why an Access-Accept cannot contain a More-Data-Pending attribute instead of using a new service type value? (3) How can a large attributue that is allowed to appear in an Access-Accept but not allowed to appear in Access-Challenge be fragmented? [Rafa] 1) We wanted to be symmetric in the design, where Access-Request/Access-Challenge exchange is used somehow for fragmentation support. In any case, we have also considered the usage of Access-Accept with Service-Type[AddAuth] so until all the attributes in the whole RADIUS Access-Accept are finally sent the exchange will be Access-Request/Access-Accept (Service-Type[AddAuth]), while the last one is simply Access-Request/Access-Accept. This mode of operation would solve your question 3). 2) I think that may be also possible. In any case, I think Alan or Alex can elaborate a little bit a more about the usage of Service-Type[AddAuth]. 3) Precisely, trying to answer this question we just came up with the solution in 1). What do you think? This alternative sounds good to me. However, I think there may be still some advantages of using Service-Type instead of (or in addition to) More-Data-Pending for Access-Accept packets. If the NAS/RP does not know anything about fragmentation (i.e. does not support this draft), it may take the first Access-Accept chunk, ignore the More-Data-Pending attribute (it is unknown for it), and process it as a complete packet. As no additional round-trip is mandatory after an Access-Accept packet, it may be problematic as it is possible that part of the obligations from the AS to the NAS (e.g. FW policies) are not enforced. However, RFC 2865 says that (in relation to Access-Accept packets): A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an Access-Reject had been received instead Therefore, if the NAS does not understand Service-Type=AdditionalAuthorization, the Access-Accept packet will be interpreted as an Access-Reject one, which seems to be the most reasonable approach. This sort of problems seem to not be critical with Access-Challenge packets, as the NAS is expected to generate a new Access-Request packet afterwards, and the AS can detect whether fragmentation was supported. Regards, Alejandro Section 8: [YO] Security Considerations section is too short. Security mechansims that are needed for secure operation of the proposed fragmentation mechanism needs to be described in this section. [Rafa] Yes this section will be improved. Jim also raised comments about it. Section 9: [YO] I don't think the following statement is true: "This document has no actions for IANA." because Section 6 defines new attributes. [Rafa] Correct. This needs to be fixed. Best Regards, Yoshihiro Ohba " Best regards. ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: [email protected]<mailto:[email protected]> ------------------------------------------------------- _______________________________________________ radext mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/radext
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
