Subject: [Pana] Issue 136: Clarify network selection relationship with EAP

From: Alper Yegin <[email-masked]>
Date: Thu, 16 Dec 2004 11:12:42 -0800

I just did some editorial massaging on the earlier proposed text. The
technical content should be the same.

http://danforsberg.info:8080/pana-issues/issue136

5.11  Network Selection

PANA discovery and handshake phase allows PaC to learn identity of the
NAP and a list of ISPs that are available through the NAP. PaC can not
only learn the ISPs but also convey the selected ISP explicitly during
the handshake phase. PAA is assumed to be pre-configured with the
information of ISPs that are directly connected to the NAP.

PANA-Start-Request message sent from the PAA MAY contain zero or one
NAP-Information AVP and zero or more ISP-Information AVPs. The PaC MAY
indicate its choice of ISP by including an ISP-Information AVP in the
PANA-Start-Answer message. PaC MAY convey its ISP even when there is no
ISP-Information AVP contained in the PANA-Start-Request message. PaC can
do that only when it is pre-configured with ISP information.

In the absence of an ISP explicitly selected and conveyed by the PaC,
ISP selection is generally performed based on the client identifier
(e.g., using the realm portion of an NAI carried in EAP method). Backend
AAA protocol (e.g., RADIUS) will run between the AAA client on PAA and a
AAA server in the selected ISP domain.

If PaC includes an ISP-Information AVP in PANA-Start-Answer, this is
taken as the client's selected ISP, whereas the realm extracted from the
NAI suggests the client's home AAA domain. In other words, backend AAA
protocol will run between AAA client on PAA and a AAA server suggested
by the client NAI realm through a AAA agent in selected ISP domain. This
approach prevents overloading NAI mechanism for ISP selection. PaC
client can select an ISP independent of the NAI it presents to the
access network. 

Note that this approach may limit the ability of the access network to
use a local AAA proxy for all outgoing AAA 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 further routing.  

An alternative ISP discovery mechanism is outlined in
[I-D.adrangi-eap-network-discovery] which suggests advertising ISP
information in-band with the ongoing EAP method execution. Deployments
using the PANA's built-in ISP discovery mechanism need not use the other
mechanism.

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Dec 2004 04:42:02 -0500

Hi Alper,

> AAA server in the selected ISP domain.

The above paragraph seems to assume that the AAA server is in the
selected ISP domain.  But the AAA server may be in a different ISP
domain from the selected ISP domain in the case of roaming.

> client can select an ISP independent of the NAI it presents to the

The above paragraph seems to assume that the AAA agent (i.e., a AAA
proxy agent, a relay agent or a redirect agent but not a AAA server)
exists in the selected ISP domain.  But the AAA agent may not exist in
the selected ISP domain (and just a AAA server may exist) in single
domain case.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Dec 2004 12:16:17 -0800

Yoshi,

> domain from the selected ISP domain in the case of roaming.

The text is referring to the case where [email-masked] connects to NAP1
to access ISP1. Only ISP1's AAA server can auth/authz [email-masked]. So,
ISP1 must have a AAA server to do that.

Do you have a different scenario in mind?

> the selected ISP domain (and just a AAA server may exist) in single

This time, [email-masked] connects to NAP1 to access ISP2. How can we
realize this if ISP2 does not have a AAA agent?

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Dec 2004 05:45:10 -0500

> Do you have a different scenario in mind?

The user's home ISP may be ISPx (i.e., NAI=[email-masked]) but it
may choose ISP1 that has a roaming relationship with ISPx.  (in this
case, "ISPx" does not need to be advertised in PSR.)

> realize this if ISP2 does not have a AAA agent?

The users's home domain (domain1) *may* be the same as ISP2 in the
above text, where a AAA agent may not be used.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Dec 2004 15:40:50 -0800

> may choose ISP1 that has a roaming relationship with ISPx.  

This is the second case as I described below. In the first case above
there is no explicit ISP selection, it is all in NAI...

> (in this

Sure, that's the case.

> > > > taken as the client's selected ISP, whereas the realm extracted
from
> > the
> > > > NAI suggests the client's home AAA domain. In other words,
backend
> > AAA
> > > > by the client NAI realm through a AAA agent in selected ISP
domain.
> > This

I can add:

Note that in case NAI realm and selected ISP domain are the same, there
would be no separate AAA agent between the AAA client and server.

How is that?

Alper

> 
> Yoshihiro Ohba
> 
> 
> >
> > Alper
> >
> >
> >
> >
> > >
> > > Yoshihiro Ohba
> > >
> > >
> > > >
> > > > Note that this approach may limit the ability of the access
network
> > to
> > > > selection is needed.  This is because the PAA can only affect
the
> > next
> > > > using the PANA's built-in ISP discovery mechanism need not use
the
> > other

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Dec 2004 07:50:43 -0500

> there is no explicit ISP selection, it is all in NAI...

It is all in NAI, but roaming (NAI=[email-masked] but the immediate ISP
for the NAP is ISP1) is still possible even for the first case above,
right?

> would be no separate AAA agent between the AAA client and server.

This is good.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Dec 2004 18:10:26 -0800

> > > > The text is referring to the case where [email-masked] connects
to
> > NAP1
> > > > to access ISP1. Only ISP1's AAA server can auth/authz
[email-masked].
> > So,

The first case is not using PANA's ISP selection mechanism.

So, if NAP1 receives [email-masked], how can it know that the selected
ISP is ISP1? [OK, maybe NAP1 is hardwired to forward ISP1 and ISPx users
to ISP1. Is that it?]

Alper

> > > > > > approach prevents overloading NAI mechanism for ISP
selection.
> > PaC
> > > > > > client can select an ISP independent of the NAI it presents
to
> > the
> > > > > > access network.
> > > > >
> > > > > The above paragraph seems to assume that the AAA agent (i.e.,
a
> > > > This time, [email-masked] connects to NAP1 to access ISP2. How
can
> > we
> > > > > > hop selection at the PAA, and it may not have means to
present a
> > > > "source
> > > > > > [I-D.adrangi-eap-network-discovery] which suggests
advertising
> > ISP

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Dec 2004 22:53:03 -0500

> The first case is not using PANA's ISP selection mechanism.

Right.

> ISP is ISP1? [OK, maybe NAP1 is hardwired to forward ISP1 and ISPx users

Yes, that is the case.

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Sat, 18 Dec 2004 11:04:50 +0200

Yoshihiro Ohba wrote:
>>>>>>>The above paragraph seems to assume that the AAA server is in
>>
>>the
>>
>>>>>>>selected ISP domain.  But the AAA server may be in a different
>>
>>ISP
>>
>>>>This is the second case as I described below. In the first case
>>
>>above
>>

That's right. By the way, I agree with the original text from Alper and the
suggested modifications.

--Jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sun, 19 Dec 2004 21:35:22 -0800

Alper,

I like the text. A few comments below..

> information of ISPs that are directly connected to the NAP.
Nit: The phrase "directly connected" sounds a  bit odd. You mean the ISPs
to which the NAP can route packets to.

> do that only when it is pre-configured with ISP information.
Do we really need the "only" ? Just saying "PaC can do that when it is pre-configured
with ISP information" seems better.

> Note that this approach may limit the ability of the access network to

I am not sure which approach "this" is referring to. Do you mean the
PANA ISP-selection approach ?

> selection is needed. 

I am not sure i understand "limit the ability" ? If not going through
the "local AAA proxy", what other way is possible ? 

>This is because the PAA can only affect the next

> using the PANA's built-in ISP discovery mechanism need not use the other

-mohan

---

From: Alper Yegin <[email-masked]>
Date: Mon, 20 Dec 2004 11:13:11 -0800

> to which the NAP can route packets to.

Or "ISPs that are served by the NAP"

> with ISP information" seems better.

Yes, that's better.

> PANA ISP-selection approach ?

Yes. I shall clarify that.

> the "local AAA proxy", what other way is possible ?

The AAA client running on the NAS can directly talk to AAA proxy on the
selected ISP.... This is what happens when the PaC relays its selected
ISP to PAA.  If you want to insert NAPs AAA proxy in the path, this is
not possible, as there is no way to tell (on the NAS) AAA to go through
AAA proxy in NAP to AAA proxy in selected ISP. There is no such source
routing in AAA protocols.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 20 Dec 2004 11:19:59 -0800

> > ISP is ISP1? [OK, maybe NAP1 is hardwired to forward ISP1 and ISPx
users

This is a mechanism outside NAI and PANA-based schemes. It is possible.
But I don't see what we should be doing about it in the PANA
specification.

Alper