diff options
Diffstat (limited to 'doc/rfc/rfc5113.txt')
| -rw-r--r-- | doc/rfc/rfc5113.txt | 2187 |
1 files changed, 2187 insertions, 0 deletions
diff --git a/doc/rfc/rfc5113.txt b/doc/rfc/rfc5113.txt new file mode 100644 index 0000000..080144a --- /dev/null +++ b/doc/rfc/rfc5113.txt @@ -0,0 +1,2187 @@ + + + + + + +Network Working Group J. Arkko +Request for Comments: 5113 Ericsson +Category: Informational B. Aboba + Microsoft + J. Korhonen, Ed. + TeliaSonera + F. Bari + AT&T + January 2008 + + + Network Discovery and Selection Problem + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Abstract + + When multiple access networks are available, users may have + difficulty in selecting which network to connect to and how to + authenticate with that network. This document defines the network + discovery and selection problem, dividing it into multiple sub- + problems. Some constraints on potential solutions are outlined, and + the limitations of several solutions (including existing ones) are + discussed. + + + + + + + + + + + + + + + + + + + + + + + +Arkko, et al. Informational [Page 1] + +RFC 5113 Network Discovery and SP January 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Terminology Used in This Document . . . . . . . . . . . . 4 + 2. Problem Definition . . . . . . . . . . . . . . . . . . . . . . 7 + 2.1. Discovery of Points of Attachment . . . . . . . . . . . . 8 + 2.2. Identity Selection . . . . . . . . . . . . . . . . . . . . 9 + 2.3. AAA Routing . . . . . . . . . . . . . . . . . . . . . . . 11 + 2.3.1. The Default Free Zone . . . . . . . . . . . . . . . . 13 + 2.3.2. Route Selection and Policy . . . . . . . . . . . . . . 14 + 2.3.3. Source Routing . . . . . . . . . . . . . . . . . . . . 15 + 2.4. Network Capabilities Discovery . . . . . . . . . . . . . . 17 + 3. Design Issues . . . . . . . . . . . . . . . . . . . . . . . . 18 + 3.1. AAA Routing . . . . . . . . . . . . . . . . . . . . . . . 18 + 3.2. Backward Compatibility . . . . . . . . . . . . . . . . . . 18 + 3.3. Efficiency Constraints . . . . . . . . . . . . . . . . . . 19 + 3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 19 + 3.5. Static Versus Dynamic Discovery . . . . . . . . . . . . . 21 + 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 3.7. Management . . . . . . . . . . . . . . . . . . . . . . . . 22 + 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 6. Informative References . . . . . . . . . . . . . . . . . . . . 26 + Appendix A. Existing Work . . . . . . . . . . . . . . . . . . . . 32 + A.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 + A.2. IEEE 802 . . . . . . . . . . . . . . . . . . . . . . . . . 33 + A.3. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 + A.4. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 36 + Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 37 + + + + + + + + + + + + + + + + + + + + + + +Arkko, et al. Informational [Page 2] + +RFC 5113 Network Discovery and SP January 2008 + + +1. Introduction + + Today, network access clients are typically pre-configured with a + list of access networks and corresponding identities and credentials. + However, as network access mechanisms and operators have + proliferated, it has become increasingly likely that users will + encounter networks for which no pre-configured settings are + available, yet which offer desired services and the ability to + successfully authenticate with the user's home realm. It is also + possible that pre-configured settings will not be adequate in some + situations. In such a situation, users can have difficulty in + determining which network to connect to, and how to authenticate to + that network. + + The problem arises when any of the following conditions are true: + + o Within a single network, more than one network attachment point is + available, and the attachment points differ in their roaming + arrangements, or access to services. While the link layer + capabilities of a point of attachment may be advertised, higher- + layer capabilities, such as roaming arrangements, end-to-end + quality of service, or Internet access restrictions, may not be. + As a result, a user may have difficulty determining which services + are available at each network attachment point, and which + attachment points it can successfully authenticate to. For + example, it is possible that a roaming agreement will only enable + a user to authenticate to the home realm from some points of + attachment, but not others. Similarly, it is possible that access + to the Internet may be restricted at some points of attachment, + but not others, or that end-to-end quality of service may not be + available in all locations. In these situations, the network + access client cannot assume that all points of attachment within a + network offer identical capabilities. + + o Multiple networks are available for which the user has no + corresponding pre-configuration. The user may not have pre- + configured an identity and associated credentials for use with a + network, yet it is possible that the user's home realm is + reachable from that network, enabling the user to successfully + authenticate. However, unless the roaming arrangements are + advertised, the network access client cannot determine a priori + whether successful authentication is likely. In this situation, + it is possible that the user will need to try multiple networks in + order to find one to which it can successfully authenticate, or it + is possible that the user will not be able to obtain access at + all, even though successful authentication is feasible. + + + + + +Arkko, et al. Informational [Page 3] + +RFC 5113 Network Discovery and SP January 2008 + + + o The user has multiple sets of credentials. Where no pre- + configuration exists, it is possible that the user will not be + able to determine which credentials to use with which attachment + point, or even whether any credentials it possesses will allow it + to authenticate successfully. An identity and associated + credentials can be usable for authentication with multiple + networks, and not all of these networks will be pre-configured. + For example, the user could have one set of credentials from a + public service provider and another set from an employer, and a + network might enable authentication with one or more of these + credentials. Yet, without pre-configuration, multiple + unsuccessful authentication attempts could be needed for each + attachment point in order to determine what credentials are + usable, wasting valuable time and resulting in user frustration. + In order to choose between multiple attachment points, it can be + helpful to provide additional information to enable the correct + credentials to be determined. + + o There are multiple potential roaming paths between the visited + realm and the user's home realm, and service parameters or pricing + differs between them. In this situation, there could be multiple + ways for the user to successfully authenticate using the same + identity and credentials, yet the cost of each approach might + differ. In this case, the access network may not be able to + determine the roaming path that best matches the user's + preferences. This can lead to the user being charged more than + necessary, or not obtaining the desired services. For example, + the visited access realm could have both a direct relationship + with the home realm and an indirect relationship through a roaming + consortium. Current Authentication, Authorization, and Accounting + (AAA) protocols may not be able to route the access request to the + home AAA sever purely based on the realm within the Network Access + Identifier (NAI) [RFC4282]. In addition, payload packets can be + routed or tunneled differently, based on the roaming relationship + path. This may have an impact on the available services or their + pricing. + + In Section 2, the network discovery and selection problem is defined + and divided into sub-problems. Some solution constraints are + outlined in Section 3. Section 4 provides conclusions and + suggestions for future work. Appendix A discusses existing solutions + to portions of the problem. + +1.1. Terminology Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + +Arkko, et al. Informational [Page 4] + +RFC 5113 Network Discovery and SP January 2008 + + + Authentication, Authorization, and Accounting (AAA) + + AAA protocols with EAP support include Remote Authentication + Dial-In User Service (RADIUS) [RFC3579] and Diameter [RFC4072]. + + Access Point (AP) + + An entity that has station functionality and provides access to + distribution services via the wireless medium (WM) for associated + stations. + + Access Technology Selection + + This refers to the selection between access technologies, e.g., + 802.11, Universal Mobile Telecommunications System (UMTS), WiMAX. + The selection will be dependent upon the access technologies + supported by the device and the availability of networks + supporting those technologies. + + Bearer Selection + + For some access technologies (e.g., UMTS), there can be a + possibility for delivery of a service (e.g., voice) by using + either a circuit-switched or packet-switched bearer. Bearer + selection refers to selecting one of the bearer types for service + delivery. The decision can be based on support of the bearer type + by the device and the network as well as user subscription and + operator preferences. + + Basic Service Set (BSS) + + A set of stations controlled by a single coordination function. + + Decorated NAI + + A NAI specifying a source route. See Section 2.7 of RFC 4282 + [RFC4282] for more information. + + Extended Service Set (ESS) + + A set of one or more interconnected basic service sets (BSSs) with + the same Service Set Identifier (SSID) and integrated local area + networks (LANs), which appears as a single BSS to the logical link + control layer at any station associated with one of those BSSs. + This refers to a mechanism that a node uses to discover the + networks that are reachable from a given access network. + + + + + +Arkko, et al. Informational [Page 5] + +RFC 5113 Network Discovery and SP January 2008 + + + Network Access Identifier (NAI) + + The Network Access Identifier (NAI) [RFC4282] is the user identity + submitted by the client during network access authentication. In + roaming, the purpose of the NAI is to identify the user as well as + to assist in the routing of the authentication request. Please + note that the NAI may not necessarily be the same as the user's + e-mail address or the user identity submitted in an application + layer authentication. + + Network Access Server (NAS) + + The device that peers connect to in order to obtain access to the + network. In Point-to-Point Tunneling Protocol (PPTP) terminology, + this is referred to as the PPTP Access Concentrator (PAC), and in + Layer 2 Tunneling Protocol (L2TP) terminology, it is referred to + as the L2TP Access Concentrator (LAC). In IEEE 802.11, it is + referred to as an Access Point (AP). + + Network Discovery + + The mechanism used to discover available networks. The discovery + mechanism may be passive or active, and depends on the access + technology. In passive network discovery, the node listens for + network announcements; in active network discovery, the node + solicits network announcements. It is possible for an access + technology to utilize both passive and active network discovery + mechanisms. + + Network Selection + + Selection of an operator/ISP for network access. Network + selection occurs prior to network access authentication. + + Realm + + The realm portion of an NAI [RFC4282]. + + Realm Selection + + The selection of the realm (and corresponding NAI) used to access + the network. A realm can be reachable from more than one access + network type, and selection of a realm may not enable network + capabilities. + + + + + + + +Arkko, et al. Informational [Page 6] + +RFC 5113 Network Discovery and SP January 2008 + + + Roaming Capability + + Roaming capability can be loosely defined as the ability to use + any one of multiple Internet Service Providers (ISPs), while + maintaining a formal, customer-vendor relationship with only one. + Examples of cases where roaming capability might be required + include ISP "confederations" and ISP-provided corporate network + access support. + + Station (STA) + + A device that contains an IEEE 802.11 conformant medium access + control (MAC) and physical layer (PHY) interface to the wireless + medium (WM). + +2. Problem Definition + + The network discovery and selection problem can be broken down into + multiple sub-problems. These include: + + o Discovery of points of attachment. This involves the discovery of + points of attachment in the vicinity, as well as their + capabilities. + + o Identifier selection. This involves selection of the NAI (and + credentials) used to authenticate to the selected point of + attachment. + + o AAA routing. This involves routing of the AAA conversation back + to the home AAA server, based on the realm of the selected NAI. + + o Payload routing. This involves the routing of data packets, in + the situation where mechanisms more advanced than destination- + based routing are required. While this problem is interesting, it + is not discussed further in this document. + + o Network capability discovery. This involves discovering the + capabilities of an access network, such as whether certain + services are reachable through the access network and the charging + policy. + + Alternatively, the problem can be divided into discovery, decision, + and selection components. The AAA routing problem, for instance, + involves all components: discovery (which mediating networks are + available), decision (choosing the "best" one), and selection + (selecting which mediating network to use) components. + + + + + +Arkko, et al. Informational [Page 7] + +RFC 5113 Network Discovery and SP January 2008 + + +2.1. Discovery of Points of Attachment + + Traditionally, the discovery of points of attachment has been handled + by out-of-band mechanisms or link or network layer advertisements. + + RFC 2194 [RFC2194] describes the pre-provisioning of dial-up roaming + clients, which typically included a list of potential phone numbers + updated by the provider(s) with which the client had a contractual + relationship. RFC 3017 [RFC3017] describes the IETF Proposed + Standard for the Roaming Access eXtensible Markup Language (XML) + Document Type Definition (DTD). This covers not only the attributes + of the Points of Presence (PoP) and Internet Service Providers + (ISPs), but also hints on the appropriate NAI to be used with a + particular PoP. The XML DTD supports dial-in and X.25 access, but + has extensible address and media type fields. + + As access networks and the points of attachment have proliferated, + out-of-band pre-configuration has become increasingly difficult. For + networks with many points of attachment, keeping a complete and up- + to-date list of points of attachment can be difficult. As a result, + wireless network access clients typically only attempt to pre- + configure information relating to access networks, rather than + individual points of attachment. + + In IEEE 802.11 Wireless Local Area Networks (WLAN), the Beacon and + Probe Request/Response mechanism provides a way for Stations to + discover Access Points (AP) and the capabilities of those APs. The + IEEE 802.11 specification [IEEE.802.11-2003] provides support for + both passive (Beacon) and active (Probe Request/Response) discovery + mechanisms; [Fixingapsel] studied the effectiveness of these + mechanisms. + + Among the Information Elements (IE) included within the Beacon and + Probe Response is the Service Set Identifier (SSID), a non-unique + identifier of the network to which an AP is attached. The Beacon/ + Probe facility therefore enables network discovery, as well as the + discovery of points of attachment and the capabilities of those + points of attachment. + + The Global System for Mobile Communications (GSM) specifications also + provide for discovery of points of attachment, as does the Candidate + Access Router Discovery (CARD) [RFC4066] protocol developed by the + IETF SEAMOBY Working Group (WG). + + Along with discovery of points of attachment, the capabilities of + access networks are also typically discovered. These may include: + + + + + +Arkko, et al. Informational [Page 8] + +RFC 5113 Network Discovery and SP January 2008 + + + o Access network name (e.g., IEEE 802.11 SSID) + + o Lower layer security mechanism (e.g., IEEE 802.11 Wired Equivalent + Privacy (WEP) vs. Wi-Fi Protected Access 2 (WPA2)) + + o Quality of service capabilities (e.g., IEEE 802.11e support) + + o Bearer capabilities (e.g., circuit-switched, packet-switched, or + both) + + Even though pre-configuration of access networks scales better than + pre-configuration of points of attachment, where many access networks + can be used to authenticate to a home realm, providing complete and + up-to-date information on each access network can be challenging. + + In such a situation, network access client configuration can be + minimized by providing information relating to each home realm, + rather than each access network. One way to enable this is for an + access network to support "virtual Access Points" (virtual APs), and + for each point of attachment to support virtual APs corresponding to + each reachable home realm. + + While a single IEEE 802.11 network may only utilize a single SSID, it + may cover a wide geographical area, and as a result, may be + segmented, utilizing multiple prefixes. It is possible that a single + SSID may be advertised on multiple channels, and may support multiple + access mechanisms (including Universal Access Method (UAM) and IEEE + 802.1X [IEEE.8021X-2004]) which may differ between points of + attachment. A single SSID may also support dynamic VLAN access as + described in [RFC3580], or may support authentication to multiple + home AAA servers supporting different realms. As a result, users of + a single point of attachment, connecting to the same SSID, may not + have the same set of services available. + +2.2. Identity Selection + + As networks proliferate, it becomes more and more likely that a user + may have multiple identities and credential sets, available for use + in different situations. For example, the user may have an account + with one or more Public WLAN providers, a corporate WLAN, and one or + more wireless Wide Area Network (WAN) providers. + + Typically, the user will choose an identity and corresponding + credential set based on the selected network, perhaps with additional + assistance provided by the chosen authentication mechanism. For + example, if Extensible Authentication Protocol - Transport Layer + Security (EAP-TLS) is the authentication mechanism used with a + particular network, then the user will select the appropriate EAP-TLS + + + +Arkko, et al. Informational [Page 9] + +RFC 5113 Network Discovery and SP January 2008 + + + client certificate based, in part, on the list of trust anchors + provided by the EAP-TLS server. + + However, in access networks where roaming is enabled, the mapping + between an access network and an identity/credential set may not be + one to one. For example, it is possible for multiple identities to + be usable on an access network, or for a given identity to be usable + on a single access network, which may or may not be available. + + Figure 1 illustrates a situation where a user identity may not be + usable on a potential access network. In this case, access network 1 + enables access to users within the realm "isp1.example.com", whereas + access network 3 enables access to users within the realm + "corp2.example.com"; access network 2 enables access to users within + both realms. + + ? ? +---------+ +------------------+ + ? | Access | | | + O_/ _-->| Network |------>|"isp1.example.com"| + /| / | 1 | _->| | + | | +---------+ / +------------------+ + _/ \_ | / + | +---------+ / + User "subscriber@isp1. | | Access |/ + example.com" -- ? -->| Network | + also known as | | 2 |\ + "employee123@corp2. | +---------+ \ + example.com" | \ + | +---------+ \_ +-------------------+ + \_ | Access | ->| | + -->| Network |------>|"corp2.example.com"| + | 3 | | | + +---------+ +-------------------+ + + Figure 1: Two credentials, three possible access networks + + In this situation, a user only possessing an identity within the + "corp2.example.com" realm can only successfully authenticate to + access networks 2 or 3; a user possessing an identity within the + "isp1.example.com" realm can only successfully authenticate to access + networks 1 or 2; a user possessing identities within both realms can + connect to any of the access networks. The question is: how does the + user figure out which access networks it can successfully + authenticate to, preferably prior to choosing a point of attachment? + + Traditionally, hints useful in identity selection have been provided + out-of-band. For example, the XML DTD, described in [RFC3017], + enables a client to select between potential points of attachment as + + + +Arkko, et al. Informational [Page 10] + +RFC 5113 Network Discovery and SP January 2008 + + + well as to select the NAI and credentials to use in authenticating + with it. + + Where all points of attachment within an access network enable + authentication utilizing a set of realms, selection of an access + network provides knowledge of the identities that a client can use to + successfully authenticate. For example, in an access network, the + set of supported realms corresponding to network name can be pre- + configured. + + In some cases, it may not be possible to determine the available + access networks prior to authentication. For example, + [IEEE.8021X-2004] does not support network discovery on IEEE 802 + wired networks, so that the peer cannot determine which access + network it has connected to prior to the initiation of the EAP + exchange. + + It is also possible for hints to be embedded within credentials. In + [RFC4334], usage hints are provided within certificates used for + wireless authentication. This involves extending the client's + certificate to include the SSIDs with which the certificate can be + used. + + However, there may be situations in which an access network may not + accept a static set of realms at every point of attachment. For + example, as part of a roaming agreement, only points of attachment + within a given region or country may be made available. In these + situations, mechanisms such as hints embedded within credentials or + pre-configuration of access network to realm mappings may not be + sufficient. Instead, it is necessary for the client to discover + usable identities dynamically. + + This is the problem that RFC 4284 [RFC4284] attempts to solve, using + the EAP-Request/Identity to communicate a list of supported realms. + However, the problems inherent in this approach are many, as + discussed in Appendix A.1. + + Note that identity selection also implies selection of different + credentials, and potentially, selection of different EAP + authentication methods. In some situations this may imply serious + security vulnerabilities. These are discussed in depth in Section 5. + +2.3. AAA Routing + + Once the identity has been selected, the AAA infrastructure needs to + route the access request back to the home AAA server. Typically, the + routing is based on the Network Access Identifier (NAI) defined in + [RFC4282]. + + + +Arkko, et al. Informational [Page 11] + +RFC 5113 Network Discovery and SP January 2008 + + + Where the NAI does not encode a source route, the routing of requests + is determined by the AAA infrastructure. As described in [RFC2194], + most roaming implementations are relatively simple, relying on a + static realm routing table that determines the next hop based on the + NAI realm included in the User-Name attribute within the Access- + Request. Within RADIUS, the IP address of the home AAA server is + typically determined based on static mappings of realms to IP + addresses maintained within RADIUS proxies. + + Diameter [RFC3588] supports mechanisms for intra- and inter-domain + service discovery, including support for DNS as well as service + discovery protocols such as Service Location Protocol version 2 + (SLPv2) [RFC2608]. As a result, it may not be necessary to configure + static tables mapping realms to the IP addresses of Diameter agents. + However, while this simplifies maintenance of the AAA routing + infrastructure, it does not necessarily simplify roaming-relationship + path selection. + + As noted in RFC 2607 [RFC2607], RADIUS proxies are deployed not only + for routing purposes, but also to mask a number of inadequacies in + the RADIUS protocol design, such as the lack of standardized + retransmission behavior and the need for shared secret provisioning + between each AAA client and server. + + Diameter [RFC3588] supports certificate-based authentication (using + either TLS or IPsec) as well as Redirect functionality, enabling a + Diameter client to obtain a referral to the home server from a + Diameter redirect server, so that the client can contact the home + server directly. In situations in which a trust model can be + established, these Diameter capabilities can enable a reduction in + the length of the roaming relationship path. + + However, in practice there are a number of pitfalls. In order for + certificate-based authentication to enable communication between a + Network Access Server (NAS) or local proxy and the home AAA server, + trust anchors need to be configured, and certificates need to be + selected. The AAA server certificate needs to chain to a trust + anchor configured on the AAA client, and the AAA client certificate + needs to chain to a trust anchor configured on the AAA server. Where + multiple potential roaming relationship paths are available, this + will reflect itself in multiple certificate choices, transforming the + path selection problem into a certificate selection problem. + Depending on the functionality supported within the certificate + selection implementation, this may not make the problem easier to + solve. For example, in order to provide the desired control over the + roaming path, it may be necessary to implement custom certificate + selection logic, which may be difficult to introduce within a + + + + +Arkko, et al. Informational [Page 12] + +RFC 5113 Network Discovery and SP January 2008 + + + certificate handling implementation designed for general-purpose + usage. + + As noted in [RFC4284], it is also possible to utilize an NAI for the + purposes of source routing. In this case, the client provides + guidance to the AAA infrastructure as to how it would like the access + request to be routed. An NAI including source-routing information is + said to be "decorated"; the decoration format is defined in + [RFC4282]. + + When decoration is utilized, the EAP peer provides the decorated NAI + within the EAP-Response/Identity, and as described in [RFC3579], the + NAS copies the decorated NAI included in the EAP-Response/Identity + into the User-Name attribute included within the access request. As + the access request transits the roaming relationship path, AAA + proxies determine the next hop based on the realm included within the + User-Name attribute, in the process, successively removing decoration + from the NAI included in the User-Name attribute. In contrast, the + decorated NAI included within the EAP-Response/Identity encapsulated + in the access request remains untouched. As a result, when the + access request arrives at the AAA home server, the decorated NAI + included in the EAP-Response/Identity may differ from the NAI + included in the User-Name attribute (which may have some or all of + the decoration removed). For the purpose of identity verification, + the EAP server utilizes the NAI in the User-Name attribute, rather + than the NAI in the EAP-Response/Identity. + + Over the long term, it is expected that the need for NAI "decoration" + and source routing will disappear. This is somewhat analogous to the + evolution of email delivery. Prior to the widespread proliferation + of the Internet, it was necessary to gateway between SMTP-based mail + systems and alternative delivery technologies, such as Unix-to-Unix + CoPy Protocol (UUCP) and FidoNet. Prior to the implementation of + email gateways utilizing MX RR routing, email address-based source- + routing was used extensively. However, over time the need for email + source-routing disappeared. + +2.3.1. The Default Free Zone + + AAA clients on the edge of the network, such as NAS devices and local + AAA proxies, typically maintain a default realm route, providing a + default next hop for realms not otherwise taken into account within + the realm routing table. This permits devices with limited resources + to maintain a small realm routing table. Deeper within the AAA + infrastructure, AAA proxies may be maintained with a "default free" + realm table, listing next hops for all known realms, but not + providing a default realm route. + + + + +Arkko, et al. Informational [Page 13] + +RFC 5113 Network Discovery and SP January 2008 + + + While dynamic realm routing protocols are not in use within AAA + infrastructure today, even if such protocols were to be introduced, + it is likely that they would be deployed solely within the core AAA + infrastructure, but not on NAS devices, which are typically resource + constrained. + + Since NAS devices do not maintain a full realm routing table, they do + not have knowledge of all the realms reachable from the local + network. The situation is analogous to that of Internet hosts or + edge routers that do not participate in the BGP mesh. In order for + an Internet host to determine whether it can reach a destination on + the Internet, it is necessary to send a packet to the destination. + + Similarly, when a user provides an NAI to the NAS, the NAS does not + know a priori whether or not the realm encoded in the NAI is + reachable; it simply forwards the access request to the next hop on + the roaming relationship path. Eventually, the access request + reaches the "default free" zone, where a core AAA proxy determines + whether or not the realm is reachable. As described in [RFC4284], + where EAP authentication is in use, the core AAA proxy can send an + Access-Reject, or it can send an Access-Challenge encapsulating an + EAP-Request/Identity containing "realm hints" based on the content of + the "default free" realm routing table. + + There are a number of intrinsic problems with this approach. Where + the "default free" routing table is large, it may not fit within a + single EAP packet, and the core AAA proxy may not have a mechanism + for selecting the most promising entries to include. Even where the + "default free" realm routing table would fit within a single EAP- + Request/Identity packet, the core AAA router may not choose to + include all entries, since the list of realm routes could be + considered confidential information not appropriate for disclosure to + hosts seeking network access. Therefore, it cannot be assumed that + the list of "realm hints" included within the EAP-Request/Identity is + complete. Given this, a NAS or local AAA proxy snooping the EAP- + Request/Identity cannot rely on it to provide a complete list of + reachable realms. The "realm hint" mechanism described in [RFC4284] + is not a dynamic routing protocol. + +2.3.2. Route Selection and Policy + + Along with lack of a dynamic AAA routing protocol, today's AAA + infrastructure lacks mechanisms for route selection and policy. As a + result, multiple routes may exist to a destination realm, without a + mechanism for the selection of a preferred route. + + + + + + +Arkko, et al. Informational [Page 14] + +RFC 5113 Network Discovery and SP January 2008 + + + In Figure 2, Roaming Groups 1 and 2 both include a route to the realm + "a.example.com". However, these realm routes are not disseminated to + the NAS along with associated metrics, and, as a result, there is no + mechanism for implementation of dynamic routing policies (such as + selection of realm routes by shortest path, or preference for routes + originating at a given proxy). + + +---------+ + | |----> "a.example.com" + | Roaming | + +---------+ | Group 1 | + | |----->| Proxy |----> "b.example.com" + user "joe@ | Access | +---------+ + a.example.com"--->| Provider| + | NAS | +---------+ + | |----->| |----> "a.example.com" + +---------+ | Roaming | + | Group 2 | + | Proxy |----> "c.example.com" + +---------+ + + Figure 2: Multiple routes to a destination realm + + In the example in Figure 2, access through Roaming Group 1 may be + less expensive than access through Roaming Group 2, and as a result + it would be desirable to prefer Roaming Group 1 as a next hop for an + NAI with a realm of "a.example.com". However, the only way to obtain + this result would be to manually configure the NAS realm routing + table with the following entries: + + Realm Next Hop + ----- -------- + b.example.com Roaming Group 1 + c.example.com Roaming Group 2 + Default Roaming Group 1 + + While manual configuration may be practical in situations where the + realm routing table is small and entries are static, where the list + of supported realms change frequently, or the preferences change + dynamically, manual configuration will not be manageable. + +2.3.3. Source Routing + + Due to the limitations of current AAA routing mechanisms, there are + situations in which NAI-based source routing is used to influence the + roaming relationship path. However, since the AAA proxies on the + roaming relationship path are constrained by existing relationships, + NAI-based source routing is not source routing in the classic sense; + + + +Arkko, et al. Informational [Page 15] + +RFC 5113 Network Discovery and SP January 2008 + + + it merely suggests preferences that the AAA proxy can choose not to + accommodate. + + Where realm routes are set up as the result of pre-configuration and + dynamic route establishment is not supported, if a realm route does + not exist, then NAI-based source routing cannot establish it. Even + where dynamic route establishment is possible, such as where the AAA + client and server support certificate-based authentication, and AAA + servers are discoverable (such as via the mechanisms described in + [RFC3588]), an AAA proxy may choose not to establish a realm route by + initiating the discovery process based on a suggestion in an NAI- + based source route. + + Where the realm route does exist, or the AAA proxy is capable of + establishing it dynamically, the AAA proxy may choose not to + authorize the client to use it. + + While, in principle, source routing can provide users with better + control over AAA routing decisions, there are a number of practical + problems to be overcome. In order to enable the client to construct + optimal source routes, it is necessary for it to be provided with a + complete and up-to-date realm routing table. However, if a solution + to this problem were readily available, then it could be applied to + the AAA routing infrastructure, enabling the selection of routes + without the need for user intervention. + + As noted in [Eronen04], only a limited number of parameters can be + updated dynamically. For example, quality of service or pricing + information typically will be pre-provisioned or made available on + the web rather than being updated on a continuous basis. Where realm + names are communicated dynamically, the "default free" realm list is + unlikely to be provided in full since this table could be quite + large. Given the constraints on the availability of information, the + construction of source routes typically needs to occur in the face of + incomplete knowledge. + + In addition, there are few mechanisms available to audit whether the + requested source route is honored by the AAA infrastructure. For + example, an access network could advertise a realm route to + "costsless.example.com", while instead routing the access-request + through "costsmore.example.com". While the decorated NAI would be + made available to the home AAA server in the EAP-Response/Identity, + the home AAA server might have a difficult time verifying that the + source route requested in the decorated NAI was actually honored by + the AAA infrastructure. Similarly, it could be difficult to + determine whether quality of service (QoS) or other routing requests + were actually provided as requested. To some extent, this problem + + + + +Arkko, et al. Informational [Page 16] + +RFC 5113 Network Discovery and SP January 2008 + + + may be addressed as part of the business arrangements between roaming + partners, which may provide minimum service-level guarantees. + + Given the potential issues with source routing, conventional AAA + routing mechanisms are to be preferred wherever possible. Where an + error is encountered, such as an attempt to authenticate to an + unreachable realm, "realm hints" can be provided as described + [RFC4284]. However, this approach has severe scalability + limitations, as outlined in Appendix A.1. + +2.4. Network Capabilities Discovery + + Network capability discovery focuses on discovery of the services + offered by networks, not just the capabilities of individual points + of attachment. By acquiring additional information on access network + characteristics, it is possible for users to make a more informed + access decision. These characteristics may include: + + o Roaming relationships between the access network provider and + other network providers and associated costs. Where the network + access client is not pre-configured with an identity and + credentials corresponding to a local access network, it will need + to be able to determine whether one or more home realms are + reachable from an access network so that successful authentication + can be possible. + + o EAP authentication methods. While the EAP authentication methods + supported by a home realm can only be determined by contacting the + home AAA server, it is possible that the local realm will also + support one or more EAP methods. For example, a user may be able + to utilize EAP-SIM (Extensible Authentication Protocol - + Subscriber Identity Module) to authenticate to the access network + directly, rather than having to authenticate to the home network. + + o End-to-end quality of service capability. While local quality of + service capabilities are typically advertised by the access + network (e.g., support for Wi-Fi Multimedia (WMM)), the + availability of end-to-end QoS services may not be advertised. + + o Service parameters, such as the existence of middleboxes or + firewalls. If the network access client is not made aware of the + Internet access that it will receive on connecting to a point of + attachment, it is possible that the user may not be able to access + the desired services. + + Reference [IEEE.11-04-0624] classifies the possible steps at which + IEEE 802.11 networks can acquire this information: + + + + +Arkko, et al. Informational [Page 17] + +RFC 5113 Network Discovery and SP January 2008 + + + o Pre-association + + o Post-association (or pre-authentication) + + o Post-authentication + + In the interest of minimizing connectivity delays, all of the + information required for network selection (including both access + network capabilities and global characteristics) needs to be provided + prior to authentication. + + By the time authentication occurs, the node has typically selected + the access network, the NAI to be used to authenticate, as well as + the point of attachment. Should it learn information during the + authentication process that would cause it to revise one or more of + those decisions, the node will need to select a new network, point of + attachment, and/or identity, and then go through the authentication + process all over again. Such a process is likely to be both time + consuming and unreliable. + +3. Design Issues + + The following factors should be taken into consideration while + evaluating solutions to the problem of network selection and + discovery. + +3.1. AAA Routing + + Solutions to the AAA routing issues discussed in Section 2.3 need to + apply to a wide range of AAA messages, and should not restrict the + introduction of new AAA or access network functionality. For + example, AAA routing mechanisms should work for access requests and + responses as well as accounting requests and responses and server- + initiated messages. Solutions should not restrict the development of + new AAA attributes, access types, or performance optimizations (such + as fast handoff support). + +3.2. Backward Compatibility + + Solutions need to maintain backward compatibility. In particular: + + o Selection-aware clients need to interoperate with legacy NAS + devices and AAA servers. + + o Selection-aware AAA infrastructure needs to interoperate with + legacy clients and NAS devices. + + + + + +Arkko, et al. Informational [Page 18] + +RFC 5113 Network Discovery and SP January 2008 + + + For example, selection-aware clients should not transmit packets + larger than legacy NAS devices or AAA servers can handle. Where + protocol extensions are required, changes should be required to as + few infrastructure elements as possible. For example, extensions + that require upgrades to existing NAS devices will be more difficult + to deploy than proposals that are incrementally deployable based on + phased upgrades of clients or AAA servers. + +3.3. Efficiency Constraints + + Solutions should be efficient as measured by channel utilization, + bandwidth consumption, handoff delay, and energy utilization. + Mechanisms that depend on multicast frames need to be designed with + care since multicast frames are often sent at the lowest supported + rate and therefore consume considerable channel time as well as + energy on the part of listening nodes. Depending on the deployment, + it is possible for bandwidth to be constrained both on the link, as + well as in the backend AAA infrastructure. As a result, chatty + mechanisms such as keepalives or periodic probe packets are to be + avoided. Given the volume handled by AAA servers, solutions should + also be conscious of adding to the load, particularly in cases where + this could enable denial-of-service attacks. For example, it would + be a bad idea for a NAS to attempt to obtain an updated realm routing + table by periodically sending probe EAP-Response/Identity packets to + the AAA infrastructure in order to obtain "realm hints" as described + in [RFC4284]. Not only would this add significant load to the AAA + infrastructure (particularly in cases where the AAA server was + already overloaded, thereby dropping packets resulting in + retransmission by the NAS), but it would also not provide the NAS + with a complete realm routing table, for reasons described in + Section 2.3. + + Battery consumption is a significant constraint for handheld devices. + Therefore, mechanisms that require significant increases in packets + transmitted, or the fraction of time during which the host needs to + listen (such as proposals that require continuous scanning), are to + be discouraged. In addition, the solution should not significantly + impact the time required to complete network attachment. + +3.4. Scalability + + Given limitations on frame sizes and channel utilization, it is + important that solutions scale less than linearly in terms of the + number of networks and realms supported. For example, solutions such + as [RFC4284] increase the size of advertisements in proportion to the + number of entries in the realm routing table. This approach does not + scale to support a large number of networks and realms. + + + + +Arkko, et al. Informational [Page 19] + +RFC 5113 Network Discovery and SP January 2008 + + + Similarly, approaches that utilize separate Beacons for each "virtual + AP" introduce additional Beacons in proportion to the number of + networks being advertised. While such an approach may minimize the + pre-configuration required for network access clients, the + proliferation of "virtual APs" can result in high utilization of the + wireless medium. For example, the 802.11 Beacon is sent only at a + rate within the basic rate set, which typically consists of the + lowest supported rates, or perhaps only the lowest supported rate. + As a result, "virtual AP" mechanisms that require a separate Beacon + for each "virtual AP" do not scale well. + + For example, with a Beacon interval of 100 Time Units (TUs) or 102.4 + ms (9.8 Beacons/second), twenty 802.11b "virtual APs" each announcing + their own Beacon of 170 octets would result in a channel utilization + of 37.9 percent. The calculation can be verified as follows: + + 1. A single 170-octet Beacon sent at 1 Mbps will utilize the channel + for 1360 us (1360 bits @ 1 Mbps); + + 2. Adding 144 us for the Physical Layer Convergence Procedure (PLCP) + long preamble (144 bits @ 1 Mbps), 48 us for the PLCP header (48 + bits @ 1 Mbps), 10 us for the Short Interframe Space (SIFS), 50 us + for the Distributed Interframe Space (DIFS), and 320 us for the + average minimum Contention Window without backoff (CWmin/2 * + aSlotTime = 32/2 * 20 us) implies that a single Beacon will + utilize an 802.11b channel for 1932 us; + + 3. Multiply the channel time per Beacon by 196 Beacons/second, and we + obtain a channel utilization of 378672 us/second = 37.9 percent. + + In addition, since Beacon/Probe Response frames are sent by each AP + over the wireless medium, stations can only discover APs within + range, which implies substantial coverage overlap for roaming to + occur without interruption. Another issue with the Beacon and Probe + Request/Response mechanism is that it is either insecure or its + security can be assured only as part of authenticating to the network + (e.g., verifying the advertised capabilities within the 4-way + handshake). + + A number of enhancements have been proposed to the Beacon/Probe + Response mechanism in order to improve scalability and performance in + roaming scenarios. These include allowing APs to announce + capabilities of neighbor APs as well as their own [IEEE.802.11k]. + More scalable mechanisms for support of "virtual APs" within IEEE + 802.11 have also been proposed [IEEE.802.11v]; generally these + proposals collapse multiple "virtual AP" advertisements into a single + advertisement. + + + + +Arkko, et al. Informational [Page 20] + +RFC 5113 Network Discovery and SP January 2008 + + + Higher-layer mechanisms can also be used to improve scalability + since, by running over IP, they can utilize facilities, such as + fragmentation, that may not be available at the link layer. For + example, in IEEE 802.11, Beacon frames cannot use fragmentation + because they are multicast frames. + +3.5. Static Versus Dynamic Discovery + + "Phone-book" based approaches such as [RFC3017] can provide + information for automatic selection decisions. While this approach + has been applied to wireless access, it typically can only be used + successfully within a single operator or limited roaming partner + deployment. For example, were a "Phone-Book" approach to attempt to + incorporate information from a large number of roaming partners, it + could become quite difficult to keep the information simultaneously + comprehensive and up to date. As noted in [Priest04] and [GROETING], + a large fraction of current WLAN access points operate on the default + SSID, which may make it difficult to distinguish roaming partner + networks by SSID. In any case, in wireless networks, dynamic + discovery is a practical requirement since a node needs to know which + APs are within range before it can connect. + +3.6. Security + + Network discovery and selection mechanisms may introduce new security + vulnerabilities. As noted in Section 2.3.1, network operators may + consider the AAA routing table to be confidential information, and + therefore may not wish to provide it to unauthenticated peers via the + mechanism described in RFC 4284. While the peer could provide a list + of the realms it supports, with the authenticator choosing one, this + approach raises privacy concerns. Since identity selection occurs + prior to authentication, the peer's supported realms would be sent in + cleartext, enabling an attacker to determine the realms for which a + potential victim has credentials. This risk can be mitigated by + restricting peer disclosure. For example, a peer may only disclose + additional realms in situations where an initially selected identity + has proved unusable. + + Since network selection occurs prior to authentication, it is + typically not possible to secure mechanisms for network discovery or + identity selection, although it may be possible to provide for secure + confirmation after authentication is complete. As an example, some + parameters discovered during network discovery may be confirmable via + EAP Channel Bindings; others may be confirmed in a subsequent Secure + Association Protocol handshake. + + + + + + +Arkko, et al. Informational [Page 21] + +RFC 5113 Network Discovery and SP January 2008 + + + However, there are situations in which advertised parameters may not + be confirmable. This could lead to "bidding down" vulnerabilities. + Section 7.8 of [RFC3748] states: + + Within or associated with each authenticator, it is not + anticipated that a particular named peer will support a choice of + methods. This would make the peer vulnerable to attacks that + negotiate the least secure method from among a set. Instead, for + each named peer, there SHOULD be an indication of exactly one + method used to authenticate that peer name. If a peer needs to + make use of different authentication methods under different + circumstances, then distinct identities SHOULD be employed, each + of which identifies exactly one authentication method. + + In practice, where the authenticator operates in "pass-through" mode, + the EAP method negotiation will occur between the EAP peer and + server, and therefore the peer will need to associate a single EAP + method with a given EAP server. Where multiple EAP servers and + corresponding identities may be reachable from the same selected + network, the EAP peer may have difficulty determining which identity + (and corresponding EAP method) should be used. Unlike network + selection, which may be securely confirmed within a Secure + Association Protocol handshake, identity selection hints provided + within the EAP-Request/Identity are not secured. + + As a result, where the identity selection mechanism described in RFC + 4284 is used, the "hints" provided could be used by an attacker to + convince the victim to select an identity corresponding to an EAP + method offering lesser security (e.g., EAP MD5-Challenge). One way + to mitigate this risk is for the peer to only utilize EAP methods + satisfying the [RFC4017] security requirements, and for the peer to + select the identity corresponding to the strongest authentication + method where a choice is available. + +3.7. Management + + From an operational point of view, a network device in control of + network advertisement and providing "realm hints" for guiding the + network discovery and selection, should at least offer a management + interface capable of providing status information for operators. + Status information, such as counters of each selected network and + used realm, and when RFC 4284 is used, the count of delivered "realm + hints" might interest operators. Especially the information related + to realms that fall into the "default free zone" or the "AAA fails to + route" are of interest. + + Larger deployments would benefit from a management interface that + allow full remote configuration capabilities, for example, of "realm + + + +Arkko, et al. Informational [Page 22] + +RFC 5113 Network Discovery and SP January 2008 + + + hints" in case of RFC 4284-conforming network devices. While changes + to "realm hints" and realm routing information are not expected to be + frequent, centralized remote management tends to lower the frequency + of misconfigured devices. + +4. Conclusions + + This document describes the network selection and discovery problem. + In the opinion of the authors, the major findings are as follows: + + o There is a need for additional work on access network discovery, + identifier selection, AAA routing, and payload routing. + + o Credential selection and AAA routing are aspects of the same + problem, namely identity selection. + + o When considering selection among a large number of potential + access networks and points of attachment, the issues described in + the document become much harder to solve in an automated way, + particularly if there are constraints on handoff latency. + + o The proliferation of network discovery technologies within IEEE + 802, IETF, and 3rd Generation Partnership Project (3GPP) has the + potential to become a significant problem going forward. Without + a unified approach, multiple non-interoperable solutions may be + deployed. + + o New link-layer designs should include efficient distribution of + network and realm information as a design requirement. + + o It may not be possible to solve all aspects of the problem for + legacy NAS devices on existing link layers. Therefore, a phased + approach may be more realistic. For example, a partial solution + could be made available for existing link layers, with a more + complete solution requiring support for link layer extensions. + + With respect to specific mechanisms for access network discovery and + selection: + + o Studies such as [MACScale] and [Velayos], as well as the + calculations described in Section 2.1, demonstrate that the IEEE + 802.11 Beacon/Probe Response mechanism has substantial scaling + issues in situations where a new Beacon is used for each "virtual + AP". As a result, a single channel is, in practice, limited to + less than twenty Beacon announcements with IEEE 802.11b. + + + + + + +Arkko, et al. Informational [Page 23] + +RFC 5113 Network Discovery and SP January 2008 + + + The situation is improved substantially with successors, such as + IEEE 802.11a, that enable additional channels, thus potentially + increasing the number of potential virtual APs. + + However, even with these enhancements, it is not feasible to + advertise more than 50 different networks, and probably less in + most circumstances. + + As a result, there appears to be a need to enhance the scalability + of IEEE 802.11 network advertisements. + + o Work is underway in IEEE 802.1, IEEE 802.21, and IEEE 802.11u + [IEEE.802.11u] to provide enhanced discovery functionality. + Similarly, IEEE 802.1af [IEEE.802.1af] has discussed the addition + of network discovery functionality to IEEE 802.1X + [IEEE.8021X-2004]. However, neither IEEE 802.1AB [IEEE.802.1ab] + nor IEEE 802.1af is likely to support fragmentation of network + advertisement frames so that the amount of data that can be + transported will be limited. + + o While IEEE 802.11k [IEEE.802.11k] provides support for the + Neighbor Report, this only provides for gathering of information + on neighboring 802.11 APs, not points of attachment supporting + other link layers. Solution to this problem would appear to + require coordination across IEEE 802 as well as between standards + bodies. + + o Given that EAP does not support fragmentation of EAP-Request/ + Identity packets, the volume of "realm hints" that can be fit with + these packets is limited. In addition, within IEEE 802.11, EAP + packets can only be exchanged within State 3 (associated and + authenticated). As a result, use of EAP for realm discovery may + result in significant delays. The extension of the realm + advertisement mechanism defined in [RFC4284] to handle + advertisement of realm capability information (such as QoS + provisioning) is not recommended due to semantic and packet size + limitations [GROETING]. As a result, we believe that extending + the mechanism described in [RFC4284] for discovery of realm + capabilities is inappropriate. Instead, we believe it is more + appropriate for this functionality to be handled within the link + layer so that the information can be available early in the + handoff process. + + o Where link-layer approaches are not available, higher-layer + approaches can be considered. A limitation of higher-layer + solutions is that they can only optimize the movement of already + connected hosts, but cannot address scenarios where network + discovery is required for successful attachment. + + + +Arkko, et al. Informational [Page 24] + +RFC 5113 Network Discovery and SP January 2008 + + + Higher-layer alternatives worth considering include the SEAMOBY + CARD protocol [RFC4066], which enables advertisement of network + device capabilities over IP, and Device Discovery Protocol (DDP) + [MARQUES], which provides functionality equivalent to IEEE 802.1AB + using ASN.1 encoded advertisements sent to a link-local scope + multicast address. + +5. Security Considerations + + All aspects of the network discovery and selection problem are + security related. The security issues and requirements have been + discussed in the previous sections. + + The security requirements for network discovery depend on the type of + information being discovered. Some of the parameters may have a + security impact, such as the claimed name of the network to which the + user tries to attach. Unfortunately, current EAP methods do not + always make the verification of such parameters possible. EAP + methods, such as Protected EAP (PEAP) [JOSEFSSON] and EAP-IKEv2 + [IKEV2], may make this possible, however. There is even an attempt + to provide a backward-compatible extension to older methods [ARKKO]. + + The security requirements for network selection depend on whether the + selection is considered a mandate or a hint. In general, treating + network advertisements as a hint is a more secure approach, since it + reduces access client vulnerability to forged network advertisements. + For example, "realm hints" may be ignored by an EAP peer if they are + incompatible with the security policy corresponding to a selected + access network. + + Similarly, network access clients may refuse to connect to a point of + attachment if the advertised security capabilities do not match those + that have been pre-configured. For example, if an IEEE 802.11 access + client has been pre-configured to require WPA2 enterprise support + within an access network, it may refuse to connect to access points + advertising support for WEP. + + Where the use of methods that do not satisfy the security + requirements of [RFC4017] is allowed, it may be possible for an + attacker to trick a peer into using an insecure EAP method, leading + to the compromise of long-term credentials. This can occur either + where a network is pre-configured to allow use of an insecure EAP + method, or where connection without pre-configuration is permitted + using such methods. + + For example, an attacker can spoof a network advertisement, possibly + downgrading the advertised security capabilities. The rogue access + point would then attempt to negotiate an insecure EAP method. Such + + + +Arkko, et al. Informational [Page 25] + +RFC 5113 Network Discovery and SP January 2008 + + + an attack can be prevented if the peer refuses to connect to access + points not meeting its security requirements, which would include + requiring use of EAP methods satisfying the [RFC4017] requirements. + + Support for secure discovery could potentially protect against + spoofing of network advertisements, enabling verifiable information + to guide connection decisions. However, development of these + mechanisms requires solving several difficult engineering and + deployment problems. + + Since discovery is a prerequisite for authentication, it is not + possible to protect initial discovery using dynamic keys derived in + the authentication process. On the other hand, integrity protection + of network advertisements utilizing symmetric keys or digital + signatures would require pre-configuration. + +6. Informative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. + Arkko, "Diameter Base Protocol", RFC 3588, September 2003. + + [RFC3017] Riegel, M. and G. Zorn, "XML DTD for Roaming Access Phone + Book", RFC 3017, December 2000. + + [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. + Levkowetz, "Extensible Authentication Protocol (EAP)", + RFC 3748, June 2004. + + [RFC4334] Housley, R. and T. Moore, "Certificate Extensions and + Attributes Supporting Authentication in Point-to-Point + Protocol (PPP) and Wireless Local Area Networks (WLAN)", + RFC 4334, February 2006. + + [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The + Network Access Identifier", RFC 4282, December 2005. + + [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + + + + +Arkko, et al. Informational [Page 26] + +RFC 5113 Network Discovery and SP January 2008 + + + [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible + Authentication Protocol (EAP) Application", RFC 4072, + August 2005. + + [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication + Dial In User Service) Support For Extensible + Authentication Protocol (EAP)", RFC 3579, September 2003. + + [RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, + "Review of Roaming Implementations", RFC 2194, + September 1997. + + [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy + Implementation in Roaming", RFC 2607, June 1999. + + [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, + "Service Location Protocol, Version 2", RFC 2608, + June 1999. + + [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, + "IEEE 802.1X Remote Authentication Dial In User Service + (RADIUS) Usage Guidelines", RFC 3580, September 2003. + + [RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity + Selection Hints for the Extensible Authentication Protocol + (EAP)", RFC 4284, January 2006. + + [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible + Authentication Protocol (EAP) Method Requirements for + Wireless LANs", RFC 4017, March 2005. + + [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", + RFC 2486, January 1999. + + [RFC4066] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. + Shim, "Candidate Access Router Discovery (CARD)", + RFC 4066, July 2005. + + [IKEV2] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., + and F. Bersani, "EAP-IKEv2 Method", Work in Progress, + September 2007. + + [ARKKO] Arkko, J. and P. Eronen, "Authenticated Service + Information for the Extensible Authentication Protocol + (EAP)", Work in Progress, October 2005. + + + + + + +Arkko, et al. Informational [Page 27] + +RFC 5113 Network Discovery and SP January 2008 + + + [GROETING] Groeting, W., Berg, S., Tschofenig, H., and M. Ness, + "Network Selection Implementation Results", Work + in Progress, July 2004. + + [JOSEFSSON] + Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G., + and S. Josefsson, "Protected EAP Protocol (PEAP) Version + 2", Work in Progress, October 2004. + + [MARQUES] Enns, R., Marques, P., and D. Morrell, "Device Discovery + Protocol (DDP)", Work in Progress, May 2003. + + [OHBA] Taniuchi, K., Ohba, Y., and D. Subir, "IEEE 802.21 Basic + Schema", Work in Progress, October 2007. + + [IEEE.802.11-2003] + IEEE, "Wireless LAN Medium Access Control (MAC) and + Physical Layer (PHY) Specifications", IEEE Standard + 802.11, 2003. + + [Fixingapsel] + Judd, G. and P. Steenkiste, "Fixing 802.11 Access Point + Selection", Sigcomm Poster Session 2002. + + [IEEE.802.11k] + IEEE, "Draft Ammendment to Standard for Telecommunications + and Information Exchange Between Systems - LAN/MAN + Specific Requirements - Part 11: Wireless LAN Medium + Access Control (MAC) and Physical Layer (PHY) + Specifications: Radio Resource Management", IEEE 802.11k, + D7.0, January 2007. + + [IEEE.802.1ab] + IEEE, "Draft Standard for Local and Metropolitan Area + Networks - Station and Media Access Control Connectivity + Discovery", IEEE 802.1AB, D1.0, April 2007. + + [IEEE.802.1af] + IEEE, "Draft Standard for Local and Metropolitan Area + Networks - Port-Based Network Access Control - Amendment + 1: Authenticated Key Agreement for Media Access Control + (MAC) Security", IEEE 802.1af, D1.2, January 2007. + + + + + + + + + +Arkko, et al. Informational [Page 28] + +RFC 5113 Network Discovery and SP January 2008 + + + [IEEE.802.11v] + IEEE, "Draft Amemdment to Standard for Information + Technology - Telecommunications and Information Exchange + Between Systems - LAN/MAN Specific Requirements - Part 11: + Wireless Medium Access Control (MAC) and physical layer + (PHY) specifications: Wireless Network Management", + IEEE 802.11v, D0.09, March 2007. + + [Eronen04] + Eronen, P. and J. Arkko, "Role of authorization in + wireless network security", Extended abstract presented in + the DIMACS workshop, November 2004. + + [IEEE.11-04-0624] + Berg, S., "Information to Support Network Selection", IEEE + Contribution 11-04-0624 2004. + + [Priest04] + Priest, J., "The State of Wireless London", July 2004. + + [MACScale] + Heusse, M., "Performance Anomaly of 802.11b", LSR-IMAG + Laboratory, Grenoble, France, IEEE Infocom 2003. + + [Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE + 802.11b MAC Layer Handover Time", Laboratory for + Communication Networks, KTH, Royal Institute of + Technology, Stockholm, Sweden, TRITA-IMIT-LCN R 03:02, + April 2003. + + [IEEE.802.11u] + IEEE, "Draft Amendment to STANDARD FOR Information + Technology - LAN/MAN Specific Requirements - Part 11: + Interworking with External Networks; Draft Amendment to + Standard; IEEE P802.11u/D0.04", IEEE 802.11u, D0.04, + April 2007. + + [IEEE-11-03-154r1] + Aboba, B., "Virtual Access Points", IEEE Contribution 11- + 03-154r1, May 2003. + + [IEEE-11-03-0827] + Hepworth, E., "Co-existence of Different Authentication + Models", IEEE Contribution 11-03-0827 2003. + + + + + + + +Arkko, et al. Informational [Page 29] + +RFC 5113 Network Discovery and SP January 2008 + + + [11-05-0822-03-000u-tgu-requirements] + Moreton, M., "TGu Requirements", IEEE Contribution 11-05- + 0822-03-000u-tgu-requirements, August 2005. + + [3GPPSA2WLANTS] + 3GPP, "3GPP System to Wireless Local Area Network (WLAN) + interworking; System De scription; Release 6; Stage 2", + 3GPP Technical Specification 23.234, September 2005. + + [3GPP-SA3-030736] + Ericsson, "Security of EAP and SSID based network + advertisements", 3GPP Contribution S3-030736, + November 2003. + + [3GPP.23.122] + 3GPP, "Non-Access-Stratum (NAS) functions related to + Mobile Station (MS) in idle mode", 3GPP TS 23.122 6.5.0, + October 2005. + + [WWRF-ANS] + Eijk, R., Brok, J., Bemmel, J., and B. Busropan, "Access + Network Selection in a 4G Environment and the Role of + Terminal and Service Platform", 10th WWRF, New York, + October 2003. + + [WLAN3G] Ahmavaara, K., Haverinen, H., and R. Pichna, "Interworking + Architecture between WLAN and 3G Systems", IEEE + Communications Magazine, November 2003. + + [INTELe2e] + Intel, "Wireless LAN (WLAN) End to End Guidelines for + Enterprises and Public Hotspot Service Providers", + November 2003. + + [Eronen03] + Eronen, P., "Network Selection Issues", presentation to + EAP WG at IETF 58, November 2003. + + [3GPPSA3WLANTS] + 3GPP, "3GPP Technical Specification Group Service and + System Aspects; 3G Security; Wireless Local Area Network + (WLAN) interworking security (Release 6); Stage 2", + 3GPP Technical Specification 33.234 v 6.6.0, October 2005. + + + + + + + + +Arkko, et al. Informational [Page 30] + +RFC 5113 Network Discovery and SP January 2008 + + + [3GPPCT1WLANTS] + 3GPP, "3GPP System to Wireless Local Area Network (WLAN) + interworking; User Equipment (UE) to network protocols; + Stage 3 (Release 6)", 3GPP Technical Specification 24.234 + v 6.4.0, October 2005. + + [IEEE.802.21] + IEEE, "Draft IEEE Standard for Local and Metropolitan Area + Networks: Media Independent Handover Services", + IEEE 802.21, D05.00, April 2007. + + [3GPPCT4WLANTS] + 3GPP, "3GPP system to Wireless Local Area Network (WLAN) + interworking; Stage 3 (Release 6)", 3GPP Technical + Specification 29.234 v 6.4.0, October 2005. + + [IEEE.8021X-2004] + IEEE, "Local and Metropolitan Area Networks: Port-Based + Network Access Control", IEEE Standard 802.1X, July 2004. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arkko, et al. Informational [Page 31] + +RFC 5113 Network Discovery and SP January 2008 + + +Appendix A. Existing Work + +A.1. IETF + + Several IETF WGs have dealt with aspects of the network selection + problem, including the AAA, EAP, PPP, RADIUS, ROAMOPS, and RADEXT + WGs. + + ROAMOPS WG developed the NAI, originally defined in [RFC2486], and + subsequently updated in [RFC4282]. Initial roaming implementations + are described in [RFC2194], and the use of proxies in roaming is + addressed in [RFC2607]. The SEAMOBY WG developed CARD [RFC4066], + which assists in discovery of suitable base stations. PKIX WG + produced [RFC3280], which addresses issues of certificate selection. + The AAA WG developed more sophisticated access routing, + authentication, and service discovery mechanisms within Diameter + [RFC3588]. + + Adrangi et al. [RFC4284] defines the use of the EAP-Request/Identity + to provide "realm hints" useful for identity selection. The NAI + syntax described in [RFC4282] enables the construction of source + routes. Together, these mechanisms enable the user to determine + whether it possesses an identity and corresponding credential + suitable for use with an EAP-capable NAS. This is particularly + useful in situations where the lower layer provides limited + information (such as in wired IEEE 802 networks where IEEE 802.1X + currently does not provide for advertisement of networks and their + capabilities). + + However, advertisement mechanisms based on the use of the EAP- + Request/Identity have scalability problems. As noted in [RFC3748] + Section 3.1, the minimum EAP Maximum Transmission Unit (MTU) is 1020 + octets, so that an EAP-Request/Identity is only guaranteed to be able + to include 1015 octets within the Type-Data field. Since RFC 1035 + [RFC1035] enables Fully Qualified Domain Names (FQDN) to be up to 255 + octets in length, this may not enable the announcement of many + realms. The use of network identifiers other than domain names is + also possible. + + As noted in [Eronen03], the use of the EAP-Request/Identity for realm + discovery has substantial negative impact on handoff latency, since + this may result in a station needing to initiate an EAP conversation + with each Access Point in order to receive an EAP-Request/Identity + describing which realms are supported. Since IEEE 802.11-2003 does + not support use of Class 1 data frames in State 1 (unauthenticated, + unassociated) within an Extended Service Set (ESS), this implies + either that the APs must support 802.1X pre-authentication (optional + in IEEE 802.11i-2004), or that the station must associate with each + + + +Arkko, et al. Informational [Page 32] + +RFC 5113 Network Discovery and SP January 2008 + + + AP prior to sending an EAPOL-Start to initiate EAP (here, EAPOL + refers to EAP over LAN). This will dramatically increase handoff + latency. + + Thus, rather than thinking of [RFC4284] as an effective network + discovery mechanism, it is perhaps better to consider the use of + "realm hints" as an error recovery technique to be used to inform the + EAP peer that AAA routing has failed, and perhaps to enable selection + of an alternate identity that can enable successful authentication. + Where "realm hints" are only provided in event of a problem, rather + than as a staple network discovery technique, it is probably best to + enable "realm hints" to be sent by core AAA proxies in the "default + free" zone. This way, it will not be necessary for NASes to send + "realm hints", which would require them to maintain a complete and + up-to-date realm routing table, something that cannot be easily + accomplished given the existing state of AAA routing technology. + + If realm routing tables are manually configured on the NAS, then + changes in the "default free" realm routing table will not + automatically be reflected in the realm list advertised by the NAS. + As a result, a realm advertised by the NAS might not, in fact, be + reachable, or the NAS might neglect to advertise one or more realms + that were reachable. This could result in multiple EAP-Identity + exchanges, with the initial set of "realm hints" supplied by the NAS + subsequently updated by "realm hints" provided by a core AAA proxy. + In general, originating "realm hints" on core AAA proxies appears to + be a more sound approach, since it provides for "fate sharing" -- + generation of "realm hints" by the same entity (the core AAA proxy) + that will eventually need to route the request based on the hints. + This approach is also preferred from a management perspective, since + only core AAA proxies would need to be updated; no updates would be + required to NAS devices. + +A.2. IEEE 802 + + There has been work in several IEEE 802 working groups relating to + network discovery: + + o [IEEE.802.11-2003] defines the Beacon and Probe Response + mechanisms within IEEE 802.11. Unfortunately, Beacons may be sent + only at a rate within the base rate set, which typically consists + of the lowest supported rate, or perhaps the next lowest rate. + Studies such as [MACScale] have identified MAC layer performance + problems, and [Velayos] has identified scaling issues from a + lowering of the Beacon interval. + + o [IEEE-11-03-0827] discusses the evolution of authentication models + in WLANs and the need for the network to migrate from existing + + + +Arkko, et al. Informational [Page 33] + +RFC 5113 Network Discovery and SP January 2008 + + + models to new ones, based on either EAP layer indications or + through the use of SSIDs to represent more than the local network. + It notes the potential need for management or structuring of the + SSID space. + + The paper also notes that virtual APs have scalability issues. It + does not compare these scalability issues to those of alternative + solutions, however. + + o [IEEE-11-03-154r1] discusses mechanisms currently used to provide + "virtual AP" capabilities within a single physical access point. + A "virtual AP" appears at the MAC and IP layers to be a distinct + physical AP. As noted in the paper, full compatibility with + existing 802.11 station implementations can only be maintained if + each "virtual AP" uses a distinct MAC address (BSSID) for use in + Beacons and Probe Responses. This paper does not discuss scaling + issues in detail, but recommends that only a limited number of + "virtual APs" be supported by a single physical access point. + + o IEEE 802.11u is working on realm discovery and network selection + [11-05-0822-03-000u-tgu-requirements] [IEEE.802.11u]. This + includes a mechanism for enabling a station to determine the + identities it can use to authenticate to an access network, prior + to associating with that network. As noted earlier, solving this + problem requires the AP to maintain an up-to-date, "default free" + realm routing table, which is not feasible without dynamic routing + support within the AAA infrastructure. Similarly, a priori + discovery of features supported within home realms (such as + enrollment) is also difficult to implement in a scalable way, + absent support for dynamic routing. Determination of network + capabilities (such as QoS support) is considerably simpler, since + these depend solely on the hardware and software contained within + the AP. However, 802.11u is working on Generic Advertisement + Service (GAS) mechanism, which can be used to carry 802.21 + Information Service (IS) messages and, in that way, allow a more + sophisticated way of delivering information from the network side. + + o IEEE 802.21 [IEEE.802.21] is developing standards to enable + handover between heterogeneous link layers, including both IEEE + 802 and non-IEEE 802 networks. To enable this, a general + mechanism for capability advertisement is being developed, which + could conceivably benefit aspects of the network selection + problem, such as realm discovery. For example, IEEE 802.21 is + developing Information Elements (IEs) that may assist with network + selection, including information relevant to both layer 2 and + layer 3. Query mechanisms (including both XML and TLV support) + are also under development. IEEE 802.21 also defines a Resource + Description Framework (RDF) schema to allow use of a query + + + +Arkko, et al. Informational [Page 34] + +RFC 5113 Network Discovery and SP January 2008 + + + language (i.e., SPARQL). The schema is a normative part of IEEE + 802.21 and also defined in [OHBA]. + +A.3. 3GPP + + The 3GPP stage 2 technical specification [3GPPSA2WLANTS] covers the + architecture of 3GPP Interworking WLAN (I-WLAN) with 2G and 3G + networks. This specification also discusses realm discovery and + network selection issues. The I-WLAN realm discovery procedure + borrows ideas from the cellular Public Land-based Mobile Network + (PLMN) selection principles, known as "PLMN Selection". + + In 3GPP PLMN selection [3GPP.23.122], the mobile node monitors + surrounding cells and prioritizes them based on signal strength + before selecting a new potential target cell. Each cell broadcasts + its PLMN. A mobile node may automatically select cells that belong + to its Home PLMN, Registered PLMN, or an allowed set of Visited + PLMNs. The PLMN lists are prioritized and stored in the Subscriber + Identity Module (SIM). In the case of manual PLMN selection, the + mobile node lists the PLMNs it learns about from surrounding cells + and enables the user to choose the desired PLMN. After the PLMN has + been selected, cell prioritization takes place in order to select the + appropriate target cell. + + [WLAN3G] discusses the new realm (PLMN) selection requirements + introduced by I-WLAN roaming, which support automatic PLMN selection, + not just manual selection. Multiple network levels may be present, + and the hotspot owner may have a contract with a provider who, in + turn, has a contract with a 3G network, which may have a roaming + agreement with other networks. + + The I-WLAN specification requires that network discovery be performed + as specified in the relevant WLAN link layer standards. In addition + to network discovery, it is necessary to select intermediary realms + to enable construction of source routes. In 3GPP, the intermediary + networks are PLMNs, and it is assumed that an access network may have + a roaming agreement with more than one PLMN. The PLMN may be a Home + PLMN (HPLMN) or a Visited PLMN (VPLMN), where roaming is supported. + GSM/UMTS roaming principles are employed for routing AAA requests + from the VPLMN to the Home Public Land-based Mobile Network (HPLMN) + using either RADIUS or Diameter. The procedure for selecting the + intermediary network has been specified in the stage 3 technical + specifications [3GPPCT1WLANTS] and [3GPPCT4WLANTS]. + + + + + + + + +Arkko, et al. Informational [Page 35] + +RFC 5113 Network Discovery and SP January 2008 + + + In order to select the PLMN, the following procedure is required: + + o The user may choose the desired HPLMN or VPLMN manually or let the + WLAN User Equipment (WLAN UE) choose the PLMN automatically, based + on user and operator defined preferences. + + o AAA messages are routed based on the decorated or undecorated NAI. + + o EAP is utilized as defined in [RFC3748] and [RFC3579]. + + o PLMN advertisement and selection is based on [RFC4284], which + defines only realm advertisement. The document refers to the + potential need for extensibility, though EAP MTU restrictions make + this difficult. + + The I-WLAN specification states that "realm hints" are only provided + when an unreachable realm is encountered. Where VPLMN control is + required, this is handled via NAI decoration. The station may + manually trigger PLMN advertisement by including an unknown realm + (known as the Alternative NAI) within the EAP-Response/Identity. A + realm guaranteed not to be reachable within 3GPP networks is utilized + for this purpose. + + The I-WLAN security requirements are described in the 3GPP stage 3 + technical specification [3GPPSA3WLANTS]. The security requirements + for PLMN selection are discussed in 3GPP contribution + [3GPP-SA3-030736], which concludes that both SSID and EAP-based + mechanisms have similar security weaknesses. As a result, it + recommends that PLMN advertisements should be considered as hints. + +A.4. Other + + [INTELe2e] discusses the need for realm selection where an access + network may have more than one roaming relationship path to a home + realm. It also describes solutions to the realm selection problem + based on EAP, SSID and Protected EAP (PEAP) based mechanisms. + + Eijk et al. [WWRF-ANS] discusses the realm and network selection + problem. The authors concentrate primarily on discovery of access + networks meeting a set of criteria, noting that information on the + realm capabilities and reachability inherently resides in home AAA + servers, and therefore it is not readily available in a central + location, and may not be easily obtained by NAS devices. + + + + + + + + +Arkko, et al. Informational [Page 36] + +RFC 5113 Network Discovery and SP January 2008 + + +Appendix B. Acknowledgements + + The authors of this document would like to especially acknowledge the + contributions of Farid Adrangi, Michael Richardson, Pasi Eronen, Mark + Watson, Mark Grayson, Johan Rune, and Tomas Goldbeck-Lowe. + + Input for the early versions of this document 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. + + Jouni Korhonen would like to thank the Academy of Finland for + providing funding to work on this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arkko, et al. Informational [Page 37] + +RFC 5113 Network Discovery and SP January 2008 + + +Authors' Addresses + + Jari Arkko + Ericsson + Jorvas 02420 + Finland + + EMail: jari.arkko@ericsson.com + + + Bernard Aboba + Microsoft + One Microsoft Way + Redmond, WA 98052 + USA + + EMail: bernarda@microsoft.com + + + Jouni Korhonen + TeliaSonera + Teollisuuskatu 13 + Sonera FIN-00051 + Finland + + EMail: jouni.korhonen@teliasonera.com + + + Farooq Bari + AT&T + 7277 164th Avenue N.E. + Redmond WA 98052 + USA + + EMail: farooq.bari@att.com + + + + + + + + + + + + + + + + +Arkko, et al. Informational [Page 38] + +RFC 5113 Network Discovery and SP January 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Arkko, et al. Informational [Page 39] + |