Subject: RE: [Pana] and network selection

From: Avi Lior <[email-masked]>
Date: Thu, 4 Nov 2004 14:06:52 -0500

Hi Yoshihiro,

> Network selection based on EAP occurs always after completion 
> of network selection in PANA in its discovery and handshake 
> phase (this is guaranteed because section 5.12.1 of 
> pana-pana-06 explcitly prohibits piggybacking EAP-Request in 
> PANA-Start-Request messsage). This means that network 
> selection based on EAP is only performed under the chosen ISP.

I am a bit confused here.  So let me ask you a few questions:

What is the purpose of ISP-Information?
How does the PAA know what ISP-Information to provide to the PaC?
If the PAA has a relationship with hunderds of ISPs does it send all the
ISPs?
How does the PaC select which ISP?

Note: the visited network may not have a direct relationship with the home
network 
So it will send a list of intermediaries to the PaC.  The PaC may not be
able to select the intermediaries because it wouldn't necessarily know the
routing.  It knows its home network for sure but it may not know other
relationships.

When we do EAP based authentication in AAA we use the User-Name the NAI to
determine how to route the AAA requests to the Home Network.  How is this
invisioned to work when PANA and AAA work together.

When we do the authentication part, the AAA will use the NAI that was
provided by the device to route the authentication requests.  This may be
totally different then the ISP selected during the discovery phase.

So what is the purpose of doing ISP selection in the discovery phase? 

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Tuesday, November 02, 2004 9:32 PM
> To: Avi Lior
> Cc: 'Alper Yegin'; [email-masked]
> Subject: Re: [Pana] and network selection
> 
> 
> Hi Avi,
> 
> I think network selection in PANA (that is ISP selection) and 
> the network selection based on EAP (that is intermediary network
> selection) does not conflict each other for the following reason:
> 
> Network selection based on EAP occurs always after completion 
> of network selection in PANA in its discovery and handshake 
> phase (this is guaranteed because section 5.12.1 of 
> pana-pana-06 explcitly prohibits piggybacking EAP-Request in 
> PANA-Start-Request messsage). This means that network 
> selection based on EAP is only performed under the chosen ISP.
> 
> I agree that we should clarify somethign like this in the 
> PANA specification draft.
> 
> Regards,
> 
> Yoshihiro Ohba
> 
> 
> On Wed, Nov 03, 2004 at 03:22:46PM -0500, Avi Lior wrote:
> > 
> > Issues with Network Selection.
> > 
> > PANA provides its own network selection and EAP also provides a 
> > network discover mechanism 
> > (draft-adrangi-eap-network-discovery-05.txt)
> > 
> > These may conflict with each other.  Furthermore, the PAA 
> may not know 
> > that the EAP payload contains network discovery material.
> > 
> > What happens if both are used?  Is it something that PANA 
> needs to be 
> > concerned about? Do we need to say something about this in PANA?
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Pana mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pana
> 

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 02 Nov 2004 23:56:17 -0500

Hi Avi,

> What is the purpose of ISP-Information?

It is used by the PaC to choose an ISP.

> How does the PAA know what ISP-Information to provide to the PaC?

It is assumed that the PAA knows which ISPs are available in the
visited network.  The PAA does not have to advertise the list of home
ISPs that are not directly connected to the visited network.

> If the PAA has a relationship with hunderds of ISPs does it send all the

Yes.  But I assume that only the list of ISPs in the visited network
is advertised (not the home ISPs with which the visited network ISPs
have relationship), and I don't think there are hundreds of ISPs in
the visited network in most cases.

> How does the PaC select which ISP?

This is up to implementation.

> Note: the visited network may not have a direct relationship with the home

The home ISP network information is not advertised in PANA, assuming
that the subsribers has a knowledge on which ISP in the visited
network has direct/indirect relationship with its home ISP.

> routing.  It knows its home network for sure but it may not know other

This list of intermediaries are carried in EAP message (note: PANA
itself does not support any intermediaries selection) and this happens
after the PaC chooses an ISP in the visited network through PANA.  So
if you use EAP-based network selection during PANA authentication
phase, you can choose an intermediary in the scope of the chosen ISP.

> invisioned to work when PANA and AAA work together.

You just specify a correct NAI in an EAP-Request/Identity or an EAP
method-specific identity message during PANA authentication phase.

> totally different then the ISP selected during the discovery phase.

When the PaC chooses an ISP, it is the responsibility of the PaC to 
specify an NAI in EAP that is routed correctly through the chosen ISP.

> So what is the purpose of doing ISP selection in the discovery phase? 

To provide the PaC a way to choose an ISP without relying on the
NAI-based selection, which requires different identifies for choosing
different ISPs.  Since PANA has ISP selection mechanism, the PaC can
use the same identity [email-masked] and still choose an ISP among
multiple ISPs, as long as those ISPs have relationship with visa.com.

Regards,

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Fri, 05 Nov 2004 14:53:16 +0200

Hi Avi and Yoshihiro,

It may help to think about PANA as a layer 2 function
for the purposes of this discussion. Layer 2 systems
typically have means for at least rudimentary network
selection. For instance, in 802.11 we have the SSID
which enables a client to pick the right type of a
network, and several such networks might in fact be
co-located in the same equipment. In general, we
expect link layer support for network discovery to
be improved in the future, because without that
other solutions will be inefficient (such as running
EAP towards everyone to find out who we want to
connect to).

The PANA link layer has slightly different mechanisms
than in 802.11. One big difference is that in PANA, you have
a possibility of authenticating twice, both to the access network
and a home operator. So the first observation is that there's
more things to "discover" in PANA than in 802.11 networks.

The second observation is that by their nature, link
layers may not have a lot of information on what
happens in the AAA beyond the first proxy hop.
The third observation is that roaming is important;
I would not like to see a link layer that prevents
roaming beyond what the link layer negotiated for
the "ISP" or "SSID" or whatever at the beginning.

What does this mean for the discussion at hand?
I would classify PANA's network discovery mechanisms
as an enhanced link layer discovery mechanism, and
I like to have such mechanisms. However, we should
also ensure that it is still possible for the user
to select one ISP (say, "isp1") BUT submit a NAI
that is from a roaming partnert of that ISP (say,
"[email-masked]". If this is possible in PANA then
we are fine. If not, we need further discussion.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 05 Nov 2004 00:45:38 -0500

I totally agree with Jari.

Regarding whether it is possible to for the user to select one ISP
(say, "isp1") but submit a NAI that is from a roaming partnert of that
ISP (say, "[email-masked]"), I think section 5.11 of the current PANA
specification needs to be revised to support this case.  Here is my
suggested changes:

[1] Change section 5.11 from:

"
5.11  Network Selection

   In a discovery and handshake phase, a PANA-Start-Request message sent
   from the PAA MAY contain zero or one NAP-Information AVP and zero or
   more ISP-Information AVPs to advertise the information on the NAP
   and/or ISPs.  The PaC MAY indicate its choice of ISP by including an
   ISP-Information AVP in the PANA-Start-Answer message.  When a AAA
   backend is used, the identity of the destination AAA server or realm
   MUST be determined based on the explicitly chosen ISP.  When the
   ISP-Information AVP is not present, the access network MAY rely on
   the client identifier carried in the EAP authentication method to
   make this determination.  The PaC can choose an ISP and contain an
   ISP-Information AVP for the chosen ISP in a PANA-Start-Answer message
   even when there is no ISP-Information AVP contained in the
   PANA-Start-Request message.
"

To:

"
5.11  Network Selection

   In a discovery and handshake phase, a PANA-Start-Request message sent
   from the PAA MAY contain zero or one NAP-Information AVP and zero or
   more ISP-Information AVPs to advertise the information on the NAP
   and/or ISPs.  The PaC MAY indicate its choice of ISP by including an
   ISP-Information AVP in the PANA-Start-Answer message.  The PaC can
   choose an ISP and contain an ISP-Information AVP for the chosen ISP
   in a PANA-Start-Answer message even when there is no
   ISP-Information AVP contained in the PANA-Start-Request message.
   When an ISP-Information AVP is not present in the PANA-Start-Answer
   message, a default ISP is automatically chosen by the PAA.

   When a AAA backend is used, the identity of the destination AAA
   server or realm MAY be determined based on the the client
   identifier carried in the EAP authentication method. If the
   client is a subscriber of another ISP (i.e., the home ISP of the
   client) that has a roaming relationship with the chosen ISP, it can
   specify the realm of the home ISP in the realm part of the client
   identifier.  In the roaming case, the PAA MAY carry 
   ISP-Information AVPs only for ISPs that are directly connected to the
   access network it resides, not for all possible home ISPs.

   In addition to performing network selection by using PANA for
   choosing an ISP, another level of network selection may be
   performed by using EAP for choosing AAA intermediaries
   [I-D.adrangi-eap-network-discovery].  The latter network selection
   occurs over EAP in PANA authentication phase after completion of
   the former network selection in PANA discovery and handshake phase,
   possibly in the scope of the chosen ISP.
"

[2] Add the following reference:

[I-D.adrangi-eap-network-discovery]

  F. Adrangi, et. al, "Identity selection hints for Extensible
  Authentication Protocol (EAP)", adrangi-eap-network-discovery-05
  (work in progress), October 2004.

Regards,

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Sat, 06 Nov 2004 15:56:47 +0200

>    PANA-Start-Request message.

I agree that this needs to be changed.

>    message, a default ISP is automatically chosen by the PAA.

Ok so far.

>    access network it resides, not for all possible home ISPs.

I think you text is in the right direction but I'd prefer
to make it a bit more explicit. I would like to suggest
text but after having thought about this for a while I
was unable to come up with the right text. I guess the
functionality that I'd like to achieve is

- The ISP-Information AVP affects the next hop business
  entity that is chosen.

- The NAI affects the routing beyond this next hop determination.

However, I'm not quite sure how to achieve this. The trivial
answer is that ISP-Information affects the next hop AAA proxy
selection and NAI affects Destination-Realm and the routing
beyond the next hop AAA proxy. However, this does not work in
the case that the access operator wants things to go through
its local proxy first.

>    possibly in the scope of the chosen ISP.

Ok.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 09 Nov 2004 09:52:43 -0500

Hi Jari,

Please see my comments below.

> - The NAI affects the routing beyond this next hop determination.

OK.  How about something like this?

"
When a AAA backend is used, the identity of the destination AAA server
or realm MAY be determined based on the the client identifier carried
in the EAP authentication method.  In this case, the ISP selection
based on ISP-Information AVPs affects the determination of the next
hop in AAA message routing and the rest of the AAA message routing
beyond the next hop is based on the NAI.  If the client is a
subscriber of another ISP (i.e., the home ISP of the client) that has
a roaming relationship with the chosen ISP, it can specify the realm
of the home ISP in the realm part of the client identifier.  In the
roaming case, the PAA MAY carry ISP-Information AVPs only for ISPs
that are directly connected to the access network it resides, not for
all possible home ISPs.
"

> the case that the access operator wants things to go through

This is true.  But I think this limitation is due to using the
realm-based AAA routing.  I think none of network selection solutions
can completely solve this kind of problem.

> >    possibly in the scope of the chosen ISP.

I's further revise text considering the possible selection conflict
between PANA and EAP as pointed out by Avi:

"
In addition to performing network selection by using PANA for choosing
an ISP, another level of network selection may be performed by using
EAP for choosing AAA intermediaries
[I-D.adrangi-eap-network-discovery].  The latter network selection
occurs over EAP in PANA authentication phase after completion of the
former network selection in PANA discovery and handshake phase,
possibly in the scope of the chosen ISP.  There is a possible conflict
if both EAP-based network selection and PANA-based network selection
are used for ISP selection.  Implementations should avoid such
conflict.
"

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Tue, 09 Nov 2004 21:39:31 +0200

Yoshihiro Ohba wrote:

>> I guess the

This sounds good.

> can completely solve this kind of problem.

Hmm.... maybe this is enouh.

> are used for ISP selection.  Implementations should avoid such

Actually, I don't think the conflict really exists, or at least
it does not exist in all cases. For instance, if PANA advertises
isp1 and isp2, two immediate upstream ISPs, then if you select
isp1, it should be perfectly fine and possibly even useful for
isp1 to use EAP to tell the client that there's mediating1 and
mediating2 networks. The user can then choose to give NAI

   [email-masked]

So, from the point of view of PANA, the user is connected
to isp1, but the user's AAA transaction is actually roamed
via mediating2 to isp3.

So I think the original reasons for this issue were from
my point of view the following:

- Exact specification of what ISP-Information affects in terms
  of an AAA request that leaves the box. I believe this is now
  taken care of, using Yoshi's text above.

- Worry that there's some limitation regarding local access network
  proxies. I think I'm beginning to agree that this is just the
  way it is, and we should just document the limitation. Not sure
  if some additional text is needed.

- Worry that there's some conflict between what EAP and PANA
  do. I do not believe such a conflict exists.

- A more high level discussion of what's useful to provide in
  a "L2" access control solution. Everyone agrees that the
  more you have lower in the stack, the better. So its good
  that we have this stuff in PANA. However, I noted some
  potential improvements from a network selection perspective
  in this functionality that could be additional selling points
  for PANA. However, it may well be that the cost of these
  improvements is too great (e.g. additional messages) so that
  they are not worth it. The problem is that the benefits depend
  on the likelihood of needing network selection. If most clients
  need it, then we should optimize for it. If not, we should not.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 09 Nov 2004 23:41:48 -0500

Hi Jari,

On Tue, Nov 09, 2004 at 09:39:31PM +0200, Jari Arkko wrote:

(snip)

> to isp1, but the user's AAA transaction is actually roamed

This is the case where EAP network selection is not used for choosing
the first hop ISPs.  However, by reading
[I-D.adrangi-eap-network-discovery], I see that it is possible to use
EAP network selection for choosing the first hop ISPs as well.  If
this happens (due to misconfiguration of EAP authenticator, etc.),
there can be a conflict and I think this is the issue raised by Avi.

>   if some additional text is needed.

IMHO, it is better to describe this kind of limitation in
draft-ietf-eap-netsel-problem draft because it is general limitation
of realm-based AAA routing.

>   do. I do not believe such a conflict exists.

Please see my comment above.

>   need it, then we should optimize for it. If not, we should not.

Network selection based on unsolicited multicasting (i.e., periodic
multicast) from PAAs might not be good.  This is similar to having a
number of (physical/virtual) APs periodically broadcast different
SSIDs in IEEE 802.11 Beacon messages, which would end up with filling
wireless bandwidth with the Beacons.

Also, I don't see significant difference between multicasting
different ISP information from different PAA and unicasting a list of
ISP information from a single PAA.

What do you think?

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Wed, 10 Nov 2004 14:16:51 +0200

Hi Yoshihiro,

> there can be a conflict and I think this is the issue raised by Avi.

This is true, in a way. But I do not think it actually causes anything
bad in practise. See, the PANA/1X first level selection reduces the
scope of the things you can select. That is, you HAVE already chosen
the first hop ISP. Now, the first hop ISP might announce some additional
first or mediating hop ISPs, but this list is entirely within the
scope of the already chosen first hop. If the first hop ISP announces
any entity that isn't actually routable from it, its going to be a
problem whether or not its first or some other hop. But theoretically,
it would be possible for the first hop to offer a next hop that
had already been offered in PANA. It does not make a lot of sense,
but it would not break anything as far as I can see.

> of realm-based AAA routing.

Actually, I think the issue that interacts with PANA is roaming.
Let me see if I can come up with some text that you could use.
Here's an attempt:

  Note that AAA typically uses the client's NAI to route the
  request to an appropriate home server. PANA's ISP selection
  mechanism does not preclude the use of roaming. That is, the
  realm provided in the NAI may not match the chosen ISP; all
  that is required is that the chosen ISP is capable of routing
  the request to the realm in the NAI. As a result, PANA's
  ISP selection feature does not affect the NAI but rather the
  next hop AAA entity from the PAA. Note that this may limit
  the ability of the access network to use a local AAA proxy
  for all outgoing traffic, assuming ISP selection is needed.
  This is because the PAA can only affect the next hop selection
  at the PAA, and it may not have means to present a "source route"
  to the next hop proxy for doing it in the next step.

> Please see my comment above.

I do not think you need to add anything to the document
based on this. It would at least be inappropriate to
prohibit either mechanism or even prohibit their simultaneous
use.

> wireless bandwidth with the Beacons.

Part of the problem in 802.11 was that you had to do this in different
messages, rather than putting everything in the same beacon.

> ISP information from a single PAA.

That's true.

> What do you think?

Well, its up to you, really. I like "link layers" (I'm
counting network access control in the link layer) where
the client can make as many decisions as possible before
having to send packets. Or have a high decisions/packets
ratio at least. But that's not the only concern. It seems
that the ability of PANA to support multiple ISPs and ASPs
makes it more likely (vs. 802.11) that the link you are
on is the right one. This would seem to support the model
you already have.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 10 Nov 2004 11:00:22 -0500

Hi Jari,

> but it would not break anything as far as I can see.

I understand and I agree with you on this.  I think we can remove text
that talks about the conflict.

>   to the next hop proxy for doing it in the next step.

Thank you very much for providing the text.  I'd reuse the text.

> on is the right one. This would seem to support the model

I'd take this as a rough sign of the agreement on the currently
defined PANA network selection mechanism :)

I'll send revised text in a separate email soon.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 12 Nov 2004 16:35:38 -0800

> that talks about the conflict.

In fact, I'd recommend the EAP ND&S solution I-D to have a discussion on
that. This is more appropriate given the nature of that solution
(workaround ;-) and likelihood of other "EAP lower layers" developing
this functionality, hence causing same/similar concerns. I think the
burden is on that I-D to point that out.

Alper