eap Mailing List: RE: Re: deciding which NAI to send in an ID-RESPONSE

[Bari, Farooq (farooq.bari]

Even if the APs can have multiple SSIDs, do the standards allow them to
be broadcast i.e. all of them. Also if APs can broadcast all of them,
would not this result in extra traffic over the air specially if there
are a large no. of roaming agreements (i.e. large no. of SSIDs to
broadcast).

Alternatively if each of the user device decides to probe for all WISP
SSIDs with which user's operator has roaming agreements in an effort to
pick the best possible network say in terms of tariffs, it too may be a
long process and create extra traffic.

A better solution might be that somehow the WLAN (AP or some other
entity in the RADIUS path), can pass the supported WISPS information as
part of initial user authentication process. 

Farooq


-----Original Message-----
From: Bernard Aboba [mailto:aboba [at] internaut.com] 
Sent: Thursday, June 12, 2003 5:58 AM
To: Mark Watson
Cc: 'jari.arkko [at] piuha.net'; eap [at] frascone.com
Subject: RE: [eap] Re: deciding which NAI to send in an ID-RESPONSE


> WISPs may not have their own SSIDs

Is this due to a limitation of current APs that could be removed?  For
example, if some large number of virtual APs could be defined (say, 255)
per AP, so that each WISP could have their own SSIDs, would there be a
need for additional information as well?  If so, how much information
are we talking about?  Remember that EAP-Request/Identity (or
Notification) doesn't support fragmentation, so it's limited by the MTU
size.

> Notifications have the advantage that a mapping from RADIUS 
> Reply-Message to EAP Notification is already defined.

Please check RFC 2869bis -- use of RADIUS Reply-Message is deprecated
for use with EAP.  Use of Notification is preferred. However, in this
case it seems like EAP-Request/Identity might make more sense, given the
purpose of the displayable message.

> So, the information can come from the
> RADIUS server/proxy in the case of an error due to an unrecognised 
> Domain Name in the NAI. This places less burden on the AP.

I don't understand why Notification is a burden on the AP -- it's just
handled like any other EAP message.

> I think the idea of a defined 'name=value' format with IANA 
> registrations for names is a good one. Does this align with general 
> practice ? I see we have only one example so far.

RFC 2284 states that Notification is for delivery of a displayable
messages, and that is what it is used for, as I understand it.  Since a
Notification Response is sent automatically, there is no way for the
sender to know that the peer understood the message, or even that the
message was displayed (the peer responds immediately, and doesn't wait
until it has done the displaying to reply).

On the other hand, some APs do use the name=value format today within
EAP-Request/Identity messages, for the purpose of identifying the AP.
However, I don't think that EAP peer implementations do anything with
it.

The problem with going down the road of defining new 'name=value'
parameters is that this could create interoperability problems unless
the parameters were only treated as hints -- if the wrong NAI is sent,
then the displayable message part of the EAP-Request/Identity is set to
indicate that. _______________________________________________
eap mailing list
eap [at] frascone.com
http://mail.frascone.com/mailman/listinfo/eap