eap Mailing List: Re: Issue 245: EAP Restart Issue

[Jari Arkko (jari.arkko]

I think you are right in worrying about undamped link down
indications. However, I think the current text is clear
enough. What is referred to as "lower layer failure indication"
is not to be taken as the "IEEE 802.11 unreliable indication
of failure". The text that you quoted already says that
damping is advisable; I read that that as meaning that in
the rest of the document, when it says "lower layer indiciation",
its already damped.

(But I confess that my interpretation may be biased by the
desire to get this RFC out.)

--Jari

Florent Bersani wrote:
> 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 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
> >
> >