| Re: Q: EAP retransmission & fragmentation | <– Date –> <– Thread –> |
|
From: Mahesh Kelkar (mkelkar |
|
| 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
-
Q: EAP retransmission & fragmentation Mahesh Kelkar, June 7 2005
-
Re: Q: EAP retransmission & fragmentation Artur Hecker, June 8 2005
- Re: Q: EAP retransmission & fragmentation Mahesh Kelkar, June 8 2005
-
Re: Q: EAP retransmission & fragmentation Artur Hecker, June 8 2005
- Re: Q: EAP retransmission & fragmentation Bernard Aboba, June 9 2005
- Re: Q: EAP retransmission & fragmentation Mahesh Kelkar, June 17 2005
Results generated by Tiger Technologies using MHonArc.