eap Mailing List: RE: RE: draft-adrangi-eap-network-discovery-11.txt

[Adrangi, Farid (farid.adrangi]

Hi Glen,
Thanks so much for your quick review and feedback.  And thanks for
confirming fixes for issues 287 & 293 :-)  Please see my comments
inline.
BR,
Farid

> -----Original Message-----
> From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] 
> On Behalf Of Glen Zorn (gwz)
> Sent: Monday, April 04, 2005 9:04 PM
> To: eap [at] frascone.com
> Cc: jsalowey [at] cisco.com; gwz [at] cisco.com; 'Bernard Aboba'
> Subject: RE: [eap] RE: draft-adrangi-eap-network-discovery-11.txt
> 
> 
> Glen Zorn (gwz) <> supposedly scribbled:
> 
> > Bernard Aboba <mailto:aboba [at] internaut.com> supposedly scribbled:
> > 
> >> Can you review -11 and confirm that issues 287 and 293 have been
> >> resolved to your satisfaction?
> > 
> > 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
> 
[FA] Good suggestion!  Will do.

> 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.
> 
[FA] Ok.  I thought we could send an EAP-Notificaiton or Failure message
- I guess I was wrong.  So, how about if we say:

"
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 MUST respond with an EAP Failure packet.  The
local AAA proxy/server MAY also send an EAP-Notification message
providing the reason for the failure."

Will this work for you?


> 3.  The message flows in the Appendix only shoe the success cases --
> it would be nice if at least one failure case was illustrated.

[FA] Ok.  I will a failure case to one of the delivery options. 

> > 
> >> 
> >> ---------- Forwarded message ----------
> >> Date: Sun, 3 Apr 2005 21:29:40 -0700
> >> From: "Adrangi, Farid" <farid.adrangi [at] intel.com>
> >> To: Bernard Aboba <aboba [at] internaut.com>
> >> Cc: eap [at] frascone.com, iesg [at] ietf.org, Jari Arkko
> >>      <jari.arkko [at] piuha.net>, gwz [at] cisco.com, jsalowey [at] 
> >> cisco.com,
> >>      Pasi.Eronen [at] nokia.com, Eugene Chang <eugene.chang [at] funk.com>
> >> 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:aboba [at] internaut.com]
> >>> Sent: Saturday, April 02, 2005 5:08 PM
> >>> To: Adrangi, Farid
> >>> Cc: eap [at] frascone.com; iesg [at] ietf.org; Jari Arkko; gwz [at] 
> >>> cisco.com;
> >>> jsalowey [at] cisco.com; Pasi.Eronen [at] nokia.com; 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.
> > 
> > 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
> > eap [at] frascone.com
> > http://mail.frascone.com/mailman/listinfo/eap
> 
> 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
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>