[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 5113

Extensible Authentication Protocol                              J. Arkko
Internet-Draft                                                  Ericsson
Intended status: Informational                                  B. Aboba
Expires: April 26, 2007                                        Microsoft
                                                             J. Korhonen
                                                             TeliaSonera
                                                                 F. Bari
                                                       Cingular Wireless
                                                        October 23, 2006


                Network Discovery and Selection Problem
                    draft-ietf-eap-netsel-problem-05

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 26, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).









Arkko, et al.            Expires April 26, 2007                 [Page 1]


Internet-Draft          Network Discovery and PS            October 2006


Abstract

   The so called network discovery and selection problem affects network
   access, particularly in the presence of multiple available wireless
   accesses and roaming.  This problem has been the subject of
   discussions in various standards bodies.  This document summarizes
   the discussion held about this problem in the Extensible
   Authentication Protocol (EAP) working group at the IETF.  The problem
   is defined and divided into subproblems, and some constraints for
   possible solutions are outlined.  The document also provides a
   discussion of the limitations of certain classes of solution,
   including some that have been previously defined.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Problem Definition . . . . . . . . . . . . . . . . . . . . . .  7
     2.1.  Discovery of the Point of Attachment to the Network  . . .  7
     2.2.  Identity selection . . . . . . . . . . . . . . . . . . . .  9
     2.3.  AAA routing  . . . . . . . . . . . . . . . . . . . . . . . 10
       2.3.1.  The Incomplete Routing Table Problem . . . . . . . . . 11
       2.3.2.  The User and Identity Selection Problem  . . . . . . . 12
     2.4.  Capability Discovery . . . . . . . . . . . . . . . . . . . 14
   3.  Design Issues  . . . . . . . . . . . . . . . . . . . . . . . . 16
     3.1.  AAA issues . . . . . . . . . . . . . . . . . . . . . . . . 16
     3.2.  Backward Compatibility . . . . . . . . . . . . . . . . . . 16
     3.3.  Efficiency Constraints . . . . . . . . . . . . . . . . . . 16
     3.4.  Scalability  . . . . . . . . . . . . . . . . . . . . . . . 16
     3.5.  Realm discovery and selection decision making  . . . . . . 17
   4.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 18
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 24
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 24
   Appendix A.  Existing Work . . . . . . . . . . . . . . . . . . . . 28
     A.1.  IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     A.2.  IEEE 802 . . . . . . . . . . . . . . . . . . . . . . . . . 29
     A.3.  3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     A.4.  Other  . . . . . . . . . . . . . . . . . . . . . . . . . . 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
   Intellectual Property and Copyright Statements . . . . . . . . . . 34






Arkko, et al.            Expires April 26, 2007                 [Page 2]


Internet-Draft          Network Discovery and PS            October 2006


1.  Introduction

   The network discovery and selection problem affects network access
   and wireless access networks in particular.  Aspects of the problem
   will appear when any of the following conditions are true:

   o  There is more than one available network attachment point, and the
      different attachment points may have different characteristics or
      belong to different operators.  In the case of virtual operators,
      access network infrastructure including e.g. the access points can
      be shared by multiple operators.  In order to choose between the
      network attachment points, it may be helpful to determine which
      realms are supported and the capabilities access network
      supporting those realms.  Otherwise, the mobile station might
      frequently roam into networks that are not able to satisfy the
      roaming connectivity needs or provide services the mobile station
      (and the subscriber) are seeking for.  This would of course lower
      the general quality of offered services.

   o  The user has multiple sets of credentials.  For instance, the user
      could have one set of credentials from a public service provider
      and set from the user's employer.  In this case it may be helpful
      to provide additional information to enable the correct credential
      set to be determined.  Otherwise, it could happen that for example
      a network access authentication repeatedly fails because of
      incorrectly selected and offered set of credentials.

   o  There is more than one way to provide roaming between the visited
      realm used for access and user's home realm, and service
      parameters or pricing differs between them.  For instance, the
      visited access realm could have both a direct relationship with
      the home realm and an indirect relationship through a roaming
      consortium.  In some scenarios, current AAA protocols may not be
      able to route the requests to the home realm unaided, just based
      on the domain in the given Network Access Identifier (NAI)
      [RFC4282].  In addition, payload packets can get routed or
      tunneled differently, based on the roaming relationship path in
      use.  This may have an impact on the available services or their
      pricing.

   In Section 2 the network discovery and selection problem is defined
   and divided into subproblems, and some design issues for possible
   solutions are outlined in Section 3.  Section 4 gives the conclusions
   and some suggestions on how to proceed for the rest.  Appendix A
   discusses existing mechanisms which help solve at least parts of the
   problem.  The terms "network" and "realm" have sometimes been used
   interchangeably within the context of selection and discovery.  It
   should be noted that a realm can be reachable from more than one



Arkko, et al.            Expires April 26, 2007                 [Page 3]


Internet-Draft          Network Discovery and PS            October 2006


   access network types and selection of a realm may not imply certain
   network capabilities.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Network Access Identifier (NAI)

      The Network Access Identifier (NAI) [RFC4282] is the user identity
      submitted by the client during network access authentication.  In
      roaming, the purpose of the NAI is to identify the user as well as
      to assist in the routing of the authentication request.  Please
      note that 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.

   Decorated NAI

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

   Realm

      Realm portion of an NAI [RFC4282].

   Network Selection

      This refers to selection of an operator/ISP in order to access the
      network.  The process of network selection can occur either at the
      beginning of a new session or during a handoff in case the user is
      mobile.  The selection is dependent upon for example the selection
      of realm for the operator, authentication credentials for the
      user/device and the roaming agreements.  The realm Selection can
      in turn also depend upon Access Technology Selection and/or Bearer
      Selection.

   Network Discovery

      This refers to a mechanisms that a node uses to discover available
      networks prior the realm selection takes place.  The discovery
      process may be passive or active from a node point of view.
      Typically the discovery mechanism varies depending on the access
      technology.  It is also possible that there are multiple discovery
      mechanisms within one access technology depending on the network
      deployment.



Arkko, et al.            Expires April 26, 2007                 [Page 4]


Internet-Draft          Network Discovery and PS            October 2006


   Realm Selection

      This refers to selection of the realm of the operator/ISP used to
      access the network.

   Access Technology Selection

      This refers to the selection between access technologies e.g.
      802.11, UMTS, WiMAX.  The selection will be dependent upon the
      access technologies supported by the device and the availability
      of networks supporting those technologies.

   Bearer Selection

      For some access technologies (e.g.  UMTS), there can be a
      possibility for delivery of a service (e.g. voice) by using either
      a circuit switched or a packet switched bearer.  The Bearer
      selection refers to selecting one of the bearer types for service
      delivery.  The decision can be based on support of the bearer type
      by the device and the network as well as user subscription and
      operator preferences.

   Network Access Server

      The Network Access Server (NAS) is the device that clients connect
      to in order to get access to the network.  In PPTP terminology,
      this is referred to as the PPTP Access Concentrator (PAC), and in
      L2TP terminology, it is referred to as the L2TP Access
      Concentrator (LAC).  In IEEE 802.11, it is referred to as an
      Access Point.

   Roaming Capability

      Roaming capability can be loosely defined as the ability to use
      any one of multiple Internet Service Providers (ISPs), while
      maintaining 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).






Arkko, et al.            Expires April 26, 2007                 [Page 5]


Internet-Draft          Network Discovery and PS            October 2006


   Access Point (AP)

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

   Basic Service Set (BSS)

      A set of stations controlled by a single coordination function.

   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), which appears as a single BSS to the logical link
      control layer at any station associated with one of those BSSs.
      This refers to a mechanism that a node uses to discover the
      networks that are reachable from a given access network.

































Arkko, et al.            Expires April 26, 2007                 [Page 6]


Internet-Draft          Network Discovery and PS            October 2006


2.  Problem Definition

   This problem spans multiple protocol layers and has been the subject
   of discussions in IETF, 3GPP, and IEEE.  This document summarizes the
   discussion held about this problem in the Extensible Authentication
   Protocol working group at IETF.  There are a set of somewhat
   orthogonal problems being discussed under the rubric of "network
   discovery and selection".

   o  The problem of "discovery of points of attachment".  This is the
      problem of discovering points of attachment available in the
      vicinity, and the capabilities associated with these points of
      attachment.

   o  The problem of "Identifier selection".  This is the problem of
      selecting which identity (and credentials) to use to authenticate
      in a given point of attachment to the network.

   o  The problem of "AAA routing" which involves figuring out how to
      route the authentication conversation originating from the
      selected identity back to the home realm.

   o  The problem of "Payload routing" which involves figuring how the
      payload packets are routed, where more advanced mechanisms than
      destination-based routing is needed.  However, while being an
      interesting problem, this document does not attempt to do any
      analysis or suggestions on it.

   o  The problem of "network capability discovery".  This is the
      problem of discovering the capabilities of a particular
      destination network.  For example, it may be important to know
      whether a given network supports enrollment, what the charges are,
      etc.

   Alternatively, the problem can be divided to the discovery, decision,
   and the selection components.  The AAA routing problem, for instance,
   involves all components: discovery (which mediating networks are
   available?), decision (choose the "best" one), and selection (client
   tells the network which mediating network it has decided to choose)
   components.

2.1.  Discovery of the Point of Attachment to the Network

   "The discovery of points of attachment" problem has been extensively
   studied, see for instance the IEEE specifications on 802.11 wireless
   LAN beaconing and probing process, studies (such as [Fixingapsel]) on
   the effectiveness of these mechanisms, specifications on GSM network
   discovery, results of the IETF Seamoby WG, and so on.



Arkko, et al.            Expires April 26, 2007                 [Page 7]


Internet-Draft          Network Discovery and PS            October 2006


   Traditionally, the problem of discovering available point of
   attachment has been handled as a part of the link layer attachment
   procedures, or through out-of-band mechanisms.

   RFC 2194 [RFC2194] describes the pre-provisioning of dialup roaming
   clients, which typically included a list of potential phone numbers,
   updated by the provider(s) with which the client had a contractual
   relationship.  RFC 3017 [RFC3017] describes the IETF Proposed
   Standard for the Roaming Access XML DTD.  This covers not only the
   attributes of the Points of Presence (POPs) and Internet Service
   Providers (ISPs), but also hints on the appropriate NAI to be used
   with a particular POP.  The RFC supports dial-in and X.25 access, but
   has extensible address and media type fields.

   In IEEE 802.11 WLANs, the Beacon/Probe Request/Response mechanism
   provides a way for Stations to discover Access Points (APs), as well
   as the capabilities of those APs.  Among the Information Elements
   (IEs) included within the Beacon and Probe Response is the SSID, a
   non-unique identifier of the network to which an Access Point is
   attached.  By combining network identification along with
   capabilities discovery, the Beacon/Probe facility provides the
   information required for both network discovery and roaming decisions
   within a single mechanism.

   As noted in [Velayos], the IEEE 802.11 Beacon mechanism does not
   scale well; with a Beacon interval of 100ms, and 10 APs in the
   vicinity, approximately 32 percent of an 802.11b AP's capacity is
   used for beacon transmission.  In addition, since Beacon/Probe
   Response frames are sent by each AP over the wireless medium,
   stations can only discover APs within range, which implies
   substantial coverage overlap for roaming to occur without
   interruption.

   A number of enhancements have been proposed to the Beacon/Probe
   Response mechanism in order to improve scalability and roaming
   performance.  These include allowing APs to announce capabilities of
   neighbor APs as well as their own, as proposed in IEEE 802.11k
   [IEEE.802.11k].

   Typically scalability enhancement mechanisms attempt to get around
   Beacon/Probe Response restrictions by sending advertisements at the
   higher layers which are enabled once the station has associated with
   an AP and gained IP connectivity.  Since these mechanisms run over
   IP, they can utilize IP facilities such as fragmentation, which the
   link layer mechanisms may not always be able to do.  For instance, in
   IEEE 802.11, Beacon frames cannot use fragmentation because they are
   multicast frames, and multicast frames are not acknowledged in
   802.11.



Arkko, et al.            Expires April 26, 2007                 [Page 8]


Internet-Draft          Network Discovery and PS            October 2006


   Another issue with the Beacon/Probe Request/Response mechanism is
   that it is either insecure or its security can be assured only after
   already attaching to this particular network.

   When considering access systems such as 802.11 WLANs networks it is
   important to take into account different deployment options.  For
   example, a WLAN deployment may include a number of VLANs in order to
   separate UAM (Universal Access Method) and 802.1X [IEEE.8021X] users
   or users accessing network from different geographical/organizational
   locations.  It is also possible that a larger network spans multiple
   ESSes and prefixes.  It is also possible that users authenticating to
   different realms are able to do so via the same SSID.

2.2.  Identity selection

   As networks proliferate, it becomes more and more likely that a given
   user may have multiple identities and credential sets, available for
   use in different situations.  For example, the user may have an
   account with one or more Public WLAN providers; a corporate WLAN; one
   or more wireless WAN providers.  As a result, the user has to decide
   which credential set to use when presented with a choice.

   Figure 1 illustrates a situation where the user realm may not be
   reachable from each potential access network.  Access Network 1 only
   enables access to the realm "isp1.example.com" whereas Access Network
   3 enables access to the realm "corp2.example.com" whereas Access
   Network 2 enables access to both realms.

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


         Figure 1: Two credentials, three possible access networks



Arkko, et al.            Expires April 26, 2007                 [Page 9]


Internet-Draft          Network Discovery and PS            October 2006


   Traditionally, hints useful in identity selection have also been
   provided out-of-band.  For example, via the RFC 3017 XML DTD
   [RFC3017], a client can select between potential POPs, and then based
   on information provided in the DTD, determine the appropriate NAI to
   use with the selected point of attachment to the network.

   Where a fixed set of realms are always reachable from a given
   network, access network names can be used to infer realm
   reachability.  For example, IEEE 802.11 Access Points provide the
   SSID, though in some cases the station may not learn all the SSIDs
   supported by the given access point without probing for them.  In
   IKEv2 [RFC4306], the identity of the responder (typically the
   security gateway) is provided as a part of the IKEv2 exchange.

   To use this information for identity selection, the client has to
   match the access network name with the realm portion of a valid
   client identity.  For example, the client may be configured with the
   network access names that have roaming contracts with each of the
   client's home realms.

   It is also possible for hints to be embedded within credentials.  In
   [RFC4334], usage hints are provided within certificates used for
   wireless authentication.  This involves extending the client's
   certificate to include the SSIDs with which the certificate can be
   used.

   Finally, some EAP implementations use the space after the NUL
   character in an EAP Identity Request to communicate some parameters
   for example listing realms supported for authentication.  The
   Informational RFC [RFC4284] specifies the interpretation of the field
   beyond the NUL character when realms are to be communicated.

2.3.  AAA routing

   Once the identity has been selected, it is necessary for the
   authentication conversation to be routed back to the home realm.
   This is typically done today through the use of the Network Access
   Identifier (NAI), RFC 4282 [RFC4282], and the ability of the AAA
   network to route requests to the realm indicated in the NAI.

   Within the past IETF ROAMOPS WG, additional approaches were
   considered for routing authentication conversation back to the home
   realm, including source routing techniques based on the NAI, and
   techniques relying on the AAA infrastructure.  Given the relative
   simplicity of the roaming implementations described in RFC 2194
   [RFC2194], static routing mechanisms appeared adequate for the task
   and it was not deemed necessary to develop dynamic routing protocols.




Arkko, et al.            Expires April 26, 2007                [Page 10]


Internet-Draft          Network Discovery and PS            October 2006


   As noted in RFC 2607 [RFC2607], RADIUS proxies are deployed not only
   for routing purposes, but also to mask a number of inadequacies in
   the RADIUS protocol design, such as the lack of standardized
   retransmission behavior and the need for shared secret provisioning.

   By removing many of the protocol inadequacies, introducing new AAA
   agent types such as Redirects, providing support for certificate-
   based authentication as well as inter and intra-domain service
   discovery, allowing DNS based dynamic discovery of peer agents,
   Diameter allows a NAS to directly open a Diameter connection to the
   home realm without having to utilize a network of proxies.  For
   instance, the Redirect feature could be used to provide a centralized
   routing function for AAA, without having to know all home network
   names in all access networks.  However, there are issues in the
   previously mentioned approach as setting up security might turn out
   to be problematic and the model might not meet business practices.

   This is somewhat analogous to the evolution of email delivery.  Prior
   to the widespread proliferation of the Internet, it was necessary to
   gateway between SMTP-based mail systems and alternative delivery
   technologies, such as UUCP and FidoNet, and email-address based
   source-routing was used to handle this.  However, as mail could
   increasingly be delivered directly, the use of source routing
   disappeared.

   As with the selection of certificates by stations, a Diameter client
   wishing to authenticate with a Diameter server may have a choice of
   available certificates, and therefore it may need to choose between
   them.

2.3.1.  The Incomplete Routing Table Problem

   No dynamic routing protocols are in use in AAA infrastructure today.
   This implies that there has to be a device (such as a proxy) within
   the access network that knows how to route to different domains, even
   if they are further than one hop away, as shown in Figure 2.  In this
   figure, the user "joe@c.example.com" has to be authenticated through
   ISP 2, since the domain "c.example.com" is served by it.













Arkko, et al.            Expires April 26, 2007                [Page 11]


Internet-Draft          Network Discovery and PS            October 2006


                     +---------+      +---------+
                     |         |      |         |
   User "joe@        | Access  |----->|  ISP 1  |-----> "a.example.com"
    c.example.com"-->| Network |      |         |
                     |         |      +---------+
                     +---------+
                         |
                         |
                         V
                     +---------+
                     |         |-----> "b.example.com"
                     |  ISP 2  |
                     |         |-----> "c.example.com"
                     +---------+

                Figure 2: AAA routing problem


2.3.2.  The User and Identity Selection Problem

   A related issue is that the roaming relationship graph may have
   ambiguous routes, as shown in Figure 3.  As billing is based on AAA
   and pricing may be based on the used intermediaries, it is necessary
   to select which route is used.  For instance, in Figure 3, access
   through the roaming group 1 may be cheaper, than if roaming group 2
   is used.

                                       +---------+
                                       |         |----> "a.example.com"
                                       | Roaming |
                      +---------+      | Group 1 |
                      |         |----->|         |----> "b.example.com"
   User "joe@         | Access  |      +---------+
    a.example.com"--->| Network |
                      |         |      +---------+
                      |         |----->|         |----> "a.example.com"
                      +---------+      | Roaming |
                                       | Group 2 |
                                       |         |----> "c.example.com"
                                       +---------+

                Figure 3: Ambiguous AAA routing


   There have been requests to place credential and AAA route selection
   under user control, as the user is affected by the pricing and other
   differences.  Optionally, automatic tools could make the selection
   based on the user's preferences.  On the other hand, user control is



Arkko, et al.            Expires April 26, 2007                [Page 12]


Internet-Draft          Network Discovery and PS            October 2006


   similar to source routing, and as discussed earlier, network-based
   routing mechanisms have traditionally won over source routing-based
   mechanisms.

   If users can control the selection of intermediaries, such
   intermediaries still have to be legitimate AAA proxies.  That is, an
   access network should not send a request to an unknown intermediary.
   If it has a business relationship with three intermediaries
   int1.example.com, int2.example.com, and int3.example.com, it will
   route the request through one of them, even if the user tried to
   request routing through mitm.example.org.  Thus, NAI-based source
   routing is not source routing in the classic sense.  It is merely
   suggesting preferences among already established routes.  If the
   route does not already exist, or is not feasible, then NAI-based
   source routing cannot establish it.

   An additional issue is that even if the intermediaries are
   legitimate, they could be switched.  For instance, an access network
   could advertise that it has a deal with
   cheapintermediary.example.net, and then switch the user's selection
   to priceyintermediary.example.com instead.  To make this relevant,
   the pricing would have to be based on the intermediary.  Even if it
   were possible to secure this selection, it would not be possible to
   guarantee that QoS or other properties claimed by the network were
   indeed provided.  However, the ability to get authenticated via
   intermediates implies that all the parties have a business agreement
   with each other, which may also include an agreement about the
   minimum service level guarantees.

   Only a limited amount of information about AAA routes or pricing
   information can be dynamically communicated [Eronen04].  It is
   necessary to retrieve network and intermediary names, but quality of
   service or pricing information is clearly something that would need
   to be pre-provisioned, or perhaps just available via the web.
   Similarly, dynamic communication of network names can not be expected
   to provide all possible home network names, as their number can be
   quite large globally.

   As a result, network-based AAA routing mechanisms should be used
   instead of user-based selection where sufficient routes exist.  In an
   error situation, such as when an attempt to use the network-based
   routing mechanism has failed, routing hints can be advertised and
   used as defined in [RFC4282] and [RFC4284].  Even so, such approaches
   have severe scalability limitations.  See Appendix A.1 for further
   discussion






Arkko, et al.            Expires April 26, 2007                [Page 13]


Internet-Draft          Network Discovery and PS            October 2006


2.4.  Capability Discovery

   Network Capabilities can provide information useful in the selection
   process [I-D.groeting-eap-netselection-results].  For instance,
   access network discovery may benefit from getting knowledge about the
   quality of service available from a particular access network or
   node, and AAA routing may require knowledge of roaming agreements.
   References [I-D.groeting-eap-netselection-results] and
   [IEEE.11-04-0624] describe the following categories of information
   which can be discovered:


   o  Access network identification

   o  Roaming agreements

   o  Authentication mechanisms

   o  Quality of Service

   o  Cost

   o  Authorization policy

   o  Privacy policy

   o  Service parameters, such as the existence of middleboxes

   The nature of the discovered information can be static, such as the
   fastest available transmission speed on a given piece of equipment.
   Or it can be dynamic, such as the current load on this equipment.
   The information can describe something about the network access nodes
   themselves, or it can be something that they simply advertise on
   behalf of other parts of the network, such as roaming agreements
   further in the AAA network.

   Typically, it would be desirable to acquire all this information
   prior to the authentication process.  In some cases it is in fact
   necessary, if the authentication process can not complete without the
   information.  Reference [IEEE.11-04-0624] classifies the possible
   steps at which IEEE 802.11 networks can acquire this information:


   o  Pre-association

   o  Post-association (or pre-authentication)





Arkko, et al.            Expires April 26, 2007                [Page 14]


Internet-Draft          Network Discovery and PS            October 2006


   o  Post-authentication

   Note that some EAP methods (such as those defined in
   [I-D.josefsson-pppext-eap-tls-eap] [I-D.tschofenig-eap-ikev2]
   [I-D.arkko-eap-service-identity-auth]) have an ability to agree about
   additional parameters during an authentication process.  While such
   parameters are useful for many purposes, their use for access network
   selection suffers from an obvious chicken-and-egg problem.  Or at
   least it seems costly to run a relatively heavy authentication
   process to decide whether the client wants to attach to this access
   network.








































Arkko, et al.            Expires April 26, 2007                [Page 15]


Internet-Draft          Network Discovery and PS            October 2006


3.  Design Issues

   The following factors should be taken into consideration while
   evaluating solutions for problem of network selection and discovery:

3.1.  AAA issues

   Access network or realm selection may leverage or interact with the
   AAA infrastructure.  The solution should therefore be compatible with
   all AAA protocols.  AAA routing mechanisms should work for requests,
   responses, as well as server-initiated messages.  The solution should
   not prevent the introduction of new AAA or access network features,
   such as AAA routing protocols or fast handoffs.

3.2.  Backward Compatibility

   The solution should allow interoperability with clients, protocols,
   access networks, AAA proxies, and AAA servers that have not been
   modified to support network discovery and selection.  For example, it
   should not cause a problem with limited packet sizes of current
   protocols.  Where new protocol mechanisms are required, it should be
   possible to deploy the solution without requiring changes to the
   largest base of installed devices -- network access servers, wireless
   access points, and clients.

3.3.  Efficiency Constraints

   The solution should be efficient in network resource utilization,
   specially on bandwidth constrained sections of the network (E.g.
   wireless link).  Mechanisms that could significantly increase
   communication of an unauthenticated device with more than one points
   of attachment during the selection process should be avoided.  For
   many handheld devices, battery life is a significant constraint.
   Mechanisms that could significantly drain battery e.g. by requiring
   one or more radios in multimode devices to continuously scan for
   networks, should be avoided.  In addition, the solution should not
   significantly impact network attachment time.

3.4.  Scalability

   Depending upon deployment scenarios and business agreements amongst
   the network operators, the number of networks to be advertised can
   range from a few to a very large number.  The solution should
   therefore be scalable so that it can handle from a small to very
   large number of networks without violating the efficiency constraints
   described in Section 3.3.





Arkko, et al.            Expires April 26, 2007                [Page 16]


Internet-Draft          Network Discovery and PS            October 2006


3.5.  Realm discovery and selection decision making

   "Phone-book" based approaches such as RFC 3017 appear attractive due
   to their ability to provide sufficient information for automatic
   selection decisions.  However, there is no experience on applying
   such approaches to wireless access.  The number of WLAN access points
   is significantly higher than the number of dial-in POPs; the
   distributed nature of the access network has created a more
   complicated business and roaming structure, and the expected rate of
   change in the information is high.  As noted in [Priest04] and
   [I-D.groeting-eap-netselection-results], a large fraction of current
   WLAN access points operate on the default SSID, which may make the
   use of the phone book approach difficult.






































Arkko, et al.            Expires April 26, 2007                [Page 17]


Internet-Draft          Network Discovery and PS            October 2006


4.  Conclusions

   The issues surrounding the network discovery and selection problem
   have been summarized.

   In the opinion of the authors of this document, the main findings
   are:

   o  There is a clear need for access network discovery, identifier
      selection, AAA routing, and payload routing.

   o  Identifier selection and AAA routing problems can and should be
      seen as the different aspects of the same problem, identifier
      selection.

   o  Nevertheless, many of the problems discussed in this draft are
      very hard when one considers them in an environment that requires
      a potentially large number of networks, fast handoffs, and
      automatic decisions.

   o  The proliferation of multiple competing network discovery
      technologies within IEEE 802, IETF, and 3GPP appears to a
      significant problem going forward.  In the absence of a clearly
      defined solution to the problem it is likely that any or all of
      these solutions will be utilized, resulting in industry
      fragmentation and lack of interoperability.

   o  New link layers should be designed with facilities that enable the
      efficient distribution of network advertisement information.

   o  Solving all problems with current link layers and existing network
      access devices may not be possible.  It may be useful to consider
      a phased approach where only certain, limited functions are
      provided now, and the full functionality is provided when
      extensions to current link layers become available.

   We will briefly comment on the specific mechanisms related to access
   network discovery and selection:

   o  As noted in studies such as [MACScale] and [Velayos], the IEEE
      802.11 Beacon/Probe Response mechanism has substantial scaling
      issues, and as a result a single physical access point is in
      practice limited to less than a dozen virtual APs on each channel
      with IEEE 802.11b.

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



Arkko, et al.            Expires April 26, 2007                [Page 18]


Internet-Draft          Network Discovery and PS            October 2006


      However, even these enhancements it is not feasible to advertise
      more than 50 different networks using existing mechanisms, and
      probably significantly less in most circumstances.

      As a result, there appears to be justification for enhancing the
      scalability of network advertisements.

   o  Work is already underway in IEEE 802.1, IEEE 802.21 and the IEEE
      802.11u to provide enhanced discovery functionality.  Similarly,
      the IEEE 802.1af has discussed the idea of supporting network
      discovery within a future revision to IEEE 802.1X. However,
      neither IEEE 802.1ab nor IEEE 802.1af is likely to address the
      transport of large quantities of data where fragmentation would be
      a problem.

      Another typical limitation of link layer assistance in this area
      is that in general, it would be desirable to retrieve also
      information relating to the potential next access networks or
      access points.  However, such networks may be of another type than
      the current one, so the link layer would have to carry information
      relating to other types of link layers as well.  This is possible,
      but requires coordination among different groups in the industry.

   o  Given that EAP does not support fragmentation of EAP-Request/
      Identity packets, and that use of EAP for network selection on all
      attachments will have a substantial adverse impact on roaming
      performance without appropriate lower layer support (such as
      support for Class 1 data frames within IEEE 802.11), the use of
      EAP is limited.  For instance, the use of EAP to carry quality of
      service as proposed in [I-D.groeting-eap-netselection-results]
      seems difficult given the limitations.  Long-term, it makes more
      sense for the desired functionality to be handled either within
      IEEE 802 or at the IP layer.  However, a strictly limited
      discovery mechanism such as the one defined in [RFC4284] is
      useful.

   o  In the IETF, a potential alternative is use of the SEAMOBY CARD
      protocol [RFC4066], which enables advertisement of network device
      capabilities over IP.  Another alternative is the already expired
      Device Discovery Protocol (DDP) [I-D.marques-ddp] proposal, which
      provides functionality equivalent to IEEE 802.1ab using ASN.1
      encoded advertisements sent to a link-local scope multicast
      address.

      A limitation of these IP layer solutions is that they can only
      work as a means to speed up the attachment procedures when moving
      from one location to another; when a node starts up, it needs to
      be able to attach to a network before IP communications are



Arkko, et al.            Expires April 26, 2007                [Page 19]


Internet-Draft          Network Discovery and PS            October 2006


      available.  This is fine for optimizations, but precludes the use
      in a case where the discovery information is mandatory before
      successful attachment can be accomplished, for instance when the
      access network is unable to route the AAA request unaided.















































Arkko, et al.            Expires April 26, 2007                [Page 20]


Internet-Draft          Network Discovery and PS            October 2006


5.  IANA Considerations

   This document does not define any new name spaces to be managed by
   IANA.  This document does not either reserve any new numbers or names
   under any existing name space managed by IANA.














































Arkko, et al.            Expires April 26, 2007                [Page 21]


Internet-Draft          Network Discovery and PS            October 2006


6.  Security Considerations

   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 the user
   tries to attach to.  Unfortunately, current EAP methods do not always
   make the verification of such parameters possible.  New EAP methods
   are doing it [I-D.josefsson-pppext-eap-tls-eap]
   [I-D.tschofenig-eap-ikev2], however, and there is even an attempt to
   provide a backwards compatible extensions to older methods
   [I-D.arkko-eap-service-identity-auth].

   The security requirements for network selection depend on whether the
   selection is considered as a command or a hint.  For instance, the
   selection that the user provided may be ignored if it relates to AAA
   routing and the access network can route the AAA traffic to the
   correct home network using other means in any case.






























Arkko, et al.            Expires April 26, 2007                [Page 22]


Internet-Draft          Network Discovery and PS            October 2006


7.  Contributors

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

   Input for the early versions of this draft has been gathered from
   many sources, including the above persons as well as 3GPP and IEEE
   developments.  We would also like to thank Alper Yegin, Victor Lortz,
   Stephen Hayes, and David Johnston for comments.








































Arkko, et al.            Expires April 26, 2007                [Page 23]


Internet-Draft          Network Discovery and PS            October 2006


8.  References

8.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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.

   [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.

   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282, December 2005.

   [RFC4284]  Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity
              Selection Hints for the Extensible Authentication Protocol
              (EAP)", RFC 4284, January 2006.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

8.2.  Informative References

   [I-D.arkko-eap-service-identity-auth]
              Arkko, J. and P. Eronen, "Authenticated Service Identities
              for the Extensible Authentication Protocol  (EAP)",
              draft-arkko-eap-service-identity-auth-04 (work in



Arkko, et al.            Expires April 26, 2007                [Page 24]


Internet-Draft          Network Discovery and PS            October 2006


              progress), October 2005.

   [I-D.groeting-eap-netselection-results]
              Tschofenig, H., "Network Selection Implementation
              Results", draft-groeting-eap-netselection-results-00 (work
              in progress), July 2004.

   [I-D.ietf-pana-pana]
              Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
              Yegin, "Protocol for Carrying Authentication for Network
              Access (PANA)", draft-ietf-pana-pana-11 (work in
              progress), March 2006.

   [I-D.josefsson-pppext-eap-tls-eap]
              Josefsson, S., Palekar, A., Simon, D., and G. Zorn,
              "Protected EAP Protocol (PEAP)",
              draft-josefsson-pppext-eap-tls-eap-07 (work in progress),
              October 2003.

   [I-D.marques-ddp]
              Enns, R., Marques, P., and D. Morrell, "Device Discovery
              Protocol (DDP)", draft-marques-ddp-00 (work in progress),
              May 2003.

   [I-D.tschofenig-eap-ikev2]
              Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method (EAP-
              IKEv2)", draft-tschofenig-eap-ikev2-10 (work in progress),
              February 2006.

   [IEEE.8021X]
              Institute of Electrical and Electronics Engineers, "Local
              and Metropolitan Area Networks: Port-Based Network Access
              Control", IEEE Standard 802.1X, September 2001.

   [IEEE.802.11-2003]
              Institute of Electrical and Electronics Engineers,
              "Wireless LAN Medium Access Control (MAC) and Physical
              Layer (PHY) Specifications", IEEE Standard 802.11, 2003.

   [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.

   [IEEE.11-04-0624]



Arkko, et al.            Expires April 26, 2007                [Page 25]


Internet-Draft          Network Discovery and PS            October 2006


              Berg, S., "Information to Support Network Selection", IEEE
              Contribution 11-04-0624 2004.

   [IEEE.11-04-0638]
              Aboba, B., "Network Selection", IEEE Contribution 11-04-
              0638 2004.

   [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 Description; Release 6; Stage 2",
              3GPP Technical Specification 23.234 v 6.6.0,
              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.

   [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.




Arkko, et al.            Expires April 26, 2007                [Page 26]


Internet-Draft          Network Discovery and PS            October 2006


   [Fixingapsel]
              Judd, G. and P. Steenkiste, "Fixing 802.11 Access Point
              Selection", Sigcomm Poster Session 2002.

   [Eronen03]
              Eronen, P., "Network Selection Issues", presentation to
              EAP WG at IETF 58, November 2003.

   [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.

   [Eronen04]
              Eronen, P. and J. Arkko, "Role of authorization in
              wireless network security", Extended abstract presented in
              the DIMACS workshop, November 2004.

   [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.11k]
              Institute of Electrical and Electronics Engineers, "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 IEEE 802.11k, D4.1, July 2006.

   [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.

   [RFC4066]  Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E.
              Shim, "Candidate Access Router Discovery (CARD)",
              RFC 4066, July 2005.



Arkko, et al.            Expires April 26, 2007                [Page 27]


Internet-Draft          Network Discovery and PS            October 2006


Appendix A.  Existing Work

A.1.  IETF

   There has already been a lot of past work in this area, including a
   number of IETF Proposed Standards generated by the ROAMOPS WG.  The
   topic of roaming was considered different enough from both AAA and
   access protocols such as PPP that it deserved its own WG.

   In addition to work on ROAMOPS directly relating to the problem,
   there has been work in SEAMOBY relating to scaling of target access
   network discovery mechanisms (which in this context refers to finding
   a suitable base station to attach to); work in PKIX relating to
   identity and credential selection; and work in AAA WG relating to
   access routing.

   The PANA protocol [I-D.ietf-pana-pana] has a mechanism to advertise
   and select "ISPs" through the exchange of the ISP-Information AVP in
   its initial exchange.

   Adrangi et al [RFC4284] define the use of the EAP-Request/Identity
   for identifier selection.  It is necessary to have this kind of a
   mechanism, as clients may have more than one credential, and when
   combined with the '!' syntax for NAIs, it can also be used for
   mediating realm discovery and selection.  The use of lower-layer
   information may also be limited in terms of discovering identifiers
   that are used on the EAP layer.  In the longer term, the use of this
   mechanism may run into scalability problems, however.  As noted in
   [RFC3748] Section 3.1, the minimum EAP 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
   FQDNs to be up to 255 octets in length, this may not enable the
   announcement of many realms.  The use of other network identifiers
   than domain names is also possible, for instance the PANA protocol
   uses an a free form string and an SMI Network Management Private
   Enterprise Code [I-D.ietf-pana-pana], or Mobile Network Codes
   embedded in NAIs as specified in 3GPP.

   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-1999 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) or that the station must associate with each AP
   prior to sending an EAPOL- Start to initiate EAP.  This will



Arkko, et al.            Expires April 26, 2007                [Page 28]


Internet-Draft          Network Discovery and PS            October 2006


   dramatically increase handoff latency.

   The effects on handoff latency depend also on the specific protocol
   design, and the expected likelihood of having to provide
   advertisements and initiate scanning of several APs.  The use of
   advertisements only as a last resort when the AAA routing has failed
   is a better approach than the use of advertisement - scanning
   procedure on every attachment.

   Furthermore, if the AP has not been updated to present an up to date
   set of realms in the EAP-Requests/Identity, after associating to
   candidate APs and then choosing one, it is possible that the station
   will find that the chosen realm is not supported after all.  In this
   case, the station's EAP-Response/Identity may be answered with an
   updated EAP-Request/Identity, adding more latency.  However, it is
   possible to configure APs to pass through all EAP negotiation to a
   local AAA proxy and provision the supported realms there.  This would
   ease the management of larger deployments but at the same time
   require RFC 4284 support from the local AAA proxies.  In general
   upgrading the AAA proxies seems a better approach than upgrading and
   managing all APs.

A.2.  IEEE 802

   There has been work in various IEEE 802 working groups relating to
   network discovery enhancements.

   Some recent and past contributions in this space include the
   following:

   o  [IEEE.802.11-2003] defines the Beacon and Probe Response
      mechanisms used with IEEE 802.11.  Unfortunately, Beacons are only
      sent at the lowest supported rate.  Studies such as [MACScale]
      have identified MAC layer performance problems, and [Velayos] have
      identified scaling issues resulting from a lowering of the Beacon
      interval.

   o  [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 analyze these scalability issues in relation to those
      existing in other alternative solutions, however.




Arkko, et al.            Expires April 26, 2007                [Page 29]


Internet-Draft          Network Discovery and PS            October 2006


   o  [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 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 draft 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.  The
      simulations presented in [Velayos] appear to confirm this
      conclusion; with a Beacon interval of 100 ms, once more than 8
      virtual APs are supported on a single channel, more than 20% of
      bandwidth is used for Beacons alone.  This would indicate a limit
      of approximately 20 virtual APs per physical AP.

   o  IEEE 802.11u group is defining the access realm discovery and
      selection solution as part of its requirements
      [11-05-0822-03-000u-tgu-requirements].  The requirements related
      to realm discovery and selection include the functionality by
      which a station can determine whether its subscription to a
      service provider would allow it to access a particular 802.11
      access network or whether the access network is able to route
      authentication to user's home realm before actually joining a BSS
      within that 802.11 access network.  The mechanism should be able
      to handle multiple credentials from the same user and be able to
      select the correct credentials.  Other planned features would
      allow the station to learn the supported enrollment mechanisms and
      possibly the set of basic services (such as Internet access is
      provided or not) in the access network prior to the user
      authenticating to his or her home realm.

   o  IEEE 802.21 is developing standards to enable handover and
      interoperability between heterogeneous network types including
      both 802 and non 802 networks.  The intention is to provide a
      general information transfer capability for these purposes.  As a
      result, realm discovery process may benefit from such standards.
      Part of handover process is the discovery of candidate access
      networks and selection of an access network for a handover.  The
      IEEE 802.21 group is looking into various information elements
      that can be used to provide sufficient information to either a
      network node or the terminal to make network selection possible.
      Both link layer and layer 3 delivery mechanisms are being looked
      into.  Layer 3 protocol development is being looked into in IETF
      MIPSHOP WG.  Different query mechanisms between the terminal and
      the network, including using of XML or basic TLV type interaction
      are being explored.





Arkko, et al.            Expires April 26, 2007                [Page 30]


Internet-Draft          Network Discovery and PS            October 2006


A.3.  3GPP

   The 3GPP stage 2 technical specification [3GPPSA2WLANTS] covers the
   architecture of 3GPP Interworking WLAN (I-WLAN) with 2G and 3G
   networks.  This specification discusses also realm discovery and
   selection issues.  The I-WLAN realm discovery and selection procedure
   borrows ideas from the cellular side Public Land-based Mobile Network
   (PLMN) selection principles and is referred in 3GPP I-WLAN
   specifications as PLMN Selection.

   In the 3GPP defined cellular network PLMN selection [3GPP.23.122] the
   mobile node monitors surrounding cells and prioritizes them e.g.
   based on signal strength before selecting a new possible target cell.
   Each cell also broadcasts its PLMN information.  A mobile node may
   automatically select cells that belong to its Home PLMN, Registered
   PLMN or to a allowed set of Visited PLMNs.  These lists of PLMNs are
   prioritized and stored in the SIM card.  In a case of manual PLMN
   selection the mobile node lists all PLMNs it knows from the
   surrounding cells and lets the user choose the desired PLMN.  After
   the PLMN has been selected other cell related prioritization takes
   place in order to select the appropriate target cell.

   The [WLAN3G] discuss the new realm (PLMN) selection requirements that
   I-WLAN roaming introduces.  It is necessary to support automatic PLMN
   selection, and not just manual selection by the user.  There may be
   multiple levels of networks, the hotspot owner may have a contract
   with a provider who in turn has a contract with one 3G network, and
   this 3G network has a roaming capability with a number of other
   networks.

   The I-WLAN specification requires that network discovery is performed
   as specified in the standards for the relevant WLAN link layer
   technology.  In addition to network discovery, it is necessary to
   select intermediary networks for the purposes of AAA Routing.  In
   3GPP, these networks are PLMNs.  It is assumed that WLAN networks may
   have a contract with more than one PLMN.  The PLMN may be a Home PLMN
   (HPLMN) or a Visited PLMN (VPLMN) in the roaming case.  GSM/UMTS
   roaming principles are employed for routing AAA requests from the
   VPLMN to the Home Public Land-based Mobile Network (HPLMN) using
   either RADIUS or Diameter.  The procedure for selecting the
   intermediary network has been specified in the stage 3 technical
   specifications [3GPPCT1WLANTS] and [3GPPCT4WLANTS].

   In order to select the PLMN, the following is required:

   o  User may choose the desired HPLMN or VPLMN manually or let the
      WLAN User Equipment (WLAN UE) choose the PLMN automatically based
      on the user and operator defined preferences.



Arkko, et al.            Expires April 26, 2007                [Page 31]


Internet-Draft          Network Discovery and PS            October 2006


   o  AAA messages are routed according to the (root) NAI or decorated
      NAI.

   o  Existing EAP mechanisms are used where possible.

   o  Extensibility is desired, to allow the advertisement of other
      parameters later.  The current network (PLMN) advertisement and
      selection is based on [RFC4284], which currently explicitly
      defines only the advertisement of realms.  However, the RFC4284
      does not prohibit encoding any octet string (as defined in
      [RFC4234]) containing any information parameter into the
      advertisement.

   The 3GPP I-WLAN technical specifications state that advertisement
   information shall be provided only when the access network is unable
   to route the request using normal AAA routing means, such as when it
   sees an unknown NAI realm.  It is also stated that where VPLMN
   control is required, the necessary information is added to a NAI.
   Furthermore, the station (WLAN UE) may manually trigger the network
   (PLMN) advertisement by using Alternative NAI in EAP Request/
   Identity.  The Alternative NAI is guaranteed to be an unknown NAI
   realm throughout all 3GPP networks.

   The security requirements for 3GPP I-WLAN have been specified in the
   3GPP stage 3 technical specification [3GPPSA3WLANTS].  The security
   properties related to different mediating network (PLMN) selection
   mechanisms have been discussed earlier in the 3GPP contribution
   [3GPP-SA3-030736], which concludes that both SSID and EAP-based
   mechanisms have roughly similar (and very limited) security
   properties, and that, as a result, network (PLMN) advertisement
   should be considered only as hints.

A.4.  Other

   [INTELe2e] discusses the need for realm selection in a situation
   where there is more than one available access network with a roaming
   agreement to the home realm.  It also lists EAP-level, SSID-based,
   and PEAP-based mechanisms as potential solutions to the realm
   selection problem.

   Eijk et al [WWRF-ANS] discussed the general issue of network/realm
   selection.  They concentrated primarily on the access network
   discovery problem, based on various criteria, and did not consider
   the other aspects of the network/realm selection problem.
   Nevertheless, they mention that one of the network selection problems
   is that the information about accessibility and roaming relationships
   is not stored in one location, but rather spread around the network.




Arkko, et al.            Expires April 26, 2007                [Page 32]


Internet-Draft          Network Discovery and PS            October 2006


Authors' Addresses

   Jari Arkko
   Ericsson
   Jorvas  02420
   Finland

   Email: jari.arkko@ericsson.com


   Bernard Aboba
   Microsoft
   One Microsoft Way
   Redmond, WA  98052
   USA

   Email: aboba@internaut.com


   Jouni Korhonen
   TeliaSonera
   Teollisuuskatu 13
   Sonera  FIN-00051
   Finland

   Email: jouni.korhonen@teliasonera.com


   Farooq Bari
   Cingular Wireless
   7277 164th Avenue N.E.
   Redmond  WA  98052
   USA

   Email: farooq.bari@cingular.com
















Arkko, et al.            Expires April 26, 2007                [Page 33]


Internet-Draft          Network Discovery and PS            October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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 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 regarding 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 the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Arkko, et al.            Expires April 26, 2007                [Page 34]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/