| network discovery & selection: problem definition | <– Date –> <– Thread –> |
|
From: Jari Arkko (jari.arkko |
|
| Date: Fri, 28 Nov 2003 11:11:41 -0600 (CST) | |
Folks,
Here is the plan for the discussion:
o Works on all AAA protocols.
--Jari
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
-
network discovery & selection: problem definition Jari Arkko, November 28 2003
-
Re: network discovery & selection: problem definition Michael Richardson, November 28 2003
-
Re: network discovery & selection: problem definition Jari Arkko, November 28 2003
- Re: network discovery & selection: problem definition Michael Richardson, November 29 2003
- Re: network discovery & selection: problem definition Jari Arkko, November 30 2003
-
Re: network discovery & selection: problem definition Jari Arkko, November 28 2003
-
Re: network discovery & selection: problem definition Michael Richardson, November 28 2003
Results generated by Tiger Technologies using MHonArc.