| Re: Issue 376: Proposed Resolution (Section 2.4) | <– Date –> <– Thread –> |
|
From: Bari, Farooq (farooq.bari |
|
| Date: Mon, 26 Feb 2007 15:31:40 -0800 (PST) | |
Hi Bernard, The current text has been there for sometime now- so I do not recall the exact reasoning when it was inserted. I have put in my comments below. BR, Farooq Bari farooq.bari [at] att.com +1 425 580 5526 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] > Sent: Monday, February 26, 2007 7:15 AM > To: eap [at] frascone.com > Subject: Re: [eap] Issue 376: Proposed Resolution (Section 2.4) > > 2.4. Capability Discovery > > Network Capabilities can provide information useful in the selection > process [I-D.groeting-eap-netselection-results]. For instance, > access network discovery may benefit from getting knowledge about the > quality of service available from a particular access network or > node, and AAA routing may require knowledge of roaming agreements. > References [I-D.groeting-eap-netselection-results] and > [IEEE.11-04-0624] describe the following categories of information > which can be discovered: > > [BA] Suggest changing to: > > Network capabilities can provide information useful in the selection > of an access network. These include characteristics of the network > beyond those of individual points of attachment. Network capabilities > which can be discovered include: > > o Access network identification > > [BA] Suggest changing to "Access network identifier (e.g. IEEE 802.11 SSID)" > > o Roaming agreements > > [BA] Suggest changing to "Roaming relationships between the access network > provider and other network providers and associated costs" > > o Authentication mechanisms > > [BA] Not sure what is meant here. Are we talking about discovering > capabilities of individual points of attachment (e.g. support for WEP, > WPA, WPA2, etc.) or are we talking about discovery of EAP authentication > mechanisms? The latter is really a characteristic of the home AAA server, > no? Not sure why item is included in the list. [Bari, Farooq] I think it can be either. 802.21 techniques probably can provide both type of info. I would propose to keep it. > > o Quality of Service > > [BA] Again, I'm not sure whether this is talking about QoS capabilities or > QoS metrics (which would be relevant to selecting a point of attachment), > or something different. While maximum bandwidth or perhaps generic QoS > capabilities (which might or might not be available on all points of > attachment) might be relevant for selecting an access network, QoS metrics > relating to a particular point of attachment seem too specific for that > purpose. [Bari, Farooq] I think the bullet relates to QoS support in the access network as a whole and Access Point is part of it. I think the bullet is generic enough to keep it as is and allow for the solutions to interpret the scope of QoS information that they can provide. > > o Cost > > [BA] Since this is a property of the roaming relationship path, should we > lump this in with roaming information? [Bari, Farooq] I do not have any specific preference but if we roll it up into roaming bullet then maybe we should explicitly indicate that roaming agreement information is not a scalar value. > > o Authorization policy > > [BA] Not sure what this is referring to. If we are talking about > access restrictions, then this is a property of the home AAA server > and should be included in "realm discovery". [Bari, Farooq] not sure what that means either - if no one else has an objection we can remove it from here? > > o Privacy policy > > [BA] Not sure what this is referring to. If we are talking about EAP > method privacy, then this is a property of the home AAA server, and > should be included in "realm discovery". [Bari, Farooq] not sure what that means either - if no one else has an objection we can remove it from here? > > o Service parameters, such as the existence of middleboxes > > The nature of the discovered information can be static, such as the > fastest available transmission speed on a given piece of equipment. > Or it can be dynamic, such as the current load on this equipment. > > [BA] Are dynamic considerations really part of network selection? It > seems to me that those kind of dynamic considerations are too specific > and transient for that purpose, and belong under selection of a > point of attachment. [Bari, Farooq] I think from handoffs perspective current network load/congestion levels would definitely be considered in network selection. Also if the only difference in two available networks is their current load then it should be a factor in network selection. 802.21 based solutions also propose to use such dynamic information. So I propose to keep current text. > > The information can describe something about the network access nodes > themselves, or it can be something that they simply advertise on > behalf of other parts of the network, such as roaming agreements > further in the AAA network. > > Typically, it would be desirable to acquire all this information > prior to the authentication process. In some cases it is in fact > necessary, if the authentication process can not complete without the > information. Reference [IEEE.11-04-0624] classifies the possible > steps at which IEEE 802.11 networks can acquire this information: > > [BA] If network discovery is to be distinct from discovery of points > of attachment and associated capabilities, then it needs to deal with > different aspects. It seems to me that capabilities of individual > network access servers belong with discovery of points of attachment; > in network discovery we are talking about discovery of characteristics > of networks as a whole. [Bari, Farooq] what you said is true in my opinion. > > Suggest changing to: > > Network discovery focuses on the discovery of the services offered > by networks, not just the capabilities of individual points of > attachment. Typically it is desirable to acquire information on > access networks prior to authentication, particularly in situations > where successful authentication depends on that information. > > Reference [IEEE.11-04-0624] classifies the possible > steps at which IEEE 802.11 networks can acquire this information: > > o Pre-association > o Post-association (or pre-authentication) > o Post-authentication > > Note that some EAP methods (such as those defined in > [I-D.josefsson-pppext-eap-tls-eap] [I-D.tschofenig-eap-ikev2] > [I-D.arkko-eap-service-identity-auth]) have an ability to agree about > additional parameters during an authentication process. While such > parameters are useful for many purposes, their use for access network > selection suffers from an obvious chicken-and-egg problem. Or at > least it seems costly to run a relatively heavy authentication > process to decide whether the client wants to attach to this access > network. > > [BA] EAP methods only become relevant once the realm has been selected, so > I'd suggest that this be changed to the following: > > In the interest of minimizing connectivity delays, the > information required for network selection needs to be provided > prior to authentication. By the time authentication occurs, > the node has typically selected the access network, the NAI > to be used to authenticate, as well as the point of attachment. > Should it learn information during the authentication process > that would cause it to revise one or more of those decisions, > the node will need to select a new network, point of attachment, > and/or identity, and then go through the authentication process > all over again. Such a process is likely to be both time > consuming and unreliable. > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/eap > > Arhives: http://lists.frascone.com/pipermail/eap
- Re: Issue 376: Proposed Resolution (Section 2), (continued)
-
Re: Issue 376: Proposed Resolution (Section 2) Bernard Aboba, February 26 2007
-
Re: Issue 376: Proposed Resolution (Section 2.4) Bernard Aboba, February 26 2007
- Re: Issue 376: Proposed Resolution (Section 2.4) Bernard Aboba, February 26 2007
- Re: Issue 376: Proposed Resolution (Section 2.1) Bernard Aboba, February 26 2007
- Re: Issue 376: Proposed Resolution (Section 2.4) Bari, Farooq, February 26 2007
- Re: Issue 376: Proposed Resolution (Section 2.2) Bernard Aboba, February 26 2007
-
Re: Issue 376: Proposed Resolution (Section 2.4) Bernard Aboba, February 26 2007
-
Re: Issue 376: Proposed Resolution (Section 2) Bernard Aboba, February 26 2007
Results generated by Tiger Technologies using MHonArc.