Re: Q: EAP retransmission & fragmentation
From: Mahesh Kelkar (mkelkarrocketmail.com)
Date: Wed, 8 Jun 2005 12:11:36 -0400 (EDT)
Arthur,

Thanks for the response. 
Please see inline [mvk]

Thanks
Mahesh

--- Artur Hecker <hecker [at] enst.fr> wrote:

> 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". 


[mvk] This is not clearly spelled out in any RFC. 

If both the EAP-server & EAP-authenticator share the
responsiblity of retransmition, who decides when to
retransmit? I mean, EAP-authenticator can start a timer
after forwarding the request packet and retransmit the
packet again on the timeout. So can EAP-server.

Packet could get lost in the paths EAP-server &
authenticator or authenticator & the peer. There is no way
EAP-server could know about it. If EAP-server is equiped
with the retransmissions, then I think there is no real
need for EAP-authenticator to get involved in the
retransmitions & duplicate detection.

Also, is it true that retransmission of the identity
request packet (that originates on the EAP-authenticator)
should have a different identifier. i.e. it should be a
retry not a retransmission?


>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."


[mvk] Thus, Radius Server and/or EAP-server (that resides
on the backend authentication server) MUST comply with the
default min EAP MTU of 1020 bytes or the FRAMED-MTU passed
in the Radius Access request. right?



+++++++++++++++++++++++++++++
 M a h e s h  V  K e l k a r


                
__________________________________ 
Yahoo! Mail 
Stay connected, organized, and protected. Take the tour: 
http://tour.mail.yahoo.com/mailtour.html 


Results generated by Tiger Technologies using MHonArc.