idnits 2.17.1 draft-ietf-eap-netsel-problem-04.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 on line 1251. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1228. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1235. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1241. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of lines with control characters in the document. == There is 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 275 has weird spacing: '... realms are a...' == Line 713 has weird spacing: '...lection solut...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (May 25, 2006) is 6545 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 1019, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1025, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1029, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1036, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1086, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 1097, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 1103, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 1109, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2194 (ref. '3') ** Obsolete normative reference: RFC 2486 (ref. '4') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2607 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 2868 (ref. '7') ** Obsolete normative reference: RFC 3588 (ref. '9') (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 3770 (ref. '11') (Obsoleted by RFC 4334) ** Obsolete normative reference: RFC 4282 (ref. '12') (Obsoleted by RFC 7542) ** Downref: Normative reference to an Informational RFC: RFC 4284 (ref. '13') ** Obsolete normative reference: RFC 4306 (ref. '14') (Obsoleted by RFC 5996) == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-11 == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-07 == Outdated reference: A later version (-15) exists of draft-tschofenig-eap-ikev2-10 Summary: 14 errors (**), 0 flaws (~~), 17 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Extensible Authentication Protocol J. Arkko 3 Internet-Draft Ericsson 4 Expires: November 26, 2006 B. Aboba 5 Microsoft 6 J. Korhonen 7 TeliaSonera 8 F. Bari 9 Cingular Wireless 10 May 25, 2006 12 Network Discovery and Selection Problem 13 draft-ietf-eap-netsel-problem-04 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 November 26, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 The so called realm discovery and selection problem affects network 47 access, particularly in the presence of multiple available wireless 48 accesses and roaming. This problem has been the subject of 49 discussions in various standards bodies. This document summarizes 50 the discussion held about this problem in the Extensible 51 Authentication Protocol (EAP) working group at the IETF. The problem 52 is defined and divided into subproblems, and some constraints for 53 possible solutions are outlined. The document also provides a 54 discussion of the limitations of certain classes of solution, 55 including some that have been previously defined. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Problem Definition . . . . . . . . . . . . . . . . . . . . . . 5 62 2.1 Discovery of the Point of Attachment to the Network . . . 5 63 2.2 Identity selection . . . . . . . . . . . . . . . . . . . . 7 64 2.3 AAA routing . . . . . . . . . . . . . . . . . . . . . . . 8 65 2.3.1 The Incomplete Routing Table Problem . . . . . . . . . 9 66 2.3.2 The User and Identity Selection Problem . . . . . . . 10 67 2.4 Discovery, Decision, and Selection . . . . . . . . . . . . 12 68 2.5 Type of Information . . . . . . . . . . . . . . . . . . . 13 69 3. Existing Work . . . . . . . . . . . . . . . . . . . . . . . . 15 70 3.1 IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 3.2 IEEE . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 3.3 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 3.4 Other . . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 4. Design Issues . . . . . . . . . . . . . . . . . . . . . . . . 20 75 4.1 AAA issues . . . . . . . . . . . . . . . . . . . . . . . . 20 76 4.2 Backward Compatibility . . . . . . . . . . . . . . . . . . 20 77 4.3 Efficiency Constraints . . . . . . . . . . . . . . . . . . 20 78 4.4 Network discovery and selection decision making . . . . . 20 79 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 22 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 82 7.1 Normative References . . . . . . . . . . . . . . . . . . . 26 83 7.2 Informative References . . . . . . . . . . . . . . . . . . 27 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 85 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 86 Intellectual Property and Copyright Statements . . . . . . . . 32 88 1. Introduction 90 The realm discovery and selection problem affects network access and 91 wireless access networks in particular. This problem spans multiple 92 protocol layers and has been the subject of discussions in IETF, 93 3GPP, and IEEE. This document summarizes the discussion held about 94 this problem in the Extensible Authentication Protocol working group 95 at IETF. 97 The realm discovery and selection problem becomes relevant when any 98 of the following conditions are true: 100 o There is more than one available network attachment point, and the 101 different attachment points may have different characteristics or 102 belong to different operators. In the case of virtual operators, 103 access network infrastructure including e.g. the access points can 104 be shared by multiple operators. 106 o The user has multiple sets of credentials. For instance, the user 107 could have one set of credentials from a public service provider 108 and set from the user's employer. 110 o There is more than one way to provide roaming between the visited 111 realm used for access and user's home realm, and service 112 parameters or pricing differs between them. For instance, the 113 visited access realm could have both a direct relationship with 114 the home realm and an indirect relationship through a roaming 115 consortium. In some scenarios, current AAA protocols may not be 116 able to route the requests to the home realm unaided, just based 117 on the domain in the given Network Access Identifier (NAI) [12]. 118 In addition, payload packets can get routed or tunneled 119 differently, based on which particular roaming relationship 120 variation is used. This may have an impact on the available 121 services or their pricing. 123 In Section 2 the realm discovery and selection problem is defined and 124 divided into subproblems, and some constraints for possible solutions 125 are outlined in Section 4. Section 3 discusses existing mechanisms 126 which help solve at least parts of the problem. Section 5 gives some 127 suggestions on how to proceed for the rest. 129 1.1 Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [2]. 135 Realm Selection 137 This refers to selection of the operator/ISP in order to access 138 the network. The process of realm selection can occur either at 139 the beginning of a new session or during a handoff in case the 140 user is mobile. The selection is dependent upon for example the 141 authentication credentials for the user / device and the roaming 142 agreements. The realm Selection can in turn also depend upon 143 Access Technology Selection and/or Bearer Selection. 145 Realm Discovery 147 This refers to a mechanisms that a node uses to discover available 148 realms prior the realm selection takes place. The discovery 149 process may be passive or active from a node point of view. 150 Typically the realm discovery mechanism varies depending on the 151 access technology. It is also possible that there are multiple 152 discovery mechanisms within one access technology depending on the 153 network deployment. 155 Access Technology Selection 157 This refers to the selection between access technologies e.g. 158 802.11, UMTS, WiMAX. The selection will be dependent upon for 159 example the support for an access technology by the device and 160 availability of such access technology based networks. 162 Bearer Selection 164 For some access technologies (e.g. UMTS), there can be a 165 possibility for delivery of a service (e.g. voice) by using either 166 a circuit switched or a packet switched bearer. The Bearer 167 selection refers to selecting one of the bearer type for service 168 delivery. The decision can be based on support of the bearer type 169 by the device and the network as well as user subscription and 170 operator preferences. 172 2. Problem Definition 174 There are a set of somewhat orthogonal problems being discussed under 175 the rubric of "realm discovery and selection". 177 o The problem of "discovery of points of attachment". This is the 178 problem of discovering points of attachment available in the 179 vicinity, and the capabilities associated with these points of 180 attachment. 182 o The problem of "Identifier selection". This is the problem of 183 selecting which identity (and credentials) to use to authenticate 184 in a given point of attachment to the network. 186 o The problem of "AAA routing" which involves figuring out how to 187 route the authentication conversation originating from the 188 selected identity back to the home realm. 190 o The problem of "Payload routing" which involves figuring how the 191 payload packets are routed, where more advanced mechanisms than 192 destination-based routing is needed. However, while being an 193 interesting problem, this document does not attempt to do any 194 analysis or suggestions on it. 196 o The problem of "realm capability discovery". This is the problem 197 of discovering the capabilities of a particular destination realm. 198 For example, it may be important to know whether a given realm 199 supports enrollment, what the charges are, etc. 201 Alternatively, the problem can be divided to the discovery, decision, 202 and the selection components. The AAA routing problem, for instance, 203 involves all components: discovery (which mediating networks are 204 available?), decision (choose the "best" one), and selection (client 205 tells the network which mediating network it has decided to choose) 206 components. 208 2.1 Discovery of the Point of Attachment to the Network 210 "The discovery of points of attachment" problem has been extensively 211 studied, see for instance the IEEE specifications on 802.11 wireless 212 LAN beaconing and probing process, studies (such as [37]) on the 213 effectiveness of these mechanisms, specifications on GSM network 214 discovery, results of the IETF Seamoby WG, and so on. 216 Traditionally, the problem of discovering available point of 217 attachment has been handled as a part of the link layer attachment 218 procedures, or through out-of-band mechanisms. 220 RFC 2194 [3] describes the pre-provisioning of dialup roaming 221 clients, which typically included a list of potential phone numbers, 222 updated by the provider(s) with which the client had a contractual 223 relationship. RFC 3017 [8] describes the IETF Proposed Standard for 224 the Roaming Access XML DTD. This covers not only the attributes of 225 the Points of Presence (POPs) and Internet Service Providers (ISPs), 226 but also hints on the appropriate NAI to be used with a particular 227 POP. The RFC supports dial-in and X.25 access, but has extensible 228 address and media type fields. 230 In IEEE 802.11 WLANs, the Beacon/Probe Request/Response mechanism 231 provides a way for Stations to discover Access Points (APs), as well 232 as the capabilities of those APs. Among the Information Elements 233 (IEs) included within the Beacon and Probe Response is the SSID, a 234 non-unique identifier of the network to which an Access Point is 235 attached. By combining network identification along with 236 capabilities discovery, the Beacon/Probe facility provides the 237 information required for both network discovery and roaming decisions 238 within a single mechanism. 240 As noted in [36], the IEEE 802.11 Beacon mechanism does not scale 241 well; with a Beacon interval of 100ms, and 10 APs in the vicinity, 242 approximately 32 percent of an 802.11b AP's capacity is used for 243 beacon transmission. In addition, since Beacon/Probe Response frames 244 are sent by each AP over the wireless medium, stations can only 245 discover APs within range, which implies substantial coverage overlap 246 for roaming to occur without interruption. 248 A number of enhancements have been proposed to the Beacon/Probe 249 Response mechanism in order to improve scalability and roaming 250 performance. These include allowing APs to announce capabilities of 251 neighbor APs as well as their own, as proposed in IEEE 802.11k. 253 Typically scalability enhancement mechanisms attempt to get around 254 Beacon/Probe Response restrictions by sending advertisements at the 255 higher layers which are enabled once the station has associated with 256 an AP and gained IP connectivity. Since these mechanisms run over 257 IP, they can utilize IP facilities such as fragmentation, which the 258 link layer mechanisms may not always be able to do. For instance, in 259 IEEE 802.11, Beacon frames cannot use fragmentation because they are 260 multicast frames, and multicast frames are not acknowledged in 261 802.11. 263 Another issue with the Beacon/Probe Request/Response mechanism is 264 that it is either insecure or its security can be assured only after 265 already attaching to this particular network. 267 When considering access systems such as 802.11 WLANs networks it is 268 important to take into account different deployment options. For 269 example, a WLAN deployment may include a number of VLANs in order to 270 separate UAM and 802.1X users or users accessing network from 271 different geographical/organizational locations. It is also possible 272 that a larger network spans multiple ESSes and prefixes. Typically 273 different enrollment methods and organizational locations within 274 ESSes advertise or respond to different SSIDs. However, it is also 275 possible that users authenticating to different realms are able to 276 do so via the same SSID. 278 2.2 Identity selection 280 As networks proliferate, it becomes more and more likely that a given 281 user may have multiple identities and credential sets, available for 282 use in different situations. For example, the user may have an 283 account with one or more Public WLAN providers; a corporate WLAN; 284 one or more wireless WAN providers. As a result, the user has to 285 decide which credential set to use when presented with a choice. 287 Figure 1 illustrates a situation where the user does not know whether 288 the access network he or she is attached to supports the realms he or 289 she is attemping to authenticate with. The access network 1 290 interworks only with the ISP and the access network 3 interworks with 291 the corporate network whereas the access network 2 interworks with 292 both. 294 ? ? +---------+ +------------------+ 295 ? | Access | | | 296 O_/ _-->| Network |------>| isp.example1.com | 297 /| / | 1 | _->| | 298 | | +---------+ / +------------------+ 299 _/ \_ | / 300 | +---------+ / 301 User "subscriber@isp. | | Access |/ 302 example1.com" -- ? -->| Network | 303 also known | | 2 |\ 304 "employee123@corp. | +---------+ \ 305 example2.com" | \ 306 | +---------+ \_ +-------------------+ 307 \_ | Access | ->| | 308 -->| Network |------>| corp.example2.com | 309 | 3 | | | 310 +---------+ +-------------------+ 312 Figure 1: Two credentials, three possible access networks 314 Traditionally, hints useful in identity selection have also been 315 provided out-of-band. For example, via the RFC 3017 XML DTD [8], a 316 client can select between potential POPs, and then based on 317 information provided in the DTD, determine the appropriate NAI to use 318 with the selected point of attachment to the network. 320 Perhaps the most typical case is a link layer that provides some 321 information about the realms that are reachable before EAP or some 322 other enrollment method is initiated. For instance, in IEEE 802.11 323 provides the SSID, though in some cases the client may not learn 324 about all the SSIDs supported by the given access point without 325 actively probing for additional SSIDs. In IKEv2 [14], the identity 326 of the responder (typically the security gateway) is provided as a 327 part of the usual IKEv2 exchange. 329 In order to use this information in deciding the right identity to 330 use, the provided information has to either match with one of the 331 client's home realms, or the client has to have some other knowledge 332 that enables to link the advertised access network name and the home 333 realm. For instance, the client may be aware that his home realm has 334 a roaming contract with a given access network. 336 It is also possible for hints to be embedded within credentials. In 337 [11], usage hints are provided within certificates used for wireless 338 authentication. This involves extending the client's certificate to 339 include the SSIDs with which the certificate can be used. 341 Finally, some EAP implementations use the space after the NUL 342 character in an EAP Identity Request to communicate some parameters 343 for example listing realms supported for authentication. The 344 Informational RFC [13] specifies the interpretation of the field 345 beyond the NUL character when realms are to be communicated. 347 2.3 AAA routing 349 Once the identity has been selected, it is necessary for the 350 authentication conversation to be routed back to the home realm. 351 This is typically done today through the use of the Network Access 352 Identifier (NAI), RFC 4282 [12], and the ability of the AAA network 353 to route requests to the realm indicated in the NAI. 355 Within the past IETF ROAMOPS WG, a number of additional approaches 356 were considered for routing authentication conversation back to the 357 home realm, including source routing techniques based on the NAI, and 358 techniques relying on the AAA infrastructure. Given the relative 359 simplicity of the roaming implementations described in RFC 2194 [3], 360 static routing mechanisms appeared adequate for the task and it was 361 not deemed necessary to develop dynamic routing protocols. 363 As noted in RFC 2607 [5], RADIUS proxies are deployed not only for 364 routing purposes, but also to mask a number of inadequacies in the 365 RADIUS protocol design, such as the lack of standardized 366 retransmission behavior and the need for shared secret provisioning. 368 By removing many of the protocol inadequacies, introducing new AAA 369 agent types such as Redirects, providing support for certificate- 370 based authentication as well as inter and intra-domain service 371 discovery, allowing DNS based dynamic discovery of peer agents, 372 Diameter allows a NAS to directly open a Diameter connection to the 373 home realm without having to utilize a network of proxies. For 374 instance, the Redirect feature could be used to provide a centralized 375 routing function for AAA, without having to know all home network 376 names in all access networks. However, there are issues in the 377 previously mentioned approach as setting up security might turn out 378 to be problematic and the model might not meet business practices. 380 This is somewhat analogous to the evolution of email delivery. Prior 381 to the widespread proliferation of the Internet, it was necessary to 382 gateway between SMTP-based mail systems and alternative delivery 383 technologies, such as UUCP and FidoNet, and email-address based 384 source-routing was used to handle this. However, as mail could 385 increasingly be delivered directly, the use of source routing 386 disappeared. 388 As with the selection of certificates by stations, a Diameter client 389 wishing to authenticate with a Diameter server may have a choice of 390 available certificates, and therefore it may need to choose between 391 them. 393 2.3.1 The Incomplete Routing Table Problem 395 No dynamic routing protocols are in use in AAA infrastructure today. 396 This implies that there has to be a device (such as a proxy) within 397 the access network that knows how to route to different domains, even 398 if they are further than one hop away, as shown in Figure 2. In this 399 figure, the user "joe@c.example.com" has to be authenticated through 400 ISP 2, since the domain "c.example.com" is served by it. 402 +---------+ +---------+ 403 | | | | 404 User "joe@ | Access |----->| ISP 1 |-----> "a.example.com" 405 c.example.com"-->| Network | | | 406 | | +---------+ 407 +---------+ 408 | 409 | 410 V 411 +---------+ 412 | |-----> "b.example.com" 413 | ISP 2 | 414 | |-----> "c.example.com" 415 +---------+ 417 Figure 2: AAA routing problem 419 2.3.2 The User and Identity Selection Problem 421 A related issue is that the roaming relationship graph may have 422 ambiguous routes, as shown in Figure 3. As billing is based on AAA 423 and pricing may be based on the used intermediaries, it is necessary 424 to select which route is used. For instance, in Figure 3, access 425 through the roaming group 1 may be cheaper, than if roaming group 2 426 is used. 428 +---------+ 429 | |----> "a.example.com" 430 | Roaming | 431 +---------+ | Group 1 | 432 | |----->| |----> "b.example.com" 433 User "joe@ | Access | +---------+ 434 a.example.com"--->| Network | 435 | | +---------+ 436 | |----->| |----> "a.example.com" 437 +---------+ | Roaming | 438 | Group 2 | 439 | |----> "c.example.com" 440 +---------+ 442 Figure 3: Ambiguous AAA routing 444 There have been requests to place credential and AAA route selection 445 under user control, as the user is affected by the pricing and other 446 differences. Optionally, automatic tools could make the selection 447 based on the user's preferences. On the other hand, user control is 448 similar to source routing, and as discussed earlier, network-based 449 routing mechanisms have traditionally won over source routing-based 450 mechanisms. 452 If users can control the selection of intermediaries, such 453 intermediaries still have to be legitimate AAA proxies. That is, an 454 access network should not send a request to an unknown intermediary. 455 If it has a business relationship with three intermediaries 456 int1.example.com, int2.example.com, and int3.example.com, it will 457 route the request through one of them, even if the user tried to 458 request routing through mitm.example.org. Thus, NAI-based source 459 routing is not source routing in the classic sense. It is merely 460 suggesting preferences among already established routes. If the 461 route does not already exist, or is not feasible, then NAI-based 462 source routing cannot establish it. 464 An additional issue is that even if the intermediaries are 465 legitimate, they could be switched. For instance, an access network 466 could advertise that it has a deal with 467 cheapintermediary.example.net, and then switch the user's selection 468 to priceyintermediary.example.com instead. To make this relevant, 469 the pricing would have to be based on the intermediary. Even if it 470 were possible to secure this selection, it would not be possible to 471 guarantee that QoS or other properties claimed by the network were 472 indeed provided. However, the ability to get authenticated via 473 intermediates implies that all the parties have a business agreement 474 with each other, which may also include an agreement about the 475 minimum service level guarantees. 477 Only a limited amount of information about AAA routes or pricing 478 information can be dynamically communicated [41]. It is necessary to 479 retrieve network and intermediary names, but quality of service or 480 pricing information is clearly something that would need to be pre- 481 provisioned, or perhaps just available via the web. Similarly, 482 dynamic communication of network names can not be expected to provide 483 all possible home network names, as their number can be quite large 484 globally. 486 As a result, network-based AAA routing mechanisms are preferred over 487 user-based selection where sufficient routes have been configured and 488 there is no need for user control. Where these conditions are not 489 met -- particularly when an attempt to use the network-based routing 490 mechanism has failed -- routing hints can be placed in an NAI as 491 defined in [12]. Where NAIs are used in this manner, the AAA routing 492 problem becomes a subset of the identifier selection problem. 494 2.4 Discovery, Decision, and Selection 496 An alternative decomposition of the problem is to consider the 497 discovery, decision, and selection aspects separately. Discovery 498 consists of discovering access networks and associated points of 499 attachment to the network, discovering what identities the access 500 networks will accept (either directly or through roaming 501 relationships), and discovering which potential AAA intermediaries or 502 routes exist. 504 Selection consists of attaching to the "right" access network and 505 point of attachment, offering an identity through EAP Identity 506 Response, and providing a hint about the desired AAA intermediary. 507 The selection of the AAA intermediary, along with the home and access 508 realms, determines also the treatment of payload packets. 510 Decision can be either manual selection or automatic. Most likely, 511 automatic mechanisms are preferred, even if manual selection should 512 be retained as a fallback. The type of the decision also places 513 additional requirements on the type of information that the discovery 514 phase must provide. Just knowing which choices are available is 515 probably enough for manual selection. Unfortunately, automatic 516 selection based on a list of choices is by itself not possible: 518 o Some access networks may be preferred over others. For instance, 519 the user's private corporate access network may be preferred over 520 a public access network due to cost and efficiency reasons. 522 o Similarly, some credentials may be preferred over others. 524 o Use of an access network with direct connection to home realm may 525 be preferred over using mediating networks. 527 o Some mediating networks may be preferred to others, for example 528 based on cost. Note that optimizing cost is not a trivial 529 problem, because the total cost may be a combination of a fixed 530 fee, per-minute, per-megabyte, volume discounts, and so on. 532 o Preferences may come from the user, his or her employer (who's 533 paying the bill), home realm, or access network. 535 Different discovery mechanisms can accommodate such preferences in 536 various ways. Some user input or perhaps a pre-provisioned database 537 seems inevitable. 539 Finally, while the final step of choosing a new access network lies 540 always on the client side, different approaches vary in how much they 541 rely on the client vs. network driven decisions. In cellular 542 networks, for instance, the network-based performance measurements 543 lead to instructions that the network gives to the client about the 544 appropriate base station(s) that should be used. Most of the 545 processing and decisions are performed on the network side. In 546 contrast, in a completely client-driven approach the client may get 547 some raw information from the access network, but makes all decisions 548 by itself. 550 2.5 Type of Information 552 A third alternative way to decompose the problem is to analyze the 553 type of information which is required [16]. For instance, access 554 network discovery may benefit from getting knowledge about the 555 quality of service available from a particular access network or 556 node, and AAA routing may require knowledge of roaming agreements. 557 References [16] and [27] describe the following categories of 558 information which can be discovered: 560 o Access network identification 562 o Roaming agreements 564 o Authentication mechanisms 566 o Quality of Service 568 o Cost 570 o Authorization policy 572 o Privacy policy 574 o Service parameters, such as the existence of middleboxes 576 The nature of the discovered information can be static, such as the 577 fastest available transmission speed on a given piece of equipment. 578 Or it can be dynamic, such as the current load on this equipment. 579 The information can describe something about the network access nodes 580 themselves, or it can be something that they simply advertise on 581 behalf of other parts of the network, such as roaming agreements 582 further in the AAA network. 584 Typically, it would be desirable to acquire all this information 585 prior to the authentication process. In some cases it is in fact 586 necessary, if the authentication process can not complete without the 587 information. Reference [27] classifies the possible steps at which 588 IEEE 802.11 networks can acquire this information: 590 o Pre-association 592 o Post-association (or pre-authentication) 594 o Post-authentication 596 Note that some EAP methods (such as those defined in [18] [20] [15]) 597 have an ability to agree about additional parameters during an 598 authentication process. While such parameters are useful for many 599 purposes, their use for access network selection suffers from an 600 obvious chicken-and-egg problem. Or at least it seems costly to run 601 a relatively heavy authentication process to decide whether the 602 client wants to attach to this access network. 604 3. Existing Work 606 3.1 IETF 608 There has already been a lot of past work in this area, including a 609 number of IETF Proposed Standards generated by the ROAMOPS WG. The 610 topic of roaming was considered different enough from both AAA and 611 access protocols such as PPP that it deserved its own WG. 613 In addition to work on ROAMOPS directly relating to the problem, 614 there has been work in SEAMOBY relating to scaling of target access 615 network discovery mechanisms; work in PKIX relating to identity and 616 credential selection; and work in AAA WG relating to access routing. 618 The PANA protocol [17] has a mechanism to advertise and select "ISPs" 619 through the exchange of the ISP-Information AVP in its initial 620 exchange. 622 Adrangi et al [13] define the use of the EAP-Request/Identity for 623 identifier selection. It is necessary to have this kind of a 624 mechanism, as clients may have more than one credential, and when 625 combined with the '!' syntax for NAIs, it can also be used for 626 mediating network discovery and selection. The use of lower-layer 627 information may also be limited in terms of discovering identifiers 628 that are used on the EAP layer. In the longer term, the use of this 629 mechanism may run into scalability problems, however. As noted in 630 [10] Section 4.x, the minimum EAP MTU is 1020 octets, so that an EAP- 631 Request/Identity is only guaranteed to be able to include 1015 octets 632 within the Type-Data field. Since RFC 1035 [1] enables FQDNs to be 633 up to 255 octets in length, this may not enable the announcement of 634 many realms, although if SSIDs are used, the maximum length of 32 635 octets per SSID may provide somewhat better scaling. The use of 636 other network identifiers than domain names is also possible, for 637 instance the PANA protocol uses an a free form string and an SMI 638 Network Management Private Enterprise Code [17], or Mobile Network 639 Codes embedded in NAIs as specified in 3GPP. 641 As noted in [38], the use of the EAP-Request/Identity for network 642 discovery has substantial negative impact on handoff latency, since 643 this may result in a station needing to initiate an EAP conversation 644 with each Access Point in order to receive an EAP-Request/Identity 645 describing which networks are supported. Since IEEE 802.11-1999 does 646 not support use of Class 1 data frames in State 1 (unauthenticated, 647 unassociated) within an Extended Service Set (ESS), this implies 648 either that the APs must support 802.1X pre-authentication (optional 649 in IEEE 802.11i) or that the station must associate with each AP 650 prior to sending an EAPOL- Start to initiate EAP. This will 651 dramatically increase handoff latency. 653 The effects to handoff latency depend also on the specific protocol 654 design, and the expected likelihood of having to provide 655 advertisements and initiate scanning of several APs. The use of 656 advertisements only as a last resort when the AAA routing has failed 657 is a better approach than the use of advertisement - scanning 658 procedure on every attachment. 660 Furthermore, if the AP has not been updated to present an up to date 661 set of realms in the EAP-Requests/Identity, after associating to 662 candidate APs and then choosing one, it is possible that the station 663 will find that the chosen realm is not supported after all. In this 664 case, the station's EAP-Response/Identity may be answered with an 665 updated EAP-Request/Identity, adding more latency. However, it is 666 possible to configure APs to pass through all EAP negotiation to a 667 local AAA proxy and provision the supported realms there. This would 668 ease the management of larger deployments but at the same time 669 require RFC 4284 support from the local AAA proxies. In general 670 upgrading the AAA proxies seems a better approach than upgrading and 671 managing all APs. 673 3.2 IEEE 675 There has been work in various IEEE 802 working groups relating to 676 network discovery enhancements. 678 Some recent and past contributions in this space include the 679 following: 681 o [22] defines the Beacon and Probe Response mechanisms used with 682 IEEE 802.11. Unfortunately, Beacons are only sent at the lowest 683 supported rate. Studies such as [40] have identified MAC layer 684 performance problems, and [36] have identified scaling issues 685 resulting from a lowering of the Beacon interval. 687 o [25] discusses the evolution of authentication models in WLANs, 688 and the need for the network to migrate from existing models to 689 new ones, based on either EAP layer indications or through the use 690 of SSIDs to represent more than the local network. It notes the 691 potential need for management or structuring of the SSID space. 693 The paper also notes that virtual APs have scalability issues. It 694 does not analyze these scalability issues in relation to those 695 existing in other alternative solutions, however. 697 o [23] discusses mechanisms currently used to provide "Virtual AP" 698 capabilities within a single physical access point. A "Virtual 699 AP" appears at the MAC and IP layers to be distinct physical AP. 700 As noted in the paper, full compatibility with existing 802.11 701 station implementations can only be maintained if each virtual AP 702 uses a distinct MAC address (BSSID) for use in Beacons and Probe 703 Responses. This draft does not discuss scaling issues in detail, 704 but recommends that only a limited number of virtual APs be 705 supported by a single physical access point. The simulations 706 presented in [36] appear to confirm this conclusion; with a Beacon 707 interval of 100 ms, once more than 8 virtual APs are supported on 708 a single channel, more than 20% of bandwidth is used for Beacons 709 alone. This would indicate a limit of approximately 20 virtual 710 APs per physical AP. 712 o IEEE 802.11u group is defining the access network discovery and 713 selection solution as part of its requirements [29]. The 714 requirements related to access network discovery and selection 715 include the functionality by which a station can determine whether 716 its subscription to a service provider would allow it to access a 717 particular 802.11 access network or whether the access network is 718 able to route authentication to user's home realm before actually 719 joining a BSS within that 802.11 access network. The mechanism 720 should be able to handle multiple credentials from the same user 721 and be able to select the correct credentials. Other planned 722 features would allow the station to learn the supported enrollment 723 mechanisms and possibly the set of basic services (such as 724 Internet access is provided or not) in the access network prior to 725 the user authenticating to his or her home realm. 727 o IEEE 802.21 is developing standards to enable handover and 728 interoperability between heterogeneous network types including 729 both 802 and non 802 networks. The intention is to provide a 730 general information transfer capability for these purposes. As a 731 result, network discovery process may benefit from such standards. 732 Part of handover process is the discovery of candidate access 733 networks and selection of an access network for a handover. The 734 IEEE 802.21 group is looking into various information elements 735 that can be used to provide sufficient information to either a 736 network node or the terminal to make network selection possible. 737 Both link layer and layer 3 delivery mechanisms are being looked 738 into. Layer 3 protocol development is being looked into in IETF 739 MIPSHOP WG. Different query mechanisms between the terminal and 740 the network, including using of XML or basic TLV type interaction 741 are being explored. 743 3.3 3GPP 745 The 3GPP stage 2 technical specification [30] covers the architecture 746 of 3GPP Interworking WLAN (I-WLAN) with 2G and 3G networks. This 747 specification discusses also network discovery and selection issues. 749 The I-WLAN network discovery and selection procedure borrows ideas 750 from the cellular side Public Land-based Mobile Network (PLMN) 751 selection principles. 753 In the 3GPP defined cellular network selection [32] the mobile node 754 monitors surrounding cells and prioritizes them e.g. based on signal 755 strength before selecting a new possible target cell. Each cell also 756 broadcasts its PLMN information. A mobile node may automatically 757 select cells that belong to its Home PLMN, Registered PLMN or to a 758 allowed set of Visited PLMNs. These lists of PLMNs are prioritized 759 and stored in the SIM card. In a case of manual network selection 760 the mobile node lists all PLMNs it knows from the surrounding cells 761 and lets the user to choose the desired PLMN. After the PLMN has 762 been selected other cell related prioritization takes place in order 763 to select the appropriate target cell. 765 Ahmavaara, Haverinen, and Pichna [34] discuss the new network 766 selection requirements that I-WLAN roaming introduces. It is 767 necessary to support automatic network selection, and not just manual 768 selection by the user. There may be multiple levels of networks, the 769 hotspot owner may have a contract with a provider who in turn has a 770 contract with one 3G network, and this 3G network has a roaming 771 capability with a number of other networks. 773 The I-WLAN specification requires that access network discovery is 774 performed as specified in the standards for the relevant WLAN link 775 layer technology. In addition to access network discovery, it is 776 necessary to select intermediary networks for the purposes of AAA 777 Routing. In 3GPP, these networks are PLMNs. It is assumed that WLAN 778 networks may have a contract with more than one PLMN. The PLMN may 779 be a Home PLMN (HPLMN) or a Visited PLMN (VPLMN) is a roaming case. 780 GSM/UMTS roaming principles are employed for routing AAA requests 781 from the VPLMN to the Home Public Land-based Mobile Network (HPLMN) 782 using either RADIUS or Diameter. The procedure for selecting the 783 intermediary network has been specified in the stage 3 technical 784 specifications [43] and [44]. 786 In order to select the PLMN, the following is required: 788 o User may choose the desired HPLMN or VPLMN manually or let the 789 WLAN User Equipment (WLAN UE) choose the PLMN automatically based 790 on the user and operator defined preferences. 792 o AAA messages are routed according to the (root) NAI or decorated 793 NAI. 795 o Existing EAP mechanisms are used where possible. 797 o Extensibility is desired, to allow the advertisement of other 798 parameters later. The current network advertisement and selection 799 is based on [12]. 801 The 3GPP I-WLAN technical specifications state that advertisement 802 information shall be provided only when the access network is unable 803 to route the request using normal AAA routing means, such as when it 804 sees an unknown NAI realm. It is also stated that where VPLMN 805 control is required, the necessary information is added to a NAI. 806 Furthermore, the WLAN UE may manually trigger the network 807 advertisement by using Alternative NAI in EAP Request/ Identity. The 808 Alternative NAI is guaranteed to be an unknown NAI realm throughout 809 all 3GPP networks. 811 The security requirements for 3GPP I-WLAN have been specified in the 812 3GPP stage 3 technical specification [42]. The security properties 813 related to different mediating network selection mechanisms have been 814 discussed earlier in the 3GPP contribution [31], which concludes that 815 both SSID- and EAP-based mechanisms have roughly similar (and very 816 limited) security properties, and that, as a result, network 817 advertisement should be considered only as hints. 819 3.4 Other 821 [35] discusses the need for network selection in a situation where 822 there is more than one available access network with a roaming 823 agreement to the home network. It also lists EAP-level, SSID-based, 824 and PEAP-based mechanisms as potential solutions to the network 825 selection problem. 827 Eijk et al [33] discussed the general issue of network selection. 828 They concentrated primarily on the access network discovery problem, 829 based on various criteria, and did not consider the other aspects of 830 the network selection problem. Nevertheless, they mention that one 831 of the network selection problems is that the information about 832 accessibility and roaming relationships is not stored in one 833 location, but rather spread around the network. 835 4. Design Issues 837 The following factors should be taken into consideration while 838 evaluating solutions for problem of network selection and discovery: 840 4.1 AAA issues 842 Access network or realm selection may leverage or interact with the 843 AAA infrastructure. The solution should therefore be compatible with 844 all AAA protocols. AAA routing mechanisms should work for requests, 845 responses, as well as server-initiated messages. The solution should 846 not prevent the introduction of new AAA or access network features, 847 such as link-state AAA routing protocols or fast handoffs. 849 4.2 Backward Compatibility 851 The solution should allow interoperability with clients, protocols, 852 access networks, AAA proxies, and AAA servers that have not been 853 modified to support network discovery and selection. For example, it 854 should not cause a problem with limited packet sizes of current 855 protocols. Where new protocol mechanisms are required, it should be 856 possible to deploy the solution without requiring changes to the 857 largest base of installed devices -- network access servers, wireless 858 access points, and clients. 860 4.3 Efficiency Constraints 862 The solution should be efficient in network resource utilization, 863 specially on bandwidth constrained sections of the network (E.g. 864 wireless link). Mechanisms that could significantly increase 865 communication of an unauthenticated device with more than one points 866 of attachment during the selection process should be avoided. For 867 many handheld devices, battery life is a significant constraint. 868 Mechanisms that could significantly drain battery e.g. by requiring 869 one or more radios in multimode devices to continuously scan for 870 networks, should be avoided. In addition, the solution should not 871 significantly impact network attachment time. 873 4.4 Network discovery and selection decision making 875 "Phone-book" based approaches such as RFC 3017 appear attractive due 876 to their ability to provide sufficient information for automatic 877 selection decisions. However, there is no experience on applying 878 such approaches to wireless access. The number of WLAN access points 879 is significantly higher than the number of dial-in POPs; the 880 distributed nature of the access network has created a more 881 complicated business and roaming structure, and the expected rate of 882 change in the information is high. As noted in [39] and [16], a 883 large fraction of current WLAN access points operate on the default 884 SSID, which may make the use of the phone book approach hard. 886 5. Conclusions 888 The issues surrounding the network discovery and selection problem 889 have been summarized. 891 In the opinion of the authors of this document, the main findings 892 are: 894 o There is a clear need for access network discovery, identifier 895 selection, AAA routing, and payload routing. 897 o Identifier selection and AAA routing problems can and should be 898 seen as the different aspects of the same problem, identifier 899 selection. 901 o Nevertheless, many of the problems discussed in this draft are 902 very hard when one considers them in an environment that requires 903 a potentially large number of networks, fast handoffs, and 904 automatic decisions. 906 o The proliferation of multiple competing network discovery 907 technologies within IEEE 802, IETF, and 3GPP appears to a 908 significant problem going forward. In the absence of a clearly 909 defined solution to the problem it is likely that any or all of 910 these solutions will be utilized, resulting in industry 911 fragmentation and lack of interoperability. 913 o New link layers should be designed with facilities that enable the 914 efficient distribution of network advertisement information. 916 o Solving all problems with current link layers and existing network 917 access devices may not be possible. It may be useful to consider 918 a phased approach where only certain, limited functions are 919 provided now, and the full functionality is provided when 920 extensions to current link layers become available. 922 We will briefly comment on the specific mechanisms related to access 923 network discovery and selection: 925 o As noted in studies such as [40] and [36], the IEEE 802.11 Beacon/ 926 Probe Response mechanism has substantial scaling issues, and as a 927 result a single physical access point is in practice limited to 928 less than a dozen virtual APs on each channel with IEEE 802.11b. 930 The situation is improved substantially with successors such as 931 IEEE 802.11a which enable additional channels, thus potentially 932 increasing the number of potential virtual APs. 934 However, even these enhancements it is not feasible to advertise 935 more than 50 different networks using existing mechanisms, and 936 probably significantly less in most circumstances. 938 As a result, there appears to be justification for enhancing the 939 scalability of network advertisements. 941 o Work is already underway in IEEE 802.1, IEEE 802.21 and the IEEE 942 802.11u to provide enhanced discovery functionality. For example, 943 IEEE 802.1ab enables network devices to announce themselves and 944 provide information on their capabilities. Similarly, the IEEE 945 802.1af has discussed the idea of supporting network discovery 946 within a future revision to IEEE 802.1X. However, neither IEEE 947 801.ab nor IEEE 802.1af is likely to address the transport of 948 large quantities of data where fragmentation would be a problem. 950 Another typical limitation of link layer assistance in this area 951 is that in general, it would be desirable to retrieve also 952 information relating to the potential next access networks or 953 access points. However, such networks may be of another type than 954 the current one, so the link layer would have to carry information 955 relating to other types of link layers as well. This is possible, 956 but requires coordination among different groups in the industry. 958 o Given that EAP does not support fragmentation of EAP-Request/ 959 Identity packets, and that use of EAP for network selection on all 960 attachments will have a substantial adverse impact on roaming 961 performance without appropriate lower layer support (such as 962 support for Class 1 data frames within IEEE 802.11), the use of 963 EAP is limited. For instance, the use of EAP to carry quality of 964 service as proposed in [16] seems hard given the limitations. 965 Long-term, it makes more sense for the desired functionality to be 966 handled either within IEEE 802 or at the IP layer. However, a 967 strictly limited discovery mechanism such as the one defined in 968 [13] is useful. 970 o In the IETF, a potential alternative is use of the SEAMOBY CARD 971 protocol [45], which enables advertisement of network device 972 capabilities over IP. Another alternative is the already expired 973 Device Discovery Protocol (DDP) [19] proposal, which provides 974 functionality equivalent to IEEE 802.1ab using ASN.1 encoded 975 advertisements sent to a link-local scope multicast address. 977 A limitation of these IP layer solutions is that they can only 978 work as a means to speed up the attachment procedures when moving 979 from one location to another; when a node starts up, it needs to 980 be able to attach to a network before IP communications are 981 available. This is fine for optimizations, but precludes the use 982 in a case where the discovery information is mandatory before 983 successful attachment can be accomplished, for instance when the 984 access network is unable to route the AAA request unaided. 986 6. Security Considerations 988 All aspects of the network discovery and selection problem are 989 security related. The security issues and requirements have been 990 discussed in the previous sections. 992 The security requirements for network discovery depend on the type of 993 information being discovered. Some of the parameters may have a 994 security impact, such as the claimed name of the network the user 995 tries to attach to. Unfortunately, current EAP methods do not always 996 make the verification of such parameters possible. New EAP methods 997 are doing it [18] [20], however, and there is even an attempt to 998 provide a backwards compatible extensions to older methods [15]. 1000 The security requirements for network selection depend on whether the 1001 selection is considered as a command or a hint. For instance, the 1002 selection that the user provided may be ignored if it relates to AAA 1003 routing and the access network can route the AAA traffic to the 1004 correct home network using other means in any case. 1006 7. References 1008 7.1 Normative References 1010 [1] Mockapetris, P., "Domain names - implementation and 1011 specification", STD 13, RFC 1035, November 1987. 1013 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1014 Levels", BCP 14, RFC 2119, March 1997. 1016 [3] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of 1017 Roaming Implementations", RFC 2194, September 1997. 1019 [4] Aboba, B. and M. Beadles, "The Network Access Identifier", 1020 RFC 2486, January 1999. 1022 [5] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1023 Implementation in Roaming", RFC 2607, June 1999. 1025 [6] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1026 Authentication Dial In User Service (RADIUS)", RFC 2865, 1027 June 2000. 1029 [7] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 1030 and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", 1031 RFC 2868, June 2000. 1033 [8] Riegel, M. and G. Zorn, "XML DTD for Roaming Access Phone 1034 Book", RFC 3017, December 2000. 1036 [9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 1037 "Diameter Base Protocol", RFC 3588, September 2003. 1039 [10] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1040 Levkowetz, "Extensible Authentication Protocol (EAP)", 1041 RFC 3748, June 2004. 1043 [11] Housley, R. and T. Moore, "Certificate Extensions and 1044 Attributes Supporting Authentication in Point-to-Point Protocol 1045 (PPP) and Wireless Local Area Networks (WLAN)", RFC 3770, 1046 May 2004. 1048 [12] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network 1049 Access Identifier", RFC 4282, December 2005. 1051 [13] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity 1052 Selection Hints for the Extensible Authentication Protocol 1053 (EAP)", RFC 4284, January 2006. 1055 [14] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1056 RFC 4306, December 2005. 1058 7.2 Informative References 1060 [15] Arkko, J. and P. Eronen, "Authenticated Service Identities for 1061 the Extensible Authentication Protocol (EAP)", 1062 draft-arkko-eap-service-identity-auth-04 (work in progress), 1063 October 2005. 1065 [16] Tschofenig, H., "Network Selection Implementation Results", 1066 draft-groeting-eap-netselection-results-00 (work in progress), 1067 July 2004. 1069 [17] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 1070 Yegin, "Protocol for Carrying Authentication for Network Access 1071 (PANA)", draft-ietf-pana-pana-11 (work in progress), 1072 March 2006. 1074 [18] Josefsson, S., Palekar, A., Simon, D., and G. Zorn, "Protected 1075 EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap-07 1076 (work in progress), October 2003. 1078 [19] Enns, R., Marques, P., and D. Morrell, "Device Discovery 1079 Protocol (DDP)", draft-marques-ddp-00 (work in progress), 1080 May 2003. 1082 [20] Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method (EAP- 1083 IKEv2)", draft-tschofenig-eap-ikev2-10 (work in progress), 1084 February 2006. 1086 [21] Institute of Electrical and Electronics Engineers, "Local and 1087 Metropolitan Area Networks: Port-Based Network Access Control", 1088 IEEE Standard 802.1X, September 2001. 1090 [22] Institute of Electrical and Electronics Engineers, "Wireless 1091 LAN Medium Access Control (MAC) and Physical Layer (PHY) 1092 Specifications", IEEE Standard 802.11, 2003. 1094 [23] Aboba, B., "Virtual Access Points", IEEE Contribution 11-03- 1095 154r1, May 2003. 1097 [24] Mishra, A., "Improving the latnecy of the Probe Phase during 1098 802.11 Handoff", IEEE Contribution 11-03-417r2, May 2003. 1100 [25] Hepworth, E., "Co-existence of Different Authentication 1101 Models", IEEE Contribution 11-03-0827 2003. 1103 [26] Hong, C. and T. Yew, "Interworking - WLAN Control", IEEE 1104 Contribution 11-03-0843 2003. 1106 [27] Berg, S., "Information to Support Network Selection", IEEE 1107 Contribution 11-04-0624 2004. 1109 [28] Aboba, B., "Network Selection", IEEE Contribution 11-04- 1110 0638 2004. 1112 [29] Moreton, M., "TGu Requirements", IEEE Contribution 11-05-0822- 1113 03-000u-tgu-requirements, August 2005. 1115 [30] 3GPP, "3GPP System to Wireless Local Area Network (WLAN) 1116 interworking; System Description; Release 6; Stage 2", 1117 3GPP Technical Specification 23.234 v 6.6.0, September 2005. 1119 [31] Ericsson, "Security of EAP and SSID based network 1120 advertisements", 3GPP Contribution S3-030736, November 2003. 1122 [32] 3GPP, "Non-Access-Stratum (NAS) functions related to Mobile 1123 Station (MS) in idle mode", 3GPP TS 23.122 6.5.0, October 2005. 1125 [33] Eijk, R., Brok, J., Bemmel, J., and B. Busropan, "Access 1126 Network Selection in a 4G Environment and the Role of Terminal 1127 and Service Platform", 10th WWRF, New York, October 2003. 1129 [34] Ahmavaara, K., Haverinen, H., and R. Pichna, "Interworking 1130 Architecture between WLAN and 3G Systems", IEEE Communications 1131 Magazine, November 2003. 1133 [35] Intel, "Wireless LAN (WLAN) End to End Guidelines for 1134 Enterprises and Public Hotspot Service Providers", 1135 November 2003. 1137 [36] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b 1138 MAC Layer Handover Time", Laboratory for Communication 1139 Networks, KTH, Royal Institute of Technology, Stockholm, 1140 Sweden, TRITA-IMIT-LCN R 03:02, April 2003. 1142 [37] Judd, G. and P. Steenkiste, "Fixing 802.11 Access Point 1143 Selection", Sigcomm Poster Session 2002. 1145 [38] Eronen, P., "Network Selection Issues", presentation to EAP WG 1146 at IETF 58, November 2003. 1148 [39] Priest, J., "The State of Wireless London", July 2004. 1150 [40] Heusse, M., "Performance Anomaly of 802.11b", LSR-IMAG 1151 Laboratory, Grenoble, France, IEEE Infocom 2003. 1153 [41] Eronen, P. and J. Arkko, "Role of authorization in wireless 1154 network security", Extended abstract presented in the DIMACS 1155 workshop, November 2004. 1157 [42] 3GPP, "3GPP Technical Specification Group Service and System 1158 Aspects; 3G Security; Wireless Local Area Network (WLAN) 1159 interworking security (Release 6); Stage 2", 3GPP Technical 1160 Specification 33.234 v 6.6.0, October 2005. 1162 [43] 3GPP, "3GPP System to Wireless Local Area Network (WLAN) 1163 interworking; User Equipment (UE) to network protocols; Stage 3 1164 (Release 6)", 3GPP Technical Specification 24.234 v 6.4.0, 1165 October 2005. 1167 [44] 3GPP, "3GPP system to Wireless Local Area Network (WLAN) 1168 interworking; Stage 3 (Release 6)", 3GPP Technical 1169 Specification 29.234 v 6.4.0, October 2005. 1171 [45] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, 1172 "Candidate Access Router Discovery (CARD)", RFC 4066, 1173 July 2005. 1175 Authors' Addresses 1177 Jari Arkko 1178 Ericsson 1179 Jorvas 02420 1180 Finland 1182 Email: jari.arkko@ericsson.com 1184 Bernard Aboba 1185 Microsoft 1186 One Microsoft Way 1187 Redmond, WA 98052 1188 USA 1190 Email: aboba@internaut.com 1191 Jouni Korhonen 1192 TeliaSonera 1193 Teollisuuskatu 13 1194 Sonera FIN-00051 1195 Finland 1197 Email: jouni.korhonen@teliasonera.com 1199 Farooq Bari 1200 Cingular Wireless 1201 7277 164th Avenue N.E. 1202 Redmond WA 98052 1203 USA 1205 Email: farooq.bari@cingular.com 1207 Appendix A. Contributors 1209 The editors of this document would like to especially acknowledge the 1210 contributions of Farid Adrangi, Farooq Bari, Michael Richardson, Pasi 1211 Eronen, Mark Watson, Mark Grayson, Johan Rune, and Tomas Goldbeck- 1212 Lowe. 1214 Input for the early versions of this draft has been gathered from 1215 many sources, including the above persons as well as 3GPP and IEEE 1216 developments. We would also like to thank Alper Yegin, Victor Lortz, 1217 Stephen Hayes, and David Johnston for comments. 1219 Intellectual Property Statement 1221 The IETF takes no position regarding the validity or scope of any 1222 Intellectual Property Rights or other rights that might be claimed to 1223 pertain to the implementation or use of the technology described in 1224 this document or the extent to which any license under such rights 1225 might or might not be available; nor does it represent that it has 1226 made any independent effort to identify any such rights. Information 1227 on the procedures with respect to rights in RFC documents can be 1228 found in BCP 78 and BCP 79. 1230 Copies of IPR disclosures made to the IETF Secretariat and any 1231 assurances of licenses to be made available, or the result of an 1232 attempt made to obtain a general license or permission for the use of 1233 such proprietary rights by implementers or users of this 1234 specification can be obtained from the IETF on-line IPR repository at 1235 http://www.ietf.org/ipr. 1237 The IETF invites any interested party to bring to its attention any 1238 copyrights, patents or patent applications, or other proprietary 1239 rights that may cover technology that may be required to implement 1240 this standard. Please address the information to the IETF at 1241 ietf-ipr@ietf.org. 1243 Disclaimer of Validity 1245 This document and the information contained herein are provided on an 1246 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1247 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1248 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1249 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1250 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1251 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1253 Copyright Statement 1255 Copyright (C) The Internet Society (2006). This document is subject 1256 to the rights, licenses and restrictions contained in BCP 78, and 1257 except as set forth therein, the authors retain all their rights. 1259 Acknowledgment 1261 Funding for the RFC Editor function is currently provided by the 1262 Internet Society.