eap Mailing List: RE: Re: network discovery & selection: problem definition

[Adrangi, Farid (farid.adrangi]

Hi Bernard,
I have slightly different way of breaking down the problem 
- maybe we are talking about the same thing and the differences
is in wording it!  As the name implies, the problem has two 
aspects: discovery and selection so maybe it is easier
to understand the problem by describing the purpose of each
aspect.


Purpose of Network Discovery:
----------------------------
1) Discover 802.11 Access Networks within a coverage area.
(Note, although our examples are 802.11, it is applicable to
any access network).

2) Discover Mediating or Service Networks that a given 
802.11 access network is affiliated with.  (Note that POP 
is only know to the Access Network, but mediating networks 
are known to both Access Networks and home service network
because of romaing agreements.)


Purpose of Network Selection:
----------------------------
1) Enable the WLAN client (manually or automatically) to select 
the most appropriate 802.11 Access Network to associate with for
a given "Network Identifier/credential" installed on the client's 
device.

2) The home service network needs to enable a policy mechanism by which
the WLAN client (manually or automatically) can influence the
routing of AAA packets through the preferred Mediating Network to
the WLAN client's home service network.  

Note:  IMO, "Identifier Selection" is an indenpent problem by itself.

Best regards,
Farid

> -----Original Message-----
> From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] 
> On Behalf Of Bernard Aboba
> Sent: Sunday, November 30, 2003 8:00 AM
> To: eap [at] frascone.com
> Subject: [eap] Re: network discovery & selection: problem definition
> 
> 
> I'd suggest that there are three somewhat orthogonal problems 
> being discussed under the rubric of "network selection".
> 
> First, there is the problem of "Network discovery".  This is 
> the problem of discovering access networks available in the 
> vicinity, and the points of presence (POPs) associated with 
> those networks.
> 
> Second, there is the problem of "Identifier selection".  This 
> is the problem of selecting which identity (and credentials) 
> to use to authenticate to a given POP.
> 
> Thirdly, there is the problem of "Access routing" which 
> involves figuring out how to route the authentication 
> conversation originating from the selected identity back to 
> the home realm.
> 
> Network Discovery
> -----------------
> Traditionally, the problem of discovering available networks 
> has been handled out-of-band of EAP.
> 
> RFC 2194 describes the pre-provisioning of dialup roaming 
> clients, which typically included a list of potential phone 
> numbers, updated by the
> provider(s) with which the client had a contractual 
> relationship. RFC 3017 describes the IETF Proposed Standard 
> for the Roaming Access XML DTD.  This covers not only the 
> attributes of the Points of Presence (POPs) and Internet 
> Service Providers (ISPs), but also hints on the appropriate 
> NAI to be used with a particular POP.
> 
> In IEEE 802.11 WLANs, the Beacon/Probe Request/Response 
> mechanism provides a way for Stations to discover Access 
> Points (APs), as well as the capabilities of those APs.  
> Among the Information Elements (IEs) included within the 
> Beacon and Probe Response is the SSID, a non-unique 
> identifier of the network to which an Access Point is 
> attached.  By combining network identification along with 
> capabilities discovery, the Beacon/Probe facility provides 
> the information required for both network discovery and 
> roaming decisions within a single mechanism.
> 
> As noted in [Velayos], the Beacon mechanism does not scale 
> well; with a Beacon interval of 100ms, and 10 APs in the 
> vicinity, approximately 32 percent of an 802.11b AP's 
> capacity is used for beacon transmission. In addition, since 
> Beacon/Probe Response frames are sent by each AP over the 
> wireless medium,  stations can only discover APs within 
> range, which implies substantial coverage overlap for roaming 
> to occur without interruption.
> 
> A number of enhancements have been proposed to the 
> Beacon/Probe Response mechanism in order to improve 
> scalability and roaming performance.  These include allowing 
> APs to announce capabilities of neighbor APs as well as their 
> own, as proposed in IEEE 802.11k; propagation of discovery 
> information over IP, as handled in the CARD protocol 
> developed within the IETF SEAMOBY WG, etc.
> 
> Typically scalability enhancement mechanisms attempt to get 
> around Beacon/Probe Response restrictions by sending 
> advertisements at the higher rates which are enabled one the 
> station has associated with an AP.  Since these mechanisms 
> run over IP, they can utilize IP facilities such as 
> fragmentation, which the Beacon/Probe Response mechanism cannot.
> 
> Identity selection
> ------------------
> As networks proliferate, it becomes more and more likely that 
> a given EAP peer may have multiple identities and credential 
> sets, available for use in different situations.  For 
> example, the EAP peer may have an account with one or more 
> Public WLAN providers;  a corporate WLAN;  one or more 
> wireless WAN providers. As a result, the EAP peer has to 
> decide which credential set to use when presented with a 
> given set of potential EAP authenticators.
> 
> Traditionally, hints useful in identity selection have also 
> been provided out-of-band.  For example, via the IETF 
> Proposed Standard Roaming Access XML DTD, a client can select 
> between potential POPs, and then based on information 
> provided in the DTD, determine the appropriate NAI to use 
> with the selected POP.
> 
> However, it is also possible for hints to be embedded within 
> credentials. In [Housley], usage hints are provided within 
> certificates used for wireless authentication.  This involves 
> extending the certificate to include the SSIDs with which the 
> certificate can be used.
> 
> 
> Access routing
> --------------
> Once the identity has been selected, it is necessary for the 
> authentication conversation to be routed back to the home 
> realm.  Within the IETF ROAMOPS WG, a number of approaches 
> were considered for this, including source routing techniques 
> based on the NAI [RFC2486], and techniques relying on the AAA 
> infrastructure.  Given the relative simplicity of the roaming 
> implementations described in RFC 2194,  static routing 
> mechanisms appeared adequate for the task and it was not 
> deemed necessary to develop dynamic routing protocols.
> 
> As noted in RFC 2607, RADIUS proxies are deployed not only 
> for routing purposes, but also to mask a number of 
> inadequacies in the RADIUS protocol design, such as the lack 
> of standarized retransmission behavior and the need for 
> shared secret provisioning.
> 
> By removing many of the protocol inadequacies, introducing 
> new AAA agent types such as Redirects, providing support for 
> certificate-based authentication as well as inter and 
> intra-domain service discovery, Diameter allows a NAS to 
> directly open a Diameter connection to the home realm without 
> having to utilize a network of proxies.
> 
> This is somewhat analagous to the evolution of email 
> delivery.  Prior to the widespread proliferation of the 
> Internet, it was necessary to gateway between SMTP-based mail 
> systems and alternative delivery technologies, such as UUCP 
> and FidoNet, and email-address based source-routing was used 
> to handle this. However, as mail could increasingly be 
> delivered directly, the use of source routing disappeared.
> 
> As with the selection of certificates by stations, a Diameter 
> client wishing to authenticate with a Diameter server may 
> have a choice of available certificates, and therefore it may 
> need to choose between them.
> 
> References
> ----------
> 
> [Housley] Housley, R., and T. Moore, "Certificate Extensions 
> and Attributes Supporting Authentication in PPP and Wireless 
> LAN", draft-ietf-pkix-wlan-extns-04.txt,
> Internet Draft (work in progress), June 2003.
> 
> [Mishra] Mishra, A., Shin, M. and W. Arbaugh, "An empirical 
> analysis of the IEEE 802.11 MAC layer handoff process", 
> University of Maryland Technical Report, UMIACS-TR-2002-75, 2002.
> 
> [Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce 
> IEEE 802.11b MAC Layer Handover Time", Laboratory for 
> Communication Networks, KTH, Royal Institute of Technology, 
> Stockholm, Sweden, TRITA-IMIT-LCN R 03:02
> 
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>