It's quite late and I'm aware that my explanation may not have been too coherent, so I've drawn a picture to explain better.

https://docs.google.com/spreadsheet/ccc?key=0AtYhgwwLC5sqdHNUbmhwOFRPTjF5SnRVWmVPU1plZkE

Adam Bishop
JANET(UK)

On 31 Oct 2011, at 22:36, Adam Bishop wrote:

> It seems the two extra bytes indicate an additional type and length?
> 
> F9 = 249
> 84 = 132 = SAML-AAA-Assertion in dictionary.ukerna
> 
> 249 being the length that the RADIUS server tried to set the string to?
> 
> Adam Bishop
> JANET(UK)
> 
> On 31 Oct 2011, at 22:23, Adam Bishop wrote:
> 
>> Mystery solved.
>> 
>> The two static bytes triggered something in the back of my mind from the RADIUS rfc - when using an attribute of type string or text, the maximum length is 253 octets, not 255.
>> 
>> Though, I can't remember what the extra 2 bytes mean... possibly just "I AM STRING"
>> 
>> So, terminating each attribute at 247 is the correct behaviour.
>> 
>> 
>> string    1-253 octets containing binary data (values 0 through
>>               255 decimal, inclusive).  Strings of length zero (0)
>>               MUST NOT be sent; omit the entire attribute instead.
>> 
>> 
>> Adam Bishop
>> JANET(UK)
>> 
>> On 31 Oct 2011, at 21:55, Rhys Smith wrote:
>> 
>> Actually, it's turning out to be a bit slightly different than I thought.
>> 
>> First of all - caveat emptor - I think I'm doing all of this right, but I don't normally operate at the packet level end of things, so i'm not 100% sure of this!
>> 
>> 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.
>> --
>> Dr Rhys Smith: Identity, Access, and Middleware Specialist
>> Cardiff University & JANET(UK)
>> 
>> email: [log in to unmask]<mailto:[log in to unmask]> / [log in to unmask]<mailto:[log in to unmask]>
>> GPG: 0xDE2F024C
>> 
>> On 31 Oct 2011, at 13:12, Sam Hartman wrote:
>> 
>> Yeah, the 254 vs 253 thing is annoying and we also ran into that in
>> Moonshot's mech_eap.  However this is something different and probably a
>> bug in our code (assuming things travel through the network OK, which I
>> believe Rhys is confirming).
>> 
>> --Sam
>> 
>> 
>> 
>> JANET(UK) is a trading name of The JNT Association, a company limited
>> by guarantee which is registered in England under No. 2881024 
>> and whose Registered Office is at Lumen House, Library Avenue,
>> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG
> 


JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG