eap Mailing List: Re: Questions for draft-barany-eap-gee-01

[Alper Yegin (alper.yegin]

This is starting to look more like a solution looking for a problem. Earlier
Lakshminath was asking if the EAP-GEE functionality could ever be done any
other way. Now that the obvious answer is "yes", authors are saying EAP-GEE
is good for doing it generically.

Parallel EAP execution is just one of the possible features a given EAP
lower layer can implement. I still don't understand why we need to carve
that out of the EAP lower layer and spin a whole new layer and protocol for
it. Those EAP lower layers that care about this feature are only one
"session id" definition away from achieving that, if not done already.

Alper



> -----Original Message-----
> From: Narayanan, Vidya [mailto:vidyan [at] qualcomm.com]
> Sent: Friday, June 16, 2006 11:58 AM
> To: Alper Yegin; Dondeti, Lakshminath; Quinn Li; Cao Zhen
> Cc: eap [at] frascone.com
> Subject: RE: [eap] Questions for draft-barany-eap-gee-01
> 
> Alper,
> It is not a question of whether this functionality can or cannot be put
> into the lower layer - of course, it can be done. But, the functionality
> can be provided in a generic enough way that there is no reason it
> should be done at each lower layer separately. And, I don't believe that
> EAP doesn't have extra fields by "design" - EAP was originally defined
> for PPP and it has been generically extended to work on other layers
> since - so, we live with what has been designed already!
> 
> We can have this argument of whether supporting this in the lower layer
> or a "shim" like GEE is the right approach forever - the question to
> really answer is whether or not this functionality (multiple parallel
> EAP exchanges) is something that is applicable to more than one lower
> layer. We believe the answer to that question is yes - hence, the work
> is being proposed in the IETF.
> 
> And, about the word "layer", what we have been saying is that GEE is not
> an EAP *lower* layer - we can reword "layer" to something else more
> appropriate if that helps avoid confusion. If you have a suggestion,
> please let us know.
> 
> Regards,
> Vidya
> 
> > -----Original Message-----
> > From: Alper Yegin [mailto:alper.yegin [at] yegin.org]
> > Sent: Thursday, June 15, 2006 11:09 AM
> > To: Dondeti, Lakshminath; 'Quinn Li'; 'Cao Zhen'
> > Cc: eap [at] frascone.com
> > Subject: Re: [eap] Questions for draft-barany-eap-gee-01
> >
> > You were earlier questioning if parallel EAP runs was ever
> > possible. This is different than saying you'd design it once
> > for all L2s.
> >
> > Regarding the first question, in fact, I don't know if there
> > is any EAP lower layer that cannot achieve what you are looking for.
> >
> > It's true EAP does not have extra fields for this use (by
> > design!), but the "EAP lower layers" do have. And that's
> > where the functionality you are seeking belongs to.
> >
> > I also find your "layering" responses very confusing. If
> > EAP-GEE is not a layer, why does your document call it "GEE
> > layer" and nicely puts it below the "EAP layer"?
> >
> >                 Peer                   Authenticator
> >         +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+
> >         |           |           |  |           |           |
> >         | EAP method| EAP method|  | EAP method| EAP method|
> >         | Type = X  | Type = Y  |  | Type = X  | Type = Y  |
> >         |       V   |           |  |       ^   |           |
> >         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
> >         |       !               |  |       !               |
> >         |  EAP  ! Peer layer    |  |  EAP  ! Auth. layer   |
> >         |       !               |  |       !               |
> >         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
> >         |       !               |  |       !               |
> >         |  EAP  ! layer         |  |  EAP  ! layer         |
> >         |       !               |  |       !               |
> >         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
> >         |       !               |  |       !               |
> >         |   GEE ! layer         |  |   GEE ! layer         |
> >         |       !               |  |       !               |
> >         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
> >         |       !               |  |       !               |
> >         | Lower ! layer         |  | Lower ! layer         |
> >         |       !               |  |       !               |
> >         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
> >                 !                          !
> >                 !                          !
> >                 +------------>-------------+
> >
> >
> >
> >
> > Alper
> >
> >
> >
> > > -----Original Message-----
> > > From: Lakshminath Dondeti [mailto:ldondeti [at] qualcomm.com]
> > > Sent: Tuesday, June 13, 2006 1:43 PM
> > > To: Alper Yegin; 'Quinn Li'; 'Cao Zhen'
> > > Cc: eap [at] frascone.com
> > > Subject: RE: [eap] Questions for draft-barany-eap-gee-01
> > >
> > > At 01:13 PM 6/13/2006, Alper Yegin wrote:
> > > > > With your last statement, are you saying that there is
> > another way
> > > > > to demultiplex multiple parallel EAP exchanges?  If so,
> > I would like to
> > > > > read about it.   Please share the reference.  Thanks.
> > > >
> > > >I don't see any inherent problems with an EAP lower layer
> > performing
> > > >such multiplexing, if they are really after such an optimization.
> > >
> > > The advantage of doing this at the IETF is to design it at the EAP
> > > level and allow use by multiple lower layers and multiple
> > purposes.
> > > The original authors had one use case, Joe and Parviz
> > joined us with
> > > another use case.  Designing support for multiple EAP
> > conversations is
> > > not new at the IETF.  All that GEE is doing is adding support for
> > > parallel authentications.
> > >
> > > >Especially not
> > > >to the extent that one needs to design a new layer to
> > solve the problem.
> > >
> > > No, GEE is *not* another "layer."  If EAP had an extra field in the
> > > header, GEE might not have been needed.
> > >
> > > best,
> > > Lakshminath
> > >
> > > >
> > > >Alper
> >
> >
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/eap
> >
> > Arhives: http://lists.frascone.com/pipermail/eap
> >