So I'm running tcpdump on the freeradius server as it sends the radius packets out, and on the service's server as it receives them, also looking at the output of radiusd -X on the radius IdP to see what it thinks it's about to send, and the output of gss-server on the service to see what is received on the other end of our code.

Anything <=247 characters goes through fine. Anything > 247 characters disappears (as we knew).

However, our assumption that it was not traversing the network okay or disappearing in our code was wrong, it actually seems to disappear between what the output of radiusd -X shows (which shows me the SAML-AAA-Assertion split into chunks but with nothing missing) and the packets actually leaving the freeradius IdP box as I see in tcpdump, where anything beyond character 247 disappears. So the other end is receiving what was sent as would be expected.

In the radius packet trace leaving I'm seeing:

* an AVP of length 255, as you'd expect.

-> AVP: l=255  t=Vendor-Specific(26) v=UKERNA (United Kingdom Education and Research Networking(25622)

In the AVP are always 6 bytes (1a ff 00 00 64 16) at the start (Identifying the attribute?), followed by a VSA of length 249

-> VSA: l=249 t=Unknown-Attribute(132): 3c3f786d6c2076657273696f6e3d27312e302720656e636f…

The VSA seems to always have 2 bytes (84 f9) at the start (framing bytes or something?), leaving room for 247 bytes (chars) of content. 

Reducing the size of the chunks to less than 247 gives a corresponding reduction in the above (e.g. split every 237 characters gives an AVP l=245 containing VSA l=239).

So maybe someone more familiar with freeradius and/or RADIUS can explain this…?

Anyway, for now, simply making SAML fragments split at 247 characters seems to be the easiest way forward :-). Would be nice to know what's happening though, and whether this is expected behaviour or not...

R.