Extensible Authentication Protocol J. Arkko
Internet-Draft Ericsson
Expires: April 26, 2006 B. Aboba, Eds.
Microsoft
October 23, 2005
Network Discovery and Selection Problem
draft-ietf-eap-netsel-problem-03
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 April 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The so called network discovery and selection problem affects network
access, particularly in the presence of multiple available wireless
accesses and roaming. This problem has been the subject of
discussions in various standards bodies. This document summarizes
the discussion held about this problem in the Extensible
Authentication Protocol (EAP) working group at the IETF. The problem
is defined and divided into subproblems, and some constraints for
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 1]
Internet-Draft Network Discovery and PS October 2005
possible solutions are outlined. The document presents also some
existing mechanisms which help solve at least parts of the problem,
and gives some suggestions on how to proceed for the rest.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Definition . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Access Network Discovery . . . . . . . . . . . . . . . . . 4
2.2 Identity selection . . . . . . . . . . . . . . . . . . . . 6
2.3 AAA routing . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 The Incomplete Routing Table Problem . . . . . . . . . 8
2.3.2 The User Selection Problem . . . . . . . . . . . . . . 9
2.4 Payload Routing . . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Issues with Payload Routing . . . . . . . . . . . . . 11
2.5 Discovery, Decision, and Selection . . . . . . . . . . . . 12
2.6 Type of Information . . . . . . . . . . . . . . . . . . . 13
3. Design Constrains . . . . . . . . . . . . . . . . . . . . . . 14
4. Existing Work . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1 IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 IEEE . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4 Other . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1 Normative References . . . . . . . . . . . . . . . . . . . 24
7.2 Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29
B. Modifications from Version 00 . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . 31
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 2]
Internet-Draft Network Discovery and PS October 2005
1. Introduction
The so called network discovery and selection problem affects network
access and wireless access networks in particular. This problem
comes relevant when any of the following conditions are true:
o There is more than one available network attachment point, and the
different points may have different characteristics.
o The user has multiple sets of credentials. For instance, the user
could have one set of credentials from a public service provider
and another set from his company.
o There is more than one way to provide roaming between the access
and home network, and service parameters or pricing differs
between them. For instance, the access network could have both a
direct relationship with the home network and an indirect
relationship through a roaming consortium.
o The roaming relationships between access and home networks are so
complicated that current AAA protocols can not route the requests
to the home network unaided, just based on the domain in the given
Network Access Identifier (NAI) [RFC2486] [I-D.ietf-radext-
rfc2486bis].
o Payload packets get routed or tunneled differently, based on which
particular roaming relationship variation is used. This may have
an impact on the available services or their pricing.
o Virtual Operators share the same infrastructure, such as wireless
access points.
The network discovery and selection problem spans multiple protocol
layers and has been the subject of discussions in IETF, 3GPP, and
IEEE. This document summarizes the discussion held about this
problem in the Extensible Authentication Protocol working group at
IETF.
In Section 2 the problem is defined and divided into subproblems, and
some constraints for possible solutions are outlined in Section 3.
Section 4 discusses existing mechanisms which help solve at least
parts of the problem. Section 5 gives some suggestions on how to
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 3]
Internet-Draft Network Discovery and PS October 2005
proceed for the rest.
2. Problem Definition
There are four somewhat orthogonal problems being discussed under the
rubric of "network discovery and selection".
o First, there is the problem of "Access Network discovery". This
is the problem of discovering access networks available in the
vicinity, and the points of presence (POPs) associated with those
networks.
o 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.
o Thirdly, there is the problem of "AAA routing" which involves
figuring out how to route the authentication conversation
originating from the selected identity back to the home realm.
o Finally, there is the the problem of "Payload routing" which
involves figuring how the payload packets are routed, where more
advanced mechanisms than destination-based routing is needed.
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 mediting network it has decided to choose)
components.
2.1 Access Network Discovery
The Access Network Discovery problem has been extensively studied,
see for instance the results of the IETF Seamoby WG, IEEE
specifications on 802.11 wireless LAN beaconing and probing process,
studies (such as [Fixingapsel]) on the effectiveness of these
mechanisms, and so on.
Traditionally, the problem of discovering available networks has been
handled as a part of the link layer attachment procedures, or through
out-of-band mechanisms.
RFC 2194 [RFC2194] describes the pre-provisioning of dialup roaming
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 4]
Internet-Draft Network Discovery and PS October 2005
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
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/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 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.
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 link layer mechanisms may
not always be able to do. For instance, in IEEE 802.11, Beacon
frames cannot use fragmentation because they are multicast frames,
and multicast frames are not acknowledged in 802.11.
Another issue with the Beacon/Probe Request/Response mechanism is
that it is either insecure or its security can be assured only after
already attaching to this particular network.
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 5]
Internet-Draft Network Discovery and PS October 2005
2.2 Identity selection
As networks proliferate, it becomes more and more likely that a given
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;
one or more wireless WAN providers. As a result, the user has to
decide which credential set to use when presented with a choice.
Figure 1 illustrates a situation where the user does not know whether
he is connected to access network 1, which only serves the ISP,
access network 3, which only serves the company, or access network 2,
which serves both.
+---------+ +---------+
| Access | | |
_---->| Network |------>| isp.com |
/ | 1 | _->| |
| +---------+ / +---------+
| /
| +---------+ /
User "subscriber@ | | Access |/
isp.com" also known as --- ? ---->| Network |
"employee123@corp.com" | | 2 |\
| +---------+ \
| \
| +---------+ \_ +---------+
\_ | Access | ->| |
---->| Network |------>| corp.com|
| 3 | | |
+---------+ +---------+
Figure 1: Two credentials, three possible access links
Traditionally, hints useful in identity selection have also been
provided out-of-band. For example, via the RFC 3017 XML DTD
[RFC3017], 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.
Perhaps the most typical case is a link layer that provides some
information about the network before EAP is initiated. For instance,
in IEEE 802.11 provides the SSID, though in some cases the client may
not learn about all the SSIDs supported by the given access point.
In IKEv2 [I-D.ietf-ipsec-ikev2], the identity of the responder
(typically the security gateway) is provided as a part of the usual
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 6]
Internet-Draft Network Discovery and PS October 2005
IKEv2 exchange.
In order to use this information in deciding the right identity to
use, the provided information has to either match with one of the
client's home networks, or the client has to have some other
knowledge that enables to link the advertised network and the home
network. For instance, the client may be aware that his home network
has a roaming contract with a given access network.
It is also possible for hints to be embedded within credentials. In
[RFC3770], 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.
Finally, some EAP implementations use the space after the NUL
character in an EAP Identity Request to communicate some parameters
relating to the network requesting EAP authentication. While there
is Standards Track RFC specifying the interpretation of the field
beyond the NUL character, [I-D.adrangi-eap-network-discovery] is
widely expected to be used.
2.3 AAA routing
Once the identity has been selected, it is necessary for the
authentication conversation to be routed back to the home realm.
This is typically done today through the use of the Network Access
Identifier (NAI), RFC 2486 [RFC2486] [I-D.ietf-radext-rfc2486bis],
and the ability of the AAA network to route requests to the domain
indicated in the NAI.
Within the IETF ROAMOPS WG, a number of additional approaches were
considered for this, including source routing techniques based on the
NAI, and techniques relying on the AAA infrastructure. Given the
relative simplicity of the roaming implementations described in RFC
2194 [RFC2194], static routing mechanisms appeared adequate for the
task and it was not deemed necessary to develop dynamic routing
protocols.
As noted in RFC 2607 [RFC2607], 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 standardized
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
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 7]
Internet-Draft Network Discovery and PS October 2005
connection to the home realm without having to utilize a network of
proxies. For instance, the Redirect feature could be used to provide
a centralized routing function for AAA, without having to know all
home network names in all access networks.
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, 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.
2.3.1 The Incomplete Routing Table Problem
No dynamic routing protocols are in use in AAA infrastructure today.
This implies that there has to be a device (such as a proxy) within
the access network that knows how to route to different domains, even
if they are further than one hop away, as shown in Figure 2. In this
figure, the user "joe@corp3.com" has to be authenticated through ISP
2, since the domain "corp3.com" is served by it.
+---------+ +---------+
| | | |
User "joe | Access |--------->| ISP 1 |-------> "corp1.com"
@corp3.com"-->| Network | | |
| | +---------+
+---------+
|
|
\|/
+---------+
| |--------> "corp2.com"
| ISP 2 |
| |--------> "corp3.com"
+---------+
Figure 2: AAA routing problem
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 8]
Internet-Draft Network Discovery and PS October 2005
2.3.2 The User Selection Problem
A related issue is that the roaming relationship graph may have
ambiguous routes, as shown in Figure 3. As billing is based on AAA
and pricing may be based on the used intermediaries, it is necessary
to select which route is used. For instance, in Figure 3, access
through the roaming group 1 may be cheaper, than if roaming group 2
is used. For commercial reasons, intermediaries want to participate
the AAA transaction.
+---------+
| |---------> "isp1.com"
| Roaming |
+---------+ | Group 1 |
| |-------->| |---------> "isp2.com"
User "joe | Access | +---------+
@isp1.com"--->| Network |
| | +---------+
| |-------->| |---------> "isp1.com"
+---------+ | Roaming |
| Group 2 |
| |---------> "isp3.com"
+---------+
Figure 3: Ambiguous AAA routing
Currently planned networks include one level with a small number of
intermediaries, just a few now and perhaps up to 50 as a maximum.
However, multiple levels and higher number of alternative networks
are possible in theory.
There have been requests to place credential and AAA route selection
under user control, as the user is affected by the pricing and other
differences. Optionally, automatic tools could make the selection
based on the user's preferences. On the other hand, user control is
similar to source routing, and as discussed earlier, network-based
routing mechanisms have traditionally won over source routing-based
mechanisms.
If users can control the selection of intermediaries, such
intermediaries still have to be legitimate AAA proxies. That is, an
access network should not send a request to an unknown intermediary.
If it has a business relationship with three intermediaries int1.com,
int2.com, and int3.com, it will route the request through one of
them, even if the user tried to request routing through mitm.org.
Thus, NAI-based source routing is not source routing in the classic
sense. It is merely suggesting preferences among already established
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 9]
Internet-Draft Network Discovery and PS October 2005
routes. If the route does not already exist, or is not feasible,
then NAI-based source routing cannot establish it.
An additional issue is that even if the intermediaries are
legitimate, they could be switched. For instance, an access network
could advertise that it has a deal with cheapintermediary.net, and
then switch the user's selection to priceyintermediary.com instead.
To make this relevant, the pricing would have to be based on the
intermediary. Even if it were possible to secure this selection, it
would not be possible to guarantee that QoS or other properties
claimed by the network were indeed provided. As a result, it may be
useful to think of the intermediary selection only as a hint.
Only a limited amount of information about AAA routes or pricing
information can be dynamically communicated [eronendimacs]. It is
necessary to retrieve network and intermediary names, but quality of
service or pricing information is clearly something that would need
to be pre-provisioned, or perhaps just available via the web.
Similarly, dynamic communication of network names can not be expected
to provide all possible home network names, as their number can be
quite large globally.
As a result, network-based AAA routing mechanisms are preferred over
user-based selection where sufficient routes have been configured and
there is no need for user control. Where these conditions are not
met -- particularly when an attempt to use the network-based routing
mechanism has failed -- routing hints can be placed in an NAI as
defined in [RFC2486] [I-D.ietf-radext-rfc2486bis]. Where NAIs are
used in this manner, the AAA routing problem becomes a subset of the
identifier selection problem.
2.4 Payload Routing
The access network, mediating AAA infrastructure, and the home
network may all have a desire to affect the kind of treatment payload
packets get. This includes filtering, prioritization, routing paths,
and mandatory tunneling.
Traditionally, the involved entities have been able to provide some
control of this through AAA protocols such as RADIUS [RFC2865] and
Diameter [RFC3588]. RFC 2868 [RFC2868] defines tunneling attributes
that the home and mediating networks can use to establish mandatory
tunneling at the access network. RFC 3588 [RFC3588] defines a filter
syntax which can be used to install per-session filters under the
control of AAA.
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 10]
Internet-Draft Network Discovery and PS October 2005
2.4.1 Issues with Payload Routing
In an attack described by Michael Richardson, a rogue hotspot
operator (but with a legitimate roaming relationship to a home
network) steals revenues from local hotspot operator by spoofing its
identity. The rogue operator places a node with two interfaces in
the coverage area of the local operator, and attaches to the Internet
via this operator using a flat fee -based account. It then starts to
advertise itself as a hotspot operator on the other interface, luring
unsuspecting clients to use this node rather the than the local
operator. The users authenticate via this node and its roaming
relationship. All AAA and payload traffic goes via the local
hotspot, suitably NATted by the rogue node. As a result, the rogue
operator gets the roaming service fees for a number of clients,
whereas the local operator gets just one client.
Due to the way that the IEEE 802.11, IETF protocols, and common EAP
methods have been designed, the rogue operator can actually advertise
the same identity (SSID) as the local operator; the parameters
advertised by the access point information are not authenticated end-
to-end to the home network. EAP methods that support channel
bindings [RFC3748] do not have this problem, but this support is not
present in commonly used methods. Rogue access point can present a
different set of parameters to the client and to the home network.
The current network access mechanisms enable us to have
authentication, and link layer protection. They do not, however,
guarantee anything about the delivery of the actual payload packets.
In particular, there is no guarantee that the payload packets are
delivered through a right route, or NATed only up to some specific
number of times.
We call this the "payload route binding problem". In this problem,
authentication and link layer support do not guarantee that the
packets are actually routed through the path that appears to have
been offered. Basically, if the "rogue" access point has a flat fee
account and a contract with a clearing house, it can offer access to
anyone with a per-byte account, NAT their packets, and send the
traffic forward on its own account, and generate income. The local
ISP would not be able to detect this by looking at the traffic
stream. The user would not be able to detect it either, unless an
EAP method with channel binding support is used. And even if it is,
the user may not care about the identity of the access point enough
to look at it; channel bindings can only ensure that all parties
agree about the parameters, not that they make sense.
The working group did not come to a conclusion whether this attack
needs to be prevented. Some of the proposed solutions include the
use of EAP EMSK in the authentication exchange with the DHCP server,
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 11]
Internet-Draft Network Discovery and PS October 2005
or the use of EAP to provide the certificates that SEND requires for
the authentication of Router Advertisements. Either approach means
that we are sure we are speaking at layer 3 to the services that we
authenticated at layer two. However, this does not prevent an
attacker from offering such services, and then performing a NAT on
the packets later. However, IPsec could be used to detect the
presence of such NATs, even if NAT traversal is in use.
2.5 Discovery, Decision, and Selection
An alternative decomposition of the problem is to consider the
discovery, decision, and selection aspects separately. Discovery
consists of discovering access networks and associated POPs,
discovering what identities the access networks will accept (either
directly or through roaming relationships), and discovering which
potential AAA intermediaries or routes exist.
Selection consists of attaching to the "right" access network and
POP, offering an identity through EAP Identity Response, and
providing a hint about the desired AAA intermediary. The selection
of the AAA intermediary, along with the home and access networks,
determines also the treatment of payload packets.
Decision can be either manual selection or automatic. Most likely,
automatic mechanisms are preferred, even if manual selection should
be retained as a fallback. The type of the decision also places
additional requirements on the type of information that the discovery
phase must provide. Just knowing which choices are available is
probably enough for manual selection. Unfortunately, automatic
selection based on a list of choices is by itself not possible:
o Some access networks may be preferred over others. For instance,
the user's private corporate network may be preferred over a
public network due to cost and efficiency reasons.
o Similarly, some credentials may be preferred over others.
o Use of an access network with direct connection to home network
may be preferred over using mediating networks.
o Some mediating networks may be preferred to others, for example
based on cost or QoS. Note that optimizing cost is not a trivial
problem, because the total cost may be a combination of a fixed
fee, per-minute, per-megabyte, volume discounts, and so on.
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 12]
Internet-Draft Network Discovery and PS October 2005
o Preferences may come from the user, his or her employer (who's
paying the bill), home network, or access network.
Different discovery mechanisms can accommodate such preferences in
various ways. Some user input or perhaps a pre-provisioned database
seems inevitable.
Finally, while the final step of choosing a new network lies always
on the client side, different approches vary in how much they rely on
the client vs. network driven decisions. In cellular networks, for
instance, the network-based performance measurements lead to
instructions that the network gives to the client about the
appropriate base station(s) that should be used. Most of the
processing and decisions are performed on the network side. In
contrast, in a completely client-driven approach the client may get
some raw information from the network, but makes all decisions by
itself.
2.6 Type of Information
A third alternative way to decompose the problem is to analyze the
type of information which is required [I-D.groeting-eap-netselection-
results]. For instance, access network discovery may benefit from
getting knowledge about the quality of service available from a
particular access network or node, and AAA routing may require
knowledge of roaming agreements. References [I-D.groeting-eap-
netselection-results] and [IEEE.11-04-0624] describe the following
categories of information which can be discovered:
o Access network identification
o Roaming agreements
o Authentication mechanisms
o Quality of service
o Cost
o Authorization policy
o Privacy policy
o Service parameters, such as the existence of middleboxes
The nature of the discovered information can be static, such as the
fastest available transmission speed on a given piece of equipment.
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 13]
Internet-Draft Network Discovery and PS October 2005
Or it can be dynamic, such as the current load on this equipment.
The information can describe something about the network access nodes
themselves, or it can be something that they simply advertise on
behalf of other parts of the network, such as roaming agreements
further in the AAA network.
Typically, it would be desirable to acquire all this information
prior to the authentication process. In some cases it is in fact
necessary, if the authentication process can not complete without the
information. Reference [IEEE.11-04-0624] classifies the possible
steps at which IEEE 802.11 networks can acquire this information:
o Pre-association
o Post-association (or pre-authentication)
o Post-authentication
Note that some EAP methods (such as those defined in [I-D.josefsson-
pppext-eap-tls-eap] [I-D.tschofenig-eap-ikev2] [I-D.arkko-eap-
service-identity-auth]) have an ability to agree about additional
parameters during an authentication process. While such parameters
are useful for many purposes, their use for network selection suffers
from an obvious chicken-and-egg problem. Or at least it seems costly
to run a relatively heavy authentication process to decide whether
the client wants to attach to this network.
3. Design Constrains
All solutions to the network selection and discovery problem must
satisfy the following additional constraints:
o AAA routing mechanisms have to work for requests, responses, as
well as server-initiated messages.
o Solution is compatible with all AAA protocols.
o Does not prevent the introduction of new AAA or access network
features, such as link-state AAA routing protocols or fast
handoffs.
o Does not consume a significant amount of resources, such as
bandwidth or increase network attachment time.
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 14]
Internet-Draft Network Discovery and PS October 2005
o Does not cause a problem with limited packet sizes of current
protocols.
o Where new protocol mechanisms are required, it should be possible
to deploy the solution without requiring changes to the largest
base of installed devices -- network access servers, wireless
access points, and clients.
o Similarly, new solutions should allow interoperability with
clients, access networks, AAA proxies, and AAA servers that have
not been modified to support network discovery and selection.
4. Existing Work
4.1 IETF
There has already been a lot of past work in this area, including a
number of IETF Proposed Standards generated by the ROAMOPS WG. The
topic of roaming was considered different enough from both AAA and
access protocols such as PPP that it deserved its own WG.
In addition to work on ROAMOPS directly relating to the problem,
there has been work in SEAMOBY relating to scaling of network
discovery mechanisms; work in PKIX relating to identity and
credential selection; and work in AAA WG relating to access routing.
The PANA protocol [I-D.ietf-pana-pana] has a mechanism to advertise
and select "ISPs" through the exchange of the ISP-Information AVP in
its initial exchange.
A number of (small) improvements to payload routing control are
currently in progress in the IETF RADEXT WG. These include better
filtering and redirection support [I-D.ietf-radext-ieee802]. RADEXT
WG is also working on an new revision of the NAI specification
[I-D.ietf-radext-rfc2486bis]. This revision clarifies the use of the
'!' syntax in a NAI to route requests via specified mediating
networks.
Adrangi et al [I-D.adrangi-eap-network-discovery] discuss the use of
the EAP-Request/Identity for identifier selection. It is necessary
to have this kind of a mechanism, as clients may have more than one
credential, and when combined with the '!' syntax for NAIs, it can
also be used for mediating network discovery and selection. The use
of lower-layer information may also be limited in terms of
discovering identifiers that are used on the EAP layer. In the
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 15]
Internet-Draft Network Discovery and PS October 2005
longer term, the use of this mechanism may run into scalability
problems, however. 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 networks,
although if SSIDs are used, the maximum length of 32 octets per SSID
may provide somewhat better scaling. The use of other network
identifiers than domain names is also possible, for instance the PANA
protocol uses an a free form string and an SMI Network Management
Private Enterprise Code [I-D.ietf-pana-pana], or Mobile Network Codes
embedded in NAIs as specified in 3GPP.
As noted in [Pasi58], the use of the EAP-Request/Identity for network
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 networks are supported. Since IEEE 802.11-1999 does
not support use of Class 1 data frames in State 1 (unauthenticated,
unassociated) within an ESS, this implies either that the APs must
support 802.1X pre-authentication (optional in IEEE 802.11i) or that
the station must associate with each AP prior to sending an EAPOL-
Start to initiate EAP. This will dramatically increase handoff
latency.
The effects to handoff latency depend also on the specific protocol
design, and the expected likelihood of having to provide
advertisements and initiate scanning of several access points. The
use of advertisements only as a last resort when the AAA routing has
failed is a better approach than the use of advertisement - scanning
procedure on every attachment.
Furthermore, if the AP has not been updated to present an up to date
set of networks in the EAP-Requests/Identity, after associating to
candidate APs and then choosing one, it is possible that the station
will find that the chosen network is not supported after all. In
this case, the station's EAP-Response/Identity may be answered with
an updated EAP-Request/Identity, adding more latency.
4.2 IEEE
There has been work in IEEE 802.11, IEEE 802.21 and 802.1 relating to
network discovery enhancements.
Some recent contributions in this space include the following:
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 16]
Internet-Draft Network Discovery and PS October 2005
o [IEEE.802.11-1999] defines the Beacon and Probe Response
mechanisms used with IEEE 802.11. Unfortunately, Beacons are only
sent at the lowest supported rate. Studies such as [MACScale]
have identified MAC layer performance problems, and [Velayos] have
identified scaling issues resulting 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
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 analyze these scalability issues in relation to those
existing in other alternative solutions, however.
o [IEEE-11-03-0843] discusses requirements for differentiation in
the way that the user's payload traffic is routed, based on home
network control. Such requirements have come up, for instance, in
the context of 3GPP.
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 (formerly the WIEN Study Group) recently completed a
set of requirements [11-05-0822-03-000u-tgu-requirements]. The
group is looking into the network discovery and selection problem
as part of its requirements. The requirements related to network
discovery and selection include the functionality by which a
station can determine whether its subscription to a service
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 17]
Internet-Draft Network Discovery and PS October 2005
provider would allow it to access a particular 802.11 AN before
actually joining a BSS within that 802.11 AN. The mechanism
should be able to handle multiple credentials from the same user
and be able to select the correct credentials. Another
requirement is the support for authentication with multiple
service providers through a single functionality by which a WLAN
station can determine which interworking services are available
before joining a BSS. In addition, there is an optional
requirement for a functionality by which APs can advertise (before
connection) the charges that will be made for use of the network
if connection is authorized based on a subscription.
o IEEE 802.21 is developing standards to enable handover and
interoperability between heterogeneous network types including
both 802 and non 802 networks. The intention is to provide a
general information transfer capability for these purposes. As a
result, network discovery process may benefit from such standards.
Part of handover process is the discovery of candidate networks
and selection of a network for a handover. The IEEE 802.21 group
is looking into various information elements that can be used to
provide sufficient information to either a network node or the
terminal to make network selection possible. Both link layer and
layer 3 delivery mechanisms are being looked into. Layer 3
protocol development is being looked into in IETF MIPSHOP WG.
Different query mechanisms between the terminal and the network,
including using of XML or basic TLV type interaction are being
explored.
4.3 3GPP
The 3GPP stage 2 technical specification [3GPPSA2WLANTS] covers the
architecture of 3GPP Interworking WLAN with 2G and 3G networks. This
specification discusses also network discovery and selection issues.
The specification requires that Access Network Discovery is performed
as specified in the standards for the relevant WLAN link layer
technology. An early version of the technical specification required
the use of a 3GPP-specific SSID, but that has since then been
abandoned; access network or local 3GPP network based SSIDs may be
used instead.
In addition to Access Network Discovery, it is necessary to select
intermediary networks for the purposes of AAA Routing. In 3GPP,
these networks are called Visited Public Land-based Mobile Networks
(VPLMNs), and it is assumed that WLAN networks may have a contract
with more than one VPLMN. GSM/UMTS roaming principles are then
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 18]
Internet-Draft Network Discovery and PS October 2005
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 VPLMN, the following is required:
o User may choose the desired VPLMN manually or let the WLAN User
Equipment (WLAN UE) choose the the VPLMN automatically based on
the user and operator defined preferences.
o AAA message are routed according to the (root) NAI or decorated
NAI.
o Existing EAP mechanisms are used where possible.
o Extensibility is desired, to allow the advertisement of other
parameters later. The current network advertisement and selection
is based on [I-D.adrangi-eap-network-discovery].
Ahmavaara, Haverinen, and Pichna [WLAN3G] discuss the new network
selection requirements that 3G-WLAN roaming introduces. It is
necessary to support automatic network selection, and not just manual
selection by the user. There may be multiple levels of networks, the
hotspot owner may have a contract with a provider who in turn has a
contract with one 3G network, and this 3G network has a roaming
capability with a number of other networks.
The 3GPP Interworking WLAN technical specifications state that
advertisement information shall be provided only when the access
network is unable to route the request using normal AAA routing
means, such as when it sees an unknown NAI domain. It is also stated
that where VPLMN control is required, the necessary information is
added to a NAI. Furthermore, the WLAN UE may manually trigger the
network advertisement by using Alternative NAI in EAP Request/
Identity. The Alternative NAI is quaranteed to be an unknown NAI
domain throughout all 3GPP networks.
The security requirements for 3GPP Interworking WLAN have been
specified in the 3GPP stage 3 technical specification
[3GPPSA3WLANTS]. The security properties related to different
mediating network selection mechanisms have been discussed earlier in
the 3GPP contribution [3GPP-SA3-030736], which concludes that both
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 19]
Internet-Draft Network Discovery and PS October 2005
SSID- and EAP-based mechanisms have roughly similar (and very
limited) security properties, and that, as a result, network
advertisement should be considered only as hints.
The referenced 3GPP stage 2 and stage 3 technical specifications are
for 3GPP Release-6 network architecture. Next generation 3GPP
Release-7 architecture may change the network advertisement and
selection technical solution as well as the general requirements.
There is ongoing stage 1 work in 3GPP Service and System Aspects
group (SA1) of reviewing the principles of network selection
[3GPPSA1NETSELTR]. There seems to be considerable interest in adding
greater HPLMN control over the network selection procedure and a
capability of dynamically initiating a reselection of the earlier
selected network. The current technical report acknowledges that
there is not yet mechanism to implement reselection in non 3GPP
access technologies such as WLAN.
4.4 Other
[INTELe2e] discusses the need for network selection in a situation
where there is more than one available access network with a roaming
agreement to the home network. It also lists EAP-level, SSID-based,
and PEAP-based mechanisms as potential solutions to the network
selection problem.
Eijk et al [WWRF-ANS] discussed the general issue of network
selection. They concentrated primarily on the Access Network
Discovery problem, based on various criteria, and did not consider
the other aspects of the network selection problem. Nevertheless,
they mention that one of the network selection problems is that the
information about accessibility and roaming relationships is not
stored in one location, but rather spread around the network.
5. Conclusions
The issues surrounding the network discovery and selection problem
have been summarized.
In the opinion of the editors of this document, the main findings
are:
o There is a clear need for access network discovery, identifier
selection, AAA routing, and payload routing.
o Existing mechanisms appear largely sufficient for the control of
payload routing, even if some minor improvements are being worked
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 20]
Internet-Draft Network Discovery and PS October 2005
on. But there appears to be justification for significantly
enhanced mechanisms relating to access network discovery,
identifier selection, and AAA routing.
o Identifier selection and AAA routing problems can and should be
seen as the different aspects of the same problem, identifier
selection.
o Nevertheless, many of the problems discussed in this draft are
very hard when one considers them in an environment that requires
a potentially large number of networks, fast handoffs, and
automatic decisions.
o The proliferation of multiple competing network discovery
technologies within IEEE 802, IETF, and 3GPP appears to a
significant problem going forward. In the absence of a clearly
defined solution to the problem it is likely that any or all of
these solutions will be utilized, resulting in industry
fragmentation and lack of interoperability.
In order to avoid this fate, it is strongly suggested that a
discussion be initiated between IETF and IEEE 802 in order to work
out the roles of the each organization in solving this problem,
and to invite 3GPP participation so that their requirements can be
fulfilled by the planned solutions.
o New link layers should be designed with facilities that enable the
efficient distribution of network advertisement information.
o Solving all problems with current link layers and existing network
access devices may not be possible. It may be useful to consider
a phased approach where only certain, limited functions are
provided now, and the full functionality is provided when
extensions to current link layers become available.
We will briefly comment on the specific mechanisms related to network
discovery and selection:
o As noted in studies such as [MACScale] and [Velayos], 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
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 21]
Internet-Draft Network Discovery and PS October 2005
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 these enhancements it is not feasible to advertise
more than 50 different networks using existing mechanisms, and
probably significantly less in most circumstances.
As a result, there appears to be justification for enhancing the
scalability of network advertisements.
o Work is already underway in IEEE 802.1, IEEE 802.21 and the IEEE
802.11u to provide enhanced discovery functionality. For example,
IEEE 802.1ab enables network devices to announce themselves and
provide information on their capabilities. Similarly, the IEEE
802.1af has discussed the idea of supporting network discovery
within a future revision to IEEE 802.1X. However, neither IEEE
801.ab nor IEEE 802.1af is likely to address the transport of
large quantities of data where fragmentation would be a problem.
Another typical limitation of link layer assistance in this area
is that in general, it would be desirable to retrive also
information relating to the potential next access networks or
access points. However, such networks may be of another type than
the current one, so the link layer would have to carry information
relating to other types of link layers as well. This is possible,
but requires coordination among different groups in the industry.
o Given that EAP does not support fragmentation of EAP-Request/
Identity packets, and that use of EAP for network selection on all
attachments will have a substantial adverse impact on roaming
performance without appropriate lower layer support (such as
support for Class 1 data frames within IEEE 802.11), the use of
EAP is limited. For instance, the use of EAP to carry quality of
service as proposed in [I-D.groeting-eap-netselection-results]
seems hard given the limitations. Long-term, it makes more sense
for the desired functionality to be handled either within IEEE 802
or at the IP layer. However, a strictly limited discovery
mechanism such as the one defined in [I-D.adrangi-eap-network-
discovery] is useful.
o In the IETF, a potential alternative is use of the SEAMOBY CARD
protocol [RFC4066], which enables advertisement of network device
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 22]
Internet-Draft Network Discovery and PS October 2005
capabilities over IP. Another alternative is the recently
proposed 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.
A limitation of these IP layer solutions is that they can only
work as a means to speed up the attachment procedures when moving
from one location to another; when a node starts up, it needs to
be able to attach to a network before IP communications are
available. This is fine for optimizations, but precludes the use
in a case where the discovery information is mandatory before
successful attachment can be accomplished, for instance when the
access network is unable to route the AAA request unaided.
o "Phone-book" based approaches such as RFC 3017 appear attractive
due to their ability to provide sufficient information for
automatic selection decisions. However, there is no experience on
applying such approaches to wireless access. The number of WLAN
access points is significantly higher than the number of dial-in
POPs; the distributed nature of the access network has created a
more complicated business and roaming structure, and the expected
rate of change in the information is high. As noted in [pri04]
and [I-D.groeting-eap-netselection-results], a large fraction of
current WLAN access points operate on the default SSID, which may
make the use of the phone book approach hard.
Finally, to address some of the security concerns that have come up
during this work, the IETF should in any case initiate work that
enables support for channel bindings in methods. Preferably, popular
methods should be updated, ensuring compatibility with existing
deployments. The representation of link layer parameters within EAP
should utilize a common framework, to make it easier to define new
link layers and keep the selection of EAP methods independent of the
link layer. A number of proposals exist in this space, but none of
them have yet been adopted by the EAP WG as work items.
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
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 23]
Internet-Draft Network Discovery and PS October 2005
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.
7. References
7.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.
[RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang,
"Review of Roaming Implementations", RFC 2194,
September 1997.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000.
[RFC3017] Riegel, M. and G. Zorn, "XML DTD for Roaming Access Phone
Book", RFC 3017, December 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 24]
Internet-Draft Network Discovery and PS October 2005
RFC 3748, June 2004.
[RFC3770] Housley, R. and T. Moore, "Certificate Extensions and
Attributes Supporting Authentication in Point-to-Point
Protocol (PPP) and Wireless Local Area Networks (WLAN)",
RFC 3770, May 2004.
7.2 Informative References
[11-05-0822-03-000u-tgu-requirements]
Moreton, M., "TGu Requirements", IEEE Contribution 11-05-
0822-03-000u-tgu-requirements, August 2005.
[3GPP-SA3-030736]
Ericsson, "Security of EAP and SSID based network
advertisements", 3GPP Contribution S3-030736,
November 2003.
[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.
[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.
[3GPPSA1NETSELTR]
3GPP, "3GPP Technical Specification Group Services and
Systems Aspects; Review of Network Selection Principles;
(Release 7); Stage 1", 3GPP Technical Report 22.811 v
1.0.0, June 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.
[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.
[Fixingapsel]
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 25]
Internet-Draft Network Discovery and PS October 2005
Judd, G. and P. Steenkiste, "Fixing 802.11 Access Point
Selection", Sigcomm Poster Session 2002.
[I-D.adrangi-eap-network-discovery]
Adrangi, F., "Mediating Network Discovery in the
Extensible Authentication Protocol (EAP)",
draft-adrangi-eap-network-discovery-14 (work in progress),
August 2005.
[I-D.adrangi-eap-network-discovery-and-selection]
Adrangi, F., "Network Discovery and Selection within the
EAP Framework",
draft-adrangi-eap-network-discovery-and-selection-01 (work
in progress), March 2004.
[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-03 (work in
progress), July 2004.
[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.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-17 (work in progress),
October 2004.
[I-D.ietf-pana-pana]
Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", draft-ietf-pana-pana-05 (work in
progress), July 2004.
[I-D.ietf-radext-ieee802]
Congdon, P., "VLAN, Priority, and Filtering Attributes",
draft-ietf-radext-ieee802-00 (work in progress),
July 2005.
[I-D.ietf-radext-rfc2486bis]
Aboba, B., "The Network Access Identifier",
draft-ietf-radext-rfc2486bis-01 (work in progress),
October 2004.
[I-D.josefsson-pppext-eap-tls-eap]
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 26]
Internet-Draft Network Discovery and PS October 2005
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-03 (work in progress),
February 2004.
[IEEE-11-03-0827]
Hepworth, E., "Co-existence of Different Authentication
Models", IEEE Contribution 11-03-0827 2003.
[IEEE-11-03-0843]
Hong, C. and T. Yew, "Interworking - WLAN Control", IEEE
Contribution 11-03-0843 2003.
[IEEE-11-03-154r1]
Aboba, B., "Virtual Access Points", IEEE Contribution 11-
03-154r1, May 2003.
[IEEE-11-03-417r2]
Mishra, A., "Improving the latnecy of the Probe Phase
during 802.11 Handoff", IEEE Contribution 11-03-417r2,
May 2003.
[IEEE.11-04-0624]
Berg, S., "Information to Support Network Selection", IEEE
Contribution 11-04-0624 2004.
[IEEE.802.11-1999]
Institute of Electrical and Electronics Engineers,
"Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Standard 802.11, 1999.
[IEEE.8021x]
Institute of Electrical and Electronics Engineers, "Local
and Metropolitan Area Networks: Port-Based Network Access
Control", IEEE Standard 802.1X, September 2001.
[INTELe2e]
Intel, "Wireless LAN (WLAN) End to End Guidelines for
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 27]
Internet-Draft Network Discovery and PS October 2005
Enterprises and Public Hotspot Service Providers",
November 2003.
[MACScale]
Heusse, M., "Performance Anomaly of 802.11b", LSR-IMAG
Laboratory, Grenoble, France, IEEE Infocom 2003.
[Pasi58] Eronen, P., "Network Selection Issues", presentation to
EAP WG at IETF 58, November 2003.
[RFC4066] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E.
Shim, "Candidate Access Router Discovery (CARD)",
RFC 4066, July 2005.
[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.
[WLAN3G] Ahmavaara, K., Haverinen, H., and R. Pichna, "Interworking
Architecture between WLAN and 3G Systems", IEEE
Communications Magazine, November 2003.
[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.
[eronendimacs]
Eronen, P. and J. Arkko, "Role of authorization in
wireless network security", Extended abstract presented in
the DIMACS workshop, November 2004.
[pri04] Priest, J., "The State of Wireless London", July 2004.
Authors' Addresses
Jari Arkko
Ericsson
Jorvas 02420
Finland
Email: jari.arkko@ericsson.com
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 28]
Internet-Draft Network Discovery and PS October 2005
Bernard Aboba
Microsoft
One Microsoft Way
Redmond, WA 98052
USA
Email: aboba@internaut.com
Appendix A. Contributors
Version 00 of this draft was based on the discussion held on the EAP
WG mailing list in December 2003, and on a number of input documents
such as [I-D.adrangi-eap-network-discovery-and-selection]. 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 version 01 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.
Version 03 of this draft was edited and updated by Jouni Korhonen and
Farooq Bari.
Appendix B. Modifications from Version 00
The following modifications have been incorporated to the -01 version
of this draft:
o Added a discussion of new IETF protocol documents relating to this
problem, such as [I-D.adrangi-eap-network-discovery], [I-D.ietf-
radext-rfc2486bis], [I-D.ietf-radext-ieee802], , and [I-D.arkko-
eap-service-identity-auth].
o Added references to a number of new documents that discuss the
network selection problem.
o Added pointers to new IEEE work in this area.
o Added a discussion of what type of information may need to be
discovered and when (Section 2.6).
o Added a discussion relating to the use of phone books in an
environment where network identifiers are not being regularly set.
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 29]
Internet-Draft Network Discovery and PS October 2005
o Added a discussion of network-based control in Section 2.5.
o Updated the conclusions.
The following modifications have been incorporated to the -03 version
of this draft:
o Updated the 3GPP section, including notes on the new in progress
network selection work.
o Checked and updated all changed informative references.
o Replaced 'I-D.lior-radius-redirection' with 'I-D.ietf-radext-
ieee802'.
o Replaced 'I-D.ietf-seamoby-card-protocol' with 'RFC4066'.
o Added reference to 3GPP SA1 Network Selection TR28.11 v1.0.0.
o Added reference to 3GPP SA3 WLAN Security TS.
o Added reference to 3GPP CT1 WLAN User Equipment TS.
o Added reference to 3GPP CT4 WLAN Core Network TS.
o Updated IEEE Activities in IEEE 802.11u (formerly IEEE WIEN Study
Group)
o Updated IEEE Activities in IEEE 802.21
o Removed reference to a IEEE WIEN document
o Added reference to IEEE 802.11u requirements document
o Performed minor editorial changes and text cleanup throughout the
document
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 30]
Internet-Draft Network Discovery and PS October 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Arkko & Aboba, Eds. Expires April 26, 2006 [Page 31]
