| Re: Issue 245: EAP Restart Issue | <– Date –> <– Thread –> |
From: Florent Bersani (florent.bersani rd.francetelecom.fr)
|
|
| Date: Tue, 8 Jun 2004 06:18:04 -0400 (EDT) | |
Well,
I've got a fuzzy feeling about this issue, especially when I take a look at rfc3748.b.txt in section 7.12:
"In IEEE 802.11, a "link down" indication is an unreliable indication of link failure, since wireless signal strength can come and go and may be influenced by radio frequency interference generated by an attacker. To avoid unnecessary resets, it is advisable to damp these indications, rather than passing them directly to the EAP. Since EAP supports retransmission, it is robust against transient connectivity losses. "
Perhaps it's my unskilled understanding of the problem, but I find "indication of link failure" and "lower layer failure indication" quite confusing :-(
* If they refer to the same thing, then I find the proposed changed to resolve issue 245 contradictory to the RFC 3748 text quoted here above
* If not, I'd be more than happy to get some clarification :-)
Any suggestion?
Florent
P.S:
My two cents here is that there might be a confusion arising from "lower layer". Indeed, I guess when EAP is used for wireless LANs, lower layer could apply to two layers: the IEEE 802.11 layer and the IEEE 802.1X/11i layer. Stricto sensu, I think that in this case, lower layer should only refer to 802.1X. If this is the case, then the problem I am trying to consider reduces to know when 802.1X considers that it should restart due to its lower layer (i.e. 802.11) link failure. Depending on this decision, the RFC 3748 text quoted here above might become useless (i.e. since 802.1X could be damping the link failure indications, there would be no need to mandate that EAP do so - but I believe without any justification that this is not the case for 802.1X). I leave the debate on 802.1X/EAP to the group of well versed people in that matter (which I unfortunately do not -yet? - belong to :-()
However, the problem with this P.S is that it is too 802.1X centric (as much of EAP probably but this is another debate). There could be some cases in which EAP is run directly over a link layer and has no intermediate layer (like 802.1X) to do the possible damping. If this is the case, we really want to make sure that the "damping" mechanism used by EAP is really media independent and works as well with 802.1X as without. If 802.1X does no damping (which is probably the case), then this problem is easy. If it does, well?
Not sure I have been very clear here :-( Hope however this helps.
Henrik Levkowetz wrote:
I've got a fuzzy feeling about this issue, especially when I take a look at rfc3748.b.txt in section 7.12:
"In IEEE 802.11, a "link down" indication is an unreliable indication of link failure, since wireless signal strength can come and go and may be influenced by radio frequency interference generated by an attacker. To avoid unnecessary resets, it is advisable to damp these indications, rather than passing them directly to the EAP. Since EAP supports retransmission, it is robust against transient connectivity losses. "
Perhaps it's my unskilled understanding of the problem, but I find "indication of link failure" and "lower layer failure indication" quite confusing :-(
* If they refer to the same thing, then I find the proposed changed to resolve issue 245 contradictory to the RFC 3748 text quoted here above
* If not, I'd be more than happy to get some clarification :-)
Any suggestion?
Florent
P.S:
My two cents here is that there might be a confusion arising from "lower layer". Indeed, I guess when EAP is used for wireless LANs, lower layer could apply to two layers: the IEEE 802.11 layer and the IEEE 802.1X/11i layer. Stricto sensu, I think that in this case, lower layer should only refer to 802.1X. If this is the case, then the problem I am trying to consider reduces to know when 802.1X considers that it should restart due to its lower layer (i.e. 802.11) link failure. Depending on this decision, the RFC 3748 text quoted here above might become useless (i.e. since 802.1X could be damping the link failure indications, there would be no need to mandate that EAP do so - but I believe without any justification that this is not the case for 802.1X). I leave the debate on 802.1X/EAP to the group of well versed people in that matter (which I unfortunately do not -yet? - belong to :-()
However, the problem with this P.S is that it is too 802.1X centric (as much of EAP probably but this is another debate). There could be some cases in which EAP is run directly over a link layer and has no intermediate layer (like 802.1X) to do the possible damping. If this is the case, we really want to make sure that the "damping" mechanism used by EAP is really media independent and works as well with 802.1X as without. If 802.1X does no damping (which is probably the case), then this problem is easy. If it does, well?
Not sure I have been very clear here :-( Hope however this helps.
Henrik Levkowetz wrote:
I have included this change in the Auth. 48 corrected rfc3748 text - see 'rfc3748.b.txt' on http://ietf.levkowetz.com/drafts/eap/rfc2248bis/
Henrik
Sunday 6 June 2004, Jari Arkko wrote:
I think the suggested change is OK.
--Jari
Bernard Aboba wrote:
_______________________________________________In going over the discussion on Issue 241, John Vollbrecht made a suggestion for a change to RFC 3748 that I think corrects an oversight. As the document is now Author 48 hours, it is still possible to correct the problem if the WG approves.
-------------------------------------------------------------------------- Issue 245: EAP Restart Issue Submitter name: John Vollbrecht Submitter email address: jrv [at] umich.edu Date first submitted: 5/7/2004 Reference: http://mail.frascone.com/pipermail/eap/2004-May/002460.html Document: RFC2284bis-09 Comment type: T Priority: S Section: 4.1 Rationale/Explanation of issue:
Section 4.1 of RFC 3748 states:
"Additional Request packets MUST be sent until a valid Response packet is received, or an optional retry counter expires."
Where the lower layer terminates the initial session and causes a restart, if EAP knows that the lower layer is terminated then I am not sure why it would continue to resend.
Perhaps we should change this to:
"Additional Request packets MUST be sent until a valid Response packet is
received, an optional retry counter expires, or a lower layer failure
indication is received."
eap mailing list
eap [at] frascone.com
http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________ eap mailing list eap [at] frascone.com http://mail.frascone.com/mailman/listinfo/eap
-
Issue 245: EAP Restart Issue Bernard Aboba, June 6 2004
-
Re: Issue 245: EAP Restart Issue Jari Arkko, June 6 2004
-
Re: Issue 245: EAP Restart Issue Henrik Levkowetz, June 6 2004
- Re: Issue 245: EAP Restart Issue Florent Bersani, June 8 2004
- Re: Issue 245: EAP Restart Issue Jari Arkko, June 10 2004
-
Re: Issue 245: EAP Restart Issue Henrik Levkowetz, June 6 2004
-
Re: Issue 245: EAP Restart Issue Jari Arkko, June 6 2004
Results generated by Tiger Technologies using MHonArc.