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

From: Jari Arkko <[email-masked]>
Date: Tue, 21 Sep 2004 15:54:04 +0300

A question has come up that may relate to Farid's EAP
network discovery solution draft. The draft currently
does not say anything about this, but I'm wondering if
it should.

Here's the problem: the EAP Identity Request packet
with the discovery information is usually triggered
from one of the access network proxies, due to seeing
a NAI that can not be directly routed. Having all
APs send an EAP Identity Request packet with the
discovery information initially may not be possible
due to the capabilities of those APs and/or
provisioning effort.

Now, people might want to get the discovery information
in every case, not just if they have a failure. This
might be useful, for instance, if you wanted to have
the user, not the host, be in charge of the selection.

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.

2) Have the clients issue a fake realm in
order to cause a discovery packet to to be
sent to them. Ugly...

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

---

From: "Bari, Farooq" <[email-masked]>
Date: Tue, 21 Sep 2004 16:57:22 -0700

Hi Jari,

I would agree with you on pursuing the third option for this draft.  If
some client software or a user wants to get an advertisement in any
case, it can use option 2  which would have no impact on the logic on
the network side. 

BR,

Farooq
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jari Arkko
Sent: Tuesday, September 21, 2004 5:54 AM
To: [email-masked]; Adrangi, Farid
Subject: [eap] a question related to the eap network discovery solution
draft

--Jari

---

From: "Adrangi, Farid" <[email-masked]>
Date: Tue, 21 Sep 2004 19:02:45 -0700

I also think the third option is reasonable.  However, please see
comments inline.
BR,
Farid

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

> order to cause a discovery packet to to be

I agree!  Coming up with a fake realm could be challenging too!

---

From: Ruffino Simone <[email-masked]>
Date: Wed, 22 Sep 2004 15:42:46 +0200

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

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

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: Ruffino Simone <[email-masked]>
Date: Fri, 24 Sep 2004 09:18:37 +0200

Hi to all.

Option 2) with modified text is OK for me.

Regards,
Simone

> From: Adrangi, Farid [mailto:[email-masked]]
> Sent: giovedì 23 settembre 2004 22.40
> To: Ruffino Simone; [email-masked]
> Cc: [email-masked]
> Subject: RE: [eap] RE: a question related to the eap network discovery
> solution draft
> 
> 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:
> 
> provided by the peer, it sends a second EAP Identity Request containing
> the identity hint information."
> 
> Modified Text:
> 
> 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
> 
> > 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.
> >
> > > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of
> > > Adrangi, Farid

---

From: "Adrangi, Farid" <[email-masked]>
Date: Wed, 29 Sep 2004 10:01:43 -0700

Hi Jari,
I agree.  My preference is "do nothing"!  However, I like your proposed
text for discouraging the use of the alternative 2.  
BR,
Farid

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, September 29, 2004 4:09 AM
> To: Adrangi, Farid
> Cc: Ruffino Simone; [email-masked]
> Subject: Re: [eap] RE: a question related to the eap network 
> discovery solution draft
> 
> 
> 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
> 
> Adrangi, Farid wrote:
> > Jari, Simone, all
> > 
> > 
> > 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.
>