Subject: RE: [eap] RE: a question related to the eap network discovery solution draft

From: "Adrangi, Farid" <[email-masked]>
Date: Thu, 23 Sep 2004 13:40:13 -0700

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:[email-masked]] 
> Sent: Wednesday, September 22, 2004 6:43 AM
> To: [email-masked]
> 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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of
> > Adrangi, Farid
> > Sent: mercoledì 22 settembre 2004 4.03
> > To: [email-masked]; [email-masked]
> > 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
> > [email-masked]
> > 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 
> [email-masked]. Thank you
> ====================================================================
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Wed, 29 Sep 2004 14:08:53 +0300

Personally, I'd rather avoid this particular change. The
reason for this is what I described in the original message:
additional latency. In particular, an access network is
not in a position to know whether or not the client wants
to do manual selection or not. Most likely only a small
fraction of clients would be doing this (in GSM its relatively
rare in my understanding). So, everyone else would end up
paying a roundtrip for the benefit of the few.

In fact, I'd rather see as choosing between doing nothing,
or making the text more restrictive than it currently is.
We currently prohibit "unnecessary" advertisements. Perhaps
what we could add is some text that discourages the use of
alternative 2 from my original e-mail. For instance, we
could say "Note that EAP peers could force the access network
to generate an advertisement by supplying a NAI that is not
routable by the access network. However, such usage is NOT
RECOMMENDED due to the difficulty of finding a NAI that is
known to be non-routable. Also, this usage is problematic
when it is not certain that the network supports this
specification or when the authentication attempt uses
resources from a number of proxies on the default route
until it is found to be invalid."

What do you think?

--Jari