idnits 2.17.1 draft-ietf-eap-netsel-problem-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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.) 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 (January 10, 2004) is 7402 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 857, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 913, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 924, 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) == Outdated reference: A later version (-09) exists of draft-ietf-eap-rfc2284bis-07 == Outdated reference: A later version (-05) exists of draft-ietf-pkix-wlan-extns-04 == 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-02 == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-07 == Outdated reference: A later version (-01) exists of draft-adrangi-eap-network-discovery-and-selection-00 Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 2 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: July 10, 2004 B. Aboba, Eds. 5 Microsoft 6 January 10, 2004 8 Network Discovery and Selection Problem 9 draft-ietf-eap-netsel-problem-00 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 10, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 The so called network discovery and selection problem affects network 41 access, particularly in the presence of multiple available wireless 42 accesses and roaming. This problem has been the subject of 43 discussions in various standards bodies. This document summarizes 44 the discussion held about this problem in the Extensible 45 Authentication Protocol (EAP) working group at the IETF. The problem 46 is defined and divided into subproblems, and some constraints for 47 possible solutions are outlined. The document presents also some 48 existing mechanisms which help solve at least parts of the problem, 49 and gives some suggestions on how to proceed for the rest. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Problem Definition . . . . . . . . . . . . . . . . . . . . . 4 55 2.1 Access Network Discovery . . . . . . . . . . . . . . . 4 56 2.1.1 Issues with Access Network Discovery . . . . . . 5 57 2.2 Identity selection . . . . . . . . . . . . . . . . . . 5 58 2.3 AAA routing . . . . . . . . . . . . . . . . . . . . . 7 59 2.3.1 Issues with AAA Routing . . . . . . . . . . . . 8 60 2.4 Payload Routing . . . . . . . . . . . . . . . . . . . 10 61 2.4.1 Issues with Payload Routing . . . . . . . . . . 10 62 2.5 Discovery, Decision, and Selection . . . . . . . . . . 11 63 3. Design Constrains . . . . . . . . . . . . . . . . . . . . . 13 64 4. Existing Work . . . . . . . . . . . . . . . . . . . . . . . 14 65 4.1 IETF . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 4.2 IEEE . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 4.3 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 4.4 Other . . . . . . . . . . . . . . . . . . . . . . . . 17 69 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 18 70 6. Security Considerations . . . . . . . . . . . . . . . . . . 21 71 Normative References . . . . . . . . . . . . . . . . . . . . 22 72 Informative References . . . . . . . . . . . . . . . . . . . 23 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 24 74 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 75 Intellectual Property and Copyright Statements . . . . . . . 26 77 1. Introduction 79 The so called network discovery and selection problem affects network 80 access and wireless access networks in particular. This problem 81 comes relevant when any of the following conditions are true: 83 o There is more than one available network attachment point, and the 84 different points may have different characteristics. 86 o The user has multiple sets of credentials. For instance, the user 87 could have one set of credentials from a public service provider 88 and another set from his company. 90 o There is more than one way to provide roaming between the access 91 and home network, and service parameters or pricing differs 92 between them. For instance, the access network could have both a 93 direct relationship with the home network and an indirect 94 relationship through a roaming consortium. 96 o The roaming relationships between access and home networks are so 97 complicated that current AAA protocols can not route the requests 98 to the home network unaided, just based on the domain in the given 99 Network Access Identifier (NAI) [4]. 101 o Payload packets get routed or tunneled differently, based on which 102 particular roaming relationship variation is used. This may have 103 an impact on the available services or their pricing. 105 o Providers share the same infrastructure, such as wireless access 106 points. 108 The network discovery and selection problem spans multiple protocol 109 layers and has been the subject of discussions in IETF, 3GPP, and 110 IEEE 802.11. This document summarizes the discussion held about this 111 problem in the Extensible Authentication Protocol working group at 112 IETF. 114 In Section 2 the problem is defined and divided into subproblems, and 115 some constraints for possible solutions are outlined in Section 3. 116 Section 4 discusses existing mechanisms which help solve at least 117 parts of the problem. Section 5 gives some suggestions on how to 118 proceed for the rest. 120 2. Problem Definition 122 There are four somewhat orthogonal problems being discussed under the 123 rubric of "network discovery and selection". 125 o First, there is the problem of "Access Network discovery". This 126 is the problem of discovering access networks available in the 127 vicinity, and the points of presence (POPs) associated with those 128 networks. 130 o Second, there is the problem of "Identifier selection". This is 131 the problem of selecting which identity (and credentials) to use 132 to authenticate to a given POP. 134 o Thirdly, there is the problem of "AAA routing" which involves 135 figuring out how to route the authentication conversation 136 originating from the selected identity back to the home realm. 138 o Finally, there is the the problem of "Payload routing" which 139 involves figuring how the payload packets are routed, where more 140 advanced mechanisms than destination-based routing is needed. 142 Alternatively, the problem can be divided to the discovery, decision, 143 and the selection components. The AAA routing problem, for instance, 144 involves all components: discovery (which mediating networks are 145 available?), decision (choose the "best" one), and selection (this is 146 the chosen network) components. 148 2.1 Access Network Discovery 150 The Access Network Discovery problem has been extensively studied, 151 see for instance the results of the IETF Seamoby WG, IEEE 152 specifications on 802.11 wireless LAN beaconing and probing process, 153 studies (such as [29]) on the effectiveness of these mechanisms, and 154 so on. 156 Traditionally, the problem of discovering available networks has been 157 handled as a part of the link layer attachment procedures, or through 158 out-of-band mechanisms. 160 RFC 2194 [3] describes the pre-provisioning of dialup roaming 161 clients, which typically included a list of potential phone numbers, 162 updated by the provider(s) with which the client had a contractual 163 relationship. RFC 3017 [8] describes the IETF Proposed Standard for 164 the Roaming Access XML DTD. This covers not only the attributes of 165 the Points of Presence (POPs) and Internet Service Providers (ISPs), 166 but also hints on the appropriate NAI to be used with a particular 167 POP. The RFC supports dial-in and X.25 access, but has extensible 168 address and media type fields. 170 In IEEE 802.11 WLANs, the Beacon/Probe Request/Response mechanism 171 provides a way for Stations to discover Access Points (APs), as well 172 as the capabilities of those APs. Among the Information Elements 173 (IEs) included within the Beacon and Probe Response is the SSID, a 174 non-unique identifier of the network to which an Access Point is 175 attached. By combining network identification along with 176 capabilities discovery, the Beacon/Probe facility provides the 177 information required for both network discovery and roaming decisions 178 within a single mechanism. 180 2.1.1 Issues with Access Network Discovery 182 As noted in [28], the IEEE 802.11 Beacon mechanism does not scale 183 well; with a Beacon interval of 100ms, and 10 APs in the vicinity, 184 approximately 32 percent of an 802.11b AP's capacity is used for 185 beacon transmission. In addition, since Beacon/Probe Response frames 186 are sent by each AP over the wireless medium, stations can only 187 discover APs within range, which implies substantial coverage overlap 188 for roaming to occur without interruption. 190 A number of enhancements have been proposed to the Beacon/Probe 191 Response mechanism in order to improve scalability and roaming 192 performance. These include allowing APs to announce capabilities of 193 neighbor APs as well as their own, as proposed in IEEE 802.11k; 194 propagation of discovery information over IP, as handled in the CARD 195 protocol developed within the IETF SEAMOBY WG, etc. 197 Typically scalability enhancement mechanisms attempt to get around 198 Beacon/Probe Response restrictions by sending advertisements at the 199 higher rates which are enabled one the station has associated with an 200 AP. Since these mechanisms run over IP, they can utilize IP 201 facilities such as fragmentation, which the link layer mechanisms may 202 not always be able to do. For instance, in IEEE 802.11, Beacon 203 frames cannot use fragmentation because they are multicast frames, 204 and multicast frames are not acknowledged in 802.11. 206 2.2 Identity selection 208 As networks proliferate, it becomes more and more likely that a given 209 EAP peer may have multiple identities and credential sets, available 210 for use in different situations. For example, the EAP peer may have 211 an account with one or more Public WLAN providers; a corporate WLAN; 212 one or more wireless WAN providers. As a result, the EAP peer has to 213 decide which credential set to use when presented with a given set of 214 potential EAP authenticators. 216 Figure 1 illustrates a situation where the user does not know whether 217 he is connected to access network 1, which only serves the ISP, 218 access network 3, which only serves the company, or access network 2, 219 which serves both. 221 +---------+ +---------+ 222 | Access | | | 223 _---->| Network |------>| isp.com | 224 / | 1 | _->| | 225 | +---------+ / +---------+ 226 | / 227 | +---------+ / 228 User "subscriber@ | | Access |/ 229 isp.com" also known as --- ? ---->| Network | 230 "employee123@corp.com" | | 2 |\ 231 | +---------+ \ 232 | \ 233 | +---------+ \_ +---------+ 234 \_ | Access | ->| | 235 ---->| Network |------>| corp.com| 236 | 3 | | | 237 +---------+ +---------+ 239 Figure 1: Two credentials, three possible access links 241 Traditionally, hints useful in identity selection have also been 242 provided out-of-band. For example, via the RFC 3017 XML DTD [8], a 243 client can select between potential POPs, and then based on 244 information provided in the DTD, determine the appropriate NAI to use 245 with the selected POP. 247 Perhaps the most typical case is a link layer that provides some 248 information about the network before EAP is initiated. For instance, 249 in IEEE 802.11 provides the SSID, though in some cases the client may 250 not learn about all the SSIDs supported by the given access point. 251 In IKEv2 [15], the identity of the responder (typically the security 252 gateway) is provided in the same packet as the EAP Identity Request 253 is transported. In order to use this information in deciding the 254 right identity to use, the provided information has to either match 255 with one of the client's home networks, or the client has to have 256 some other knowledge that enables to link the advertised network and 257 the home network. For instance, the client may be aware that his 258 home network has a roaming contract with a given access network. 260 It is also possible for hints to be embedded within credentials. In 261 [11], usage hints are provided within certificates used for wireless 262 authentication. This involves extending the client's certificate to 263 include the SSIDs with which the certificate can be used. 265 Finally, some EAP implementations use the space after the NUL 266 character in an EAP Identity Request to communicate some parameters 267 relating to the network requesting EAP authentication. However, 268 there is no standard interpretation of the field beyond the NUL 269 character. 271 2.3 AAA routing 273 Once the identity has been selected, it is necessary for the 274 authentication conversation to be routed back to the home realm. 275 This is typically done today through the use of the Network Access 276 Identifier (NAI), RFC 2486 [4], and the ability of the AAA network to 277 route requests to the domain indicated in the NAI. 279 Within the IETF ROAMOPS WG, a number of additional approaches were 280 considered for this, including source routing techniques based on the 281 NAI, and techniques relying on the AAA infrastructure. Given the 282 relative simplicity of the roaming implementations described in RFC 283 2194 [3], static routing mechanisms appeared adequate for the task 284 and it was not deemed necessary to develop dynamic routing protocols. 286 As noted in RFC 2607 [5], RADIUS proxies are deployed not only for 287 routing purposes, but also to mask a number of inadequacies in the 288 RADIUS protocol design, such as the lack of standardized 289 retransmission behavior and the need for shared secret provisioning. 291 By removing many of the protocol inadequacies, introducing new AAA 292 agent types such as Redirects, providing support for 293 certificate-based authentication as well as inter and intra-domain 294 service discovery, Diameter allows a NAS to directly open a Diameter 295 connection to the home realm without having to utilize a network of 296 proxies. For instance, the Redirect feature could be used to provide 297 a centralized routing function for AAA, without having to know all 298 home network names in all access networks. 300 This is somewhat analogous to the evolution of email delivery. Prior 301 to the widespread proliferation of the Internet, it was necessary to 302 gateway between SMTP-based mail systems and alternative delivery 303 technologies, such as UUCP and FidoNet, and email-address based 304 source-routing was used to handle this. However, as mail could 305 increasingly be delivered directly, the use of source routing 306 disappeared. 308 As with the selection of certificates by stations, a Diameter client 309 wishing to authenticate with a Diameter server may have a choice of 310 available certificates, and therefore it may need to choose between 311 them. 313 2.3.1 Issues with AAA Routing 315 No dynamic routing protocols are in use in AAA infrastructure today. 316 This implies that there has to be a device (such as a proxy) within 317 the access network that knows how to route to different domains, even 318 if they are further than one hop away, as shown in Figure 2. In this 319 figure, the user "joe@corp3.com" has to be authenticated through ISP 320 2, since the domain "corp3.com" is served by it. 322 +---------+ +---------+ 323 | | | | 324 User "joe | Access |--------->| ISP 1 |-------> "corp1.com" 325 @corp3.com"-->| Network | | | 326 | | +---------+ 327 +---------+ 328 | 329 | 330 \|/ 331 +---------+ 332 | |--------> "corp2.com" 333 | ISP 2 | 334 | |--------> "corp3.com" 335 +---------+ 337 Figure 2: AAA routing problem 339 A related issue is that the roaming relationship graph may have 340 ambiguous routes, as shown in Figure 3. As billing is based on AAA 341 and pricing may be based on the used intermediaries, it is necessary 342 to select which route is used. For instance, in Figure 3, access 343 through the roaming group 1 may be cheaper, than if roaming group 2 344 is used. For commercial reasons, intermediaries want to participate 345 the AAA transaction. 347 +---------+ 348 | |---------> "isp1.com" 349 | Roaming | 350 +---------+ | Group 1 | 351 | |-------->| |---------> "isp2.com" 352 User "joe | Access | +---------+ 353 @isp1.com"--->| Network | 354 | | +---------+ 355 | |-------->| |---------> "isp1.com" 356 +---------+ | Roaming | 357 | Group 2 | 358 | |---------> "isp3.com" 359 +---------+ 361 Figure 3: Ambiguous AAA routing 363 Currently planned networks include one level with a small number of 364 intermediaries, just a few now and perhaps up to 50 as a maximum. 365 However, multiple levels and higher number of alternative networks 366 are possible in theory. 368 There has been requests to place credential and AAA route selection 369 under user control, as the user is affected by the pricing and other 370 differences. Optionally, automatic tools could make the selection 371 based on the user's preferences. On the other hand, user control is 372 similar to source routing, and as discussed earlier, network-based 373 routing mechanisms have traditionally won over source routing-based 374 mechanisms. 376 If users can control the selection of intermediaries, such 377 intermediaries still have to be legitimate AAA proxies. That is, an 378 access network should not send a request to an unknown intermediary. 379 If it has a business relationship with three intermediaries int1.com, 380 int2.com, and int3.com, it will route your request through one of 381 them, even if you tried to request routing through mitm.org. Thus, 382 NAI-based source routing is not source routing in the classic sense. 383 It is merely suggesting preferences among already established routes. 384 If the route does not already exist, or is not feasible, then 385 NAI-based source routing cannot establish it. 387 An additional issue is that even if the intermediaries are 388 legitimate, they could be switched. For instance, an access network 389 could advertise that it has a deal with cheapintermediary.net, and 390 then switch the user's selection to priceyintermediary.com instead. 391 To make this relevant, the pricing would have to be based on the 392 intermediary. Even if it were possible to secure this selection, it 393 would not be possible to guarantee that QoS or other properties 394 claimed by the network were indeed provided. As a result, it may be 395 useful to think of the intermediary selection only as a hint. 397 Only a limited amount of information about AAA routes can be 398 dynamically communicated. It is necessary to retrieve network and 399 intermediary names, but quality of service or pricing information is 400 clearly something that would need to be pre-provisioned, or perhaps 401 just available via the web. Similarly, dynamic communication of 402 network names can not be expected to provide all possible home 403 network names, as their number can be quite large globally. 405 2.4 Payload Routing 407 The access network, mediating AAA infrastructure, and the home 408 network may all have a desire to affect the kind of treatment payload 409 packets get. This includes filtering, prioritization, routing paths, 410 and mandatory tunneling. 412 Traditionally, the involved entities have been able to provide some 413 control of this through AAA protocols such as RADIUS [6] and Diameter 414 [9]. RFC 2868 [7] defines tunneling attributes that the home and 415 mediating networks can use to establish mandatory tunneling at the 416 access network. RFC 3588 [9] defines a filter syntax which can be 417 used to install per-session filters under the control of AAA. 419 2.4.1 Issues with Payload Routing 421 In an attack described by Michael Richardson, a rogue hotspot 422 operator (but with a legitimate roaming relationship to a home 423 network) steals revenues from local hotspot operator by spoofing its 424 identity. The rogue operator places a node with two interfaces in 425 the coverage area of the local operator, and attaches to the Internet 426 via this operator using a flat fee -based account. It then starts to 427 advertise itself as a hotspot operator on the other interface, luring 428 unsuspecting clients to use this node rather the than the local 429 operator. The users authenticate via this node and its roaming 430 relationship. All AAA and payload traffic goes via the local 431 hotspot, suitably NATted by the rogue node. As a result, the rogue 432 operator gets the roaming service fees for a number of clients, 433 whereas the local operator gets just one client. 435 Due to the way that the IEEE 802.11, IETF protocols, and common EAP 436 methods have been designed, the rogue operator can actually advertise 437 the same identity (SSID) as the local operator; the parameters 438 advertised by the access point information are not authenticated 439 end-to-end to the home network. EAP methods that support channel 440 bindings [10] do not have this problem, but this support is not 441 present in commonly used methods. Rogue access point can present a 442 different set of parameters to the client and to the home network. 443 The current network access mechanisms enable us to have 444 authentication, and link layer protection. They do not, however, 445 guarantee anything about the delivery of the actual payload packets. 446 In particular, there is no guarantee that the payload packets are 447 delivered through a right route, or NATed only up to some specific 448 number of times. 450 We call this the "payload route binding problem". In this problem, 451 authentication and link layer support do not guarantee that the 452 packets are actually routed through the path that appears to have 453 been offered. Basically, if the "rogue" access point has a flat fee 454 account and a contract with a clearing house, it can offer access to 455 anyone with a per-byte account, NAT their packets, and send the 456 traffic forward on its own account, and generate income. The local 457 ISP would not be able to detect this by looking at the traffic 458 stream. The user would not be able to detect it either, unless an 459 EAP method with channel binding support is used. And even if it is, 460 the user may not care about the identity of the access point enough 461 to look at it; channel bindings can only ensure that all parties 462 agree about the parameters, not that they make sense. 464 The working group did not come to a conclusion whether this attack 465 needs to be prevented. Some of the proposed solutions include the 466 use of EAP EMSK in the authentication exchange with the DHCP server, 467 or the use of EAP to provide the certificates that SEND requires for 468 the authentication of Router Advertisements. Either approach means 469 that we are sure we are speaking at layer 3 to the services that we 470 authenticated at layer two. However, this does not prevent an 471 attacker from offering such services, and then performing a NAT on 472 the packets later. However, IPsec could be used to detect the 473 presence of such NATs, even if NAT traversal is in use. 475 2.5 Discovery, Decision, and Selection 477 An alternative decomposition of the problem is to consider the 478 discovery, decision, and selection aspects separately. Discovery 479 consists of discovering access networks and associated POPs, 480 discovering what identities the access networks will accept (either 481 directly or through roaming relationships), and discovering which 482 potential AAA intermediaries or routes exist. 484 Selection consists of attaching to the "right" access network and 485 POP, offering an identity through EAP Identity Response, and 486 providing a hint about the desired AAA intermediary. The selection 487 of the AAA intermediary, along with the home and access networks, 488 determines also the treatment of payload packets. 490 Decision can be either manual selection or automatic. Most likely, 491 automatic mechanisms are preferred, even if manual selection should 492 be retained as a fallback. The type of the decision also places 493 additional requirements on the type of information that the discovery 494 phase must provide. Just knowing which choices are available is 495 probably enough for manual selection. Unfortunately, automatic 496 selection based on a list of choices is by itself not possible: 498 o Some access networks may be preferred over others. For instance, 499 the user's private corporate network may be preferred over a 500 public network due to cost and efficiency reasons. 502 o Similarly, some credentials may be preferred over others. 504 o Use of an access network with direct connection to home network 505 may be preferred over using mediating networks. 507 o Some mediating networks may be preferred to others, most likely 508 based on cost. Note that optimizing cost is not a trivial 509 problem, because the total cost may be a combination of a fixed 510 fee, per-minute, per-megabyte, volume discounts, and so on. 512 o Preferences may come from the user, his or her employer (who's 513 paying the bill), home network, or access network. 515 Different discovery mechanisms can accommodate such preferences in 516 various ways. Some user input or perhaps a pre-provisioned database 517 seems inevitable. 519 3. Design Constrains 521 All solutions to the network selection and discovery problem must 522 satisfy the following additional constraints: 524 o AAA routing mechanisms have to work for requests, responses, as 525 well as server-initiated messages. 527 o Solution is compatible with all AAA protocols. 529 o Does not prevent the introduction of new AAA or access network 530 features, such as link-state AAA routing protocols or fast 531 handoffs. 533 o Does not consume a significant amount of resources, such as 534 bandwidth or increase network attachment time. 536 o Does not cause a problem with limited packet sizes of current 537 protocols. 539 o Where new protocol mechanisms are required, it should be possible 540 to deploy the solution without requiring changes to the largest 541 base of installed devices -- network access servers, wireless 542 access points, and clients. 544 o Similarly, new solutions should allow interoperability with 545 clients, access networks, AAA proxies, and AAA servers that have 546 not been modified to support network discovery and selection. 548 4. Existing Work 550 4.1 IETF 552 There has already been a lot of past work in this area, including a 553 number of IETF Proposed Standards generated by the ROAMOPS WG. The 554 topic of roaming was considered different enough from both AAA and 555 access protocols such as PPP that it deserved its own WG. 557 In addition to work on ROAMOPS directly relating to the problem, 558 there has been work in SEAMOBY relating to scaling of network 559 discovery mechanisms; work in PKIX relating to identity and 560 credential selection; and work in AAA WG relating to access routing. 562 The PANA protocol [14] has a mechanism to advertise and select "ISPs" 563 through the exchange of the ISP-Information AVP in its initial 564 exchange. 566 Adrangi et al [16] discuss the use of the EAP-Request/Identity for 567 network discovery. As noted in [10] Section 3.1, the minimum EAP MTU 568 is 1020 octets, so that an EAP-Request/Identity is only guaranteed to 569 be able to include 1015 octets within the Type-Data field. Since RFC 570 1035 [1] enables FQDNs to be up to 255 octets in length, this may not 571 enable the announcement of very many networks, although if SSIDs are 572 used, the maximum length of 32 octets per SSID may provide 573 substantially better scaling. The use of other network identifiers 574 than domain names is also possible, for instance the PANA protocol 575 uses an a free form string and an SMI Network Management Private 576 Enterprise Code [14], or Mobile Network Codes could be used as hinted 577 in [16]. 579 As noted in [30], the use of the EAP-Request/Identity for network 580 discovery has substantial negative impact on handoff latency, since 581 this may result in a station needing to initiate an EAP conversation 582 with each Access Point in order to receive an EAP-Request/Identity 583 describing which networks are supported. Since IEEE 802.11-1999 does 584 not support use of Class 1 data frames in State 1 (unauthenticated, 585 unassociated) within an ESS, this implies either that the APs must 586 support 802.1X pre-authentication (optional in IEEE 802.11i) or that 587 the station must associate with each AP prior to sending an 588 EAPOL-Start to initiate EAP. This will dramatically increase handoff 589 latency. 591 The effects to handoff latency depend also on the specific protocol 592 design, and the expected likelihood of having to provide 593 advertisements and initiate scanning of several access points. The 594 use of advertisements only as a last resort when the AAA routing has 595 failed is a better approach than the use of advertisement - scanning 596 procedure on every attachment. 598 Furthermore, if the AP has not been updated to present an up to date 599 set of networks in the EAP-Requests/Identity, after associating to 600 candidate APs and then choosing one, it is possible that the station 601 will find that the chosen network is not supported after all. In 602 this case, the station's EAP-Response/Identity may be answered with 603 an updated EAP-Request/Identity, adding yet more latency. 605 4.2 IEEE 607 There has been work in IEEE 802.11 and 802.1 relating to network 608 discovery enhancements. 610 Some recent contributions in this space include the following: 612 o [18] defines the Beacon and Probe Response mechanisms used with 613 IEEE 802.11. Unfortunately, Beacons are only sent at the lowest 614 supported rate. Studies such as [31] have identified MAC layer 615 performance problems, and [28] have identified scaling issues 616 resulting from a lowering of the Beacon interval. 618 o [21] discusses the evolution of authentication models in WLANs, 619 and the need for the network to migrate from existing models to 620 new ones, based on either EAP layer indications or through the use 621 of SSIDs to represent more than the local network. It notes the 622 potential need for management or structuring of the SSID space. 624 The paper also notes that virtual APs have scalability issues. It 625 does not analyze these scalability issues in relation to those 626 existing in other alternative solutions, however. 628 o [22] discusses requirements for differentiation in the way that 629 the user's payload traffic is routed, based on home network 630 control. Such requirements have come up, for instance, in the 631 context of 3GPP. 633 o [19] discusses mechanisms currently used to provide "Virtual AP" 634 capabilities within a single physical access point. A "Virtual 635 AP" appears at the MAC and IP layers to be distinct physical AP. 636 As noted in the paper, full compatibility with existing 802.11 637 station implementations can only be maintained if each virtual AP 638 uses a distinct MAC address (BSSID) for use in Beacons and Probe 639 Responses. This draft does not discuss scaling issues in detail, 640 but recommends that only a limited number of virtual APs be 641 supported by a single physical access point. The simulations 642 presented in [28] appear to confirm this conclusion; with a Beacon 643 interval of 100 ms, once more than 8 virtual APs are supported on 644 a single channel, more than 20% of bandwidth is used for Beacons 645 alone. This would indicate a limit of approximately 20 virtual 646 APs per physical AP. 648 4.3 3GPP 650 The 3GPP technical specification [23] covers the interworking of WLAN 651 networks with 2G and 3G networks. This specification discusses also 652 network discovery and selection issues. 654 The specification requires that Access Network Discovery is performed 655 as specified in the standards for the relevant WLAN link layer 656 technology. An early version of the technical specification required 657 the use of a 3GPP-specific SSID, but that has since then been 658 abandoned; access network or local 3GPP network based SSIDs may be 659 used instead. It has not been decided whether some conventions on 660 the format of these SSIDs is required by 3GPP. 662 In addition to Access Network Discovery, it is necessary to select 663 intermediary networks for the purposes of AAA Routing. In 3GPP, 664 these networks are called Visited Public Land-based Mobile Networks 665 (VPLMNs), and it is assumed that WLAN networks may have a contract 666 with more than one VPLMN. GSM/UMTS roaming mechanisms are then 667 employed for routing AAA requests from the VPLMN to the home network. 669 In order to select the VPLMN, the following is required: 671 o User can choose the desired VPLMN. 673 o AAA message are routed according to the NAI. 675 o Existing EAP mechanisms are used where possible. 677 o Extensibility is desired, to allow the advertisement of other 678 parameters later. 680 The referenced 3GPP technical specification is a so called stage 2 681 specification, and contains only the principles of operation, leaving 682 detailed protocol work for later. Nevertheless, the specification 683 states that advertisement information shall be provided only when the 684 access network is unable to route the request using normal AAA 685 routing means, such as when it sees an unknown NAI domain. It is 686 also stated that where VPLMN control is required, the necessary 687 information is added to a NAI. 689 The security properties related to different mediating network 690 selection mechanisms have been discussed in the 3GPP contribution 692 [24], which concludes that both SSID- and EAP-based mechanisms have 693 roughly similar (and very limited) security properties, and that, as 694 a result, network advertisement should be considered only as hints. 696 Ahmavaara, Haverinen, and Pichna [26] discuss the new network 697 selection requirements that 3G-WLAN roaming introduces. It is 698 necessary to support automatic network selection, and not just manual 699 selection by the user. There may be multiple levels of networks, the 700 hotspot owner may have a contract with a provider who in turn has a 701 contract with one 3G network, and this 3G network has a roaming 702 capability with a number of other networks. 704 4.4 Other 706 [27] discusses the need for network selection in a situation where 707 there is more than one available access network with a roaming 708 agreement to the home network. It also lists EAP-level, SSID-based, 709 and PEAP-based mechanisms as potential solutions to the network 710 selection problem. 712 Eijk et al [25] discussed the general issue of network selection. 713 They concentrated primarily on the Access Network Discovery problem, 714 based on various criteria, and did not consider the other aspects of 715 the network selection problem. Nevertheless, they mention that one 716 of the network selection problems is that the information about 717 accessibility and roaming relationships is not stored in one 718 location, but rather spread around the network. 720 5. Conclusions 722 The issues surrounding the network discovery and selection problem 723 have been summarized. 725 In the opinion of the editors of this document, the main findings 726 are: 728 o There is a clear need for access network discovery, identifier 729 selection, AAA routing, and payload routing. 731 o Existing mechanisms appear sufficient for the control of payload 732 routing, but there appears to be justification for enhanced 733 mechanisms relating to access network discovery, identifier 734 selection, and AAA routing. 736 o Nevertheless, many of the problems discussed in this draft are 737 very hard when one considers them in an environment that requires 738 a potentially large number of networks, fast handoffs, and 739 automatic decisions. 741 o The proliferation of multiple competing network discovery 742 technologies within IEEE 802, IETF, and 3GPP appears to a 743 significant problem going forward. In the absence of a clearly 744 defined solution to the problem it is likely that any or all of 745 these solutions will be utilized, resulting in industry 746 fragmentation and lack of interoperability. 748 In order to avoid this fate, it is strongly suggested that a 749 discussion be initiated between IETF and IEEE 802 in order to work 750 out the roles of the each organization in solving this problem, 751 and to invite 3GPP participation so that their requirements can be 752 fulfilled by the planned solutions. 754 o New link layers should be designed with facilities that enable the 755 efficient distribution of network advertisement information. 757 o Solving all problems with current link layers and existing network 758 access devices may not be possible. It may be useful to consider 759 a phased approach where only certain functions are provided now, 760 and the full functionality is provided when extensions to current 761 link layers become available. 763 We will briefly comment on the specific mechanisms related to network 764 discovery and selection: 766 o As noted in studies such as [31] and [28], the IEEE 802.11 Beacon/ 767 Probe Response mechanism has substantial scaling issues, and as a 768 result a single physical access point is in practice limited to 769 less than a dozen virtual APs on each channel with IEEE 802.11b. 771 The situation is improved substantially with successors such as 772 IEEE 802.11a which enable additional channels, thus potentially 773 increasing the number of potential virtual APs. 775 However, even these enhancements it is not feasible to advertise 776 more than 50 different networks using existing mechanisms, and 777 probably significantly less in most circumstances. 779 As a result, there appears to be justification for enhancing the 780 scalability of network advertisements. 782 o Work is already underway in IEEE 802.1 to provide enhanced 783 discovery functionality. For example, IEEE 802.1ab enables 784 network devices to announce themselves and provide information on 785 their capabilities. Similarly, the IEEE 802.1af has discussed the 786 idea of supporting network discovery within a future revision to 787 IEEE 802.1X. However, neither IEEE 801.ab nor IEEE 802.1af is 788 likely to address the transport of large quantities of data where 789 fragmentation would be a problem. 791 o Given that EAP does not support fragmentation of EAP-Request/ 792 Identity packets, and that use of EAP for network selection on all 793 attachments will have a very substantial adverse impact on roaming 794 performance without appropriate lower layer support (such as 795 support for Class 1 data frames within IEEE 802.11), the use of 796 EAP is at best limited. Long-term, it makes more sense for the 797 desired functionality to be handled either within IEEE 802 or at 798 the IP layer. 800 o In the IETF, a potential alternative is use of the SEAMOBY CARD 801 protocol [13], which enables advertisement of network device 802 capabilities over IP. Another alternative is the recently 803 proposed Device Discovery Protocol (DDP) [12], which provides 804 functionality equivalent to IEEE 802.1ab using ASN.1 encoded 805 advertisements sent to a link-local scope multicast address. 807 A limitation of these IP layer solutions is that they can only 808 work as a means to speed up the attachment procedures when moving 809 from one location to another; when a node starts up, it needs to 810 be able to attach to a network before IP communications are 811 available. This is fine for optimizations, but precludes the use 812 in a case where the discovery information is mandatory before 813 successful attachment can be accomplished, for instance when the 814 access network is unable to route the AAA request unaided. 816 o "Phone-book" based approaches such as RFC 3017 appear attractive 817 due to their ability to provide sufficient information for 818 automatic selection decisions. However, there is no experience on 819 applying such approaches to wireless access. The number of WLAN 820 access points is significantly higher than the number of dial-in 821 POPs; the distributed nature of the access network has created a 822 more complicated business and roaming structure, and the expected 823 rate of change in the information is high. 825 Finally, to address some of the security concerns that have come up 826 during this work, the IETF should in any case initiate work that 827 enables support for channel bindings in methods. Preferably, popular 828 methods should be updated, ensuring compatibility with existing 829 deployments. The representation of link layer parameters within EAP 830 should utilize a common framework, to make it easier to define new 831 link layers and keep the selection of EAP methods independent of the 832 link layer. 834 6. Security Considerations 836 All aspects of the network discovery and selection problem are 837 security related. The security issues and requirements have been 838 discussed in the previous sections. 840 The security requirements for network discovery depend on the type of 841 information being discovered. Some of the parameters may have a 842 security impact, such as the claimed name of the network the user 843 tries to attach to. Unfortunately, current EAP methods do not always 844 make the verification of such parameters possible. 846 The security requirements for network selection depend on whether the 847 selection is considered as a command or a hint. For instance, the 848 selection that the user provided may be ignored if it relates to AAA 849 routing and the access network can route the AAA traffic to the 850 correct home network using other means in any case. 852 Normative References 854 [1] Mockapetris, P., "Domain names - implementation and 855 specification", STD 13, RFC 1035, November 1987. 857 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 858 Levels", BCP 14, RFC 2119, March 1997. 860 [3] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, "Review of 861 Roaming Implementations", RFC 2194, September 1997. 863 [4] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 864 2486, January 1999. 866 [5] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 867 Implementation in Roaming", RFC 2607, June 1999. 869 [6] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 870 Authentication Dial In User Service (RADIUS)", RFC 2865, June 871 2000. 873 [7] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and 874 I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 875 2868, June 2000. 877 [8] Riegel, M. and G. Zorn, "XML DTD for Roaming Access Phone 878 Book", RFC 3017, December 2000. 880 [9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, 881 "Diameter Base Protocol", RFC 3588, September 2003. 883 [10] Blunk, L., "Extensible Authentication Protocol (EAP)", 884 draft-ietf-eap-rfc2284bis-07 (work in progress), December 2003. 886 [11] Housley, R. and T. Moore, "Certificate Extensions and 887 Attributes Supporting Authentication in PPP and Wireless LAN", 888 draft-ietf-pkix-wlan-extns-04 (work in progress), December 889 2002. 891 Informative References 893 [12] Enns, R., Marques, P. and D. Morrell, "Device Discovery 894 Protocol (DDP)", draft-marques-ddp-00 (work in progress), May 895 2003. 897 [13] Liebsch, M., "Candidate Access Router Discovery", 898 draft-ietf-seamoby-card-protocol-05 (work in progress), 899 November 2003. 901 [14] Forsberg, D., "Protocol for Carrying Authentication for Network 902 Access (PANA)", draft-ietf-pana-pana-02 (work in progress), 903 October 2003. 905 [15] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 906 draft-ietf-ipsec-ikev2-07 (work in progress), April 2003. 908 [16] Adrangi, F., "Network Discovery and Selection within the EAP 909 Framework", 910 draft-adrangi-eap-network-discovery-and-selection-00 (work in 911 progress), October 2003. 913 [17] Institute of Electrical and Electronics Engineers, "Local and 914 Metropolitan Area Networks: Port-Based Network Access Control", 915 IEEE Standard 802.1X, September 2001. 917 [18] Institute of Electrical and Electronics Engineers, "Wireless 918 LAN Medium Access Control (MAC) and Physical Layer (PHY) 919 Specifications", IEEE Standard 802.11, 1999. 921 [19] Aboba, B., "Virtual Access Points", IEEE Contribution 922 11-03-154r1, May 2003. 924 [20] Mishra, A., "Improving the latnecy of the Probe Phase during 925 802.11 Handoff", IEEE Contribution 11-03-417r2, May 2003. 927 [21] Hepworth, E., "Co-existence of Different Authentication 928 Models", IEEE Contribution 11-03-0827 2003. 930 [22] Hong, C. and T. Yew, "Interworking - WLAN Control", IEEE 931 Contribution 11-03-0843 2003. 933 [23] 3GPP, "3GPP System to Wireless Local Area Network (WLAN) 934 interworking; System Description; Release 6", 3GPP Draft 935 Technical Specification 23.234 v 2.2.0, December 2003. 937 [24] Ericsson, "Security of EAP and SSID based network 938 advertisements", 3GPP Contribution S3-030736, November 2003. 940 [25] Eijk, R., Brok, J., Bemmel, J. and B. Busropan, "Access Network 941 Selection in a 4G Environment and the Role of Terminal and 942 Service Platform", 10th WWRF, New York, October 2003. 944 [26] Ahmavaara, K., Haverinen, H. and R. Pichna, "Interworking 945 Architecture between WLAN and 3G Systems", IEEE Communications 946 Magazine, November 2003. 948 [27] Intel, "Wireless LAN (WLAN) End to End Guidelines for 949 Enterprises and Public Hotspot Service Providers", November 950 2003. 952 [28] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b 953 MAC Layer Handover Time", Laboratory for Communication 954 Networks, KTH, Royal Institute of Technology, Stockholm, 955 Sweden, TRITA-IMIT-LCN R 03:02, April 2003. 957 [29] Judd, G. and P. Steenkiste, "Fixing 802.11 Access Point 958 Selection", Sigcomm Poster Session 2002. 960 [30] Eronen, P., "Network Selection Issues", presentation to EAP WG 961 at IETF 58, November 2003. 963 [31] Heusse, M., "Performance Anomaly of 802.11b", LSR-IMAG 964 Laboratory, Grenoble, France, IEEE Infocom 2003. 966 Authors' Addresses 968 Jari Arkko 969 Ericsson 971 Jorvas 02420 972 Finland 974 EMail: jari.arkko@ericsson.com 976 Bernard Aboba 977 Microsoft 978 One Microsoft Way 979 Redmond, WA 98052 980 USA 982 EMail: aboba@internaut.com 984 Appendix A. Contributors 986 This draft is based on the discussion held on the EAP WG mailing list 987 in December 2003, and on a number of input documents such as [16]. 988 The editors of this document would like to especially acknowledge the 989 contributions of Farid Adrangi, Farooq Bari, Michael Richardson, Pasi 990 Eronen, Mark Watson, Mark Grayson, Johan Rune, and Tomas 991 Goldbeck-Lowe. 993 Intellectual Property Statement 995 The IETF takes no position regarding the validity or scope of any 996 intellectual property or other rights that might be claimed to 997 pertain to the implementation or use of the technology described in 998 this document or the extent to which any license under such rights 999 might or might not be available; neither does it represent that it 1000 has made any effort to identify any such rights. Information on the 1001 IETF's procedures with respect to rights in standards-track and 1002 standards-related documentation can be found in BCP-11. Copies of 1003 claims of rights made available for publication and any assurances of 1004 licenses to be made available, or the result of an attempt made to 1005 obtain a general license or permission for the use of such 1006 proprietary rights by implementors or users of this specification can 1007 be obtained from the IETF Secretariat. 1009 The IETF invites any interested party to bring to its attention any 1010 copyrights, patents or patent applications, or other proprietary 1011 rights which may cover technology that may be required to practice 1012 this standard. Please address the information to the IETF Executive 1013 Director. 1015 Full Copyright Statement 1017 Copyright (C) The Internet Society (2004). All Rights Reserved. 1019 This document and translations of it may be copied and furnished to 1020 others, and derivative works that comment on or otherwise explain it 1021 or assist in its implementation may be prepared, copied, published 1022 and distributed, in whole or in part, without restriction of any 1023 kind, provided that the above copyright notice and this paragraph are 1024 included on all such copies and derivative works. However, this 1025 document itself may not be modified in any way, such as by removing 1026 the copyright notice or references to the Internet Society or other 1027 Internet organizations, except as needed for the purpose of 1028 developing Internet standards in which case the procedures for 1029 copyrights defined in the Internet Standards process must be 1030 followed, or as required to translate it into languages other than 1031 English. 1033 The limited permissions granted above are perpetual and will not be 1034 revoked by the Internet Society or its successors or assignees. 1036 This document and the information contained herein is provided on an 1037 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1038 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1039 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1040 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1041 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1043 Acknowledgement 1045 Funding for the RFC Editor function is currently provided by the 1046 Internet Society.