ietf
[Top] [All Lists]

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

2006-05-29 10:03:18
Lakshminath,

Please see inline... 

-----Original Message-----
From: Lakshminath Dondeti [mailto:ldondeti(_at_)qualcomm(_dot_)com] 
Sent: Friday, May 26, 2006 2:32 PM
To: Avi Lior; Pekka Savola; Sam Hartman
Cc: ietf(_at_)ietf(_dot_)org
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
your company!  In order to sway support towards EAP over HRPD, Qualcom
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(_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