Subject: [eap] RE: Question on EAP statemachine

From: <[email-masked]>
Date: Wed, 29 Jun 2005 17:53:23 +0300

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:[email-masked]]
> Sent: Wednesday, June 29, 2005 5:27 PM
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> 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
> 
> --- [email-masked] 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>
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Mahesh Kelkar <[email-masked]>
Date: Wed, 29 Jun 2005 08:37:43 -0700 (PDT)

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

> > > multiple "instances" of the state machine).

+++++++++++++++++++++++++++++
 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
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap