Re: [Pana] and network selection

Yoshihiro Ohba <yohba@tari.toshiba.com> Fri, 05 November 2004 23:10 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 SAA29202 for <pana-archive@lists.ietf.org>; Fri, 5 Nov 2004 18:10:13 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQDBL-0004Nm-Ha; Fri, 05 Nov 2004 18:07:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQD1r-0007th-I7 for pana@megatron.ietf.org; Fri, 05 Nov 2004 17:57:59 -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 RAA27959 for <pana@ietf.org>; Fri, 5 Nov 2004 17:57:56 -0500 (EST)
Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQD1r-0006yJ-9m for pana@ietf.org; Fri, 05 Nov 2004 17:58:00 -0500
Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id iA5Mvkbv020452; Sat, 6 Nov 2004 07:57:47 +0900 (JST)
Received: (from root@localhost) by tsb-wall.toshiba.co.jp id iA5MvksS016276; Sat, 6 Nov 2004 07:57:46 +0900 (JST)
Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA16273 ; Sat, 6 Nov 2004 07:57:46 +0900
Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA29165; Sat, 6 Nov 2004 07:57:46 +0900 (JST)
Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id iA5Mvk4j005792; Sat, 6 Nov 2004 07:57:46 +0900 (JST)
Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id iA5MvjuY012628; Sat, 6 Nov 2004 07:57:45 +0900 (JST)
Received: from steelhead ([172.30.24.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0I6Q002HXAG6NL@tsbpo1.po.toshiba.co.jp>; Sat, 6 Nov 2004 07:57:44 +0900 (JST)
Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1CPwuo-0003dF-00; Thu, 04 Nov 2004 21:45:38 -0800
Date: Fri, 05 Nov 2004 00:45:38 -0500
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
Subject: Re: [Pana] and network selection
In-reply-to: <418B77BC.3010301@piuha.net>
To: Jari Arkko <jari.arkko@piuha.net>
Message-id: <20041105054538.GK12214@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset="iso-2022-jp"
Content-disposition: inline
Mail-Followup-To: Jari Arkko <jari.arkko@piuha.net>, Avi Lior <avi@bridgewatersystems.com>, 'Yoshihiro Ohba' <yohba@tari.toshiba.com>, pana@ietf.org
User-Agent: Mutt/1.5.6+20040907i
References: <F17FB067A86B2D488382C923C532EAA7024A4D5C@exch01.bridgewatersys.com> <418B77BC.3010301@piuha.net>
X-Spam-Score: 0.4 (/)
X-Scan-Signature: e367d58950869b6582535ddf5a673488
Cc: 'Yoshihiro Ohba' <yohba@tari.toshiba.com>, pana@ietf.org, Avi Lior <avi@bridgewatersystems.com>
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

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, "jari@isp2.com"), 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


On Fri, Nov 05, 2004 at 02:53:16PM +0200, Jari Arkko wrote:
> 
> 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