Re: [Pana] and network selection

Jari Arkko <jari.arkko@piuha.net> Fri, 05 November 2004 12:57 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08661 for <pana-archive@lists.ietf.org>; Fri, 5 Nov 2004 07:57:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ3d6-0001DC-OX; Fri, 05 Nov 2004 07:55:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ3cS-00015l-AX for pana@megatron.ietf.org; Fri, 05 Nov 2004 07:55:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08527 for <pana@ietf.org>; Fri, 5 Nov 2004 07:55:06 -0500 (EST)
Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ3s9-0002Bm-Dy for pana@ietf.org; Fri, 05 Nov 2004 08:11:24 -0500
Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 2E76A8988D; Fri, 5 Nov 2004 14:55:02 +0200 (EET)
Message-ID: <418B77BC.3010301@piuha.net>
Date: Fri, 05 Nov 2004 14:53:16 +0200
From: Jari Arkko <jari.arkko@piuha.net>
Organization: None
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Avi Lior <avi@bridgewatersystems.com>
Subject: Re: [Pana] and network selection
References: <F17FB067A86B2D488382C923C532EAA7024A4D5C@exch01.bridgewatersys.com>
In-Reply-To: <F17FB067A86B2D488382C923C532EAA7024A4D5C@exch01.bridgewatersys.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac
Content-Transfer-Encoding: 7bit
Cc: 'Yoshihiro Ohba' <yohba@tari.toshiba.com>, pana@ietf.org
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jari.arkko@piuha.net
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pana@ietf.org>
List-Help: <mailto:pana-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=subscribe>
Sender: pana-bounces@ietf.org
Errors-To: pana-bounces@ietf.org
Content-Transfer-Encoding: 7bit

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,
"jari@isp2.com". If this is possible in PANA then
we are fine. If not, we need further discussion.

--Jari

Avi Lior wrote:
> 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:yohba@tari.toshiba.com] 
>>Sent: Tuesday, November 02, 2004 9:32 PM
>>To: Avi Lior
>>Cc: 'Alper Yegin'; pana@ietf.org
>>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
>>>Pana@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/pana
>>
> 
> _______________________________________________
> Pana mailing list
> Pana@ietf.org
> https://www1.ietf.org/mailman/listinfo/pana
> 
> 


_______________________________________________
Pana mailing list
Pana@ietf.org
https://www1.ietf.org/mailman/listinfo/pana