eap Mailing List: RE: Question on EAP statemachine

[Mahesh Kelkar (mkelkar]

Pasi,

L2tp is unawre of EAP and merely forwards the PPP frames
from LAC to LNS. LAC & LNS are the terms used for the APs
in the context of L2tp protocol. 

If for some reason, we MUST not allow the back to back EAP
protocol/method negotiations, then following discussion it
out of question. I am just wanted to find out if its
conceivable.

In the peer statemachine on page 8 of the pdf version of
the draft: 

on the receipt of the EAP request there are several
condition checks. The couple of conditions are as follows

Condition 1:-
rxReq &&
(reqId != lastId) &&
(selectedMethod == None) &&
(reqMethod != IDENTITY) &&
(reqMethod != NOTIFICATION)

Condition 2:-
rxReq &&
(reqId != lastId) &&
(selectedMethod == None) &&
(reqMethod == IDENTITY)

These 2 conditions prohibit the back to back negotiation of
the EAP protocol/auth methods. If we want to allow the back
to back negotiations then perhaps we should remove the
(Selected == None) checks from these two conditions or add
two more conditions as follows

Condition 1A:-
rxReq &&
(reqId != lastId) &&
(selectedMethod != None) &&
(methodState == Done) &&
(reqMethod != IDENTITY) &&
(reqMethod != NOTIFICATION) &&

Condition 1A allows the EAP negotiation (by allocMethod) on
the receipt of EAP request/auth method (this auth method
could be different) only if current negotiation is
finished.

Condition 2A:-
rxReq &&
(reqId != lastId) &&
(selectedMethod != None) &&
(methodState == Done) &&
(reqMethod == IDENTITY)

Condition 2A is optional because it could help us avoid an
extra user interaction. But this condition would allow the
peer to respond to the EAP request/Identity received after
the conclusion of the  earlier EAP negitiation.

Any successive authentication failure MUST result into a
failure.

During the back to back EAP protocol/method negotiation
eapRestart & potEnabled flags remain UP. i.e the intial
negotiation was intiated by the lower layer. But lower
layer should be unaware of the any successive negotiations.


Thanks
Mahesh


--- Pasi.Eronen [at] nokia.com wrote:

> Mahesh,
> 
> I'm not very familiar with L2TP, but I thought the LAC 
> is "below the PPP layer" (simply forwards PPP frames 
> to the LNS), and thus it does not know anything about
> EAP?
> 
> But anyway, determining when a new EAP conversation
> starts
> is done outside the peer state machine. If the lower
> layer
> can do it, then the state machine supports it (but the
> lower layer is then responsible for describing how the
> results of the two EAP conversations should be combined).
> 
> Best regards,
> Pasi
> 
> > -----Original Message-----
> > From: ext Mahesh Kelkar [mailto:mkelkar [at] rocketmail.com]
> > Sent: Wednesday, June 29, 2005 5:27 PM
> > To: Eronen Pasi (Nokia-NRC/Helsinki); eap [at] frascone.com
> > Subject: RE: Question on EAP statemachine
> > 
> > 
> > Pasi,
> > 
> > This particular example refers to the L2tp setup as
> > described below
> > 
> >  Peer         LAC               LNS
> >   |---- PPP----|                  |             
> >   |            |                  |
> >   |            |---- PPP/L2TP ----|
> >   |            |                  |
> >   |            |<--L2TP Tunnel--->|
> >   |                               |
> >   |<---------PPP Session--------->|
> >   |                               |
> > 
> > The peer first negotiates PPP-LCP with the LAC; then
> LAC
> > negotiates the EAP with the Peer (or acts as a
> paas-thru);
> > As an outcome of the successful authentication, the LAC
> > tunnels PPP session to the LNS; and now LNS starts
> > negotiating the EAP with the peer;
> > 
> > Thus, in this case, the peer negotiates EAP/EAP method
> with
> > the LAC; receives the EAP-success followed by the EAP
> > request/Identity (or EAP request/auth method) from the
> LNS.
> > 
> > I don't think lower layer would initate the multiple
> > conversations. The peer has a point to point lower
> layer,
> > hence it would not be able to distinguish if the
> incoming
> > EAP packets are coming from the LAC or LNS. Hence  I
> was
> > wondering if the statemachine is equiped to handle such
> a
> > back to back EAP/EAP method negotiations?
> > 
> > Thanks
> > Mahesh
> > 
> > --- Pasi.Eronen [at] nokia.com wrote:
> > 
> > > 
> > > Mahesh,
> > > 
> > > Negotiating the use of EAP and triggering the start
> of an
> > > EAP conversation happens in the lower layer outside
> EAP, 
> > > so it's really beyond the scope of the peer state
> machine.
> > > 
> > > But I don't think there's anything in draft-ietf-eap-
> > > statemachine that would prevent a lower layer from
> having 
> > > several separate EAP conversations, either in
> sequence 
> > > like (in PANA), or in parallel in which case you need
> 
> > > multiple "instances" of the state machine).
> > > 
> > > Best regards,
> > > Pasi
> <snip>
> 


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


                
____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com