If I characterize the 3GPP2 decision not to use PANA I would have to say
that it was purely based on Politics and not on technical merits.
The politics included misinformation such as telling operators "That
PANA was dead at the IETF" and that GEE will become a Standard Track RFC
soon.
Other information cited for not using PANA were:
1- EAP typically runs directly over a link layer. See the following text
from RFC 3748:
"EAP typically runs directly over data link layers such as
Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP."
2- HRPD Link Layer satisfies all lower layer requirements as specified
in section 3.1 of RFC 3748; for example, the requirements for lower
layer error detection, minimum MTU, ordering guarantees, etc.
3- PANA is not currently used in any commercial networks (wired or
wireless) such as DSL, PacketCable, WLAN, WiMAX, 3GPP UMTS, etc.
4- PANA is very complex with excessive protocol overhead that makes it
less attractive for use in mobile cellular environments.
5- It's unclear if PANA can reach RFC status within the 3GPP2 designated
time frame due to fundamental issues that are out of control of 3GPP2.
See the companion contribution X31-20060327-030 for a detailed
explanation of various PANA issues.
In particular issue 4, probably the only technical comment was shown by
your own company to be an exageration. The analysis showed that over
the air the number of message exchanges were the same as those needed by
a link layer approach. The only difference was the overhead of the
packet headers, which I would not characterize as excessive protocol
overhead given the context.
The other issues cited have been shown to been inaccurate or baseless in
fact.
But I would say that the political campaign against PANA was executed
flawlessly in 3GPP2.
I hope that the IETF makes its decisions based on technical merits
rather then on the success or failure of political campaigns.
Lets therefore not use PANAs failure in 3GPP2 as an example.
-----Original Message-----
From: Lakshminath Dondeti [mailto:ldondeti(_at_)qualcomm(_dot_)com]
Sent: Wednesday, May 24, 2006 3:44 PM
To: Pekka Savola; Sam Hartman
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: The Emperor Has No Clothes: Is PANA actually useful?
The IETF does publish protocols that may or may not be viable
in the real world. I think PANA, after a significant clean
up, might belong in that category. I, for instance, have the
following high-level issues:
** No real use cases out there, and no real hope either.
3GPP2 HRPD recently joined the growing list of L2
technologies that ruled out PANA.
** EAP over IKEv2 seems like a more viable alternative:
apparently being proposed in 3G-WLAN interworking scenario as
the access auth protocol.
** PANA's notions of EP placement seem vague "the EPs'
location can range from the first-hop router to other routers
within the access network" (I don't want to paste it all
here, but it's Section 7.1 in the framework document). Its
crucial for a protocol that sets out to authenticate clients
to enforce access control, to get the EP placement right.
** PANA has a notion of binding PANA authentication to an
existing secure channel. It is not clear whether it makes
sense and the framework document does not have any convincing
text. That notion introduces more problems than solving any,
I think. Here are some
excerpts: "Networks where a secure channel is already
available prior to running PANA." "The presence of a secure
channel before PANA exchange eliminates the need for
executing a secure association protocol after PANA."
I guess the notion is that the existing secure channel is
authenticated but for a different reason and PANA
authenticates the client again for network access and binds
the "result" using "filters" to that secure channel. Pretty
ad hoc operation, I must say and I think breaks the EAP model.
I can provide a more detailed review, but that's not the
purpose of this thread.
My conclusion is -- stealing Bernard's words -- EAP/IKEv2
will do for what PANA is supposed to support. PANA is not
needed really. But if after clarifications, the WG insists
that the docs be published, I guess the IESG might publish
them as experimental or even move them to historic (not sure
how the latter would work).
regards,
Lakshminath
At 11:27 AM 5/24/2006, Pekka Savola wrote:
On Wed, 24 May 2006, Sam Hartman wrote:
Hi. Speaking as an individual, I'd like to make an
explicit call for
members of the IETF community not involved in the PANA
working group
to review draft-ietf-pana-framework. Please speak up if
you have done
such a review or attempted such a review and been
unsuccessful. Let
us know what you think PANA is intended to be useful for
and whether
you think it is actually useful.
...
FWIW, I do not believe the current framework document as written is
sufficiently clear in order to be able to evaluate where and under
which conditions and assumptions the solution could be deployed.
Therefore it is not feasible to evaluate the usefulness or
applicability of the PANA protocol itself either.
My review is here:
http://www1.ietf.org/mail-archive/web/ietf/current/msg41231.html
There has been some follow-up work to clarify and address these.
Based on the discussion, I fear revision would take
significant cycles,
so the result remains to be seen.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
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