Re: The Emperor Has No Clothes: Is PANA actually useful?

Yoshihiro Ohba <yohba@tari.toshiba.com> Sat, 27 May 2006 16:04 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk1Gn-0006yJ-TE; Sat, 27 May 2006 12:04:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk1Gm-0006yE-Ge for ietf@ietf.org; Sat, 27 May 2006 12:04:04 -0400
Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fk1Gl-0007hI-47 for ietf@ietf.org; Sat, 27 May 2006 12:04:04 -0400
Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k4RG3lxw067556; Sat, 27 May 2006 12:03:48 -0400 (EDT) (envelope-from yohba@tari.toshiba.com)
Date: Sat, 27 May 2006 12:03:43 -0400
To: "Narayanan, Vidya" <vidyan@qualcomm.com>
Message-ID: <20060527160343.GB10182@steelhead>
References: <2EBB8025B6D1BA41B567DB32C1D8DB8490B592@NAEX06.na.qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Disposition: inline
In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB8490B592@NAEX06.na.qualcomm.com>
User-Agent: Mutt/1.5.11+cvs20060403
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
X-Dispatcher: imput version 20050308(IM148)
Lines: 113
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Cc: Jari Arkko <jari.arkko@piuha.net>, ietf@ietf.org, Vijay Devarapallli <dvijay@gmail.com>
Subject: Re: The Emperor Has No Clothes: Is PANA actually useful?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

Vidya,

Overall, network access authentication and establishing IPsec SA are
two related but different things.  EAP over IKEv2 is an integrated
approach while PANA framework is a split approach.  In general, both
approaches have pros and cons.  Speaking of the split approach, there
are number of reasons for why splitting is useful:

- If you implement PANA, gateway discovery comes free.  However, the
integrated approach could also define its own gateway discovery
mechanism.

- Since EAP over IKEv2 does not cache EAP keying material or
parameters, when IKE_SA is deleted for many reasons, the client needs
to run EAP over IKEv2 again when a new IKE_SA needs to be established
sometime later.  In PANA case, EAP keying material is cached by PAA as
long as the PANA session remains, and the keying material is reusable
for establishing new IKE_SAs without running another EAP.

- Since EAP over IKEv2 does not cache EAP keying material, when the
client needs to create multiple IKE_SAs for a particular gateway for
many reasons, the client needs to run EAP for each IKE_SA.  In PANA
case, one EAP run is sufficient for establishing multiple IKE_SAs for
the same gateway.

- As Alper already mentioned, since PANA allows PAA and EP to be
separated, one EAP run is sufficient for establishing multiple IKE_SAs
for different gateways (EPs) controlled by the same PAA instead of
running multiple EAP runs for multiple IKE_SAs.

- In an environment where network access authentication is needed but
not IPsec SA (e.g., DSL), EAP over IKEv2 is too much.

Hope this helps,
Yoshihiro Ohba


On Fri, May 26, 2006 at 12:00:31PM -0700, Narayanan, Vidya wrote:
> Hi Jari,
> 
> > 
> > Hi Lakshminath,
> > 
> > > I guess there are differences in our understanding of 3G-WLAN 
> > > interworking (and I could be wrong), but the point is that 
> > they (plan
> > > to) use EAP over IKEv2.  We can try and debate the details 
> > offline, as 
> > > that is not central to the discussion here.
> > 
> > There's no question of whether IKEv2/EAP is being used. 
> > 3G-WLAN interworking is one example, Unlicensed Mobile Access 
> > is another one, what IKEv2/EAP was originally designed for is 
> > corporate VPN access, etc.
> > 
> > But in most of these cases the usage is really VPN like, 
> > i.e., you already have Internet connectivity but to get to a 
> > closed network or service you contact a gateway via IKEv2. 
> > That gateway is often known beforehand and it could be in the 
> > other side of the world.
> > 
> > Access control to get your Internet connectivity is another 
> > matter. 3G-WLAN, for instance, assumes local mechanisms for 
> > that in addition to whatever VPN to the home network.
> > The specs don't really say much about what the local 
> > mechanisms are except that they need to be EAP-based if 
> > authentication via the 3G network is desired. But the 
> > assumption is that on a 802.11 network, 802.11i would get used.
> > 
> 
> 
> I am not sure that the VPN case and the access control in the 3G-WLAN
> case are that different. The VPN access you are describing really
> provides "remote access control". The point of that is that the edge
> equipment is out of control (and potentially untrusted) of the entity
> providing access and hence there is a need for remote access control. It
> is essentially the same scenario for parts of 3G-WLAN interworking. The
> access points may be provided by a vendor that is different from the
> operator and hence, an operator's box is performing "remote access
> control" using IPsec - the method to set up the IPsec SA was chosen to
> be an IKEv2/EAP combination. Of course, in the cases where the WLAN
> equipment can be trusted and is part of the operator's network, 802.11i
> would potentially be used as you say. 
> 
> The only difference in the enterprise WLAN vs 3G-WLAN scenario is that
> the former is providing intranet access, while the latter is for general
> internet access even. However, this is really about semantics. If an
> entity actually receives a valid IP address to use in the local network,
> it only needs to perform IPsec/IKEv2 with the operator's box in the
> 3G-WLAN case for access to home domain services (no different really
> from the corporate VPN case). 
> 
> Vidya
> 
> > This leaves still the question of whether IKEv2/EAP or PANA 
> > could be used to provide access control for the Internet 
> > connectivity. More on that in my other e-mail.
> > 
> > --Jari
> > 
> > 
> > _______________________________________________
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ietf
> > 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

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