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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf