eap Mailing List: AW: [eap] Review of draft-groeting-eap-netselection-results-00.tx t

[Berg Stefan ICM Bocholt (stefan.berg]

Thank you for your comments...

Indeed we're looking at the Network Selection Problem from a kind of
"Service Selection" point of view, which is not included in problem
statement document. But, as you already mention, Service Selection is
closely related to the "attachment decision" and thus to the analyzed
problems of Identification, Routing, Intermediary Network Selection, etc. 

Obviously the information needed for the "attachment decision" has to be
known before the decision. This implies a lower layer solution. The reason
why we tried to include access network information in EAP is that EAP is
already widely deployed and would work for various technologies. On the
other hand we see the problems with EAP concerning providing the information
in pre-association, latency and frequency, which needs further
investigation. Looking for the trade-off between having a short term
solution for network discovery and selection, and a long term solution e.g.
a modified 802.1x approach, an EAP extension could partly fill the gap.
Maybe EAP is not the perfect solution, but a starting point to gain
experience and develop a new generic method to exchange access network
information. 

To enable end hosts to make an efficient attachment decision, mechanism to
provide this information prior to attachment are needed. We agree on your
conclusion that either enabling use of 802.1X/EAP in State 1 or non-EAP
based mechanisms (either at the 802.11 or 802 layers) could be a possible
solution. Thus we appreciate the ongoing discussion.

Regards,
Stefan

> -----Ursprüngliche Nachricht-----
> Von: Bernard Aboba [mailto:aboba [at] internaut.com] 
> Gesendet: Dienstag, 27. Juli 2004 21:56
> An: eap [at] frascone.com
> Betreff: [eap] Review of 
> draft-groeting-eap-netselection-results-00.txt
> 
> 
> 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
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>