idnits 2.17.1 draft-ietf-eap-netsel-problem-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1721. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1739. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1745. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 1320 has weird spacing: '...tandard for I...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 17, 2007) is 6005 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 2486 (Obsoleted by RFC 4282) == Outdated reference: A later version (-07) exists of draft-ohba-802dot21-basic-schema-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Extensible Authentication Protocol J. Arkko 3 (EAP) Ericsson 4 Internet-Draft B. Aboba 5 Intended status: Informational Microsoft 6 Expires: May 20, 2008 J. Korhonen (Ed.) 7 TeliaSonera 8 F. Bari 9 AT&T/UBC 10 November 17, 2007 12 Network Discovery and Selection Problem 13 draft-ietf-eap-netsel-problem-09 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 20, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 When multiple access networks are available, users may have 47 difficulty in selecting which network to connect to, and how to 48 authenticate with that network. This document defines the network 49 discovery and selection problem, dividing it into multiple sub- 50 problems. Some constraints on potential solutions are outlined, and 51 the limitations of several solutions (including existing ones) are 52 discussed. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology used in this Document . . . . . . . . . . . . 4 58 2. Problem Definition . . . . . . . . . . . . . . . . . . . . . . 8 59 2.1. Discovery of Points of Attachment . . . . . . . . . . . . 8 60 2.2. Identity selection . . . . . . . . . . . . . . . . . . . . 10 61 2.3. AAA routing . . . . . . . . . . . . . . . . . . . . . . . 12 62 2.3.1. The Default Free Zone . . . . . . . . . . . . . . . . 14 63 2.3.2. Route Selection and Policy . . . . . . . . . . . . . . 15 64 2.3.3. Source Routing . . . . . . . . . . . . . . . . . . . . 16 65 2.4. Network Capabilities Discovery . . . . . . . . . . . . . . 18 66 3. Design Issues . . . . . . . . . . . . . . . . . . . . . . . . 20 67 3.1. AAA Routing . . . . . . . . . . . . . . . . . . . . . . . 20 68 3.2. Backward Compatibility . . . . . . . . . . . . . . . . . . 20 69 3.3. Efficiency Constraints . . . . . . . . . . . . . . . . . . 20 70 3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 21 71 3.5. Static Versus Dynamic Discovery . . . . . . . . . . . . . 22 72 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 23 73 3.7. Management . . . . . . . . . . . . . . . . . . . . . . . . 24 74 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 77 7. Informative References . . . . . . . . . . . . . . . . . . . . 30 78 Appendix A. Existing Work . . . . . . . . . . . . . . . . . . . . 35 79 A.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 80 A.2. IEEE 802 . . . . . . . . . . . . . . . . . . . . . . . . . 36 81 A.3. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 82 A.4. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 39 83 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 40 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 85 Intellectual Property and Copyright Statements . . . . . . . . . . 42 87 1. Introduction 89 Today, network access clients are typically preconfigured with a list 90 of access networks, and corresponding identities and credentials. 91 However, as network access mechanisms and operators have 92 proliferated, it has become increasingly likely that users will 93 encounter networks for which no preconfigured settings are available, 94 yet which offer desired services and the ability to successfully 95 authenticate with the user's home realm. It is also possible that 96 preconfigured settings will not be adequate in some situations. In 97 such a situation, users can have difficulty in determining which 98 network to connect to, and how to authenticate to that network. 100 The problem arises when any of the following conditions are true: 102 o Within a single network, more than one network attachment point is 103 available, and the attachment points differ in their roaming 104 arrangements, or access to services. While the link layer 105 capabilities of a point of attachment may be advertised, higher 106 layer capabilities such as roaming arrangements, end-to-end 107 quality of service or Internet access restrictions may not be. As 108 a result, a user may have difficulty determining what services are 109 available at each network attachment point, and which attachment 110 points it can successfully authenticate to. For example, it is 111 possible that a roaming agreement will only enable a user to 112 authenticate to the home realm from some points of attachment, but 113 not others. Similarly, it is possible that access to the Internet 114 may be restricted at some points of attachment, but not others or 115 that end-to-end quality of service may not be available in all 116 locations. In these situations, the network access client cannot 117 assume that all points of attachment within a network offer 118 identical capabilities. 120 o Multiple networks are available for which the user has no 121 corresponding pre-configuration. The user may not have pre- 122 configured an identity and associated credentials for use with a 123 network, yet it is possible that the user's home realm is 124 reachable from that network, enabling the user to successfully 125 authenticate. However, unless the roaming arrangements are 126 advertised, the network access client cannot determine apriori 127 whether successful authentication is likely. In this situation, 128 it is possible that the user will need to try multiple networks in 129 order to find one to which it can successfully authenticate, or it 130 is possible that the user will not be able to obtain access at 131 all, even though successful authentication is feasible. 133 o The user has multiple sets of credentials. Where no 134 preconfiguration exists, it is possible that the user will not be 135 able to determine which credentials to use with which attachment 136 point, or even whether any credentials it possesses will allow it 137 to authenticate successfully. An identity and associated 138 credentials can be usable for authentication with multiple 139 networks, and not all of these networks will be preconfigured. 140 For example, the user could have one set of credentials from a 141 public service provider and another set from an employer, and a 142 network might enable authentication with one or more of these 143 credentials. Yet, without preconfiguration, multiple unsuccessful 144 authentication attempts could be needed for each attachment point 145 in order to determine what credentials are usable, wasting 146 valuable time and resulting in user frustration. In order to 147 choose between multiple attachment points, it can be helpful to 148 provide additional information to enable the correct credentials 149 to be determined. 151 o There are multiple potential roaming paths between the visited 152 realm and the user's home realm, and service parameters or pricing 153 differs between them. In this situation, there could be multiple 154 ways for the user to successfully authenticate using the same 155 identity and credentials, yet the cost of each approach might 156 differ. In this case, the access network may not be able to 157 determine the roaming path that best matches the user's 158 preferences. This can lead to the user being charged more than 159 necessary, or not obtaining the desired services. For example, 160 the visited access realm could have both a direct relationship 161 with the home realm and an indirect relationship through a roaming 162 consortium. Current Authentication, Authorization and Accounting 163 (AAA) protocols may not be able to route the access request to the 164 home AAA sever purely based on the realm within the Network Access 165 Identifier (NAI) [RFC4282]. In addition, payload packets can be 166 routed or tunneled differently, based on the roaming relationship 167 path. This may have an impact on the available services or their 168 pricing. 170 In Section 2 the network discovery and selection problem is defined 171 and divided into subproblems. Some solution constraints are outlined 172 in Section 3. Section 4 provides conclusions and suggestions for 173 future work. Appendix A discusses existing solutions to portions of 174 the problem. 176 1.1. Terminology used in this Document 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 Authentication, Authorization and Accounting (AAA) AAA protocols 183 with EAP support include RADIUS [RFC3579] and Diameter [RFC4072]. 185 Access Point (AP) 187 An entity that has station functionality and provides access to 188 distribution services via the wireless medium (WM) for associated 189 stations. 191 Access Technology Selection 193 This refers to the selection between access technologies e.g., 194 802.11, UMTS, WiMAX. The selection will be dependent upon the 195 access technologies supported by the device and the availability 196 of networks supporting those technologies. 198 Bearer Selection 200 For some access technologies (e.g., UMTS), there can be a 201 possibility for delivery of a service (e.g., voice) by using 202 either a circuit switched or a packet switched bearer. Bearer 203 selection refers to selecting one of the bearer types for service 204 delivery. The decision can be based on support of the bearer type 205 by the device and the network as well as user subscription and 206 operator preferences. 208 Basic Service Set (BSS) 210 A set of stations controlled by a single coordination function. 212 Decorated NAI 214 A NAI specifying a source route. See RFC 4282 [RFC4282] Section 215 2.7 for more information. 217 Extended Service Set (ESS) 219 A set of one or more interconnected basic service sets (BSSs) with 220 the same Service Set Identifier (SSID) and integrated local area 221 networks (LANs), which appears as a single BSS to the logical link 222 control layer at any station associated with one of those BSSs. 223 This refers to a mechanism that a node uses to discover the 224 networks that are reachable from a given access network. 226 Network Access Identifier (NAI) 228 The Network Access Identifier (NAI) [RFC4282] is the user identity 229 submitted by the client during network access authentication. In 230 roaming, the purpose of the NAI is to identify the user as well as 231 to assist in the routing of the authentication request. Please 232 note that the NAI may not necessarily be the same as the user's 233 e-mail address or the user identity submitted in an application 234 layer authentication. 236 Network Access Server (NAS) 238 The device that peers connect to in order to obtain access to the 239 network. In PPTP terminology, this is referred to as the PPTP 240 Access Concentrator (PAC), and in L2TP terminology, it is referred 241 to as the L2TP Access Concentrator (LAC). In IEEE 802.11, it is 242 referred to as an Access Point (AP). 244 Network Discovery 246 The mechanism used to discover available networks. The discovery 247 mechanism may be passive or active, and depends on the access 248 technology. In passive network discovery, the node listens for 249 network announcements; in active network discovery the node 250 solicits network announcements. It is possible for an access 251 technology to utilize both passive and active network discovery 252 mechanisms. 254 Network Selection 256 Selection of an operator/ISP for network access. Network 257 selection occurs prior to network access authentication. 259 Realm 261 The realm portion of an NAI [RFC4282]. 263 Realm Selection 265 The selection of the realm (and corresponding NAI) used to access 266 the network. A realm can be reachable from more than one access 267 network type and selection of a realm may not enable network 268 capabilities. 270 Roaming Capability 272 Roaming capability can be loosely defined as the ability to use 273 any one of multiple Internet Service Providers (ISPs), while 274 maintaining a formal, customer-vendor relationship with only one. 275 Examples of cases where roaming capability might be required 276 include ISP "confederations" and ISP-provided corporate network 277 access support. 279 Station (STA) 281 A device that contains an IEEE 802.11 conformant medium access 282 control (MAC) and physical layer (PHY) interface to the wireless 283 medium (WM). 285 2. Problem Definition 287 The network discovery and selection problem can be broken down into 288 multiple sub-problems. These include: 290 o Discovery of points of attachment. This involves the discovery of 291 points of attachment in the vicinity, as well as their 292 capabilities. 294 o Identifier selection. This involves selection of the NAI (and 295 credentials) used to authenticate to the selected point of 296 attachment. 298 o AAA routing. This involves routing of the AAA conversation back 299 to the home AAA server, based on the realm of the selected NAI. 301 o Payload routing. This involves the routing of data packets, in 302 the situation where mechanisms more advanced than destination- 303 based routing are required. While this problem is interesting, it 304 is not discussed further in this document. 306 o Network capability discovery. This involves discovering the 307 capabilities of an access network, such as whether certain 308 services are reachable through the access network and the charging 309 policy. 311 Alternatively, the problem can be divided into discovery, decision, 312 and the selection components. The AAA routing problem, for instance, 313 involves all components: discovery (which mediating networks are 314 available), decision (choosing the "best" one), and selection 315 (selecting which mediating network to use) components. 317 2.1. Discovery of Points of Attachment 319 Traditionally, discovery of points of attachment has been handled by 320 out-of-band mechanisms or link or network layer advertisements. 322 RFC 2194 [RFC2194] describes the pre-provisioning of dialup roaming 323 clients, which typically included a list of potential phone numbers, 324 updated by the provider(s) with which the client had a contractual 325 relationship. RFC 3017 [RFC3017] describes the IETF Proposed 326 Standard for the Roaming Access eXtensible Markup Language (XML) 327 Document Type Definition (DTD). This covers not only the attributes 328 of the Points of Presence (PoP) and Internet Service Providers 329 (ISPs), but also hints on the appropriate NAI to be used with a 330 particular PoP. The XML DTD supports dial-in and X.25 access, but 331 has extensible address and media type fields. 333 As access networks and the points of attachment have proliferated, 334 out-of-band pre-configuration has become increasingly difficult. For 335 networks with many points of attachment, keeping a list of points of 336 attachment complete and up to date can be difficult. As a result, 337 wireless network access clients typically only attempt to pre- 338 configure information relating to access networks, rather than 339 individual points of attachment. 341 In IEEE 802.11 Wireless Local Area Networks (WLAN), the Beacon and 342 Probe Request/Response mechanism provides a way for Stations to 343 discover Access Points (AP) and the capabilities of those APs. The 344 IEEE 802.11 specification [IEEE.802.11-2003] provides support for 345 both passive (Beacon) and active (Probe Request/Response) discovery 346 mechanisms; [Fixingapsel] studied the effectiveness of these 347 mechanisms. 349 Among the Information Elements (IE) included within the Beacon and 350 Probe Response is the Service Set Identifier (SSID), a non-unique 351 identifier of the network to which an AP is attached. The Beacon/ 352 Probe facility therefore enables network discovery, as well as the 353 discovery of points of attachment and the capabilities of those 354 points of attachment. 356 The Global System for Mobile Communications (GSM) specifications also 357 provide for discovery of points of attachment, as does the Candidate 358 Access Router Discovery (CARD) [RFC4066] protocol developed by the 359 IETF SEAMOBY Working Group (WG). 361 Along with discovery of points of attachment, capability of access 362 networks are also typically discovered. These may include: 364 o Access network name (e.g., IEEE 802.11 SSID) 366 o Lower layer security mechanism (e.g., IEEE 802.11 WEP vs. WPA2) 368 o Quality of Service capabilities (e.g., IEEE 802.11e support) 370 o Bearer capabilities (e.g., circuit switched, packet switched or 371 both) 373 Even though pre-configuration of access networks scales better than 374 pre-configuration of points of attachment, where many access networks 375 can be used to authenticate to a home realm, providing complete and 376 up-to-date information on each access network can be challenging. 378 In such a situation, network access client configuration can be 379 minimized by providing information relating to each home realm, 380 rather than each access network. One way to enable this is for an 381 access network to support "virtual Access Points" (virtual APs), and 382 for each point of attachment to support virtual APs corresponding to 383 each reachable home realm. 385 While a single IEEE 802.11 network may only utilize a single SSID, it 386 may cover a wide geographical area, and as a result, may be 387 segmented, utilizing multiple prefixes. It is possible that a single 388 SSID may be advertised on multiple channels, and may support multiple 389 access mechanisms, including Universal Access Method (UAM) and IEEE 390 802.1X [IEEE.8021X-2004]. A single SSID also may support dynamic 391 VLAN access as described in [RFC3580], or may support authentication 392 to multiple home AAA servers supporting different realms. As a 393 result, users of a single point of attachment, connecting to the same 394 SSID may not have the same set of services available. 396 2.2. Identity selection 398 As networks proliferate, it becomes more and more likely that a user 399 may have multiple identities and credential sets, available for use 400 in different situations. For example, the user may have an account 401 with one or more Public WLAN providers; a corporate WLAN; and one or 402 more wireless Wide Area Network (WAN) providers. 404 Typically, the user will choose an identity and corresponding 405 credential set based on the selected network, perhaps with additional 406 assistance provided by the chosen authentication mechanism. For 407 example, if Extensible Authentication Protocol - Transport Layer 408 Security (EAP-TLS) is the authentication mechanism used with a 409 particular network, then the user will select the appropriate EAP-TLS 410 client certificate based in part on the list of trust anchors 411 provided by the EAP-TLS server. 413 However, in access networks where roaming is enabled, the mapping 414 between an access network and an identity/credential set may not be 415 one to one. For example, it is possible for multiple identities to 416 be usable on an access network or for a given identity to be usable 417 on a single access network, which may or may not be available. 419 Figure 1 illustrates a situation where a user identity may not be 420 usable on a potential access network. In this case access network 1 421 enables access to users within the realm "isp1.example.com" whereas 422 access network 3 enables access to users within the realm 423 "corp2.example.com"; access network 2 enables access to users within 424 both realms. 426 ? ? +---------+ +------------------+ 427 ? | Access | | | 428 O_/ _-->| Network |------>| isp1.example.com | 429 /| / | 1 | _->| | 430 | | +---------+ / +------------------+ 431 _/ \_ | / 432 | +---------+ / 433 User "subscriber@isp1. | | Access |/ 434 example.com" -- ? -->| Network | 435 also known | | 2 |\ 436 "employee123@corp2. | +---------+ \ 437 example.com" | \ 438 | +---------+ \_ +-------------------+ 439 \_ | Access | ->| | 440 -->| Network |------>| corp2.example.com | 441 | 3 | | | 442 +---------+ +-------------------+ 444 Figure 1: Two credentials, three possible access networks 446 In this situation, a user only possessing an identity within the 447 "corp2.example.com" realm can only successfully authenticate to 448 access networks 2 or 3; a user possessing an identity within the 449 "isp1.example.com" realm can only successfully authenticate to access 450 networks 1 or 2; a user possessing identities within both realms can 451 connect to any of the access networks. The question is: how does the 452 user figure out which access networks it can successfully 453 authenticate to, preferably prior to choosing a point of attachment? 455 Traditionally, hints useful in identity selection have been provided 456 out-of-band. For example, the XML DTD described in [RFC3017] enables 457 a client to select between potential points of attachment as well as 458 to select the NAI and credentials to use in authenticating with it. 460 Where all points of attachment within an access network enable 461 authentication utilizing a set of realms, selection of an access 462 network provides knowledge of the identities that a client can use to 463 successfully authenticate. For example, in an access network, the 464 set of supported realms corresponding to network name can be pre- 465 configured. 467 In some cases it may not be possible to determine the available 468 access networks prior to authentication. For example, 469 [IEEE.8021X-2004] does not support network discovery on IEEE 802 470 wired networks, so that the peer cannot determine which access 471 network it has connected to prior to the initiation of the EAP 472 exchange. 474 It is also possible for hints to be embedded within credentials. In 475 [RFC4334], usage hints are provided within certificates used for 476 wireless authentication. This involves extending the client's 477 certificate to include the SSIDs with which the certificate can be 478 used. 480 However, there may be situations in which an access network may not 481 accept a static set of realms at every point of attachment. For 482 example, as part of a roaming agreement only points of attachment 483 within a given region or country may be made available. In these 484 situations, mechanisms such as hints embedded within credentials or 485 pre-configuration of access network to realm mappings may not be 486 sufficient. Instead, it is necessary for the client to discover 487 usable identities dynamically. 489 This is the problem that RFC 4284 [RFC4284] attempts to solve, using 490 the EAP-Request/Identity to communicate a list of supported realms. 491 However, the problems inherent in this approach are many, as 492 discussed in Appendix A.1. 494 Note that identity selection also implies selection of different 495 credentials, and potentially, selection of different EAP 496 authentication methods. In some situations this may imply serious 497 security vulnerabilities. These are discussed in depth in Section 498 Section 6. 500 2.3. AAA routing 502 Once the identity has been selected, the AAA infrastructure needs to 503 route the access request back to the home AAA server. Typically the 504 routing is based on the Network Access Identifier (NAI) defined in 505 [RFC4282]. 507 Where the NAI does not encode a source route, the routing of requests 508 is determined by the AAA infrastructure. As described in [RFC2194], 509 most roaming implementations are relatively simple, relying on a 510 static realm routing table which determines the next hop based on the 511 NAI realm included in the User-Name attribute within the Access- 512 Request. Within RADIUS, the IP address of the home AAA server is 513 typically determined based on static mappings of realms to IP 514 addresses maintained within RADIUS proxies. 516 Diameter [RFC3588] supports mechanisms for intra- and inter-domain 517 service discovery, including support for DNS as well as service 518 discovery protocols such as SLPv2 [RFC2608]. As a result, it may not 519 be necessary to configure static tables mapping realms to the IP 520 addresses of Diameter agents. However, while this simplifies 521 maintenance of the AAA routing infrastructure, it does not 522 necessarily simplify roaming relationship path selection. 524 As noted in RFC 2607 [RFC2607], RADIUS proxies are deployed not only 525 for routing purposes, but also to mask a number of inadequacies in 526 the RADIUS protocol design, such as the lack of standardized 527 retransmission behavior and the need for shared secret provisioning 528 between each AAA client and server. 530 Diameter [RFC3588] supports certificate-based authentication (using 531 either TLS or IPSec) as well as Redirect functionality, enabling a 532 Diameter client to obtain a referral to the home server from a 533 Diameter redirect server, so that the client can contact the home 534 server directly. In situations in which a trust model can be 535 established, these Diameter capabilities can enable a reduction in 536 the length of the roaming relationship path. 538 However, in practice there are a number of pitfalls. In order for 539 certificate-based authentication to enable communication between a 540 Network Access Server (NAS) or local proxy and the home AAA server, 541 trust anchors need to be configured, and certificates need to be 542 selected. The AAA server certificate needs to chain to a trust 543 anchor configured on the AAA client, and the AAA client certificate 544 needs to chain to a trust anchor configured on the AAA server. Where 545 multiple potential roaming relationship paths are available, this 546 will reflect itself in multiple certificate choices, transforming the 547 path selection problem into a certificate selection problem. 548 Depending on the functionality supported within the certificate 549 selection implementation, this may not make the problem easier to 550 solve. For example, in order to provide the desired control over the 551 roaming path, it may be necessary to implement custom certificate 552 selection logic, which may be difficult to introduce within a 553 certificate handling implementation designed for general purpose 554 usage. 556 As noted in [RFC4284], it is also possible to utilize an NAI for the 557 purposes of source routing. In this case, the client provides 558 guidance to the AAA infrastructure as to how it would like the access 559 request to be routed. An NAI including source routing information is 560 said to be "decorated"; the decoration format is defined in 561 [RFC4282]. 563 When decoration is utilized, the EAP peer provides the decorated NAI 564 within the EAP-Response/Identity, and as described in [RFC3579], the 565 NAS copies the decorated NAI included in the EAP-Response/Identity 566 into the User-Name attribute included within the access request. As 567 the access request transits the roaming relationship path, AAA 568 proxies determine the next hop based on the realm included within the 569 User-Name attribute, in the process successively removing decoration 570 from the NAI included in the User-Name attribute. In contrast, the 571 decorated NAI included within the EAP-Response/Identity encapsulated 572 in the access request remains untouched. As a result, when the 573 access request arrives at the AAA home server, the decorated NAI 574 included in the EAP-Response/Identity may differ from the NAI 575 included in the User-Name attribute (which may have some or all of 576 the decoration removed). For the purpose of identity verification, 577 the EAP server utilizes the NAI in the User-Name attribute, rather 578 than the NAI in the EAP-Response/Identity. 580 Over the long term, it is expected that the need for NAI "decoration" 581 and source routing will disappear. This is somewhat analogous to the 582 evolution of email delivery. Prior to the widespread proliferation 583 of the Internet, it was necessary to gateway between SMTP-based mail 584 systems and alternative delivery technologies, such as UUCP and 585 FidoNet. Prior to the implementation of email gateways utilizing MX 586 RR routing, email address-based source-routing was used extensively. 587 However, over time the need for email source-routing disappeared. 589 2.3.1. The Default Free Zone 591 AAA clients on the edge of the network, such as NAS devices and local 592 AAA proxies, typically maintain a default realm route, providing a 593 default next hop for realms not otherwise taken into account within 594 the realm routing table. This permits devices with limited resources 595 to maintain a small realm routing table. Deeper within the AAA 596 infrastructure, AAA proxies may be maintained with a "default free" 597 realm table, listing next hops for all known realms, but not 598 providing a default realm route. 600 While dynamic realm routing protocols are not in use within AAA 601 infrastructure today, even if such protocols were to be introduced, 602 it is likely that they would be deployed solely within the core AAA 603 infrastructure, but not on NAS devices, which are typically resource 604 constrained. 606 Since NAS devices do not maintain a full realm routing table, they do 607 not have knowledge of all the realms reachable from the local 608 network. The situation is analogous to that of Internet hosts or 609 edge routers which do not participate in the BGP mesh. In order for 610 an Internet host to determine whether it can reach a destination on 611 the Internet, it is necessary to send a packet to the destination. 613 Similarly, when a user provides an NAI to the NAS, the NAS does not 614 know a priori whether the realm encoded in the NAI is reachable or 615 not; it simply forwards the access request to the next hop on the 616 roaming relationship path. Eventually the access request reaches the 617 "default free" zone, where a core AAA proxy determines whether the 618 realm is reachable or not. As described in [RFC4284], where EAP 619 authentication is in use, the core AAA proxy can send an Access- 620 Reject, or it can send an Access-Challenge encapsulating an EAP- 621 Request/Identity containing realm hints based on the content of the 622 "default free" realm routing table. 624 There are a number of intrinsic problems with this approach. Where 625 the "default free" routing table is large, it may not fit within a 626 single EAP packet, and the core AAA proxy may not have a mechanism 627 for selecting the most promising entries to include. Even where the 628 "default free" realm routing table would fit within a single EAP- 629 Request/Identity packet, the core AAA router may not choose to 630 include all entries, since the list of realm routes could be 631 considered confidential information not appropriate for disclosure to 632 hosts seeking network access. Therefore it cannot be assumed that 633 the list of "realm hints" included within the EAP-Request/Identity is 634 complete. Given this, a NAS or local AAA proxy snooping the EAP- 635 Request/Identity cannot rely on it to provide a complete list of 636 reachable realms. The "realm hint" mechanism described in [RFC4284] 637 is not a dynamic routing protocol. 639 2.3.2. Route Selection and Policy 641 Along with lack of a dynamic AAA routing protocol, today's AAA 642 infrastructure lacks mechanisms for route selection and policy. As a 643 result, multiple routes may exist to a destination realm, without a 644 mechanism for the selection of a preferred route. 646 In Figure 2, Roaming Groups 1 and 2 both include a route to the realm 647 "a.example.com". However, these realm routes are not disseminated to 648 the NAS along with associated metrics, and as a result there is no 649 mechanism for implementation of dynamic routing policies (such as 650 selection of realm routes by shortest path, or preference for routes 651 originating at a given proxy). 653 +---------+ 654 | |----> "a.example.com" 655 | Roaming | 656 +---------+ | Group 1 | 657 | |----->| Proxy |----> "b.example.com" 658 user "joe@ | Access | +---------+ 659 a.example.com"--->| Provider| 660 | NAS | +---------+ 661 | |----->| |----> "a.example.com" 662 +---------+ | Roaming | 663 | Group 2 | 664 | Proxy |----> "c.example.com" 665 +---------+ 667 Figure 2: Multiple routes to a destination realm 669 In the example in Figure 2, access through Roaming Group 1 may be 670 less expensive than access through Roaming Group 2, and as a result 671 it would be desirable to prefer Roaming Group 1 as a next hop for an 672 NAI with a realm of "a.example.com". However, the only way to obtain 673 this result would be to manually configure the NAS realm routing 674 table with the following entries: 676 Realm Next Hop 677 ----- -------- 678 b.example.com Roaming Group 1 679 c.example.com Roaming Group 2 680 Default Roaming Group 1 682 While manual configuration may be practical in situations where the 683 realm routing table is small and entries are static, where the list 684 of supported realms change frequently, or the preferences change 685 dynamically, manual configuration will not be manageable. 687 2.3.3. Source Routing 689 Due to the limitations of current AAA routing mechanisms, there are 690 situations in which NAI-based source routing is used to influence the 691 roaming relationship path. However, since the AAA proxies on the 692 roaming relationship path are constrained by existing relationships, 693 NAI-based source routing is not source routing in the classic sense; 694 it merely suggests preferences which the AAA proxy can choose not to 695 accommodate. 697 Where realm routes are set up as the result of pre-configuration and 698 dynamic route establishment is not supported, if a realm route does 699 not exist, then NAI-based source routing cannot establish it. Even 700 where dynamic route establishment is possible, such as where the AAA 701 client and server support certificate-based authentication, and AAA 702 servers are discoverable (such as via the mechanisms described in 703 [RFC3588]), a AAA proxy may choose not to establish a realm route by 704 initiating the discovery process based on a suggestion in an NAI- 705 based source route. 707 Where the realm route does exist, or the AAA proxy is capable of 708 establishing it dynamically, the AAA proxy may choose not to 709 authorize the client to use it. 711 While in principle source routing can provide users with better 712 control over AAA routing decisions, there are a number of practical 713 problems to be overcome. In order to enable the client to construct 714 optimal source routes, it is necessary for it to be provided with a 715 complete and up to date realm routing table. However, if a solution 716 to this problem were readily available, then it could be applied to 717 the AAA routing infrastructure, enabling the selection of routes 718 without the need for user intervention. 720 As noted in [Eronen04], only a limited number of parameters can be 721 updated dynamically. For example, quality of service or pricing 722 information typically will be pre-provisioned or made available on 723 the web rather than being updated on a continuous basis. Where realm 724 names are communicated dynamically, the "default free" realm list is 725 unlikely to be provided in full since this table could be quite 726 large. Given the constraints on the availability of information, the 727 construction of source routes typically needs to occur in the face of 728 incomplete knowledge. 730 In addition, there are few mechanisms available to audit whether the 731 requested source route is honored by the AAA infrastructure. For 732 example, an access network could advertise a realm route to 733 costsless.example.com, while instead routing the access-request 734 through costsmore.example.com. While the decorated NAI would be made 735 available to the home AAA server in the EAP-Response/Identity, the 736 home AAA server might have a difficult time verifying that the source 737 route requested in the decorated NAI was actually honored by the AAA 738 infrastructure. Similarly, it could be difficult to determine 739 whether Quality of Service (QoS) or other routing requests were 740 actually provided as requested. To some extent, this problem may be 741 addressed as part of the business arrangements between roaming 742 partners, which may provide minimum service level guarantees. 744 Given the potential issues with source routing, conventional AAA 745 routing mechanisms are to be preferred wherever possible. Where an 746 error is encountered, such as an attempt to authenticate to an 747 unreachable realm, "realm hints" can be provided as described 748 [RFC4284]. However, this approach has severe scalability 749 limitations, as outlined in Appendix A.1. 751 2.4. Network Capabilities Discovery 753 Network capability discovery focuses on discovery of the services 754 offered by networks, not just the capabilities of individual points 755 of attachment. By acquiring additional information on access network 756 characteristics, it is possible for users to make a more informed 757 access decision. These characteristics may include: 759 o Roaming relationships between the access network provider and 760 other network providers and associated costs. Where the network 761 access client is not preconfigured with an identity and 762 credentials corresponding to a local access network, it will need 763 to be able to determine whether one or more home realms are 764 reachable from an access network so that successful authentication 765 can be possible. 767 o EAP authentication methods. While the EAP authentication methods 768 supported by a home realm can only be determined by contacting the 769 home AAA server, it is possible that the local realm will also 770 support one or more EAP methods. For example, a user may be able 771 to utilize EAP-SIM to authenticate to the access network directly, 772 rather than having to authenticate to the home network. 774 o End-to-end quality of service capability. While local quality of 775 service capabilities are typically advertised by the access 776 network (e.g., support for WMM), the availability of end-to-end 777 QoS services may not be advertised. 779 o Service parameters, such as the existence of middleboxes or 780 firewalls. If the network access client is not made aware of the 781 Internet access that it will receive on connecting to a point of 782 attachment, it is possible that the user may not be able to access 783 the desired services. 785 Reference [IEEE.11-04-0624] classifies the possible steps at which 786 IEEE 802.11 networks can acquire this information: 788 o Pre-association 790 o Post-association (or pre-authentication) 792 o Post-authentication 794 In the interest of minimizing connectivity delays, all of the 795 information required for network selection (including both access 796 network capabilities and global characteristics) needs to be provided 797 prior to authentication. 799 By the time authentication occurs, the node has typically selected 800 the access network, the NAI to be used to authenticate, as well as 801 the point of attachment. Should it learn information during the 802 authentication process that would cause it to revise one or more of 803 those decisions, the node will need to select a new network, point of 804 attachment, and/or identity, and then go through the authentication 805 process all over again. Such a process is likely to be both time 806 consuming and unreliable. 808 3. Design Issues 810 The following factors should be taken into consideration while 811 evaluating solutions to the problem of network selection and 812 discovery: 814 3.1. AAA Routing 816 Solutions to the AAA routing issues discussed in Section 2.3 need to 817 apply to a wide range of AAA messages, and should not restrict the 818 introduction of new AAA or access network functionality. For 819 example, AAA routing mechanisms should work for access requests and 820 responses as well as accounting requests and responses and server- 821 initiated messages. Solutions should not restrict the development of 822 new AAA attributes, access types, or performance optimizations (such 823 as fast handoff support). 825 3.2. Backward Compatibility 827 Solutions need to maintain backward compatibility. In particular: 829 o Selection-aware clients need to interoperate with legacy NAS 830 devices and AAA servers. 832 o Selection-aware AAA infrastructure needs to interoperate with 833 legacy clients and NAS devices. 835 For example, selection-aware clients should not transmit packets 836 larger than legacy NAS devices or AAA servers can handle. Where 837 protocol extensions are required, changes should be required to as 838 few infrastructure elements as possible. For example, extensions 839 that require upgrades to existing NAS devices will be more difficult 840 to deploy than proposals that are incrementally deployable based on 841 phased upgrades of clients or AAA servers. 843 3.3. Efficiency Constraints 845 Solutions should be efficient as measured by channel utilization, 846 bandwidth consumption, handoff delay, and energy utilization. 847 Mechanisms that depend on multicast frames need to be designed with 848 care since multicast frames are often sent at the lowest supported 849 rate and therefore consume considerable channel time as well as 850 energy on the part of listening nodes. Depending on the deployment, 851 it is possible for bandwidth to be constrained both on the link, as 852 well as in the backend AAA infrastructure. As a result, chatty 853 mechanisms such as keepalives or periodic probe packets are to be 854 avoided. Given the volume handled by AAA servers, solutions should 855 also be conscious of adding to the load, particularly in cases where 856 this could enable denial of service attacks. For example, it would 857 be a bad idea for a NAS to attempt to obtain an updated realm routing 858 table by periodically sending probe EAP-Response/Identity packets to 859 the AAA infrastructure in order to obtain "realm hints" as described 860 in [RFC4284]. Not only would this add significant load to the AAA 861 infrastructure (particularly in cases where the AAA server was 862 already overloaded, thereby dropping packets resulting in 863 retransmission by the NAS), but it would also not provide the NAS 864 with a complete realm routing table, for reasons described in 865 Section 2.3. 867 Battery consumption is a significant constraint for handheld devices. 868 Therefore mechanisms which require significant increases in packets 869 transmitted, or the fraction of time during which the host needs to 870 listen (such as proposals that require continuous scanning), are to 871 be discouraged. In addition, the solution should not significantly 872 impact the time required to complete network attachment. 874 3.4. Scalability 876 Given limitations on frame sizes and channel utilization, it is 877 important that solutions scale less than linearly in terms of the 878 number of networks and realms supported. For example, solutions such 879 as [RFC4284] increase the size of advertisements in proportion to the 880 number of entries in the realm routing table. This approach does not 881 scale to support a large number of networks and realms. 883 Similarly, approaches that utilize separate Beacons for each "virtual 884 AP" introduce additional Beacons in proportion to the number of 885 networks being advertised. While such an approach may minimize the 886 pre-configuration required for network access clients, the 887 proliferation of "virtual APs" can result in high utilization of the 888 wireless medium. For example, the 802.11 Beacon is sent only at a 889 rate within the basic rate set, which typically consists of the 890 lowest supported rates, or perhaps only the lowest supported rate. 891 As a result, "virtual AP" mechanisms that require a separate Beacon 892 for each "virtual AP" do not scale well." 894 For example, with a Beacon interval of 100 Time Units (TUs) or 102.4 895 ms (9.8 Beacons/second), twenty 802.11b "virtual APs" each announcing 896 their own Beacon of 170 octets would result in a channel utilization 897 of 37.9 percent. The calculation can be verified as follows: 899 1. A single 170 octet Beacon sent at 1 Mbps will utilize the channel 900 for 1360us (1360 bits @1Mbps) 902 2. Adding 144us for the Physical Layer Convergence Procedure (PLCP) 903 long preamble (144 bits @1Mbps), 48us for the PLCP header (48 bits 904 @1 Mbps), 10us for the Short Interframe Space (SIFS), 50us for the 905 Distributed Interframe Space (DIFS), and 320us for the average 906 minimum Contention Window without backoff (CWmin/2 * aSlotTime = 907 32/2 * 20 us) implies that a single Beacon will utilize an 802.11b 908 channel for 1932us; 910 3. Multiply the channel time per Beacon by 196 Beacons/second, and we 911 obtain a channel utilization of 378672us/second = 37.9 percent. 913 In addition, since Beacon/Probe Response frames are sent by each AP 914 over the wireless medium, stations can only discover APs within 915 range, which implies substantial coverage overlap for roaming to 916 occur without interruption. Another issue with the Beacon and Probe 917 Request/Response mechanism is that it is either insecure or its 918 security can be assured only as part of authenticating to the network 919 (e.g., verifying the advertised capabilities within the 4-way 920 handshake). 922 A number of enhancements have been proposed to the Beacon/Probe 923 Response mechanism in order to improve scalability and performance in 924 roaming scenarios. These include allowing APs to announce 925 capabilities of neighbor APs as well as their own [IEEE.802.11k]. 926 More scalable mechanisms for support of "virtual APs" within IEEE 927 802.11 have also been proposed [IEEE.802.11v]; generally these 928 proposals collapse multiple "virtual AP" advertisements into a single 929 advertisement. 931 Higher layer mechanisms can also be used to improve scalability, 932 since by running over IP they can utilize facilities such as 933 fragmentation which may not be available at the link layer. For 934 example, in IEEE 802.11, Beacon frames cannot use fragmentation 935 because they are multicast frames. 937 3.5. Static Versus Dynamic Discovery 939 "Phone-book" based approaches such as [RFC3017] can provide 940 information for automatic selection decisions. While this approach 941 has been applied to wireless access, it typically can only be used 942 successfully within a single operator or limited roaming partner 943 deployment. For example, were a "Phone-Book" approach to attempt to 944 incorporate information from a large number of roaming partners, it 945 could become quite difficult to keep the information simultaneously 946 comprehensive and up to date. As noted in [Priest04] and 947 [I-D.groeting-eap-netselection-results], a large fraction of current 948 WLAN access points operate on the default SSID, which may make it 949 difficult to distinguish roaming partner networks by SSID. In any 950 case, in wireless networks dynamic discovery is a practical 951 requirement since a node needs to know which APs are within range 952 before it can connect. 954 3.6. Security 956 Network discovery and selection mechanisms may introduce new security 957 vulnerabilities. As noted in Section 2.3.1, network operators may 958 consider the AAA routing table to be confidential information, and 959 therefore may not wish to provide it to unauthenticated peers via the 960 mechanism described in RFC 4284. While the peer could provide a list 961 of the realms it supports, with the authenticator choosing one, this 962 approach raises privacy concerns. Since identity selection occurs 963 prior to authentication, the peer's supported realms would be sent in 964 cleartext, enabling an attacker to determine the realms for which a 965 potential victim has credentials. This risk can be mitigated by 966 restricting peer disclosure. For example, a peer may only disclose 967 additional realms in situations where an initially selected identity 968 has proved unusable. 970 Since network selection occurs prior to authentication, it is 971 typically not possible to secure mechanisms for network discovery or 972 identity selection, although it may be possible to provide for secure 973 confirmation after authentication is complete. As an example, some 974 parameters discovered during network discovery may be confirmable via 975 EAP Channel Bindings; others may be confirmed in a subsequent Secure 976 Association Protocol handshake. 978 However, there are situations in which advertised parameters may not 979 be confirmable. This could lead to "bidding down" vulnerabilities. 980 [RFC3748] Section 7.8 states: 982 Within or associated with each authenticator, it is not 983 anticipated that a particular named peer will support a choice of 984 methods. This would make the peer vulnerable to attacks that 985 negotiate the least secure method from among a set. Instead, for 986 each named peer, there SHOULD be an indication of exactly one 987 method used to authenticate that peer name. If a peer needs to 988 make use of different authentication methods under different 989 circumstances, then distinct identities SHOULD be employed, each 990 of which identifies exactly one authentication method. 992 In practice, where the authenticator operates in "pass-through" mode, 993 the EAP method negotiation will occur between the EAP peer and 994 server, and therefore the peer will need to associate a single EAP 995 method with a given EAP server. Where multiple EAP servers and 996 corresponding identities may be reachable from the same selected 997 network, the EAP peer may have difficulty determining which identity 998 (and corresponding EAP method) should be used. Unlike network 999 selection, which may be securely confirmed within a Secure 1000 Association Protocol handshake, identity selection hints provided 1001 within the EAP-Request/Identity are not secured. 1003 As a result, where the identity selection mechanism described in RFC 1004 4284 is used, the "hints" provided could be used by an attacker to 1005 convince the victim to select an identity corresponding to an EAP 1006 method offering lesser security (e.g., EAP MD5-Challenge). One way 1007 to mitigate this risk is for the peer to only utilize EAP methods 1008 satisfying the [RFC4017] security requirements, and for the peer to 1009 select the identity corresponding to the strongest authentication 1010 method where a choice is available. 1012 3.7. Management 1014 From an operational point of view a network device in control of 1015 network advertisement, and providing "realm hints" for guiding the 1016 network discovery and selection should at least offer a management 1017 interface capable of providing status information for operators. 1018 Status information such as counters of each selected network and used 1019 realm, and when RFC 4284 is used the count of delivered "realm hints" 1020 might interest operators. Especially the information related to 1021 realms that fall into the "default free zone" or the AAA fails to 1022 route are of interest. 1024 Larger deployments would benefit from a management interface that 1025 allow full remote configuration capabilites, for example, of "realm 1026 hints" in case of RFC 4284 conforming network devices. While changes 1027 to "realm hints" and realm routing information are not expected to be 1028 frequent, centralized remote management tend to lower the frequency 1029 of misconfigured devices. 1031 4. Conclusions 1033 This document describes the network selection and discovery problem. 1034 In the opinion of the authors, the major findings are as follows: 1036 o There is a need for additional work on access network discovery, 1037 identifier selection, AAA routing, and payload routing. 1039 o Credential selection and AAA routing are aspects of the same 1040 problem, namely identity selection. 1042 o When considering selection among a large number of potential 1043 access networks and points of attachment, the issues described in 1044 the document become much harder to solve in an automated way, 1045 particularly if there are constraints on handoff latency. 1047 o The proliferation of network discovery technologies within IEEE 1048 802, IETF, and 3GPP has the potential to become a significant 1049 problem going forward. Without a unified approach, multiple non- 1050 interoperable solutions may be deployed. 1052 o New link layer designs should include efficient distribution of 1053 network and realm information as a design requirement. 1055 o It may not be possible to solve all aspects of the problem for 1056 legacy NAS devices on existing link layers. Therefore a phased 1057 approach may be more realistic. For example, a partial solution 1058 could be made available for existing link layers, with a more 1059 complete solution requiring support for link layer extensions. 1061 With respect to specific mechanisms for access network discovery and 1062 selection: 1064 o Studies such as [MACScale] and [Velayos], as well as the 1065 calculations described in Section 2.1 demonstrate that the IEEE 1066 802.11 Beacon/Probe Response mechanism has substantial scaling 1067 issues in situations where a new Beacon is used for each "virtual 1068 AP". As a result a single channel is in practice limited to less 1069 than twenty Beacon announcements with IEEE 802.11b. 1071 The situation is improved substantially with successors such as 1072 IEEE 802.11a which enable additional channels, thus potentially 1073 increasing the number of potential virtual APs. 1075 However, even with these enhancements it is not feasible to 1076 advertise more than 50 different networks, and probably less in 1077 most circumstances. 1079 As a result, there appears to be a need to enhance the scalability 1080 of IEEE 802.11 network advertisements. 1082 o Work is underway in IEEE 802.1, IEEE 802.21 and IEEE 802.11u 1083 [IEEE.802.11u] to provide enhanced discovery functionality. 1084 Similarly, IEEE 802.1af [IEEE.802.1af] has discussed addition of 1085 network discovery functionality to IEEE 802.1X [IEEE.8021X-2004]. 1086 However, neither IEEE 802.1AB [IEEE.802.1ab] nor IEEE 802.1af is 1087 likely to support fragmentation of network advertisement frames, 1088 so that the amount of data that can be transported will be 1089 limited. 1091 o While IEEE 802.11k [IEEE.802.11k] provides support for the 1092 Neighbor Report, this only provides for gathering of information 1093 on neighboring 802.11 APs, not points of attachment supporting 1094 other link layers. Solution to this problem would appear to 1095 require coordination across IEEE 802 as well as between standards 1096 bodies. 1098 o Given that EAP does not support fragmentation of EAP-Request/ 1099 Identity packets, the volume of "realm hints" that can be fit with 1100 these packets is limited. In addition, within IEEE 802.11, EAP 1101 packets can only be exchanged within State 3 (associated and 1102 authenticated). As a result, use of EAP for realm discovery may 1103 result in significant delays. The extension of the realm 1104 advertisement mechanism defined in [RFC4284] to handle 1105 advertisement of realm capability information (such as QoS 1106 provisioning) is not recommended due to semantic and packet size 1107 limitations [I-D.groeting-eap-netselection-results]. As a result, 1108 we believe that extending the mechanism described in [RFC4284] for 1109 discovery of realm capabilities is inappropriate. Instead, we 1110 believe it is more appropriate for this functionality to be 1111 handled within the link layer, so that the information can be 1112 available early in the handoff process. 1114 o Where link layer approaches are not available, higher layer 1115 approaches can be considered. A limitation of higher layer 1116 solutions is that they can only optimize the movement of already 1117 connected hosts, but cannot address scenarios where network 1118 discovery is required for successful attachment. 1120 Higher layer alternatives worth considering include the SEAMOBY 1121 CARD protocol [RFC4066], which enables advertisement of network 1122 device capabilities over IP, and Device Discovery Protocol (DDP) 1123 [I-D.marques-ddp], which provides functionality equivalent to IEEE 1124 802.1AB using ASN.1 encoded advertisements sent to a link-local 1125 scope multicast address. 1127 5. IANA Considerations 1129 This document has no actions for IANA. 1131 6. Security Considerations 1133 All aspects of the network discovery and selection problem are 1134 security related. The security issues and requirements have been 1135 discussed in the previous sections. 1137 The security requirements for network discovery depend on the type of 1138 information being discovered. Some of the parameters may have a 1139 security impact, such as the claimed name of the network the user 1140 tries to attach to. Unfortunately, current EAP methods do not always 1141 make the verification of such parameters possible. EAP methods such 1142 as PEAP [I-D.josefsson-pppext-eap-tls-eap] and EAP-IKEv2 1143 [I-D.tschofenig-eap-ikev2] may make this possible, however. There is 1144 even an attempt to provide a backwards compatible extensions to older 1145 methods [I-D.arkko-eap-service-identity-auth]. 1147 The security requirements for network selection depend on whether the 1148 selection is considered a mandate or a hint. In general, treating 1149 network advertisements as a hint is a more secure approach, since 1150 reduces access client vulnerability to forged network advertisements. 1151 For example, realm hints may be ignored by an EAP peer if they are 1152 incompatible with the security policy corresponding to a selected 1153 access network. 1155 Similarly, network access clients may refuse to connect to a point of 1156 attachment if the advertised security capabilities do not match those 1157 that have been pre-configured. For example, if an IEEE 802.11 access 1158 client has been pre-configured to require WPA2 enterprise support 1159 within an access network, it may refuse to connect to access points 1160 advertising support for WEP. 1162 Where the use of methods that do not satisfy the security 1163 requirements of [RFC4017] is allowed, it may be possible for an 1164 attacker to trick a peer into using an insecure EAP method, leading 1165 to the compromise of long-term credentials. This can occur either 1166 where a network is pre-configured to allow use of an insecure EAP 1167 method, or where connection without pre-configuration is permitted 1168 using such methods. 1170 For example, an attacker can spoof a network advertisement, possibly 1171 downgrading the advertised security capabilities. The rogue access 1172 point would then attempt to negotiate an insecure EAP method. Such 1173 an attack can be prevented if the peer refuses to connect to access 1174 points not meeting its security requirements, which would include 1175 requiring use of EAP methods satisfying the [RFC4017] requirements. 1177 Support for secure discovery could potentially protect against 1178 spoofing of network advertisements, enabling verifiable information 1179 to guide connection decisions. However, development of these 1180 mechanisms requires solving several difficult engineering and 1181 deployment problems. 1183 Since discovery is a pre-requisite for authentication, it is not 1184 possible to protect initial discovery using dynamic keys derived in 1185 the authentication process. On the other hand, integrity protection 1186 of network advertisements utilizing symmetric keys or digital 1187 signatures would require pre-configuration. 1189 7. Informative References 1191 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1192 Requirement Levels", BCP 14, RFC 2119, March 1997. 1194 [RFC1035] Mockapetris, P., "Domain names - implementation and 1195 specification", STD 13, RFC 1035, November 1987. 1197 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1198 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1200 [RFC3017] Riegel, M. and G. Zorn, "XML DTD for Roaming Access Phone 1201 Book", RFC 3017, December 2000. 1203 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1204 Levkowetz, "Extensible Authentication Protocol (EAP)", 1205 RFC 3748, June 2004. 1207 [RFC4334] Housley, R. and T. Moore, "Certificate Extensions and 1208 Attributes Supporting Authentication in Point-to-Point 1209 Protocol (PPP) and Wireless Local Area Networks (WLAN)", 1210 RFC 4334, February 2006. 1212 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1213 Network Access Identifier", RFC 4282, December 2005. 1215 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1216 X.509 Public Key Infrastructure Certificate and 1217 Certificate Revocation List (CRL) Profile", RFC 3280, 1218 April 2002. 1220 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1221 Authentication Protocol (EAP) Application", RFC 4072, 1222 August 2005. 1224 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1225 Dial In User Service) Support For Extensible 1226 Authentication Protocol (EAP)", RFC 3579, September 2003. 1228 [RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, 1229 "Review of Roaming Implementations", RFC 2194, 1230 September 1997. 1232 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1233 Implementation in Roaming", RFC 2607, June 1999. 1235 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 1236 "Service Location Protocol, Version 2", RFC 2608, 1237 June 1999. 1239 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 1240 "IEEE 802.1X Remote Authentication Dial In User Service 1241 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 1243 [RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity 1244 Selection Hints for the Extensible Authentication Protocol 1245 (EAP)", RFC 4284, January 2006. 1247 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1248 Authentication Protocol (EAP) Method Requirements for 1249 Wireless LANs", RFC 4017, March 2005. 1251 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 1252 RFC 2486, January 1999. 1254 [RFC4066] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. 1255 Shim, "Candidate Access Router Discovery (CARD)", 1256 RFC 4066, July 2005. 1258 [I-D.tschofenig-eap-ikev2] 1259 Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., 1260 and F. Bersani, "EAP-IKEv2 Method", 1261 draft-tschofenig-eap-ikev2-15 (work in progress), 1262 September 2007. 1264 [I-D.arkko-eap-service-identity-auth] 1265 Arkko, J. and P. Eronen, "Authenticated Service 1266 Information for the Extensible Authentication Protocol 1267 (EAP)", draft-arkko-eap-service-identity-auth-04 (work in 1268 progress), October 2005. 1270 [I-D.groeting-eap-netselection-results] 1271 Tschofenig, H., "Network Selection Implementation 1272 Results", draft-groeting-eap-netselection-results-00 (work 1273 in progress), July 2004. 1275 [I-D.josefsson-pppext-eap-tls-eap] 1276 Josefsson, S., Palekar, A., Simon, D., and G. Zorn, 1277 "Protected EAP Protocol (PEAP) Version 2", 1278 draft-josefsson-pppext-eap-tls-eap-10 (work in progress), 1279 October 2004. 1281 [I-D.marques-ddp] 1282 Enns, R., Marques, P., and D. Morrell, "Device Discovery 1283 Protocol (DDP)", draft-marques-ddp-00 (work in progress), 1284 May 2003. 1286 [I-D.ohba-802dot21-basic-schema] 1287 Ohba, Y., "IEEE 802.21 Basic Schema", 1288 draft-ohba-802dot21-basic-schema-01 (work in progress), 1289 October 2007. 1291 [IEEE.802.11-2003] 1292 IEEE, "Wireless LAN Medium Access Control (MAC) and 1293 Physical Layer (PHY) Specifications", IEEE Standard 1294 802.11, 2003. 1296 [Fixingapsel] 1297 Judd, G. and P. Steenkiste, "Fixing 802.11 Access Point 1298 Selection", Sigcomm Poster Session 2002. 1300 [IEEE.802.11k] 1301 IEEE, "Draft Ammendment to Standard for Telecommunications 1302 and Information Exchange Between Systems - LAN/MAN 1303 Specific Requirements - Part 11: Wireless LAN Medium 1304 Access Control (MAC) and Physical Layer (PHY) 1305 Specifications: Radio Resource Management", IEEE 802.11k, 1306 D7.0, January 2007. 1308 [IEEE.802.1ab] 1309 IEEE, "Draft Standard for Local and Metropolitan Area 1310 Networks - Station and Media Access Control Connectivity 1311 Discovery", IEEE 802.1AB, D1.0, April 2007. 1313 [IEEE.802.1af] 1314 IEEE, "Draft Standard for Local and Metropolitan Area 1315 Networks - Port-Based Network Access Control - Amendment 1316 1: Authenticated Key Agreement for Media Access Control 1317 (MAC) Security", IEEE 802.1af, D1.2, January 2007. 1319 [IEEE.802.11v] 1320 IEEE, "Draft Amemdment to Standard for Information 1321 Technology - Telecommunications and Information Exchange 1322 Between Systems - LAN/MAN Specific Requirements - Part 11: 1323 Wireless Medium Access Control (MAC) and physical layer 1324 (PHY) specifications: Wireless Network Management", 1325 IEEE 802.11v, D0.09, March 2007. 1327 [Eronen04] 1328 Eronen, P. and J. Arkko, "Role of authorization in 1329 wireless network security", Extended abstract presented in 1330 the DIMACS workshop, November 2004. 1332 [IEEE.11-04-0624] 1333 Berg, S., "Information to Support Network Selection", IEEE 1334 Contribution 11-04-0624 2004. 1336 [Priest04] 1337 Priest, J., "The State of Wireless London", July 2004. 1339 [MACScale] 1340 Heusse, M., "Performance Anomaly of 802.11b", LSR-IMAG 1341 Laboratory, Grenoble, France, IEEE Infocom 2003. 1343 [Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 1344 802.11b MAC Layer Handover Time", Laboratory for 1345 Communication Networks, KTH, Royal Institute of Tech 1346 nology, Stockholm, Sweden, TRITA-IMIT-LCN R 03:02, 1347 April 2003. 1349 [IEEE.802.11u] 1350 IEEE, "Draft Amendment to STANDARD FOR Information 1351 Technology - LAN/MAN Specific Requirements - Part 11: 1352 Interworking with External Networks; Draft Amendment to 1353 Standard; IEEE P802.11u/D0.04", IEEE 802.11u, D0.04, 1354 April 2007. 1356 [IEEE-11-03-154r1] 1357 Aboba, B., "Virtual Access Points", IEEE Contribution 11- 1358 03-154r1, May 2003. 1360 [IEEE-11-03-0827] 1361 Hepworth, E., "Co-existence of Different Authentication 1362 Models", IEEE Contribution 11-03-0827 2003. 1364 [11-05-0822-03-000u-tgu-requirements] 1365 Moreton, M., "TGu Requirements", IEEE Contribution 11-05- 1366 0822-03-000u-tgu-requirements, August 2005. 1368 [3GPPSA2WLANTS] 1369 3GPP, "3GPP System to Wireless Local Area Network (WLAN) 1370 interworking; System De scription; Release 6; Stage 2", 1371 3GPP Technical Specification 23.234, September 2005. 1373 [3GPP-SA3-030736] 1374 Ericsson, "Security of EAP and SSID based network 1375 advertisements", 3GPP Contribution S3-030736, 1376 November 2003. 1378 [3GPP.23.122] 1379 3GPP, "Non-Access-Stratum (NAS) functions related to 1380 Mobile Station (MS) in idle mode", 3GPP TS 23.122 6.5.0, 1381 October 2005. 1383 [WWRF-ANS] 1384 Eijk, R., Brok, J., Bemmel, J., and B. Busropan, "Access 1385 Network Selection in a 4G Environment and the Role of 1386 Terminal and Service Platform", 10th WWRF, New York, 1387 October 2003. 1389 [WLAN3G] Ahmavaara, K., Haverinen, H., and R. Pichna, "Interworking 1390 Architecture between WLAN and 3G Systems", IEEE 1391 Communications Magazine, November 2003. 1393 [INTELe2e] 1394 Intel, "Wireless LAN (WLAN) End to End Guidelines for 1395 Enterprises and Public Hotspot Service Providers", 1396 November 2003. 1398 [Eronen03] 1399 Eronen, P., "Network Selection Issues", presentation to 1400 EAP WG at IETF 58, November 2003. 1402 [3GPPSA3WLANTS] 1403 3GPP, "3GPP Technical Specification Group Service and 1404 System Aspects; 3G Security; Wireless Local Area Network 1405 (WLAN) interworking security (Release 6); Stage 2", 1406 3GPP Technical Specification 33.234 v 6.6.0, October 2005. 1408 [3GPPCT1WLANTS] 1409 3GPP, "3GPP System to Wireless Local Area Network (WLAN) 1410 interworking; User Equipment (UE) to network protocols; 1411 Stage 3 (Release 6)", 3GPP Technical Specification 24.234 1412 v 6.4.0, October 2005. 1414 [IEEE.802.21] 1415 IEEE, "Draft IEEE Standard for Local and Metropolitan Area 1416 Networks: Media Independent Handover Services", 1417 IEEE 802.21, D05.00, April 2007. 1419 [3GPPCT4WLANTS] 1420 3GPP, "3GPP system to Wireless Local Area Network (WLAN) 1421 interworking; Stage 3 (Release 6)", 3GPP Technical 1422 Specification 29.234 v 6.4.0, October 2005. 1424 [IEEE.8021X-2004] 1425 IEEE, "Local and Metropolitan Area Networks: Port-Based 1426 Network Access Control", IEEE Standard 802.1X, July 2004. 1428 Appendix A. Existing Work 1430 A.1. IETF 1432 Several IETF WGs have dealt with aspects of the network selection 1433 problem, including the AAA, EAP, PPP, RADIUS, ROAMOPS, and RADEXT 1434 WGs. 1436 ROAMOPS WG developed the NAI, originally defined in [RFC2486], and 1437 subsequently updated in [RFC4282]. Initial roaming implementations 1438 are described in [RFC2194], and the use of proxies in roaming is 1439 addressed in [RFC2607]. The SEAMOBY WG developed CARD [RFC4066], 1440 which assists in discovery of suitable base stations. PKIX WG 1441 produced [RFC3280], which addresses issues of certificate selection. 1442 The AAA WG developed more sophisticated access routing, 1443 authentication and service discovery mechanisms within Diameter 1444 [RFC3588]. 1446 Adrangi et al. [RFC4284] defines the use of the EAP-Request/Identity 1447 to provide "realm hints" useful for identity selection. The NAI 1448 syntax described in [RFC4282] enables the construction of source 1449 routes. Together, these mechanisms enable the user to determine 1450 whether it possesses an identity and corresponding credential 1451 suitable for use with an EAP-capable NAS. This is particularly 1452 useful in situations where the lower layer provides limited 1453 information (such as in wired IEEE 802 networks where IEEE 802.1X 1454 currently does not provide for advertisement of networks and their 1455 capabilities). 1457 However, advertisement mechanisms based on the use of the EAP- 1458 Request/Identity have scalability problems. As noted in [RFC3748] 1459 Section 3.1, the minimum EAP Maximum Transmission Unit (MTU) is 1020 1460 octets, so that an EAP-Request/Identity is only guaranteed to be able 1461 to include 1015 octets within the Type-Data field. Since RFC 1035 1462 [RFC1035] enables Fully Qualified Domain Names (FQDN) to be up to 255 1463 octets in length, this may not enable the announcement of many 1464 realms. The use of network identifiers other than domain names is 1465 also possible. 1467 As noted in [Eronen03], the use of the EAP-Request/Identity for realm 1468 discovery has substantial negative impact on handoff latency, since 1469 this may result in a station needing to initiate an EAP conversation 1470 with each Access Point in order to receive an EAP-Request/Identity 1471 describing which realms are supported. Since IEEE 802.11-2003 does 1472 not support use of Class 1 data frames in State 1 (unauthenticated, 1473 unassociated) within an Extended Service Set (ESS), this implies 1474 either that the APs must support 802.1X pre-authentication (optional 1475 in IEEE 802.11i-2004) or that the station must associate with each AP 1476 prior to sending an EAPOL-Start to initiate EAP. This will 1477 dramatically increase handoff latency. 1479 Thus, rather than thinking of [RFC4284] as a effective network 1480 discovery mechanism, it is perhaps better to consider the use of 1481 "realm hints" as an error recovery technique, to be used to inform 1482 the EAP peer that AAA routing has failed, and perhaps to enable 1483 selection of an alternate identity which can enable successful 1484 authentication. Where "realm hints" are only provided in event of a 1485 problem, rather than as a staple network discovery technique, it is 1486 probably best to enable "realm hints" to be sent by core AAA proxies 1487 in the "default free" zone. This way, it will not be necessary for 1488 NASes to send realm hints, which would require them to maintain a 1489 complete and up to date realm routing table, something which cannot 1490 be easily accomplished given the existing state of AAA routing 1491 technology. 1493 If realm routing tables are manually configured on the NAS, then 1494 changes in the "default free" realm routing table will not 1495 automatically be reflected in the realm list advertised by the NAS. 1496 As a result, a realm advertised by the NAS might not in fact be 1497 reachable, or the NAS might neglect to advertise one or more realms 1498 that were reachable. This could result in multiple EAP-Identity 1499 exchanges, with the initial set of realm hints supplied by the NAS 1500 subsequently updated by realm hints provided by a core AAA proxy. In 1501 general, originating realm hints on core AAA proxies appears to be a 1502 more sound approach, since it provides for "fate sharing" - 1503 generation of realm hints by the same entity (the core AAA proxy) 1504 that will eventually need to route the request based on the hints. 1505 This approach is also preferred from a management perspective, since 1506 only core AAA proxies would need to be updated; no updates would be 1507 required to NAS devices. 1509 A.2. IEEE 802 1511 There has been work in several IEEE 802 working groups relating to 1512 network discovery: 1514 o [IEEE.802.11-2003] defines the Beacon and Probe Response 1515 mechanisms within IEEE 802.11. Unfortunately, Beacons may be sent 1516 only at a rate within the base rate set, which typically consists 1517 of the lowest supported rate, or perhaps the next lowest rate. 1518 Studies such as [MACScale] have identified MAC layer performance 1519 problems, and [Velayos] has identified scaling issues from a 1520 lowering of the Beacon interval. 1522 o [IEEE-11-03-0827] discusses the evolution of authentication models 1523 in WLANs, and the need for the network to migrate from existing 1524 models to new ones, based on either EAP layer indications or 1525 through the use of SSIDs to represent more than the local network. 1526 It notes the potential need for management or structuring of the 1527 SSID space. 1529 The paper also notes that virtual APs have scalability issues. It 1530 does not compare these scalability issues to those of alternative 1531 solutions, however. 1533 o [IEEE-11-03-154r1] discusses mechanisms currently used to provide 1534 "Virtual AP" capabilities within a single physical access point. 1535 A "Virtual AP" appears at the MAC and IP layers to be distinct 1536 physical AP. As noted in the paper, full compatibility with 1537 existing 802.11 station implementations can only be maintained if 1538 each virtual AP uses a distinct MAC address (BSSID) for use in 1539 Beacons and Probe Responses. This draft does not discuss scaling 1540 issues in detail, but recommends that only a limited number of 1541 virtual APs be supported by a single physical access point. 1543 o IEEE 802.11u is working on realm discovery and network selection 1544 [11-05-0822-03-000u-tgu-requirements] [IEEE.802.11u]. This 1545 includes a mechanism for enabling a station to determine the 1546 identities it can use to authenticate to an access network, prior 1547 to associating with that network. As noted earlier, solving this 1548 problem requires the AP to maintain an up to date "default free" 1549 realm routing table, which is not feasible without dynamic routing 1550 support within the AAA infrastructure. Similarly, apriori 1551 discovery of features supported within home realms (such as 1552 enrollment) is also difficult to implement in a scalable way, 1553 absent support for dynamic routing. Determination of network 1554 capabilities (such as QoS support) is considerably simpler, since 1555 these depend solely on the hardware and software contained within 1556 the AP. However, 802.11u is working on Generic Advertisement 1557 Service (GAS) mechanism, which can be used to carry 802.21 1558 Information Service (IS) messages and in that way allow more 1559 sophisticated way of delivering information from the network side. 1561 o IEEE 802.21 [IEEE.802.21] is developing standards to enable 1562 handover between heterogeneous link layers, including both IEEE 1563 802 and non-IEEE 802 networks. To enable this, a general 1564 mechanism for capability advertisement is being developed, which 1565 could conceivably benefit aspects of the network selection 1566 problem, such as realm discovery. For example, IEEE 802.21 is 1567 developing Information Elements (IEs) which may assist with 1568 network selection, including information relevant to both layer 2 1569 and layer 3. Query mechanisms (including both XML and TLV 1570 support) are also under development. IEEE 802.21 also defines a 1571 Resource Description Framework (RDF) schema to allow use of a 1572 query language (i.e. SPARQL). The schema is a normative part of 1573 IEEE 802.21 and also defined in [I-D.ohba-802dot21-basic-schema]. 1575 A.3. 3GPP 1577 The 3GPP stage 2 technical specification [3GPPSA2WLANTS] covers the 1578 architecture of 3GPP Interworking WLAN (I-WLAN) with 2G and 3G 1579 networks. This specification also discusses realm discovery and 1580 network selection issues. The I-WLAN realm discovery procedure 1581 borrows ideas from the cellular Public Land-based Mobile Network 1582 (PLMN) selection principles, known as "PLMN Selection". 1584 In 3GPP PLMN selection [3GPP.23.122], the mobile node monitors 1585 surrounding cells and prioritizes them based on signal strength 1586 before selecting a new potential target cell. Each cell broadcasts 1587 its PLMN. A mobile node may automatically select cells that belong 1588 to its Home PLMN, Registered PLMN or an allowed set of Visited PLMNs. 1589 The PLMN lists are prioritized and stored in the Subscriber Identity 1590 Module (SIM). In the case of manual PLMN selection, the mobile node 1591 lists the PLMNs it learns from surrounding cells and enables the user 1592 to choose the desired PLMN. After the PLMN has been selected, cell 1593 prioritization takes place, in order to select the appropriate target 1594 cell. 1596 [WLAN3G] discuss the new realm (PLMN) selection requirements 1597 introduced by I-WLAN roaming, which supports automatic PLMN 1598 selection, not just manual selection. Multiple network levels may be 1599 present, and the hotspot owner may have a contract with a provider 1600 who in turn has a contract with a 3G network, which may have a 1601 roaming agreement with other networks. 1603 The I-WLAN specification requires that network discovery be performed 1604 as specified in the relevant WLAN link layer standards. In addition 1605 to network discovery, it is necessary to select intermediary realms 1606 to enable construction of source routes. In 3GPP, the intermediary 1607 networks are PLMNs, and it is assumed that an access network may have 1608 a roaming agreement with more than one PLMN. The PLMN may be a Home 1609 PLMN (HPLMN) or a Visited PLMN (VPLMN), where roaming is supported. 1610 GSM/UMTS roaming principles are employed for routing AAA requests 1611 from the VPLMN to the Home Public Land-based Mobile Network (HPLMN) 1612 using either RADIUS or Diameter. The procedure for selecting the 1613 intermediary network has been specified in the stage 3 technical 1614 specifications [3GPPCT1WLANTS] and [3GPPCT4WLANTS]. 1616 In order to select the PLMN, the following procedure is required: 1618 o The user may choose the desired HPLMN or VPLMN manually or let the 1619 WLAN User Equipment (WLAN UE) choose the PLMN automatically, based 1620 on user and operator defined preferences. 1622 o AAA messages are routed based on the decorated or undecorated NAI. 1624 o EAP is utilized as defined in [RFC3748] and [RFC3579]. 1626 o PLMN advertisement and selection is based on [RFC4284], which 1627 defines only realm advertisement. The document refers to the 1628 potential need for extensibility, though EAP MTU restrictions make 1629 this difficult. 1631 The I-WLAN specification states that realm hints are only provided 1632 when an unreachable realm is encountered. Where VPLMN control is 1633 required, this is handled via NAI decoration. The station may 1634 manually trigger PLMN advertisement by including an unknown realm 1635 (known as the Alternative NAI) within the EAP-Response/Identity. A 1636 realm guaranteed not to be reachable within 3GPP networks is utilized 1637 for this purpose. 1639 The I-WAN security requirements are described in the 3GPP stage 3 1640 technical specification [3GPPSA3WLANTS]. The security requirements 1641 for PLMN selection are discussed in 3GPP contribution 1642 [3GPP-SA3-030736], which concludes that both SSID and EAP-based 1643 mechanisms have similar security weaknesses. As a result, it 1644 recommends that PLMN advertisements be considered hints. 1646 A.4. Other 1648 [INTELe2e] discusses the need for realm selection where an access 1649 network may have more than one roaming relationship path to a home 1650 realm. It also describes solutions to the realm selection problem 1651 based on EAP, SSID and Protected EAP (PEAP) based mechanisms. 1653 Eijk et al. [WWRF-ANS] discusses the realm and network selection 1654 problem. The authors concentrate primarily on discovery of access 1655 networks meeting a set of criteria, noting that information on the 1656 realm capabilities and reachability inherently resides in home AAA 1657 servers, and therefore it is not readily available in a central 1658 location, and may not be easily obtained by NAS devices. 1660 Appendix B. Acknowledgements 1662 The authors of this document would like to especially acknowledge the 1663 contributions of Farid Adrangi, Michael Richardson, Pasi Eronen, Mark 1664 Watson, Mark Grayson, Johan Rune, and Tomas Goldbeck-Lowe. 1666 Input for the early versions of this draft has been gathered from 1667 many sources, including the above persons as well as 3GPP and IEEE 1668 developments. We would also like to thank Alper Yegin, Victor Lortz, 1669 Stephen Hayes, and David Johnston for comments. 1671 Jouni Korhonen would like to thank Academy of Finland for providing 1672 funding to work on this document. 1674 Authors' Addresses 1676 Jari Arkko 1677 Ericsson 1678 Jorvas 02420 1679 Finland 1681 Email: jari.arkko@ericsson.com 1683 Bernard Aboba 1684 Microsoft 1685 One Microsoft Way 1686 Redmond, WA 98052 1687 USA 1689 Email: bernarda@microsoft.com 1691 Jouni Korhonen 1692 TeliaSonera 1693 Teollisuuskatu 13 1694 Sonera FIN-00051 1695 Finland 1697 Email: jouni.korhonen@teliasonera.com 1699 Farooq Bari 1700 AT&T/UBC 1701 7277 164th Avenue N.E. 1702 Redmond WA 98052 1703 USA 1705 Email: farooq.bari@att.com 1707 Full Copyright Statement 1709 Copyright (C) The IETF Trust (2007). 1711 This document is subject to the rights, licenses and restrictions 1712 contained in BCP 78, and except as set forth therein, the authors 1713 retain all their rights. 1715 This document and the information contained herein are provided on an 1716 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1717 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1718 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1719 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1720 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1721 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1723 Intellectual Property 1725 The IETF takes no position regarding the validity or scope of any 1726 Intellectual Property Rights or other rights that might be claimed to 1727 pertain to the implementation or use of the technology described in 1728 this document or the extent to which any license under such rights 1729 might or might not be available; nor does it represent that it has 1730 made any independent effort to identify any such rights. Information 1731 on the procedures with respect to rights in RFC documents can be 1732 found in BCP 78 and BCP 79. 1734 Copies of IPR disclosures made to the IETF Secretariat and any 1735 assurances of licenses to be made available, or the result of an 1736 attempt made to obtain a general license or permission for the use of 1737 such proprietary rights by implementers or users of this 1738 specification can be obtained from the IETF on-line IPR repository at 1739 http://www.ietf.org/ipr. 1741 The IETF invites any interested party to bring to its attention any 1742 copyrights, patents or patent applications, or other proprietary 1743 rights that may cover technology that may be required to implement 1744 this standard. Please address the information to the IETF at 1745 ietf-ipr@ietf.org. 1747 Acknowledgment 1749 Funding for the RFC Editor function is provided by the IETF 1750 Administrative Support Activity (IASA).