idnits 2.17.1 draft-ietf-eap-netsel-problem-02.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1216. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1193. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1200. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1206. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 25, 2004) is 7122 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: '2' is defined on line 985, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 1072, but no explicit reference was found in the text == Unused Reference: '27' is defined on line 1083, 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) == Outdated reference: A later version (-14) exists of draft-adrangi-eap-network-discovery-05 == Outdated reference: A later version (-01) exists of draft-adrangi-eap-network-discovery-and-selection-00 == Outdated reference: A later version (-04) exists of draft-arkko-eap-service-identity-auth-01 == Outdated reference: A later version (-08) exists of draft-ietf-seamoby-card-protocol-05 == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-05 == Outdated reference: A later version (-06) exists of draft-ietf-radext-rfc2486bis-01 == Outdated reference: A later version (-01) exists of draft-lior-radius-redirection-00 == 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-03 Summary: 12 errors (**), 0 flaws (~~), 14 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: April 25, 2005 B. Aboba, Eds. 5 Microsoft 6 October 25, 2004 8 Network Discovery and Selection Problem 9 draft-ietf-eap-netsel-problem-02 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 25, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 The so called network discovery and selection problem affects network 45 access, particularly in the presence of multiple available wireless 46 accesses and roaming. This problem has been the subject of 47 discussions in various standards bodies. This document summarizes 48 the discussion held about this problem in the Extensible 49 Authentication Protocol (EAP) working group at the IETF. The problem 50 is defined and divided into subproblems, and some constraints for 51 possible solutions are outlined. The document presents also some 52 existing mechanisms which help solve at least parts of the problem, 53 and gives some suggestions on how to proceed for the rest. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Problem Definition . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1 Access Network Discovery . . . . . . . . . . . . . . 4 60 2.2 Identity selection . . . . . . . . . . . . . . . . . 5 61 2.3 AAA routing . . . . . . . . . . . . . . . . . . . . 7 62 2.3.1 The Incomplete Routing Table Problem . . . 8 63 2.3.2 The User Selection Problem . . . . . . . . 8 64 2.4 Payload Routing . . . . . . . . . . . . . . . . . . 10 65 2.4.1 Issues with Payload Routing . . . . . . . 10 66 2.5 Discovery, Decision, and Selection . . . . . . . . . 11 67 2.6 Type of Information . . . . . . . . . . . . . . . . 13 68 3. Design Constrains . . . . . . . . . . . . . . . . . . . . . . 14 69 4. Existing Work . . . . . . . . . . . . . . . . . . . . . . . . 15 70 4.1 IETF . . . . . . . . . . . . . . . . . . . . . . . . 15 71 4.2 IEEE . . . . . . . . . . . . . . . . . . . . . . . . 16 72 4.3 3GPP . . . . . . . . . . . . . . . . . . . . . . . . 17 73 4.4 Other . . . . . . . . . . . . . . . . . . . . . . . 18 74 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 77 7.1 Normative References . . . . . . . . . . . . . . . . . 24 78 7.2 Informative References . . . . . . . . . . . . . . . . 24 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 80 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 81 B. Modifications from Version 00 . . . . . . . . . . . . . . . . 29 82 Intellectual Property and Copyright Statements . . . . . . . . 30 84 1. Introduction 86 The so called network discovery and selection problem affects network 87 access and wireless access networks in particular. This problem 88 comes relevant when any of the following conditions are true: 90 o There is more than one available network attachment point, and the 91 different points may have different characteristics. 93 o The user has multiple sets of credentials. For instance, the user 94 could have one set of credentials from a public service provider 95 and another set from his company. 97 o There is more than one way to provide roaming between the access 98 and home network, and service parameters or pricing differs 99 between them. For instance, the access network could have both a 100 direct relationship with the home network and an indirect 101 relationship through a roaming consortium. 103 o The roaming relationships between access and home networks are so 104 complicated that current AAA protocols can not route the requests 105 to the home network unaided, just based on the domain in the given 106 Network Access Identifier (NAI) [4, 19]. 108 o Payload packets get routed or tunneled differently, based on which 109 particular roaming relationship variation is used. This may have 110 an impact on the available services or their pricing. 112 o Providers share the same infrastructure, such as wireless access 113 points. 115 The network discovery and selection problem spans multiple protocol 116 layers and has been the subject of discussions in IETF, 3GPP, and 117 IEEE 802.11. This document summarizes the discussion held about this 118 problem in the Extensible Authentication Protocol working group at 119 IETF. 121 In Section 2 the problem is defined and divided into subproblems, and 122 some constraints for possible solutions are outlined in Section 3. 123 Section 4 discusses existing mechanisms which help solve at least 124 parts of the problem. Section 5 gives some suggestions on how to 125 proceed for the rest. 127 2. Problem Definition 129 There are four somewhat orthogonal problems being discussed under the 130 rubric of "network discovery and selection". 132 o First, there is the problem of "Access Network discovery". This 133 is the problem of discovering access networks available in the 134 vicinity, and the points of presence (POPs) associated with those 135 networks. 137 o Second, there is the problem of "Identifier selection". This is 138 the problem of selecting which identity (and credentials) to use 139 to authenticate to a given POP. 141 o Thirdly, there is the problem of "AAA routing" which involves 142 figuring out how to route the authentication conversation 143 originating from the selected identity back to the home realm. 145 o Finally, there is the the problem of "Payload routing" which 146 involves figuring how the payload packets are routed, where more 147 advanced mechanisms than destination-based routing is needed. 149 Alternatively, the problem can be divided to the discovery, decision, 150 and the selection components. The AAA routing problem, for instance, 151 involves all components: discovery (which mediating networks are 152 available?), decision (choose the "best" one), and selection (client 153 tells the network which mediting network it has decided to choose) 154 components. 156 2.1 Access Network Discovery 158 The Access Network Discovery problem has been extensively studied, 159 see for instance the results of the IETF Seamoby WG, IEEE 160 specifications on 802.11 wireless LAN beaconing and probing process, 161 studies (such as [38]) on the effectiveness of these mechanisms, and 162 so on. 164 Traditionally, the problem of discovering available networks has been 165 handled as a part of the link layer attachment procedures, or through 166 out-of-band mechanisms. 168 RFC 2194 [3] describes the pre-provisioning of dialup roaming 169 clients, which typically included a list of potential phone numbers, 170 updated by the provider(s) with which the client had a contractual 171 relationship. RFC 3017 [8] describes the IETF Proposed Standard for 172 the Roaming Access XML DTD. This covers not only the attributes of 173 the Points of Presence (POPs) and Internet Service Providers (ISPs), 174 but also hints on the appropriate NAI to be used with a particular 175 POP. The RFC supports dial-in and X.25 access, but has extensible 176 address and media type fields. 178 In IEEE 802.11 WLANs, the Beacon/Probe Request/Response mechanism 179 provides a way for Stations to discover Access Points (APs), as well 180 as the capabilities of those APs. Among the Information Elements 181 (IEs) included within the Beacon and Probe Response is the SSID, a 182 non-unique identifier of the network to which an Access Point is 183 attached. By combining network identification along with 184 capabilities discovery, the Beacon/Probe facility provides the 185 information required for both network discovery and roaming decisions 186 within a single mechanism. 188 As noted in [37], the IEEE 802.11 Beacon mechanism does not scale 189 well; with a Beacon interval of 100ms, and 10 APs in the vicinity, 190 approximately 32 percent of an 802.11b AP's capacity is used for 191 beacon transmission. In addition, since Beacon/Probe Response frames 192 are sent by each AP over the wireless medium, stations can only 193 discover APs within range, which implies substantial coverage overlap 194 for roaming to occur without interruption. 196 A number of enhancements have been proposed to the Beacon/Probe 197 Response mechanism in order to improve scalability and roaming 198 performance. These include allowing APs to announce capabilities of 199 neighbor APs as well as their own, as proposed in IEEE 802.11k; 200 propagation of discovery information over IP, as handled in the CARD 201 protocol developed within the IETF SEAMOBY WG, etc. 203 Typically scalability enhancement mechanisms attempt to get around 204 Beacon/Probe Response restrictions by sending advertisements at the 205 higher rates which are enabled one the station has associated with an 206 AP. Since these mechanisms run over IP, they can utilize IP 207 facilities such as fragmentation, which the link layer mechanisms may 208 not always be able to do. For instance, in IEEE 802.11, Beacon 209 frames cannot use fragmentation because they are multicast frames, 210 and multicast frames are not acknowledged in 802.11. 212 Another issue with the Beacon/Probe Request/Response mechanism is 213 that it is either insecure or its security can be assured only after 214 already attaching to this particular network. 216 2.2 Identity selection 218 As networks proliferate, it becomes more and more likely that a given 219 EAP peer may have multiple identities and credential sets, available 220 for use in different situations. For example, the EAP peer may have 221 an account with one or more Public WLAN providers; a corporate WLAN; 222 one or more wireless WAN providers. As a result, the EAP peer has to 223 decide which credential set to use when presented with a given set of 224 potential EAP authenticators. 226 Figure 1 illustrates a situation where the user does not know whether 227 he is connected to access network 1, which only serves the ISP, 228 access network 3, which only serves the company, or access network 2, 229 which serves both. 231 +---------+ +---------+ 232 | Access | | | 233 _---->| Network |------>| isp.com | 234 / | 1 | _->| | 235 | +---------+ / +---------+ 236 | / 237 | +---------+ / 238 User "subscriber@ | | Access |/ 239 isp.com" also known as --- ? ---->| Network | 240 "employee123@corp.com" | | 2 |\ 241 | +---------+ \ 242 | \ 243 | +---------+ \_ +---------+ 244 \_ | Access | ->| | 245 ---->| Network |------>| corp.com| 246 | 3 | | | 247 +---------+ +---------+ 249 Figure 1: Two credentials, three possible access links 251 Traditionally, hints useful in identity selection have also been 252 provided out-of-band. For example, via the RFC 3017 XML DTD [8], a 253 client can select between potential POPs, and then based on 254 information provided in the DTD, determine the appropriate NAI to use 255 with the selected POP. 257 Perhaps the most typical case is a link layer that provides some 258 information about the network before EAP is initiated. For instance, 259 in IEEE 802.11 provides the SSID, though in some cases the client may 260 not learn about all the SSIDs supported by the given access point. 261 In IKEv2 [18], the identity of the responder (typically the security 262 gateway) is provided as a part of the usual IKEv2 exchange. 264 In order to use this information in deciding the right identity to 265 use, the provided information has to either match with one of the 266 client's home networks, or the client has to have some other 267 knowledge that enables to link the advertised network and the home 268 network. For instance, the client may be aware that his home network 269 has a roaming contract with a given access network. 271 It is also possible for hints to be embedded within credentials. In 272 [11], usage hints are provided within certificates used for wireless 273 authentication. This involves extending the client's certificate to 274 include the SSIDs with which the certificate can be used. 276 Finally, some EAP implementations use the space after the NUL 277 character in an EAP Identity Request to communicate some parameters 278 relating to the network requesting EAP authentication. While there 279 is Standards Track RFC specifying the interpretation of the field 280 beyond the NUL character, [12] is widely expected to be used. 282 2.3 AAA routing 284 Once the identity has been selected, it is necessary for the 285 authentication conversation to be routed back to the home realm. 286 This is typically done today through the use of the Network Access 287 Identifier (NAI), RFC 2486 [4, 19], and the ability of the AAA 288 network to route requests to the domain indicated in the NAI. 290 Within the IETF ROAMOPS WG, a number of additional approaches were 291 considered for this, including source routing techniques based on the 292 NAI, and techniques relying on the AAA infrastructure. Given the 293 relative simplicity of the roaming implementations described in RFC 294 2194 [3], static routing mechanisms appeared adequate for the task 295 and it was not deemed necessary to develop dynamic routing protocols. 297 As noted in RFC 2607 [5], RADIUS proxies are deployed not only for 298 routing purposes, but also to mask a number of inadequacies in the 299 RADIUS protocol design, such as the lack of standardized 300 retransmission behavior and the need for shared secret provisioning. 302 By removing many of the protocol inadequacies, introducing new AAA 303 agent types such as Redirects, providing support for 304 certificate-based authentication as well as inter and intra-domain 305 service discovery, Diameter allows a NAS to directly open a Diameter 306 connection to the home realm without having to utilize a network of 307 proxies. For instance, the Redirect feature could be used to provide 308 a centralized routing function for AAA, without having to know all 309 home network names in all access networks. 311 This is somewhat analogous to the evolution of email delivery. Prior 312 to the widespread proliferation of the Internet, it was necessary to 313 gateway between SMTP-based mail systems and alternative delivery 314 technologies, such as UUCP and FidoNet, and email-address based 315 source-routing was used to handle this. However, as mail could 316 increasingly be delivered directly, the use of source routing 317 disappeared. 319 As with the selection of certificates by stations, a Diameter client 320 wishing to authenticate with a Diameter server may have a choice of 321 available certificates, and therefore it may need to choose between 322 them. 324 2.3.1 The Incomplete Routing Table Problem 326 No dynamic routing protocols are in use in AAA infrastructure today. 327 This implies that there has to be a device (such as a proxy) within 328 the access network that knows how to route to different domains, even 329 if they are further than one hop away, as shown in Figure 2. In this 330 figure, the user "joe@corp3.com" has to be authenticated through ISP 331 2, since the domain "corp3.com" is served by it. 333 +---------+ +---------+ 334 | | | | 335 User "joe | Access |--------->| ISP 1 |-------> "corp1.com" 336 @corp3.com"-->| Network | | | 337 | | +---------+ 338 +---------+ 339 | 340 | 341 \|/ 342 +---------+ 343 | |--------> "corp2.com" 344 | ISP 2 | 345 | |--------> "corp3.com" 346 +---------+ 348 Figure 2: AAA routing problem 350 2.3.2 The User Selection Problem 352 A related issue is that the roaming relationship graph may have 353 ambiguous routes, as shown in Figure 3. As billing is based on AAA 354 and pricing may be based on the used intermediaries, it is necessary 355 to select which route is used. For instance, in Figure 3, access 356 through the roaming group 1 may be cheaper, than if roaming group 2 357 is used. For commercial reasons, intermediaries want to participate 358 the AAA transaction. 360 +---------+ 361 | |---------> "isp1.com" 362 | Roaming | 363 +---------+ | Group 1 | 364 | |-------->| |---------> "isp2.com" 365 User "joe | Access | +---------+ 366 @isp1.com"--->| Network | 367 | | +---------+ 368 | |-------->| |---------> "isp1.com" 369 +---------+ | Roaming | 370 | Group 2 | 371 | |---------> "isp3.com" 372 +---------+ 374 Figure 3: Ambiguous AAA routing 376 Currently planned networks include one level with a small number of 377 intermediaries, just a few now and perhaps up to 50 as a maximum. 378 However, multiple levels and higher number of alternative networks 379 are possible in theory. 381 There has been requests to place credential and AAA route selection 382 under user control, as the user is affected by the pricing and other 383 differences. Optionally, automatic tools could make the selection 384 based on the user's preferences. On the other hand, user control is 385 similar to source routing, and as discussed earlier, network-based 386 routing mechanisms have traditionally won over source routing-based 387 mechanisms. 389 If users can control the selection of intermediaries, such 390 intermediaries still have to be legitimate AAA proxies. That is, an 391 access network should not send a request to an unknown intermediary. 392 If it has a business relationship with three intermediaries int1.com, 393 int2.com, and int3.com, it will route your request through one of 394 them, even if you tried to request routing through mitm.org. Thus, 395 NAI-based source routing is not source routing in the classic sense. 396 It is merely suggesting preferences among already established routes. 397 If the route does not already exist, or is not feasible, then 398 NAI-based source routing cannot establish it. 400 An additional issue is that even if the intermediaries are 401 legitimate, they could be switched. For instance, an access network 402 could advertise that it has a deal with cheapintermediary.net, and 403 then switch the user's selection to priceyintermediary.com instead. 404 To make this relevant, the pricing would have to be based on the 405 intermediary. Even if it were possible to secure this selection, it 406 would not be possible to guarantee that QoS or other properties 407 claimed by the network were indeed provided. As a result, it may be 408 useful to think of the intermediary selection only as a hint. 410 Only a limited amount of information about AAA routes or pricing 411 information can be dynamically communicated [42]. It is necessary to 412 retrieve network and intermediary names, but quality of service or 413 pricing information is clearly something that would need to be 414 pre-provisioned, or perhaps just available via the web. Similarly, 415 dynamic communication of network names can not be expected to provide 416 all possible home network names, as their number can be quite large 417 globally. 419 As a result, network-based AAA routing mechanisms are preferred over 420 user-based selection where sufficient routes have been configured and 421 there is no need for user control. Where these conditions are not 422 met -- particularly when an attempt to use the network-based routing 423 mechanism has failed -- routing hints can be placed in an NAI as 424 defined in [4, 19]. Where NAIs are used in this manner, the AAA 425 routing problem becomes a subset of the identifier selection problem. 427 2.4 Payload Routing 429 The access network, mediating AAA infrastructure, and the home 430 network may all have a desire to affect the kind of treatment payload 431 packets get. This includes filtering, prioritization, routing paths, 432 and mandatory tunneling. 434 Traditionally, the involved entities have been able to provide some 435 control of this through AAA protocols such as RADIUS [6] and Diameter 436 [9]. RFC 2868 [7] defines tunneling attributes that the home and 437 mediating networks can use to establish mandatory tunneling at the 438 access network. RFC 3588 [9] defines a filter syntax which can be 439 used to install per-session filters under the control of AAA. 441 2.4.1 Issues with Payload Routing 443 In an attack described by Michael Richardson, a rogue hotspot 444 operator (but with a legitimate roaming relationship to a home 445 network) steals revenues from local hotspot operator by spoofing its 446 identity. The rogue operator places a node with two interfaces in 447 the coverage area of the local operator, and attaches to the Internet 448 via this operator using a flat fee -based account. It then starts to 449 advertise itself as a hotspot operator on the other interface, luring 450 unsuspecting clients to use this node rather the than the local 451 operator. The users authenticate via this node and its roaming 452 relationship. All AAA and payload traffic goes via the local 453 hotspot, suitably NATted by the rogue node. As a result, the rogue 454 operator gets the roaming service fees for a number of clients, 455 whereas the local operator gets just one client. 457 Due to the way that the IEEE 802.11, IETF protocols, and common EAP 458 methods have been designed, the rogue operator can actually advertise 459 the same identity (SSID) as the local operator; the parameters 460 advertised by the access point information are not authenticated 461 end-to-end to the home network. EAP methods that support channel 462 bindings [10] do not have this problem, but this support is not 463 present in commonly used methods. Rogue access point can present a 464 different set of parameters to the client and to the home network. 465 The current network access mechanisms enable us to have 466 authentication, and link layer protection. They do not, however, 467 guarantee anything about the delivery of the actual payload packets. 468 In particular, there is no guarantee that the payload packets are 469 delivered through a right route, or NATed only up to some specific 470 number of times. 472 We call this the "payload route binding problem". In this problem, 473 authentication and link layer support do not guarantee that the 474 packets are actually routed through the path that appears to have 475 been offered. Basically, if the "rogue" access point has a flat fee 476 account and a contract with a clearing house, it can offer access to 477 anyone with a per-byte account, NAT their packets, and send the 478 traffic forward on its own account, and generate income. The local 479 ISP would not be able to detect this by looking at the traffic 480 stream. The user would not be able to detect it either, unless an 481 EAP method with channel binding support is used. And even if it is, 482 the user may not care about the identity of the access point enough 483 to look at it; channel bindings can only ensure that all parties 484 agree about the parameters, not that they make sense. 486 The working group did not come to a conclusion whether this attack 487 needs to be prevented. Some of the proposed solutions include the 488 use of EAP EMSK in the authentication exchange with the DHCP server, 489 or the use of EAP to provide the certificates that SEND requires for 490 the authentication of Router Advertisements. Either approach means 491 that we are sure we are speaking at layer 3 to the services that we 492 authenticated at layer two. However, this does not prevent an 493 attacker from offering such services, and then performing a NAT on 494 the packets later. However, IPsec could be used to detect the 495 presence of such NATs, even if NAT traversal is in use. 497 2.5 Discovery, Decision, and Selection 499 An alternative decomposition of the problem is to consider the 500 discovery, decision, and selection aspects separately. Discovery 501 consists of discovering access networks and associated POPs, 502 discovering what identities the access networks will accept (either 503 directly or through roaming relationships), and discovering which 504 potential AAA intermediaries or routes exist. 506 Selection consists of attaching to the "right" access network and 507 POP, offering an identity through EAP Identity Response, and 508 providing a hint about the desired AAA intermediary. The selection 509 of the AAA intermediary, along with the home and access networks, 510 determines also the treatment of payload packets. 512 Decision can be either manual selection or automatic. Most likely, 513 automatic mechanisms are preferred, even if manual selection should 514 be retained as a fallback. The type of the decision also places 515 additional requirements on the type of information that the discovery 516 phase must provide. Just knowing which choices are available is 517 probably enough for manual selection. Unfortunately, automatic 518 selection based on a list of choices is by itself not possible: 520 o Some access networks may be preferred over others. For instance, 521 the user's private corporate network may be preferred over a 522 public network due to cost and efficiency reasons. 524 o Similarly, some credentials may be preferred over others. 526 o Use of an access network with direct connection to home network 527 may be preferred over using mediating networks. 529 o Some mediating networks may be preferred to others, most likely 530 based on cost. Note that optimizing cost is not a trivial 531 problem, because the total cost may be a combination of a fixed 532 fee, per-minute, per-megabyte, volume discounts, and so on. 534 o Preferences may come from the user, his or her employer (who's 535 paying the bill), home network, or access network. 537 Different discovery mechanisms can accommodate such preferences in 538 various ways. Some user input or perhaps a pre-provisioned database 539 seems inevitable. 541 Finally, while the final step of choosing a new network lies always 542 on the client side, different approches vary in how much they rely on 543 the client vs. network driven decisions. In cellular networks, for 544 instance, the network-based performance measurements lead to 545 instructions that the network gives to the client about the 546 appropriate base station(s) that should be used. Most of the 547 processing and decisions are performed on the network side. In 548 contrast, in a completely client-driven approach the client may get 549 some raw information from the network, but makes all decisions by 550 itself. 552 2.6 Type of Information 554 A third alternative way to decompose the problem is to analyze the 555 type of information which is required [15]. For instance, access 556 network discovery may benefit from getting knowledge about the 557 quality of service available from a particular access network or 558 node, and AAA routing may require knowledge of roaming agreements. 559 References [15] and [30] describe the following categories of 560 information which can be discovered: 562 o Access network identification 563 o Roaming agreements 564 o Authentication mechanisms 565 o Quality of service 566 o Cost 567 o Authorization policy 568 o Privacy policy 569 o Service parameters, such as the existence of middleboxes 571 The nature of the discovered information can be static, such as the 572 fastest available transmission speed on a given piece of equipment. 573 Or it can be dynamic, such as the current load on this equipment. 574 The information can describe something about the network access nodes 575 themselves, or it can be something that they simply advertise on 576 behalf of other parts of the network, such as roaming agreements 577 further in the AAA network. 579 Typically, it would be desirable to acquire all this information 580 prior to the authentication process. In some cases it is in fact 581 necessary, if the authentication process can not complete without the 582 information. Reference [30] classifies the possible steps at which 583 IEEE 802.11 networks can acquire this information: 585 o Pre-association 586 o Post-association (or pre-authentication) 587 o Post-authentication 589 Note that some EAP methods (such as those defined in [21, 23, 14]) 590 have an ability to agree about additional parameters during an 591 authentication process. While such parameters are useful for many 592 purposes, their use for network selection suffers from an obvious 593 chicken-and-egg problem. Or at least it seems costly to run a 594 relatively heavy authentication process to decide whether the client 595 wants to attach to this network. 597 3. Design Constrains 599 All solutions to the network selection and discovery problem must 600 satisfy the following additional constraints: 602 o AAA routing mechanisms have to work for requests, responses, as 603 well as server-initiated messages. 605 o Solution is compatible with all AAA protocols. 607 o Does not prevent the introduction of new AAA or access network 608 features, such as link-state AAA routing protocols or fast 609 handoffs. 611 o Does not consume a significant amount of resources, such as 612 bandwidth or increase network attachment time. 614 o Does not cause a problem with limited packet sizes of current 615 protocols. 617 o Where new protocol mechanisms are required, it should be possible 618 to deploy the solution without requiring changes to the largest 619 base of installed devices -- network access servers, wireless 620 access points, and clients. 622 o Similarly, new solutions should allow interoperability with 623 clients, access networks, AAA proxies, and AAA servers that have 624 not been modified to support network discovery and selection. 626 4. Existing Work 628 4.1 IETF 630 There has already been a lot of past work in this area, including a 631 number of IETF Proposed Standards generated by the ROAMOPS WG. The 632 topic of roaming was considered different enough from both AAA and 633 access protocols such as PPP that it deserved its own WG. 635 In addition to work on ROAMOPS directly relating to the problem, 636 there has been work in SEAMOBY relating to scaling of network 637 discovery mechanisms; work in PKIX relating to identity and 638 credential selection; and work in AAA WG relating to access routing. 640 The PANA protocol [17] has a mechanism to advertise and select "ISPs" 641 through the exchange of the ISP-Information AVP in its initial 642 exchange. 644 A number of (small) improvements to payload routing control are 645 currently in progress in the IETF RADEXT WG. These include better 646 filtering and redirection support [20]. RADEXT WG is also working on 647 an new revision of the NAI specification [19]. This revision 648 clarifies the use of the '!' syntax in a NAI to route requests via 649 specified mediating networks. 651 Adrangi et al [12] discuss the use of the EAP-Request/Identity for 652 identifier selection. It is necessary to have this kind of a 653 mechanism, as clients may have more than one credential, and when 654 combined with the '!' syntax for NAIs, it can also be used for 655 mediating network discovery and selection. The use of lower-layer 656 information may also be limited in terms of discovering identifiers 657 that are used on the EAP layer. In the longer term, the use of this 658 mechanism may run into scalability problems, however. As noted in 659 [10] Section 3.1, the minimum EAP MTU is 1020 octets, so that an 660 EAP-Request/Identity is only guaranteed to be able to include 1015 661 octets within the Type-Data field. Since RFC 1035 [1] enables FQDNs 662 to be up to 255 octets in length, this may not enable the 663 announcement of many networks, although if SSIDs are used, the 664 maximum length of 32 octets per SSID may provide somewhat better 665 scaling. The use of other network identifiers than domain names is 666 also possible, for instance the PANA protocol uses an a free form 667 string and an SMI Network Management Private Enterprise Code [17], or 668 Mobile Network Codes embedded in NAIs as specified in 3GPP. 670 As noted in [39], the use of the EAP-Request/Identity for network 671 discovery has substantial negative impact on handoff latency, since 672 this may result in a station needing to initiate an EAP conversation 673 with each Access Point in order to receive an EAP-Request/Identity 674 describing which networks are supported. Since IEEE 802.11-1999 does 675 not support use of Class 1 data frames in State 1 (unauthenticated, 676 unassociated) within an ESS, this implies either that the APs must 677 support 802.1X pre-authentication (optional in IEEE 802.11i) or that 678 the station must associate with each AP prior to sending an 679 EAPOL-Start to initiate EAP. This will dramatically increase handoff 680 latency. 682 The effects to handoff latency depend also on the specific protocol 683 design, and the expected likelihood of having to provide 684 advertisements and initiate scanning of several access points. The 685 use of advertisements only as a last resort when the AAA routing has 686 failed is a better approach than the use of advertisement - scanning 687 procedure on every attachment. 689 Furthermore, if the AP has not been updated to present an up to date 690 set of networks in the EAP-Requests/Identity, after associating to 691 candidate APs and then choosing one, it is possible that the station 692 will find that the chosen network is not supported after all. In 693 this case, the station's EAP-Response/Identity may be answered with 694 an updated EAP-Request/Identity, adding more latency. 696 4.2 IEEE 698 There has been work in IEEE 802.11 and 802.1 relating to network 699 discovery enhancements. 701 Some recent contributions in this space include the following: 703 o [25] defines the Beacon and Probe Response mechanisms used with 704 IEEE 802.11. Unfortunately, Beacons are only sent at the lowest 705 supported rate. Studies such as [41] have identified MAC layer 706 performance problems, and [37] have identified scaling issues 707 resulting from a lowering of the Beacon interval. 709 o [28] discusses the evolution of authentication models in WLANs, 710 and the need for the network to migrate from existing models to 711 new ones, based on either EAP layer indications or through the use 712 of SSIDs to represent more than the local network. It notes the 713 potential need for management or structuring of the SSID space. 715 The paper also notes that virtual APs have scalability issues. It 716 does not analyze these scalability issues in relation to those 717 existing in other alternative solutions, however. 719 o [29] discusses requirements for differentiation in the way that 720 the user's payload traffic is routed, based on home network 721 control. Such requirements have come up, for instance, in the 722 context of 3GPP. 724 o [26] discusses mechanisms currently used to provide "Virtual AP" 725 capabilities within a single physical access point. A "Virtual 726 AP" appears at the MAC and IP layers to be distinct physical AP. 727 As noted in the paper, full compatibility with existing 802.11 728 station implementations can only be maintained if each virtual AP 729 uses a distinct MAC address (BSSID) for use in Beacons and Probe 730 Responses. This draft does not discuss scaling issues in detail, 731 but recommends that only a limited number of virtual APs be 732 supported by a single physical access point. The simulations 733 presented in [37] appear to confirm this conclusion; with a Beacon 734 interval of 100 ms, once more than 8 virtual APs are supported on 735 a single channel, more than 20% of bandwidth is used for Beacons 736 alone. This would indicate a limit of approximately 20 virtual 737 APs per physical AP. 739 o The 802.11 WIEN Study Group is working on the network discovery 740 and selection problem. In general, the group is working to define 741 the problem at this stage. This includes studies on the 742 limitations of existing mechanisms, and gathering requirements 743 about the type of information needed from the discovery process. 744 Some of the contributions in this group include [31] and [30]. 746 o IEEE 802.21 is developing standards to enable handover and 747 interoperability between heterogeneous network types including 748 both 802 and non 802 networks. The intention is to provide a 749 general information transfer capability for these purposes. As a 750 result, network discovery process may benefit from such standards. 752 4.3 3GPP 754 The 3GPP technical specification [32] covers the interworking of WLAN 755 networks with 2G and 3G networks. This specification discusses also 756 network discovery and selection issues. 758 The specification requires that Access Network Discovery is performed 759 as specified in the standards for the relevant WLAN link layer 760 technology. An early version of the technical specification required 761 the use of a 3GPP-specific SSID, but that has since then been 762 abandoned; access network or local 3GPP network based SSIDs may be 763 used instead. It has not been decided whether some conventions on 764 the format of these SSIDs is required by 3GPP. 766 In addition to Access Network Discovery, it is necessary to select 767 intermediary networks for the purposes of AAA Routing. In 3GPP, 768 these networks are called Visited Public Land-based Mobile Networks 769 (VPLMNs), and it is assumed that WLAN networks may have a contract 770 with more than one VPLMN. GSM/UMTS roaming mechanisms are then 771 employed for routing AAA requests from the VPLMN to the home network. 773 In order to select the VPLMN, the following is required: 775 o User can choose the desired VPLMN. 777 o AAA message are routed according to the NAI. 779 o Existing EAP mechanisms are used where possible. 781 o Extensibility is desired, to allow the advertisement of other 782 parameters later. 784 The referenced 3GPP technical specification is a so called stage 2 785 specification, and contains only the principles of operation, leaving 786 detailed protocol work for later. Nevertheless, the specification 787 states that advertisement information shall be provided only when the 788 access network is unable to route the request using normal AAA 789 routing means, such as when it sees an unknown NAI domain. It is 790 also stated that where VPLMN control is required, the necessary 791 information is added to a NAI. 793 The security properties related to different mediating network 794 selection mechanisms have been discussed in the 3GPP contribution 795 [33], which concludes that both SSID- and EAP-based mechanisms have 796 roughly similar (and very limited) security properties, and that, as 797 a result, network advertisement should be considered only as hints. 799 Ahmavaara, Haverinen, and Pichna [35] discuss the new network 800 selection requirements that 3G-WLAN roaming introduces. It is 801 necessary to support automatic network selection, and not just manual 802 selection by the user. There may be multiple levels of networks, the 803 hotspot owner may have a contract with a provider who in turn has a 804 contract with one 3G network, and this 3G network has a roaming 805 capability with a number of other networks. 807 4.4 Other 809 [36] discusses the need for network selection in a situation where 810 there is more than one available access network with a roaming 811 agreement to the home network. It also lists EAP-level, SSID-based, 812 and PEAP-based mechanisms as potential solutions to the network 813 selection problem. 815 Eijk et al [34] discussed the general issue of network selection. 816 They concentrated primarily on the Access Network Discovery problem, 817 based on various criteria, and did not consider the other aspects of 818 the network selection problem. Nevertheless, they mention that one 819 of the network selection problems is that the information about 820 accessibility and roaming relationships is not stored in one 821 location, but rather spread around the network. 823 5. Conclusions 825 The issues surrounding the network discovery and selection problem 826 have been summarized. 828 In the opinion of the editors of this document, the main findings 829 are: 831 o There is a clear need for access network discovery, identifier 832 selection, AAA routing, and payload routing. 834 o Existing mechanisms appear largely sufficient for the control of 835 payload routing, even if some minor improvements are being worked 836 on. But there appears to be justification for significantly 837 enhanced mechanisms relating to access network discovery, 838 identifier selection, and AAA routing. 840 o Identifier selection and AAA routing problems can and should be 841 seen as the different aspects of the same problem, identifier 842 selection. 844 o Nevertheless, many of the problems discussed in this draft are 845 very hard when one considers them in an environment that requires 846 a potentially large number of networks, fast handoffs, and 847 automatic decisions. 849 o The proliferation of multiple competing network discovery 850 technologies within IEEE 802, IETF, and 3GPP appears to a 851 significant problem going forward. In the absence of a clearly 852 defined solution to the problem it is likely that any or all of 853 these solutions will be utilized, resulting in industry 854 fragmentation and lack of interoperability. 856 In order to avoid this fate, it is strongly suggested that a 857 discussion be initiated between IETF and IEEE 802 in order to work 858 out the roles of the each organization in solving this problem, 859 and to invite 3GPP participation so that their requirements can be 860 fulfilled by the planned solutions. 862 o New link layers should be designed with facilities that enable the 863 efficient distribution of network advertisement information. 865 o Solving all problems with current link layers and existing network 866 access devices may not be possible. It may be useful to consider 867 a phased approach where only certain, limited functions are 868 provided now, and the full functionality is provided when 869 extensions to current link layers become available. 871 We will briefly comment on the specific mechanisms related to network 872 discovery and selection: 874 o As noted in studies such as [41] and [37], the IEEE 802.11 875 Beacon/Probe Response mechanism has substantial scaling issues, 876 and as a result a single physical access point is in practice 877 limited to less than a dozen virtual APs on each channel with IEEE 878 802.11b. 880 The situation is improved substantially with successors such as 881 IEEE 802.11a which enable additional channels, thus potentially 882 increasing the number of potential virtual APs. 884 However, even these enhancements it is not feasible to advertise 885 more than 50 different networks using existing mechanisms, and 886 probably significantly less in most circumstances. 888 As a result, there appears to be justification for enhancing the 889 scalability of network advertisements. 891 o Work is already underway in IEEE 802.1 and the 802.11 WIEN Study 892 Group to provide enhanced discovery functionality. For example, 893 IEEE 802.1ab enables network devices to announce themselves and 894 provide information on their capabilities. Similarly, the IEEE 895 802.1af has discussed the idea of supporting network discovery 896 within a future revision to IEEE 802.1X. However, neither IEEE 897 801.ab nor IEEE 802.1af is likely to address the transport of 898 large quantities of data where fragmentation would be a problem. 900 Another typical limitation of link layer assistance in this area 901 is that in general, it would be desirable to retrive also 902 information relating to the potential next access networks or 903 access points. However, such networks may be of another type than 904 the current one, so the link layer would have to carry information 905 relating to other types of link layers as well. This is possible, 906 but requires coordination among different groups in the industry. 908 o Given that EAP does not support fragmentation of 909 EAP-Request/Identity packets, and that use of EAP for network 910 selection on all attachments will have a substantial adverse 911 impact on roaming performance without appropriate lower layer 912 support (such as support for Class 1 data frames within IEEE 913 802.11), the use of EAP is limited. For instance, the use of EAP 914 to carry quality of service as proposed in [15] seems hard given 915 the limitations. Long-term, it makes more sense for the desired 916 functionality to be handled either within IEEE 802 or at the IP 917 layer. However, a strictly limited discovery mechanism such as 918 the one defined in [12] is useful. 920 o In the IETF, a potential alternative is use of the SEAMOBY CARD 921 protocol [16], which enables advertisement of network device 922 capabilities over IP. Another alternative is the recently 923 proposed Device Discovery Protocol (DDP) [22], which provides 924 functionality equivalent to IEEE 802.1ab using ASN.1 encoded 925 advertisements sent to a link-local scope multicast address. 927 A limitation of these IP layer solutions is that they can only 928 work as a means to speed up the attachment procedures when moving 929 from one location to another; when a node starts up, it needs to 930 be able to attach to a network before IP communications are 931 available. This is fine for optimizations, but precludes the use 932 in a case where the discovery information is mandatory before 933 successful attachment can be accomplished, for instance when the 934 access network is unable to route the AAA request unaided. 936 o "Phone-book" based approaches such as RFC 3017 appear attractive 937 due to their ability to provide sufficient information for 938 automatic selection decisions. However, there is no experience on 939 applying such approaches to wireless access. The number of WLAN 940 access points is significantly higher than the number of dial-in 941 POPs; the distributed nature of the access network has created a 942 more complicated business and roaming structure, and the expected 943 rate of change in the information is high. As noted in [40] and 944 [15], a large fraction of current WLAN access points operate on 945 the default SSID, which may make the use of the phone book 946 approach hard. 948 Finally, to address some of the security concerns that have come up 949 during this work, the IETF should in any case initiate work that 950 enables support for channel bindings in methods. Preferably, popular 951 methods should be updated, ensuring compatibility with existing 952 deployments. The representation of link layer parameters within EAP 953 should utilize a common framework, to make it easier to define new 954 link layers and keep the selection of EAP methods independent of the 955 link layer. A number of proposals exist in this space, but none of 956 them have yet been adopted by the EAP WG as work items. 958 6. Security Considerations 960 All aspects of the network discovery and selection problem are 961 security related. The security issues and requirements have been 962 discussed in the previous sections. 964 The security requirements for network discovery depend on the type of 965 information being discovered. Some of the parameters may have a 966 security impact, such as the claimed name of the network the user 967 tries to attach to. Unfortunately, current EAP methods do not always 968 make the verification of such parameters possible. New EAP methods 969 are doing it [21, 23], however, and there is even an attempt to 970 provide a backwards compatible extensions to older methods [14]. 972 The security requirements for network selection depend on whether the 973 selection is considered as a command or a hint. For instance, the 974 selection that the user provided may be ignored if it relates to AAA 975 routing and the access network can route the AAA traffic to the 976 correct home network using other means in any case. 978 7. References 980 7.1 Normative References 982 [1] Mockapetris, P., "Domain names - implementation and 983 specification", STD 13, RFC 1035, November 1987. 985 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 986 Levels", BCP 14, RFC 2119, March 1997. 988 [3] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, "Review of 989 Roaming Implementations", RFC 2194, September 1997. 991 [4] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 992 2486, January 1999. 994 [5] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 995 Implementation in Roaming", RFC 2607, June 1999. 997 [6] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 998 Authentication Dial In User Service (RADIUS)", RFC 2865, June 999 2000. 1001 [7] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and 1002 I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 1003 2868, June 2000. 1005 [8] Riegel, M. and G. Zorn, "XML DTD for Roaming Access Phone 1006 Book", RFC 3017, December 2000. 1008 [9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, 1009 "Diameter Base Protocol", RFC 3588, September 2003. 1011 [10] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 1012 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1013 3748, June 2004. 1015 [11] Housley, R. and T. Moore, "Certificate Extensions and 1016 Attributes Supporting Authentication in Point-to-Point Protocol 1017 (PPP) and Wireless Local Area Networks (WLAN)", RFC 3770, May 1018 2004. 1020 7.2 Informative References 1022 [12] Adrangi, F., Lortz, V., Bari, F., Eronen, P. and M. Watson, 1023 "Mediating Network Discovery in the Extensible Authentication 1024 Protocol (EAP)", draft-adrangi-eap-network-discovery-05 (work 1025 in progress), October 2004. 1027 [13] Adrangi, F., "Network Discovery and Selection within the EAP 1028 Framework", 1029 draft-adrangi-eap-network-discovery-and-selection-00 (work in 1030 progress), October 2003. 1032 [14] Arkko, J. and P. Eronen, "Authenticated Service Identities for 1033 the Extensible Authentication Protocol (EAP)", 1034 draft-arkko-eap-service-identity-auth-01 (work in progress), 1035 October 2004. 1037 [15] Tschofenig, H., "Network Selection Implementation Results", 1038 draft-groeting-eap-netselection-results-00 (work in progress), 1039 July 2004. 1041 [16] Liebsch, M., "Candidate Access Router Discovery", 1042 draft-ietf-seamoby-card-protocol-05 (work in progress), 1043 November 2003. 1045 [17] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin, 1046 "Protocol for Carrying Authentication for Network Access 1047 (PANA)", draft-ietf-pana-pana-05 (work in progress), July 2004. 1049 [18] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1050 draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. 1052 [19] Aboba, B., "The Network Access Identifier", 1053 draft-ietf-radext-rfc2486bis-01 (work in progress), October 1054 2004. 1056 [20] Lior, A., "Remote Authentication Dial In User Service (RADIUS) 1057 Redirection", draft-lior-radius-redirection-00 (work in 1058 progress), February 2004. 1060 [21] Josefsson, S., Palekar, A., Simon, D. and G. Zorn, "Protected 1061 EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap-07 1062 (work in progress), October 2003. 1064 [22] Enns, R., Marques, P. and D. Morrell, "Device Discovery 1065 Protocol (DDP)", draft-marques-ddp-00 (work in progress), May 1066 2003. 1068 [23] Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method 1069 (EAP-IKEv2)", draft-tschofenig-eap-ikev2-03 (work in progress), 1070 February 2004. 1072 [24] Institute of Electrical and Electronics Engineers, "Local and 1073 Metropolitan Area Networks: Port-Based Network Access Control", 1074 IEEE Standard 802.1X, September 2001. 1076 [25] Institute of Electrical and Electronics Engineers, "Wireless 1077 LAN Medium Access Control (MAC) and Physical Layer (PHY) 1078 Specifications", IEEE Standard 802.11, 1999. 1080 [26] Aboba, B., "Virtual Access Points", IEEE Contribution 1081 11-03-154r1, May 2003. 1083 [27] Mishra, A., "Improving the latnecy of the Probe Phase during 1084 802.11 Handoff", IEEE Contribution 11-03-417r2, May 2003. 1086 [28] Hepworth, E., "Co-existence of Different Authentication 1087 Models", IEEE Contribution 11-03-0827 2003. 1089 [29] Hong, C. and T. Yew, "Interworking - WLAN Control", IEEE 1090 Contribution 11-03-0843 2003. 1092 [30] Berg, S., "Information to Support Network Selection", IEEE 1093 Contribution 11-04-0624 2004. 1095 [31] Aboba, B., "Network Selection", IEEE Contribution 11-04-0638 1096 2004. 1098 [32] 3GPP, "3GPP System to Wireless Local Area Network (WLAN) 1099 interworking; System Description; Release 6", 3GPP Draft 1100 Technical Specification 23.234 v 2.2.0, December 2003. 1102 [33] Ericsson, "Security of EAP and SSID based network 1103 advertisements", 3GPP Contribution S3-030736, November 2003. 1105 [34] Eijk, R., Brok, J., Bemmel, J. and B. Busropan, "Access Network 1106 Selection in a 4G Environment and the Role of Terminal and 1107 Service Platform", 10th WWRF, New York, October 2003. 1109 [35] Ahmavaara, K., Haverinen, H. and R. Pichna, "Interworking 1110 Architecture between WLAN and 3G Systems", IEEE Communications 1111 Magazine, November 2003. 1113 [36] Intel, "Wireless LAN (WLAN) End to End Guidelines for 1114 Enterprises and Public Hotspot Service Providers", November 1115 2003. 1117 [37] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b 1118 MAC Layer Handover Time", Laboratory for Communication 1119 Networks, KTH, Royal Institute of Technology, Stockholm, 1120 Sweden, TRITA-IMIT-LCN R 03:02, April 2003. 1122 [38] Judd, G. and P. Steenkiste, "Fixing 802.11 Access Point 1123 Selection", Sigcomm Poster Session 2002. 1125 [39] Eronen, P., "Network Selection Issues", presentation to EAP WG 1126 at IETF 58, November 2003. 1128 [40] Priest, J., "The State of Wireless London", July 2004. 1130 [41] Heusse, M., "Performance Anomaly of 802.11b", LSR-IMAG 1131 Laboratory, Grenoble, France, IEEE Infocom 2003. 1133 [42] Eronen, P. and J. Arkko, "Role of authorization in wireless 1134 network security", Extended abstract to be presented in the 1135 DIMACS workshop, November 2004. 1137 Authors' Addresses 1139 Jari Arkko 1140 Ericsson 1141 Jorvas 02420 1142 Finland 1144 EMail: jari.arkko@ericsson.com 1146 Bernard Aboba 1147 Microsoft 1148 One Microsoft Way 1149 Redmond, WA 98052 1150 USA 1152 EMail: aboba@internaut.com 1154 Appendix A. Contributors 1156 Version 00 of this draft was based on the discussion held on the EAP 1157 WG mailing list in December 2003, and on a number of input documents 1158 such as [13]. The editors of this document would like to especially 1159 acknowledge the contributions of Farid Adrangi, Farooq Bari, Michael 1160 Richardson, Pasi Eronen, Mark Watson, Mark Grayson, Johan Rune, and 1161 Tomas Goldbeck-Lowe. 1163 Input for version 01 has been gathered from many sources, including 1164 the above persons as well as 3GPP and IEEE developments. We would 1165 also like to thank Alper Yegin, Victor Lortz, Stephen Hayes, and 1166 David Johnston for comments. 1168 Appendix B. Modifications from Version 00 1170 The following modifications have been incorporated to the -01 version 1171 of this draft: 1172 o Added a discussion of new IETF protocol documents relating to this 1173 problem, such as [12], [19], [20], and [14]. 1174 o Added references to a number of new documents that discuss the 1175 network selection problem. 1176 o Added pointers to new IEEE work in this area. 1177 o Added a discussion of what type of information may need to be 1178 discovered and when (Section 2.6). 1179 o Added a discussion relating to the use of phone books in an 1180 environment where network identifiers are not being regularly set. 1181 o Added a discussion of network-based control in Section 2.5. 1182 o Updated the conclusions. 1184 Intellectual Property Statement 1186 The IETF takes no position regarding the validity or scope of any 1187 Intellectual Property Rights or other rights that might be claimed to 1188 pertain to the implementation or use of the technology described in 1189 this document or the extent to which any license under such rights 1190 might or might not be available; nor does it represent that it has 1191 made any independent effort to identify any such rights. Information 1192 on the procedures with respect to rights in RFC documents can be 1193 found in BCP 78 and BCP 79. 1195 Copies of IPR disclosures made to the IETF Secretariat and any 1196 assurances of licenses to be made available, or the result of an 1197 attempt made to obtain a general license or permission for the use of 1198 such proprietary rights by implementers or users of this 1199 specification can be obtained from the IETF on-line IPR repository at 1200 http://www.ietf.org/ipr. 1202 The IETF invites any interested party to bring to its attention any 1203 copyrights, patents or patent applications, or other proprietary 1204 rights that may cover technology that may be required to implement 1205 this standard. Please address the information to the IETF at 1206 ietf-ipr@ietf.org. 1208 Disclaimer of Validity 1210 This document and the information contained herein are provided on an 1211 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1212 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1213 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1214 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1215 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1216 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1218 Copyright Statement 1220 Copyright (C) The Internet Society (2004). This document is subject 1221 to the rights, licenses and restrictions contained in BCP 78, and 1222 except as set forth therein, the authors retain all their rights. 1224 Acknowledgment 1226 Funding for the RFC Editor function is currently provided by the 1227 Internet Society.