| TOC |
|
This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668.
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 25, 2005.
Copyright (C) The Internet Society (2004).
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 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.
1.
Introduction
2.
Problem Definition
2.1
Access Network Discovery
2.2
Identity selection
2.3
AAA routing
2.3.1
The Incomplete Routing Table Problem
2.3.2
The User Selection Problem
2.4
Payload Routing
2.4.1
Issues with Payload Routing
2.5
Discovery, Decision, and Selection
2.6
Type of Information
3.
Design Constrains
4.
Existing Work
4.1
IETF
4.2
IEEE
4.3
3GPP
4.4
Other
5.
Conclusions
6.
Security Considerations
7.
References
7.1
Normative References
7.2
Informative References
§
Authors' Addresses
A.
Contributors
B.
Modifications from Version 00
§
Intellectual Property and Copyright Statements
| TOC |
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:
The network discovery and selection problem spans multiple protocol layers and has been the subject of discussions in IETF, 3GPP, and IEEE 802.11. This document summarizes the discussion held about this problem in the Extensible Authentication Protocol working group at IETF.
In Section 2Problem Definition the problem is defined and divided into subproblems, and some constraints for possible solutions are outlined in Section 3Design Constrains. Section 4Existing Work discusses existing mechanisms which help solve at least parts of the problem. Section 5Conclusions gives some suggestions on how to proceed for the rest.
| TOC |
There are four somewhat orthogonal problems being discussed under the rubric of "network discovery and selection".
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.
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 [38]Judd, G. and P. Steenkiste, Fixing 802.11 Access Point Selection, Sigcomm Poster Session 2002.) 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 2194Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, Review of Roaming Implementations, September 1997.[3] describes the pre-provisioning of dialup roaming clients, which typically included a list of potential phone numbers, updated by the provider(s) with which the client had a contractual relationship. RFC 3017Riegel, M. and G. Zorn, XML DTD for Roaming Access Phone Book, December 2000.[8] 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 [37]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., 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.
As networks proliferate, it becomes more and more likely that a given EAP peer may have multiple identities and credential sets, available for use in different situations. For example, the EAP peer may have an account with one or more Public WLAN providers; a corporate WLAN; one or more wireless WAN providers. As a result, the EAP peer has to decide which credential set to use when presented with a given set of potential EAP authenticators.
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 DTDRiegel, M. and G. Zorn, XML DTD for Roaming Access Phone Book, December 2000.[8], 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 IKEv2Kaufman, C., Internet Key Exchange (IKEv2) Protocol, October 2004.[18], the identity of the responder (typically the security gateway) is provided as a part of the usual 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 [11]Housley, R. and T. Moore, Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN), May 2004., 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, [12]Adrangi, F., Lortz, V., Bari, F., Eronen, P. and M. Watson, Mediating Network Discovery in the Extensible Authentication Protocol (EAP), October 2004. is widely expected to be used.
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 2486Aboba, B. and M. Beadles, The Network Access Identifier, January 1999.[4][19]Aboba, B., The Network Access Identifier, October 2004., 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 2194Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, Review of Roaming Implementations, September 1997.[3], static routing mechanisms appeared adequate for the task and it was not deemed necessary to develop dynamic routing protocols.
As noted in RFC 2607Aboba, B. and J. Vollbrecht, Proxy Chaining and Policy Implementation in Roaming, June 1999.[5], 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 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.
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
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 has 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 your request through one of them, even if you 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 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 [42]Eronen, P. and J. Arkko, Role of authorization in wireless network security, Extended abstract to be presented in the DIMACS workshop, November 2004.. 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 [4]Aboba, B. and M. Beadles, The Network Access Identifier, January 1999.[19]Aboba, B., The Network Access Identifier, October 2004.. Where NAIs are used in this manner, the AAA routing problem becomes a subset of the identifier selection problem.
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 RADIUSRigney, C., Willens, S., Rubens, A. and W. Simpson, Remote Authentication Dial In User Service (RADIUS), June 2000.[6] and DiameterCalhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, Diameter Base Protocol, September 2003.[9]. RFC 2868Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, RADIUS Attributes for Tunnel Protocol Support, June 2000.[7] defines tunneling attributes that the home and mediating networks can use to establish mandatory tunneling at the access network. RFC 3588Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, Diameter Base Protocol, September 2003.[9] defines a filter syntax which can be used to install per-session filters under the control of AAA.
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 bindingsAboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol (EAP), June 2004.[10] 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, 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.
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:
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.
A third alternative way to decompose the problem is to analyze the type of information which is required [15]Tschofenig, H., Network Selection Implementation Results, July 2004.. 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 [15]Tschofenig, H., Network Selection Implementation Results, July 2004. and [30]Berg, S., Information to Support Network Selection, IEEE Contribution 11-04-0624 2004. describe the following categories of information which can be discovered:
The nature of the discovered information can be static, such as the fastest available transmission speed on a given piece of equipment. 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 [30]Berg, S., Information to Support Network Selection, IEEE Contribution 11-04-0624 2004. classifies the possible steps at which IEEE 802.11 networks can acquire this information:
Note that some EAP methods (such as those defined in [21]Josefsson, S., Palekar, A., Simon, D. and G. Zorn, Protected EAP Protocol (PEAP), October 2003.[23]Tschofenig, H. and D. Kroeselberg, EAP IKEv2 Method (EAP-IKEv2), February 2004.[14]Arkko, J. and P. Eronen, Authenticated Service Identities for the Extensible Authentication Protocol (EAP), October 2004.) 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.
| TOC |
All solutions to the network selection and discovery problem must satisfy the following additional constraints:
| TOC |
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 protocolForsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin, Protocol for Carrying Authentication for Network Access (PANA), July 2004.[17] 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 [20]Lior, A., Remote Authentication Dial In User Service (RADIUS) Redirection, February 2004.. RADEXT WG is also working on an new revision of the NAI specification [19]Aboba, B., The Network Access Identifier, October 2004.. This revision clarifies the use of the '!' syntax in a NAI to route requests via specified mediating networks.
Adrangi et al [12]Adrangi, F., Lortz, V., Bari, F., Eronen, P. and M. Watson, Mediating Network Discovery in the Extensible Authentication Protocol (EAP), October 2004. 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 longer term, the use of this mechanism may run into scalability problems, however. As noted in [10]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, Extensible Authentication Protocol (EAP), June 2004. 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 1035Mockapetris, P., Domain names - implementation and specification, November 1987.[1] 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 [17]Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin, Protocol for Carrying Authentication for Network Access (PANA), July 2004., or Mobile Network Codes embedded in NAIs as specified in 3GPP.
As noted in [39]Eronen, P., Network Selection Issues, presentation to EAP WG at IETF 58, November 2003., 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.
There has been work in IEEE 802.11 and 802.1 relating to network discovery enhancements.
Some recent contributions in this space include the following:
The 3GPP technical specification [32]3GPP, 3GPP System to Wireless Local Area Network (WLAN) interworking; System Description; Release 6, December 2003. covers the interworking of WLAN networks 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. It has not been decided whether some conventions on the format of these SSIDs is required by 3GPP.
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 mechanisms are then employed for routing AAA requests from the VPLMN to the home network.
In order to select the VPLMN, the following is required:
The referenced 3GPP technical specification is a so called stage 2 specification, and contains only the principles of operation, leaving detailed protocol work for later. Nevertheless, the specification states 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.
The security properties related to different mediating network selection mechanisms have been discussed in the 3GPP contribution [33]Ericsson, Security of EAP and SSID based network advertisements, 3GPP Contribution S3-030736, November 2003., which concludes that both 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.
Ahmavaara, Haverinen, and Pichna [35]Ahmavaara, K., Haverinen, H. and R. Pichna, Interworking Architecture between WLAN and 3G Systems, IEEE Communications Magazine, November 2003. 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.
[36]Intel, Wireless LAN (WLAN) End to End Guidelines for Enterprises and Public Hotspot Service Providers, November 2003. 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 [34]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. 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.
| TOC |
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:
We will briefly comment on the specific mechanisms related to network discovery and selection:
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.
| TOC |
All aspects of the network discovery and selection problem are security related. The security issues and requirements have been discussed in the previous sections.
The security requirements for network discovery depend on the type of information being discovered. Some of the parameters may have a security impact, such as the claimed name of the network the user tries to attach to. Unfortunately, current EAP methods do not always make the verification of such parameters possible. New EAP methods are doing it [21]Josefsson, S., Palekar, A., Simon, D. and G. Zorn, Protected EAP Protocol (PEAP), October 2003.[23]Tschofenig, H. and D. Kroeselberg, EAP IKEv2 Method (EAP-IKEv2), February 2004., however, and there is even an attempt to provide a backwards compatible extensions to older methods [14]Arkko, J. and P. Eronen, Authenticated Service Identities for the Extensible Authentication Protocol (EAP), October 2004..
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.
| TOC |
| TOC |
| TOC |
| [12] | Adrangi, F., Lortz, V., Bari, F., Eronen, P. and M. Watson, "Mediating Network Discovery in the Extensible Authentication Protocol (EAP)", draft-adrangi-eap-network-discovery-05 (work in progress), October 2004. |
| [13] | Adrangi, F., "Network Discovery and Selection within the EAP Framework", draft-adrangi-eap-network-discovery-and-selection-00 (work in progress), October 2003. |
| [14] | Arkko, J. and P. Eronen, "Authenticated Service Identities for the Extensible Authentication Protocol (EAP)", draft-arkko-eap-service-identity-auth-01 (work in progress), October 2004. |
| [15] | Tschofenig, H., "Network Selection Implementation Results", draft-groeting-eap-netselection-results-00 (work in progress), July 2004. |
| [16] | Liebsch, M., "Candidate Access Router Discovery", draft-ietf-seamoby-card-protocol-05 (work in progress), November 2003. |
| [17] | 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. |
| [18] | Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 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) Redirection", draft-lior-radius-redirection-00 (work in progress), February 2004. |
| [21] | 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. |
| [22] | Enns, R., Marques, P. and D. Morrell, "Device Discovery Protocol (DDP)", draft-marques-ddp-00 (work in progress), May 2003. |
| [23] | Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method (EAP-IKEv2)", draft-tschofenig-eap-ikev2-03 (work in progress), February 2004. |
| [24] | Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2001. |
| [25] | Institute of Electrical and Electronics Engineers, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 1999. |
| [26] | Aboba, B., "Virtual Access Points", IEEE Contribution 11-03-154r1, May 2003. |
| [27] | Mishra, A., "Improving the latnecy of the Probe Phase during 802.11 Handoff", IEEE Contribution 11-03-417r2, May 2003. |
| [28] | Hepworth, E., "Co-existence of Different Authentication Models", IEEE Contribution 11-03-0827 2003. |
| [29] | Hong, C. and T. Yew, "Interworking - WLAN Control", IEEE Contribution 11-03-0843 2003. |
| [30] | Berg, S., "Information to Support Network Selection", IEEE Contribution 11-04-0624 2004. |
| [31] | Aboba, B., "Network Selection", IEEE Contribution 11-04-0638 2004. |
| [32] | 3GPP, "3GPP System to Wireless Local Area Network (WLAN) interworking; System Description; Release 6", 3GPP Draft Technical Specification 23.234 v 2.2.0, December 2003. |
| [33] | Ericsson, "Security of EAP and SSID based network advertisements", 3GPP Contribution S3-030736, November 2003. |
| [34] | 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. |
| [35] | Ahmavaara, K., Haverinen, H. and R. Pichna, "Interworking Architecture between WLAN and 3G Systems", IEEE Communications Magazine, November 2003. |
| [36] | Intel, "Wireless LAN (WLAN) End to End Guidelines for Enterprises and Public Hotspot Service Providers", November 2003. |
| [37] | 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. |
| [38] | Judd, G. and P. Steenkiste, "Fixing 802.11 Access Point Selection", Sigcomm Poster Session 2002. |
| [39] | Eronen, P., "Network Selection Issues", presentation to EAP WG at IETF 58, November 2003. |
| [40] | Priest, J., "The State of Wireless London", July 2004. |
| [41] | Heusse, M., "Performance Anomaly of 802.11b", LSR-IMAG 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. |
| TOC |
| Jari Arkko | |
| Ericsson | |
| Jorvas 02420 | |
| Finland | |
| EMail: | jari.arkko@ericsson.com |
| Bernard Aboba | |
| Microsoft | |
| One Microsoft Way | |
| Redmond, WA 98052 | |
| USA | |
| EMail: | aboba@internaut.com |
| TOC |
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 [13]Adrangi, F., Network Discovery and Selection within the EAP Framework, October 2003.. 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.
| TOC |
The following modifications have been incorporated to the -01 version of this draft:
| TOC |
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.
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 (C) The Internet Society (2004). 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.
Funding for the RFC Editor function is currently provided by the Internet Society.