*3.2.1. EAP-CRA message and process details*

The proposed EAP-CRA packet is depicted in Table 2. The reasons for designing each of the fields are illustrated based on the associated requirements. The fields are transmitted from left to right. The first influencing factor of EAP-CRA is that it is based on the EAP protocol. Therefore, the fields, code, identifier and length are inherited from an EAP structure. The explanation of each field is listed below.

parameter which needs to be determined. The exact number for the time and trials will be decided in the actual implementation and depends on the protocol process time, line traffic and other unforeseen factors. One of the issues present in retry is the duplicate packets which must be handled by the receiving peer. Three retries will be performed, forming the base

EAP-CRA for WiMAX, WLAN and 4G LTE Interoperability

http://dx.doi.org/10.5772/54837

115

**Fragmentation**: EAP-CRA message may span multiple EAP-packets due to the multiple public and private key encryptions; hence there must be a method, to be engineered in the servers, for handling the fragmentation. As a base for work on the fragmentation, the length of the TLS record can be up to 16384 octets, while the TLS message may be 16 MB if it carries the PKI certificate of a server. However, to protect against denial of service attacks and reassembly lockup there must be maximum size set for the group of the fragmented messages. An example can be seen in what was implemented for EAP-TLS[19]. The exact numbers will be determined during implementation of the protocol, and will reveal the average length of long EAP-CRA messages. For the purposes of initial configuration, this number can be borrowed from EAP-

Since EAP is an uncomplicated ACK-NAK protocol, fragmentation support can be provided according to a relatively simple process. Damage or loss of fragments during transit is an inevitable risk for any communication. In EAP, these fragments will be retransmitted, and because sequencing information is included in EAP's identifier field, a fragment offset field

EAP-CRA fragmentation support will be provided by adding flag fields to the EAP-CRA packets inside the EAP-Response and EAP-Request. Flags include the Length (L), More fragments (M), and Start (S) bits. The L flag indicates the presence of the four octet Message Length field. It *must* be set in the first piece of a fragmented EAP-CRA message or set of messages. The M flag will be set in all except the last fragment showing that there are more frames to follow. The S flag will only be for the EAP-CRA start message sent from the EAP server to the peer. The T flag refers to the source type of the EAP-CRA message; whether it is coming from an 802.1x authenticator or from an authentication server. If there is a fragmented message, both server and the other peer must acknowledge the receipt of a packet with the flag set to M. The response can be an empty message to the other peer showing that the message

For our experiments we setup three different scenarios to compare the time taken to authen‐ ticate a user. Edu-roaming, EAP-CRA and direct authentication with a single RADIUS authentication server were considered. RADIUS servers were installed on Windows 2003

Microsoft Internet Authentication Service (IAS) with Microsoft EAP-PEAP was used in these experiments. IAS is the Microsoft implementation of a Remote Authentication Dial-In User Service (RADIUS) server and proxy in Windows Server 2003. As a RADIUS server, IAS performs centralized connection authentication, authorization and accounting for many types

Server standard edition and all platforms had 2 GB RAM and 2GHz dual core CPU.

configuration for the EAP-CRA.

TLS which is 64 KB.

has not been received.

**3.3. Experiments**

like that of IPv4 is not necessary.


**Table 2.** CRA Packet

The Code field is one octet and identifies the type of EAP packet. EAP Codes are assigned as 1 for Request, 2 for Response, 3 for Success and 4 for Failure. The Identifier field is one octet and aids in matching responses with requests. The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception. The Flags field includes the following fields:


L = Length included, M = More fragments, S = EAP-CRA start, R = Reserved, T = Source Type

**Table 3.** Add Caption
