network discovery & selection: problem definition
From: Jari Arkko (jari.arkkopiuha.net)
Date: Fri, 28 Nov 2003 11:11:41 -0600 (CST)
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?

  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?

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

  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.

  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?

     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.

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.

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.

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



Results generated by Tiger Technologies using MHonArc.