eap Mailing List: RE: RE: a question related to the eap network discovery solution draft

[Adrangi, Farid (farid.adrangi]

Jari, Simone, all


Going forward, so far there are two options:

1) Do nothing

2) We can reword the following paragraph in Sec. 6, Option 3 for more 
clarification.

Current text:

"If the RADIUS server cannot route the message based on the identity provided 
by the peer, it sends a second EAP Identity Request containing the identity 
hint information."

Modified Text:

"If the local RADIUS proxy/server cannot route the message *directly* to the 
home RADIUS server based on the identity provided by the peer (i.e., there is 
not a direct roaming relationship between the access network and the user's 
home network), it sends a second EAP Identity/Request containing the identity 
hint information. The RADIUS proxy/server may also Send identity hint even when 
an acceptable NAI realm (i.e., can be routed directly to the home RADIUS 
server) is received in the EAP Identity/Response."

I believe the WG LS call expires today -- so it would be nice to have a closure 
on this soon.

BR,
Farid

> -----Original Message-----
> From: Ruffino Simone [mailto:Simone.Ruffino [at] TILAB.COM] 
> Sent: Wednesday, September 22, 2004 6:43 AM
> To: eap [at] frascone.com
> Cc: Adrangi, Farid
> Subject: RE: [eap] RE: a question related to the eap network 
> discovery solution draft
> 
> 
> 
> Here I support Farid's proposed change, but I would leave 
> space for sending hints also in response to a valid 
> (routable) realm, i.e.,  not only when an unacceptable realm 
> is received. 
> 
> So I propose in Sec. 6, Option 3 the following change :
> 
> "If the RADIUS server cannot route the message based on the identity
>  provided by the peer, it sends a second EAP Identity Request
>  containing the identity hint information."
> 
> With (first part is Farid's proposal): 
> 
> "If the local RADIUS proxy/server cannot route the message 
> *directly* to
> the home RADIUS server based on the identity provided by the 
> peer (i.e.,
> there is not a direct roaming relationship between the access network
> and the user's home network), it sends a second EAP Identity/Request
> containing the identity hint information. The EAP server MAY 
> reply with an 
> identity hint also when an acceptable NAI realm is received in the 
> EAP Identity/Response, e.g. to support manual selection of mediating 
> networks."
> 
> Comments appreciated...
>  
> Regards,
> Simone
> 
> 
> > -----Original Message-----
> > From: eap-admin [at] frascone.com 
> [mailto:eap-admin [at] frascone.com] On Behalf Of
> > Adrangi, Farid
> > Sent: mercoledì 22 settembre 2004 4.03
> > To: jari.arkko [at] piuha.net; eap [at] frascone.com
> > Subject: [eap] RE: a question related to the eap network discovery
> > solution draft
> > 
> > I also think the third option is reasonable.  However, please see
> > comments inline.
> > BR,
> > Farid
> > 
> > > I can see a few possible ways of doing this:
> > >
> > > 1) Have the proxies issue an additional request
> > > regardless of whether they have a working NAI
> > > or not. The disadvantage of this is that an
> > > additional roundtrip is imposed. And as far as
> > > I understand options 2 and 3 in the appendix,
> > > this isn't allowed by the draft.
> > >
> > 
> > For the option 2, the network information is delivered on the first
> > Identity-Request.  In principle, it is similar to option 1 with the
> > exception that the initial Identity-Request is issued by the access
> > network proxy instead of the AP.
> > 
> > The option 3 allows , the current text in the appendix says 
> : "... If
> > the local RADIUS proxy/server cannot route the message based on the
> > identity provided by the peer, it sends a second EAP 
> Identity Request
> > containing the identity hint information."
> > 
> > I think we can address your concern by making the sentence 
> more specific
> > like:
> > 
> > "
> > If the local RADIUS proxy/server cannot route the message 
> *directly* to
> > the home RADIUS server based on the identity provided by 
> the peer (i.e.,
> > there is not a direct roaming relationship between the 
> access network
> > and the user's home network), it sends a second EAP Identity/Request
> > containing the identity hint information.
> > "
> > 
> > > 2) Have the clients issue a fake realm in
> > > order to cause a discovery packet to to be
> > > sent to them. Ugly...
> > >
> > 
> > I agree!  Coming up with a fake realm could be challenging too!
> > 
> > > 3) Avoid this requirement (at least until
> > > link layers can provide the information).
> > >
> > > What do people think? Should the document
> > > say something about this case?
> > >
> > > (Personally, I think the third option is
> > > the reasonable one.)
> > >
> > 
> > > --Jari
> > >
> > >
> > >
> > _______________________________________________
> > eap mailing list
> > eap [at] frascone.com
> > http://mail.frascone.com/mailman/listinfo/eap
> 
> 
> Gruppo Telecom Italia - Direzione e coordinamento di Telecom 
> Italia S.p.A.
> 
> ====================================================================
> CONFIDENTIALITY NOTICE
> This message and its attachments are addressed solely to the persons
> above and may contain confidential information. If you have received
> the message in error, be informed that any use of the content hereof
> is prohibited. Please return it immediately to the sender and delete
> the message. Should you have any questions, please send an e_mail to 
> MailAdmin [at] tilab.com. Thank you
> ====================================================================
>