eap Mailing List: RE: network discovery & selection: problem definition

[Adrangi, Farid (farid.adrangi]

Hi Jari,
Thanks again for starting this thread.  Please see my replies to 
your questions inline - Farooq and Pasi may add/subtract!

BR,
Farid

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko [at] piuha.net] 
> Sent: Friday, November 28, 2003 9:07 AM
> To: eap [at] frascone.com; Adrangi, Farid; Pasi Eronen
> Subject: network discovery & selection: problem definition
> 
> 
> 
> Folks,
> 
> In IETF-58 we discussed network discovery and selection 
> issues, and the straw poll indicated that the WG wants to 
> work on this.
> 
> I'd like initiate a discussion on the problem definition
> for this work before actually adopting it as something that
> the EAP WG intends to standardize. As a result of the 
> discussion, we should know what the issue is, what functions 
> are required, and what constraints should be placed on a 
> potential solution.
> 
> Here is the plan for the discussion:
> 
>   o  All input should be received by December 15. The goal
>      is to have also a common understanding of the problem
>      by then.
> 
>   o  Lets keep the actual solution discussion separate. In
>      other words, lets not talk about the pros and cons of
>      different approaches, or where this functionality should
>      be placed in terms of the network or the protocol stack.
> 
>   o  The results of the discussion will be summarized by
>      the chairs. The need for documentation in the form
>      of a draft will be determined during the process.
> 
>   o  Next steps after this discussion has been concluded
>      include another discussion & possible drafts in the
>      solution space. At that time we also need to make
>      a decision whether the work should stay in the EAP WG
>      or be moved elsewhere.
> 
> The following is my first cut at the problem definition. 
> Comments appreciated -- I'd be happy if you can shoot my 
> definition down. I have included a few questions within the 
> definition -- if you have answers I'm sure the group would 
> like to hear them.
> 
> The primary network discovery and selection issue
> is routing within the AAA infrastructure, giving
> access to the user from the right home AAA and via
> the right AAA proxies. Currently, we have the NAI [RFC2486] 
> functionality. NAIs allow users to specify their domain so 
> that the AAA requests can be routed to the right home AAA 
> servers. However, this does not provide support for the following:
> 
>    o  Ability of the client to know which of his multiple
>       home networks are available from a given access?
>       Can I get to jari.arkko [at] ericsson.com, or only to
>       jarkko [at] piuha.net?
> 

Interesting!  This is not within the scope of the problem defined 
in our draft.  But, I guess the Netowrk Information could help the 
user decide Which identity/credential should be used in cases where
multiple credenticals/identities are installed on the user's device. 

>    o  Ability of the AAA requests to be routed correctly
>       where there is no complete, global AAA routing table.
> 
>       Deployed AAA mechanisms use an essentially
>       statically configured local routing tables,
>       there is no e.g. link state routing protocols
>       for AAA.
> 
>       Such local mechanisms are sufficient when there
>       limited amout of branching in the AAA network.
>       For instance, there is no need for a global
>       routing table if all your clients are either
>       locally authenticated or served by one other entity
>       (such as a global ISP, teleoperator, or a roaming
>       consortium).
> 
>       However, if the access network supports two different
>       intermediaries, it becomes necessary to figure out
>       which intermediary handles the domain given in a NAI.
> 
>       Question: what is the expected number of intermediaries
>       per one network hop? Can you cite current numbers from
>       existing networks, or projections of future network
>       topologies?
> 

Based on the discussions that we had in 3GPP meetings, it is within 
a range of single digit for current deployments, but it could go up
to 50 or so.

>       Question: Is it necessary to support multiple levels
>       of selection, e.g. go first to intermediary 1, then
>       to intermediary 2, etc?
>

3GPP currently is concerned about support for one level Of intermediary.

 
>    o  For commercial reasons, intermediaries want
>       to participate the AAA transaction.
> 
>       Question: Is there a need for someone else than
>       the access network to control the routing to go
>       via a special intermediary? This is not very
>       clear to me.
> 

The access network may not be aware of the user's preference.  The
user is paying the bill, so he should have the ability to influece
routing of the AAA packets through a preferred intermediary to its home
network if it is going to make a differnece in his billing.  I belive
3GPP also has this as a requirement - Farooq can articualte further.
BTW, this does not have to be done manually by the user - it can be
done automatically based the policy installed on the user's device.

>    o  For the purposes of choosing an intermediary
>       with specific properties, users may wish to
>       control network selection, or at least wish
>       to be aware of the results. For instance,
>       I can get to @ericsson.com either via piuha.net
>       or commercialoperator.net, but since I want to
>       go via piuha.net since it is free for me.
> 
>       Question: what are the security requirements for
>       this? This is bordering on solution space, but as
>       far as I know, none of the proposed mechanisms
>       can support secure advertisements or secure
>       selection indications. Is this acceptable?

As you mentioned in one your e-mails, we view this advertisement as 
a hint (nothing more, nothing less).  Note that SSIDs are also used as
hints, and they can be spoofed as well.  

> 
>       Question: what kind of information needs to be
>       presented in protocols vs. provisioned in the
>       clients vs. simply told to the user off-line?
>       It seems that it would be possible to provide
>       network name over protocols, but a standardized
>       format for offered CoS of QoS would probably
>       not be possible.
> 

We are prposing to provide network names over protocols (specifically,
EAP protocol).  Other information can be provisioned in clients 
if needed.


> An interesting twist in the AAA routing problem
> is that all the above has to work for requests, responses,
> as well as server-initiated messages.
>

Yes. So, tt is important for the server to know the AAA routing 
information for a received request.  This may depend on what 
format/syntax is used for NAI decoration.
 
> The network discovery and selection problem is closely
> related to the problem of access point discovery and
> selection in wireless networks. The two problems coincide
> when each access point offers exactly one network over
> one AAA route. However, the network discovery and selection 
> problem may exist even where there is just one access point 
> to attach to, if it offers multiple networks or multiple 
> routes to these networks.
> 

Yes.  My two cents is that we should keep AP selection problems 
separate from intermediary/mediating network selection.  If you 
come up with a single solution that sloves reasonably - that's great!
otherwise, we will end up with two different solutions, one for each.

> During the discussion of solutions for these problems,
> it has become apparent that there are some additional 
> constraints that may have to be placed on solutions. Some of 
> the possible constraints are listed below:
> 
>    o  Solution can be adopted for the whole network
>       without requiring changes to the largest base
>       of installed devices -- access points and
>       clients.
> 
>    o  Allow interoperability with clients, access networks,
>       AAA proxies, and AAA servers that have not been
>       modified to support network discovery and selection.
> 
>    o  Works on all AAA protocols.
> 
>    o  Does not prevent the introduction of new AAA or
>       access network features, such as link-state AAA
>       routing protocols (pretty far fetched) or
>       fast handoffs.
> 
>    o  Does not consume a significant amount of
>       resources, such as bandwidth or network
>       attachment time.
> 
>    o  Does not cause a problem with limited packet
>       sizes of current protocols.
>
> Further discussion can be found from 
> http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-
discovery-and-selection-00.txt
(including some solution space issues too).

--Jari