Subject: Re: [eap] Proposed Resolution to Issue 376 (Appendix A)

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 04 Mar 2007 15:42:16 -0800

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.

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

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