Subject: Re: [radext] [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt

From: Alan DeKok <[email-masked]>
Date: Sun, 04 Mar 2012 08:10:04 +0100

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.

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

---

From: Alan DeKok <[email-masked]>
Date: Sun, 04 Mar 2012 08:10:04 +0100

Yes.

  Alan DeKok.
_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 05 Mar 2012 09:02:33 +0100

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

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 05 Mar 2012 09:02:33 +0100

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 3 Mar 2012 13:47:06 -0800

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 3 Mar 2012 13:47:06 -0800

---

From: Alan DeKok <[email-masked]>
Date: Fri, 09 Mar 2012 09:15:30 +0100

Jim Schaad wrote:
> Would this also be a way to deal with restrictions on the size seen by the
> server?  I.e. you also need to make the server deal with smaller packets as
> well.

  Yes.  Servers already do this for EAP authentication.  If they see a
Framed-MTU, they ensure that the EAP packet will fit into that MTU.
This gives a secondary result that the size of the RADIUS packet is limited.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 09 Mar 2012 09:15:30 +0100

Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 09 Mar 2012 12:56:01 +0100

El 09/03/12 05:55, Jim Schaad escribió:
>
>> -----Original Message-----
>> From: Alejandro Perez Mendez [mailto:[email-masked]]
>> Sent: Monday, March 05, 2012 12:03 AM
>> To: Alan DeKok
>> Cc: Jim Schaad; [email-masked]; [email-masked]
>> Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-
>> radius-fragmentation-01.txt
>>
>>
>>
>>>> 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.
>>>> 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.
>>>> 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.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 09 Mar 2012 12:56:01 +0100

Regards,
Alejandro