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

[Bernard Aboba (aboba]

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