Extensible Authentication Protocol J. Arkko
(EAP) Ericsson
Internet-Draft B. Aboba
Intended status: Informational Microsoft
Expires: September 6, 2007 J. Korhonen
TeliaSonera
F. Bari
Cingular Wireless
March 5, 2007
Network Discovery and Selection Problem
draft-ietf-eap-netsel-problem-06
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Arkko, et al. Expires September 6, 2007 [Page 1]
Internet-Draft Network Discovery and PS March 2007
Abstract
When multiple access network are available, users may have difficulty
in selecting which network to connect to, and how to authenticate
with that network. This document defines the network discovery and
selection problem, dividing it into multiple sub-problems. Some
constraints on potential solutions are outlined, and the limitations
of several solutions (including existing ones) are discussed.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Problem Definition . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Discovery of the Point of Attachment to the Network . . . 7
2.2. Identity selection . . . . . . . . . . . . . . . . . . . . 9
2.3. AAA routing . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1. The Default Free Zone . . . . . . . . . . . . . . . . 13
2.3.2. Route Selection and Policy . . . . . . . . . . . . . . 14
2.3.3. Source Routing . . . . . . . . . . . . . . . . . . . . 15
2.4. Network Discovery . . . . . . . . . . . . . . . . . . . . 16
3. Design Issues . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1. AAA Routing . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Backward Compatibility . . . . . . . . . . . . . . . . . . 18
3.3. Efficiency Constraints . . . . . . . . . . . . . . . . . . 18
3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 19
3.5. Static Versus Dynamic Discovery . . . . . . . . . . . . . 19
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Normative References . . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Existing Work . . . . . . . . . . . . . . . . . . . . 30
A.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.2. IEEE 802 . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.3. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.4. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 36
Arkko, et al. Expires September 6, 2007 [Page 2]
Internet-Draft Network Discovery and PS March 2007
1. Introduction
When multiple access network are available, users may have difficulty
in selecting which network to connect to, and how to authenticate
with that network. The problem arises when any of the following
conditions are true:
o More than one network attachment point is available, and the
attachment points differ in capability or belong to different
operators. In this case, a user may have difficulty determining
which attachment points offering the desired services it can
successfully authenticate to. In order to choose between multiple
attachment points, it can be helpful to determine which realms are
supported and the capabilities that the networks support.
o The user has multiple sets of credentials. In this case, the user
may not be able to determine which credentials to use with which
attachment point, or even whether any credentials it possesses
will allow it to authenticate successfully. This can result in
multiple unsuccessful authentication attempts for each attachment
point, wasting valuable time and resulting in user frustration.
For example, the user could have one set of credentials from a
public service provider and set from an employer. In order to
choose between multiple attachment points, it can be helpful to
provide additional information to enable the correct credentials
to be determined.
o There are multiple potential roaming paths between the visited
realm and the user's home realm, and service parameters or pricing
differs between them. In this case, the access network may not be
able to determine the roaming path that best matches the user's
preferences. This can lead to the user being charged more than
necessary, or not obtaining the desired services. For example,
the visited access realm could have both a direct relationship
with the home realm and an indirect relationship through a roaming
consortium. Current AAA protocols may not be able to route the
access request to the home AAA sever purely based on the realm
within the Network Access Identifier (NAI) [RFC4282]. In
addition, payload packets can be routed or tunneled differently,
based on the roaming relationship path. This may have an impact
on the available services or their pricing.
In Section 2 the network discovery and selection problem is defined
and divided into subproblems, and some potential solution constraints
are outlined in Section 3. Section 4 provides conclusions and
suggestions for future work. Appendix A discusses existing solutions
to portions of the problem.
Arkko, et al. Expires September 6, 2007 [Page 3]
Internet-Draft Network Discovery and PS March 2007
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Network Access Identifier (NAI)
The Network Access Identifier (NAI) [RFC4282] is the user identity
submitted by the client during network access authentication. In
roaming, the purpose of the NAI is to identify the user as well as
to assist in the routing of the authentication request. Please
note that the NAI may not necessarily be the same as the user's
e-mail address or the user identity submitted in an application
layer authentication.
Decorated NAI
A NAI specifying a source route. See RFC4282 [RFC4282] Section
2.7 for more information.
Realm
The realm portion of an NAI [RFC4282].
Network Selection
Selection of an operator/ISP for network access. Network
Selection occurs prior to network access authentication.
Network Discovery
The mechanism used to discover available networks. The discovery
mechanism may be passive or active, and depends on the access
technology. In passive network discovery, the node listens for
network announcements; in active network discovery the node
solicits network announcements. It is possible for an access
technology to utilize both passive and active network discovery
mechanisms.
Realm Selection
The selection of the realm (and corresponding NAI) used to access
the network.
Arkko, et al. Expires September 6, 2007 [Page 4]
Internet-Draft Network Discovery and PS March 2007
Access Technology Selection
This refers to the selection between access technologies e.g.
802.11, UMTS, WiMAX. The selection will be dependent upon the
access technologies supported by the device and the availability
of networks supporting those technologies.
Bearer Selection
For some access technologies (e.g. UMTS), there can be a
possibility for delivery of a service (e.g. voice) by using either
a circuit switched or a packet switched bearer. The Bearer
selection refers to selecting one of the bearer types for service
delivery. The decision can be based on support of the bearer type
by the device and the network as well as user subscription and
operator preferences.
Network Access Server
The device that peers connect to in order to obtain access to the
network. In PPTP terminology, this is referred to as the PPTP
Access Concentrator (PAC), and in L2TP terminology, it is referred
to as the L2TP Access Concentrator (LAC). In IEEE 802.11, it is
referred to as an Access Point.
Roaming Capability
Roaming capability can be loosely defined as the ability to use
any one of multiple Internet Service Providers (ISPs), while
maintaining a formal, customer-vendor relationship with only one.
Examples of cases where roaming capability might be required
include ISP "confederations" and ISP-provided corporate network
access support.
Station (STA)
A device that contains an IEEE 802.11 conformant medium access
control (MAC) and physical layer (PHY) interface to the wireless
medium (WM).
Access Point (AP)
An entity that has station functionality and provides access to
distribution services via the wireless medium (WM) for associated
stations.
Arkko, et al. Expires September 6, 2007 [Page 5]
Internet-Draft Network Discovery and PS March 2007
Basic Service Set (BSS)
A set of stations controlled by a single coordination function.
Extended Service Set (ESS)
A set of one or more interconnected basic service sets (BSSs) with
the same Service Set Identifier (SSID) and integrated local area
networks (LANs), which appears as a single BSS to the logical link
control layer at any station associated with one of those BSSs.
This refers to a mechanism that a node uses to discover the
networks that are reachable from a given access network.
Within the context of network selection and discovery the term
'network' is sometimes used interchangeably with the term 'realm'.
It should be noted that a realm can be reachable from more than one
access network types and selection of a realm may not imply certain
network capabilities.
Arkko, et al. Expires September 6, 2007 [Page 6]
Internet-Draft Network Discovery and PS March 2007
2. Problem Definition
The network discovery and selection problem can be broken down into
multiple sub-problems. These include:
o Discovery of points of attachment. This involves the discovery of
points of attachment in the vicinity, as well as their
capabilities.
o Identifier selection. This involves selection of the NAI (and
credentials) used to authenticate to the selected point of
attachment.
o AAA routing. This involves routing of the AAA conversation back
to the home AAA server, based on the realm of the selected NAI.
o Payload routing. This involves the routing of data packets, in
the situation wh ere mechanisms more advanced than destination-
based routing are required. While this problem is interesting, it
is not discussed further in this document.
o Network capability discovery. This involves discovering the
capabilities of an access network, such as whether certain
services are reachable through the access network and type of
charging policy.
Alternatively, the problem can be divided to the discovery, decision,
and the selection components. The AAA routing problem, for instance,
involves all components: discovery (which mediating networks are
available?), decision (choose the "best" one), and selection (client
tells the network which mediating network it has decided to choose)
components.
2.1. Discovery of the Point of Attachment to the Network
Traditionally, discovery of points of attachment has been handled by
link layer or out-of-band mechanisms. For example, the IEEE 802.11
specification [IEEE.802.11-2003] provides support for both passive
(Beacon) and active (Probe Request/Response) discovery mechanisms;
[Fixingapsel] studied the effectiveness of these mechanisms. The GSM
specifications also provide for discovery of points of attachment, as
does the CARD [RFC4066] protocol developed by the IETF SEAMOBY WG.
RFC 2194 [RFC2194] 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 [RFC3017] describes the IETF Proposed
Standard for the Roaming Access XML DTD. This covers not only the
Arkko, et al. Expires September 6, 2007 [Page 7]
Internet-Draft Network Discovery and PS March 2007
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. The RFC supports dial-in and X.25 access, but
has extensible address and media type fields.
In IEEE 802.11 WLANs, the Beacon and 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. The Beacon/Probe facility therefore enables network
discovery, as well as the discovery of points of attachment and the
capabilities of those points of attachment.
As noted in [Velayos], the IEEE 802.11 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. Another issue with the Beacon and Probe Request/
Response mechanism is that it is either insecure or its security can
be assured only as part of authenticating to the network (e.g.
verifying the advertised capabilities within the 4-way handhskae).
A number of enhancements have been proposed to the Beacon/Probe
Response mechanism in order to improve scalability and performance in
roaming scenarios. These include allowing APs to announce
capabilities of neighbor APs as well as their own [IEEE.802.11k].
More scalable mechanisms for support of "virtual APs" within IEEE
802.11 have also been proposed [IEEE.802.11v]; generally these
proposals collapse multiple "virtual AP" advertisements into a single
advertisement.
Higher layer mechanisms can also be used to improve scalability,
since by running over IP they can utilize facilities such as
fragmentation which may not be available at the link layer. For
example, in IEEE 802.11, Beacon frames cannot use fragmentation
because they are multicast frames.
While a single IEEE 802.11 network may only utilize a single SSID, it
may cover a wide geographical area, and as a result, may be
segmented, utilizing multiple prefixes. It is possible that a single
SSID may be advertised on multiple channels, and may support multiple
access mechanisms, including Universal Access Method (UAM) and IEEE
802.1X [IEEE.8021X]. A single SSID also may support dynamic VLAN
access as described in [RFC3580], or may support authentication to
Arkko, et al. Expires September 6, 2007 [Page 8]
Internet-Draft Network Discovery and PS March 2007
multiple home AAA servers supporting different realms. As a result,
users of a single point of attachment, connecting to the same SSID
may not have the same set of services available.
2.2. Identity selection
As networks proliferate, it becomes more and more likely that a user
may have multiple identities and credential sets, available for use
in different situations. For example, the user may have an account
with one or more Public WLAN providers; a corporate WLAN; and one or
more wireless WAN providers.
Typically, the user will choose an identity and corresponding
credential set based on the network chooses to connect to, perhaps
with additional assistance provided by the chosen authentication
mechanism. For example, if EAP-TLS is the authentication mechanism
used with a particular network, then the user will select the
appropriate EAP-TLS client certificate based in part on the list of
trust anchors provided by the EAP-TLS server.
However, in access networks where roaming is enabled, the mapping
between an access network and an identity/credential set may not be
one to one. For example, it is possible for multiple identities to
be usable on an access network or for a given identity to be usable
on a single access network, which may or may not be available.
Figure 1 illustrates a situation where a user identity may not be
usable on a potential access network. In this case access network 1
enables access to users within the realm "isp1.example.com" whereas
access network 3 enables access to users within the realm
"corp2.example.com"; access network 2 enables access to users within
both realms.
Arkko, et al. Expires September 6, 2007 [Page 9]
Internet-Draft Network Discovery and PS March 2007
? ? +---------+ +------------------+
? | Access | | |
O_/ _-->| Network |------>| isp1.example.com |
/| / | 1 | _->| |
| | +---------+ / +------------------+
_/ \_ | /
| +---------+ /
User "subscriber@isp1. | | Access |/
example.com" -- ? -->| Network |
also known | | 2 |\
"employee123@corp2. | +---------+ \
example.com" | \
| +---------+ \_ +-------------------+
\_ | Access | ->| |
-->| Network |------>| corp2.example.com |
| 3 | | |
+---------+ +-------------------+
Figure 1: Two credentials, three possible access networks
In this situation, a user only possessing an identity within the
"corp2.example.com" realm can only successfully authenticate to
access networks 2 or 3; a user possessing an identity within the
"isp1.example.com" realm can only successfully authenticate to access
networks 1 or 2; a user possessing identities within both realms can
connect to any of the access networks. The question is: how does the
user figure out which access networks it can successfully
authenticate to, preferrably prior to choosing a point of attachment?
Traditionally, hints useful in identity selection have been provided
out-of-band. For example, the XML DTD described in [RFC3017] enables
a client to select between potential point of attachment as well as
to select the NAI and credentials to use in authenticating with it.
Where all points of attachment within an access network enable
authentication utilizing a set realms, selection of an access network
provides knowledge of the identities that a client can use to
successfully authenticate. For example, in an access network, the
set of supported realms corresponding to network name can be pre-
configured.
Of course, it may not be possible to determine the available access
networks prior to authentication. For example, in 802.11, not all
SSIDs are broadcast, so that the station may need to probe to locate
a "hidden" SSID. Also, within IKEv2 [RFC4306], the responder
identity (typically the security gateway) is provided as a part of
Arkko, et al. Expires September 6, 2007 [Page 10]
Internet-Draft Network Discovery and PS March 2007
the IKEv2 exchange.
It is also possible for hints to be embedded within credentials. In
[RFC4334], usage hints are provided within certificates used for
wireless authentication. This involves extending the client's
certificate to include the SSIDs with which the certificate can be
used.
However, there may be situations in which an access network may not
accept a static set of realms at every point of attachment. For
example, as part of a roaming agreement only points of attachment
within a given region or country may be made available. In these
situations, mechanisms such as hints embedded within credentials or
pre-configuration of access network to realm mappings may not be
sufficient. Instead, it is necessary for the client to discover
usable identities dynamically.
This is the problem that RFC 4284 [RFC4284] attempts to solve, using
the EAP-Request/Identity to communicate a list of supported realms.
However, the problems inherent in this approach are many, as
discussed in Appendix A.1.
2.3. AAA routing
Once the identity has been selected, the AAA infrastructure needs to
route the access request back to the home AAA server. Typically the
routing is based on the Network Access Identifier (NAI) defined in
[RFC4282].
Where the NAI does not encode a source route, the routing of requests
is determined by the AAA infrastructure. As described in [RFC2194]
most roaming implementations are relatively simple, relying on static
realm routing table which determine the next based on the NAI realm
included within the User-Name attribute. Within RADIUS, the IP
address of the home AAA server is typically determined based on
static mappings of realms to IP addresses maintained within RADIUS
proxies.
Diameter [RFC3588] supports mechanisms for intra and inter-domain
service discovery including support for DNS as well as service
discovery protocols such as SLPv2 [RFC2608]. As a result, it may not
be necessary to configure static tables mapping realms to the IP
addresses of Diameter agents. However, while this simplifies
maintenance of the AAA routing infrastructure, it does not
necessarily simplify roaming relationship path selection.
As noted in RFC 2607 [RFC2607], RADIUS proxies are deployed not only
for routing purposes, but also to mask a number of inadequacies in
Arkko, et al. Expires September 6, 2007 [Page 11]
Internet-Draft Network Discovery and PS March 2007
the RADIUS protocol design, such as the lack of standardized
retransmission behavior and the need for shared secret provisioning
between each AAA client and server.
Diameter [RFC3588] supports certificate-based authentication (using
either TLS or IPsec) as well as Redirect functionality, enabling a
Diameter client to obtain a referral to the home server from a
Diameter redirect server, so that the client can contact the home
server directly. In situations in which a trust model can be
established, these Diameter capabilities can enable a reduction in
the length of the roaming relationship path.
However, in practice there are a number of pitfalls. In order for
certificate-based authentication to enable communication between a
NAS or local proxy and the home AAA server, trust anchors need to be
configured, and certificates need to be selected. The AAA server
certificate needs to chain to a trust anchor configured on the AAA
client, and the AAA client certificate needs to chain to a trust
anchor configured on the AAA server. Where multiple potential
roaming relationship paths are available, this will reflect itself in
multiple certificate choices, transforming the path selection problem
into a certificate selection problem. Depending on the functionality
supported within the certificate selection implementation, this may
not make the problem easier to solve. For example, in order to
provide the desired control over the roaming path, it may be
necessary to implement custom certificate selection logic, which may
be difficult to introduce within a certificate handling
implementation designed for general purpose usage.
As noted in [RFC4284], it is also possible to utilize an NAI for the
purposes of source routing. In this case, the client provides
guidance to the AAA infrastructure as to how it would like the access
request to be routed. An NAI including source routing information is
said to be "decorated"; the decoration format is defined in
[RFC4282].
When decoration is utilized, the EAP peer provides the decorated NAI
within the EAP-Response/Identity, and as described in [RFC3579], the
NAS copies the decorated NAI included in the EAP-Response/Identity
into the User-Name attribute included within the access request. As
the access request transits the roaming relationship path, AAA
proxies determine the next hop based on the realm included within the
User-Name attribute, in the process successively removing decoration
from the NAI included in the User-Name attribute. In contrast, the
decorated NAI included within the EAP-Response/Identity encapsulated
in the access request remains untouched. As a result, when the
access request arrives at the AAA home server, the decorated NAI
included in the EAP-Response/Identity may differ from the NAI
Arkko, et al. Expires September 6, 2007 [Page 12]
Internet-Draft Network Discovery and PS March 2007
included in the User-Name attribute (which may have some or all of
the decoration removed). For the purpose of identity verification,
the EAP server utilizes the NAI in the User-Name attribute, rather
than the NAI in the EAP-Response/Identity.
Over the long term, it is expected that the need for NAI "decoration"
and source routing will disappear. This is somewhat analogous 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. Prior to the implementation of email gateways utilizing MX
RR routing, email address-based source-routing was used extensively.
However, over time the need for email source-routing disappeared.
2.3.1. The Default Free Zone
AAA clients on the edge of the network, such as NAS devices and local
AAA proxies, typically maintain a default realm route, providing a
default next hop for realms not otherwise taken into account within
the realm routing table. This permits devices with limited resources
to maintain a small realm routing table. Deeper within the AAA
infrastructure, AAA proxies may be maintained with a "default free"
realm table, listing next hops for all known realms, but not
providing a default realm route.
While dynamic realm routing protocols are not in use within AAA
infrastructure today, even if such protocols were to be introduced,
it is likely that they would be deployed solely within the core AAA
infrastructure, but not on NAS devices, which are typically resource
constrained.
Since NAS devices do not maintain a full realm routing table, they do
not have knowledge of all the realms reachable from the local
network. The situation is analogous to that of Internet hosts or
edge routers which do not participate in the BGP mesh. In order for
an Internet host to determine whether it an reach a destination on
the Internet, it is necessary to send a packet to the destination.
Similarly, when a user provides an NAI to the NAS, the NAS does know
apriori whether the realm encoded in the NAI is reachable or not; it
simply forwards the access request to the next hop on the roaming
relationship path. Eventually the access request reaches the
"default free" zone, where a core AAA proxy determines whether the
realm is reachable or not. As described in [RFC4284], where EAP
authentication is in use, the core AAA proxy can send an Access-
Reject, or it can send an Access-Challenge encapsulating an EAP-
Request/Identity containing realm hints based on the content of the
"default free" realm routing table.
Arkko, et al. Expires September 6, 2007 [Page 13]
Internet-Draft Network Discovery and PS March 2007
There are a number of intrinsic problems with this approach. Where
the "default free" routing table is large, it may not fit within a
single EAP packet, and the core AAA proxy may not have a mechanism
for selecting the most promising entries to include. Even where the
"default free" realm routing table would fit within a single EAP-
Request/Identity packet, the core AAA router may not choose to
include all entries, since the list of realm routes could be
considered confidential information not appropriate for disclosure to
hosts seeking network access. Therefore it cannot be assumed that
the list of "realm hints" included within the EAP-Request/Identity is
complete. Given this, a NAS or local AAA proxy snooping the EAP-
Request/Identity cannot rely on it to provide a complete list of
reachable realms. The "realm hint" mechanism described in [RFC4284]
is not a dynamic routing protocol.
2.3.2. Route Selection and Policy
Along with lack of a dynamic AAA routing protocol, today's AAA
infrastructure lacks mechanisms for route selection and policy. As a
result, multiple routes may exist to a destination realm, without a
mechanism for the selection of a preferred route.
In Figure 2, Roaming Groups 1 and 3 both include a route to the realm
"a.example.com". However, these realm routes are not disseminated to
the NAS along with associated metrics, and as a result there is no
mechanism for implementation of dynamic routing policies (such as
selection of realm routes by shortest path, or preference for routes
originating a given proxy).
+---------+
| |----> "a.example.com"
| Roaming |
+---------+ | Group 1 |
| |----->| Proxy |----> "b.example.com"
user "joe@ | Access | +---------+
a.example.com"--->| Provider|
| NAS | +---------+
| |----->| |----> "a.example.com"
+---------+ | Roaming |
| Group 2 |
| Proxy |----> "c.example.com"
+---------+
Figure 2: Multiple routes to a destination realm
In the example in Figure 2, access through Roaming Group 1 may be
less expensive than access through Roaming Group 2, and as a result
it would be desirable to prefer Roaming Group 1 as a next hop for an
Arkko, et al. Expires September 6, 2007 [Page 14]
Internet-Draft Network Discovery and PS March 2007
NAI with a realm of"a.example.com". However, the only way to obtain
this result would be to manually configure the NAS realm routing
table with the following entries:
Realm Next Hop
----- --------
b.example.com Roaming Group 1
c.example.com Roaming Group 2
Default Roaming Group 1
While manual configuration may be practical in situations where the
realm routing table is small and entries are static, Where the list
of supported realms change frequently, or the preferences change
dynamically, manual configuration will not be manageable.
2.3.3. Source Routing
Due the limitations of current AAA routing mechanisms, there are
situations in which better control over AAA routing behavior is
required. Utilizing NAI-based source routing, a decorated NAI can be
used to influence the roaming relationship path. Since the AAA
proxies on the roaming relationship path are constrained by existing
relationships, NAI-based source routing is not source routing in the
classic sense; it merely suggests preferences among already
established realm routes. If a realm route does not exist or is not
feasible, then NAI-based source routing cannot establish it.
While in principle source routing can provide users with better
control over AAA routing decisions, there are a number of practical
problems to be overcome. In order to enable the client to construct
optimal source routes, it is necessary for it to be provided with a
complete and up to date realm routing table. However, if a solution
to this problem was readily available, then it could be applied to
the AAA routing infrastructure, enabling the selection of routes
without the need for user intervention.
As noted in [Eronen04], only a limited number of parameters can be
updated dynamically. For example, quality of service or pricing
information typically will be pre-provisioned or made available on
the web rather than being updated on a continuous basis. Where realm
names are communicated dynamically, the "default free" realm list is
unlikely to be provided in full since this table could be quite
large. Given the constraints on the availability of information, the
construction of source routes typically needs to occur in the face of
incomplete knowledge.
In addition, there are few mechanisms available to audit whether the
requested source route is honored by the AAA infrastructure. For
Arkko, et al. Expires September 6, 2007 [Page 15]
Internet-Draft Network Discovery and PS March 2007
example, an access network could advertise a realm route to
costsless.example.com, while instead routing the access-request
through costsmore.example.com. While the decorated NAI would be made
available to the home AAA server in the EAP-Response/Identity, the
home AAA server might have a difficult time verifying that the source
route requested in the decorated NAI was actually honored by the AAA
infrastructure. Similarly, it could be difficult to determine
whether QoS or other routing requests were actually provided as
requested. To some extent, this problem may be addressed as part of
the business arrangements between roaming partners, which may provide
minimum service level guarantees.
Given the potential issues with source routing, conventional AAA
routing mechanisms are to be preferred wherever possible. Where an
error is encountered, such as an attempt to authenticate to an
unreachable realm, "realm hints" can be provided as described
[RFC4284]. However, this approach has severe scalability
limitations, as outlined in Appendix A.1.
2.4. Network Discovery
Network capabilities can provide information useful in the selection
of an access network. These include characteristics of the network
beyond those of individual points of attachment. Network
capabilities which can be discovered include:
o Access network identifier (e.g. IEEE 802.11 SSID)
o Roaming relationships between the access network provider and
other network providers and associated costs
o Authentication mechanisms
o Quality of Service capability
o Cost
o Service parameters, such as the existence of middleboxes
Network discovery focuses on the discovery of the services offered by
networks, not just the capabilities of individual points of
attachment. Typically it is desirable to acquire information on
access networks prior to authentication, particularly in situations
where successful authentication depends on that information.
Reference [IEEE.11-04-0624] classifies the possible steps at which
IEEE 802.11 networks can acquire this information:
Arkko, et al. Expires September 6, 2007 [Page 16]
Internet-Draft Network Discovery and PS March 2007
o Pre-association
o Post-association (or pre-authentication)
o Post-authentication
In the interest of minimizing connectivity delays, the information
required for network selection needs to be provided prior to
authentication. By the time authentication occurs, the node has
typically selected the access network, the NAI to be used to
authenticate, as well as the point of attachment. Should it learn
information during the authentication process that would cause it to
revise one or more of those decisions, the node will need to select a
new network, point of attachment, and/or identity, and then go
through the authentication process all over again. Such a process is
likely to be both time consuming and unreliable.
Arkko, et al. Expires September 6, 2007 [Page 17]
Internet-Draft Network Discovery and PS March 2007
3. Design Issues
The following factors should be taken into consideration while
evaluating solutions for problem of network selection and discovery:
3.1. AAA Routing
Solutions to the AAA routing issues discussed in Section 2.3 need to
apply to a wide range of AAA messages, and should not restrict the
introduction of new AAA or access network functionality. For
example, AAA routing mechanisms should work for access requests and
responses as well as accounting requests and responses and server-
initiated messages. Solutions should not restrict the development of
new AAA attributes, access types, or performance optimizations (such
as fast handoff support).
3.2. Backward Compatibility
Solutions need to maintain backward compatibility. In particular:
o Selection-aware clients need to interoperate with legacy NAS
devices and AAA servers.
o Selection-aware AAA infrastructure needs to interoperate with
legacy clients and NAS devices.
For example, selection-aware clients should not transmit packets
larger than legacy NAS devices or AAA servers can handle. Where
protocol extensions are required, changes should be required to as
few infrastructure elements as possible. For example, extensions
that require upgrades to existing NAS devices will be more difficult
to deploy than proposals that are incrementally deployable based on
phased upgrades of clients or AAA servers.
3.3. Efficiency Constraints
Solutions should be efficient as measured by channel utilization,
bandwidth consumption, handoff delay, and energy utilization.
Mechanisms that require depend on multicast frames need to be
designed with care since multicast frames are often sent at the
lowest supported rate and therefore consume considerable channel time
as well as energy on the part of listening nodes. Depending on the
deployment, it is possible for bandwidth to be constrained both on
the link, as well as in the backend AAA infrastructure. As a result,
chatty mechanisms such as keepalives or periodic probe packets are to
be avoided. Given the volume handled by AAA servers, solutions
should also be conscious of adding to the load, particularly in cases
where this could enable denial of service attacks. For example, it
Arkko, et al. Expires September 6, 2007 [Page 18]
Internet-Draft Network Discovery and PS March 2007
would be a bad idea for a NAS to attempt to obtain an updated realm
routing table by periodically sending probe EAP-Response/Identity
packets to the AAA infrastructure in order to obtain "realm hints" as
described in [RFC4284]. Not only would this add significant load to
the AAA infrastructure (particularly in cases where the AAA server
was already overloaded, thereby dropping packets resulting in
retransmission by the NAS), but it would also not provide the NAS
with a complete realm routing table, for reasons described in
Section 2.3.
Battery consumption is a significant constraint for handheld devices.
Therefore mechanisms which require significant increases in packets
transmitted, or the fraction of time during which the host needs to
listen (such as proposals that require continuous scanning), are to
be discouraged. In addition, the solution should not significantly
impact the time required to complete network attachment.
3.4. Scalability
Given limitations on frame sizes and channel utilization, it is
important that solutions scale less than linearly in terms of the
number of networks and realms supported. For example, solutions such
as [RFC4284] increase the size of advertisements in proportion to the
number of entries in the realm routing table. Similarly, "virtual
AP" approaches introduce additional Beacons in proportion to the
number of networks being advertised. Neither approach scales to
support a large number of networks and realms.
3.5. Static Versus Dynamic Discovery
"Phone-book" based approaches such as [RFC3017] can provide
information for automatic selection decisions. While this approach
has been applied to wireless access, it typically can only be used
successfully within a single operator or limited roaming partner
deployment. For example, were a "Phone-Book" approach to attempt to
incorporate information from a large number of roaming partners, it
could become quite difficult to keep the information simultaneously
comprehensive and up to date. As noted in [Priest04] and
[I-D.groeting-eap-netselection-results], a large fraction of current
WLAN access points operate on the default SSID, which may make it
difficult to distinguish roaming partner networks by SSID. In any
case, in wireless networks dynamic discovery is a practical
requirement since a node needs to know which APs are within range
before it can connect.
Arkko, et al. Expires September 6, 2007 [Page 19]
Internet-Draft Network Discovery and PS March 2007
4. Conclusions
This document describes the network selection and discovery problem.
In the opinion of the authors, the major findings are as follows:
o There is a need for additional work on access network discovery,
identifier selection, AAA routing, and payload routing.
o Credential selection and AAA routing are aspects of the same
problem, namely identity selection.
o When considering selection among a large number of potential
access networks and points of attachment, the issues described in
the document become much harder to solve, in an automated way,
particularly if there are constraints on handoff latency.
o The proliferation of network discovery technologies within IEEE
802, IETF, and 3GPP has the potential to become a significant
problem going forward. Without a unified approach, multiple non-
interoperable solutions may be deployed, resulting in
fragmentation.
o New link layer designs should include the efficient distribution
of network and realm information as a design requirement.
o It may not be possible to solve all aspects of the problem for
legacy NAS devices on existing link layers. Therefore a phased
approach may be more realistic. For example, a partial solution
could be made available for existing link layers, with a more
complete solution requiring support for extensions.
With respect to specific mechanisms for access network discovery and
selection:
o Studies such as [MACScale] and [Velayos], demonstrate that the
IEEE 802.11 Beacon/Probe Response mechanism has substantial
scaling issues, and as a result a single physical access point is
in practice limited to less than a dozen virtual APs on each
channel with IEEE 802.11b.
The situation is improved substantially with successors such as
IEEE 802.11a which enable additional channels, thus potentially
increasing the number of potential virtual APs.
However, even with these enhancements it is not feasible to
advertise more than 50 different networks, and probably less in
most circumstances.
Arkko, et al. Expires September 6, 2007 [Page 20]
Internet-Draft Network Discovery and PS March 2007
As a result, there appears to be a need to enhance the scalability
of IEEE 802.11 network advertisements.
o Work is underway in IEEE 802.1, IEEE 802.21 and the IEEE 802.11u
to provide enhanced discovery functionality. Similarly, IEEE
802.1af has discussed addition of network functionality to IEEE
802.1X. However, neither IEEE 802.1ab nor IEEE 802.1af is likely
to support fragmentation of advertisement frames, so that the
amount of data that can be transported will be limited.
o While IEEE 802.11k provides support for the Neighbor Report, this
only provides for gathering of information on neighboring 802.11
APs, not points of attachment supporting other link layers.
Solution to this problem would appear to require coordination
across IEEE 802 as well as between standards bodies.
o Given that EAP does not support fragmentation of EAP-Request/
Identity packets, the volume of "realm hints" that can be fit with
these packets is limited. In addition, within IEEE 802.11, EAP
packets can only be exchanged within State 3 (associated and
authenticated). As a result, use of EAP for realm discovery may
result in significant delays. In addition, the ability of EAP to
carry Quality of Service information
[I-D.groeting-eap-netselection-results] appears limited. As a
result, we believe that use of EAP as described in [RFC4284] is
not a sound long-term approach for solution of the realm discovery
problem for mobile users where the information is needed for
handoff purposes. Instead, we believe it is more appropriate for
this functionality to be handled within the link layer, so that
the information can be available early in the handoff process.
o Where link layer approaches are not available, higher layer
approaches can be considered. A limitation of higher layer
solutions is that they can only optimize the movement of already
connected hosts, but cannot address scenarios where network
discovery is required for successful attachment.
Higher layer alternatives worth considering include the SEAMOBY
CARD protocol [RFC4066], which enables advertisement of network
device capabilities over IP and Device Discovery Protocol (DDP)
[I-D.marques-ddp], which provides functionality equivalent to IEEE
802.1ab using ASN.1 encoded advertisements sent to a link-local
scope multicast address.
Arkko, et al. Expires September 6, 2007 [Page 21]
Internet-Draft Network Discovery and PS March 2007
5. IANA Considerations
This document does not define any new name spaces to be managed by
IANA. This document does not either reserve any new numbers or names
under any existing name space managed by IANA.
Arkko, et al. Expires September 6, 2007 [Page 22]
Internet-Draft Network Discovery and PS March 2007
6. Security Considerations
All aspects of the network discovery and selection problem are
security related. The security issues and requirements have been
discussed in the previous sections.
The security requirements for network discovery depend on the type of
information being discovered. Some of the parameters may have a
security impact, such as the claimed name of the network the user
tries to attach to. Unfortunately, current EAP methods do not always
make the verification of such parameters possible. New EAP methods
are doing it [I-D.josefsson-pppext-eap-tls-eap]
[I-D.tschofenig-eap-ikev2], however, and there is even an attempt to
provide a backwards compatible extensions to older methods
[I-D.arkko-eap-service-identity-auth].
The security requirements for network selection depend on whether the
selection is considered as a command or a hint. For instance, the
selection that the user provided may be ignored if it relates to AAA
routing and the access network can route the AAA traffic to the
correct home network using other means in any case.
Arkko, et al. Expires September 6, 2007 [Page 23]
Internet-Draft Network Discovery and PS March 2007
7. Contributors
The editors of this document would like to especially acknowledge the
contributions of Farid Adrangi, Farooq Bari, Michael Richardson, Pasi
Eronen, Mark Watson, Mark Grayson, Johan Rune, and Tomas Goldbeck-
Lowe.
Input for the early versions of this draft has been gathered from
many sources, including the above persons as well as 3GPP and IEEE
developments. We would also like to thank Alper Yegin, Victor Lortz,
Stephen Hayes, and David Johnston for comments.
Arkko, et al. Expires September 6, 2007 [Page 24]
Internet-Draft Network Discovery and PS March 2007
8. References
8.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3017] Riegel, M. and G. Zorn, "XML DTD for Roaming Access Phone
Book", RFC 3017, December 2000.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4334] Housley, R. and T. Moore, "Certificate Extensions and
Attributes Supporting Authentication in Point-to-Point
Protocol (PPP) and Wireless Local Area Networks (WLAN)",
RFC 4334, February 2006.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
8.2. Informative References
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang,
"Review of Roaming Implementations", RFC 2194,
September 1997.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
Arkko, et al. Expires September 6, 2007 [Page 25]
Internet-Draft Network Discovery and PS March 2007
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2", RFC 2608,
June 1999.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity
Selection Hints for the Extensible Authentication Protocol
(EAP)", RFC 4284, January 2006.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[I-D.arkko-eap-service-identity-auth]
Arkko, J. and P. Eronen, "Authenticated Service Identities
for the Extensible Authentication Protocol (EAP)",
draft-arkko-eap-service-identity-auth-04 (work in
progress), October 2005.
[I-D.groeting-eap-netselection-results]
Tschofenig, H., "Network Selection Implementation
Results", draft-groeting-eap-netselection-results-00 (work
in progress), July 2004.
[I-D.josefsson-pppext-eap-tls-eap]
Josefsson, S., Palekar, A., Simon, D., and G. Zorn,
"Protected EAP Protocol (PEAP)",
draft-josefsson-pppext-eap-tls-eap-07 (work in progress),
October 2003.
[I-D.marques-ddp]
Enns, R., Marques, P., and D. Morrell, "Device Discovery
Protocol (DDP)", draft-marques-ddp-00 (work in progress),
May 2003.
[I-D.tschofenig-eap-ikev2]
Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method (EAP-
IKEv2)", draft-tschofenig-eap-ikev2-10 (work in progress),
February 2006.
[IEEE.8021X]
Institute of Electrical and Electronics Engineers, "Local
and Metropolitan Area Networks: Port-Based Network Access
Control", IEEE Standard 802.1X, September 2001.
[IEEE.802.11-2003]
Arkko, et al. Expires September 6, 2007 [Page 26]
Internet-Draft Network Discovery and PS March 2007
Institute of Electrical and Electronics Engineers,
"Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Standard 802.11, 2003.
[IEEE-11-03-154r1]
Aboba, B., "Virtual Access Points", IEEE Contribution 11-
03-154r1, May 2003.
[IEEE-11-03-0827]
Hepworth, E., "Co-existence of Different Authentication
Models", IEEE Contribution 11-03-0827 2003.
[IEEE.11-04-0624]
Berg, S., "Information to Support Network Selection", IEEE
Contribution 11-04-0624 2004.
[11-05-0822-03-000u-tgu-requirements]
Moreton, M., "TGu Requirements", IEEE Contribution 11-05-
0822-03-000u-tgu-requirements, August 2005.
[3GPPSA2WLANTS]
3GPP, "3GPP System to Wireless Local Area Network (WLAN)
interworking; System Description; Release 6; Stage 2",
3GPP Technical Specification 23.234 v 6.6.0,
September 2005.
[3GPP-SA3-030736]
Ericsson, "Security of EAP and SSID based network
advertisements", 3GPP Contribution S3-030736,
November 2003.
[3GPP.23.122]
3GPP, "Non-Access-Stratum (NAS) functions related to
Mobile Station (MS) in idle mode", 3GPP TS 23.122 6.5.0,
October 2005.
[WWRF-ANS]
Eijk, R., Brok, J., Bemmel, J., and B. Busropan, "Access
Network Selection in a 4G Environment and the Role of
Terminal and Service Platform", 10th WWRF, New York,
October 2003.
[WLAN3G] Ahmavaara, K., Haverinen, H., and R. Pichna, "Interworking
Architecture between WLAN and 3G Systems", IEEE
Communications Magazine, November 2003.
[INTELe2e]
Intel, "Wireless LAN (WLAN) End to End Guidelines for
Arkko, et al. Expires September 6, 2007 [Page 27]
Internet-Draft Network Discovery and PS March 2007
Enterprises and Public Hotspot Service Providers",
November 2003.
[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,
April 2003.
[Fixingapsel]
Judd, G. and P. Steenkiste, "Fixing 802.11 Access Point
Selection", Sigcomm Poster Session 2002.
[Eronen03]
Eronen, P., "Network Selection Issues", presentation to
EAP WG at IETF 58, November 2003.
[Priest04]
Priest, J., "The State of Wireless London", July 2004.
[MACScale]
Heusse, M., "Performance Anomaly of 802.11b", LSR-IMAG
Laboratory, Grenoble, France, IEEE Infocom 2003.
[Eronen04]
Eronen, P. and J. Arkko, "Role of authorization in
wireless network security", Extended abstract presented in
the DIMACS workshop, November 2004.
[3GPPSA3WLANTS]
3GPP, "3GPP Technical Specification Group Service and
System Aspects; 3G Security; Wireless Local Area Network
(WLAN) interworking security (Release 6); Stage 2",
3GPP Technical Specification 33.234 v 6.6.0, October 2005.
[3GPPCT1WLANTS]
3GPP, "3GPP System to Wireless Local Area Network (WLAN)
interworking; User Equipment (UE) to network protocols;
Stage 3 (Release 6)", 3GPP Technical Specification 24.234
v 6.4.0, October 2005.
[IEEE.802.11k]
Institute of Electrical and Electronics Engineers, "Draft
Ammendment to Standard for Telecommunications and
Information Exchange Between Systems - LAN/MAN Specific
Requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications: Radio
Resource Management", IEEE IEEE 802.11k, D4.1, July 2006.
Arkko, et al. Expires September 6, 2007 [Page 28]
Internet-Draft Network Discovery and PS March 2007
[IEEE.802.11v]
Institute of Electrical and Electronics Engineers, "Draft
Amemdment to Standard for Information Technology -
Telecommunications and Information Exchange Between
Systems - LAN/MAN Specific Requirements - Part 11:
Wireless Medium Access Control (MAC) and physical layer
(PHY) specifications: Wireless Network Management",
IEEE IEEE 802.11v, D0.08, January 2007.
[IEEE.802.21]
Institute of Electrical and Electronics Engineers, "Draft
IEEE Standard for Local and Metropolitan Area Networks:
Media Independent Handover Services", IEEE IEEE 802.21,
D03.00, December 2006.
[3GPPCT4WLANTS]
3GPP, "3GPP system to Wireless Local Area Network (WLAN)
interworking; Stage 3 (Release 6)", 3GPP Technical
Specification 29.234 v 6.4.0, October 2005.
[RFC4066] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E.
Shim, "Candidate Access Router Discovery (CARD)",
RFC 4066, July 2005.
Arkko, et al. Expires September 6, 2007 [Page 29]
Internet-Draft Network Discovery and PS March 2007
Appendix A. Existing Work
A.1. IETF
Several IETF WGs have dealt with aspects of the network selection
problem, including the AAA, EAP, PPP, RADIUS, ROAMOPS, and RADEXT
WGs.
ROAMOPS WG developed the NAI, originally defined in [RFC2486], and
subsequently updated in [RFC4282]. Initial roaming implementations
are described in [RFC2194], and the use of proxies in roaming is
addressed in [RFC2607]. The SEAMOBY WG developed CARD [RFC4066],
which assists in discovery of suitable base stations. PKIX WG
produced [RFC3280], which addresses issues of certificate selection.
The AAA WG developed more sophisticated access routing,
authentication and service discovery mechanisms within Diameter
[RFC3588].
Adrangi et al. [RFC4284] defines the use of the EAP-Request/Identity
to provide "realm hints" useful for identity selection. The NAI
syntax described in [RFC4282] enables the construction of source
routes. Together, these mechanisms enable the user to determine
whether it possesses an identity and corresponding credential
suitable for use with an EAP-capable NAS. This is particularly
useful in situations where the lower layer provides limited
information (such as in wired IEEE 802 networks where IEEE 802.1X
currently does not provide for advertisement of networks and their
capabilities).
However, advertisement mechanisms based on the use of the EAP-
Request/Identity have scalability problems. As noted in [RFC3748]
Section 3.1, the minimum EAP MTU is 1020 octets, so that an EAP-
Request/Identity is only guaranteed to be able to include 1015 octets
within the Type-Data field. Since RFC 1035 [RFC1035] enables FQDNs
to be up to 255 octets in length, this may not enable the
announcement of many realms. The use of network identifiers other
than domain names is also possible.
As noted in [Eronen03], the use of the EAP-Request/Identity for realm
discovery has substantial negative impact on handoff latency, since
this may result in a station needing to initiate an EAP conversation
with each Access Point in order to receive an EAP-Request/Identity
describing which realms are supported. Since IEEE 802.11-2003 does
not support use of Class 1 data frames in State 1 (unauthenticated,
unassociated) within an Extended Service Set (ESS), this implies
either that the APs must support 802.1X pre-authentication (optional
in IEEE 802.11i-2004) or that the station must associate with each AP
prior to sending an EAPOL-Start to initiate EAP. This will
Arkko, et al. Expires September 6, 2007 [Page 30]
Internet-Draft Network Discovery and PS March 2007
dramatically increase handoff latency.
Thus, rather than thinking of [RFC4284] as a effective network
discovery mechanism, it is perhaps better to consider the use of
"realm hints" as an error recovery technique, to be used to inform
the EAP peer that AAA routing has failed, and perhaps to enable
selection of an alternate identity which can enable successful
authentication. Where "realm hints" are only provided in event of a
problem, rather than as a staple network discovery technique, it is
probably best to enable "realm hints" to be sent by core AAA proxies
in the "default free" zone. This way, it will not be necessary for
NASes to send realm hints, which would require them to maintain a
complete and up to date realm routing table, something which cannot
be easily accomplished given the existing state of AAA routing
technology.
If realm routing tables are manually configured on the NAS, then
changes in the "default free" realm routing table will not
automatically be reflected in the realm list advertised by the NAS.
As a result, a realm advertised by the NAS might not in fact be
reachable, or the NAS might neglect to advertise one or more realms
that were reachable. This could result in multiple EAP-Identity
exchanges, with the initial set of realm hints supplied by the NAS
subsequently updated by realm hints provided by a core AAA proxy. In
general, originating realm hints on core AAA proxies appears to be a
more sound approach, since it provides for "fate sharing" -
generation of realm hints by the same entity (the core AAA proxy)
that will eventually need to route the request based on the hints.
This approach is also preferred from a management perspective, since
only core AAA proxies would need to be updated; no updates would be
required to NAS devices.
A.2. IEEE 802
There has been work in several IEEE 802 working groups relating to
network discovery:
o [IEEE.802.11-2003] defines the Beacon and Probe Response
mechanisms within IEEE 802.11. Unfortunately, Beacons may be sent
only at a rate within the base rate set, which typically consists
of the lowest supported rate, or perhaps the next lowest rate.
Studies such as [MACScale] have identified MAC layer performance
problems, and [Velayos] has identified scaling issues from a
lowering of the Beacon interval.
o [IEEE-11-03-0827] discusses the evolution of authentication models
in WLANs, and the need for the network to migrate from existing
models to new ones, based on either EAP layer indications or
Arkko, et al. Expires September 6, 2007 [Page 31]
Internet-Draft Network Discovery and PS March 2007
through the use of SSIDs to represent more than the local network.
It notes the potential need for management or structuring of the
SSID space.
The paper also notes that virtual APs have scalability issues. It
does not compare these scalability issues to those of alternative
solutions, however.
o [IEEE-11-03-154r1] discusses mechanisms currently used to provide
"Virtual AP" capabilities within a single physical access point.
A "Virtual AP" appears at the MAC and IP layers to be distinct
physical AP. As noted in the paper, full compatibility with
existing 802.11 station implementations can only be maintained if
each virtual AP uses a distinct MAC address (BSSID) for use in
Beacons and Probe Responses. This draft does not discuss scaling
issues in detail, but recommends that only a limited number of
virtual APs be supported by a single physical access point. The
simulations presented in [Velayos] appear to confirm this
conclusion; with a Beacon interval of 100 ms, once more than 8
virtual APs are supported on a single channel, more than 20% of
bandwidth is used for Beacons alone. This would indicate a limit
of approximately 20 virtual APs per physical AP.
o IEEE 802.11u is working on realm discovery and network selection
[11-05-0822-03-000u-tgu-requirements]. This includes a mechanism
for enabling a station to determine the identities it can use to
authenticate to an access network, prior to associating with that
network. As noted earlier, solving this problem requires the AP
to maintain an up to date "default free" realm routing table,
which is not feasible without dynamic routing support within the
AAA infrastructure. Similarly, apriori discovery of features
supported within home realms (such as enrollment) is also
difficult to implement in a scalable way, absent support for
dynamic routing. Determination of network capabilities (such as
QoS support) is considerably simpler, since these depend solely on
the hardware and software contained within the AP.
o IEEE 802.21 [IEEE.802.21] is developing standards to enable
handover between heterogeneous link layers, including both IEEE
802 and non-IEEE 802 networks. To enable this, a general
mechanism for capability advertisement is being developed, which
could conceivably benefit aspects of the network selection
problem, such as realm discovery. For example, IEEE 802.21 is
developing Information Elements (IEs) which may assist with
network selection, including information relevant to both layer 2
and layer 3. Query mechanisms (including both XML and TLV
support) are also under development.
Arkko, et al. Expires September 6, 2007 [Page 32]
Internet-Draft Network Discovery and PS March 2007
A.3. 3GPP
The 3GPP stage 2 technical specification [3GPPSA2WLANTS] covers the
architecture of 3GPP Interworking WLAN (I-WLAN) with 2G and 3G
networks. This specification also discusses realm discovery and
network selection issues. The I-WLAN realm discovery procedure
borrows ideas from the cellular Public Land-based Mobile Network
(PLMN) selection principles, known as "PLMN Selection".
In 3GPP PLMN selection [3GPP.23.122], the mobile node monitors
surrounding cells and prioritizes them based on signal strength
before selecting a new potential target cell. Each cell broadcasts
its PLMN. A mobile node may automatically select cells that belong
to its Home PLMN, Registered PLMN or an allowed set of Visited PLMNs.
The PLMN lists are prioritized and stored in the SIM. In the case of
manual PLMN selection, the mobile node lists the PLMNs it learns from
surrounding cells and enables the user to choose the desired PLMN.
After the PLMN has been selected, cell prioritization takes place, in
order to select the appropriate target cell.
[WLAN3G] discuss the new realm (PLMN) selection requirements
introduced by I-WLAN roaming, which supports automatic PLMN
selection, not just manual selection. Multiple network levels may be
present, and the hotspot owner may have a contract with a provider
who in turn has a contract with a 3G network, which may have a
roaming agreement with other networks.
The I-WLAN specification requires that network discovery be performed
as specified in the relevant WLAN link layer standards. In addition
to network discovery, it is necessary to select intermediary realms
to enable construction of source routes. In 3GPP, the intermediary
networks are PLMNs, and it is assumed that an access network may have
a roaming agreement with more than one PLMN. The PLMN may be a Home
PLMN (HPLMN) or a Visited PLMN (VPLMN), where roaming is supported.
GSM/UMTS roaming principles are employed for routing AAA requests
from the VPLMN to the Home Public Land-based Mobile Network (HPLMN)
using either RADIUS or Diameter. The procedure for selecting the
intermediary network has been specified in the stage 3 technical
specifications [3GPPCT1WLANTS] and [3GPPCT4WLANTS].
In order to select the PLMN, the following procedure is required:
o The user may choose the desired HPLMN or VPLMN manually or let the
WLAN User Equipment (WLAN UE) choose the PLMN automatically, based
on user and operator defined preferences.
o AAA messages are routed based on the decorated or undecorated NAI.
Arkko, et al. Expires September 6, 2007 [Page 33]
Internet-Draft Network Discovery and PS March 2007
o EAP is utilized as defined in [RFC3748] and [RFC3579].
o PLMN advertisement and selection is based on [RFC4284], which
defines only realm advertisement. The document refers to the
potential need for extensibility, though EAP MTU restrictions make
this difficult.
The I-WLAN specification states that realm hints are only provided
when an unreachable realm is encountered. Where VPLMN control is
required, this is handled via NAI decoration. The station may
manually trigger PLMN advertisement by including an unknown realm
(known as the Alternative NAI) within the EAP-Response/Identity. A
realm guaranteed not to be reachable within 3GPP networks is utilized
for this purpose.
The I-WAN security requirements are described in the 3GPP stage 3
technical specification [3GPPSA3WLANTS]. The security requirements
for PLMN selection are discussed in 3GPP contribution
[3GPP-SA3-030736], which concludes that both SSID and EAP-based
mechanisms have similar security weaknesses. As a result, it
recommends that PLMN advertisements be considered hints.
A.4. Other
[INTELe2e] discusses the need for realm selection where an access
network may have more than one roaming relationship path to a home
realm. It also describes solutions to the realm selection problem
based on EAP, SSID and PEAP-based mechanisms.
Eijk et al [WWRF-ANS] discusses the realm and network selection
problem. The authors concentrate primarily on discovery of access
networks meeting a set of criteria, noting that information on the
realm capabilities and reachability inherently resides in home AAA
servers, and therefore it is not readily available in a central
location, and may not be easily obtained by NAS devices.
Arkko, et al. Expires September 6, 2007 [Page 34]
Internet-Draft Network Discovery and PS March 2007
Authors' Addresses
Jari Arkko
Ericsson
Jorvas 02420
Finland
Email: jari.arkko@ericsson.com
Bernard Aboba
Microsoft
One Microsoft Way
Redmond, WA 98052
USA
Email: aboba@internaut.com
Jouni Korhonen
TeliaSonera
Teollisuuskatu 13
Sonera FIN-00051
Finland
Email: jouni.korhonen@teliasonera.com
Farooq Bari
Cingular Wireless
7277 164th Avenue N.E.
Redmond WA 98052
USA
Email: farooq.bari@cingular.com
Arkko, et al. Expires September 6, 2007 [Page 35]
Internet-Draft Network Discovery and PS March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Arkko, et al. Expires September 6, 2007 [Page 36]