RE: Re: network discovery & selection: problem definition
From: Mark Grayson (mgrayson) (mgraysoncisco.com)
Date: Mon, 1 Dec 2003 03:59:55 -0600 (CST)
Bernard

I would add a further level of decomposition to the section on Network
Discovery to allow separation of the dicovery of the (802.11) access
network and, since this may in turn be a common infrastructure shared
between a numper of service providers, the dicovery of the service
providers using this infrastructure. 

Cheers,
Mark

-----Original Message-----
From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] On Behalf
Of Bernard Aboba
Sent: 30 November 2003 16:00
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

Results generated by Tiger Technologies using MHonArc.