draft-ietf-eap-netsel-problem-01.txt   eapns.txt 
Extensible Authentication Protocol J. Arkko Extensible Authentication Protocol J. Arkko
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: January 15, 2005 B. Aboba, Eds. Expires: April 25, 2005 B. Aboba, Eds.
Microsoft Microsoft
July 17, 2004 October 25, 2004
Network Discovery and Selection Problem Network Discovery and Selection Problem
draft-ietf-eap-netsel-problem-01 draft-ietf-eap-netsel-problem-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with author represents that any applicable patent or other IPR claims of
RFC 3667. which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2005. This Internet-Draft will expire on April 25, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
The so called network discovery and selection problem affects network The so called network discovery and selection problem affects network
access, particularly in the presence of multiple available wireless access, particularly in the presence of multiple available wireless
accesses and roaming. This problem has been the subject of accesses and roaming. This problem has been the subject of
discussions in various standards bodies. This document summarizes the discussions in various standards bodies. This document summarizes
discussion held about this problem in the Extensible Authentication the discussion held about this problem in the Extensible
Protocol (EAP) working group at the IETF. The problem is defined and Authentication Protocol (EAP) working group at the IETF. The problem
divided into subproblems, and some constraints for possible solutions is defined and divided into subproblems, and some constraints for
are outlined. The document presents also some existing mechanisms possible solutions are outlined. The document presents also some
which help solve at least parts of the problem, and gives some existing mechanisms which help solve at least parts of the problem,
suggestions on how to proceed for the rest. and gives some suggestions on how to proceed for the rest.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Definition . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Definition . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Access Network Discovery . . . . . . . . . . . . . . . 4 2.1 Access Network Discovery . . . . . . . . . . . . . . 4
2.1.1 Issues with Access Network Discovery . . . . . . 5 2.2 Identity selection . . . . . . . . . . . . . . . . . 5
2.2 Identity selection . . . . . . . . . . . . . . . . . . 5 2.3 AAA routing . . . . . . . . . . . . . . . . . . . . 7
2.3 AAA routing . . . . . . . . . . . . . . . . . . . . . 7 2.3.1 The Incomplete Routing Table Problem . . . 8
2.3.1 Issues with AAA Routing . . . . . . . . . . . . 8 2.3.2 The User Selection Problem . . . . . . . . 8
2.4 Payload Routing . . . . . . . . . . . . . . . . . . . 10 2.4 Payload Routing . . . . . . . . . . . . . . . . . . 10
2.4.1 Issues with Payload Routing . . . . . . . . . . 10 2.4.1 Issues with Payload Routing . . . . . . . 10
2.5 Discovery, Decision, and Selection . . . . . . . . . . 11 2.5 Discovery, Decision, and Selection . . . . . . . . . 11
2.6 Type of Information . . . . . . . . . . . . . . . . . 12 2.6 Type of Information . . . . . . . . . . . . . . . . 13
3. Design Constrains . . . . . . . . . . . . . . . . . . . . . 14 3. Design Constrains . . . . . . . . . . . . . . . . . . . . . . 14
4. Existing Work . . . . . . . . . . . . . . . . . . . . . . . 15 4. Existing Work . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1 IETF . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1 IETF . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 IEEE . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2 IEEE . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3 3GPP . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4 Other . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4 Other . . . . . . . . . . . . . . . . . . . . . . . 18
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
Normative References . . . . . . . . . . . . . . . . . . . . 23 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Informative References . . . . . . . . . . . . . . . . . . . 24 7.1 Normative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 7.2 Informative References . . . . . . . . . . . . . . . . 24
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
B. Modifications from Version 00 . . . . . . . . . . . . . . . 28 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . 29 B. Modifications from Version 00 . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . 30
1. Introduction 1. Introduction
The so called network discovery and selection problem affects network The so called network discovery and selection problem affects network
access and wireless access networks in particular. This problem comes access and wireless access networks in particular. This problem
relevant when any of the following conditions are true: comes relevant when any of the following conditions are true:
o There is more than one available network attachment point, and the o There is more than one available network attachment point, and the
different points may have different characteristics. different points may have different characteristics.
o The user has multiple sets of credentials. For instance, the user o The user has multiple sets of credentials. For instance, the user
could have one set of credentials from a public service provider could have one set of credentials from a public service provider
and another set from his company. and another set from his company.
o There is more than one way to provide roaming between the access o There is more than one way to provide roaming between the access
and home network, and service parameters or pricing differs and home network, and service parameters or pricing differs
between them. For instance, the access network could have both a between them. For instance, the access network could have both a
direct relationship with the home network and an indirect direct relationship with the home network and an indirect
relationship through a roaming consortium. relationship through a roaming consortium.
o The roaming relationships between access and home networks are so o The roaming relationships between access and home networks are so
complicated that current AAA protocols can not route the requests complicated that current AAA protocols can not route the requests
to the home network unaided, just based on the domain in the given to the home network unaided, just based on the domain in the given
Network Access Identifier (NAI) [4, 14]. Network Access Identifier (NAI) [4, 19].
o Payload packets get routed or tunneled differently, based on which o Payload packets get routed or tunneled differently, based on which
particular roaming relationship variation is used. This may have particular roaming relationship variation is used. This may have
an impact on the available services or their pricing. an impact on the available services or their pricing.
o Providers share the same infrastructure, such as wireless access o Providers share the same infrastructure, such as wireless access
points. points.
The network discovery and selection problem spans multiple protocol The network discovery and selection problem spans multiple protocol
layers and has been the subject of discussions in IETF, 3GPP, and layers and has been the subject of discussions in IETF, 3GPP, and
skipping to change at page 4, line 29 skipping to change at page 4, line 29
figuring out how to route the authentication conversation figuring out how to route the authentication conversation
originating from the selected identity back to the home realm. originating from the selected identity back to the home realm.
o Finally, there is the the problem of "Payload routing" which o Finally, there is the the problem of "Payload routing" which
involves figuring how the payload packets are routed, where more involves figuring how the payload packets are routed, where more
advanced mechanisms than destination-based routing is needed. advanced mechanisms than destination-based routing is needed.
Alternatively, the problem can be divided to the discovery, decision, Alternatively, the problem can be divided to the discovery, decision,
and the selection components. The AAA routing problem, for instance, and the selection components. The AAA routing problem, for instance,
involves all components: discovery (which mediating networks are involves all components: discovery (which mediating networks are
available?), decision (choose the "best" one), and selection (this is available?), decision (choose the "best" one), and selection (client
the chosen network) components. tells the network which mediting network it has decided to choose)
components.
2.1 Access Network Discovery 2.1 Access Network Discovery
The Access Network Discovery problem has been extensively studied, The Access Network Discovery problem has been extensively studied,
see for instance the results of the IETF Seamoby WG, IEEE see for instance the results of the IETF Seamoby WG, IEEE
specifications on 802.11 wireless LAN beaconing and probing process, specifications on 802.11 wireless LAN beaconing and probing process,
studies (such as [38]) on the effectiveness of these mechanisms, and studies (such as [38]) on the effectiveness of these mechanisms, and
so on. so on.
Traditionally, the problem of discovering available networks has been Traditionally, the problem of discovering available networks has been
skipping to change at page 5, line 15 skipping to change at page 5, line 16
In IEEE 802.11 WLANs, the Beacon/Probe Request/Response mechanism In IEEE 802.11 WLANs, the Beacon/Probe Request/Response mechanism
provides a way for Stations to discover Access Points (APs), as well provides a way for Stations to discover Access Points (APs), as well
as the capabilities of those APs. Among the Information Elements as the capabilities of those APs. Among the Information Elements
(IEs) included within the Beacon and Probe Response is the SSID, a (IEs) included within the Beacon and Probe Response is the SSID, a
non-unique identifier of the network to which an Access Point is non-unique identifier of the network to which an Access Point is
attached. By combining network identification along with attached. By combining network identification along with
capabilities discovery, the Beacon/Probe facility provides the capabilities discovery, the Beacon/Probe facility provides the
information required for both network discovery and roaming decisions information required for both network discovery and roaming decisions
within a single mechanism. within a single mechanism.
2.1.1 Issues with Access Network Discovery
As noted in [37], the IEEE 802.11 Beacon mechanism does not scale As noted in [37], the IEEE 802.11 Beacon mechanism does not scale
well; with a Beacon interval of 100ms, and 10 APs in the vicinity, 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 approximately 32 percent of an 802.11b AP's capacity is used for
beacon transmission. In addition, since Beacon/Probe Response frames beacon transmission. In addition, since Beacon/Probe Response frames
are sent by each AP over the wireless medium, stations can only are sent by each AP over the wireless medium, stations can only
discover APs within range, which implies substantial coverage overlap discover APs within range, which implies substantial coverage overlap
for roaming to occur without interruption. for roaming to occur without interruption.
A number of enhancements have been proposed to the Beacon/Probe A number of enhancements have been proposed to the Beacon/Probe
Response mechanism in order to improve scalability and roaming Response mechanism in order to improve scalability and roaming
performance. These include allowing APs to announce capabilities of performance. These include allowing APs to announce capabilities of
neighbor APs as well as their own, as proposed in IEEE 802.11k; neighbor APs as well as their own, as proposed in IEEE 802.11k;
propagation of discovery information over IP, as handled in the CARD propagation of discovery information over IP, as handled in the CARD
protocol developed within the IETF SEAMOBY WG, etc. protocol developed within the IETF SEAMOBY WG, etc.
Typically scalability enhancement mechanisms attempt to get around Typically scalability enhancement mechanisms attempt to get around
Beacon/Probe Response restrictions by sending advertisements at the Beacon/Probe Response restrictions by sending advertisements at the
higher rates which are enabled one the station has associated with an higher rates which are enabled one the station has associated with an
AP. Since these mechanisms run over IP, they can utilize IP AP. Since these mechanisms run over IP, they can utilize IP
facilities such as fragmentation, which the link layer mechanisms may facilities such as fragmentation, which the link layer mechanisms may
not always be able to do. For instance, in IEEE 802.11, Beacon frames not always be able to do. For instance, in IEEE 802.11, Beacon
cannot use fragmentation because they are multicast frames, and frames cannot use fragmentation because they are multicast frames,
multicast frames are not acknowledged in 802.11. 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.
2.2 Identity selection 2.2 Identity selection
As networks proliferate, it becomes more and more likely that a given As networks proliferate, it becomes more and more likely that a given
EAP peer may have multiple identities and credential sets, available EAP peer may have multiple identities and credential sets, available
for use in different situations. For example, the EAP peer may have for use in different situations. For example, the EAP peer may have
an account with one or more Public WLAN providers; a corporate WLAN; an account with one or more Public WLAN providers; a corporate WLAN;
one or more wireless WAN providers. As a result, the EAP peer has to one or more wireless WAN providers. As a result, the EAP peer has to
decide which credential set to use when presented with a given set of decide which credential set to use when presented with a given set of
potential EAP authenticators. potential EAP authenticators.
skipping to change at page 6, line 38 skipping to change at page 6, line 40
Traditionally, hints useful in identity selection have also been Traditionally, hints useful in identity selection have also been
provided out-of-band. For example, via the RFC 3017 XML DTD [8], a provided out-of-band. For example, via the RFC 3017 XML DTD [8], a
client can select between potential POPs, and then based on client can select between potential POPs, and then based on
information provided in the DTD, determine the appropriate NAI to use information provided in the DTD, determine the appropriate NAI to use
with the selected POP. with the selected POP.
Perhaps the most typical case is a link layer that provides some Perhaps the most typical case is a link layer that provides some
information about the network before EAP is initiated. For instance, information about the network before EAP is initiated. For instance,
in IEEE 802.11 provides the SSID, though in some cases the client may 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 not learn about all the SSIDs supported by the given access point.
IKEv2 [19], the identity of the responder (typically the security In IKEv2 [18], the identity of the responder (typically the security
gateway) is provided in the same packet as the EAP Identity Request gateway) is provided as a part of the usual IKEv2 exchange.
is transported. In order to use this information in deciding the
right identity to use, the provided information has to either match In order to use this information in deciding the right identity to
with one of the client's home networks, or the client has to have use, the provided information has to either match with one of the
some other knowledge that enables to link the advertised network and client's home networks, or the client has to have some other
the home network. For instance, the client may be aware that his home knowledge that enables to link the advertised network and the home
network has a roaming contract with a given access network. 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 It is also possible for hints to be embedded within credentials. In
[11], usage hints are provided within certificates used for wireless [11], usage hints are provided within certificates used for wireless
authentication. This involves extending the client's certificate to authentication. This involves extending the client's certificate to
include the SSIDs with which the certificate can be used. include the SSIDs with which the certificate can be used.
Finally, some EAP implementations use the space after the NUL Finally, some EAP implementations use the space after the NUL
character in an EAP Identity Request to communicate some parameters character in an EAP Identity Request to communicate some parameters
relating to the network requesting EAP authentication. However, there relating to the network requesting EAP authentication. While there
is no standard interpretation of the field beyond the NUL character. is Standards Track RFC specifying the interpretation of the field
beyond the NUL character, [12] is widely expected to be used.
2.3 AAA routing 2.3 AAA routing
Once the identity has been selected, it is necessary for the Once the identity has been selected, it is necessary for the
authentication conversation to be routed back to the home realm. authentication conversation to be routed back to the home realm.
This is typically done today through the use of the Network Access This is typically done today through the use of the Network Access
Identifier (NAI), RFC 2486 [4, 14], and the ability of the AAA Identifier (NAI), RFC 2486 [4, 19], and the ability of the AAA
network to route requests to the domain indicated in the NAI. network to route requests to the domain indicated in the NAI.
Within the IETF ROAMOPS WG, a number of additional approaches were Within the IETF ROAMOPS WG, a number of additional approaches were
considered for this, including source routing techniques based on the considered for this, including source routing techniques based on the
NAI, and techniques relying on the AAA infrastructure. Given the NAI, and techniques relying on the AAA infrastructure. Given the
relative simplicity of the roaming implementations described in RFC relative simplicity of the roaming implementations described in RFC
2194 [3], static routing mechanisms appeared adequate for the task 2194 [3], static routing mechanisms appeared adequate for the task
and it was not deemed necessary to develop dynamic routing protocols. and it was not deemed necessary to develop dynamic routing protocols.
As noted in RFC 2607 [5], RADIUS proxies are deployed not only for As noted in RFC 2607 [5], RADIUS proxies are deployed not only for
skipping to change at page 8, line 5 skipping to change at page 8, line 10
technologies, such as UUCP and FidoNet, and email-address based technologies, such as UUCP and FidoNet, and email-address based
source-routing was used to handle this. However, as mail could source-routing was used to handle this. However, as mail could
increasingly be delivered directly, the use of source routing increasingly be delivered directly, the use of source routing
disappeared. disappeared.
As with the selection of certificates by stations, a Diameter client As with the selection of certificates by stations, a Diameter client
wishing to authenticate with a Diameter server may have a choice of wishing to authenticate with a Diameter server may have a choice of
available certificates, and therefore it may need to choose between available certificates, and therefore it may need to choose between
them. them.
2.3.1 Issues with AAA Routing 2.3.1 The Incomplete Routing Table Problem
No dynamic routing protocols are in use in AAA infrastructure today. 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 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 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 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 figure, the user "joe@corp3.com" has to be authenticated through ISP
2, since the domain "corp3.com" is served by it. 2, since the domain "corp3.com" is served by it.
+---------+ +---------+ +---------+ +---------+
| | | | | | | |
skipping to change at page 8, line 31 skipping to change at page 8, line 36
| |
\|/ \|/
+---------+ +---------+
| |--------> "corp2.com" | |--------> "corp2.com"
| ISP 2 | | ISP 2 |
| |--------> "corp3.com" | |--------> "corp3.com"
+---------+ +---------+
Figure 2: AAA routing problem Figure 2: AAA routing problem
2.3.2 The User Selection Problem
A related issue is that the roaming relationship graph may have A related issue is that the roaming relationship graph may have
ambiguous routes, as shown in Figure 3. As billing is based on AAA 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 and pricing may be based on the used intermediaries, it is necessary
to select which route is used. For instance, in Figure 3, access 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 through the roaming group 1 may be cheaper, than if roaming group 2
is used. For commercial reasons, intermediaries want to participate is used. For commercial reasons, intermediaries want to participate
the AAA transaction. the AAA transaction.
+---------+ +---------+
| |---------> "isp1.com" | |---------> "isp1.com"
skipping to change at page 10, line 6 skipping to change at page 10, line 6
An additional issue is that even if the intermediaries are An additional issue is that even if the intermediaries are
legitimate, they could be switched. For instance, an access network legitimate, they could be switched. For instance, an access network
could advertise that it has a deal with cheapintermediary.net, and could advertise that it has a deal with cheapintermediary.net, and
then switch the user's selection to priceyintermediary.com instead. then switch the user's selection to priceyintermediary.com instead.
To make this relevant, the pricing would have to be based on the To make this relevant, the pricing would have to be based on the
intermediary. Even if it were possible to secure this selection, it intermediary. Even if it were possible to secure this selection, it
would not be possible to guarantee that QoS or other properties would not be possible to guarantee that QoS or other properties
claimed by the network were indeed provided. As a result, it may be claimed by the network were indeed provided. As a result, it may be
useful to think of the intermediary selection only as a hint. useful to think of the intermediary selection only as a hint.
Only a limited amount of information about AAA routes can be Only a limited amount of information about AAA routes or pricing
dynamically communicated. It is necessary to retrieve network and information can be dynamically communicated [42]. It is necessary to
intermediary names, but quality of service or pricing information is retrieve network and intermediary names, but quality of service or
clearly something that would need to be pre-provisioned, or perhaps pricing information is clearly something that would need to be
just available via the web. Similarly, dynamic communication of pre-provisioned, or perhaps just available via the web. Similarly,
network names can not be expected to provide all possible home dynamic communication of network names can not be expected to provide
network names, as their number can be quite large globally. 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 [4, 19]. Where NAIs are used in this manner, the AAA
routing problem becomes a subset of the identifier selection problem.
2.4 Payload Routing 2.4 Payload Routing
The access network, mediating AAA infrastructure, and the home The access network, mediating AAA infrastructure, and the home
network may all have a desire to affect the kind of treatment payload network may all have a desire to affect the kind of treatment payload
packets get. This includes filtering, prioritization, routing paths, packets get. This includes filtering, prioritization, routing paths,
and mandatory tunneling. and mandatory tunneling.
Traditionally, the involved entities have been able to provide some Traditionally, the involved entities have been able to provide some
control of this through AAA protocols such as RADIUS [6] and Diameter control of this through AAA protocols such as RADIUS [6] and Diameter
[9]. RFC 2868 [7] defines tunneling attributes that the home and [9]. RFC 2868 [7] defines tunneling attributes that the home and
mediating networks can use to establish mandatory tunneling at the mediating networks can use to establish mandatory tunneling at the
access network. RFC 3588 [9] defines a filter syntax which can be access network. RFC 3588 [9] defines a filter syntax which can be
used to install per-session filters under the control of AAA. used to install per-session filters under the control of AAA.
2.4.1 Issues with Payload Routing 2.4.1 Issues with Payload Routing
In an attack described by Michael Richardson, a rogue hotspot In an attack described by Michael Richardson, a rogue hotspot
operator (but with a legitimate roaming relationship to a home operator (but with a legitimate roaming relationship to a home
network) steals revenues from local hotspot operator by spoofing its network) steals revenues from local hotspot operator by spoofing its
identity. The rogue operator places a node with two interfaces in the identity. The rogue operator places a node with two interfaces in
coverage area of the local operator, and attaches to the Internet via the coverage area of the local operator, and attaches to the Internet
this operator using a flat fee -based account. It then starts to via this operator using a flat fee -based account. It then starts to
advertise itself as a hotspot operator on the other interface, luring advertise itself as a hotspot operator on the other interface, luring
unsuspecting clients to use this node rather the than the local unsuspecting clients to use this node rather the than the local
operator. The users authenticate via this node and its roaming operator. The users authenticate via this node and its roaming
relationship. All AAA and payload traffic goes via the local hotspot, relationship. All AAA and payload traffic goes via the local
suitably NATted by the rogue node. As a result, the rogue operator hotspot, suitably NATted by the rogue node. As a result, the rogue
gets the roaming service fees for a number of clients, whereas the operator gets the roaming service fees for a number of clients,
local operator gets just one client. whereas the local operator gets just one client.
Due to the way that the IEEE 802.11, IETF protocols, and common EAP Due to the way that the IEEE 802.11, IETF protocols, and common EAP
methods have been designed, the rogue operator can actually advertise methods have been designed, the rogue operator can actually advertise
the same identity (SSID) as the local operator; the parameters the same identity (SSID) as the local operator; the parameters
advertised by the access point information are not authenticated advertised by the access point information are not authenticated
end-to-end to the home network. EAP methods that support channel end-to-end to the home network. EAP methods that support channel
bindings [10] do not have this problem, but this support is not bindings [10] do not have this problem, but this support is not
present in commonly used methods. Rogue access point can present a present in commonly used methods. Rogue access point can present a
different set of parameters to the client and to the home network. different set of parameters to the client and to the home network.
The current network access mechanisms enable us to have The current network access mechanisms enable us to have
skipping to change at page 11, line 19 skipping to change at page 11, line 28
number of times. number of times.
We call this the "payload route binding problem". In this problem, We call this the "payload route binding problem". In this problem,
authentication and link layer support do not guarantee that the authentication and link layer support do not guarantee that the
packets are actually routed through the path that appears to have packets are actually routed through the path that appears to have
been offered. Basically, if the "rogue" access point has a flat fee 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 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 anyone with a per-byte account, NAT their packets, and send the
traffic forward on its own account, and generate income. The local traffic forward on its own account, and generate income. The local
ISP would not be able to detect this by looking at the traffic 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 stream. The user would not be able to detect it either, unless an
method with channel binding support is used. And even if it is, the EAP method with channel binding support is used. And even if it is,
user may not care about the identity of the access point enough to the user may not care about the identity of the access point enough
look at it; channel bindings can only ensure that all parties agree to look at it; channel bindings can only ensure that all parties
about the parameters, not that they make sense. agree about the parameters, not that they make sense.
The working group did not come to a conclusion whether this attack The working group did not come to a conclusion whether this attack
needs to be prevented. Some of the proposed solutions include the use needs to be prevented. Some of the proposed solutions include the
of EAP EMSK in the authentication exchange with the DHCP server, or use of EAP EMSK in the authentication exchange with the DHCP server,
the use of EAP to provide the certificates that SEND requires for the or the use of EAP to provide the certificates that SEND requires for
authentication of Router Advertisements. Either approach means that the authentication of Router Advertisements. Either approach means
we are sure we are speaking at layer 3 to the services that we 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 authenticated at layer two. However, this does not prevent an
attacker from offering such services, and then performing a NAT on attacker from offering such services, and then performing a NAT on
the packets later. However, IPsec could be used to detect the the packets later. However, IPsec could be used to detect the
presence of such NATs, even if NAT traversal is in use. presence of such NATs, even if NAT traversal is in use.
2.5 Discovery, Decision, and Selection 2.5 Discovery, Decision, and Selection
An alternative decomposition of the problem is to consider the An alternative decomposition of the problem is to consider the
discovery, decision, and selection aspects separately. Discovery discovery, decision, and selection aspects separately. Discovery
consists of discovering access networks and associated POPs, consists of discovering access networks and associated POPs,
discovering what identities the access networks will accept (either discovering what identities the access networks will accept (either
directly or through roaming relationships), and discovering which directly or through roaming relationships), and discovering which
potential AAA intermediaries or routes exist. potential AAA intermediaries or routes exist.
Selection consists of attaching to the "right" access network and Selection consists of attaching to the "right" access network and
POP, offering an identity through EAP Identity Response, and POP, offering an identity through EAP Identity Response, and
providing a hint about the desired AAA intermediary. The selection of providing a hint about the desired AAA intermediary. The selection
the AAA intermediary, along with the home and access networks, of the AAA intermediary, along with the home and access networks,
determines also the treatment of payload packets. determines also the treatment of payload packets.
Decision can be either manual selection or automatic. Most likely, Decision can be either manual selection or automatic. Most likely,
automatic mechanisms are preferred, even if manual selection should automatic mechanisms are preferred, even if manual selection should
be retained as a fallback. The type of the decision also places be retained as a fallback. The type of the decision also places
additional requirements on the type of information that the discovery additional requirements on the type of information that the discovery
phase must provide. Just knowing which choices are available is phase must provide. Just knowing which choices are available is
probably enough for manual selection. Unfortunately, automatic probably enough for manual selection. Unfortunately, automatic
selection based on a list of choices is by itself not possible: selection based on a list of choices is by itself not possible:
o Some access networks may be preferred over others. For instance, o Some access networks may be preferred over others. For instance,
the user's private corporate network may be preferred over a the user's private corporate network may be preferred over a
public network due to cost and efficiency reasons. public network due to cost and efficiency reasons.
o Similarly, some credentials may be preferred over others. o Similarly, some credentials may be preferred over others.
o Use of an access network with direct connection to home network o Use of an access network with direct connection to home network
may be preferred over using mediating networks. may be preferred over using mediating networks.
o Some mediating networks may be preferred to others, most likely o Some mediating networks may be preferred to others, most likely
based on cost. Note that optimizing cost is not a trivial problem, based on cost. Note that optimizing cost is not a trivial
because the total cost may be a combination of a fixed fee, problem, because the total cost may be a combination of a fixed
per-minute, per-megabyte, volume discounts, and so on. fee, per-minute, per-megabyte, volume discounts, and so on.
o Preferences may come from the user, his or her employer (who's o Preferences may come from the user, his or her employer (who's
paying the bill), home network, or access network. paying the bill), home network, or access network.
Different discovery mechanisms can accommodate such preferences in Different discovery mechanisms can accommodate such preferences in
various ways. Some user input or perhaps a pre-provisioned database various ways. Some user input or perhaps a pre-provisioned database
seems inevitable. seems inevitable.
Finally, while the final step of choosing a new network lies always 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 on the client side, different approches vary in how much they rely on
skipping to change at page 12, line 47 skipping to change at page 13, line 7
instructions that the network gives to the client about the instructions that the network gives to the client about the
appropriate base station(s) that should be used. Most of the appropriate base station(s) that should be used. Most of the
processing and decisions are performed on the network side. In processing and decisions are performed on the network side. In
contrast, in a completely client-driven approach the client may get contrast, in a completely client-driven approach the client may get
some raw information from the network, but makes all decisions by some raw information from the network, but makes all decisions by
itself. itself.
2.6 Type of Information 2.6 Type of Information
A third alternative way to decompose the problem is to analyze the A third alternative way to decompose the problem is to analyze the
type of information which is required [16]. For instance, access type of information which is required [15]. For instance, access
network discovery may benefit from getting knowledge about the network discovery may benefit from getting knowledge about the
quality of service available from a particular access network or quality of service available from a particular access network or
node, and AAA routing may require knowledge of roaming agreements. node, and AAA routing may require knowledge of roaming agreements.
References [16] and [30] describe the following categories of References [15] and [30] describe the following categories of
information which can be discovered: information which can be discovered:
o Access network identification o Access network identification
o Roaming agreements o Roaming agreements
o Authentication mechanisms o Authentication mechanisms
o Quality of service o Quality of service
o Cost o Cost
o Authorization policy o Authorization policy
o Privacy policy o Privacy policy
o Service parameters, such as the existence of middleboxes o Service parameters, such as the existence of middleboxes
The nature of the discovered information can be static, such as the The nature of the discovered information can be static, such as the
fastest available transmission speed on a given piece of equipment. fastest available transmission speed on a given piece of equipment.
Or it can be dynamic, such as the current load on this equipment. The Or it can be dynamic, such as the current load on this equipment.
information can describe something about the network access nodes The information can describe something about the network access nodes
themselves, or it can be something that they simply advertise on themselves, or it can be something that they simply advertise on
behalf of other parts of the network, such as roaming agreements behalf of other parts of the network, such as roaming agreements
further in the AAA network. further in the AAA network.
Typically, it would be desirable to acquire all this information Typically, it would be desirable to acquire all this information
prior to the authentication process. In some cases it is in fact prior to the authentication process. In some cases it is in fact
necessary, if the authentication process can not complete without the necessary, if the authentication process can not complete without the
information. Reference [30] classifies the possible steps at which information. Reference [30] classifies the possible steps at which
IEEE 802.11 networks can acquire this information: IEEE 802.11 networks can acquire this information:
skipping to change at page 13, line 36 skipping to change at page 13, line 38
behalf of other parts of the network, such as roaming agreements behalf of other parts of the network, such as roaming agreements
further in the AAA network. further in the AAA network.
Typically, it would be desirable to acquire all this information Typically, it would be desirable to acquire all this information
prior to the authentication process. In some cases it is in fact prior to the authentication process. In some cases it is in fact
necessary, if the authentication process can not complete without the necessary, if the authentication process can not complete without the
information. Reference [30] classifies the possible steps at which information. Reference [30] classifies the possible steps at which
IEEE 802.11 networks can acquire this information: IEEE 802.11 networks can acquire this information:
o Pre-association o Pre-association
o Post-association (or pre-authentication) o Post-association (or pre-authentication)
o Post-authentication o Post-authentication
Note that some EAP methods (such as those defined in [21, 23, 15]) Note that some EAP methods (such as those defined in [21, 23, 14])
have an ability to agree about additional parameters during an have an ability to agree about additional parameters during an
authentication process. While such parameters are useful for many authentication process. While such parameters are useful for many
purposes, their use for network selection suffers from an obvious purposes, their use for network selection suffers from an obvious
chicken-and-egg problem. Or at least it seems costly to run a chicken-and-egg problem. Or at least it seems costly to run a
relatively heavy authentication process to decide whether the client relatively heavy authentication process to decide whether the client
wants to attach to this network. wants to attach to this network.
3. Design Constrains 3. Design Constrains
All solutions to the network selection and discovery problem must All solutions to the network selection and discovery problem must
skipping to change at page 15, line 18 skipping to change at page 15, line 18
There has already been a lot of past work in this area, including a 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 number of IETF Proposed Standards generated by the ROAMOPS WG. The
topic of roaming was considered different enough from both AAA and topic of roaming was considered different enough from both AAA and
access protocols such as PPP that it deserved its own WG. access protocols such as PPP that it deserved its own WG.
In addition to work on ROAMOPS directly relating to the problem, In addition to work on ROAMOPS directly relating to the problem,
there has been work in SEAMOBY relating to scaling of network there has been work in SEAMOBY relating to scaling of network
discovery mechanisms; work in PKIX relating to identity and discovery mechanisms; work in PKIX relating to identity and
credential selection; and work in AAA WG relating to access routing. credential selection; and work in AAA WG relating to access routing.
The PANA protocol [18] has a mechanism to advertise and select "ISPs" The PANA protocol [17] has a mechanism to advertise and select "ISPs"
through the exchange of the ISP-Information AVP in its initial through the exchange of the ISP-Information AVP in its initial
exchange. exchange.
A number of (small) improvements to payload routing control are A number of (small) improvements to payload routing control are
currently in progress in the IETF RADEXT WG. These include better currently in progress in the IETF RADEXT WG. These include better
filtering and redirection support [20]. RADEXT WG is also working on filtering and redirection support [20]. RADEXT WG is also working on
an new revision of the NAI specification [14]. This revision an new revision of the NAI specification [19]. This revision
clarifies the use of the '!' syntax in a NAI to route requests via clarifies the use of the '!' syntax in a NAI to route requests via
specified mediating networks. specified mediating networks.
Adrangi et al [12] discuss the use of the EAP-Request/Identity for Adrangi et al [12] discuss the use of the EAP-Request/Identity for
network discovery. As noted in [10] Section 3.1, the minimum EAP MTU identifier selection. It is necessary to have this kind of a
is 1020 octets, so that an EAP-Request/Identity is only guaranteed to mechanism, as clients may have more than one credential, and when
be able to include 1015 octets within the Type-Data field. Since RFC combined with the '!' syntax for NAIs, it can also be used for
1035 [1] enables FQDNs to be up to 255 octets in length, this may not mediating network discovery and selection. The use of lower-layer
enable the announcement of very many networks, although if SSIDs are information may also be limited in terms of discovering identifiers
used, the maximum length of 32 octets per SSID may provide that are used on the EAP layer. In the longer term, the use of this
substantially better scaling. The use of other network identifiers mechanism may run into scalability problems, however. As noted in
than domain names is also possible, for instance the PANA protocol [10] Section 3.1, the minimum EAP MTU is 1020 octets, so that an
uses an a free form string and an SMI Network Management Private EAP-Request/Identity is only guaranteed to be able to include 1015
Enterprise Code [18], or Mobile Network Codes could be used as hinted octets within the Type-Data field. Since RFC 1035 [1] enables FQDNs
in [13]. 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 [17], or
Mobile Network Codes embedded in NAIs as specified in 3GPP.
As noted in [39], the use of the EAP-Request/Identity for network As noted in [39], the use of the EAP-Request/Identity for network
discovery has substantial negative impact on handoff latency, since discovery has substantial negative impact on handoff latency, since
this may result in a station needing to initiate an EAP conversation this may result in a station needing to initiate an EAP conversation
with each Access Point in order to receive an EAP-Request/Identity with each Access Point in order to receive an EAP-Request/Identity
describing which networks are supported. Since IEEE 802.11-1999 does describing which networks are supported. Since IEEE 802.11-1999 does
not support use of Class 1 data frames in State 1 (unauthenticated, not support use of Class 1 data frames in State 1 (unauthenticated,
unassociated) within an ESS, this implies either that the APs must unassociated) within an ESS, this implies either that the APs must
support 802.1X pre-authentication (optional in IEEE 802.11i) or that support 802.1X pre-authentication (optional in IEEE 802.11i) or that
the station must associate with each AP prior to sending an the station must associate with each AP prior to sending an
skipping to change at page 16, line 15 skipping to change at page 16, line 21
The effects to handoff latency depend also on the specific protocol The effects to handoff latency depend also on the specific protocol
design, and the expected likelihood of having to provide design, and the expected likelihood of having to provide
advertisements and initiate scanning of several access points. The advertisements and initiate scanning of several access points. The
use of advertisements only as a last resort when the AAA routing has use of advertisements only as a last resort when the AAA routing has
failed is a better approach than the use of advertisement - scanning failed is a better approach than the use of advertisement - scanning
procedure on every attachment. procedure on every attachment.
Furthermore, if the AP has not been updated to present an up to date 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 set of networks in the EAP-Requests/Identity, after associating to
candidate APs and then choosing one, it is possible that the station 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 will find that the chosen network is not supported after all. In
case, the station's EAP-Response/Identity may be answered with an this case, the station's EAP-Response/Identity may be answered with
updated EAP-Request/Identity, adding yet more latency. an updated EAP-Request/Identity, adding more latency.
4.2 IEEE 4.2 IEEE
There has been work in IEEE 802.11 and 802.1 relating to network There has been work in IEEE 802.11 and 802.1 relating to network
discovery enhancements. discovery enhancements.
Some recent contributions in this space include the following: Some recent contributions in this space include the following:
o [25] defines the Beacon and Probe Response mechanisms used with o [25] defines the Beacon and Probe Response mechanisms used with
IEEE 802.11. Unfortunately, Beacons are only sent at the lowest IEEE 802.11. Unfortunately, Beacons are only sent at the lowest
skipping to change at page 17, line 11 skipping to change at page 17, line 17
AP" appears at the MAC and IP layers to be distinct physical AP. AP" appears at the MAC and IP layers to be distinct physical AP.
As noted in the paper, full compatibility with existing 802.11 As noted in the paper, full compatibility with existing 802.11
station implementations can only be maintained if each virtual AP station implementations can only be maintained if each virtual AP
uses a distinct MAC address (BSSID) for use in Beacons and Probe uses a distinct MAC address (BSSID) for use in Beacons and Probe
Responses. This draft does not discuss scaling issues in detail, Responses. This draft does not discuss scaling issues in detail,
but recommends that only a limited number of virtual APs be but recommends that only a limited number of virtual APs be
supported by a single physical access point. The simulations supported by a single physical access point. The simulations
presented in [37] appear to confirm this conclusion; with a Beacon presented in [37] appear to confirm this conclusion; with a Beacon
interval of 100 ms, once more than 8 virtual APs are supported on 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 a single channel, more than 20% of bandwidth is used for Beacons
alone. This would indicate a limit of approximately 20 virtual APs alone. This would indicate a limit of approximately 20 virtual
per physical AP. APs per physical AP.
o The 802.11 WIEN Study Group is working on the network discovery o The 802.11 WIEN Study Group is working on the network discovery
and selection problem. Some of the contributions in this group and selection problem. In general, the group is working to define
include [31] and [30]. In general, the group is working to define the problem at this stage. This includes studies on the
the problem at this point in time. This includes studies on the
limitations of existing mechanisms, and gathering requirements limitations of existing mechanisms, and gathering requirements
about the type of information needed from the discovery process. about the type of information needed from the discovery process.
Some of the contributions in this group include [31] and [30].
o IEEE 802.21 is developing standards to enable handover and o IEEE 802.21 is developing standards to enable handover and
interoperability between heterogeneous network types including interoperability between heterogeneous network types including
both 802 and non 802 networks. The intention is to provide a both 802 and non 802 networks. The intention is to provide a
general information transfer capability for these purposes. As a general information transfer capability for these purposes. As a
result, network discovery process may benefit from such standards. result, network discovery process may benefit from such standards.
4.3 3GPP 4.3 3GPP
The 3GPP technical specification [32] covers the interworking of WLAN The 3GPP technical specification [32] covers the interworking of WLAN
networks with 2G and 3G networks. This specification discusses also networks with 2G and 3G networks. This specification discusses also
network discovery and selection issues. network discovery and selection issues.
The specification requires that Access Network Discovery is performed The specification requires that Access Network Discovery is performed
as specified in the standards for the relevant WLAN link layer as specified in the standards for the relevant WLAN link layer
technology. An early version of the technical specification required technology. An early version of the technical specification required
the use of a 3GPP-specific SSID, but that has since then been the use of a 3GPP-specific SSID, but that has since then been
abandoned; access network or local 3GPP network based SSIDs may be abandoned; access network or local 3GPP network based SSIDs may be
used instead. It has not been decided whether some conventions on the used instead. It has not been decided whether some conventions on
format of these SSIDs is required by 3GPP. the format of these SSIDs is required by 3GPP.
In addition to Access Network Discovery, it is necessary to select In addition to Access Network Discovery, it is necessary to select
intermediary networks for the purposes of AAA Routing. In 3GPP, these intermediary networks for the purposes of AAA Routing. In 3GPP,
networks are called Visited Public Land-based Mobile Networks these networks are called Visited Public Land-based Mobile Networks
(VPLMNs), and it is assumed that WLAN networks may have a contract (VPLMNs), and it is assumed that WLAN networks may have a contract
with more than one VPLMN. GSM/UMTS roaming mechanisms are then with more than one VPLMN. GSM/UMTS roaming mechanisms are then
employed for routing AAA requests from the VPLMN to the home network. employed for routing AAA requests from the VPLMN to the home network.
In order to select the VPLMN, the following is required: In order to select the VPLMN, the following is required:
o User can choose the desired VPLMN. o User can choose the desired VPLMN.
o AAA message are routed according to the NAI. o AAA message are routed according to the NAI.
o Existing EAP mechanisms are used where possible. o Existing EAP mechanisms are used where possible.
o Extensibility is desired, to allow the advertisement of other o Extensibility is desired, to allow the advertisement of other
parameters later. parameters later.
The referenced 3GPP technical specification is a so called stage 2 The referenced 3GPP technical specification is a so called stage 2
specification, and contains only the principles of operation, leaving specification, and contains only the principles of operation, leaving
detailed protocol work for later. Nevertheless, the specification detailed protocol work for later. Nevertheless, the specification
states that advertisement information shall be provided only when the states that advertisement information shall be provided only when the
access network is unable to route the request using normal AAA 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 routing means, such as when it sees an unknown NAI domain. It is
stated that where VPLMN control is required, the necessary also stated that where VPLMN control is required, the necessary
information is added to a NAI. information is added to a NAI.
The security properties related to different mediating network The security properties related to different mediating network
selection mechanisms have been discussed in the 3GPP contribution selection mechanisms have been discussed in the 3GPP contribution
[33], which concludes that both SSID- and EAP-based mechanisms have [33], which concludes that both SSID- and EAP-based mechanisms have
roughly similar (and very limited) security properties, and that, as roughly similar (and very limited) security properties, and that, as
a result, network advertisement should be considered only as hints. a result, network advertisement should be considered only as hints.
Ahmavaara, Haverinen, and Pichna [35] discuss the new network Ahmavaara, Haverinen, and Pichna [35] discuss the new network
selection requirements that 3G-WLAN roaming introduces. It is selection requirements that 3G-WLAN roaming introduces. It is
skipping to change at page 18, line 47 skipping to change at page 19, line 3
[36] discusses the need for network selection in a situation where [36] discusses the need for network selection in a situation where
there is more than one available access network with a roaming there is more than one available access network with a roaming
agreement to the home network. It also lists EAP-level, SSID-based, agreement to the home network. It also lists EAP-level, SSID-based,
and PEAP-based mechanisms as potential solutions to the network and PEAP-based mechanisms as potential solutions to the network
selection problem. selection problem.
Eijk et al [34] discussed the general issue of network selection. Eijk et al [34] discussed the general issue of network selection.
They concentrated primarily on the Access Network Discovery problem, They concentrated primarily on the Access Network Discovery problem,
based on various criteria, and did not consider the other aspects of 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 problem. Nevertheless, they mention that one
the network selection problems is that the information about of the network selection problems is that the information about
accessibility and roaming relationships is not stored in one accessibility and roaming relationships is not stored in one
location, but rather spread around the network. location, but rather spread around the network.
5. Conclusions 5. Conclusions
The issues surrounding the network discovery and selection problem The issues surrounding the network discovery and selection problem
have been summarized. have been summarized.
In the opinion of the editors of this document, the main findings In the opinion of the editors of this document, the main findings
are: are:
o There is a clear need for access network discovery, identifier o There is a clear need for access network discovery, identifier
selection, AAA routing, and payload routing. selection, AAA routing, and payload routing.
o Existing mechanisms appear largely sufficient for the control of o Existing mechanisms appear largely sufficient for the control of
payload routing, even if some minor improvements are being worked payload routing, even if some minor improvements are being worked
on. But there appears to be justification for significantly on. But there appears to be justification for significantly
enhanced mechanisms relating to access network discovery, enhanced mechanisms relating to access network discovery,
identifier selection, and AAA routing. 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 o Nevertheless, many of the problems discussed in this draft are
very hard when one considers them in an environment that requires very hard when one considers them in an environment that requires
a potentially large number of networks, fast handoffs, and a potentially large number of networks, fast handoffs, and
automatic decisions. automatic decisions.
o The proliferation of multiple competing network discovery o The proliferation of multiple competing network discovery
technologies within IEEE 802, IETF, and 3GPP appears to a technologies within IEEE 802, IETF, and 3GPP appears to a
significant problem going forward. In the absence of a clearly significant problem going forward. In the absence of a clearly
defined solution to the problem it is likely that any or all of defined solution to the problem it is likely that any or all of
these solutions will be utilized, resulting in industry these solutions will be utilized, resulting in industry
skipping to change at page 19, line 43 skipping to change at page 20, line 47
In order to avoid this fate, it is strongly suggested that a In order to avoid this fate, it is strongly suggested that a
discussion be initiated between IETF and IEEE 802 in order to work discussion be initiated between IETF and IEEE 802 in order to work
out the roles of the each organization in solving this problem, out the roles of the each organization in solving this problem,
and to invite 3GPP participation so that their requirements can be and to invite 3GPP participation so that their requirements can be
fulfilled by the planned solutions. fulfilled by the planned solutions.
o New link layers should be designed with facilities that enable the o New link layers should be designed with facilities that enable the
efficient distribution of network advertisement information. efficient distribution of network advertisement information.
o Solving all problems with current link layers and existing network o Solving all problems with current link layers and existing network
access devices may not be possible. It may be useful to consider a access devices may not be possible. It may be useful to consider
phased approach where only certain, limited functions are provided a phased approach where only certain, limited functions are
now, and the full functionality is provided when extensions to provided now, and the full functionality is provided when
current link layers become available. extensions to current link layers become available.
We will briefly comment on the specific mechanisms related to network We will briefly comment on the specific mechanisms related to network
discovery and selection: discovery and selection:
o As noted in studies such as [41] and [37], the IEEE 802.11 Beacon/ o As noted in studies such as [41] and [37], the IEEE 802.11
Probe Response mechanism has substantial scaling issues, and as a Beacon/Probe Response mechanism has substantial scaling issues,
result a single physical access point is in practice limited to and as a result a single physical access point is in practice
less than a dozen virtual APs on each channel with IEEE 802.11b. limited to less than a dozen virtual APs on each channel with IEEE
802.11b.
The situation is improved substantially with successors such as The situation is improved substantially with successors such as
IEEE 802.11a which enable additional channels, thus potentially IEEE 802.11a which enable additional channels, thus potentially
increasing the number of potential virtual APs. increasing the number of potential virtual APs.
However, even these enhancements it is not feasible to advertise However, even these enhancements it is not feasible to advertise
more than 50 different networks using existing mechanisms, and more than 50 different networks using existing mechanisms, and
probably significantly less in most circumstances. probably significantly less in most circumstances.
As a result, there appears to be justification for enhancing the As a result, there appears to be justification for enhancing the
skipping to change at page 20, line 35 skipping to change at page 21, line 41
large quantities of data where fragmentation would be a problem. large quantities of data where fragmentation would be a problem.
Another typical limitation of link layer assistance in this area Another typical limitation of link layer assistance in this area
is that in general, it would be desirable to retrive also is that in general, it would be desirable to retrive also
information relating to the potential next access networks or information relating to the potential next access networks or
access points. However, such networks may be of another type than access points. However, such networks may be of another type than
the current one, so the link layer would have to carry information the current one, so the link layer would have to carry information
relating to other types of link layers as well. This is possible, relating to other types of link layers as well. This is possible,
but requires coordination among different groups in the industry. but requires coordination among different groups in the industry.
o Given that EAP does not support fragmentation of EAP-Request/ o Given that EAP does not support fragmentation of
Identity packets, and that use of EAP for network selection on all EAP-Request/Identity packets, and that use of EAP for network
attachments will have a substantial adverse impact on roaming selection on all attachments will have a substantial adverse
performance without appropriate lower layer support (such as impact on roaming performance without appropriate lower layer
support for Class 1 data frames within IEEE 802.11), the use of support (such as support for Class 1 data frames within IEEE
EAP is limited. For instance, the use of EAP to carry quality of 802.11), the use of EAP is limited. For instance, the use of EAP
service as proposed in [16] seems hard given the limitations. to carry quality of service as proposed in [15] seems hard given
Long-term, it makes more sense for the desired functionality to be the limitations. Long-term, it makes more sense for the desired
handled either within IEEE 802 or at the IP layer. However, a functionality to be handled either within IEEE 802 or at the IP
strictly limited discovery mechanism such as the one defined in layer. However, a strictly limited discovery mechanism such as
[12] is useful. the one defined in [12] is useful.
o In the IETF, a potential alternative is use of the SEAMOBY CARD o In the IETF, a potential alternative is use of the SEAMOBY CARD
protocol [17], which enables advertisement of network device protocol [16], which enables advertisement of network device
capabilities over IP. Another alternative is the recently proposed capabilities over IP. Another alternative is the recently
Device Discovery Protocol (DDP) [22], which provides functionality proposed Device Discovery Protocol (DDP) [22], which provides
equivalent to IEEE 802.1ab using ASN.1 encoded advertisements sent functionality equivalent to IEEE 802.1ab using ASN.1 encoded
to a link-local scope multicast address. advertisements sent to a link-local scope multicast address.
A limitation of these IP layer solutions is that they can only A limitation of these IP layer solutions is that they can only
work as a means to speed up the attachment procedures when moving 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 from one location to another; when a node starts up, it needs to
be able to attach to a network before IP communications are be able to attach to a network before IP communications are
available. This is fine for optimizations, but precludes the use available. This is fine for optimizations, but precludes the use
in a case where the discovery information is mandatory before in a case where the discovery information is mandatory before
successful attachment can be accomplished, for instance when the successful attachment can be accomplished, for instance when the
access network is unable to route the AAA request unaided. access network is unable to route the AAA request unaided.
o "Phone-book" based approaches such as RFC 3017 appear attractive o "Phone-book" based approaches such as RFC 3017 appear attractive
due to their ability to provide sufficient information for due to their ability to provide sufficient information for
automatic selection decisions. However, there is no experience on automatic selection decisions. However, there is no experience on
applying such approaches to wireless access. The number of WLAN applying such approaches to wireless access. The number of WLAN
access points is significantly higher than the number of dial-in access points is significantly higher than the number of dial-in
POPs; the distributed nature of the access network has created a POPs; the distributed nature of the access network has created a
more complicated business and roaming structure, and the expected more complicated business and roaming structure, and the expected
rate of change in the information is high. As noted in [40] and rate of change in the information is high. As noted in [40] and
[16], a large fraction of current WLAN access points operate on [15], a large fraction of current WLAN access points operate on
the default SSID, which may make the use of the phone book the default SSID, which may make the use of the phone book
approach hard. approach hard.
Finally, to address some of the security concerns that have come up Finally, to address some of the security concerns that have come up
during this work, the IETF should in any case initiate work that during this work, the IETF should in any case initiate work that
enables support for channel bindings in methods. Preferably, popular enables support for channel bindings in methods. Preferably, popular
methods should be updated, ensuring compatibility with existing methods should be updated, ensuring compatibility with existing
deployments. The representation of link layer parameters within EAP deployments. The representation of link layer parameters within EAP
should utilize a common framework, to make it easier to define new 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 layers and keep the selection of EAP methods independent of the
skipping to change at page 22, line 16 skipping to change at page 23, line 16
All aspects of the network discovery and selection problem are All aspects of the network discovery and selection problem are
security related. The security issues and requirements have been security related. The security issues and requirements have been
discussed in the previous sections. discussed in the previous sections.
The security requirements for network discovery depend on the type of The security requirements for network discovery depend on the type of
information being discovered. Some of the parameters may have a information being discovered. Some of the parameters may have a
security impact, such as the claimed name of the network the user security impact, such as the claimed name of the network the user
tries to attach to. Unfortunately, current EAP methods do not always tries to attach to. Unfortunately, current EAP methods do not always
make the verification of such parameters possible. New EAP methods make the verification of such parameters possible. New EAP methods
are doing it [21, 23], however, and there is even an attempt to are doing it [21, 23], however, and there is even an attempt to
provide a backwards compatible extensions to older methods [15]. provide a backwards compatible extensions to older methods [14].
The security requirements for network selection depend on whether the The security requirements for network selection depend on whether the
selection is considered as a command or a hint. For instance, 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 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 routing and the access network can route the AAA traffic to the
correct home network using other means in any case. correct home network using other means in any case.
Normative References 7. References
7.1 Normative References
[1] Mockapetris, P., "Domain names - implementation and [1] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, "Review of [3] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, "Review of
Roaming Implementations", RFC 2194, September 1997. Roaming Implementations", RFC 2194, September 1997.
skipping to change at page 23, line 35 skipping to change at page 24, line 37
[7] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and [7] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
2868, June 2000. 2868, June 2000.
[8] Riegel, M. and G. Zorn, "XML DTD for Roaming Access Phone [8] Riegel, M. and G. Zorn, "XML DTD for Roaming Access Phone
Book", RFC 3017, December 2000. Book", RFC 3017, December 2000.
[9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, [9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003. "Diameter Base Protocol", RFC 3588, September 2003.
[10] Blunk, L., "Extensible Authentication Protocol (EAP)", [10] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
draft-ietf-eap-rfc2284bis-07 (work in progress), December 2003. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[11] Housley, R. and T. Moore, "Certificate Extensions and [11] Housley, R. and T. Moore, "Certificate Extensions and
Attributes Supporting Authentication in PPP and Wireless LAN", Attributes Supporting Authentication in Point-to-Point Protocol
draft-ietf-pkix-wlan-extns-04 (work in progress), December (PPP) and Wireless Local Area Networks (WLAN)", RFC 3770, May
2002. 2004.
Informative References 7.2 Informative References
[12] Adrangi, F., "Mediating Network Discovery in the Extensible [12] Adrangi, F., Lortz, V., Bari, F., Eronen, P. and M. Watson,
Authentication Protocol (EAP)", "Mediating Network Discovery in the Extensible Authentication
draft-adrangi-eap-network-discovery-01 (work in progress), June Protocol (EAP)", draft-adrangi-eap-network-discovery-05 (work
2004. in progress), October 2004.
[13] Adrangi, F., "Network Discovery and Selection within the EAP [13] Adrangi, F., "Network Discovery and Selection within the EAP
Framework", Framework",
draft-adrangi-eap-network-discovery-and-selection-00 (work in draft-adrangi-eap-network-discovery-and-selection-00 (work in
progress), October 2003. progress), October 2003.
[14] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network [14] Arkko, J. and P. Eronen, "Authenticated Service Identities for
Access Identifier", draft-arkko-roamops-rfc2486bis-02 (work in
progress), July 2004.
[15] Arkko, J. and P. Eronen, "Authenticated Service Identities for
the Extensible Authentication Protocol (EAP)", the Extensible Authentication Protocol (EAP)",
draft-arkko-eap-service-identity-auth-00 (work in progress), draft-arkko-eap-service-identity-auth-01 (work in progress),
April 2004. October 2004.
[16] Tschofenig, H., "Network Selection Implementation Results", [15] Tschofenig, H., "Network Selection Implementation Results",
draft-groeting-eap-netselection-results-00 (work in progress), draft-groeting-eap-netselection-results-00 (work in progress),
July 2004. July 2004.
[17] Liebsch, M., "Candidate Access Router Discovery", [16] Liebsch, M., "Candidate Access Router Discovery",
draft-ietf-seamoby-card-protocol-05 (work in progress), draft-ietf-seamoby-card-protocol-05 (work in progress),
November 2003. November 2003.
[18] Forsberg, D., "Protocol for Carrying Authentication for Network [17] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin,
Access (PANA)", draft-ietf-pana-pana-02 (work in progress), "Protocol for Carrying Authentication for Network Access
October 2003. (PANA)", draft-ietf-pana-pana-05 (work in progress), July 2004.
[19] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [18] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-07 (work in progress), April 2003. draft-ietf-ipsec-ikev2-17 (work in progress), October 2004.
[19] Aboba, B., "The Network Access Identifier",
draft-ietf-radext-rfc2486bis-01 (work in progress), October
2004.
[20] Lior, A., "Remote Authentication Dial In User Service (RADIUS) [20] Lior, A., "Remote Authentication Dial In User Service (RADIUS)
Redirection", draft-lior-radius-redirection-00 (work in Redirection", draft-lior-radius-redirection-00 (work in
progress), February 2004. progress), February 2004.
[21] Josefsson, S., Palekar, A., Simon, D. and G. Zorn, "Protected [21] Josefsson, S., Palekar, A., Simon, D. and G. Zorn, "Protected
EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap-07 EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap-07
(work in progress), October 2003. (work in progress), October 2003.
[22] Enns, R., Marques, P. and D. Morrell, "Device Discovery [22] Enns, R., Marques, P. and D. Morrell, "Device Discovery
skipping to change at page 26, line 20 skipping to change at page 27, line 12
Selection", Sigcomm Poster Session 2002. Selection", Sigcomm Poster Session 2002.
[39] Eronen, P., "Network Selection Issues", presentation to EAP WG [39] Eronen, P., "Network Selection Issues", presentation to EAP WG
at IETF 58, November 2003. at IETF 58, November 2003.
[40] Priest, J., "The State of Wireless London", July 2004. [40] Priest, J., "The State of Wireless London", July 2004.
[41] Heusse, M., "Performance Anomaly of 802.11b", LSR-IMAG [41] Heusse, M., "Performance Anomaly of 802.11b", LSR-IMAG
Laboratory, Grenoble, France, IEEE Infocom 2003. Laboratory, Grenoble, France, IEEE Infocom 2003.
[42] Eronen, P. and J. Arkko, "Role of authorization in wireless
network security", Extended abstract to be presented in the
DIMACS workshop, November 2004.
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
EMail: jari.arkko@ericsson.com EMail: jari.arkko@ericsson.com
Bernard Aboba Bernard Aboba
Microsoft Microsoft
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
skipping to change at page 28, line 8 skipping to change at page 29, line 8
Input for version 01 has been gathered from many sources, including Input for version 01 has been gathered from many sources, including
the above persons as well as 3GPP and IEEE developments. We would the above persons as well as 3GPP and IEEE developments. We would
also like to thank Alper Yegin, Victor Lortz, Stephen Hayes, and also like to thank Alper Yegin, Victor Lortz, Stephen Hayes, and
David Johnston for comments. David Johnston for comments.
Appendix B. Modifications from Version 00 Appendix B. Modifications from Version 00
The following modifications have been incorporated to the -01 version The following modifications have been incorporated to the -01 version
of this draft: of this draft:
o Added a discussion of new IETF protocol documents relating to this o Added a discussion of new IETF protocol documents relating to this
problem, such as [12], [14], [20], and [15]. problem, such as [12], [19], [20], and [14].
o Added references to a number of new documents that discuss the o Added references to a number of new documents that discuss the
network selection problem. network selection problem.
o Added pointers to new IEEE work in this area. o Added pointers to new IEEE work in this area.
o Added a discussion of what type of information may need to be o Added a discussion of what type of information may need to be
discovered and when (Section 2.6). discovered and when (Section 2.6).
o Added a discussion relating to the use of phone books in an o Added a discussion relating to the use of phone books in an
environment where network identifiers are not being regularly set. environment where network identifiers are not being regularly set.
o Added a discussion of network-based control in Section 2.5. o Added a discussion of network-based control in Section 2.5.
o Updated the conclusions. o Updated the conclusions.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
skipping to change at page 29, line 12 skipping to change at page 30, line 12
o Updated the conclusions. o Updated the conclusions.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can on the procedures with respect to rights in RFC documents can be
be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
 End of changes. 

This html diff was produced by rfcdiff v1.06, available from http://www.levkowetz.com/ietf/tools/rfcdiff/