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? 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: r...@um.es ------------------------------------------------------- _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab
