Re: Issue 376: Proposed Resolution (Section 2.4)
From: Bari, Farooq (farooq.baricingular.com)
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

Results generated by Tiger Technologies using MHonArc.