Subject: Re: [eap] proposed resolution to Issue 376 (Section 3)

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 01 Mar 2007 23:04:10 -0800

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.

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

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