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

[Bari, Farooq (farooq.bari]

Pls see my comments below

-----Original Message-----
From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] On Behalf
Of Adrangi, Farid
Sent: Monday, December 01, 2003 4:08 PM
To: jari.arkko [at] piuha.net
Cc: eap [at] frascone.com; Pasi Eronen
Subject: [eap] RE: network discovery & selection: problem definition


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. 

[FB] My understanding of the problem space we are trying to solve is
that the authentication/authorization is for a particular service that
the user has subscribed to (and not for the user in general who may have
subscription to several services with different identities and
credentials). For a particular service, the user will have only one
credentials and only one home network. So multiple user credentials with
multiple home networks is out of scope of the problem space that we are
trying to address[FB]
 

>    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.

[FB] The number of intermediaries / roaming partners can be
significantly high (e.g. roaming agreements of GSMA operators can be in
hundreds). I would not say more than that here as we are discussing
problem space and not a solution as to how to advertise them. [FB]

>       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.

 [FB] Agree with Farid - 3GPP has considered one level of intermediary
where the intermediary has business (roaming) agreements with both the
WLAN ISP and the home network. [FB]

>    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.

[FB] In the end it is the user who has to pay the bill based on his
agreement with the home operator. Since the intermediary network choice
effects the amount the user/operator has to pay to its roaming partner
(i.e. intermediary), the choice of intermediary really should rest with
the user and the home operator. The access network will not have
information on roaming partners of the home operator and also can not be
expected to make such decisions as it will have conflict of interest to
increase its revenue by trying to sell a more expensive AAA path where
it makes more money (i.e. the home operator pays more). [FB]

>    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.  

[FB] Agree with Farid here. The user (or the device that he is using) is
part of the decision making process. The process can be either automatic
or manual. Also advertisement is only a hint that should be available to
any devices that is try to have access to the network. The actual user
authentication for a service happens after the advertisement and this is
where we need to have security (and that is not part of this draft)[FB]

> 
>       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.
[FB] Agree with Farid - the scope of this draft is specifically on
roaming partner information. It can not be provisioned since it will
only be needed when WLAN ISP does not have any roaming agreement with
the user home operator (so WLAN user device will not be able to know it
upfront). The user expectation will be to have this process automated
and not having to find a piece of advertisements or being informed
offline of a long list of WLAN ISPs roaming partners and then having to
compare it with a long list of his home operator's roaming partners and
then having to find the best match for roaming intermediary [FB]

> 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.

[FB] Agree with Farid [FB]

> 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


_______________________________________________
eap mailing list
eap [at] frascone.com
http://mail.frascone.com/mailman/listinfo/eap