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

[Mark Watson (mwatson]

Title: RE: [eap] network discovery & selection: problem definition

Hi Jari,

Some comments on your questions below ...

<snip - proposed plan for discussion>

I agree with your plan.

>
> 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 question. This is not a requirement that 3GPP have discussed, since a given user identity (IMSI) is associated with a single Home Network.

Bu I wonder if this problem is in fact a sub-problem of the 'AAA intermediary selection' problem when you consider:
a) The AAA server in the WLAN does not know whether the 'next hop' AAA servers that the user requsts routing to is in fact an intermediaries or a home network for this user. The WLAN owner just knows that they have an agreement with this other network which allows them to be paid for users authenticated by that route - this is all they care about.

B) At this stage we are considering user selection only of a single 'hop' for the AAA message

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

I think in the short/medium term we will be staying with statically configured routing tables just because these tables represent not just message routing but business relationships between the various AAA entities. If my AAA server is configured to believe Authentication success messages returning from a someone elses AAA server then I assume I must have some business relationship with that other person which covers:

(i) the effectiveness of the authentication scheme they use
(ii) a commitment to pay for the access used by the people they authenticate

[mayby (i) is their problem, not mine]

It would be difficult to create a system for dynamic update of routing tables which maintained the integrity of these business relationships.

I would usually expect there to be a single intermediary in the path from the local access network to the Home Network. At least this is the 3GPP model. I would envisage that a WLAN hotspot provided would make agreements with several 'local' 3GPP network providers. These local providers act as intermediaries to other 3GPP networks across the world.

I don't rule out the possibility that rather than making these agreements themselves, a hotspot provided might make a single agreement with some single local aggregator who has then the agreements with the various 3GPP networks. But this is just the hotspot owner outsourcing this aspect of the system - it's invisible to the architecture. 

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

I don't think this is necessary. Even if someone found a realistic use-case, I would argue that it's overcomplicated for the first phase of this work.

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

Do you mean, 'why do we need user selection at all?'.

The cost to the user may depend on the intermediary chosen (it depends on the deal made between the chosen intermediary and the Home Network). So then the user should be able to make this choice - presumably based on information obtained (out-of-band) from their Home Network on costs & possibly other factors.

The access network would always choose the intermediary with whom they have struck the 'best deal' - i.e. most expensive for the user.

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

It should be possible for the user/Home network to verify that the request was indeed routed through the user's choice of intermediary.

As for 'securing' network advertisements (including SSIDs etc.) then I'm not sure what this means. The user has no prior relationship with the access network - even if I could be sure that an access network claiming to be 'Joe's access network' really does have that name and that the advertisement has not been modified by anybody else, I am no better off because I do not know if I can trust Joe at all.

A 'rouge' access point might be able to attract authentication attempts with false advertisements, but if they have no relationship with a 'real' intermediary, then they will not be able to provide any service. If they do have a relationship with a 'real' intermediary then their false advertisement will presumably be in breach of that agreement or their agreement with another intermediary.

For example, access networks have an incentive to include false information in the advertisement which directs users to the intermediary that is most lucrative for the access network. This presumably involves including false information about intermediaries which are cheaper for the user, or omitting that information altogether. The cheaper intermediary will not be happy about this, but as for whether we should include mechanisms to help them discover such fraudulent activity, I am not sure.

So, I would suggest we restrict our requirements to verifying that the intermediary used was the one requested by the user.

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

Agreed.

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

I had assumed that once the intial request was sent, this estalishes some kind of 'session state' in the AAA devices so that all subsequent messages related to that initial request follow the same path. Is this not correct ? Do some intemediaries operate in a completely stateless fashion ?

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

Not sure how we could introduce intermediate selection without impacting the clients. For 3GPP, anyway, client impacts are assumed because at least we have to implement EAP-SIM/AKA.

Do you mean that any solution should be backwards compatible with existing clients ? i.e. existing clients can still be supported on a network which also provides advertisements and allows intermediary selection. That would seem essential.

>    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