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

From: "Adrangi, Farid" <[email-masked]>
Date: Mon, 4 Apr 2005 22:16:32 -0700

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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Glen Zorn (gwz)
> Sent: Monday, April 04, 2005 9:04 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 'Bernard Aboba'
> Subject: RE: [eap] RE: draft-adrangi-eap-network-discovery-11.txt
> 
> 
> Glen Zorn (gwz) <> supposedly scribbled:
> 
> > Bernard Aboba <mailto:[email-masked]> 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" <[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.
> > 
> > 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
> 
> 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
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Tue, 5 Apr 2005 13:26:52 -0700

Adrangi, Farid <mailto:[email-masked]> supposedly
scribbled:

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

I'm pretty sure that the EAP-{Request, Response}/Notification
exchange has to come before EAP Failure; if you could make that
sequential character clear (which I attempted to do, but apparently
failed), it would be great.

the
has
>>>> 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 
>>>> 
material
of
>>>>> 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
>>>>> 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. 
>>>   simply listening to John Coltrane? -- Henry Gabriel
>>> [email-masked] http://mail.frascone.com/mailman/listinfo/eap
>> 
>> Hope this helps,
>> 
>> ~gwz
>> 
simply

Hope this helps,

~gwz