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