Subject: [eap] RE: draft-adrangi-eap-network-discovery-11.txt

From: Bernard Aboba <[email-masked]>
Date: Mon, 4 Apr 2005 18:32:53 -0700 (PDT)

Can you review -11 and confirm that issues 287 and 293 have been
resolved to your satisfaction?

---------- Forwarded message ----------
Date: Sun, 3 Apr 2005 21:29:40 -0700
From: "Adrangi, Farid" <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked], [email-masked], Jari Arkko <[email-masked]>,
     [email-masked], [email-masked], [email-masked],
     Eugene Chang <[email-masked]>
Subject: RE: [eap] RE: FW: I-D
    ACTION:draft-adrangi-eap-network-discovery-11.txt

I don't recall talking about an IESG note on the mailing list!  Anyhow,
as to your strawman IESG note, it should be noted that the draft was
reviewed and accepted by IEEE 802.11 (WIEN? - the WG has sent an
official review report to IETF.  And also, I would remove the last part
of the note: "and it is not recommended for implementation outside of
3GPP."  I think we should state the facts about the solution and let the
implementer decided whether or not the solution is suitable for their
deployments outside 3GPP.
BR,
Farid

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Saturday, April 02, 2005 5:08 PM
> To: Adrangi, Farid
> Cc: [email-masked]; [email-masked]; Jari Arkko;
> [email-masked]; [email-masked]; [email-masked]; Eugene Chang
> Subject: RE: [eap] RE: FW: I-D
> ACTION:draft-adrangi-eap-network-discovery-11.txt
>
>
> I think we were talking about an IESG note in addition to
> material in the applicability statement, no?
>
> For example, EAP SIM contains the following note:
>
> IESG Note
>
> The EAP-SIM protocol was developed by 3GPP.  The documentation of
> EAP-SIM is provided as information to the Internet community.  While
> the EAP WG has verified that EAP-SIM is compatible with EAP as
> defined in RFC 3748, no other review has been done, including
> validation of the security claims.
>
> Here is a potential strawman note for the EAP Network
> Discovery document:
>
>  EAP Network Discovery was developed by 3GPP.  Documentation is
>  provided as information to the Internet community.  While the
>  EAP WG has verified that EAP Network Discovery is compatible with
>  EAP as defined in RFC 3748, no other review has been done, including
>  investigation of potential security issues.  There is work
>  underway in IEEE 802.11 which may provide similar functionality,
>  enabling an EAP peer to determine network availability prior to
>  handoff.  As a result, the approach described in this document may
>  be superceded by future standards, and it is not recommended for
>  implementation outside of 3GPP.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Mon, 4 Apr 2005 19:07:29 -0700

> resolved to your satisfaction? 

You betcha, this evening.

> Cc: [email-masked], [email-masked], Jari Arkko
>      <[email-masked]>, [email-masked], [email-masked],
>      [email-masked], Eugene Chang <[email-masked]>
> I don't recall talking about an IESG note on the mailing list! 
> Anyhow, as to your strawman IESG note, it should be noted that the
> draft was reviewed and accepted by IEEE 802.11 (WIEN? - the WG has
> sent an official review report to IETF.  And also, I would remove
the
> last part of the note: "and it is not recommended for
implementation
> outside of 3GPP."  I think we should state the facts about the
> solution and let the implementer decided whether or not the
solution
> is suitable for their deployments outside 3GPP. BR,      
> Farid
> 
>> Cc: [email-masked]; [email-masked]; Jari Arkko; [email-masked];
>> [email-masked]; [email-masked]; Eugene Chang
material in
>> the applicability statement, no?
>> 
>> Here is a potential strawman note for the EAP Network Discovery
>> document: 
>> 
EAP WG
>> has verified that EAP Network Discovery is compatible with  EAP
as
>> investigation of potential security issues.  There is work
underway
>> in IEEE 802.11 which may provide similar functionality,  enabling
an
>> EAP peer to determine network availability prior to  handoff.  As
a
>> result, the approach described in this document may  be
superceded by
>> future standards, and it is not recommended for  implementation
>> outside of 3GPP.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Mon, 4 Apr 2005 21:04:16 -0700

> You betcha, this evening.

As far as issues 287 & 293, looks OK to me.  A few other comments:

1. (editorial) I think the paragraph break here

   In such scenarios, a limited number of identity hints (e.g., a 
   list of roaming partners of the access network) can be provided 
   by the mechanism to enable the EAP peer to influence routing of
   AAA packets.

   The immediate application of the proposed mechanism is in 3GPP
   systems interworking with WLANs [TS 23.234] and [TS 24.234].  The
   roaming partner information provided via this mechanism is
limited by
   the link layer MTU size.  For example, assuming an average of 20

is in the wrong place -- this make more sense to me:

   In such scenarios, a limited number of identity hints (e.g., a 
   list of roaming partners of the access network) can be provided 
   by the mechanism to enable the EAP peer to influence routing of
   AAA packets.  The immediate application of the proposed mechanism
   is in 3GPP systems interworking with WLANs [TS 23.234] and 
   [TS 24.234].  

   The roaming partner information provided via this mechanism is 
   limited by the link layer MTU size.  For example, assuming an 
   average of 20

2. (technical) It's not clear to me what the required behavior is
from the following (section 2. paragraph 3)

   If the peer responds with an EAP-Response/Identity containing an
   unknown realm after the local AAA proxy/server sends an identity
   hint, then the local AAA proxy/server MAY respond immediately
with an
   EAP Failure packet.  Alternatively, it MAY first send an
   EAP-Notification providing the reason for the failure.

I think what is meant is that the proxy MAY send an EAP-Notification
message before sending EAP FAILURE, but EAP Failure is always sent
in this case.  If that is correct, may I suggest the following
replacement text:

   If the peer responds with an EAP-Response/Identity containing an
   unknown realm after the local AAA proxy/server sends an identity
   hint, then the local AAA proxy/server MAY send an
EAP-Notification
   message providing the reason for the failure; whether an
   EAP notification message is sent, the AAA proxy/server MUST
respond 
   with an EAP Failure packet. 

or something similar.

3.  The message flows in the Appendix only shoe the success cases --
it would be nice if at least one failure case was illustrated.
the
implementation
solution
>>> I think we were talking about an IESG note in addition to
material
>>> in the applicability statement, no?
>>> 
EAP WG
as
underway
>>> in IEEE 802.11 which may provide similar functionality,
enabling an
>>> EAP peer to determine network availability prior to  handoff.
As a
>>> result, the approach described in this document may  be
superceded
>>> by future standards, and it is not recommended for
implementation
simply
> _______________________________________________ eap mailing list
> [email-masked]

Hope this helps,

~gwz