Subject: Re: [eap] Questions for draft-barany-eap-gee-01

From: "DENG, HUI -HCHBJ" <[email-masked]>
Date: Sat, 17 Jun 2006 16:54:47 +0800

Hi, Vidya,
 
I am not happy with the word "generic" in this draft,
This idea only support one application: MVNO.
Meanwhile not all lower level need this.
 
Thinking about how many people use MVNO, 
and how many people is the subscriber of Mobile IP.
 
-Hui

	-----Original Message----- 
	From: Narayanan, Vidya [mailto:[email-masked]] 
	Sent: 2006-6-17 (星期六) 2:58 
	To: Alper Yegin; Dondeti, Lakshminath; Quinn Li; Cao Zhen 
	Cc: [email-masked] 
	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:[email-masked]]
	> Sent: Thursday, June 15, 2006 11:09 AM
	> To: Dondeti, Lakshminath; 'Quinn Li'; 'Cao Zhen'
	> Cc: [email-masked]
	> 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:[email-masked]]
	> > Sent: Tuesday, June 13, 2006 1:43 PM
	> > To: Alper Yegin; 'Quinn Li'; 'Cao Zhen'
	> > Cc: [email-masked]
	> > 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
	>
	_________________________________________________________________
	To unsubscribe or modify your subscription options, please visit:
	http://lists.frascone.com/mailman/listinfo/eap
	
	Arhives: http://lists.frascone.com/pipermail/eap

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 20 Jun 2006 20:56:08 -0400

All,

A use case for parallel EAP transaction is: terminal auth and user auth.
If you take this simple use case, it may be easier for you to understand
why parallel EAP transactions may be useful.

Even if the authenticators are not the same, the de-multiplexing layer
(GEE in this case) allows the MN to differentiate the EAP packets.

-Kuntal

> Sent: Tuesday, June 20, 2006 2:21 PM
> To: Nakhjiri Madjid-MNAKHJI1; Dondeti, Lakshminath; Quinn Li; Cao Zhen
> Cc: [email-masked]
> Madjid,
> > First of all, multiple parallel EAPs between who and whom. In
> > general case one end is the peer but the other end is not
> > always the same.
> >
> 
> This is clearly explained in the draft - do you find that explantion
to
> not be adequate? If so, it would help if you point out the issues with
> the details in the draft.
> 
> > Second, I can see a case where you have to do both IMS
> > authentication and MIP6 authentication, not sure if
> > "parallelism" can be achieved but that is just the nature of
> > the beast.
> >
> 
> It is about running them in parallel on the same lower layer. IMS and
> MIP6 are different services - I don't see any reason why you can't
> authenticate for both in parallel with what is available today.
> 
> Vidya
> 
> > Third, when I want to design a system, I usually look for the
> > best solution for each system, not why a specific solution
> > cannot be used. I just don't see anything remarkable about
> > putting a new layer in EAP except the adding complexity to
> > something that is already too complex. I personally cannot
> > justify spending the time explaining all the EAP keying
> > layering concepts to an implementer under deadline pressure,
> > let alone adding yet another layer through an addendum to EAP
> > keying. I have already seen that nobody but a small group of
> > people understands the layering concepts anyway.
> >
> > Madjid
> >
> > Sent: Tuesday, June 20, 2006 1:11 PM
> > To: Nakhjiri Madjid-MNAKHJI1; Dondeti, Lakshminath; Quinn Li; Cao
Zhen
> > Madjid,
> > There is no customization for any specific use case. GEE can
> > be used any
> > time multiple parallel EAP runs are needed on a given lower layer. I
> > don't, however, see a use case where multiple parallel runs
> > of EAP will
> > be required for a service such as MIP6 or IMS. If there is such a
use
> > case, there is no reason why GEE cannot be used.
> >
> > If you think of a case where GEE cannot be used to
> > demultiplex multiple
> > parallel EAP exchanges, please share your thoughts on it.
> >
> > Thanks,
> > Vidya
> >
> > > From: Nakhjiri Madjid-MNAKHJI1
> > [mailto:[email-masked]]
> > > Sent: Tuesday, June 20, 2006 8:02 AM
> > > To: Dondeti, Lakshminath; Quinn Li; Cao Zhen
> > > Cc: [email-masked]
> > > Sent: Monday, June 12, 2006 11:58 PM
> > > To: Quinn Li; Cao Zhen
> > > Cc: [email-masked]
> > > Hi,
> > > GEE is not a general purpose authentication protocol.  It is
> > > a generic EAP encapsulation mechanism that allows
> > > demultiplexing of multiple simultaneous EAP conversations
> > > between a peer and an authenticator.  You say that the draft
> > > does describe the MVNO scenarios well, so I guess we can
> > > safely conclude that it does its job then.
> > >
> > > EAP is not used for IMS or Mobile IPv6 authentication, is it?
> > >  So, in simple terms, it's not the purpose of the GEE draft
> > > to specify support for those services.
> > >
> > > Madjid>>EAP is being used for non-cellular access into IMS.
> > > EAP is being considered for MIP6 bootstrapping.
> > > If the idea is to standardize the usage, then it should not
> > > be customized for a specific use case.
> > >

"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap