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

[Jari Arkko (jari.arkko]

(I am summarizing the network discovery discussion, and responding to a couple
of old e-mails in the process. Pardon me for the delay.)

Mark Watson wrote:

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

Yes, you could classify this as a sub-problem of the AAA intermediary
selection -- particularly if "identifier" includes also the desired
intermediate networks.

> I think in the short/medium term we will be staying with statically 
> configured routing tables just because these tables represent not just 

I agree.

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

While I agree that static tables are more or less sufficient, and will
be the only available tools for some time, I'm not sure I agree that the
business relationship is an issue.

Presumably, you could develop a routing protocol to provide a "network-level"
AAA routing table, based on the "link level connectivity" information i.e.
the business relationships. Access network A has a path to home network H
if and only if for every component X->Y of the path there exists a manually
configured business relationship from X to Y.

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

This may be very hard given the current protocols. At least the
user is typically not told about the path that the AAA packets took,
perhaps this would be easier for the home network to verify. But the
home network on the other hand has no secure information about the
hints that the user provided.

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

Yes. This has significance only if you know Joe. I think Michael and
others who argued for secure network advertisements would like to
enable that you can indeed check the advertisements *if* you know Joe,
but not require that everyone knows Joe.

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

Some of these issues are really hard, and would be best left to
non-protocol means, such as careful users and network monitoring.
But having some tools for the users to verify claims would make
it easier to be a "careful user".

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

Uh.... this may be the hardest requirement. I would actually just
assume all of the information is just hints, and then provide
an optional (and later published) mechanism for verifying claims
made by access points.

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

There is a desire to keep intermediaries stateless, or at least
not require that all of them keep state.

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

Yes, but this is orthogonal to the issue of network selection.

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

Yes.

--Jari