Subject: RE: [eap] Issue 287: Roaming Model

From: "Bari, Farooq" <[email-masked]>
Date: Sun, 13 Feb 2005 18:21:38 -0800

I was planning not to respond to this but now that it is listed as a
issue, here is my response.

Glen's scenario
Bigco.com contracts with Consort.com to provide remote access for
Bigco's employees when they are traveling.  Suppose also that
Consort.com is a roaming partner of Megatel.com, which operates hotspots
in coffeehouses around the world.  A Bigco employee using her Bigco.com
user ID, walks into a Megatel hotspot and tries to access the network.

My response
1.	Bigco can have its employee's handsets/laptops provisioned with
a list of its preferred roaming partners lists which in this case would
include Consort.com.
2.	Megatel is a roaming partner of Consort.com and therefore can
advertise Consort.com as its roaming partners if needed.

One possible scenario is that:
The Bigco employee with her Bigco credentials tries to authenticate
herself. Megatel does not recognize her and sends her back list of its
roaming partner and among them is Consort.com. The BigCo employees
client was provisioned with BigCo's preferred roaming partner list and
therefore it recognizes Consort and sends out a response that indicates
its desire to use Consort (as a middle man). The client software
behavior described here is not part of the draft and the client may
decide to behave differently.

Another possible scenarios is 
The Bigco employee upon entering the hotspot facility notices a sign
saying that this Megatel operator faciltiy supports Consort customers as
well. The user from its past experience or from information in its
client software knows that it can use the network via Consort. So the
BigCo employee sends out the first authentication request that includes
the desire that she would like to use Consort (as a middle man). In this
case the first message can be successful and no advertisement would be
needed from MegaTel. Again this client software behavior is not part of
the draft.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Bernard Aboba
> Sent: Sunday, February 13, 2005 12:13 PM
> To: [email-masked]
> Subject: [eap] Issue 287: Roaming Model
> 
> This issue, raised by Glen seems to relate to the roaming model
implicitly
> assumed by this document, and whether it is compatible with the IETF
> roaming model as embodied in the products of the ROAMOPS WG.
> 
> Glen has put forward a basic ROAMOPS roaming scenario, and has
questioned
> whether this scenario is supported by the document.
> 
> Some questions raised by this issue include:
> 
> o Are the roaming model assumptions and limitations clearly
articulated in
>   the document?
> 
> o Is the document capable of supporting basic roaming scenarios, such
as
>   those articulated by Glen as well as other ROAMOPS documents?
> _______________________________________________
> 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: Bernard Aboba <[email-masked]>
Date: Sun, 13 Feb 2005 19:27:21 -0800 (PST)

> a list of its preferred roaming partners lists which in this case would

I think the question is what assumptions this document makes about how AAA
proxy routing tables are transformed into EAP network announcements.
Essentially, what is being defined here is a peer-AAA proxy routing
protocol into which static AAA proxy routes are redistributed.  Once the
peer obtains the routing table, it uses it to form the "source routes"
utilized within the NAI.

Multiple issues are brought up by Glen's comments:

a) Is the roaming model proposed by the document adequately specified and
analyzed?

b) Does the proposed model scale?  What are its limitations?

> herself. Megatel does not recognize her

It would be more clear if you described the scenario in terms of the
entries present in the AAA proxy routing table and the ensuing
announcements.  Are you saying that a bigco.com entry is present in the
routing table, but that this document specifies that a "filter" is to be
applied to that entry so that it is not announced?  Or are you saying that
the entry is not present at all, and therefore is not announced?  There is
a considerable difference between these two scenarios.