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
