Avi,
I'd appreciate it if you could refrain from mentioning how representatives
from specific companies spoke in another SDO. In the IETF, we trust each other
to leave our company affiliations at the door. The fact that statements about
the IETF were made elsewhere may be relevant, but who employs the people making
them isn't our concern.
Everybody,
This discussion seems to have gone about as far as is useful. It's not
uncommon in the IETF for the value of ongoing work to be controversial.
I think the WG Chairs and AD concerned have some interesting input to
evaluate at this point.
Brian
Avi Lior wrote:
Lakshminath,
Please see inline...
-----Original Message-----
From: Lakshminath Dondeti [mailto:ldondeti@xxxxxxxxxxxx]
Sent: Friday, May 26, 2006 2:32 PM
To: Avi Lior; Pekka Savola; Sam Hartman
Cc: ietf@xxxxxxxx
Subject: RE: The Emperor Has No Clothes: Is PANA actually useful?
Avi,
EAPoHRPD was designed after a thorough technical evaluation
of PANA proved that the PANA suite of protocols are
unnecessarily complex, and those technical reasons, some of
which you state below, were put forth in front of 3GPP2.
I am very knowledgeable about what happened in 3GPP2 wrt to PANA and EAP
over HRPD.
(Sadly) I would not characterize what happened in 3GPP2 as a thorugh
technical evaluation. Nor would I
characterize that it was proven that PANA was over complex. The
decision taken by 3GPP2 was political. It was based on horse-trading.
As I said before the only "techincal comparison" between PANA and EAP
over HRPD showed the two protocols using the same number of messages.
So the only difference between them was that the PANA messages had the
overhead to be expected from UDP.
debate of course was between PANA and EAPoHRPD, and GEE is
but a small optional enhancement to address the case of
parallel EAP authentications. GEE is not an EAP lower layer
and thus it is invalid to compare it to PANA.
The statement regaring GEE and PANA was not made by me but rather by
XXXXXX! In order to sway support towards EAP over HRPD, XXXXX
made statements that PANA was dead at the IETF and that GEE will be
standardize at the IETF.
I would further say that discounting the technical evaluation
done elsewhere is fine, but an evaluation based on the same
technical drivers (the complexity of PANA vs. EAP over
link-layers) will need to be done in the IETF. So far
evaluations done by the broader community seem to be
concluding that PANA is in fact complex and not easily deployable.
In 3GPP2 deploying EAP over HRPD is not enough. Another proocol was
needed to carry the EAP message to the Authenticator in the PDSN. With
PANA, the EAP message was carried from the Mobile directly to the PDSN.
EAP over HRPD therefore required two portocols. Seems to me that that
is far more complex to deploy then PANA. By the way, the same is true
in WiMAX. PKMV2 only brings the EAP message to the Base Station, WiMAX
had to create another protocol to carry the EAP message to the ASN-GW.
Again, don't count 3GPP2 as part of the broader community. That would
be a missleading. You don't want to misslead people do you?
Hopefully this too will be my last email. But if anyone attemtps to
mischaracterize what happened in 3GPP2 I will be sure to chime in again.
Avi
This is my last email on this line of arguments.
best regards,
Lakshminath
At 11:19 PM 5/25/2006, Avi Lior wrote:
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@xxxxxxxxxxxx]
Sent: Wednesday, May 24, 2006 3:44 PM
To: Pekka Savola; Sam Hartman
Cc: ietf@xxxxxxxx
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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf