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
