Thanks Damjan, I was very curious as to what it worked out to,
Ric

Damic, Damjan wrote, around 6/11/07 10:22 PM:
Hello Ric,

Few details on EAP-SIM length below...

From: Richard Pruss <[EMAIL PROTECTED]>
Subject: Re: [Int-area] DCHP-based authentication for DSL?
To: "'Internet Area'" <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"

I felt some deeper analysis on fragmentation seemed necessary after volume of emails on the topic.

A couple of emails lay out the basics of the matter:
http://www1.ietf.org/mail-archive/web/int-area/current/msg01110.html
http://www1.ietf.org/mail-archive/web/int-area/current/msg01116.html
http://www1.ietf.org/mail-archive/web/int-area/current/msg01121.html
http://www1.ietf.org/mail-archive/web/int-area/current/msg01124.html


<snip>

P.S. Also on a simple practical note but kind of off topic, I had a look at EAPOL traces for the various methods nothing and in the sample I saw nothing was near 500 bytes in length from the ones that do not support fragmentation. The main two that are of a concern that do not support fragmentation today are EAP-SIM and EAP-AKA, how large do these actually get, in practice, I understand new messages could expact EAP-SIM but what is it today?

I've found some EAP-SIM traces we made few years back, hope the
information might be useful.
In our case the overall EAP frame size varied around 100 bytes, bit more
for some specific messages. The longest message in the sequence was the
EAP-Request SIM Challenge when containing AT_RAND (20-84 bytes), AT_MAC
(20), and optionally AT_ENCR_DATA and AT_IV (20). But, altogether it
wasn't more than 200 bytes (<< 500) in any occurence.

Regards,
Damjan





_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area

Reply via email to