eap Mailing List: Re: Proposed Resolution to Issue 376 (Appendix A)

[Bernard Aboba (bernard_aboba]

Here is a suggested rewrite of Appendix A:

A.1.  IETF

  Several IETF WGs have dealt with aspects of the network selection
  problem, including the AAA, EAP, PPP, RADIUS, ROAMOPS, and
  RADEXT WGs.

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

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

  However, advertisement mechanisms based on the use of the
  EAP-Request/Identity have scalability problems.  As noted in
  [RFC3748] Section 3.1, the minimum EAP 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 network identifiers other
  than domain names is also possible.

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

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

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

A.2.  IEEE 802

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

  o  [IEEE.802.11-2003] defines the Beacon and Probe Response
     mechanisms within IEEE 802.11.  Unfortunately, Beacons may be
     sent only at a rate within the base rate set, which typically
     consists of the lowest supported rate, or perhaps the next lowest
     rate.  Studies such as [MACScale] have identified MAC layer
     performance problems, and [Velayos] has identified scaling issues
     from a lowering of the Beacon interval.

  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 compare these scalability issues to those of alternative
     solutions, however.

  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 is working on realm discovery and network
     selection [11-05-0822-03-000u-tgu-requirements].  This
     includes a mechanism for enabling a station to determine
     the identities it can use to authenticate to an access network,
     prior to associating with that network.  As noted earlier,
     solving this problem requires the AP to maintain an up to date
     "default free" realm routing table, which is not feasible without
     dynamic routing support within the AAA infrastructure.  Similarly,
     apriori discovery of features supported within home realms (such as
     enrollment) is also difficult to implement in a scalable way,
     absent support for dynamic routing.  Determination of network
     capabilities (such as QoS support) is considerably simpler, since
     these depend solely on the hardware and software contained within
     the AP.

  o  IEEE 802.21 is developing standards to enable handover between
     heterogeneous link layers, including both IEEE 802 and non-IEEE 802
     networks.  To enable this, a general mechanism for capability
     advertisement is being developed, which could conceivably benefit
     aspects of the network selection problem, such as realm discovery.
     For example, IEEE 802.21 is developing Information Elements (IEs) 
which may
     assist with network selection, including information relevant
     to both layer 2 and layer 3.  Query mechanisms (including both
     XML and TLV support) are also under development.

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 also discusses realm discovery and network
  selection issues.  The I-WLAN realm discovery procedure
  borrows ideas from the cellular Public Land-based Mobile Network
  (PLMN) selection principles, known as "PLMN Selection".

  In 3GPP PLMN selection [3GPP.23.122], the mobile node monitors
  surrounding cells and prioritizes them based on signal strength before
  selecting a new potential target cell.  Each cell broadcasts its PLMN.
  A mobile node may automatically select cells that belong to its Home 
PLMN, Registered
  PLMN or an allowed set of Visited PLMNs.  The PLMN lists are
  prioritized and stored in the SIM.  In the case of manual PLMN
  selection, the mobile node lists the PLMNs it learns from
  surrounding cells and enables the user to choose the desired PLMN.  After
  the PLMN has been selected, cell prioritization takes
  place, in order to select the appropriate target cell.

  [WLAN3G] discuss the new realm (PLMN) selection requirements introduced 
by
  I-WLAN roaming, which supports automatic PLMN selection, not just manual 
selection.
  Multiple network levels may be present, and the hotspot owner may have a 
contract
  with a provider who in turn has a contract with a 3G network, which may
  have a roaming agreement with other networks.

  The I-WLAN specification requires that network discovery be performed
  as specified in the relevent WLAN link layer standards.
  In addition to network discovery, it is necessary to
  select intermediary realms to enable construction of source
  routes.  In 3GPP, the intermediary networks are PLMNs, and it is
  assumed that an access network may have a roaming agreement with more
  than one PLMN.   The PLMN may be a Home PLMN (HPLMN) or a Visited
  PLMN (VPLMN), where roaming is supported.  GSM/UMTS
  roaming principles 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 procedure is required:

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

  o  AAA messages are routed based on the decorated or undecorated NAI.

  o  EAP is utilized as defined in [RFC3748] and [RFC3579].

  o  PLMN advertisement and selection is based on [RFC4284], which
     defines only realm advertisement.  The document refers to the
     potential need for extensibility, though EAP MTU restrictions
     make this difficult.

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

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

A.4.  Other

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

  Eijk et al [WWRF-ANS] discusses the realm and network selection
  problem.  The authors concentrate primarily on discovery of
  access networks meeting a set of criteria, noting that information
  on the realm capabilities and reachability inherently resides in
  home AAA servers, and therefore it is not readily available in a central
  location, and may not be easily obtained by NAS devices.