*3.2.2. Two kinds of RADIUS packets in EAP-CRA*

In EAP-CRA, RADIUS packets are divided into two categories, based on their content. The first category includes those messages sent from an access point to the foreign server and the sec‐ ond type is those exchanged between a Home and Foreign server. In the first scenario, the sup‐ plicant encrypts the EAP-CRA message using the Home server public key and sends it to the foreign server. Between the home server and the client, the authenticator encapsulates the mes‐ sage inside a RADIUS packet and sends it to the foreign server. On the other hand, when the two servers are in communication with each other they sign the EAP-CRA message first using their own private key and then by encrypting the message using the other server's public key. Therefore, the content of the RADIUS packets differ depending on whether they are received from an authenticator or from an authentication server. The field T in the fragmentation field is for source type of the packet. If the packet is from or is sent to an authenticator then the value will be set to 0. Otherwise, if the source is a server, then the value will be set to 1.

**Retry behavior**: It is possible during peer communication that a response will not occur within the expected time. In which case, there must be a way to specify how many messages will be sent to make sure that another peer is not present. The time to resend the message is another 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 configuration for the EAP-CRA.

**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-TLS which is 64 KB.

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 like that of IPv4 is not necessary.

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 has not been received.
