RFC 5113

Network Discovery and Selection Problem

📅 published January 2008, from ietf

RFC 5113: Network Discovery and Selection Problem 🦋

Okay bestie, this is RFC 5113, called Network Discovery and Selection Problem. It's an Informational doc from the Network Working Group, dated January 2008. The authors are J. Arkko (Ericsson), B. Aboba (Microsoft), J. Korhonen, Ed. (TeliaSonera), and F. Bari (AT&T). The title block doesn't list anything it obsoletes or updates, so no drama there 💅

Status of This Memo

This memo is here to inform the Internet community. It is not an Internet standard of any kind, and distribution is unlimited 🌸

Abstract

When there are multiple access networks around, users can get stuck figuring out which one to join and how to authenticate to it 😭 This document defines the network discovery and selection problem and breaks it into several sub-problems. It also lays out some constraints that any solution has to deal with, and talks through the limitations of a few solutions, including ones that already exist ✨

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology Used in This Document  . . . . . . . . . . . .  4
   2.  Problem Definition . . . . . . . . . . . . . . . . . . . . . .  7
     2.1.  Discovery of Points of Attachment  . . . . . . . . . . . .  8
     2.2.  Identity Selection . . . . . . . . . . . . . . . . . . . .  9
     2.3.  AAA Routing  . . . . . . . . . . . . . . . . . . . . . . . 11
       2.3.1.  The Default Free Zone  . . . . . . . . . . . . . . . . 13
       2.3.2.  Route Selection and Policy . . . . . . . . . . . . . . 14
       2.3.3.  Source Routing . . . . . . . . . . . . . . . . . . . . 15
     2.4.  Network Capabilities Discovery . . . . . . . . . . . . . . 17
   3.  Design Issues  . . . . . . . . . . . . . . . . . . . . . . . . 18
     3.1.  AAA Routing  . . . . . . . . . . . . . . . . . . . . . . . 18
     3.2.  Backward Compatibility . . . . . . . . . . . . . . . . . . 18
     3.3.  Efficiency Constraints . . . . . . . . . . . . . . . . . . 19
     3.4.  Scalability  . . . . . . . . . . . . . . . . . . . . . . . 19
     3.5.  Static Versus Dynamic Discovery  . . . . . . . . . . . . . 21
     3.6.  Security . . . . . . . . . . . . . . . . . . . . . . . . . 21
     3.7.  Management . . . . . . . . . . . . . . . . . . . . . . . . 22
   4.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 23
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   6.  Informative References . . . . . . . . . . . . . . . . . . . . 26
   Appendix A.  Existing Work . . . . . . . . . . . . . . . . . . . . 32
     A.1.  IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     A.2.  IEEE 802 . . . . . . . . . . . . . . . . . . . . . . . . . 33
     A.3.  3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
     A.4.  Other  . . . . . . . . . . . . . . . . . . . . . . . . . . 36
   Appendix B.  Acknowledgements  . . . . . . . . . . . . . . . . . . 37

1. Introduction ✨

Right now, network access clients usually come pre-loaded with a list of access networks, plus the matching identities and credentials. But access mechanisms and operators have multiplied like crazy, so users are increasingly likely to run into networks that have zero pre-configured settings. Those networks might still offer the services they want and let them authenticate with their home realm 👀 Pre-configured settings can also just not be good enough in some situations. When that happens, users can struggle to figure out which network to connect to and how to authenticate to it 😩

The problem shows up when any of the following conditions are true:

  • Within a single network, more than one network attachment point is available, and those attachment points differ in their roaming arrangements or in the services they can access. The link layer capabilities of an attachment point may be advertised, but higher-layer capabilities, like roaming arrangements, end-to-end quality of service, or Internet access restrictions, may not be. So a user may have a hard time figuring out which services are available at each attachment point, and which ones it can successfully authenticate to. For example, a roaming agreement might only let a user authenticate to the home realm from some attachment points and not others. Similarly, Internet access might be restricted at some attachment points but not others, or end-to-end quality of service might not be available everywhere. In these situations, the network access client cannot assume that all attachment points within a network offer identical capabilities 🙅‍♀️
  • Multiple networks are available, and the user has no corresponding pre-configuration for them. The user may not have set up an identity and matching credentials for a network, yet the user's home realm might be reachable from that network, which would make successful authentication possible. But unless the roaming arrangements are advertised, the network access client cannot determine a priori whether successful authentication is likely. In this case, the user might need to try multiple networks to find one it can authenticate to, or the user might not be able to get access at all, even though successful authentication is feasible 😤
  • The user has multiple sets of credentials. Where no pre-configuration exists, the user may not be able to tell which credentials to use with which attachment point, or even whether any of its credentials will let it authenticate successfully. An identity and its credentials can be usable with multiple networks, and not all of those networks will be pre-configured. For example, the user could have one set of credentials from a public service provider and another from an employer, and a network might allow authentication with one or more of them. But without pre-configuration, it could take multiple failed authentication attempts at each attachment point to work out which credentials are usable. That wastes valuable time and leads to real user frustration 💀 To choose between multiple attachment points, it can help to provide additional information so the correct credentials can be determined 🧚
  • There are multiple potential roaming paths between the visited realm and the user's home realm, and service parameters or pricing differ between them. In this situation, there could be several ways for the user to authenticate successfully using the same identity and credentials, but the cost of each approach might be different. The access network may not be able to figure out which roaming path best matches the user's preferences. That can lead to the user being charged more than necessary, or not getting the services they wanted. For example, the visited access realm could have a direct relationship with the home realm and also an indirect relationship through a roaming consortium. Current Authentication, Authorization, and Accounting (AAA) protocols may not be able to route the access request to the home AAA sever purely based on the realm within the Network Access Identifier (NAI) [RFC4282]. On top of that, payload packets can be routed or tunneled differently depending on the roaming relationship path, which may affect the available services or their pricing 💸

In Section 2, the network discovery and selection problem is defined and divided into sub-problems. Some solution constraints are outlined in Section 3. Section 4 provides conclusions and suggestions for future work. Appendix A discusses existing solutions to portions of the problem 📚

1.1. Terminology Used in This Document

Okay bestie, first things first 💅 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc mean exactly what [RFC2119] says they mean 🫶

Now the glossary, the vocab list you need to know before anything else makes sense ✨

Authentication, Authorization, and Accounting (AAA)

AAA protocols with EAP support include Remote Authentication Dial-In User Service (RADIUS) [RFC3579] and Diameter [RFC4072] 🎀

Access Point (AP)

An entity that has station functionality and provides access to distribution services via the wireless medium (WM) for associated stations 📡

Access Technology Selection

This is the choice between access technologies, e.g., 802.11, Universal Mobile Telecommunications System (UMTS), WiMAX. The selection depends on which access technologies the device supports and on which networks supporting those technologies are available 🌈

Bearer Selection

For some access technologies (e.g., UMTS), a service (e.g., voice) can be delivered over either a circuit-switched or a packet-switched bearer. Bearer selection means picking one of those bearer types for delivering the service. The decision can be based on whether the device and the network support the bearer type, as well as user subscription and operator preferences 💜

Basic Service Set (BSS)

A set of stations controlled by a single coordination function 🌸

Decorated NAI

A NAI specifying a source route. See Section 2.7 of RFC 4282 [RFC4282] for more information 🦋

Extended Service Set (ESS)

A set of one or more interconnected basic service sets (BSSs) with the same Service Set Identifier (SSID) and integrated local area networks (LANs). To any station associated with one of those BSSs, it appears as a single BSS to the logical link control layer. This is a mechanism a node uses to discover the networks that are reachable from a given access network 🧚

Network Access Identifier (NAI)

The Network Access Identifier (NAI) [RFC4282] is the user identity the client submits during network access authentication. In roaming, the NAI's job is to identify the user and also to help route the authentication request. Heads up though: the NAI may not necessarily be the same as the user's e-mail address or the user identity submitted in an application layer authentication 🙈

Network Access Server (NAS)

The device that peers connect to in order to get access to the network. In Point-to-Point Tunneling Protocol (PPTP) terminology, this is called the PPTP Access Concentrator (PAC), and in Layer 2 Tunneling Protocol (L2TP) terminology, it is called the L2TP Access Concentrator (LAC). In IEEE 802.11, it is called an Access Point (AP) 🍓

Network Discovery

The mechanism used to discover available networks. The discovery mechanism may be passive or active, and it depends on the access technology. In passive network discovery, the node listens for network announcements. In active network discovery, the node solicits network announcements. An access technology can use both passive and active network discovery mechanisms 👀

Network Selection

Selecting an operator/ISP for network access. Network selection happens before network access authentication ⭐

Realm

The realm portion of an NAI [RFC4282] 🩷

Realm Selection

Selecting the realm (and the corresponding NAI) used to access the network. A realm can be reachable from more than one access network type, and choosing a realm may not enable any network capabilities 💅

Roaming Capability

Roaming capability can be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs) while keeping a formal, customer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support 🌍

Station (STA)

A device that contains an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM) 📶

2. Problem Definition ✨

The network discovery and selection problem can be broken down into multiple sub-problems, and honestly it's a lot 😭 These include:

  • Discovery of points of attachment. This involves the discovery of points of attachment in the vicinity, as well as their capabilities.
  • Identifier selection. This involves selection of the NAI (and credentials) used to authenticate to the selected point of attachment.
  • AAA routing. This involves routing of the AAA conversation back to the home AAA server, based on the realm of the selected NAI.
  • Payload routing. This involves the routing of data packets, in the situation where mechanisms more advanced than destination-based routing are required. While this problem is interesting, it is not discussed further in this document.
  • Network capability discovery. This involves discovering the capabilities of an access network, such as whether certain services are reachable through the access network and the charging policy.

Alternatively, the problem can be divided into discovery, decision, and selection components. The AAA routing problem, for instance, involves all components: discovery (which mediating networks are available), decision (choosing the "best" one), and selection (selecting which mediating network to use) components 🔥

2.1. Discovery of Points of Attachment

Traditionally, the discovery of points of attachment has been handled by out-of-band mechanisms or link or network layer advertisements 🌸

[RFC2194] describes the pre-provisioning of dial-up roaming clients (it's giving old-school dial-up vibes 📞). That typically included a list of potential phone numbers, updated by the provider(s) the client had a contractual relationship with. RFC 3017 [RFC3017] describes the IETF Proposed Standard for the Roaming Access eXtensible Markup Language (XML) Document Type Definition (DTD). This covers not only the attributes of the Points of Presence (PoP) and Internet Service Providers (ISPs), but also hints on the appropriate NAI to use with a particular PoP. The XML DTD supports dial-in and X.25 access, but has extensible address and media type fields 🎀

As access networks and points of attachment have multiplied, out-of-band pre-configuration has become increasingly difficult 😩 For networks with many points of attachment, keeping a complete and up-to-date list can be hard. As a result, wireless network access clients typically only attempt to pre-configure information relating to access networks, rather than individual points of attachment 🫶

In IEEE 802.11 Wireless Local Area Networks (WLAN), the Beacon and Probe Request/Response mechanism gives Stations a way to discover Access Points (AP) and the capabilities of those APs. The IEEE 802.11 specification [IEEE.802.11-2003] supports both passive (Beacon) and active (Probe Request/Response) discovery mechanisms, and [Fixingapsel] studied how effective these mechanisms are 🧐

Among the Information Elements (IE) included in the Beacon and Probe Response is the Service Set Identifier (SSID), a non-unique identifier of the network an AP is attached to. So the Beacon/Probe facility enables network discovery, as well as the discovery of points of attachment and the capabilities of those points of attachment ✨

The Global System for Mobile Communications (GSM) specifications also provide for discovery of points of attachment, as does the Candidate Access Router Discovery (CARD) [RFC4066] protocol developed by the IETF SEAMOBY Working Group (WG) 🌈

Along with discovery of points of attachment, the capabilities of access networks are also typically discovered. These may include:

  • Access network name (e.g., IEEE 802.11 SSID)
  • Lower layer security mechanism (e.g., IEEE 802.11 Wired Equivalent Privacy (WEP) vs. Wi-Fi Protected Access 2 (WPA2))
  • Quality of service capabilities (e.g., IEEE 802.11e support)
  • Bearer capabilities (e.g., circuit-switched, packet-switched, or both)

Even though pre-configuration of access networks scales better than pre-configuration of points of attachment, where many access networks can be used to authenticate to a home realm, providing complete and up-to-date information on each access network can be challenging 🥺

So in that situation, network access client configuration can be minimized by providing information about each home realm, rather than each access network. One way to enable this is for an access network to support "virtual Access Points" (virtual APs), and for each point of attachment to support virtual APs corresponding to each reachable home realm. It's giving main character energy for the realm, not the network 👑

While a single IEEE 802.11 network may only utilize a single SSID, it may cover a wide geographical area, and as a result, may be segmented, utilizing multiple prefixes. It is possible that a single SSID may be advertised on multiple channels, and may support multiple access mechanisms (including Universal Access Method (UAM) and IEEE 802.1X [IEEE.8021X-2004]), which may differ between points of attachment. A single SSID may also support dynamic VLAN access as described in [RFC3580], or may support authentication to multiple home AAA servers supporting different realms. As a result, users of a single point of attachment, connecting to the same SSID, may not have the same set of services available. Lowkey chaotic, but that's networking 💀

2.2. Identity Selection 🎀

okay so bestie, as networks keep multiplying, it's getting more and more likely that a user has multiple identities and credential sets they can use in different situations 🌈. Like, you might have an account with one or more Public WLAN providers, a corporate WLAN, and one or more wireless Wide Area Network (WAN) providers. So many accounts, so little brain space 💀.

Usually the user picks an identity and its matching credential set based on whichever network they're on ✨. Sometimes the chosen authentication mechanism gives them a little hand with that too. For example, if Extensible Authentication Protocol - Transport Layer Security (EAP-TLS) is the authentication mechanism on a particular network, then the user picks the right EAP-TLS client certificate based, in part, on the list of trust anchors the EAP-TLS server hands over 🔐.

BUT (and it's a big but 😭), in access networks where roaming is turned on, the mapping between an access network and an identity/credential set might not be one to one. Multiple identities could work on one access network, or a single identity could work on just one access network, and that network might or might not be around. Messy but make it make sense 💅.

Check out Figure 1 below. It shows a situation where a user identity might not work on a potential access network 👀. Here, access network 1 lets in users within the realm "isp1.example.com", access network 3 lets in users within the realm "corp2.example.com", and access network 2 lets in users from both realms 🦋.

       ?  ?                 +---------+       +------------------+
        ?                   | Access  |       |                  |
        O_/             _-->| Network |------>|"isp1.example.com"|
       /|              /    |    1    |    _->|                  |
        |              |    +---------+   /   +------------------+
      _/ \_            |                 /
                       |    +---------+ /
User "subscriber@isp1. |    | Access  |/
  example.com"      -- ? -->| Network |
also known as          |    |    2    |\
  "employee123@corp2.  |    +---------+ \
  example.com"         |                 \
                       |    +---------+   \_  +-------------------+
                       \_   | Access  |     ->|                   |
                         -->| Network |------>|"corp2.example.com"|
                            |   3     |       |                   |
                            +---------+       +-------------------+

      Figure 1: Two credentials, three possible access networks

So here's the tea ☕. A user who only has an identity in the "corp2.example.com" realm can only successfully authenticate to access networks 2 or 3 🏢. A user with an identity in the "isp1.example.com" realm can only successfully authenticate to access networks 1 or 2 📡. And a user with identities in both realms can connect to any of the access networks 👑. The real question is: how does the user figure out which access networks they can actually authenticate to, ideally before picking a point of attachment? 🤔

Traditionally, the hints that help with identity selection came out-of-band 📬. For example, the XML DTD described in [RFC3017] lets a client choose between potential points of attachment, and also pick the NAI and credentials to use when authenticating with it.

When every point of attachment in an access network lets you authenticate using a set of realms, picking an access network tells you which identities the client can use to successfully authenticate 🧚. For instance, in an access network, the set of supported realms that goes with a network name can be pre-configured.

Sometimes it isn't possible to figure out which access networks are available before authentication 😩. For example, [IEEE.8021X-2004] doesn't support network discovery on IEEE 802 wired networks, so the peer can't tell which access network it's connected to before the EAP exchange starts.

Hints can also be embedded right inside credentials 🎟️. In [RFC4334], usage hints are provided within certificates used for wireless authentication. This works by extending the client's certificate to include the SSIDs that the certificate can be used with.

BUT (again, bestie 😭), there may be situations where an access network can't accept a static set of realms at every point of attachment. For example, as part of a roaming agreement, only points of attachment within a given region or country might be available. In those cases, hints embedded in credentials or pre-configured access network to realm mappings might not be enough 🙈. Instead, the client needs to discover usable identities dynamically.

That's the problem RFC 4284 [RFC4284] tries to solve, using the EAP-Request/Identity to communicate a list of supported realms 🌸. The catch is that the problems with this approach are many, as discussed in Appendix A.1 💀.

Also, note that identity selection also means selecting different credentials and, potentially, different EAP authentication methods 🔥. In some situations this could create serious security vulnerabilities 😱. These are discussed in depth in Section 5, so go read that one, it's not optional, periodt 💅.

2.3. AAA Routing 🛣️

Once the identity has been selected, the AAA infrastructure needs to route the access request back to the home AAA server 🏠. Typically, the routing is based on the Network Access Identifier (NAI) defined in [RFC4282].

If the NAI doesn't encode a source route, the AAA infrastructure decides how requests get routed 🗺️. As described in [RFC2194], most roaming implementations are pretty simple. They rely on a static realm routing table that picks the next hop based on the NAI realm included in the User-Name attribute within the Access-Request. In RADIUS, the IP address of the home AAA server is typically determined by static mappings of realms to IP addresses kept within RADIUS proxies 📋.

Diameter [RFC3588] supports mechanisms for intra- and inter-domain service discovery 🔍. That includes support for DNS, plus service discovery protocols like Service Location Protocol version 2 (SLPv2) [RFC2608]. So it may not be necessary to configure static tables that map realms to the IP addresses of Diameter agents ✨. BUT, while this makes the AAA routing infrastructure easier to maintain, it doesn't necessarily make roaming-relationship path selection any easier 😩.

As noted in RFC 2607 [RFC2607], RADIUS proxies are deployed not just for routing, but also to mask a bunch of inadequacies in the RADIUS protocol design 🙄. Examples include the lack of standardized retransmission behavior and the need for shared secret provisioning between each AAA client and server.

Diameter [RFC3588] supports certificate-based authentication (using either TLS or IPsec), and it also has Redirect functionality 🦋. That lets a Diameter client get a referral to the home server from a Diameter redirect server, so the client can contact the home server directly. When a trust model can be established, these Diameter capabilities can shorten the roaming relationship path 🚀.

BUT in practice there are a number of pitfalls 💀. For certificate-based authentication to enable communication between a Network Access Server (NAS) or local proxy and the home AAA server, trust anchors need to be configured and certificates need to be selected 🔐. The AAA server certificate needs to chain to a trust anchor configured on the AAA client, and the AAA client certificate needs to chain to a trust anchor configured on the AAA server. When there are multiple potential roaming relationship paths, that shows up as multiple certificate choices, which turns the path selection problem into a certificate selection problem 😵‍💫. Depending on what the certificate selection implementation supports, this may not make things easier. For example, to get the control you want over the roaming path, you might need custom certificate selection logic, and that can be hard to add to a certificate handling implementation built for general-purpose use 🛠️.

As noted in [RFC4284], you can also use an NAI for source routing 🧭. In that case, the client guides the AAA infrastructure on how it would like the access request routed. An NAI that includes source-routing information is said to be "decorated", and the decoration format is defined in [RFC4282] 🎀.

When decoration is used, the EAP peer puts the decorated NAI in the EAP-Response/Identity, and as described in [RFC3579], the NAS copies that decorated NAI into the User-Name attribute of the access request 📨. As the access request travels along the roaming relationship path, AAA proxies pick the next hop based on the realm in the User-Name attribute, and they strip decoration off the NAI in the User-Name attribute as they go 🧹. Meanwhile, the decorated NAI inside the EAP-Response/Identity (encapsulated in the access request) stays untouched 🙌. So when the access request reaches the AAA home server, the decorated NAI in the EAP-Response/Identity may differ from the NAI in the User-Name attribute, which may have some or all of the decoration gone. For identity verification, the EAP server uses the NAI in the User-Name attribute, not the one in the EAP-Response/Identity 🔎.

Long term, the need for NAI "decoration" and source routing is expected to disappear 🌅. It's kind of like how email delivery evolved 📧. Before the Internet really took off, you had to gateway between SMTP-based mail systems and other delivery technologies, like Unix-to-Unix CoPy Protocol (UUCP) and FidoNet. Before email gateways started using MX RR routing, email address-based source-routing was used a lot. But over time, the need for email source-routing went away 💜.

2.3.1. The Default Free Zone

okay so AAA clients on the edge of the network, like NAS devices and local AAA proxies, usually keep a default realm route 💅 which gives them a default next hop for any realm that isn't in their realm routing table. this lets tiny, resource-limited devices keep a small realm routing table 🧚 deeper inside the AAA infrastructure, proxies may run a "default free" realm table instead. it lists next hops for all known realms, but it doesn't have a default realm route 🌸

dynamic realm routing protocols aren't used in AAA infrastructure today ✨ and even if they showed up, they'd probably only be deployed in the core AAA infrastructure and not on NAS devices, since NAS devices are typically resource constrained 💀

so NAS devices don't keep a full realm routing table, which means they don't know all the realms they can reach from the local network 🙈 this is giving the same vibe as Internet hosts or edge routers that don't take part in the BGP mesh. for an Internet host to find out whether it can reach a destination on the Internet, it has to send a packet to that destination and see what happens 🦋

same deal here. when a user hands the NAS an NAI, the NAS has no clue ahead of time whether the realm in that NAI is reachable 😭 it just forwards the access request to the next hop on the roaming relationship path. eventually the request reaches the "default free" zone, where a core AAA proxy figures out whether the realm is reachable. as described in [RFC4284], when EAP authentication is in use, the core AAA proxy can send an Access-Reject, or it can send an Access-Challenge that wraps up an EAP-Request/Identity containing "realm hints" based on what's in its "default free" realm routing table 🎀

this approach has a bunch of intrinsic problems, bestie 😩 if the "default free" routing table is huge, it might not fit in a single EAP packet, and the core AAA proxy might not have a way to pick the most promising entries to include 🫠 and even when the table would fit in one EAP-Request/Identity packet, the core AAA router might not want to include every entry. the list of realm routes could be seen as confidential and not appropriate to disclose to hosts that are trying to get network access 🔒 so it can't be assumed that the "realm hints" in the EAP-Request/Identity are complete. because of that, a NAS or local AAA proxy that snoops the EAP-Request/Identity can't rely on it for a complete list of reachable realms 💔 and the "realm hint" mechanism from [RFC4284] is not a dynamic routing protocol, periodt 💅

2.3.2. Route Selection and Policy

ngl this one is a whole mood too 💜 along with the lack of a dynamic AAA routing protocol, today's AAA infrastructure also lacks mechanisms for route selection and policy. so there can be multiple routes to a destination realm, and there's no way to pick a preferred one 🙃

in Figure 2, Roaming Groups 1 and 2 both have a route to the realm "a.example.com" ✨ but these realm routes aren't passed along to the NAS with their metrics attached. so there's no mechanism for dynamic routing policies, like picking the route with the shortest path or preferring routes that come from a given proxy 😤

                                       +---------+
                                       |         |----> "a.example.com"
                                       | Roaming |
                      +---------+      | Group 1 |
                      |         |----->| Proxy   |----> "b.example.com"
   user "joe@         | Access  |      +---------+
    a.example.com"--->| Provider|
                      |   NAS   |      +---------+
                      |         |----->|         |----> "a.example.com"
                      +---------+      | Roaming |
                                       | Group 2 |
                                       | Proxy   |----> "c.example.com"
                                       +---------+

                Figure 2: Multiple routes to a destination realm

so in that Figure 2 example, going through Roaming Group 1 might cost less than going through Roaming Group 2 🤑 which makes it desirable to prefer Roaming Group 1 as the next hop for an NAI with the realm "a.example.com" 👑 the only way to get that result is to manually configure the NAS realm routing table with these entries:

      Realm            Next Hop
      -----            --------
      b.example.com    Roaming Group 1
      c.example.com    Roaming Group 2
      Default          Roaming Group 1

manual config can be fine when the realm routing table is small and the entries are static 🌷 but when the list of supported realms changes a lot, or the preferences shift dynamically, manual configuration just isn't manageable 😵‍💫

2.3.3. Source Routing

because current AAA routing mechanisms have limits, sometimes NAI-based source routing gets used to nudge the roaming relationship path 🧭 however, the AAA proxies on that path are boxed in by existing relationships. so NAI-based source routing isn't source routing in the classic sense. it just suggests preferences, and the AAA proxy can totally choose to ignore them 🙅‍♀️

when realm routes are set up through pre-configuration and dynamic route establishment isn't supported, a missing realm route can't be created by NAI-based source routing 💔 even where dynamic route establishment is possible, like when the AAA client and server support certificate-based authentication and AAA servers can be discovered (for example through the mechanisms in [RFC3588]), an AAA proxy can still decide not to set up a realm route by starting discovery based on a suggestion in an NAI-based source route. rude, but valid 💅

and if the realm route does exist, or the AAA proxy can set it up on the fly, the AAA proxy can still decide not to authorize the client to use it 🚫

source routing can give users better control over AAA routing decisions in principle ✨ but there are a bunch of practical problems to fix first. to build optimal source routes, the client needs a complete and up-to-date realm routing table. but if someone had a solution for that problem that was easy to get, it could be applied to the AAA routing infrastructure too, which would let routes get picked without user intervention 🧠

as noted in [Eronen04], only a limited number of parameters can be updated dynamically 📉 for example, quality of service or pricing info usually gets pre-provisioned or posted on the web instead of being updated constantly. when realm names are shared dynamically, the "default free" realm list probably won't be sent in full, since that table could be pretty huge 😩 given these limits on what info is available, building source routes usually has to happen with incomplete knowledge.

there are also few ways to audit whether the requested source route is actually honored by the AAA infrastructure 👀 for example, an access network could advertise a realm route to "costsless.example.com" while secretly sending the access-request through "costsmore.example.com". the decorated NAI would show up for the home AAA server in the EAP-Response/Identity, but the home AAA server might have a hard time checking whether the source route in that decorated NAI was really honored 🕵️‍♀️ it could be just as hard to tell whether quality of service (QoS) or other routing requests were actually delivered as asked. to some extent, roaming partners might handle this through their business arrangements, which may include minimum service-level guarantees 🤝

so because source routing can be risky, conventional AAA routing mechanisms are to be preferred wherever possible 💖 when there's an error, like trying to authenticate to an unreachable realm, "realm hints" can be provided as described in [RFC4284]. but this approach has severe scalability limitations, as outlined in Appendix A.1 😬

2.4. Network Capabilities Discovery

okay now we're talking about network capabilities discovery 🌈 this one focuses on finding out the services networks offer, not just the capabilities of individual points of attachment. if you can get more info about what an access network is like, you can make a more informed access decision 🧁 the characteristics that might matter include:

  • Roaming relationships between the access network provider and other network providers, plus the associated costs. if the network access client isn't pre-configured with an identity and credentials for a local access network, it needs to be able to figure out whether one or more home realms are reachable from that access network, so authentication can actually succeed 🔑
  • EAP authentication methods. the EAP methods a home realm supports can only be found by contacting the home AAA server, but the local realm might support one or more EAP methods too 🌟 for example, a user might be able to use EAP-SIM (Extensible Authentication Protocol - Subscriber Identity Module) to authenticate directly to the access network, instead of having to authenticate to the home network 📱
  • End-to-end quality of service capability. local QoS capabilities usually get advertised by the access network (for example, support for Wi-Fi Multimedia (WMM)), but end-to-end QoS services might not be advertised at all 🎶
  • Service parameters, like whether there are middleboxes or firewalls in the way. if the network access client isn't told what kind of Internet access it'll get when it connects to a point of attachment, the user might not be able to reach the services they want 😤

reference [IEEE.11-04-0624] breaks down the possible steps where IEEE 802.11 networks can acquire this info:

  • Pre-association
  • Post-association (or pre-authentication)
  • Post-authentication

to keep connectivity delays low, all of the info needed for network selection (both access network capabilities and global characteristics) needs to be provided before authentication ⏱️

by the time authentication happens, the node has usually already picked the access network, the NAI it'll authenticate with, and the point of attachment 📍 but if it learns something during authentication that makes it want to change any of those choices, it has to pick a new network, point of attachment, and/or identity, and then go through authentication all over again. that's going to be time consuming and unreliable 🥲

3. Design Issues ✨

okay, bestie, here's the checklist 📝 the following factors should be taken into consideration while evaluating solutions to the problem of network selection and discovery 💅

3.1. AAA Routing ✨

okay so the AAA routing headaches from Section 2.3 need fixes that work for a huge range of AAA messages 💅 and they should not block new AAA or access network stuff from showing up later. like, AAA routing has to work for access requests and responses, accounting requests and responses, and server-initiated messages too 🫶 Solutions also can't lock out new AAA attributes, new access types, or perf upgrades like fast handoff support 🚀 no cap, that would be so limiting.

3.2. Backward Compatibility 🎀

bestie, solutions have to stay backward compatible 😭 specifically:

  • Selection-aware clients need to play nice with legacy NAS devices and AAA servers.
  • Selection-aware AAA infrastructure needs to play nice with legacy clients and NAS devices.

like, selection-aware clients should not send packets bigger than what legacy NAS devices or AAA servers can handle 🙈 and if a protocol extension has to exist, it should only need changes to as few infrastructure pieces as possible. extensions that force upgrades on existing NAS devices are way harder to roll out than ones you can deploy bit by bit by upgrading clients or AAA servers first 🧚 it's giving phased rollout energy.

3.3. Efficiency Constraints 🦋

solutions should be efficient in terms of channel utilization, bandwidth use, handoff delay, and energy use ⚡ mechanisms that lean on multicast frames need careful design, because multicast frames usually go out at the lowest supported rate 😬 that eats up a lot of channel time and a lot of energy for every node that's listening 🔋. depending on the deployment, bandwidth can be tight on the link and in the backend AAA infrastructure 💀 so chatty stuff like keepalives or periodic probe packets is to be avoided, full stop 🙅‍♀️. AAA servers handle a LOT of traffic, so solutions should also be mindful of piling on load, especially if that could open the door to denial-of-service attacks 🚨.

for example, it would be a bad idea for a NAS to keep sending probe EAP-Response/Identity packets to the AAA infrastructure just to grab "realm hints" (as described in [RFC4284]) so it can refresh its realm routing table 😭 that would add serious load to the AAA infrastructure, especially when the AAA server is already overloaded and dropping packets, which then makes the NAS retransmit 🌀. and even then, it still wouldn't give the NAS a complete realm routing table, for the reasons in Section 2.3 💔.

battery life is a big deal for handheld devices 🔋🫶 so mechanisms that significantly increase the packets sent, or the fraction of time the host has to listen (like anything requiring continuous scanning), are to be discouraged 🙅. also, the solution shouldn't noticeably slow down how long it takes to finish attaching to the network ⏱️.

3.4. Scalability 🌈

with limits on frame sizes and channel utilization, solutions need to scale less than linearly as the number of networks and realms goes up 📈 for instance, approaches like [RFC4284] make advertisements grow in proportion to the number of entries in the realm routing table 😵‍💫 that just doesn't scale to a big number of networks and realms.

same vibe with approaches that use a separate Beacon for each "virtual AP" 👻. they add Beacons in proportion to the number of networks being advertised 🙃. sure, it might keep the pre-configuration for network access clients low, but all those "virtual APs" can make the wireless medium super busy 🚦. the 802.11 Beacon only goes out at a rate within the basic rate set, which usually means the lowest supported rates, or maybe just the lowest one 🐢. so "virtual AP" mechanisms that need a separate Beacon for each "virtual AP" just don't scale well 💅.

let's do the math, it's giving nerd girl 🤓✨. with a Beacon interval of 100 Time Units (TUs) or 102.4 ms (9.8 Beacons/second), twenty 802.11b "virtual APs" each announcing their own 170-octet Beacon would give a channel utilization of 37.9 percent 😱. here's how that checks out:

  1. A single 170-octet Beacon sent at 1 Mbps uses the channel for 1360 us (1360 bits @ 1 Mbps) 🧮;
  2. add 144 us for the PLCP long preamble (144 bits @ 1 Mbps), 48 us for the PLCP header (48 bits @ 1 Mbps), 10 us for SIFS, 50 us for DIFS, and 320 us for the average minimum Contention Window without backoff (CWmin/2 * aSlotTime = 32/2 * 20 us), and a single Beacon takes up an 802.11b channel for 1932 us 🌸;
  3. multiply the channel time per Beacon by 196 Beacons/second and you get 378672 us/second = 37.9 percent 🎉 ICONIC math, no notes.

also, since each AP sends its Beacon/Probe Response frames over the wireless medium, stations can only discover APs that are within range 📡. that means there has to be a ton of coverage overlap so roaming can happen without interruption 🦋. another problem with the Beacon and Probe Request/Response mechanism is that it's either insecure, or its security can only be assured as part of authenticating to the network (for example, by verifying the advertised capabilities in the 4-way handshake) 🔐 not ideal, bestie.

people have proposed a bunch of enhancements to the Beacon/Probe Response mechanism to boost scalability and performance in roaming scenarios ✨. these include letting APs announce the capabilities of neighboring APs as well as their own [IEEE.802.11k] 🫶. there are also more scalable ways to support "virtual APs" within IEEE 802.11 [IEEE.802.11v], and those generally squish multiple "virtual AP" advertisements into one single advertisement 🧩.

higher-layer mechanisms can help scalability too 🙌. since they run over IP, they can use things like fragmentation that might not exist at the link layer 💜. for example, in IEEE 802.11, Beacon frames can't use fragmentation because they're multicast frames 🙃.

3.5. Static Versus Dynamic Discovery 🗺️

"Phone-book" approaches like [RFC3017] can hand over info for automatic selection decisions 📒. they've been used for wireless access, but they can usually only work well inside a single operator or a small roaming partner setup 🏠. for example, if a "Phone-Book" approach tried to pull in info from a huge number of roaming partners, keeping everything comprehensive and up to date would get really hard 😩. as noted in [Priest04] and [GROETING], a big chunk of current WLAN access points run on the default SSID, which can make it hard to tell roaming partner networks apart by SSID alone 🤷‍♀️. either way, in wireless networks, dynamic discovery is a practical must, since a node needs to know which APs are in range before it can connect 📶🔥.

3.6. Security 🔐

network discovery and selection can introduce brand-new security vulnerabilities 😈. as noted in Section 2.3.1, network operators may treat the AAA routing table as confidential, so they may not want to hand it to unauthenticated peers through the mechanism in RFC 4284 🤐. the peer could send a list of the realms it supports, with the authenticator picking one, but that raises privacy concerns 👀. since identity selection happens before authentication, the peer's supported realms would go out in cleartext, which lets an attacker figure out which realms a potential victim has credentials for 💀. you can reduce this risk by restricting peer disclosure 🛡️. for example, a peer might only disclose additional realms when an initially selected identity has proved unusable 🫶.

since network selection happens before authentication, it's usually not possible to secure network discovery or identity selection mechanisms 😭, although it may be possible to get secure confirmation after authentication is done ✅. for example, some parameters discovered during network discovery might be confirmable via EAP Channel Bindings, and others might be confirmed in a later Secure Association Protocol handshake 🦋.

BUT, there are situations where advertised parameters can't be confirmed 😱, and that could lead to "bidding down" vulnerabilities 📉. Section 7.8 of [RFC3748] says:

   Within or associated with each authenticator, it is not
   anticipated that a particular named peer will support a choice of
   methods.  This would make the peer vulnerable to attacks that
   negotiate the least secure method from among a set.  Instead, for
   each named peer, there SHOULD be an indication of exactly one
   method used to authenticate that peer name.  If a peer needs to
   make use of different authentication methods under different
   circumstances, then distinct identities SHOULD be employed, each
   of which identifies exactly one authentication method.

in practice, when the authenticator runs in "pass-through" mode, the EAP method negotiation happens between the EAP peer and server 🤝. so the peer needs to tie a single EAP method to a given EAP server 🎀. if several EAP servers and matching identities are reachable from the same selected network, the EAP peer might have trouble figuring out which identity (and matching EAP method) to use 😵. unlike network selection, which can be securely confirmed in a Secure Association Protocol handshake, identity selection hints sent in the EAP-Request/Identity are not secured 🙅‍♀️.

so, where the identity selection mechanism from RFC 4284 is used, an attacker could use those "hints" to trick the victim into picking an identity tied to a weaker EAP method (like EAP MD5-Challenge) 😈💔. one way to lower this risk is for the peer to only use EAP methods that satisfy the [RFC4017] security requirements, and for the peer to pick the identity tied to the strongest authentication method whenever there's a choice 💪👑.

3.7. Management 📋

from an ops point of view, a network device that controls network advertisement and provides "realm hints" to guide network discovery and selection should, at the very least, offer a management interface that gives status info to operators 🧑‍💻. status info like counters for each selected network and used realm, and (when RFC 4284 is used) the count of delivered "realm hints", is probably what operators want to see 📊. especially the info about realms that fall into the "default free zone" or the "AAA fails to route" case is super important 🚨.

bigger deployments would benefit from a management interface that allows full remote configuration, for example, of "realm hints" for RFC 4284-conforming network devices 🌐. changes to "realm hints" and realm routing info aren't expected to happen often, but centralized remote management tends to mean fewer misconfigured devices 💖✨.

4. Conclusions ✨

okay so this section is the authors' big takeaways 🧠 this document is about the network selection and discovery problem, and these are the main things they found 💅

  • There is a need for additional work on access network discovery, identifier selection, AAA routing, and payload routing. 🔥
  • Credential selection and AAA routing are aspects of the same problem, namely identity selection. 🫶
  • When considering selection among a large number of potential access networks and points of attachment, the issues described in the document become much harder to solve in an automated way, particularly if there are constraints on handoff latency. 😭
  • The proliferation of network discovery technologies within IEEE 802, IETF, and 3rd Generation Partnership Project (3GPP) has the potential to become a significant problem going forward. Without a unified approach, multiple non-interoperable solutions may be deployed. 💀 bestie this is giving "too many competing standards, nobody can talk to each other" energy 🙈
  • New link-layer designs should include efficient distribution of network and realm information as a design requirement. 🌸
  • It may not be possible to solve all aspects of the problem for legacy NAS devices on existing link layers. Therefore, a phased approach may be more realistic. For example, a partial solution could be made available for existing link layers, with a more complete solution requiring support for link layer extensions. 🦋 phased rollout is literally the realistic glow-up route 💖

With respect to specific mechanisms for access network discovery and selection, here's the tea 🍓

  • Studies such as [MACScale] and [Velayos], as well as the calculations described in Section 2.1, demonstrate that the IEEE 802.11 Beacon/Probe Response mechanism has substantial scaling issues in situations where a new Beacon is used for each "virtual AP". As a result, a single channel is, in practice, limited to less than twenty Beacon announcements with IEEE 802.11b. 😩

The situation is improved substantially with successors, such as IEEE 802.11a, that enable additional channels, thus potentially increasing the number of potential virtual APs. ✨

However, even with these enhancements, it is not feasible to advertise more than 50 different networks, and probably less in most circumstances. 💀

As a result, there appears to be a need to enhance the scalability of IEEE 802.11 network advertisements. 🧚

  • Work is underway in IEEE 802.1, IEEE 802.21, and IEEE 802.11u [IEEE.802.11u] to provide enhanced discovery functionality. Similarly, IEEE 802.1af [IEEE.802.1af] has discussed the addition of network discovery functionality to IEEE 802.1X [IEEE.8021X-2004]. However, neither IEEE 802.1AB [IEEE.802.1ab] nor IEEE 802.1af is likely to support fragmentation of network advertisement frames so that the amount of data that can be transported will be limited. 📦
  • While IEEE 802.11k [IEEE.802.11k] provides support for the Neighbor Report, this only provides for gathering of information on neighboring 802.11 APs, not points of attachment supporting other link layers. Solution to this problem would appear to require coordination across IEEE 802 as well as between standards bodies. 🤝
  • Given that EAP does not support fragmentation of EAP-Request/Identity packets, the volume of "realm hints" that can be fit with these packets is limited. In addition, within IEEE 802.11, EAP packets can only be exchanged within State 3 (associated and authenticated). As a result, use of EAP for realm discovery may result in significant delays. The extension of the realm advertisement mechanism defined in [RFC4284] to handle advertisement of realm capability information (such as QoS provisioning) is not recommended due to semantic and packet size limitations [GROETING]. As a result, we believe that extending the mechanism described in [RFC4284] for discovery of realm capabilities is inappropriate. Instead, we believe it is more appropriate for this functionality to be handled within the link layer so that the information can be available early in the handoff process. 😱 the packet-size drama is real 💅
  • Where link-layer approaches are not available, higher-layer approaches can be considered. A limitation of higher-layer solutions is that they can only optimize the movement of already connected hosts, but cannot address scenarios where network discovery is required for successful attachment. 🌿

Higher-layer alternatives worth considering include the SEAMOBY CARD protocol [RFC4066], which enables advertisement of network device capabilities over IP, and Device Discovery Protocol (DDP) [MARQUES], which provides functionality equivalent to IEEE 802.1AB using ASN.1 encoded advertisements sent to a link-local scope multicast address. 🎀

5. Security Considerations 🔐

bestie, this is the part where everything gets serious 😤 all aspects of the network discovery and selection problem are security related. The security issues and requirements have been discussed in the previous sections. 🛡️

The security requirements for network discovery depend on the type of information being discovered. Some of the parameters may have a security impact, such as the claimed name of the network to which the user tries to attach. Unfortunately, current EAP methods do not always make the verification of such parameters possible. EAP methods, such as Protected EAP (PEAP) [JOSEFSSON] and EAP-IKEv2 [IKEV2], may make this possible, however. There is even an attempt to provide a backward-compatible extension to older methods [ARKKO]. 🥺

The security requirements for network selection depend on whether the selection is considered a mandate or a hint. In general, treating network advertisements as a hint is a more secure approach, since it reduces access client vulnerability to forged network advertisements. For example, "realm hints" may be ignored by an EAP peer if they are incompatible with the security policy corresponding to a selected access network. 🫣

Similarly, network access clients may refuse to connect to a point of attachment if the advertised security capabilities do not match those that have been pre-configured. For example, if an IEEE 802.11 access client has been pre-configured to require WPA2 enterprise support within an access network, it may refuse to connect to access points advertising support for WEP. 🚫📡

⚠️ Where the use of methods that do not satisfy the security requirements of [RFC4017] is allowed, it may be possible for an attacker to trick a peer into using an insecure EAP method, leading to the compromise of long-term credentials. This can occur either where a network is pre-configured to allow use of an insecure EAP method, or where connection without pre-configuration is permitted using such methods. 🚨 this one is genuinely scary, so pay attention 👀

For example, an attacker can spoof a network advertisement, possibly downgrading the advertised security capabilities. The rogue access point would then attempt to negotiate an insecure EAP method. Such an attack can be prevented if the peer refuses to connect to access points not meeting its security requirements, which would include requiring use of EAP methods satisfying the [RFC4017] requirements. 🕵️‍♀️

Support for secure discovery could potentially protect against spoofing of network advertisements, enabling verifiable information to guide connection decisions. However, development of these mechanisms requires solving several difficult engineering and deployment problems. 🧩

Since discovery is a prerequisite for authentication, it is not possible to protect initial discovery using dynamic keys derived in the authentication process. On the other hand, integrity protection of network advertisements utilizing symmetric keys or digital signatures would require pre-configuration. 🔑 ngl this is the classic chicken-and-egg problem 🥚🐔

6. Informative References ✨

okay bestie, this is the receipts pile 📚 the sources the doc leans on, all lined up for anyone who wants to dig deeper 🫶

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
  • [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
  • [RFC3017] Riegel, M. and G. Zorn, "XML DTD for Roaming Access Phone Book", RFC 3017, December 2000.
  • [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
  • [RFC4334] Housley, R. and T. Moore, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)", RFC 4334, February 2006.
  • [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
  • [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
  • [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
  • [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
  • [RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997.
  • [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
  • [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
  • [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
  • [RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity Selection Hints for the Extensible Authentication Protocol (EAP)", RFC 4284, January 2006.
  • [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
  • [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
  • [RFC4066] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, "Candidate Access Router Discovery (CARD)", RFC 4066, July 2005.
  • [IKEV2] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and F. Bersani, "EAP-IKEv2 Method", Work in Progress, September 2007.
  • [ARKKO] Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", Work in Progress, October 2005.
  • [GROETING] Groeting, W., Berg, S., Tschofenig, H., and M. Ness, "Network Selection Implementation Results", Work in Progress, July 2004.
  • [JOSEFSSON] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G., and S. Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.
  • [MARQUES] Enns, R., Marques, P., and D. Morrell, "Device Discovery Protocol (DDP)", Work in Progress, May 2003.
  • [OHBA] Taniuchi, K., Ohba, Y., and D. Subir, "IEEE 802.21 Basic Schema", Work in Progress, October 2007.
  • [IEEE.802.11-2003] IEEE, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 2003.
  • [Fixingapsel] Judd, G. and P. Steenkiste, "Fixing 802.11 Access Point Selection", Sigcomm Poster Session 2002.
  • [IEEE.802.11k] IEEE, "Draft Ammendment to Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Radio Resource Management", IEEE 802.11k, D7.0, January 2007.
  • [IEEE.802.1ab] IEEE, "Draft Standard for Local and Metropolitan Area Networks - Station and Media Access Control Connectivity Discovery", IEEE 802.1AB, D1.0, April 2007.
  • [IEEE.802.1af] IEEE, "Draft Standard for Local and Metropolitan Area Networks - Port-Based Network Access Control - Amendment 1: Authenticated Key Agreement for Media Access Control (MAC) Security", IEEE 802.1af, D1.2, January 2007.
  • [IEEE.802.11v] IEEE, "Draft Amemdment to Standard for Information Technology - Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Wireless Network Management", IEEE 802.11v, D0.09, March 2007.
  • [Eronen04] Eronen, P. and J. Arkko, "Role of authorization in wireless network security", Extended abstract presented in the DIMACS workshop, November 2004.
  • [IEEE.11-04-0624] Berg, S., "Information to Support Network Selection", IEEE Contribution 11-04-0624 2004.
  • [Priest04] Priest, J., "The State of Wireless London", July 2004.
  • [MACScale] Heusse, M., "Performance Anomaly of 802.11b", LSR-IMAG Laboratory, Grenoble, France, IEEE Infocom 2003.
  • [Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b MAC Layer Handover Time", Laboratory for Communication Networks, KTH, Royal Institute of Technology, Stockholm, Sweden, TRITA-IMIT-LCN R 03:02, April 2003.
  • [IEEE.802.11u] IEEE, "Draft Amendment to STANDARD FOR Information Technology - LAN/MAN Specific Requirements - Part 11: Interworking with External Networks; Draft Amendment to Standard; IEEE P802.11u/D0.04", IEEE 802.11u, D0.04, April 2007.
  • [IEEE-11-03-154r1] Aboba, B., "Virtual Access Points", IEEE Contribution 11-03-154r1, May 2003.
  • [IEEE-11-03-0827] Hepworth, E., "Co-existence of Different Authentication Models", IEEE Contribution 11-03-0827 2003.
  • [11-05-0822-03-000u-tgu-requirements] Moreton, M., "TGu Requirements", IEEE Contribution 11-05-0822-03-000u-tgu-requirements, August 2005.
  • [3GPPSA2WLANTS] 3GPP, "3GPP System to Wireless Local Area Network (WLAN) interworking; System De scription; Release 6; Stage 2", 3GPP Technical Specification 23.234, September 2005.
  • [3GPP-SA3-030736] Ericsson, "Security of EAP and SSID based network advertisements", 3GPP Contribution S3-030736, November 2003.
  • [3GPP.23.122] 3GPP, "Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode", 3GPP TS 23.122 6.5.0, October 2005.
  • [WWRF-ANS] Eijk, R., Brok, J., Bemmel, J., and B. Busropan, "Access Network Selection in a 4G Environment and the Role of Terminal and Service Platform", 10th WWRF, New York, October 2003.
  • [WLAN3G] Ahmavaara, K., Haverinen, H., and R. Pichna, "Interworking Architecture between WLAN and 3G Systems", IEEE Communications Magazine, November 2003.
  • [INTELe2e] Intel, "Wireless LAN (WLAN) End to End Guidelines for Enterprises and Public Hotspot Service Providers", November 2003.
  • [Eronen03] Eronen, P., "Network Selection Issues", presentation to EAP WG at IETF 58, November 2003.
  • [3GPPSA3WLANTS] 3GPP, "3GPP Technical Specification Group Service and System Aspects; 3G Security; Wireless Local Area Network (WLAN) interworking security (Release 6); Stage 2", 3GPP Technical Specification 33.234 v 6.6.0, October 2005.
  • [3GPPCT1WLANTS] 3GPP, "3GPP System to Wireless Local Area Network (WLAN) interworking; User Equipment (UE) to network protocols; Stage 3 (Release 6)", 3GPP Technical Specification 24.234 v 6.4.0, October 2005.
  • [IEEE.802.21] IEEE, "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE 802.21, D05.00, April 2007.
  • [3GPPCT4WLANTS] 3GPP, "3GPP system to Wireless Local Area Network (WLAN) interworking; Stage 3 (Release 6)", 3GPP Technical Specification 29.234 v 6.4.0, October 2005.
  • [IEEE.8021X-2004] IEEE, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, July 2004.

Appendix A. Existing Work ✨

A.1. IETF

okay so bestie, several IETF working groups have been poking at the network selection problem 🦋: the AAA, EAP, PPP, RADIUS, ROAMOPS, and RADEXT WGs. literally a whole squad 💅

ROAMOPS WG developed the NAI, originally defined in [RFC2486], and subsequently updated in [RFC4282]. Initial roaming implementations are described in [RFC2194], and the use of proxies in roaming is addressed in [RFC2607]. The SEAMOBY WG developed CARD [RFC4066], which assists in discovery of suitable base stations 📡. PKIX WG produced [RFC3280], which addresses issues of certificate selection 🎀. The AAA WG developed more sophisticated access routing, authentication, and service discovery mechanisms within Diameter [RFC3588] ✨ obsessed.

Adrangi et al. [RFC4284] defines the use of the EAP-Request/Identity to provide "realm hints" useful for identity selection. The NAI syntax described in [RFC4282] enables the construction of source routes. Together, these mechanisms enable the user to determine whether it possesses an identity and corresponding credential suitable for use with an EAP-capable NAS. This is particularly useful in situations where the lower layer provides limited information (such as in wired IEEE 802 networks where IEEE 802.1X currently does not provide for advertisement of networks and their capabilities) 🙈

However, advertisement mechanisms based on the use of the EAP-Request/Identity have scalability problems 💀. As noted in [RFC3748] Section 3.1, the minimum EAP Maximum Transmission Unit (MTU) is 1020 octets, so that an EAP-Request/Identity is only guaranteed to be able to include 1015 octets within the Type-Data field. Since RFC 1035 [RFC1035] enables Fully Qualified Domain Names (FQDN) to be up to 255 octets in length, this may not enable the announcement of many realms. The use of network identifiers other than domain names is also possible.

As noted in [Eronen03], the use of the EAP-Request/Identity for realm discovery has substantial negative impact on handoff latency 😭, since this may result in a station needing to initiate an EAP conversation with each Access Point in order to receive an EAP-Request/Identity describing which realms are supported. Since IEEE 802.11-2003 does not support use of Class 1 data frames in State 1 (unauthenticated, unassociated) within an Extended Service Set (ESS), this implies either that the APs must support 802.1X pre-authentication (optional in IEEE 802.11i-2004), or that the station must associate with each AP prior to sending an EAPOL-Start to initiate EAP (here, EAPOL refers to EAP over LAN). This will dramatically increase handoff latency.

Thus, rather than thinking of [RFC4284] as an effective network discovery mechanism, it is perhaps better to consider the use of "realm hints" as an error recovery technique to be used to inform the EAP peer that AAA routing has failed, and perhaps to enable selection of an alternate identity that can enable successful authentication. Where "realm hints" are only provided in event of a problem, rather than as a staple network discovery technique, it is probably best to enable "realm hints" to be sent by core AAA proxies in the "default free" zone. This way, it will not be necessary for NASes to send "realm hints", which would require them to maintain a complete and up-to-date realm routing table, something that cannot be easily accomplished given the existing state of AAA routing technology 🙃.

If realm routing tables are manually configured on the NAS, then changes in the "default free" realm routing table will not automatically be reflected in the realm list advertised by the NAS 🤷. As a result, a realm advertised by the NAS might not, in fact, be reachable, or the NAS might neglect to advertise one or more realms that were reachable. This could result in multiple EAP-Identity exchanges, with the initial set of "realm hints" supplied by the NAS subsequently updated by "realm hints" provided by a core AAA proxy. In general, originating "realm hints" on core AAA proxies appears to be a more sound approach, since it provides for "fate sharing" (generation of "realm hints" by the same entity, the core AAA proxy, that will eventually need to route the request based on the hints) 🧠. This approach is also preferred from a management perspective, since only core AAA proxies would need to be updated; no updates would be required to NAS devices 💅.

A.2. IEEE 802

There has been work in several IEEE 802 working groups relating to network discovery:

  • [IEEE.802.11-2003] defines the Beacon and Probe Response mechanisms within IEEE 802.11. Unfortunately, Beacons may be sent only at a rate within the base rate set, which typically consists of the lowest supported rate, or perhaps the next lowest rate. Studies such as [MACScale] have identified MAC layer performance problems, and [Velayos] has identified scaling issues from a lowering of the Beacon interval.
  • [IEEE-11-03-0827] discusses the evolution of authentication models in WLANs and the need for the network to migrate from existing models to new ones, based on either EAP layer indications or through the use of SSIDs to represent more than the local network. It notes the potential need for management or structuring of the SSID space.

The paper also notes that virtual APs have scalability issues. It does not compare these scalability issues to those of alternative solutions, however.

  • [IEEE-11-03-154r1] discusses mechanisms currently used to provide "virtual AP" capabilities within a single physical access point. A "virtual AP" appears at the MAC and IP layers to be a distinct physical AP. As noted in the paper, full compatibility with existing 802.11 station implementations can only be maintained if each "virtual AP" uses a distinct MAC address (BSSID) for use in Beacons and Probe Responses. This paper does not discuss scaling issues in detail, but recommends that only a limited number of "virtual APs" be supported by a single physical access point.
  • IEEE 802.11u is working on realm discovery and network selection [11-05-0822-03-000u-tgu-requirements] [IEEE.802.11u]. This includes a mechanism for enabling a station to determine the identities it can use to authenticate to an access network, prior to associating with that network. As noted earlier, solving this problem requires the AP to maintain an up-to-date, "default free" realm routing table, which is not feasible without dynamic routing support within the AAA infrastructure. Similarly, a priori discovery of features supported within home realms (such as enrollment) is also difficult to implement in a scalable way, absent support for dynamic routing. Determination of network capabilities (such as QoS support) is considerably simpler, since these depend solely on the hardware and software contained within the AP. However, 802.11u is working on Generic Advertisement Service (GAS) mechanism, which can be used to carry 802.21 Information Service (IS) messages and, in that way, allow a more sophisticated way of delivering information from the network side.
  • IEEE 802.21 [IEEE.802.21] is developing standards to enable handover between heterogeneous link layers, including both IEEE 802 and non-IEEE 802 networks. To enable this, a general mechanism for capability advertisement is being developed, which could conceivably benefit aspects of the network selection problem, such as realm discovery. For example, IEEE 802.21 is developing Information Elements (IEs) that may assist with network selection, including information relevant to both layer 2 and layer 3. Query mechanisms (including both XML and TLV support) are also under development. IEEE 802.21 also defines a Resource Description Framework (RDF) schema to allow use of a query language (i.e., SPARQL). The schema is a normative part of IEEE 802.21 and also defined in [OHBA].

A.3. 3GPP ✨

okay bestie, the 3GPP stage 2 spec [3GPPSA2WLANTS] lays out the architecture of 3GPP Interworking WLAN (I-WLAN) with 2G and 3G networks 🎀. it also talks about realm discovery and network selection issues. the I-WLAN realm discovery procedure literally borrows ideas from the cellular Public Land-based Mobile Network (PLMN) selection principles, known as "PLMN Selection" 📡

In 3GPP PLMN selection [3GPP.23.122], the mobile node keeps an eye on surrounding cells and ranks them by signal strength before picking a new potential target cell 💅 each cell broadcasts its PLMN. a mobile node may automatically select cells that belong to its Home PLMN, Registered PLMN, or an allowed set of Visited PLMNs. the PLMN lists get prioritized and stored in the Subscriber Identity Module (SIM) 🔥 for manual PLMN selection, the mobile node lists the PLMNs it learns about from surrounding cells and lets the user pick the one they want. once the PLMN is selected, cell prioritization happens so it can land on the right target cell 🦋

[WLAN3G] discusses the new realm (PLMN) selection requirements that come with I-WLAN roaming. these support automatic PLMN selection, not just manual selection 🧚 multiple network levels may be present. the hotspot owner may have a contract with a provider, who in turn has a contract with a 3G network, which may have a roaming agreement with other networks. it's a whole chain, iykyk 💀

The I-WLAN specification requires that network discovery be performed as specified in the relevant WLAN link layer standards. on top of network discovery, you also need to select intermediary realms so you can build source routes 🌸 in 3GPP, the intermediary networks are PLMNs, and it's assumed that an access network may have a roaming agreement with more than one PLMN. the PLMN may be a Home PLMN (HPLMN) or a Visited PLMN (VPLMN), where roaming is supported. GSM/UMTS roaming principles get used to route AAA requests from the VPLMN to the Home Public Land-based Mobile Network (HPLMN), using either RADIUS or Diameter. the procedure for picking the intermediary network is specified in the stage 3 technical specifications [3GPPCT1WLANTS] and [3GPPCT4WLANTS].

To select the PLMN, the following procedure is required:

  • The user may choose the desired HPLMN or VPLMN manually, or let the WLAN User Equipment (WLAN UE) choose the PLMN automatically based on user and operator defined preferences.
  • AAA messages are routed based on the decorated or undecorated NAI.
  • EAP is utilized as defined in [RFC3748] and [RFC3579].
  • PLMN advertisement and selection is based on [RFC4284], which defines only realm advertisement. The document refers to the potential need for extensibility, though EAP MTU restrictions make this difficult 🙈

The I-WLAN specification states that "realm hints" are only provided when an unreachable realm is encountered. where VPLMN control is required, this is handled via NAI decoration 💜 the station may manually trigger PLMN advertisement by including an unknown realm (known as the Alternative NAI) within the EAP-Response/Identity. a realm guaranteed not to be reachable within 3GPP networks is used for this purpose ✨

The I-WLAN security requirements are described in the 3GPP stage 3 technical specification [3GPPSA3WLANTS]. the security requirements for PLMN selection are discussed in 3GPP contribution [3GPP-SA3-030736], which concludes that both SSID and EAP-based mechanisms have similar security weaknesses 😭 so it recommends that PLMN advertisements should be considered as hints.

A.4. Other 🌈

[INTELe2e] discusses the need for realm selection where an access network may have more than one roaming relationship path to a home realm. it also describes solutions to the realm selection problem based on EAP, SSID, and Protected EAP (PEAP) based mechanisms 🦋

Eijk et al. [WWRF-ANS] discusses the realm and network selection problem. the authors concentrate mainly on discovering access networks that meet a set of criteria. they note that information on realm capabilities and reachability inherently lives in home AAA servers, so it isn't readily available in a central location and may not be easily obtained by NAS devices 🧚

Appendix B. Acknowledgements 🫶

The authors of this document would like to especially acknowledge the contributions of Farid Adrangi, Michael Richardson, Pasi Eronen, Mark Watson, Mark Grayson, Johan Rune, and Tomas Goldbeck-Lowe 👑

Input for the early versions of this document was gathered from many sources, including the above persons as well as 3GPP and IEEE developments. we'd also like to thank Alper Yegin, Victor Lortz, Stephen Hayes, and David Johnston for comments 💖

Jouni Korhonen would like to thank the Academy of Finland for providing funding to work on this document 🌸

Authors' Addresses

Jari Arkko
Ericsson
Jorvas  02420
Finland

EMail: jari.arkko@ericsson.com


Bernard Aboba
Microsoft
One Microsoft Way
Redmond, WA  98052
USA

EMail: bernarda@microsoft.com


Jouni Korhonen
TeliaSonera
Teollisuuskatu 13
Sonera  FIN-00051
Finland

EMail: jouni.korhonen@teliasonera.com


Farooq Bari
AT&T
7277 164th Avenue N.E.
Redmond  WA  98052
USA

EMail: farooq.bari@att.com

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔥

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on the extent to which any license under such rights might or might not be available. it also doesn't represent that it has made any independent effort to identify any such rights. info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📜

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use these proprietary rights can be obtained from the IETF online IPR repository at http://www.ietf.org/ipr 🦋

the IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology required to implement this standard. please send that info to the IETF at ietf-ipr@ietf.org 🌈⭐

📦 where this page comes from