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

[Glen Zorn (gwz) (gwz]

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

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.
> 
>> 
>> ---------- 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