Subject: [eap] Issue 376: Proposed Resolution (Section 1)

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 25 Feb 2007 15:41:43 -0800

In the next few messages, I will propose specific changes to address Issue 
376.  This message will concentrate on changes to the abstract and Section 
1.  Other messages will deal with other sections of the document.

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.

Suggest changing to:

   When multiple access network are available, roaming
   users may have difficulty in selecting which network
   to connect to, and how to authenticate with that network.
   This document defines the network discovery and
   selection problem, dividing it into multiple sub-problems.
   Some constraints on potential solutions are outlined, and
   the limitations of several solutions (including existing ones)
   are discussed.

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:

[BA] Suggest changing to:

   When multiple access network are available, roaming
   users may have difficulty in selecting which network
   to connect to, and how to authenticate with that network.
   The problem arises when any of the following conditions are
   true:

[BA] The next few paragraphs state conditions under which the problem
can occur, but don't clearly state what bad things will happen in
each circumstance:

   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.

[BA] Suggest changing to:

   o  More than one network attachment point is available, and the
      attachment points differ in capability or belong to different
      operators.  In this case, a roaming user may have difficulty
      determining which attachment points offering the desired services
      it can successfully authenticate to.  In order to choose between
      multiple attachment points, it can be helpful to determine which
      realms are supported and the capabilities that the networks support

   o  The user has multiple sets of credentials.  In this case, the
      user may not be able to determine which credentials to use with
      which attachment point, or even whether any credentials it
      possesses will allow it to authenticate successfully.  This
      can result in multiple unsuccessful authentication attempts
      for each attachment point, wasting valuable time and resulting
      in user frustration.   For example, the user
      could have one set of credentials from a public service provider
      and set from an employer.  In order to choose between multiple
      attachment points, it can be helpful to provide additional
      information to enable the correct credentials to be determined.

   o  There are multiple potential roaming paths between the visited
      realm and the user's home realm, and service parameters or
      pricing differs between them.  In this case, the access network
      may not be able to determine the roaming path that best matches
      the user's preferences.  This can lead to the user being
      charged more than necessary, or not obtaining the desired
      services.  For example, the visited access realm could have
      both a direct relationship with the home realm and an indirect
      relationship through a roaming consortium.  Current 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].  In addition, payload packets can be routed or
      tunneled differently, based on the roaming relationship path.
      This may have an impact on the available services or their
      pricing.

[BA] The next paragraph could be cleaned up a bit:

   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
   access network types and selection of a realm may not imply certain
   network capabilities.

Suggest changing to:

   In Section 2 the network discovery and selection problem is defined
   and divided into subproblems, and some potential 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.

[BA] The following sentences belong in the terminology section:

   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
   access network types and selection of a realm may not imply certain
   network capabilities.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 26 Feb 2007 06:15:08 -0800

Decorated NAI

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

[BA] "RFC4282" -> "RFC 4282"

   Realm

      Realm portion of an NAI [RFC4282].

[BA] Change to "The realm portion of..."

   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.

[BA] I don't understand how network selection can occur at the beginning
of a session -- doesn't it need to occur before the session begins?
Also, I don't understand how network selection can occur during an L2
handoff.  The "realm" of an operator doesn't make sense -- isn't a
realm is a characteristic of the home AAA server? Suggest rewriting to:

      Selection of an operator/ISP for network access.  Network Selection
      occurs prior to network access authentication.

   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.

[BA] Suggest rewriting to:

      The mechanism used to discover available networks. The discovery
      mechanism may be passive or active, and depends on the access
      technology.  In passive network discovery, the node listens for
      network announcements; in active network discovery the node
      solicits network announcements.  It is possible for an access
      technology to utilize both passive and active network discovery
      mechanisms.

   Realm Selection

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

[BA] This doesn't make sense to me -- the realm is a characteristic of
the home AAA server.  Suggest rewriting to:

The selection of the realm (and corresponding NAI) used to access the
network.

   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.

[BA] I would change to:

   Network Access Server

      The device that peers connect to in order to obtain 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.

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 26 Feb 2007 06:26:46 -0800

Section 2

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

The network discovery and selection problem can be broken down into
multiple sub-problems.  These include:

   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 Discovery of points of attachment.  This involves the discovery
of points of attachment in the vicinity, as well as their
capabilities.

o  Identifier selection.  This involves selection of the
NAI (and credentials) used to authenticate to the selected
ponit of attachment.

o  AAA routing. This involves routing of the AAA
conversation back to the home AAA server, based on the realm
of the selected NAI.

o  Payload routing.  This involves the routing of data packets, in
the situation wh ere mechanisms more advanced than destination-based
routing are required.  While this problem is interesting, it is not
discussed further in this document.

   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.

[BA] I'm not sure what "network capability discovery" means.  Is this
about discovery the capabilities of the access network, or of the
home realm?  On the assumption that this is about the home realm,
I suggest that the text be changed to the following:

o Realm capability discovery.  This involves discovering the
capabilities of a home AAA server, such as whether the
home AAA server supports enrollment.

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 26 Feb 2007 07:14:43 -0800

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:

   Network capabilities can provide information useful in the selection
   of an access network.  These include characteristics of the network
   beyond those of individual points of attachment.  Network capabilities
   which can be discovered include:

   o  Access network identification

[BA] Suggest changing to "Access network identifier (e.g. IEEE 802.11 SSID)"

   o  Roaming agreements

[BA] Suggest changing to "Roaming relationships between the access network
provider and other network providers and associated costs"

   o  Authentication mechanisms

[BA] Not sure what is meant here.  Are we talking about discovering
capabilities of individual points of attachment (e.g. support for WEP,
WPA, WPA2, etc.) or are we talking about discovery of EAP authentication
mechanisms?  The latter is really a characteristic of the home AAA server,
no?  Not sure why item is included in the list.

   o  Quality of Service

[BA] Again, I'm not sure whether this is talking about QoS capabilities or
QoS metrics (which would be relevant to selecting a point of attachment),
or something different.  While maximum bandwidth or perhaps generic QoS
capabilities (which might or might not be available on all points of
attachment) might be relevant for selecting an access network, QoS metrics
relating to a particular point of attachment seem too specific for that
purpose.

   o  Cost

[BA] Since this is a property of the roaming relationship path, should we
lump this in with roaming information?

   o  Authorization policy

[BA] Not sure what this is referring to.  If we are talking about
access restrictions, then this is a property of the home AAA server
and should be included in "realm discovery".

   o  Privacy policy

[BA] Not sure what this is referring to.  If we are talking about EAP
method privacy, then this is a property of the home AAA server, and
should be included in "realm discovery".

   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.

[BA] Are dynamic considerations really part of network selection? It
seems to me that those kind of dynamic considerations are too specific
and transient for that purpose, and belong under selection of a
point of attachment.

   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:

[BA] If network discovery is to be distinct from discovery of points
of attachment and associated capabilities, then it needs to deal with
different aspects.  It seems to me that capabilities of individual
network access servers belong with discovery of points of attachment;
in network discovery we are talking about discovery of characteristics
of networks as a whole.

Suggest changing to:

Network discovery focuses on the discovery of the services offered
by networks, not just the capabilities of individual points of
attachment.  Typically it is desirable to acquire information on
access networks prior to authentication, particularly in situations
where successful authentication depends on that 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)
   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.

[BA] EAP methods only become relevant once the realm has been selected, so
I'd suggest that this be changed to the following:

   In the interest of minimizing connectivity delays, the
   information required for network selection needs to be provided
   prior to authentication.  By the time authentication occurs,
   the node has typically selected the access network, the NAI
   to be used to authenticate, as well as the point of attachment.
   Should it learn information during the authentication process
   that would cause it to revise one or more of those decisions,
   the node will need to select a new network, point of attachment,
   and/or identity, and then go through the authentication process
   all over again.  Such a process is likely to be both time
   consuming and unreliable.

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 26 Feb 2007 10:46:09 -0800

BTW, I think this section should be renamed "Network Discovery".

>From: "Bernard Aboba" <[email-masked]>
>To: [email-masked]
>Subject: Re: [eap] Issue 376: Proposed Resolution (Section 2.4)
>Date: Mon, 26 Feb 2007 07:14:43 -0800
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 26 Feb 2007 14:14:55 -0800

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.

   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.

[BA] The above two paragraphs could be combined and tightened up.  See
suggests below.

   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.

[BA] The Beacon/Probe Request provides the SSID, as well as the capabilities
of individual APs.  It does not provide for discovery of network wide
capabilities, per se.  For example, the capabilities of all APs advertising
an SSID need not be identical.  So while this mechanism might enable 
discovery
of a network, it does not enable discovery of the capabilities of that
network, only the discovery of the capabilities of selected APs within that
network.

   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.

   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.

[BA] This paragraph needs to tie the various options back to the different
sub-problems.

Suggest rewriting to:

   Traditionally, discovery of points of attachment has been handled
   by link layer or out-of-band mechanisms.   For example, the
   IEEE 802.11 specification [IEEE-802.11] provides support for both
   passive (Beacon) and active (Probe Request/Response) discovery
   mechanisms; [Fixingapsell] studied the effectiveness of these
   mechanisms.  The GSM specifications [GSM] also provide for
   discovery of points of attachment, as does the CARD [RFC4066]
   protocol developed by the IETF SEAMOBY WG.

   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 and 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.  The Beacon/Probe facility therefore enables network
   discovery, as well as the discovery of points of attachment and
   the capabilities of those points of attachment.

   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.  Another issue with the Beacon and Probe
   Request/Response mechanism is that it is either insecure or
   its security can be assured only as part of authenticating
   to the network (e.g. verifying the advertised capabilities
   within the 4-way handhskae).

   A number of enhancements have been proposed to the Beacon/Probe
   Response mechanism in order to improve scalability and performance
   in roaming scenarios.  These include allowing APs to announce
   capabilities of neighbor APs as well as their own [IEEE.802.11k].
   More scalable mechanisms for support of "virtual APs" within
   IEEE 802.11 have also been proposed [];  generally these proposals
   collapse multiple "virtual AP" advertisements into a single 
advertisement.

   Higher layer mechanisms can also be used to improve
   scalability, since by running over IP they can utilize facilities
   such as fragmentation which may not be available at the link layer.
   For example, in IEEE 802.11, Beacon frames cannot use fragmentation
   because they are multicast frames.

   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.  A single SSID also may 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.

---

From: "Bari, Farooq" <[email-masked]>
Date: Mon, 26 Feb 2007 14:51:43 -0800

Hi Bernard,

I would propose to replace the term "roaming user" with "user" in you
proposed changes as this problem can exist even when the user is not
roaming e.g. when multiple networks with different capabilities exist
with user's home operator at a geographic location. Is that change
acceptable?

BR,
 
Farooq Bari
[email-masked]
+1 425 580 5526
 
> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Sunday, February 25, 2007 3:42 PM
> To: [email-masked]
> Subject: [eap] Issue 376: Proposed Resolution (Section 1)
>

---

From: "Bari, Farooq" <[email-masked]>
Date: Mon, 26 Feb 2007 15:30:09 -0800

Hi Bernard,

The current text has been there for sometime now- so I do not recall the
exact reasoning when it was inserted. I have put in my comments below.

BR,

Farooq Bari
[email-masked]
+1 425 580 5526

> Sent: Monday, February 26, 2007 7:15 AM
> To: [email-masked]
[Bari, Farooq] I think it can be either. 802.21 techniques probably can
provide both type of info. I would propose to keep it.
> relating to a particular point of attachment seem too specific for
that
[Bari, Farooq] I think the bullet relates to QoS support in the access
network as a whole and Access Point is part of it. I think the bullet is
generic enough to keep it as is and allow for the solutions to interpret
the scope of QoS information that they can provide. 
> lump this in with roaming information?
[Bari, Farooq] I do not have any specific preference but if we roll it
up into roaming bullet then maybe we should explicitly indicate that
roaming agreement information is not a scalar value.
> and should be included in "realm discovery".
[Bari, Farooq] not sure what that means either - if no one else has an
objection we can remove it from here?
> should be included in "realm discovery".
[Bari, Farooq] not sure what that means either - if no one else has an
objection we can remove it from here?
> and transient for that purpose, and belong under selection of a

[Bari, Farooq] I think from handoffs perspective current network
load/congestion levels would definitely be considered in network
selection. Also if the only difference in two available networks is
their current load then it should be a factor in network selection.
802.21 based solutions also propose to use such dynamic information. So
I propose to keep current text.
> in network discovery we are talking about discovery of characteristics
[Bari, Farooq] what you said is true in my opinion.

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 26 Feb 2007 17:14:17 -0800

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.

[BA] The above paragraph could use an example describing how the choice
is typically made, in order to introduce the example.

   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

[BA] I think you need to fill in some more details on why the
example above creates a problem.

   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.

[BA] I think we need to provide more information on why out-of-band or 
static configuration is not sufficient.

Suggest rewriting this section to:

2.2.  Identity selection

   As networks proliferate, it becomes more and more likely that a
   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;
   and one or more wireless WAN providers.

   Typically, the user will choose an identity and corresponding credential
   set based on the network chooses to connect to, perhaps with additional
   assistance provided by the chosen authentication mechanism.  For example,
   if EAP-TLS is the authentication mechanism used with a particular
   network, then the user will select the appropriate EAP-TLS client
   certificate based in part on the list of trust anchors provided by
   the EAP-TLS server.

   However, in access networks where roaming is enabled, the mapping
   between an access network and an identity/credential set may not be
   one to one.  For example, it is possible for multiple identities
   to be usable on an access network or for a given identity to
   be usable on a single access network, which may or may not be
   available.

   Figure 1 illustrates a situation where a user identity may
   not be usable on a potential access network.  In this case
   access network 1 enables access to users within the realm
   "isp1.example.com" whereas access network
   3 enables access to users within the realm "corp2.example.com";
   access network 2 enables access to users within 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

   In this situation, a user only possessing an identity within the
   "corp2.example.com" realm can only successfully authenticate to
   access networks 2 or 3;  a user possessing an identity within the
   "isp1.example.com" realm can only successfully authenticate to
   access networks 1 or 2; a user possessing identities within both
   realms can connect to any of the access networks.  The question
   is: how does the user figure out which access networks it can
   successfully authenticate to, preferrably prior to choosing a
   point of attachment?

   Traditionally, hints useful in identity selection have been
   provided out-of-band.  For example, the XML DTD described in
   [RFC3017] enables a client to select between potential
   point of attachment as well as to select the NAI and credentials
   to use in authenticating with it.

   Where all points of attachment within an access network enable
   authentication utilizing a set realms, selection of an access
   network provices knowledge of the identities that a client
   can use to successfully authenticate.  For example, in an
   access network, the set of supported realms corresponding
   to network name can be pre-configured.

   Of course, it may not be possible to determine the available
   access networks prior to authentication.  For example, in
   802.11, not all SSIDs are broadcast, so that the
   station may need to probe to locate a "hidden" SSID.  Also,
   within IKEv2 [RFC4306], the responder identity (typically
   the security gateway) is provided as a part of the IKEv2
   exchange.

   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.

   However, there may be situations in which an access network may
   not 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 may be made available.  In these
   situations, mechanisms such as hints embedded within credentials or
   pre-configuration of access network to realm mappings may not be
   sufficient.  Instead, it is necessary for the client to discover usable
   identities dynamically.

   This is the problem that RFC 4284 attempts to solve, using the
   EAP-Request/Identity to communicate a list of supported realms.
   However, the problems inherent in this approach are many, as
   discussed in Appendix A.1.