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

From: "Avi Lior" <[email-masked]>
Date: Fri, 26 May 2006 02:19:58 -0400

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:[email-masked]] 
> Sent: Wednesday, May 24, 2006 3:44 PM
> To: Pekka Savola; Sam Hartman
> Cc: [email-masked]
> 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
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/ietf
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 26 May 2006 11:32:13 -0700

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.  The 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.

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.

This is my last email on this line of arguments.

best regards,
Lakshminath

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 26 May 2006 15:20:59 -0700

> GEE is but a small optional enhancement to address the

What is GEE than? Please explain it to us in terms of RFC 3748.

> So far evaluations done by the broader

Who would that community be?

I have heard the complexity issue from you and few others multiple times,
but there has never been a justification to this claim. 

We are not feeding on complexity, we are not married to it either. If you
can tell us what parts we can simplify, the whole community would be
grateful to you.

Please describe where you see unnecessary complexity, and suggest remedies.

Thanks.

Alper

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 26 May 2006 15:57:44 -0700

>but there has never been a justification to this claim.

Alper,

It's clear now that PANA documents as written are found to be complex 
and with gaps by folks who have spent the time to review them during 
the IETF LC process.  So, whereas there is consensus at WG level as 
determined by Raj and you to forward the documents to the IESG, at 
the IETF LC level, I see that there is no broad consensus as I 
understand the word rough consensus.

>can tell us what parts we can simplify, the whole community would be

I did a review of PANA-IPsec and had several questions and comments, 
but then of course the discussion moved to what does PANA buy more 
than say EAP over IKEv2 and I didn't have a reasonable answer.

Further, my recollection is that several emails in this thread have 
already listed things PANA might do away with to reduce the 
complexity (e.g., one of Jari's emails).

regards,
Lakshminath

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 26 May 2006 16:03:29 -0700

Lakshminath,

Are you aware that you are not answering my question? 

	Please describe where you see unnecessary complexity, and suggest
	remedies.

Noone came near answering these, so throwing the ball to someone else wont
help.

Alper

> Sent: Friday, May 26, 2006 3:58 PM
> To: Alper Yegin
> Cc: [email-masked]
> Subject: Re: Complexity (was RE: The Emperor Has No Clothes: Is PANA
> actually useful?)
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 26 May 2006 16:24:47 -0700

>Noone came near answering these, so throwing the ball to someone else wont

I am not, really.  I am saying that the question has been answered by 
others. For instance, Jari says the following:

"One advice that I would like to give is
to take another look at the ambition level and
scale it down. (Management 101: if you can't
fix it, rip it out.) A solution that does not mix
IP and link layer solutions would be preferrable,
IMHO, and then we would get out of the 802.11
interaction problems. Perhaps lose the EP
separation. Core PANA as a way to run EAP
and confirm possession of the resulting key
would be very useful, IMHO. Tunneling IPsec for
data packets could be optional.

--Jari"

In addition to those I never quite understood the need for NAP and 
ISP authentications and including all that discussion in the main 
protocol, to state one additional concern.

In my secdir review of PANA-IPsec I had the following high-level 
comments (a detailed review is posted on secdir; I am not sure about 
whether you've seen it.  Let me know otherwise):

1. The document should restrict itself to IKEv2 and IPsec as in 4301 
and 4303.  There is also a reference to MOBIKE in PANA protocol, but 
this document doesn't talk about that.  Perhaps that gap needs to be filled.
2. I have suggestions for revision of PSK derivation from the PaC-EP-Master-Key
3. EAP Re-authentication, PSK switch over, new IKEv2 and IPsec 
establishment needs more detailed specification.
4. I have some comments about default crypto algorithms and algorithm agility
5. The security considerations section says, "If the EP does not 
verify whether the PaC is authorized to use an IP address, it is 
possible for the PaC to steal the traffic destined to some other PaC."

This is at best not clear, or perhaps a serious security hole.  It 
appears that either address authorization (CGA?) is needed or a 
particular configuration of IP addresses is needed for IPsec to be effective.

So, in summary, I have really put a lot of time reviewing and reading 
PANA documents before making my statements.  As many have said, if it 
is one or two persons who have some doubts it's one thing.  It looks 
like I am in good company in expressing my opinions.

I am really not going to spend any more *substantial* time on this thread.

regards,
Lakshminath

---

From: "Fleischman, Eric" <[email-masked]>
Date: Fri, 26 May 2006 16:30:45 -0700

Ever since PANA was first proposed, I did not understand why the IETF
accepted it as a work item, because it seemed to me that it was
duplicating existing capabilities (e.g., RADIUS, Diameter, etc.) and
thereby needlessly increasing complexity system-wide.

By this discussion, I surmise that you have greater insights than I.
Hence this question to you:

"What 'bad thing' would happen should PANA not go forward?"

I suspect that this question has been answered many times. But could you
please answer it using simple concepts for the benefit of those of us
who aren't thinking deeply on a sleepy Friday evening? I am particularly
interested in whether you believe end users require PANA and, if so,
why? Thanks!

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 26 May 2006 18:37:56 -0700

> thereby needlessly increasing complexity system-wide.

Sigh.... This is why some people think it creates complexity?

PANA has nothing to do with duplicating RADIUS and Diameter. The relation
between PANA and RADIUS/Diameter is clearly documented across multiple
documents of this WG. For example, the framework document said:

      The PAA consults an authentication server in order to verify the
      credentials and rights of a PaC.  If the authentication server
      resides on the same node as the PAA, an API is sufficient for this
      interaction.  When they are separated (a much more common case in
      public access networks), a protocol needs to run between the two.
      AAA protocols like RADIUS [RFC2865] and Diameter [RFC3588] are
      commonly used for this purpose.

We even illustrated this in the same document:

                                                 RADIUS/
                                                 Diameter/
           +-----+       PANA        +-----+     LDAP/ API    +-----+
           | PaC |<----------------->| PAA |<---------------->| AS  |
           +-----+                   +-----+                  +-----+
              ^                         ^
              |                         |
              |         +-----+         |
         IKE/ +-------->| EP  |<--------+ SNMP/ API
      4-way handshake   +-----+

And we even put this in an FAQ! http://www.panasec.org/docs/PANA-FAQ.txt for
those that don't want to read the documents.

What else should we do? Record a reading of the documents and mail it to
everyone?

These are impossible to miss when someone reads the documents.

As in this, and several other examples in the latest threads, the answers
are there -- when people are looking for answers.

Alper

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 May 2006 21:48:18 -0700

> Noone came near answering these, so throwing the ball to someone else wont

from what I can tell, it does not matter very much that some folks see pana as 
having too much complexity, except to the extent that it affects what does matter.

and what *does* matter quite a bit is that it looks like quite a few folk are 
unclear about the problem papa solves or the way(s) to use it, to achieve that 
solution.

as always, the burden for fixing such problems lies with those promoting the 
specifications.

d/

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 27 May 2006 00:15:40 -0700

> others. For instance, Jari says the following:

Jari's message is the only real attempt. I'm not aware of any other. Can you
give some pointers?
 
> data packets could be optional.

We need to discuss these in more details. Before we jump to pruning
features, we need to first identify the source of complexity in the design,
then discuss if it can be simplified (is that feature really needed, are
there alternatives solutions). Only after then we can decide what to do.
There is necessary complexity, and there is unnecessary complexity.

> protocol, to state one additional concern.

The need is specified in the requirements document (RFC 4058, Section
4.1.1). Having presented EAP-GEE which was driven by a need for
dual-EAP-authentication, you should not be that unclear about this feature.
And if you are familiar with IEEE 802.16e security, dual-EAP is there as
well. In fact, 16e design was influenced by the PANA's dual-EAP design.

Anything else in the PANA protocol design? That's it? This is awfully short
of a list for someone who claims PANA is too complex to be used anywhere.

> whether you've seen it.  Let me know otherwise):

Very recently we got it. Thank you for the review. 

> particular configuration of IP addresses is needed for IPsec to be

Since these are not really about complexity, and in fact mostly not even the
base spec, we'll deal with them in a separate thread.

> like I am in good company in expressing my opinions.

How is it useful if people make subjective claims like "PANA is too complex"
(and carry it to the extent to justify deprecating this effort based on that
claim), without really substantiating it? 

Again, thanks for your time and effort for the PANA-IPsec review!

Alper

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 27 May 2006 08:15:16 -0700

> > protocol, to state one additional concern.

Small clarification, as my statement above is incorrect (apologies 
for the error).  I meant to write: never quite understood the need 
for including the discussion on NAP and ISP authentication in the 
main protocol specification.  I also don't understand the binding 
aspects of the NAP and ISP authentication, but that's an issue I 
already raised on the PANA mailing list.

My point is that including the dual authentication specification in 
the base spec is one that adds to the complexity.  And that actually 
alludes to the point of feature creep.  You understand that several 
folks have trouble seeing the motivation for PANA, and are also 
looking for certain details that are not there; it's easy to see that 
they find some of the features that are already in the spec to be of 
no significance, at least to them.

>well. In fact, 16e design was influenced by the PANA's dual-EAP design.

You probably already know that without GEE, we can still do dual 
authentications!  GEE allows multiple EAP authentications to happen 
in parallel.

>of a list for someone who claims PANA is too complex to be used anywhere.

Alper, I have typed up my review of the PANA-IPsec spec in detail and 
haven't done the same with the others.  But there are other reviews 
on the protocol document and the framework document.  I am not sure I 
am going to find time to write up the issues I have on PANA-PANA and 
PANA-Framework for the next 10 days.  But, you must realize though 
that the points have already been made, if you are willing to take 
the time to go through the reviews, list them in an email and try and 
make an attempt to address them instead of challenging them.

You really have two options:

1. You can continue these threads and respond line by line and pretty 
soon we'll all give up.  I was going to stop with my previous 
message, but I will with this one.  (May clarify if people find 
errors in my logic, but that's about it).  The IESG goes on to make 
the decision.

2. You can really make the effort to look at the reviews and comments 
as the "outsiders' perspective" and try and see what's worth pruning 
and what's worth clarifying further, and then perhaps one or more 
link layer SDOs would find the revised PANA to be attractive enough 
to adopt.  Please believe me when I say that honest attempts were 
made to adopt PANA (I must say that with some architectural 
simplifications in mind).

best wishes,
Lakshminath

---

From: Jari Arkko <[email-masked]>
Date: Sat, 27 May 2006 20:05:50 +0300

>There is necessary complexity, and there is unnecessary complexity.
Right. Let me clarify my original statement: It was expressed in
the context of getting reviews and last call comments with
a number of issues. Of course, if you can address those issues
easily you should do that. But if you hit a problem and do not
make progress in resolving an issue, you (= the WG) should
consider whether some functionality associated with it is
needed.

--Jari

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 29 May 2006 01:48:55 -0700

> the base spec is one that adds to the complexity.  

That is a good and constructive point. We'll re-consider that part of the
design. Thank you.

> And that actually
> alludes to the point of feature creep.  

In the absence of any other technical feedback you are providing on the
complexity matter, I don't see how you jump to such a conclusion...

> You understand that several

I don't know what exactly you are referring to. But at least sticking to the
thread subject, at least provide us what are those features that you think
have no significance? 

> authentications!  GEE allows multiple EAP authentications to happen

I don't know how dual authentications work without GEE. If you care to
explain, feel free to start a separate thread. 

> make an attempt to address them instead of challenging them.

Lakshminath, are you aware that we have responded to all such reviews? In
fact, have you read them? Have you read them and found any issues? They were
sent on the PANA WG and IESG lists. In the absence of a "yes" answer to all
of these questions, I cannot make much sense out of your above statement.

> soon we'll all give up.  

As I had stated at the very beginning of the thread, since you made a
comment about the complexity (to the extent that you recommend this protocol
is not useful), I thought you'd help us identify the exact issues and fix
them. You are not doing that, despite so much e-mailing. 

> I was going to stop with my previous
> and what's worth clarifying further, 

It would help us a lot if you look at the review threads and tell us if we
are missing anything.

Alper

> and then perhaps one or more
> > > > > > > community seem to be concluding that PANA is in fact complex
> and
> > > not
> > > > > > > easily deployable.
> > > > > >
> > > > > >I have heard the complexity issue from you and few others
> multiple
> > > times,
> > > > > >We are not feeding on complexity, we are not married to it
> either. If
> > > you