eap Mailing List: Re: Q: EAP retransmission & fragmentation

[Artur Hecker (hecker]

hi



group, please correct me if i'm wrong:

to Question 1:

i think that depending on what is lost and where, both cases can occur. 
EAP-server is responsible for the EAP method, the authenticator is 
responsible for the EAP "channel". please remember that the EAP method 
is NOT implemented on the authenticator. i would generally suppose that 
a retry is something different than a retransmit. retransmit is a 
reissue of the same packet, whereas retry might imply semantic changes 
to the packet body (increase counters, etc). the latter case can 
impossibly be treated by the authenticator/AP. even if the EAP/TLS 
document does not really describe this case, some EAP methods might 
depend on critical, method-specific timeouts etc. finally, packets might 
be lost between the server and the authenticator. the authenticator will 
only retransmit the EAP packets on the link, according to its EAP state 
machine.

you can perhaps look at it as at layering. the authenticator builds the 
EAP channel, but the EAP server builds the EAP method semantics. i.e. it 
is comparable to the second layer managing retransmissions and e.g. TCP 
managing retransmissions.


to Question 2:

as already said, the AP will not be able to fragment the EAP packet 
according to the EAP method because it does not implement the EAP 
method. citing RFC3748 "fragmentation is not supported within EAP 
itself; however, individual EAP methods may support this."


regards
artur



> Question 1) Who is supposed to retransmit the EAP packets?
> EAP-server or AP? 
> - According to RFC2716 EAP-server should retransmit the EAP
> packets (section 3.2 - Retry Behavior - "As with other EAP
> protocols, the EAP server is responsible for retry
> behavior")
> - According to RFC3748 AP should retransmit the EAP packets
> (4.1 - Request and Response - "Implementation Note: The
> authenticator is responsible for retransmitting Request
> messages.  If the Request message is obtained from
> elsewhere (such as from a backend authentication server),
> then the authenticator will need to save a copy of the
> Request in order to accomplish this.")
> - According to RFC 3579, AP should retransmit the EAP
> packets (2.3 - Retransmission - As noted in [RFC2284], if
> an EAP packet is lost in transit between the authenticating
> peer and the NAS (or vice versa), the NAS will retransmit)
>
> Which one is true? 
> I think it is very unnatural for AP to retransmit the
> packets. Because it is acting as a pass-though and
> shouldn't be involved in caching the packets & keeping
> track of it.
>
> Question 2)
> Normally, EAP-server is instructed to fragment the
> EAP-packets to the size of FRAMED-MTU (transmitted in the
> Radius Access request). Lets say if we have an EAP-server
> or Radius Server that does not comply with this and
> fragments the packet to the size more than the link MTU
> between AP & the peer. 
>
> Now, AP will have to fragment the EAP packet using the
> fragmentation specified by the authentication method (TLS
> in this case). And each fragment will require a unique
> identifier.
>  
> In this case how do we manage the identification fields of
> the EAP packets? Because if we don't then EAP-response from
> peer, reassembled at the AP, will definitely have a
> different id than the original id of the EAP request
> packet.
>
> Also, can we fragment the EAP-TLS fragment in order to fit
> it within the link MTU?