El 09/03/12 05:55, Jim Schaad escribió:
-----Original Message-----
From: Alejandro Perez Mendez [mailto:[email protected]]
Sent: Monday, March 05, 2012 12:03 AM
To: Alan DeKok
Cc: Jim Schaad; [email protected]; [email protected]
Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-
radius-fragmentation-01.txt
El 04/03/12 08:10, Alan DeKok escribió:
Jim Schaad wrote:
I have some comments on the draft. However first let me say that I know
next to nothing about RADIX having only briefly read it a couple of times and
having not yet worked with it to any extent.
Reviews are always welcome.
1. I think a discussion is in order about the issues of packing a radius
message full in the presence of proxy intermediaries which might need room
for adding and removing routing materials. I don't know how many proxies
are keep local state as oppose to just filling up the message with Proxy-State
items and thus need space on the way back. Also a discussion of removal
and re-insertion of the T flag might be needed if the proxy fully assembles
the message and then relays it in pieces.
The simplest way to address that is to artificially lower the
RADIUS maximum packet size, as seen by the client.
Additionally, regarding the T flag removal/re-insertion comment, proxies are
not allowed to perform RADIUS fragmentation on forwarded packets. It is a
process performed end-to-end the RADIUS client and server.
What happens for proxies that, for some reason - want to re-write the contents
of packets. For ABFAB I am specifically thinking of changing or mapping
attributes in SAML assertions.
I don't think a RADIUS proxy should change anything at a SAML level, but
I may be wrong. Specially, if the assertion is singed by the IdP, that
would be impossible at it would invalidate the signature.
Anyway, other alternatives to deliver large authorization data, like
providing a URL where the RP can download the assertion later, have
exactly the same issue: proxies cannot modify the contents of the assertion.
Regards,
Alejandro
2. The Overview in section 2 does not discuss the fact that a new set of
state items might also added to the message. This changes the limit of how
many bytes can be placed into the fragmented packets.
Yes.
3. nit - in para #3 of overview you use the word truncated and truncation.
I think a better word set might be partitioned and partitioning. Also ensure
that fragmentation is used strictly for the process in radius-extensions. I
have not found any cases yet were it is not but will try and remember to
look.
4. I am not sure if positioning of the more-data-pending packet is
significant. The introduction says it comes last but nothing to that effect is
said in section 3.
5. Section 6 implies that the order of items in a set of fragmented packets
might need to be changed based on the ability of items to be in the packet.
For example if the Access-Accept packet had been = Data1[M],
Data2[M]...Data 10, User-Name, Service-Type[X], Framed-IP-Address the
order would need to be changed in the original partitioning. This should be
mentioned someplace other than just in the "examples" section. It implies
that a general use piece of code to do this will need to have the table built
in,
and potentially extended as new items are added, rather than just being
coded correctly in the specific packet type code.
Attribute ordering is explicitly *not* required in RADIUS.
6. What if any indications does a server have that the client will be able to
deal with the partitioned message other than it will either fail or get confused
depending on what set of attributes are in the first packet and what it needs
and feels it can ignore.
That's an open area for discussion. RADIUS doesn't have capability
negotiation, so it's hard to do.
Alan DeKok.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
