Subject: [eap] Review of draft-groeting-eap-netselection-results-00.txt

From: Bernard Aboba <[email-masked]>
Date: Tue, 27 Jul 2004 12:55:48 -0700 (PDT)

Review of draft-groeting-eap-netselection-results-00.txt

Thank you for this draft.  I think you bring up some interesting points
about the "service selection" aspects of this problem, which isn't
currently included in the Problem Statement document.

For example, in Section 2.1 ,it is stated:

"  As already proposed in [I-D.adrangi-eap-network-discovery] the
   discovery of roaming agreements and mediating networks is a valuable
   access network information.  This can be extended by other access
   network information elements like costs and charging, quality of
   service, authorization information, privacy policy and middlebox
   devices, which help the end host to make his attachment decision."

This paragraph defines the problem as being about "helping the end
host to make his attachment decision".  In the current Problem
Statement we only really talk about problems of Identification, Routing,
Intermediary Network Selection, etc.  Maybe we need to think more
about the extent to which those decisions are intertwined with the
"attachment decisions".

To date, the "attachment decision" has been a lower layer issue.
For example, 802.11 Beacon/Probe Response mechanisms enable the STA
to learn about the AP capabilities, which can include security and
QoS support, supported rates, PHY types, etc.  Inherently information
useful for making "attachment decisions" needs to be known *before* making
those decisions.

IEEE 802.11-2003 defines 3 states:  state 1
(unauthenticated/unassociated), State 2
(authenticated/unassociated), and State 3 (authenticated/associated).
As defined in the standard, within an ESS, data frames may only be
sent within State 3 (within IBSS, they can be sent within state 1
if the "From DS" and "To DS" bits are set to zero).  Given this, 802.11
cannot support sending of EAP/802.1X frames within state 1, except via
pre-authentication.  And since pre-authentication support is optional in
802.11i, even that may not always be available.

Section 2:

"   To support more intelligent end host decisions, it seems to be
   beneficial to discover certain characteristics about the network up
   front during the association and authentication phase.  Such
   information could include authentication models, roaming information,
   quality of service (see Appendix B) and cost parameters (see Appendix
   A)."

Again in this paragraph you raise the issue of what information needs to
be known "up front".  To date, the Problem Statement has assumed that
Network Discovery information could be discovered later, after Association,
but this paragraph seems to imply that this assumption may not be correct.

While "discovery" is something that a STA can engage
in with multiple potential APs (via the Beacon/Probe Response mechanism),
a successful Association-Request binds the STA to a single AP, so
that Association or post-Association frames (such as 802.1X/EAP) cannot
be part of the "discovery" function.

In addition, IEEE 802.11i supports PMK caching and so EAP-based
authentication may only occur on a fraction of all attachment changes, as
you note.

Section 2.1

  "EAP is a generic container protocol that can - in theory - carry any
   information desired by the network (as long as both sides of the
   information exchange understand the information that they are
   receiving)."

I'm not sure that this "theory" is supported by RFC 3748.  For
example, Section 6 states:

"   EAP is not intended as a general-purpose protocol, and allocations
    SHOULD NOT be made for purposes unrelated to authentication."

Further on, it is stated:

  "If information can be carried in identity
   messages, then the end host can make further decisions based on it,
   before the full authentication procedure has been completed (and
   hence probably before accounting has started).  This is particularly
   useful for the case of cost and service availability information."

I think you are making the point that the STA needs information on the
services available and cost prior to making a roaming decision.  To date,
roaming logic has not been specified within 802.11 standards, so this is
breaking some new ground.

Your statements relating to the frequency at which the information is
needed are quite important, I think.   EAP authentication is a high
latency operation, so standards such as 802.11i envisage it being bypassed
in many situations.  Given this, EAP can't really be used for "discovery"
of information which may change between APs, such as base AP capabilities.

For example, a STA roaming within a single SSID may do EAP authentication
once every few hours, but it may need to make roaming decisions very
frequently.  However, it is probably reasonable to assume that a STA will
complete an EAP authentication upon changing networks.  So in terms of
evaluating EAP suitability, it's important to understand whether the
factors you cite (costs, etc.) are expected to change *within* a network.

Of course, the notion of network itself is somewhat shaky in 802.11, so
that it could be argued that there really is no way to tell, since the
SSID is non-unique anyway.

"  As already proposed in [I-D.adrangi-eap-network-discovery] the
   discovery of roaming agreements and mediating networks is a valuable
   access network information.  This can be extended by other access
   network information elements like costs and charging, quality of
   service, authorization information, privacy policy and middlebox
   devices, which help the end host to make his attachment decision."

This again brings up the central question you are raising, which is
whether the Problem Statement for Discovery is really "helping
the end host to make his attachment decision".  If so, then the focus
needs to be on mechanisms which can provide the required information prior
to attachment.  For the reasons I cited, I think this leads us either
toward enabling use of 802.1X/EAP in State 1 (prior to Association, with
"From DS" and "To DS" bits off) or towards a focus on non-EAP based
solutions (either at the 802.11 or 802 layers).

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap