Subject: RE: [eap] Re: network discovery & selection: problem definition

From: "Mark Grayson (mgrayson)" <[email-masked]>
Date: Mon, 1 Dec 2003 10:59:50 +0100

Bernard

I would add a further level of decomposition to the section on Network
Discovery to allow separation of the dicovery of the (802.11) access
network and, since this may in turn be a common infrastructure shared
between a numper of service providers, the dicovery of the service
providers using this infrastructure. 

Cheers,
Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bernard Aboba
Sent: 30 November 2003 16:00
To: [email-masked]
Subject: [eap] Re: network discovery & selection: problem definition

I'd suggest that there are three somewhat orthogonal problems being
discussed
under the rubric of "network selection".

First, there is the problem of "Network discovery".  This is the problem
of
discovering access networks available in the vicinity, and the points of
presence (POPs) associated with those networks.

Second, there is the problem of "Identifier selection".  This is the
problem
of selecting which identity (and credentials) to use to authenticate to
a given POP.

Thirdly, there is the problem of "Access routing" which involves
figuring
out how to route the authentication conversation originating from the
selected identity back to the home realm.

Network Discovery
-----------------
Traditionally, the problem of discovering available networks has been
handled out-of-band of EAP.

RFC 2194 describes the pre-provisioning of dialup roaming clients, which
typically included a list of potential phone numbers, updated by the
provider(s) with which the client had a contractual relationship.
RFC 3017 describes the IETF Proposed Standard for the Roaming Access XML
DTD.  This covers not only the attributes of the Points of Presence
(POPs)
and Internet Service Providers (ISPs), but also hints on the appropriate
NAI to be used with a particular POP.

In IEEE 802.11 WLANs, the Beacon/Probe Request/Response mechanism
provides
a way for Stations to discover Access Points (APs), as well as the
capabilities of those APs.  Among the Information Elements (IEs)
included
within the Beacon and Probe Response is the SSID, a non-unique
identifier of
the network to which an Access Point is attached.  By combining network
identification along with capabilities discovery, the Beacon/Probe
facility
provides the information required for both network discovery and roaming
decisions within a single mechanism.

As noted in [Velayos], the Beacon mechanism does not scale well;
with a Beacon interval of 100ms, and 10 APs in the vicinity,
approximately
32 percent of an 802.11b AP's capacity is used for beacon transmission.
In addition, since Beacon/Probe Response frames are sent by each AP over
the
wireless medium,  stations can only discover APs within range, which
implies
substantial coverage overlap for roaming to occur without interruption.

A number of enhancements have been proposed to the Beacon/Probe Response
mechanism in order to improve scalability and roaming performance.
These
include allowing APs to announce capabilities of neighbor APs as well as
their
own, as proposed in IEEE 802.11k; propagation of discovery information
over
IP, as handled in the CARD protocol developed within the IETF SEAMOBY
WG, etc.

Typically scalability enhancement mechanisms attempt to get around
Beacon/Probe
Response restrictions by sending advertisements at the higher rates
which are
enabled one the station has associated with an AP.  Since these
mechanisms
run over IP, they can utilize IP facilities such as fragmentation, which
the
Beacon/Probe Response mechanism cannot.

Identity selection
------------------
As networks proliferate, it becomes more and more likely that a given
EAP
peer may have multiple identities and credential sets, available for use
in different situations.  For example, the EAP peer may have an account
with
one or more Public WLAN providers;  a corporate WLAN;  one or more
wireless
WAN providers. As a result, the EAP peer has to decide which credential
set
to use when presented with a given set of potential EAP authenticators.

Traditionally, hints useful in identity selection have also been
provided
out-of-band.  For example, via the IETF Proposed Standard Roaming Access
XML DTD, a client can select between potential POPs, and then based on
information provided in the DTD, determine the appropriate NAI to use
with the selected POP.

However, it is also possible for hints to be embedded within
credentials.
In [Housley], usage hints are provided within certificates used for
wireless authentication.  This involves extending the certificate to
include
the SSIDs with which the certificate can be used.

Access routing
--------------
Once the identity has been selected, it is necessary for the
authentication
conversation to be routed back to the home realm.  Within the IETF
ROAMOPS
WG, a number of approaches were considered for this, including source
routing
techniques based on the NAI [RFC2486], and techniques relying on the AAA
infrastructure.  Given the relative simplicity of the roaming
implementations
described in RFC 2194,  static routing mechanisms appeared adequate for
the
task and it was not deemed necessary to develop dynamic routing
protocols.

As noted in RFC 2607, RADIUS proxies are deployed not only for routing
purposes,
but also to mask a number of inadequacies in the RADIUS protocol design,
such
as the lack of standarized retransmission behavior and the need for
shared secret
provisioning.

By removing many of the protocol inadequacies, introducing new AAA agent
types such as Redirects, providing support for certificate-based
authentication
as well as inter and intra-domain service discovery, Diameter allows a
NAS
to directly open a Diameter connection to the home realm without having
to
utilize a network of proxies.

This is somewhat analagous to the evolution of email delivery.  Prior to
the
widespread proliferation of the Internet, it was necessary to gateway
between
SMTP-based mail systems and alternative delivery technologies, such as
UUCP
and FidoNet, and email-address based source-routing was used to handle
this.
However, as mail could increasingly be delivered directly, the use of
source
routing disappeared.

As with the selection of certificates by stations, a Diameter client
wishing
to authenticate with a Diameter server may have a choice of available
certificates,
and therefore it may need to choose between them.

References
----------

[Housley] Housley, R., and T. Moore, "Certificate Extensions and
Attributes
Supporting Authentication in PPP and Wireless LAN",
draft-ietf-pkix-wlan-extns-04.txt,
Internet Draft (work in progress), June 2003.

[Mishra] Mishra, A., Shin, M. and W. Arbaugh, "An empirical analysis
of the IEEE 802.11 MAC layer handoff process", University of Maryland
Technical Report, UMIACS-TR-2002-75, 2002.

[Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE
802.11b
MAC Layer Handover Time", Laboratory for Communication Networks, KTH,
Royal Institute of Technology, Stockholm, Sweden, TRITA-IMIT-LCN R 03:02

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Adrangi, Farid" <[email-masked]>
Date: Mon, 1 Dec 2003 16:07:42 -0800

Hi Jari,
Thanks again for starting this thread.  Please see my replies to 
your questions inline - Farooq and Pasi may add/subtract!

BR,
Farid

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Friday, November 28, 2003 9:07 AM
> To: [email-masked]; 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 [email-masked], or only to
>       [email-masked]?
> 

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. 

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

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

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

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

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

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

> 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

---

From: "Adrangi, Farid" <[email-masked]>
Date: Mon, 1 Dec 2003 19:08:04 -0800

Hi Bernard,
I have slightly different way of breaking down the problem 
- maybe we are talking about the same thing and the differences
is in wording it!  As the name implies, the problem has two 
aspects: discovery and selection so maybe it is easier
to understand the problem by describing the purpose of each
aspect.

Purpose of Network Discovery:
----------------------------
1) Discover 802.11 Access Networks within a coverage area.
(Note, although our examples are 802.11, it is applicable to
any access network).

2) Discover Mediating or Service Networks that a given 
802.11 access network is affiliated with.  (Note that POP 
is only know to the Access Network, but mediating networks 
are known to both Access Networks and home service network
because of romaing agreements.)

Purpose of Network Selection:
----------------------------
1) Enable the WLAN client (manually or automatically) to select 
the most appropriate 802.11 Access Network to associate with for
a given "Network Identifier/credential" installed on the client's 
device.

2) The home service network needs to enable a policy mechanism by which
the WLAN client (manually or automatically) can influence the
routing of AAA packets through the preferred Mediating Network to
the WLAN client's home service network.  

Note:  IMO, "Identifier Selection" is an indenpent problem by itself.

Best regards,
Farid

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernard Aboba
> Sent: Sunday, November 30, 2003 8:00 AM
> To: [email-masked]
> I'd suggest that there are three somewhat orthogonal problems 
> being discussed under the rubric of "network selection".
> 
> First, there is the problem of "Network discovery".  This is 
> the problem of discovering access networks available in the 
> vicinity, and the points of presence (POPs) associated with 
> those networks.
> 
> Second, there is the problem of "Identifier selection".  This 
> is the problem of selecting which identity (and credentials) 
> to use to authenticate to a given POP.
> 
> Thirdly, there is the problem of "Access routing" which 
> involves figuring out how to route the authentication 
> conversation originating from the selected identity back to 
> the home realm.
> 
> Network Discovery
> -----------------
> Traditionally, the problem of discovering available networks 
> has been handled out-of-band of EAP.
> 
> RFC 2194 describes the pre-provisioning of dialup roaming 
> clients, which typically included a list of potential phone 
> numbers, updated by the
> provider(s) with which the client had a contractual 
> relationship. RFC 3017 describes the IETF Proposed Standard 
> for the Roaming Access XML DTD.  This covers not only the 
> attributes of the Points of Presence (POPs) and Internet 
> Service Providers (ISPs), but also hints on the appropriate 
> In IEEE 802.11 WLANs, the Beacon/Probe Request/Response 
> mechanism provides a way for Stations to discover Access 
> Points (APs), as well as the capabilities of those APs.  
> Among the Information Elements (IEs) included within the 
> Beacon and Probe Response is the SSID, a non-unique 
> identifier of the network to which an Access Point is 
> attached.  By combining network identification along with 
> capabilities discovery, the Beacon/Probe facility provides 
> the information required for both network discovery and 
> roaming decisions within a single mechanism.
> 
> As noted in [Velayos], the Beacon mechanism does not scale 
> well; with a Beacon interval of 100ms, and 10 APs in the 
> vicinity, approximately 32 percent of an 802.11b AP's 
> capacity is used for beacon transmission. In addition, since 
> Beacon/Probe Response frames are sent by each AP over the 
> wireless medium,  stations can only discover APs within 
> range, which implies substantial coverage overlap for roaming 
> to occur without interruption.
> 
> A number of enhancements have been proposed to the 
> Beacon/Probe Response mechanism in order to improve 
> scalability and roaming performance.  These include allowing 
> APs to announce capabilities of neighbor APs as well as their 
> own, as proposed in IEEE 802.11k; propagation of discovery 
> information over IP, as handled in the CARD protocol 
> developed within the IETF SEAMOBY WG, etc.
> 
> Typically scalability enhancement mechanisms attempt to get 
> around Beacon/Probe Response restrictions by sending 
> advertisements at the higher rates which are enabled one the 
> station has associated with an AP.  Since these mechanisms 
> run over IP, they can utilize IP facilities such as 
> fragmentation, which the Beacon/Probe Response mechanism cannot.
> 
> Identity selection
> ------------------
> As networks proliferate, it becomes more and more likely that 
> a given EAP peer may have multiple identities and credential 
> sets, available for use in different situations.  For 
> example, the EAP peer may have an account with one or more 
> Public WLAN providers;  a corporate WLAN;  one or more 
> wireless WAN providers. As a result, the EAP peer has to 
> decide which credential set to use when presented with a 
> given set of potential EAP authenticators.
> 
> Traditionally, hints useful in identity selection have also 
> been provided out-of-band.  For example, via the IETF 
> Proposed Standard Roaming Access XML DTD, a client can select 
> between potential POPs, and then based on information 
> provided in the DTD, determine the appropriate NAI to use 
> with the selected POP.
> 
> credentials. In [Housley], usage hints are provided within 
> certificates used for wireless authentication.  This involves 
> extending the certificate to include the SSIDs with which the 
> certificate can be used.
> 
> 
> Access routing
> --------------
> authentication conversation to be routed back to the home 
> realm.  Within the IETF ROAMOPS WG, a number of approaches 
> were considered for this, including source routing techniques 
> based on the NAI [RFC2486], and techniques relying on the AAA 
> implementations described in RFC 2194,  static routing 
> mechanisms appeared adequate for the task and it was not 
> deemed necessary to develop dynamic routing protocols.
> 
> As noted in RFC 2607, RADIUS proxies are deployed not only 
> for routing purposes, but also to mask a number of 
> inadequacies in the RADIUS protocol design, such as the lack 
> of standarized retransmission behavior and the need for 
> shared secret provisioning.
> 
> By removing many of the protocol inadequacies, introducing 
> new AAA agent types such as Redirects, providing support for 
> certificate-based authentication as well as inter and 
> intra-domain service discovery, Diameter allows a NAS to 
> directly open a Diameter connection to the home realm without 
> having to utilize a network of proxies.
> 
> This is somewhat analagous to the evolution of email 
> delivery.  Prior to the widespread proliferation of the 
> Internet, it was necessary to gateway between SMTP-based mail 
> systems and alternative delivery technologies, such as UUCP 
> and FidoNet, and email-address based source-routing was used 
> to handle this. However, as mail could increasingly be 
> delivered directly, the use of source routing disappeared.
> 
> As with the selection of certificates by stations, a Diameter 
> client wishing to authenticate with a Diameter server may 
> have a choice of available certificates, and therefore it may 
> need to choose between them.
> 
> References
> ----------
> 
> [Housley] Housley, R., and T. Moore, "Certificate Extensions 
> and Attributes Supporting Authentication in PPP and Wireless 
> LAN", draft-ietf-pkix-wlan-extns-04.txt,
> [Mishra] Mishra, A., Shin, M. and W. Arbaugh, "An empirical 
> analysis of the IEEE 802.11 MAC layer handoff process", 
> University of Maryland Technical Report, UMIACS-TR-2002-75, 2002.
> 
> [Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce 
> IEEE 802.11b MAC Layer Handover Time", Laboratory for 
> Communication Networks, KTH, Royal Institute of Technology, 
> Stockholm, Sweden, TRITA-IMIT-LCN R 03:02
> 
>

---

From: "Bari, Farooq" <[email-masked]>
Date: Tue, 2 Dec 2003 09:09:02 -0800

Pls see my comments below

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrangi, Farid
Sent: Monday, December 01, 2003 4:08 PM
To: [email-masked]
Cc: [email-masked]; Pasi Eronen
Subject: [eap] RE: network discovery & selection: problem definition

Hi Jari,

BR,
Farid

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

[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]

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]

 [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]

>       via a special intermediary? This is not very

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]

[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]

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]

 
> 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

[FB] Agree with Farid [FB]

--Jari

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 8 Dec 2003 10:38:53 -0000

Hi Jari,

Some comments on your questions below ...

<snip - proposed plan for discussion>

I agree with your plan.

>       Can I get to [email-masked], or only to

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

>       existing networks, or projections of future network

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.  

>       of selection, e.g. go first to intermediary 1, then

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.

>       via a special intermediary? This is not very

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.

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

>       format for offered CoS of QoS would probably

Agreed.

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

>       of installed devices -- access points and

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.

--Jari