eap Mailing List: Re: proposed resolution to Issue 376 (Section 3)

[Bernard Aboba (bernard_aboba]

Here are comments on Section 3

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.

[BA] I'm not sure I understand how access network selection can leverage
AAA infrastructure, since this needs to take place prior to authentication.
Proposals such as RFC 4284 do interact with AAA infrastructure for realm
selection, but this has drawbacks as noted in Appendix A.  In any case,
I think the issue here is universality and backward compatibility, not
network selection or realm routing.

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.

[BA] I think we need to be clear exactly what we mean by backward
compatibility.  For example, do we mean that a client that does not
support network selection can work with an access network that
does? Or that AAA infrastructure components that support network
selection can work with legacy infrastructure that doesn't? As the
paragraph currently reads, it is a bit vague.

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.

[BA] I think we are talking about several performance metrics here:
network attachment time, channel utilization (not the same thing as
bandwidth, in the case of discovery mechanisms), energy usage.  These
seem most applicable to the mobile node.  Are there any efficiency
metrics applicable to the AAA infrastructure?

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.

[BA] I am confused by the use of the term "networks" here.  Are we
talking about scaling of network advertisements here (e.g. virtual
APs) or about scaling in terms of realms?

I think we should avoid using the term "advertised" since this
implies a particular solution; maybe "provided in an advertisement,
or in response to query" would be better.  I think the key
characteristic is that we want a solution that does not increase
channel utilization or bandwidth consumption in proportion to the
number of networks or realms that are supported.

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.

[BA] The statement about "no experience" is no longer true -- the
largest public WLAN deployment in the US (T-Mobile) maintains a
phone book listing all APs in their client.  No scaling issues
have been reported, as far as I know, even with support for thousands
of locations.  However, this is a homogeneous network.  Therefore
I think we need to focus the criticism more on the difficulties
introduced by roaming.  For example, even with a phone book, it is
still necesssary for the client to determine if an AP is within
range, so dynamic discovery is still required.  Also, when
roaming is supported, it is typically not possible for the
phone book to remain both comprehensive and up to date.

  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.

[BA] I'm not sure what the problem is, exactly.  Are we saying that
duplicate SSIDs make it difficult to determine which APs are operated
by roaming partners?  Typically the phone book is organized by
link layer identifier (e.g. phone number, BSSID), so that the SSID
is not needed to identify a candidate NAS.

Suggested rewrite:

3.  Design Issues

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

3.1.  AAA Routing

  Solutions to the AAA routing issues discussed in Section 2.3 need
  to apply to a wide range of AAA messages, and should not restrict
  the introduction of new AAA or access network functionality.  For
  example, AAA routing mechanisms should work for access requests
  and responses as well as accounting requests and responses and
  server-initiated messages.  Solutions should not restrict the
  development of new AAA attributes, access types, or performance
  optimizations (such as fast handoff support).

3.2.  Backward Compatibility

  Solutions need to maintain backward compatibility.  In particular:

  * Selection-aware clients need to interoperate with legacy NAS
    devices and AAA servers.

  * Selection-aware AAA infrastructure needs to interoperate with
    legacy clients and NAS devices.

  For example, selection-aware clients should not transmit packets larger
  than legacy NAS devices or AAA servers can handle.  Where protocol
  extensions are required, changes should be required to as few
  infrastructure elements as possible.  For example, extensions that
  require upgrades to existing NAS devices will be more difficult to
  deploy than proposals that are incrementally deployable based on
  phased upgrades of clients or AAA servers.

3.3.  Efficiency Constraints

  Solutions should be efficient as measured by channel
  utilization, bandwidth consumption, handoff delay, and energy
  utilization.  Mechanisms that require depend on multicast
  frames need to be designed with care since multicast frames
  are often sent at the lowest supported rate and therefore consume
  considerable channel time as well as energy on the part of
  listening nodes.  Depending on the deployment, it is possible
  for bandwidth to be constrained both on the link, as well as
  in the backend AAA infrastructure.  As a result, chatty
  mechanisms such as keepalives or periodic probe packets are
  to be avoided.  Given the volume handled by AAA servers,
  solutions should also be conscious of adding to the load,
  particularly in cases where this could enable denial of
  service attacks.  For example, it would be a bad idea for
  a NAS to attempt to obtain an updated realm routing table
  by periodically sending probe EAP-Response/Identity packets
  to the AAA infrastructure in order to obtain "realm hints"
  as described in [RFC4284].  Not only would this add significant
  load to the AAA infrastructure (particularly in cases where
  the AAA server was already overloaded, thereby dropping
  packets resulting in retransmission by the NAS), but it
  would also not provide the NAS with a complete realm
  routing table, for reasons described in Section 2.3.

  Battery consumption is a significant constraint for handheld
  devices.  Therefore mechanisms which require significant
  increases in packets transmitted, or the fraction of time
  during which the host needs to listen (such as proposals
  that require continuous scanning), are to be discouraged.
  In addition, the solution should not significantly impact
  the time required to complete network attachment.

3.4.  Scalability

  Given limitations on frame sizes and channel utilization, it is
  important that solutions scale less than linearly in
  terms of the number of networks and realms supported.  For
  example, solutions such as [RFC4284] increase the size of
  advertisements in proportion to the number of entries in the
  realm routing table.  Similarly, "virtual AP" approaches
  introduce additional Beacons in proportion to the number of
  networks being advertised.  Neither approach scales to
  support a large number of networks and realms.

3.5.  Static Versus Dynamic Discovery

  "Phone-book" based approaches such as [RFC3017] can provide information
  for automatic selection decisions.  While this approach has been
  applied to wireless access, it typically can only be used successfully
  within a single operator or limited roaming partner deployment.  For 
example,
  were a "Phone-Book" approach to attempt to incorporate information
  from a large number of roaming partners, it could become
  quite difficult to keep the information simultaneously comprehensive
  and up to date.  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 it
  difficult to distinguish roaming partner networks by SSID.
  In any case, in wireless networks dynamic discovery
  is a practical requirement since a node needs to know which APs
  are within range before it can connect.