> -----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. > > > >> 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
