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

From: Sam Hartman <[email-masked]>
Date: Wed, 24 May 2006 11:12:04 -0400

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.

My strong hunch is that we've chartered work for some reason, and now
that the working group is nearing the end of its charter, we still
don't understand why we want this thing we've built and whether it's a
good idea.  People aren't screaming not so much because they are happy
with results but because no one actually understands PANA.

I understand that there's a strong presumption that once chartered,
work is useful.  I'd like to challenge this presumption enough to get
people to actually read the document.  If people not involved in the
effort sit down, read the document and understand what it's all about,
my concern is satisfied.  But if enough people try to read the
document, try to understand and fail, we're not done yet.  We
certainly cannot have consensus to publish something we've tried and
failed to understand.

It's not just me.  I've been trying to find people outside of PANA who
claim to understand the effort and what it's good for and why
link-layer solutions are not better.  When the first discussion of
PANA hit the IESG, I asked other IESG members why PANA was a good idea
and what problem it solved.  "Don't go there," was the advice I got
from the responsible AD.

At that time (a year and a half ago) there was no one on the IESG who
claimed to understand PANA or to think it was a good idea.

I'm fairly sure that with the possible exception of Jari (who is a
technical advisor to PANA), that's still true.

The security community has been trying to understand PANA.  I've sent
multiple security reviewers at the PANA document.s They always come
back fundamentally confused about what PANA is trying to do or about
whether it is a good idea.  They end up focusing on some detail or
another and asking for some minor part of the system to be fixed.  But
I don't get the impression from the reviews they understand the
overall picture; explicit discussion of this also indicates that they
are not confident in their understanding nor do they know whether it
is a good idea.

We keep running back over the same ground, still confused and still
trying to muddle through to no real effect.

I've tried to understand it myself.  I tried to understand in the BOF.
It was very clear to me leaving the original PANA BOF that something
was very confused.  Every year or so since I've tried to go back and
figure out what I missed.  Eventually though I've started wondering
whether the problem wasn't me, but was an actual lack of clarity.

So, folks can you please help us all out.  Especially if the internet
area is not your primary focus, especially if you've never heard of
PANA before, take a look at the framework document and all their other
documents.  Do you get it?  Is it a good idea?

Thanks for your time.

P.S.  Again, this is me speaking as an individual.  At this late
stage, it would be entirely inappropriate for me to take actions as an
AD claiming that we didn't understand a problem without a strong
community consensus.

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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 24 May 2006 21:27:12 +0300 (EEST)

> 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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 24 May 2006 21:27:12 +0300 (EEST)

...

My review is here:

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 24 May 2006 12:44:21 -0700

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 clarificatioFrom [email-masked] Wed May 24 15:49:22 2006
Date: Wed, 24 May 2006 12:44:21 -0700
To: Pekka Savola <[email-masked]>, Sam Hartman <[email-masked]>
From: Lakshminath Dondeti <[email-masked]>
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

---

From: "Lucy E. Lynch" <[email-masked]>
Date: Wed, 24 May 2006 12:52:10 -0700 (PDT)

> you think it is actually useful.

Sam -

I don't know if PANA will be useful, but I do know why some 
folks are interested...

Have you taken a look at the I2 NetAuth work:
http://security.internet2.edu/netauth/

These academic networks are interested in both PANA and NEA as part
of their ubiquitous sign-on to R&E networks agenda.

I'm equally confused, but from another direction.

- lel

-- 
Lucy E. Lynch 				Academic User Services
Computing Center			University of Oregon
llynch  @darkwing.uoregon.edu		(541) 346-1774

---

From: Josh Howlett <[email-masked]>
Date: Wed, 24 May 2006 21:22:53 +0100

On 24 May 2006, at 20:52, Lucy E. Lynch wrote:
>
> I don't know if PANA will be useful, but I do know why some folks  
> are interested...
>

While I can't comment on NetAuth, I've been engaged in the Europe's  
equivalent project for HEFE, Eduroam, for the last couple of years  
and to my knowledge we've never discussed PANA (even though at least  
a few of us have been aware of its gestation).

FWIW I've personally never understood what niche(s) PANA was  
expecting to fill, but I assumed it was me being dim.

josh.

Josh Howlett, Networking Specialist, University of Bristol.
email: [email-masked] | phone: +44 (0)7867 907076 |  
interal: 7850

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Wed, 24 May 2006 17:07:05 -0700

> being proposed in 3G-WLAN interworking scenario as the access auth protocol.

the 3G-WLAN interworking scenario is similar to an enterprise user
gaining access to the enterprise via an IPsec gateway. a user who
is subscribed to a mobile operator's services uses IKEv2 with a
VPN-like gateway to access the operator's services. the mode is
different. therefore I don't think this is an alternative to PANA and
shouldn't be confused with PANA.

we could discuss this more, but on a separate thread.

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 25 May 2006 00:52:54 -0700

Hi Sam,

I wish you had approached the PANA WG first to get clarification on your
concerns and questions. And I wish the responsible AD had said "go to PANA
WG" rather than "don't go there" when you consulted him.

Even after the PANA WG was chartered, we went through your suggested
exercise twice with our AD (Thomas Narten), and got the problem statement
approved in RFC 4058.  No conditions have changed since than, so I am not
sure why we need to go through this exercise again at this stage (the
protocol documents passed AD review and getting readied for IESG review). 

I am sure if you ask a broad question like who is confused about a given
protocol, you'd always have many positive answers -- for various reasons.
Not sure if this is helpful. Having basic knowledge about network access
authentication and EAP is a prerequisite for anyone to understand what PANA
really does.

And for the question of where it would be used... One answer is already in
the IETF NEA BoF. It calls for EAPoverL3 transport. And the other answer is
in the DSL networks. If you have access to DSL Forum documents, I recommend
you look at dsl2006.174.02. The document lists requirements for network
access authentication protocol. PANA is a documented candidate and in fact
it is the only one that satisfies all of the requirements. 

I hope these answer your concerns.

Alper

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Wednesday, May 24, 2006 8:12 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: The Emperor Has No Clothes: Is PANA actually useful?
> 
> 
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 25 May 2006 14:22:59 -0700

At 05:07 PM 5/24/2006, Vijay Devarapallli wrote:
>On 5/24/06, Lakshminath Dondeti <[email-masked]> wrote: > ** 
>EAP over IKEv2 seems like a more viable alternative: apparently > 
>being proposed in 3G-WLAN interworking scenario as the access auth 
>protocol. the 3G-WLAN interworking scenario is similar to an 
>enterprise user gaining access to the enterprise via an IPsec 
>gateway. a user who is subscribed to a mobile operator's services 
>uses IKEv2 with a VPN-like gateway to access the operator's 
>services. the mode is different. therefore I don't think this is an 
>alternative to PANA and shouldn't be confused with PANA. we could 
>discuss this more, but on a separate thread. Vijay </x-flowed>

Hi,

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.

regards,
Lakshminath

---

From: Jari Arkko <[email-masked]>
Date: Fri, 26 May 2006 15:34:18 +0300

Sam,

I think your note is asking in fact a number of questions:

1. Is the concept of EAP-authentication over IP for network
    access useful, as opposed to link layer mechanisms?

2. Is the PANA realization of this idea good, and
    are the documents satisfactory?

3. Is there a specific real-world case where PANA is being
    applied or will be applied?

4. What other alternatives exist for the same function
    and how do they compare to PANA?

Re 1: I do believe an IP layer solution in this space
is potentially useful. Not as something that replaces
existing link layer solutions and takes over the market,
but there are situations where it would be useful,
for instance over link layers that have no such support,
as a solution for networks where you just want to add
a node in the middle of the access network without updating
all access points (kind of like a replacement for weblogin
but without the need for user intervention), etc.

Re: 2: Here there are some issues, clearly. Defining
a mechanism that works well in the IP layer does take
some considerable care for discovery, local IP address,
binding of the EAP to what is being done, etc. reasons.
Even if you didn't have these complications, the task
of getting all details right takes a long time, just
witness how long 802.11i took. The task becomes
even harder if you try cover situations that involve distributed
implementation, allowances for different pluggable
components, different environments, etc. This may be
the root cause why we are in this discussion. Without "the
target" WGs want to shoot for maximum flexibility, but if they
overdo it they may get too many issues to worry about. And
a lot of baggage to carry around in the protocol. And
it for sure makes it hard to read the specs.

Having said the above, I'm not sure there are any
fundamental, unfixable problems in the protocol.
The base protocol itself looks solid.

Re: 3: This has been a long standing issue for the WG's
results. I don't have much to add what was already said by
others; in general, many of the specific technologies
like 3GPP cellular or 802.11 employ their own link-layer
solutions and the vendors tend to go with these. But
I also know that PANA had been under serious
consideration at least for 3GPP2 networks.

Re: 4: There are indeed choices. The default assumption
is going to be link layer protection, but as I said
above, there seems to be some scenarios for other
solutions as well. The question is what those solutions
are and how they compare. One alternative is IKEv2
with its EAP support. It comes close to a full solution,
but appears to lack at least discovery functionality
since nomadic clients can't be expected to know the
addresses of gateways in the networks they visit.
But there may be some extension that I'm unaware
of. (Historically, it is interesting to note that the first
IKEv2 drafts started to appear around the time that
PANA got chartered, though it seems that EAP support
was added to IKEv2 only later.)

Another alternative is described in draft-thomson-nacp-02.txt;
this is a bare bones, very simple EAP-over-UDP solution.
I like it, but if it were adopted as an IETF proposed
standard it would probably need to support discovery,
key confirmation and possibly some other things.

PPPoE is an alternative. Propably folks who are doing
this are going to continue using it.

Some other partial solutions exist too. For instance,
PANA has the capability to support authenticating
both to a local network and to a home network;
draft-barany-eap-gee is a solution for that (but
met with some number of questions in the last
EAP meeting).

Is there a winner among the alternatives?
Perhaps too early to tell. I have some unease
with all of the options, in fact.

So what's the conclusion? My conclusion is that
there is need for a non-link layer solution, too.
I feel the pain from PANA searching real world
deployment, but I'm not sure we should set the
PS bar so high that if you do not have commercial
deployment you cannot publish your documents.
We should, however, require that the specifications
pass last call review, and work remains there.
I'm not sure I have easy answers on how to get
there. 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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 26 May 2006 16:54:11 +0300

Hi Lakshminath,

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

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 26 May 2006 16:18:27 -0700

Lakshminath Dondeti wrote:
>> enterprise user gaining access to the enterprise via an IPsec gateway. 
>> a user who is subscribed to a mobile operator's services uses IKEv2 
>> with a VPN-like gateway to access the operator's services. the mode is 
>> shouldn't be confused with PANA. we could discuss this more, but on a 
>> separate thread. Vijay </x-flowed>
> 
> Hi,
> 
> to) use EAP over IKEv2.  

EAP over IKEv2 is used but in the remote gateway mode. exactly
like access to an Enterprise through a VPN gateway. please dont
confuse this with PANA for network access.

Vijay

We can try and debate the details offline, as

---

From: "Junghoon Jee" <[email-masked]>
Date: Mon, 29 May 2006 11:11:59 +0900

Hello Sam,

Please find my inline specific replies.

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

Hmm, not involved in the PANA working group...
At least I am not actively contributing to the PANA group's I-Ds
even if I had several chances to join the working group discussion in
the form of offline or on-line, 
However, I can still say that I am not actively involved in the PANA
WG.
Therefore, I think I can share my view and thought on this thread.
  
> 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.

I also understand the concern about PANA because in these days most
link layers provide their own link specific authentication facilities.
On that situation, the IP connectivity is not allowed before the link
specific authentication procedure is completed. 
So, I suppose that the arguments and criticisms about PANA are coming
from on this point .
However, I'd say that this fact can not throw out the advantage of
PANA which delivers the EAP over UDP, thus link independent
authentication procedure can happen.
Moreover, it can supplement the underlying network which is lack of
the authentication facility.
If one would like to try to stress about the other alternative,
oh,,,please do not go that way. 
PANA WG/IETF already have spent more than one year.
I think it is more productive to enhance our existing efforts rather
than throwing out this and taking the other direction from the bottom
line.
I hope I am misunderstanding the current situation and the implication
from my mind is incorrect.

> My strong hunch is that we've chartered work for some reason, 
> and now that the working group is nearing the end of its 
> charter, we still don't understand why we want this thing 
> we've built and whether it's a good idea.  People aren't 
> screaming not so much because they are happy with results but 
> because no one actually understands PANA.

At least, I am understanding what is PANA and what it aims for and
what it complements.

> 
> I understand that there's a strong presumption that once 
> chartered, work is useful.  I'd like to challenge this 
> presumption enough to get people to actually read the 
> document.  If people not involved in the effort sit down, 
> read the document and understand what it's all about, my 
> concern is satisfied.  But if enough people try to read the 
> certainly cannot have consensus to publish something we've 
> tried and failed to understand.

Same with my previous response.

> It's not just me.  I've been trying to find people outside of 
> PANA who claim to understand the effort and what it's good 
> for and why link-layer solutions are not better.  When the 
> first discussion of PANA hit the IESG, I asked other IESG 
> members why PANA was a good idea and what problem it solved.  
> "Don't go there," was the advice I got from the responsible AD.

How about joining the PANA WG's discussion and having a chance to
share the concern?
Though I am not a freak in the PANA WG, I think there are many folks
who can relieve the concern.

> At that time (a year and a half ago) there was no one on the 
> IESG who claimed to understand PANA or to think it was a good idea.
> 
> I'm fairly sure that with the possible exception of Jari (who 
> is a technical advisor to PANA), that's still true.
> 
> 
> The security community has been trying to understand PANA.  
> I've sent multiple security reviewers at the PANA document.s 
> They always come back fundamentally confused about what PANA 
> is trying to do or about whether it is a good idea.  They end 
> up focusing on some detail or another and asking for some 
> minor part of the system to be fixed.  But I don't get the 
> impression from the reviews they understand the overall 
> picture; explicit discussion of this also indicates that they 
> are not confident in their understanding nor do they know 
> whether it is a good idea.

IMHO, noted technical flaws from framework and protocol are different
with 
some peoples' observation that it is not fully understandable and it
is not a good idea.
It would be great if we can proceed the **technical discussions**
based on the texts
from PANA framework and protocol because it seems that we all have
reviewed those drafts.

Best Regards,
-Junghoon

> We keep running back over the same ground, still confused and 
> still trying to muddle through to no real effect.
> 
> 
> It was very clear to me leaving the original PANA BOF that 
> something was very confused.  Every year or so since I've 
> tried to go back and figure out what I missed.  Eventually 
> though I've started wondering whether the problem wasn't me, 
> but was an actual lack of clarity.

> 
> So, folks can you please help us all out.  Especially if the 
> internet area is not your primary focus, especially if you've 
> never heard of PANA before, take a look at the framework 
> document and all their other documents.  Do you get it?  Is 
> it a good idea?
> 
> Thanks for your time.
> 
> P.S.  Again, this is me speaking as an individual.  At this 
> late stage, it would be entirely inappropriate for me to take 
> actions as an AD claiming that we didn't understand a problem 
> without a strong community consensus.
> 
> 
>