The Emperor Has No Clothes: Is PANA actually useful?

[Sam Hartman]

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
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Pekka Savola]

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 Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Lakshminath Dondeti]

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 Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Narayanan, Vidya]

Disclaimer - I do work in the INT area, but have not been involved in
the PANA WG. 

When this work was chartered, I failed to understand its need and the
deployment use cases. Subsequently, about 3 years ago, I recommended
against the use of PANA for the needs of my ex-employer. More recently,
I have been advocating against the use of PANA in 3gpp2. With that
background, some high level confusions that I have about the use of
PANA: 

1. Reading the framework document, it is simply not clear to me as to
why PANA would be useful for any type of network. Actually, even after
reading some other PANA documents, this is not clear to me. It seems to
have become this complex suite of protocols that aren't specifically
buying anything. Why would I want to go through IP address acquisition,
for one, if I had a link layer that carried EAP, particularly for link
layer security? 

2. Link layer agnostic approach has often been cited as a reason to use
PANA. I must say that I don't understand how it is link layer agnostic,
when it depends on 802.11i 4-way handshake or the like for the secure
association protocol. In fact, I am not sure how this even works with
the currently defined secure association protocols in lower layers. None
of the documents have provided any clarity to me on this. The use of
IPsec/IKE for this is even more confusing to me - in this case, why
would PANA be used instead of EAP-in-IKEv2? 

3. Statements like "...whereas it allows only limited type of traffic
(e.g., PANA, DHCP, router discovery, etc.) for the authorized PaCs" do
not exactly provide a clear picture of port control - yet another reason
IMO to leave the EAP lower layer where it belongs (at the link layer).
There are many other such confusions in my mind arising from the PANA
documents that I won't get into here. 

4. The choices that are left to deployment while using PANA constitute a
long list for one protocol! Security before/after the PANA run, global
vs local PRPA, DHCP vs 3927 vs 2131 for IPv4 PRPA, dual-stack handling
behavior, secure association protocol choice and what it takes to make
it work with PANA, need for POPA and "unconfiguring" PRPA, PAA/EP
location and choice of protocol between those entities, IKEv1 vs IKEv2
etc. - I am sure I've missed more choices here; but, complex enough, to
say the least! 

Given all of this, publishing these documents in the current stage as
proposed standard RFCs concerns me. 

Vidya

> -Original Message-
> From: Sam Hartman [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, May 24, 2006 8:12 AM
> To: ietf@ietf.org
> Cc: [EMAIL PROTECTED]
> Subject: The Emperor Has No Clothes: Is PANA actually useful?
> 
> 
> 
> 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 sec

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

[Lucy E. Lynch]

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.


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


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
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



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

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Josh Howlett]

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


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.


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 PROTECTED] | phone: +44 (0)7867 907076 |  
interal: 7850





___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Vijay Devarapallli]

On 5/24/06, Lakshminath Dondeti <[EMAIL PROTECTED]> 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
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Alper Yegin]

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 PROTECTED]
> Sent: Wednesday, May 24, 2006 8:12 AM
> To: ietf@ietf.org
> Cc: [EMAIL PROTECTED]
> Subject: The Emperor Has No Clothes: Is PANA actually useful?
> 
> 
> 
> 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
> 

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

[Lakshminath Dondeti]

At 05:07 PM 5/24/2006, Vijay Devarapallli wrote:
On 5/24/06, Lakshminath Dondeti <[EMAIL PROTECTED]> 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 


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 



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Bernard Aboba]

I have reviewed the PANA framework document, the PANA protocol spec, and 
the PANA/IPsec document. After reading all these documents, I still do 
not understand why PANA is useful.

The PANA framework document claims that it can be used along with IEEE 
802.11i.  However, IEEE 802.11 reviewed the document, and came to a 
different conclusion:
http://www.drizzle.com/~aboba/IEEE/11-06-0577-01-ietf-liaison-response-IETF-PANA.doc

The other potential scenario outlined by the framework document is use 
along with IPsec.  However, IKEv2 already supports EAP authentication, so 
I don't understand why PANA would be used for that scenario instead of 
IKEv2. 

I do understand the potential need for EAP to be encapsulated over IP.  
However, in practice PANA is more complex than EAP over UDP 
(see draft-thomson-nacp-02.txt), which looks like it is on the road 
to becoming the defacto standard for EAP encapsulation over IP. 

So from what I can tell, in each potential usage scenario PANA is 
either not feasible, is more complex than an established alternative, 
or has been rejected by the SDOs that have examined it.

---
Sam Hartman said:

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
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Alper Yegin]

Hi Bernard,

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 25, 2006 4:46 PM
> To: ietf@ietf.org
> Subject: Re: The Emperor Has No Clothes: Is PANA actually useful?
> 
> I have reviewed the PANA framework document, the PANA protocol spec, and
> the PANA/IPsec document. After reading all these documents, I still do
> not understand why PANA is useful.

Just below you are acknowledging the need for EAP over IP. I don't
understand how you can still claim you don't understand why PANA is
useful... 

> The PANA framework document claims that it can be used along with IEEE
> 802.11i.  However, IEEE 802.11 reviewed the document, and came to a
> different conclusion:
> http://www.drizzle.com/~aboba/IEEE/11-06-0577-01-ietf-liaison-response-
> IETF-PANA.doc

This is an inaccurate reading of the IEEE response (and you are the
liaison). You are aware that "virtual open-access AP" mode is OK. One of the
two alternatives we proposed had an issue, and the other one still holds.


> The other potential scenario outlined by the framework document is use
> along with IPsec.  However, IKEv2 already supports EAP authentication, so
> I don't understand why PANA would be used for that scenario instead of
> IKEv2.

You had commented on that earlier and I had explained it.
http://www1.ietf.org/mail-archive/web/pana/current/msg02234.html. If not
clear, please follow up from there (we don't need to go back to your
original question).

 
> I do understand the potential need for EAP to be encapsulated over IP.

Thank you. 

> However, in practice PANA is more complex than EAP over UDP
> (see draft-thomson-nacp-02.txt), which looks like it is on the road
> to becoming the defacto standard for EAP encapsulation over IP.

De-facto? Could you please elaborate how it is becoming a de-facto standard?


Besides. Of course PANA is more complex than EAPoUDP. The latter (an
individual I-D) has very limited applicability. If it were to handle
mobility and wireless, it'll also grow in complexity. Just to get some sense
of it, compare 802.1X and 802.11r.

> So from what I can tell, in each potential usage scenario PANA is
> either not feasible, is more complex than an established alternative,
> or has been rejected by the SDOs that have examined it.

Which SDOs? Please give us more detail.

Thank you.

Alper




> 
> ---
> Sam Hartman said:
> 
> 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 a

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

[Bernard Aboba]

> Just below you are acknowledging the need for EAP over IP. I don't
> understand how you can still claim you don't understand why PANA is
> useful... 

The framework doesn't seem to talk much about simple EAP over IP 
scenarios, so I have assumed this is not the major focus. 

> You are aware that "virtual open-access AP" mode is OK. One of the
> two alternatives we proposed had an issue, and the other one still holds.

Right.  I was referring only to the WPA/WPA2 scenarios. 

> De-facto? Could you please elaborate how it is becoming a de-facto standard?

EAP over UDP is one of the foundation technologies for Network Endpoint 
Assessment (NEA).  As I understand it, EAPoUDP is being made available on 
most operating systems, and is in the process of being deployed by many 
enterprise customers. 

> Besides. Of course PANA is more complex than EAPoUDP. The latter (an
> individual I-D) has very limited applicability.  

As I understand it, EAP over UDP is mostly being deployed for wired access 
scenarios where IEEE 802.1X might not work well (e.g. multiple hosts 
sharing a port).  

> Which SDOs? Please give us more detail.

As I understand it, 3GPP2 has considered PANA, and IEEE 802.11 has 
evaluated the PANA framework document. 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Alper Yegin]

> 
> > Just below you are acknowledging the need for EAP over IP. I don't
> > understand how you can still claim you don't understand why PANA is
> > useful...
> 
> The framework doesn't seem to talk much about simple EAP over IP
> scenarios, so I have assumed this is not the major focus.

I am sure you read RFC 4058 (like anyone who claims they don't understand
PANA should have done). RFC 4058 said:

   PANA will carry EAP above IP in order to enable any authentication
   method on any link-layer.


> > You are aware that "virtual open-access AP" mode is OK. One of the
> > two alternatives we proposed had an issue, and the other one still
> holds.
> 
> Right.  I was referring only to the WPA/WPA2 scenarios.

Your earlier statement did give another impression, like PANA does not work
with 802.11i at all. Thanks for clarifying it now!


> > De-facto? Could you please elaborate how it is becoming a de-facto
> standard?
> 
> EAP over UDP is one of the foundation technologies for Network Endpoint
> Assessment (NEA).  As I understand it, EAPoUDP is being made available on
> most operating systems, and is in the process of being deployed by many
> enterprise customers.

Yes, that individual I-D is productized as a proprietary protocol by one
company (Cisco). Client-side software may be made available by them for
various platforms (note PANA is already made available as an open source
--both client and software side). If Cisco develops a proprietary protocol
on its own for a subset of our work, should we now stop what we do at IETF?
Is that where this whole fuss is coming from now?

> > Besides. Of course PANA is more complex than EAPoUDP. The latter (an
> > individual I-D) has very limited applicability.
> 
> As I understand it, EAP over UDP is mostly being deployed for wired access
> scenarios where IEEE 802.1X might not work well (e.g. multiple hosts
> sharing a port).
> 
> > Which SDOs? Please give us more detail.
> 
> As I understand it, 3GPP2 has considered PANA, and IEEE 802.11 has
> evaluated the PANA framework document.

How does this explain your "rejected by the SDOs" claim? IEEE 802.11
provided a review feedback and they fixed few important problems and
acknowledged the applicability of our other alternative solutions. How is
that a rejection?!? 

As for 3GPP2, I can get into really gory details of what has been happening
there, but it's not technical at all (if you are familiar with 3GPP2 and the
relevant players in this discussion, you can guess).


Alper





___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Yoshihiro Ohba]

On Thu, May 25, 2006 at 04:45:39PM -0700, Bernard Aboba wrote:
>
> I do understand the potential need for EAP to be encapsulated over IP.  
> However, in practice PANA is more complex than EAP over UDP 
> (see draft-thomson-nacp-02.txt), which looks like it is on the road 
> to becoming the defacto standard for EAP encapsulation over IP. 

I don't think draft-thomson-nacp-02.txt is something to become an IETF
standard EAP over UDP protocol because of its lack of security.  In
fact the draft admits:

"
   If breach of confidentiality and deliberate attacks on the integrity
   of the NACP protocol itself are a significant risk in certain
   deployment environments, NACP should be protected by a protocol that
   offers confidentiality and/or packet authentication, integrity and
   protection against replay e.g.  IPSEC [RFC2401].
"

Why IPsec is needed to carry EAP?  What is authentication protocol for
bootstrapping IPsec to protect NACP, perhaps EAP over IKEv2??

I have other security-related issues on NACP.  My view is that secure
enhancement of NACP will be equivalent to the EAP over UDP protocol
the IETF is standardizing, PANA.

Yoshihiro Ohba


> 
> So from what I can tell, in each potential usage scenario PANA is 
> either not feasible, is more complex than an established alternative, 
> or has been rejected by the SDOs that have examined it.
> 
> ---
> Sam Hartman said:
> 
> 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.
> 
> ___
> I

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

[Bernard Aboba]

> Yes, that individual I-D is productized as a proprietary protocol by one
> company (Cisco). 

As I understand it, EAP over UDP is one of the items proposed for 
standardization in the NEA WG.  That leads me to wonder whether the IETF 
will be chartering multiple WGs to standardize EAP encapsulation over IP. 

Although my understanding of both PANA and NEA is no doubt 
incomplete/wrong/confusled, having multiple EAP encapsulation standards 
seems duplicative to me.

> As for 3GPP2, I can get into really gory details of what has been happening
> there, but it's not technical at all (if you are familiar with 3GPP2 and the
> relevant players in this discussion, you can guess).

The issue is that integration of PANA with link layer technologies 
requires the support of the organizations that own those link layers.  
Without that link layer integration (for whatever reason) the scenarios 
can't be realized, at least in a mainstream way. 

It seems to me that one of the motivations for PANA is to *avoid* link layer 
dependencies in situations where link layer technology is inadequate/can't 
be deployed, and a forklift upgrade isn't in the budget.  In those 
circumstances, integration with link layers or IPsec VPN technology is 
not under consideration -- because that would require a forklift upgrade.

For example, the wireless hotspot case where something more sophisticated 
than a Web portal is needed, but a forklift upgrade to WPA2 or a VPN 
deployment isn't a realistic alternative.  Or the shared wired media case 
where "network port authentication" doesn't really work, and wholesale 
switch port replacements aren't affordable.  In both of those cases, EAP 
over IP might provide a light weight, easily deployed solution.

Yet, rather than focusing on the specific scenarios in which PANA might 
be compelling, the PANA framework document tries to cover a wide 
range of potential uses, trying to position PANA for use in scenarios 
where the case is less obvious. 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Bernard Aboba]

> I have other security-related issues on NACP.  My view is that secure
> enhancement of NACP will be equivalent to the EAP over UDP protocol
> the IETF is standardizing, PANA.

Can you describe why the security of PANA is better than EAP over UDP 
(NACP)?  I had thought that they were more or less equivalent, since 
neither approach mandates protection. 

But maybe I am missing something? 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Yoshihiro Ohba]

On Thu, May 25, 2006 at 09:24:03PM -0700, Bernard Aboba wrote:
> > I have other security-related issues on NACP.  My view is that secure
> > enhancement of NACP will be equivalent to the EAP over UDP protocol
> > the IETF is standardizing, PANA.
> 
> Can you describe why the security of PANA is better than EAP over UDP 
> (NACP)?  I had thought that they were more or less equivalent, since 
> neither approach mandates protection. 

NACP does not have its own integrity protection mechanism while PANA
has.  It is true that PANA AUTH AVP is optional, but the use of
protection is mandatory when an EAP method that is capable of deriving
keys is used.  This is described in the PANA specification draft.

We can discuss security aspects more, but what I would really like to
say in this thread is that discussing usefulness of PANA or any other
EAP transport without deep security analysis does not appear to be the
right thing.

Yoshihiro Ohba


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Alper Yegin]

> > Yes, that individual I-D is productized as a proprietary protocol by one
> > company (Cisco).
> 
> As I understand it, EAP over UDP is one of the items proposed for
> standardization in the NEA WG.  

You misunderstood it, despite the clear text in their charter:

...

  Requirements need to
  be defined for an EAP over L3 transport for L3 access scenarios.

...

  * Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG)
and work with ADs to identify the WG responsible for accommodating
protocol requirements that are not currently being met.


> That leads me to wonder whether the IETF
> will be chartering multiple WGs to standardize EAP encapsulation over IP.
> 
> Although my understanding of both PANA and NEA is no doubt
> incomplete/wrong/confusled, having multiple EAP encapsulation standards
> seems duplicative to me.

It is not suggested anyways.

> > As for 3GPP2, I can get into really gory details of what has been
> happening
> > there, but it's not technical at all (if you are familiar with 3GPP2 and
> the
> > relevant players in this discussion, you can guess).
> 
> The issue is that integration of PANA with link layer technologies
> requires the support of the organizations that own those link layers.

Not necessarily. Why do you think so? 802.11 is a counter example. DSL is a
counter example. 

> Without that link layer integration (for whatever reason) the scenarios
> can't be realized, at least in a mainstream way.
> 
> It seems to me that one of the motivations for PANA is to *avoid* link
> layer
> dependencies in situations where link layer technology is inadequate/can't
> be deployed, and a forklift upgrade isn't in the budget.  In those
> circumstances, integration with link layers or IPsec VPN technology is
> not under consideration -- because that would require a forklift upgrade.
>
> For example, the wireless hotspot case where something more sophisticated
> than a Web portal is needed, but a forklift upgrade to WPA2 or a VPN
> deployment isn't a realistic alternative.  Or the shared wired media case
> where "network port authentication" doesn't really work, and wholesale
> switch port replacements aren't affordable.  In both of those cases, EAP
> over IP might provide a light weight, easily deployed solution.

Are you referring to NACP as "EAP over IP"? You acknowledged it is designed
for wired networks. It is not even useful for wireless. Won't work.

> Yet, rather than focusing on the specific scenarios in which PANA might
> be compelling, the PANA framework document tries to cover a wide
> range of potential uses, trying to position PANA for use in scenarios
> where the case is less obvious.

I think that would have been unnecessarily limiting, given that we designed
a protocol that can naturally work in variety of scenarios.

Alper








___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Avi Lior]

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 PROTECTED] 
> Sent: Wednesday, May 24, 2006 3:44 PM
> To: Pekka Savola; Sam Hartman
> Cc: ietf@ietf.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 
&

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

[Antonio F. Gómez Skarmeta]

Well, certainly other EU project are interested as I am involve in some 
of them like Daidalos http://www.ist-daidalos.org and previously also 
SEINIT http://www.seinit.org/


 But also I will like to mention and Josh is aware (DAME project) that 
some work is being considered in the european academic networks 
regarding to the interaction between  authentication and authorization 
that comes from a design that was based on the use of PANA in the 
network access :-)


Antonio



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

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.
   



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: josh.howlett at bristol.ac.uk | phone: +44 (0)7867 907076 | 
interal: 7850

----------------

Asunto:
The Emperor Has No Clothes: Is PANA actually useful?
De:
"Sam Hartman" <[EMAIL PROTECTED]>
Fecha:
Wed, 24 May 2006 08:12:04 -0700
Para:


Para:

CC:
<[EMAIL PROTECTED]>


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 a

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

[Jari Arkko]

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


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Ralph Droms]

What is the current state of the nea WG?  I don't see it listed at
http://ietf.org/html.charters/wg-dir.html

- Ralph


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Joel M. Halpern]

In reading the PANA Framework document,  what I read seemed to me to 
be more of a "system" or "solution" document than a clean IETF 
protocol framework.


I saw efforts to address three different problems:
1) Securing an otherwise unsecured link, when the access node is not 
known to the client in advance.

2) Selecting an authorization (charging, possibly packet handling) service
3) Authenticating the user

EAP over IP (or UDP, or link) is about authenticating the user.  If a 
media independent technique better than just using a browser is 
needed, then solve that problem.  Personally, I would find the work 
far more persuasive if it did not also try to solve the problem of 
creating an IPSec association to the access device, nor of the 
authorization selection problem.


And spell out in clear English what use case needs that problem 
solved.  I can read between the lines and start to guess.  But the 
document is quite unclear.  The appendix about DSL is not helpful in 
that regard.


Yours,
Joel M. Halpern


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Jari Arkko]

Hi Lakshminath,

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

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


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Jari Arkko]

Ralph Droms wrote:

>What is the current state of the nea WG?  I don't see it listed at
>http://ietf.org/html.charters/wg-dir.html
>  
>
NEA held a BOF in Dallas, and I believe they are planning
to hold a 2nd BOF in Montreal.

--Jari


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Sam Hartman]

> "Alper" == Alper Yegin <[EMAIL PROTECTED]> writes:

>> > Yes, that individual I-D is productized as a proprietary
>> protocol by one > company (Cisco).
>> 
>> As I understand it, EAP over UDP is one of the items proposed
>> for standardization in the NEA WG.

Alper> You misunderstood it, despite the clear text in their
Alper> charter:

Alper> ...

Alper>   Requirements need to be defined for an EAP over L3
Alper> transport for L3 access scenarios.

I don't think he misunderstood.  IT may not be in their charter, but
they definitely did want to standardize EAP over UDP in at least some
versions of NEA.

My question is more why do they need EAP in situations where they are
not running at the link layer than why do they want or not want PANA.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Sam Hartman]

> "Ralph" == Ralph Droms <[EMAIL PROTECTED]> writes:

Ralph> What is the current state of the nea WG?  I don't see it
Ralph> listed at http://ietf.org/html.charters/wg-dir.html

It had a BOF at the last IETF.

It seems highly likely it will either have a proposed WG or BOF again.
(Russ and I have received both a charter and a BOF proposal)

Russ is shepherding the effort.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Ralph Droms]

Sam - I see where the nea BOF was more-or-less associated with the Internet
Area at IETF 65.  Do you expect that nea would (if eventually chartered)
land in Internet or Security?

- Ralph


On 5/26/06 10:58 AM, "Sam Hartman" <[EMAIL PROTECTED]> wrote:

>> "Ralph" == Ralph Droms <[EMAIL PROTECTED]> writes:
> 
> Ralph> What is the current state of the nea WG?  I don't see it
> Ralph> listed at http://ietf.org/html.charters/wg-dir.html
> 
> It had a BOF at the last IETF.
> 
> It seems highly likely it will either have a proposed WG or BOF again.
> (Russ and I have received both a charter and a BOF proposal)
> 
> Russ is shepherding the effort.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Dave Crocker]

Joel M. Halpern wrote:
EAP over IP (or UDP, or link) is about authenticating the user.  If a 
media independent technique better than just using a browser is needed, 
then solve that problem.  Personally, I would find the work far more 
persuasive if it did not also try to solve the problem of creating an 
IPSec association to the access device, nor of the authorization 
selection problem.


And spell out in clear English what use case needs that problem solved.  
I can read between the lines and start to guess.  But the document is 
quite unclear.  The appendix about DSL is not helpful in that regard.



Although not a guaranteed way to distinguish among criticisms, it can be helpful 
to categorize them as either "It will not work" versus "I don't like it". The 
former indicates a basic technical flaw, and the latter a matter of preference.


If it is common for readers of a specification to fail to understand what it is 
for then it has, perhaps, the most basic kind of technical flaw.  How can a 
specification succeed if there is confusion about its implementation or use?


By contrast observations such as "there are better solutions" moves into the 
fuzzier and more subjective realm of trying to predict market preferences. The 
IETF is not very good at making these predictions.  Absent any indication of 
actual harm that would ensue from publishing a specification, fear that no one 
will adopt it or that there will be multiple solutions seems an inappropriate 
basis for denying publication.  (On the other hand, strong indication of 
community interest in deplying a specification is supposed to be a factor in 
deciding whether to charter the work in the first place; however as Sam noted, 
we are rather late in the process.)


In any event, I would claim that concerns over who will use PANA fall into the 
"I don't like it" category, since it basically seeks to make statements about 
market preferences, which is a small step from personal preferences.


Having looked over this thread and the -framework document a bit, I find myself 
unclear which of the two lines of concern is being pursued, although I impressed 
by the degree of confusion about PANA after what appears to be considerable 
effort to understand it.  This does not bode well for community understanding, 
and that of course does not bode well for adoption and use.


I would find it particularly helpful to have a concise statement from someone 
who says that PANA will not work.  Cannot be implemented (properly) by virtue of 
technical errors or documentation too confusing to understand.  Or cannot be 
deployed and used, by virtue of administrative complexity or, again, 
documentation too confusing to understand.


Absent this, I will ask why it is productive to note that the emperor is 
pursuing an idiosynchratic sartorial style?


d/

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Ralph Droms]

Dave - one quick follow on to your observation about "will not work" that
falls somewhere between "will not work" and "don't like it".  There is
another possibility: "works, but there's a much simpler way to meet the same
requirements"...

- Ralph


On 5/26/06 11:34 AM, "Dave Crocker" <[EMAIL PROTECTED]> wrote:

> 
> 
> Joel M. Halpern wrote:
>> EAP over IP (or UDP, or link) is about authenticating the user.  If a
>> media independent technique better than just using a browser is needed,
>> then solve that problem.  Personally, I would find the work far more
>> persuasive if it did not also try to solve the problem of creating an
>> IPSec association to the access device, nor of the authorization
>> selection problem.
>> 
>> And spell out in clear English what use case needs that problem solved.
>> I can read between the lines and start to guess.  But the document is
>> quite unclear.  The appendix about DSL is not helpful in that regard.
> 
> 
> Although not a guaranteed way to distinguish among criticisms, it can be
> helpful 
> to categorize them as either "It will not work" versus "I don't like it". The
> former indicates a basic technical flaw, and the latter a matter of
> preference.
> 
> If it is common for readers of a specification to fail to understand what it
> is 
> for then it has, perhaps, the most basic kind of technical flaw.  How can a
> specification succeed if there is confusion about its implementation or use?
> 
> By contrast observations such as "there are better solutions" moves into the
> fuzzier and more subjective realm of trying to predict market preferences. The
> IETF is not very good at making these predictions.  Absent any indication of
> actual harm that would ensue from publishing a specification, fear that no one
> will adopt it or that there will be multiple solutions seems an inappropriate
> basis for denying publication.  (On the other hand, strong indication of
> community interest in deplying a specification is supposed to be a factor in
> deciding whether to charter the work in the first place; however as Sam noted,
> we are rather late in the process.)
> 
> In any event, I would claim that concerns over who will use PANA fall into the
> "I don't like it" category, since it basically seeks to make statements about
> market preferences, which is a small step from personal preferences.
> 
> Having looked over this thread and the -framework document a bit, I find
> myself 
> unclear which of the two lines of concern is being pursued, although I
> impressed 
> by the degree of confusion about PANA after what appears to be considerable
> effort to understand it.  This does not bode well for community understanding,
> and that of course does not bode well for adoption and use.
> 
> I would find it particularly helpful to have a concise statement from someone
> who says that PANA will not work.  Cannot be implemented (properly) by virtue
> of 
> technical errors or documentation too confusing to understand.  Or cannot be
> deployed and used, by virtue of administrative complexity or, again,
> documentation too confusing to understand.
> 
> Absent this, I will ask why it is productive to note that the emperor is
> pursuing an idiosynchratic sartorial style?
> 
> d/
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Joel M. Halpern]

I have to disagree.
Firstly, if many of us reading the document can not figure out what 
problem it is solving, then the framework is not doing its job.
Secondly, if there are existing, viable, deployed solutions to the 
problem that the WG is attempting to solve then the WG needs to 
explain somewhere (the framework document would seem the obvious 
place) why there is a need for a new solution.


I am not claiming that the PANA protocol can't work.  As was said 
many years ago "with sufficient thrust, pigs will fly."  But that 
does not make flying pigs a good thing.


Yours,
Joel M. Halpern

At 11:34 AM 5/26/2006, Dave Crocker wrote:



Joel M. Halpern wrote:
EAP over IP (or UDP, or link) is about authenticating the user.  If 
a media independent technique better than just using a browser is 
needed, then solve that problem.  Personally, I would find the work 
far more persuasive if it did not also try to solve the problem of 
creating an IPSec association to the access device, nor of the 
authorization selection problem.

And spell out in clear English what use case needs that problem solved.
I can read between the lines and start to guess.  But the document 
is quite unclear.  The appendix about DSL is not helpful in that regard.



Although not a guaranteed way to distinguish among criticisms, it 
can be helpful to categorize them as either "It will not work" 
versus "I don't like it". The former indicates a basic technical 
flaw, and the latter a matter of preference.


If it is common for readers of a specification to fail to understand 
what it is for then it has, perhaps, the most basic kind of 
technical flaw.  How can a specification succeed if there is 
confusion about its implementation or use?


By contrast observations such as "there are better solutions" moves 
into the fuzzier and more subjective realm of trying to predict 
market preferences. The IETF is not very good at making these 
predictions.  Absent any indication of actual harm that would ensue 
from publishing a specification, fear that no one will adopt it or 
that there will be multiple solutions seems an inappropriate basis 
for denying publication.  (On the other hand, strong indication of 
community interest in deplying a specification is supposed to be a 
factor in deciding whether to charter the work in the first place; 
however as Sam noted, we are rather late in the process.)


In any event, I would claim that concerns over who will use PANA 
fall into the "I don't like it" category, since it basically seeks 
to make statements about market preferences, which is a small step 
from personal preferences.


Having looked over this thread and the -framework document a bit, I 
find myself unclear which of the two lines of concern is being 
pursued, although I impressed by the degree of confusion about PANA 
after what appears to be considerable effort to understand it.  This 
does not bode well for community understanding, and that of course 
does not bode well for adoption and use.


I would find it particularly helpful to have a concise statement 
from someone who says that PANA will not work.  Cannot be 
implemented (properly) by virtue of technical errors or 
documentation too confusing to understand.  Or cannot be deployed 
and used, by virtue of administrative complexity or, again, 
documentation too confusing to understand.


Absent this, I will ask why it is productive to note that the 
emperor is pursuing an idiosynchratic sartorial style?


d/

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Antonio F. Gómez Skarmeta]

Dave Crocker escribió:




Joel M. Halpern wrote:

EAP over IP (or UDP, or link) is about authenticating the user.  If a 
media independent technique better than just using a browser is 
needed, then solve that problem.  Personally, I would find the work 
far more persuasive if it did not also try to solve the problem of 
creating an IPSec association to the access device, nor of the 
authorization selection problem.


And spell out in clear English what use case needs that problem 
solved.  I can read between the lines and start to guess.  But the 
document is quite unclear.  The appendix about DSL is not helpful in 
that regard.




Although not a guaranteed way to distinguish among criticisms, it can 
be helpful to categorize them as either "It will not work" versus "I 
don't like it". The former indicates a basic technical flaw, and the 
latter a matter of preference.




 I totally agree with your statement, I was just thinking about sending 
a message in this line.


 I am (at least I thought I am) a scientific and as such I prefer to 
work with statement and lemas that allow me to reason with them. 
Although in some of the messages I have read there are more perceptions 
or opinions but too little technical criticism.


 In that sense I will like to see clear indication of what is not 
adequate and wrong in a more technical fashion, hence it will allow 
people to debate on it an a least explain the reason in objectives and 
not subjective ways


My 2 cents on this

If it is common for readers of a specification to fail to understand 
what it is for then it has, perhaps, the most basic kind of technical 
flaw.  How can a specification succeed if there is confusion about its 
implementation or use?


By contrast observations such as "there are better solutions" moves 
into the fuzzier and more subjective realm of trying to predict market 
preferences. The IETF is not very good at making these predictions.  
Absent any indication of actual harm that would ensue from publishing 
a specification, fear that no one will adopt it or that there will be 
multiple solutions seems an inappropriate basis for denying 
publication.  (On the other hand, strong indication of community 
interest in deplying a specification is supposed to be a factor in 
deciding whether to charter the work in the first place; however as 
Sam noted, we are rather late in the process.)


In any event, I would claim that concerns over who will use PANA fall 
into the "I don't like it" category, since it basically seeks to make 
statements about market preferences, which is a small step from 
personal preferences.


Having looked over this thread and the -framework document a bit, I 
find myself unclear which of the two lines of concern is being 
pursued, although I impressed by the degree of confusion about PANA 
after what appears to be considerable effort to understand it.  This 
does not bode well for community understanding, and that of course 
does not bode well for adoption and use.


I would find it particularly helpful to have a concise statement from 
someone who says that PANA will not work.  Cannot be implemented 
(properly) by virtue of technical errors or documentation too 
confusing to understand.  Or cannot be deployed and used, by virtue of 
administrative complexity or, again, documentation too confusing to 
understand.


Absent this, I will ask why it is productive to note that the emperor 
is pursuing an idiosynchratic sartorial style?


d/

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf




--

Antonio F. Gómez Skarmeta
Dept. Ingeniería de la Información y las Comunicaciones
Facultad de Informática
Universidad de Murcia
Apartado 4021
30001 Murcia
Telf: +34-968-364607
fax: +34-968-364151


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Antonio F. Gómez Skarmeta]

Ralph Droms escribió:


Dave - one quick follow on to your observation about "will not work" that
falls somewhere between "will not work" and "don't like it".  There is
another possibility: "works, but there's a much simpler way to meet the same
requirements"...

 



 Which one? and why it is better?

Antonio


- Ralph


On 5/26/06 11:34 AM, "Dave Crocker" <[EMAIL PROTECTED]> wrote:

 


Joel M. Halpern wrote:
   


EAP over IP (or UDP, or link) is about authenticating the user.  If a
media independent technique better than just using a browser is needed,
then solve that problem.  Personally, I would find the work far more
persuasive if it did not also try to solve the problem of creating an
IPSec association to the access device, nor of the authorization
selection problem.

And spell out in clear English what use case needs that problem solved.
I can read between the lines and start to guess.  But the document is
quite unclear.  The appendix about DSL is not helpful in that regard.
 


Although not a guaranteed way to distinguish among criticisms, it can be
helpful 
to categorize them as either "It will not work" versus "I don't like it". The

former indicates a basic technical flaw, and the latter a matter of
preference.

If it is common for readers of a specification to fail to understand what it
is 
for then it has, perhaps, the most basic kind of technical flaw.  How can a

specification succeed if there is confusion about its implementation or use?

By contrast observations such as "there are better solutions" moves into the
fuzzier and more subjective realm of trying to predict market preferences. The
IETF is not very good at making these predictions.  Absent any indication of
actual harm that would ensue from publishing a specification, fear that no one
will adopt it or that there will be multiple solutions seems an inappropriate
basis for denying publication.  (On the other hand, strong indication of
community interest in deplying a specification is supposed to be a factor in
deciding whether to charter the work in the first place; however as Sam noted,
we are rather late in the process.)

In any event, I would claim that concerns over who will use PANA fall into the
"I don't like it" category, since it basically seeks to make statements about
market preferences, which is a small step from personal preferences.

Having looked over this thread and the -framework document a bit, I find
myself 
unclear which of the two lines of concern is being pursued, although I
impressed 
by the degree of confusion about PANA after what appears to be considerable

effort to understand it.  This does not bode well for community understanding,
and that of course does not bode well for adoption and use.

I would find it particularly helpful to have a concise statement from someone
who says that PANA will not work.  Cannot be implemented (properly) by virtue
of 
technical errors or documentation too confusing to understand.  Or cannot be

deployed and used, by virtue of administrative complexity or, again,
documentation too confusing to understand.

Absent this, I will ask why it is productive to note that the emperor is
pursuing an idiosynchratic sartorial style?

d/

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

 




--

Antonio F. Gómez Skarmeta
Dept. Ingeniería de la Información y las Comunicaciones
Facultad de Informática
Universidad de Murcia
Apartado 4021
30001 Murcia
Telf: +34-968-364607
fax: +34-968-364151


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Paul Hoffman]

At 5:21 PM +0300 5/26/06, Jari Arkko wrote:

Ralph Droms wrote:


What is the current state of the nea WG?  I don't see it listed at
http://ietf.org/html.charters/wg-dir.html



NEA held a BOF in Dallas, and I believe they are planning
to hold a 2nd BOF in Montreal.


Mailing list info: . The 
post-Dallas discussions have been quite fruitful, and the discussion 
this week particularly so.


--Paul Hoffman, Director
--VPN Consortium

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Bernard Aboba]

> My question is more why do they need EAP in situations where they are
> not running at the link layer than why do they want or not want PANA.

The simple answer is that there are situations which IEEE 802.1X cannot 
handle on wired networks.  As specified, IEEE 802.1X is "network port 
control", which means that authorization is controllable only at the port 
level.  If there is more than one host connected to a switch port, then 
that model no longer applies. 

For example, consider a user with two machines attached to a hub on a 
single port - a laptop and a desktop machine.  The desktop authenticates 
via machine credentials, and for some reason the certificate has expired 
without being renewed.  The laptop has up to date credentials.  However, 
because they are both connected to the same port, they will each attempt 
to authenticate; since the desktop machine no longer has up to date 
credentials, its authentication will fail, causing port access to be 
denied, throwing the laptop off the network.  The two machines will 
continue to cycle through authentication attempts, causing the port to 
alternatively be open and closed.

Some of the solutions that have been discussed include:

a. For the switch to keep MAC state on each port, which requires a 
additional CAM, and therefore a forklift upgrade, OR

b. For the switch to support protected Ethernet (802.1ae) and associated 
key management (802.1af) so that traffic from each host can be 
cryptographically separated, also requiring an (even more expensive) 
forklift upgrade; OR

c. For the host and routers to support EAP over UDP.  Typically this works 
by having the router recognize a new host (e.g. new entry in the ARP 
table), then challenging it via EAP over UDP.  If the host successfully 
authenticates, packets from that IP address are allowed to pass through 
the router filter; otherwise not. 

Of these approaches, b) is the most secure since it enables cryptographic 
separation between traffic from different MAC addresses, preventing
MAC address piggyback attacks as well as enabling reliable "shared media" 
operation. However, it is also the most expensive approach, since each 
port now needs to support encryption; at lines rates of 1+ Gbps this can 
be pricey. 

Approach a) is less expensive (and less ecure) than b), but also requires 
a forklift upgrade. 

Approach c) is probably the least secure, but it is also the 
least expensive approach, since no switch ports need to be upgraded. 

One might argue that approach c) is likely to represent a short-term fix 
until switches supporting a) or b) are commonly available, and therefore 
that EAP over UDP has no long-term future.  I would tend to agree with 
this, but would also observe that switches tend to have long replacement 
cycles. For example, it is common to see customers with Cat 5K switches 
that have been in place for a nearly decade with no immediate prospects 
for replacement. Those kind of customers are likely to find EAP over UDP 
appealing. 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Ralph Droms]

Antonio - I'm not well-informed enough about the specifics of the PANA
problem space and framework to make definitive recommendations.  I was
mostly making an observation, based on my experience, of another reaction
someone might have to a particular technology/design/protocol.

- Ralph


On 5/26/06 11:50 AM, "Antonio F. Gómez Skarmeta" <[EMAIL PROTECTED]> wrote:

> Ralph Droms escribió:
> 
>> Dave - one quick follow on to your observation about "will not work" that
>> falls somewhere between "will not work" and "don't like it".  There is
>> another possibility: "works, but there's a much simpler way to meet the same
>> requirements"...
>> 
>>  
>> 
> 
>   Which one? and why it is better?
> 
>  Antonio
> 
>> - Ralph
>> 
>> 
>> On 5/26/06 11:34 AM, "Dave Crocker" <[EMAIL PROTECTED]> wrote:
>> 
>>  
>> 
>>> Joel M. Halpern wrote:
>>>
>>> 
 EAP over IP (or UDP, or link) is about authenticating the user.  If a
 media independent technique better than just using a browser is needed,
 then solve that problem.  Personally, I would find the work far more
 persuasive if it did not also try to solve the problem of creating an
 IPSec association to the access device, nor of the authorization
 selection problem.
 
 And spell out in clear English what use case needs that problem solved.
 I can read between the lines and start to guess.  But the document is
 quite unclear.  The appendix about DSL is not helpful in that regard.
  
 
>>> Although not a guaranteed way to distinguish among criticisms, it can be
>>> helpful 
>>> to categorize them as either "It will not work" versus "I don't like it".
>>> The
>>> former indicates a basic technical flaw, and the latter a matter of
>>> preference.
>>> 
>>> If it is common for readers of a specification to fail to understand what it
>>> is 
>>> for then it has, perhaps, the most basic kind of technical flaw.  How can a
>>> specification succeed if there is confusion about its implementation or use?
>>> 
>>> By contrast observations such as "there are better solutions" moves into the
>>> fuzzier and more subjective realm of trying to predict market preferences.
>>> The
>>> IETF is not very good at making these predictions.  Absent any indication of
>>> actual harm that would ensue from publishing a specification, fear that no
>>> one
>>> will adopt it or that there will be multiple solutions seems an
>>> inappropriate
>>> basis for denying publication.  (On the other hand, strong indication of
>>> community interest in deplying a specification is supposed to be a factor in
>>> deciding whether to charter the work in the first place; however as Sam
>>> noted,
>>> we are rather late in the process.)
>>> 
>>> In any event, I would claim that concerns over who will use PANA fall into
>>> the
>>> "I don't like it" category, since it basically seeks to make statements
>>> about
>>> market preferences, which is a small step from personal preferences.
>>> 
>>> Having looked over this thread and the -framework document a bit, I find
>>> myself 
>>> unclear which of the two lines of concern is being pursued, although I
>>> impressed 
>>> by the degree of confusion about PANA after what appears to be considerable
>>> effort to understand it.  This does not bode well for community
>>> understanding,
>>> and that of course does not bode well for adoption and use.
>>> 
>>> I would find it particularly helpful to have a concise statement from
>>> someone
>>> who says that PANA will not work.  Cannot be implemented (properly) by
>>> virtue
>>> of 
>>> technical errors or documentation too confusing to understand.  Or cannot be
>>> deployed and used, by virtue of administrative complexity or, again,
>>> documentation too confusing to understand.
>>> 
>>> Absent this, I will ask why it is productive to note that the emperor is
>>> pursuing an idiosynchratic sartorial style?
>>> 
>>> d/
>>> 
>>> ___
>>> Ietf mailing list
>>> Ietf@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ietf
>>>
>>> 
>> 
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf
>> 
>>  
>> 
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Sam Hartman]

> "Bernard" == Bernard Aboba <[EMAIL PROTECTED]> writes:

>> My question is more why do they need EAP in situations where
>> they are not running at the link layer than why do they want or
>> not want PANA.

Bernard> The simple answer is that there are situations which IEEE
Bernard> 802.1X cannot handle on wired networks.  As specified,
Bernard> IEEE 802.1X is "network port control", which means that
Bernard> authorization is controllable only at the port level.  If
Bernard> there is more than one host connected to a switch port,
Bernard> then that model no longer applies.

Yeah.  I guess I wonder whether you are actually getting network
access authenticatino at that point or whether you are getting a
service that allows you to check posture.  It seems that a service
that simply allows you to check posture should be not EAP.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Dave Crocker]

Ralph Droms wrote:

Dave - one quick follow on to your observation about "will not work" that
falls somewhere between "will not work" and "don't like it".  There is
another possibility: "works, but there's a much simpler way to meet the same
requirements"...



ahh, good.  this nicely permits making the underlying distinction a bit more 
strongly:


"There is a much simpler way to meet the requirements" states an engineering 
preference.  Further, it often involves comparing a concrete specification 
against an unspecified idea.  The issue therefore is not whether the criticism 
is valid -- it often is -- but that it falls primarily into the "I don't like 
it" category.


If there is a better way to solve a problem, those supporting the alternative 
ought to go and specify it and gain community adoption.  Otherwise, we suffer 
the danger of preventing deployment of *any* capability, since we will always be 
waiting for work to get done on that simpler way of meeting the same requirements.


The folks who actually did the work ought get to test that work in the market 
place... unless there is a clear basis for claiming that it won't work and 
reasonable consensus that the basis is valid.


d/

ps.  The process model that informs this line of thinking says that we should be 
strict in demanding strong indication of community support, when an effort 
starts -- and I will claim while the working group proceeds -- but that it 
should not factor that into the final standardization decision.  In this latter 
stage, this concern looks too much like sour grapes.  (Not that it necessarily 
is, but that it simply is not fair to use it as a basis for rejection at that 
stage.)


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Peter Dambier]

Joel M. Halpern wrote:

I have to disagree.
Firstly, if many of us reading the document can not figure out what 
problem it is solving, then the framework is not doing its job.
Secondly, if there are existing, viable, deployed solutions to the 
problem that the WG is attempting to solve then the WG needs to explain 
somewhere (the framework document would seem the obvious place) why 
there is a need for a new solution.


I am not claiming that the PANA protocol can't work.  As was said many 
years ago "with sufficient thrust, pigs will fly."  But that does not 
make flying pigs a good thing.




Flying pigs would add RFC 2549 a totally new meaning, incrementing
put through dramatically :)


Joel M. Halpern wrote:

EAP over IP (or UDP, or link) is about authenticating the user.  If a 
media independent technique better than just using a browser is 
needed, then solve that problem.  Personally, I would find the work 
far more persuasive if it did not also try to solve the problem of 
creating an IPSec association to the access device, nor of the 
authorization selection problem.

And spell out in clear English what use case needs that problem solved.
I can read between the lines and start to guess.  But the document is 
quite unclear.  The appendix about DSL is not helpful in that regard.




Here in germany DTAG.de, the infrastructure supplier for most aDSL providers
does use PPPoE exclusively, authorization by PAP. It would be nice to
connect an aDSL modem directly to a WLAN and let everybody use his own
personal account via the AP. Alas - eavesdropping ...

If PANA could come in here?

I dont know PANA at all right now. That is why I dont know what harm it does.
Can anybody tell me what to look for?


> At 11:34 AM 5/26/2006, Dave Crocker wrote:


Although not a guaranteed way to distinguish among criticisms, it can 
be helpful to categorize them as either "It will not work" versus "I 
don't like it". The former indicates a basic technical flaw, and the 
latter a matter of preference.


If it is common for readers of a specification to fail to understand 
what it is for then it has, perhaps, the most basic kind of technical 
flaw.  How can a specification succeed if there is confusion about its 
implementation or use?


By contrast observations such as "there are better solutions" moves 
into the fuzzier and more subjective realm of trying to predict market 
preferences. The IETF is not very good at making these predictions.  
Absent any indication of actual harm that would ensue


from publishing a specification, fear that no one will adopt it or 


that there will be multiple solutions seems an inappropriate basis for 
denying publication.  (On the other hand, strong indication of 
community interest in deplying a specification is supposed to be a 
factor in deciding whether to charter the work in the first place; 
however as Sam noted, we are rather late in the process.)


In any event, I would claim that concerns over who will use PANA fall 
into the "I don't like it" category, since it basically seeks to make 
statements about market preferences, which is a small step



from personal preferences.



Having looked over this thread and the -framework document a bit, I 
find myself unclear which of the two lines of concern is being 
pursued, although I impressed by the degree of confusion about PANA 
after what appears to be considerable effort to understand it.  This 
does not bode well for community understanding, and that of course 
does not bode well for adoption and use.




There are more complicated protocols that have been implemented, like
netbios over tcp, without thought of their impact on security.

I have burnt my fingers running netbios (samba) on a system (linux) I
deemed imune against hackers. I dont want to run that risk again.

I dont see the pit I might fall in - but I cannot see very far right
now, because of thouse high walls around me :)

Still that is not a reason against documenting it. Just giving more
insight would be welcome.


I would find it particularly helpful to have a concise statement

from someone who says that PANA will not work.  Cannot be 


implemented (properly) by virtue of technical errors or documentation 
too confusing to understand.  Or cannot be deployed and used, by 
virtue of administrative complexity or, again, documentation too 
confusing to understand.


Absent this, I will ask why it is productive to note that the emperor 
is pursuing an idiosynchratic sartorial style?





Kind regards
Peter and Karin

--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Dave Crocker]

Joel M. Halpern wrote:

I have to disagree.
Firstly, if many of us reading the document can not figure out what 
problem it is solving, then the framework is not doing its job.


As I tried to indicate, any sort of broad-based confusion about the purpose or 
use of a spec is a very basic indication that the spec cannot work.  How can it 
work if the potential adopter community does not know what it is for or how to 
use it?


So I suspect we do NOT disagree on this point.


Secondly, if there are existing, viable, deployed solutions to the 
problem that the WG is attempting to solve then the WG needs to explain 
somewhere (the framework document would seem the obvious place) why 
there is a need for a new solution.


I enjoy debating preferences and superiority as much as the next IETF attendee, 
but it is not a good basis for rejecting the diligent effort by a chartered 
working group.






Basavaraj Patil wrote:
> The fact that the IETF is supposed to be based on "Rough consensus and
> running code" is completely being missed here.

That is clearly not correct.  The nature of Sam's public query is specifically 
(and explicitly) looking for certain kinds of rough consensus.



Currently there are
> multiple interoperable implementation of the protocol in addition to
> there existing an open-source implementation as well.
> The fact that several years of peoples work and effort has gone into
> this is being ignored by claims that I find quite have a vested
> interest.

That some people have a common view of the work and that they have used that 
common view to produce interoperable implementations is extremely important. 
However the difference between "a few folks can make this work" and "the 
broad-based Internet technical community can make this work" entails a 
non-trivial aspect of protocol scaling.  Scaling in development and adoption is 
just as important as scaling in use.


d/



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Narayanan, Vidya]

> 
> > "Bernard" == Bernard Aboba <[EMAIL PROTECTED]> writes:
> 
> >> My question is more why do they need EAP in situations where
> >> they are not running at the link layer than why do they want or
> >> not want PANA.
> 
> Bernard> The simple answer is that there are situations which IEEE
> Bernard> 802.1X cannot handle on wired networks.  As specified,
> Bernard> IEEE 802.1X is "network port control", which means that
> Bernard> authorization is controllable only at the port level.  If
> Bernard> there is more than one host connected to a switch port,
> Bernard> then that model no longer applies.
> 
> Yeah.  I guess I wonder whether you are actually getting 
> network access authenticatino at that point or whether you 
> are getting a service that allows you to check posture.  It 
> seems that a service that simply allows you to check posture 
> should be not EAP.
> 


I fully agree. As far as I can tell, using EAP in this manner merely
reduces it to a posture transport protocol. The level of security
provided by EAPoUDP does not seem to be any greater than a
kerberos-based authentication done today in most enterprise networks,
considering the presence of switched ethernet. Hence, the only reason to
move to EAPoUDP would be to check posture and I agree with Sam that
making EAP the posture transport protocol is a bad idea. 

Vidya


> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Gray, Eric]

For those of us that are just trying to follow this discussion,
what does the word "posture" mean in this context?

--
Eric 

--> -Original Message-
--> From: Narayanan, Vidya [mailto:[EMAIL PROTECTED] 
--> Sent: Friday, May 26, 2006 2:05 PM
--> To: Sam Hartman; Bernard Aboba
--> Cc: ietf@ietf.org
--> Subject: RE: The Emperor Has No Clothes: Is PANA actually useful?
--> 
--> > 
--> > >>>>> "Bernard" == Bernard Aboba <[EMAIL PROTECTED]> writes:
--> > 
--> > >> My question is more why do they need EAP in 
--> situations where
--> > >> they are not running at the link layer than why do 
--> they want or
--> > >> not want PANA.
--> > 
--> > Bernard> The simple answer is that there are 
--> situations which IEEE
--> > Bernard> 802.1X cannot handle on wired networks.  As 
--> specified,
--> > Bernard> IEEE 802.1X is "network port control", which 
--> means that
--> > Bernard> authorization is controllable only at the 
--> port level.  If
--> > Bernard> there is more than one host connected to a 
--> switch port,
--> > Bernard> then that model no longer applies.
--> > 
--> > Yeah.  I guess I wonder whether you are actually getting 
--> > network access authenticatino at that point or whether you 
--> > are getting a service that allows you to check posture.  It 
--> > seems that a service that simply allows you to check posture 
--> > should be not EAP.
--> > 
--> 
--> 
--> I fully agree. As far as I can tell, using EAP in this manner merely
--> reduces it to a posture transport protocol. The level of security
--> provided by EAPoUDP does not seem to be any greater than a
--> kerberos-based authentication done today in most enterprise 
--> networks,
--> considering the presence of switched ethernet. Hence, the 
--> only reason to
--> move to EAPoUDP would be to check posture and I agree with Sam that
--> making EAP the posture transport protocol is a bad idea. 
--> 
--> Vidya
--> 
--> 
--> > ___
--> > Ietf mailing list
--> > Ietf@ietf.org
--> > https://www1.ietf.org/mailman/listinfo/ietf
--> > 
--> 
--> ___
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Lucy E. Lynch]

On Fri, 26 May 2006, Gray, Eric wrote:


For those of us that are just trying to follow this discussion,
what does the word "posture" mean in this context?


according to draft-thomson-nea-problem-statement-02.txt

"Posture: Posture refers to the hardware or software configuration of
   an endpoint as it pertains to an organization's security policy.
   Posture may include knowledge about the types of hardware and
   software installed and their configurations, e.g.  OS name and
   version, application patch levels, and anti-virus signature file
   version."




--
Eric

--> -Original Message-
--> From: Narayanan, Vidya [mailto:[EMAIL PROTECTED]
--> Sent: Friday, May 26, 2006 2:05 PM
--> To: Sam Hartman; Bernard Aboba
--> Cc: ietf@ietf.org
--> Subject: RE: The Emperor Has No Clothes: Is PANA actually useful?
-->
--> >
--> > >>>>> "Bernard" == Bernard Aboba <[EMAIL PROTECTED]> writes:
--> >
--> > >> My question is more why do they need EAP in
--> situations where
--> > >> they are not running at the link layer than why do
--> they want or
--> > >> not want PANA.
--> >
--> > Bernard> The simple answer is that there are
--> situations which IEEE
--> > Bernard> 802.1X cannot handle on wired networks.  As
--> specified,
--> > Bernard> IEEE 802.1X is "network port control", which
--> means that
--> > Bernard> authorization is controllable only at the
--> port level.  If
--> > Bernard> there is more than one host connected to a
--> switch port,
--> > Bernard> then that model no longer applies.
--> >
--> > Yeah.  I guess I wonder whether you are actually getting
--> > network access authenticatino at that point or whether you
--> > are getting a service that allows you to check posture.  It
--> > seems that a service that simply allows you to check posture
--> > should be not EAP.
--> >
-->
-->
--> I fully agree. As far as I can tell, using EAP in this manner merely
--> reduces it to a posture transport protocol. The level of security
--> provided by EAPoUDP does not seem to be any greater than a
--> kerberos-based authentication done today in most enterprise
--> networks,
--> considering the presence of switched ethernet. Hence, the
--> only reason to
--> move to EAPoUDP would be to check posture and I agree with Sam that
--> making EAP the posture transport protocol is a bad idea.
-->
--> Vidya
-->
-->
--> > ___
--> > Ietf mailing list
--> > Ietf@ietf.org
--> > https://www1.ietf.org/mailman/listinfo/ietf
--> >
-->
--> ___
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
-->

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



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

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Lakshminath Dondeti]

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


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:[EMAIL PROTECTED]
> Sent: Wednesday, May 24, 2006 3:44 PM
> To: Pekka Savola; Sam Hartman
> Cc: ietf@ietf.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" usin

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

[Narayanan, Vidya]

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

I am trying to figure out the use case for an IP layer solution in this
space as an access authentication protocol and I am not convinced that
we need something like PANA. If you are in fact, adding a node in the
middle of the access network that is going to perform access control, is
it just performing authentication or also attempting to derive keys and
secure the data traffic? With a solution like PANA, a link layer secure
association protocol or IPsec needs to be run to secure data traffic. If
the former, the authenticator (or at least the EP) needs to be located
at the edge. This needs support at the link layer anyway, and all such
link layers already support EAP. 

If the latter, the most natural solution to use is IKEv2 with EAP, since
even with PANA, you still need to run IKE/IKEv2 and IPsec - so, I don't
see what benefit PANA provides here. 

Perhaps I am missing something here? 

Regards,
Vidya

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Narayanan, Vidya]

Hi Jari,

> 
> Hi Lakshminath,
> 
> > 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.
> 
> 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.
> 


I am not sure that the VPN case and the access control in the 3G-WLAN
case are that different. The VPN access you are describing really
provides "remote access control". The point of that is that the edge
equipment is out of control (and potentially untrusted) of the entity
providing access and hence there is a need for remote access control. It
is essentially the same scenario for parts of 3G-WLAN interworking. The
access points may be provided by a vendor that is different from the
operator and hence, an operator's box is performing "remote access
control" using IPsec - the method to set up the IPsec SA was chosen to
be an IKEv2/EAP combination. Of course, in the cases where the WLAN
equipment can be trusted and is part of the operator's network, 802.11i
would potentially be used as you say. 

The only difference in the enterprise WLAN vs 3G-WLAN scenario is that
the former is providing intranet access, while the latter is for general
internet access even. However, this is really about semantics. If an
entity actually receives a valid IP address to use in the local network,
it only needs to perform IPsec/IKEv2 with the operator's box in the
3G-WLAN case for access to home domain services (no different really
from the corporate VPN case). 

Vidya

> 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
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Sam Hartman]

> "Gray," == Gray, Eric <[EMAIL PROTECTED]> writes:

Gray,> For those of us that are just trying to follow this
Gray,> discussion, what does the word "posture" mean in this
Gray,> context?

Assertions about your OS state--things like patch levels,
configuration of security settings, etc.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Tschofenig, Hannes]

Hi Dave,

thanks for your feedback. 
I guess your mail (and Jari's mail) try to be a little bit less biased
in this discussion. 

~snip~

> By contrast observations such as "there are better solutions" 

or 'different solutions'

> moves into the 
> fuzzier and more subjective realm of trying to predict market 

> preferences. The 
> IETF is not very good at making these predictions.  

That's very nicely phrased. I guess we could have a long discussion
about this subject and why other organizations do not use some IETF
protocols. We all know that there is the 'not invented here' problem,
sometimes a company marketing story ('company X has developed it's own
proprietary protocol') and in some other cases it is an IPR issue.

If we now raise the bar for IETF protocols to a level where we consider
work as 'successful' or 'good' when other organizations make use of
these protocols then we should change our workstyle a little bit. We
could just rubber stamp protocols these SDOs developed on their own ...

~snip~

A small comment when it comes to understand documents:

I have realized that it is popular in standardization organizations to
be temporarly and selectively confused about some things. 

I suspect that you can copy-and-paste Sam's mail, replace PANA with
another protocol and working group name, post it to the IETF mailing
list and you might get a similar response. 

> I would find it particularly helpful to have a concise 
> statement from someone 
> who says that PANA will not work.  Cannot be implemented 
> (properly) by virtue of 
> technical errors or documentation too confusing to 
> understand.  Or cannot be 
> deployed and used, by virtue of administrative complexity or, again, 
> documentation too confusing to understand.
> 
> Absent this, I will ask why it is productive to note that the 
> emperor is 
> pursuing an idiosynchratic sartorial style?

Sam accidently posted his mail shortly after the heated discussion of
PANA usage at the 3GPP2.
>From the comments on this mailing list it is obvious which company was
not favor for PANA (for whatever reason).

Ciao
Hannes

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Jari Arkko]

Hi Vidya,

>>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.
>>
>>
>>
>
>I am trying to figure out the use case for an IP layer solution in this
>space as an access authentication protocol and I am not convinced that
>we need something like PANA. If you are in fact, adding a node in the
>middle of the access network that is going to perform access control, is
>it just performing authentication or also attempting to derive keys and
>secure the data traffic? With a solution like PANA, a link layer secure
>association protocol or IPsec needs to be run to secure data traffic. If
>the former, the authenticator (or at least the EP) needs to be located
>at the edge. This needs support at the link layer anyway, and all such
>link layers already support EAP. 
>
>If the latter, the most natural solution to use is IKEv2 with EAP, since
>even with PANA, you still need to run IKE/IKEv2 and IPsec - so, I don't
>see what benefit PANA provides here. 
>  
>
My comment above relates to the overall interest in an IP layer solution
without considering what protocol is used.

I also wrote in my e-mail something about the different alternative
solutions. It is true that IKEv2 with EAP is potentially a good
fit for this task. IKEv2 is my favorite EAP encapsulation
protocol :-) However, its not clear that it currently has all
the parts (though I could have missed some extension somewhere).
For instance, some mechanism appears to be needed to discover
that you are in a network that requires this type of operation,
and to find the address of the control device that you need
to talk to. I haven't done the research on how easy it would
be to add this (probably quite easy) or if there are other
things that we would need. Thoughts?

Anyway, I agree with Dave Crocker that the bar should be
higher for using "there's another solution" argument in last
call discussion of chartered work than in, say, a BOF
discussion. Perhaps we should focus more on whether
the function itself is something that we agree on, and
what we can do to fix/scope/help PANA.

--Jari


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Vijay Devarapalli]

Lakshminath Dondeti wrote:

At 05:07 PM 5/24/2006, Vijay Devarapallli wrote:
On 5/24/06, Lakshminath Dondeti <[EMAIL PROTECTED]> 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 


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.  


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

that is not central to the discussion here.

regards,
Lakshminath

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Fleischman, Eric]

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!

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Narayanan, Vidya]

Hi Jari,

> 
> Hi Vidya,
> 
> >>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.
> >>
> >>
> >>
> >
> >I am trying to figure out the use case for an IP layer 
> solution in this 
> >space as an access authentication protocol and I am not 
> convinced that 
> >we need something like PANA. If you are in fact, adding a 
> node in the 
> >middle of the access network that is going to perform access 
> control, 
> >is it just performing authentication or also attempting to 
> derive keys 
> >and secure the data traffic? With a solution like PANA, a link layer 
> >secure association protocol or IPsec needs to be run to secure data 
> >traffic. If the former, the authenticator (or at least the 
> EP) needs to 
> >be located at the edge. This needs support at the link layer anyway, 
> >and all such link layers already support EAP.
> >
> >If the latter, the most natural solution to use is IKEv2 with EAP, 
> >since even with PANA, you still need to run IKE/IKEv2 and 
> IPsec - so, I 
> >don't see what benefit PANA provides here.
> >  
> >
> My comment above relates to the overall interest in an IP 
> layer solution without considering what protocol is used.
> 
> I also wrote in my e-mail something about the different 
> alternative solutions. It is true that IKEv2 with EAP is 
> potentially a good fit for this task. IKEv2 is my favorite 
> EAP encapsulation protocol :-) However, its not clear that it 
> currently has all the parts (though I could have missed some 
> extension somewhere).
> For instance, some mechanism appears to be needed to discover 
> that you are in a network that requires this type of 
> operation, and to find the address of the control device that 
> you need to talk to. I haven't done the research on how easy 
> it would be to add this (probably quite easy) or if there are 
> other things that we would need. Thoughts?
> 

Let me separate out two issues here. In order to discover that you are
in a network that requires this type of operation, you need to know via
some kind of advertisements (SSID, for instance) that you are not in the
home network. For instance, VPN connections today are mostly user
initiated. 

Another issue that you mention here is the discovery of the address of
the control device - this is typically done via DNS today. 

Thinking further about the PAA discovery mechanisms outlined in the PANA
protocol, it seems to bring some deployment concerns. Administratively
scoped multicast is one of the advocated methods of performing PAA
discovery. Administrative scoping of multicast is a huge administrative
burden and is not a good deployment option. Protocols like DVMRP allow
TTL scoping which are somewhat better. But, the thought of opening up
port control to allow multicast packets into the network prior to
authentication is not appealing to me. 

Another option that PANA provides for PAA discovery is traffic-driven
discovery. This is somewhat similar to what EAP relies on - i.e., the
network figures out that it needs to send an EAP Request Identity (in
the absence of an EAPoL-Start like message). 

In short, discovery hardly seems to be a reason to use PANA to me - I'm
trying to at least taste the kool-aid, even if I can't drink it all, but
somehow, am yet finding a convincing reason why I should :) 

Vidya


> Anyway, I agree with Dave Crocker that the bar should be 
> higher for using "there's another solution" argument in last 
> call discussion of chartered work than in, say, a BOF 
> discussion. Perhaps we should focus more on whether the 
> function itself is something that we agree on, and what we 
> can do to fix/scope/help PANA.
> 
> --Jari
> 
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Lakshminath Dondeti]

I tried this in my secdir review, for instance suggesting that 
perhaps PANA-IPsec should be limited to IKEv2 and 4301 and people had 
different opinions ranging from 'not sure about forcing IKEv2 on 
PANA' to 'there wouldn't be any differentiator to PANA' (they are not 
quotes; I am paraphrasing), and so really didn't find a consensus to 
make any recommendations.


In the end though, I think perhaps publishing PANA documents after 
the necessary clean-up as experimental and informational RFCs is the 
right way to go about it.  There is a long of line of WGs where this 
has happened and some of those documents have eventually come back 
into standards track.


best regards,
Lakshminath

At 02:30 PM 5/26/2006, Jari Arkko wrote:

Anyway, I agree with Dave Crocker that the bar should be
higher for using "there's another solution" argument in last
call discussion of chartered work than in, say, a BOF
discussion. Perhaps we should focus more on whether
the function itself is something that we agree on, and
what we can do to fix/scope/help PANA.

--Jari



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Jari Arkko]

Lakshminath Dondeti wrote:

> I tried this in my secdir review, for instance suggesting that perhaps
> PANA-IPsec should be limited to IKEv2 and 4301 and people had
> different opinions ranging from 'not sure about forcing IKEv2 on PANA'
> to 'there wouldn't be any differentiator to PANA' (they are not
> quotes; I am paraphrasing), and so really didn't find a consensus to
> make any recommendations.

That discussion has still been going on (but I forget if it
was in secdir list, with the ADs, or on the PANA list). FWIW,
I fully agree that limiting to IKEv2 would be the right choice.

--Jari



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Yoshihiro Ohba]

Vidya,

Administratively scoped multicast is not the only way for PAA
discovery.  DHCP based PAA discovery is also available:

draft-ietf-dhc-paa-option-02.txt

Regards,
Yoshihiro Ohba


On Fri, May 26, 2006 at 04:34:22PM -0700, Narayanan, Vidya wrote:
> Hi Jari,
> 
> > 
> > Hi Vidya,
> > 
> > >>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.
> > >>
> > >>
> > >>
> > >
> > >I am trying to figure out the use case for an IP layer 
> > solution in this 
> > >space as an access authentication protocol and I am not 
> > convinced that 
> > >we need something like PANA. If you are in fact, adding a 
> > node in the 
> > >middle of the access network that is going to perform access 
> > control, 
> > >is it just performing authentication or also attempting to 
> > derive keys 
> > >and secure the data traffic? With a solution like PANA, a link layer 
> > >secure association protocol or IPsec needs to be run to secure data 
> > >traffic. If the former, the authenticator (or at least the 
> > EP) needs to 
> > >be located at the edge. This needs support at the link layer anyway, 
> > >and all such link layers already support EAP.
> > >
> > >If the latter, the most natural solution to use is IKEv2 with EAP, 
> > >since even with PANA, you still need to run IKE/IKEv2 and 
> > IPsec - so, I 
> > >don't see what benefit PANA provides here.
> > >  
> > >
> > My comment above relates to the overall interest in an IP 
> > layer solution without considering what protocol is used.
> > 
> > I also wrote in my e-mail something about the different 
> > alternative solutions. It is true that IKEv2 with EAP is 
> > potentially a good fit for this task. IKEv2 is my favorite 
> > EAP encapsulation protocol :-) However, its not clear that it 
> > currently has all the parts (though I could have missed some 
> > extension somewhere).
> > For instance, some mechanism appears to be needed to discover 
> > that you are in a network that requires this type of 
> > operation, and to find the address of the control device that 
> > you need to talk to. I haven't done the research on how easy 
> > it would be to add this (probably quite easy) or if there are 
> > other things that we would need. Thoughts?
> > 
> 
> Let me separate out two issues here. In order to discover that you are
> in a network that requires this type of operation, you need to know via
> some kind of advertisements (SSID, for instance) that you are not in the
> home network. For instance, VPN connections today are mostly user
> initiated. 
> 
> Another issue that you mention here is the discovery of the address of
> the control device - this is typically done via DNS today. 
> 
> Thinking further about the PAA discovery mechanisms outlined in the PANA
> protocol, it seems to bring some deployment concerns. Administratively
> scoped multicast is one of the advocated methods of performing PAA
> discovery. Administrative scoping of multicast is a huge administrative
> burden and is not a good deployment option. Protocols like DVMRP allow
> TTL scoping which are somewhat better. But, the thought of opening up
> port control to allow multicast packets into the network prior to
> authentication is not appealing to me. 
> 
> Another option that PANA provides for PAA discovery is traffic-driven
> discovery. This is somewhat similar to what EAP relies on - i.e., the
> network figures out that it needs to send an EAP Request Identity (in
> the absence of an EAPoL-Start like message). 
> 
> In short, discovery hardly seems to be a reason to use PANA to me - I'm
> trying to at least taste the kool-aid, even if I can't drink it all, but
> somehow, am yet finding a convincing reason why I should :) 
> 
> Vidya
> 
> 
> > Anyway, I agree with Dave Crocker that the bar should be 
> > higher for using "there's another solution" argument in last 
> > call discussion of chartered work than in, say, a BOF 
> > discussion. Perhaps we should focus more on whether the 
> > function itself is something that we agree on, and what we 
> > can do to fix/scope/help PANA.
> > 
> > --Jari
> > 
> > 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Yoshihiro Ohba]

Vidya,

Overall, network access authentication and establishing IPsec SA are
two related but different things.  EAP over IKEv2 is an integrated
approach while PANA framework is a split approach.  In general, both
approaches have pros and cons.  Speaking of the split approach, there
are number of reasons for why splitting is useful:

- If you implement PANA, gateway discovery comes free.  However, the
integrated approach could also define its own gateway discovery
mechanism.

- Since EAP over IKEv2 does not cache EAP keying material or
parameters, when IKE_SA is deleted for many reasons, the client needs
to run EAP over IKEv2 again when a new IKE_SA needs to be established
sometime later.  In PANA case, EAP keying material is cached by PAA as
long as the PANA session remains, and the keying material is reusable
for establishing new IKE_SAs without running another EAP.

- Since EAP over IKEv2 does not cache EAP keying material, when the
client needs to create multiple IKE_SAs for a particular gateway for
many reasons, the client needs to run EAP for each IKE_SA.  In PANA
case, one EAP run is sufficient for establishing multiple IKE_SAs for
the same gateway.

- As Alper already mentioned, since PANA allows PAA and EP to be
separated, one EAP run is sufficient for establishing multiple IKE_SAs
for different gateways (EPs) controlled by the same PAA instead of
running multiple EAP runs for multiple IKE_SAs.

- In an environment where network access authentication is needed but
not IPsec SA (e.g., DSL), EAP over IKEv2 is too much.

Hope this helps,
Yoshihiro Ohba


On Fri, May 26, 2006 at 12:00:31PM -0700, Narayanan, Vidya wrote:
> Hi Jari,
> 
> > 
> > Hi Lakshminath,
> > 
> > > 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.
> > 
> > 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.
> > 
> 
> 
> I am not sure that the VPN case and the access control in the 3G-WLAN
> case are that different. The VPN access you are describing really
> provides "remote access control". The point of that is that the edge
> equipment is out of control (and potentially untrusted) of the entity
> providing access and hence there is a need for remote access control. It
> is essentially the same scenario for parts of 3G-WLAN interworking. The
> access points may be provided by a vendor that is different from the
> operator and hence, an operator's box is performing "remote access
> control" using IPsec - the method to set up the IPsec SA was chosen to
> be an IKEv2/EAP combination. Of course, in the cases where the WLAN
> equipment can be trusted and is part of the operator's network, 802.11i
> would potentially be used as you say. 
> 
> The only difference in the enterprise WLAN vs 3G-WLAN scenario is that
> the former is providing intranet access, while the latter is for general
> internet access even. However, this is really about semantics. If an
> entity actually receives a valid IP address to use in the local network,
> it only needs to perform IPsec/IKEv2 with the operator's box in the
> 3G-WLAN case for access to home domain services (no different really
> from the corporate VPN case). 
> 
> Vidya
> 
> > 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
> > 
> > 
> > ___
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ietf
> > 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Junghoon Jee]

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

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

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

[Tschofenig, Hannes]

Hi Jari, 

> Anyway, I agree with Dave Crocker that the bar should be
> higher for using "there's another solution" argument in last
> call discussion of chartered work than in, say, a BOF
> discussion. Perhaps we should focus more on whether
> the function itself is something that we agree on, and
> what we can do to fix/scope/help PANA.

That's very true given that some solutions that were mentioned in the
discussion appeared recently while the PANA protocol was in AD
Evaluation for a long time already. One example:
draft-barany-eap-gee-00.txt

Ciao
Hannes

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Avi Lior]

Lakshminath,

Please see inline... 

> -Original Message-
> From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] 
> Sent: Friday, May 26, 2006 2:32 PM
> To: Avi Lior; Pekka Savola; Sam Hartman
> Cc: ietf@ietf.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

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

[Brian E Carpenter]

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:[EMAIL PROTECTED] 
Sent: Friday, May 26, 2006 2:32 PM

To: Avi Lior; Pekka Savola; Sam Hartman
Cc: ietf@ietf.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
XX!  In order to sway support towards EAP over HRPD, X
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 s

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

[Yoshihiro Ohba]

Hi Joel,

Thank you for spending your time reading the framework document and
sending your feedback.  Please see my response below.

On Fri, May 26, 2006 at 08:27:29AM -0400, Joel M. Halpern wrote:
> In reading the PANA Framework document,  what I read seemed to me to 
> be more of a "system" or "solution" document than a clean IETF 
> protocol framework.

I think your reading is correct.  The document describes how different
types of access network deployments are enabled by PANA.

> 
> I saw efforts to address three different problems:
> 1) Securing an otherwise unsecured link, when the access node is not 
> known to the client in advance.
> 2) Selecting an authorization (charging, possibly packet handling) service

Just to make sure, do you mean by 2) network selection that is
described in Section 8 of pana-framework draft?

> 3) Authenticating the user
> 
> EAP over IP (or UDP, or link) is about authenticating the user.  If a 
> media independent technique better than just using a browser is 
> needed, then solve that problem.  

This is surely one problem PANA is trying to solve, and has been
clarified from the beginning of the work and more in this dicussion, I
believe.

> Personally, I would find the work 
> far more persuasive if it did not also try to solve the problem of 
> creating an IPSec association to the access device, nor of the 
> authorization selection problem.

Bootstrapping lower-layer ciphering (IPsec and link-layer ciphering)
from EAP-based network access authentication is another problem.  When
a lower-layer does not provide EAP service, it is clear that PANA is a
standard way to solve the problem.  Perhaps the main confusion is
coming from the fact, as a side effect of solving this bootstrapping
problem, that it is possible to use PANA to bootstrap lower-layer
ciphering *even if the lower-layer supports EAP*.  While I understand
the confusion but let me explain several reasons for why I think this
is still viable for lower-layers that support EAP.

- Use of PANA for bootstrapping IKEv2.  I explained several reasons
for why doing this while IKEv2 can carry EAP, in my response to Vidya:
http://www1.ietf.org/mail-archive/web/ietf/current/msg42002.html.

- Use of PANA for bootstrapping IEEE 802.11i PSK mode.  This makes APs
and non-AP STAs that support 802.11i but do not support 802.11r can
transit from one AP to another without necessarily perform EAP for
every AP transition as long as the APs are acting as EPs of the same
PAA.  One may argue that this usage becomes useless when all APs and
non-AP STAs are migrated to 802.11r, but it is still possible to use
PANA for inter-ESS transition which is not covered by 802.11r.

> 
> And spell out in clear English what use case needs that problem 
> solved.  I can read between the lines and start to guess.  But the 
> document is quite unclear.  The appendix about DSL is not helpful in 
> that regard.

One of the reasons for this may be that the problem statement and
requirements are described in a separate RFC (i.e., RFC 4058) not in
the pana-framework draft.  Of course another reason may be that I, the
editor of the draft, am not a native English speaker.

BTW, there is no appendix in pana-dramework draft.  So you may refer
to Section 10.1 about DSL.  Is this correct?

I hope this sheds some light on the discussion.

Yoshihiro Ohba

> 
> Yours,
> Joel M. Halpern
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Florian Weimer]

* Bernard Aboba:

>> My question is more why do they need EAP in situations where they are
>> not running at the link layer than why do they want or not want PANA.
>
> The simple answer is that there are situations which IEEE 802.1X cannot 
> handle on wired networks.  As specified, IEEE 802.1X is "network port 
> control", which means that authorization is controllable only at the port 
> level.  If there is more than one host connected to a switch port, then 
> that model no longer applies. 

Isn't this just a "don't do that, then" scenario?  Plugging in a hub
tends to undermine much of the accountability 802.1X is supposed to
provide.

Anyway, 802.1X is terminally broken because end users can rewire that
port and bypass security policies (put a laptop with bridging software
onto it, plug in a hub, and so on).  It's very hard to solve this
problem at a sub-IP layer because you need an ARP replacement which is
tied to the port (physical layer) and IP rouuting (network layer) at
the same time, and in a secure fashion.  And without some cryptography
on the payload, you still won't be able to tell two hosts on the same
port apart.

My personal conclusion from this mess is to give up trying to make the
sub-IP layers secure, but start directly at the IP layer.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Bernard Aboba]

> Isn't this just a "don't do that, then" scenario?  Plugging in a hub
> tends to undermine much of the accountability 802.1X is supposed to
> provide.

Sure, except that the cost of "don't do that" is rather high -- a switch 
port for every host. 

> Anyway, 802.1X is terminally broken because end users can rewire that
> port and bypass security policies (put a laptop with bridging software
> onto it, plug in a hub, and so on).  

The issue here is not key exchange; it's the lack of data protection.  
IEEE 802.11i derives a unique key per STA MAC, using it to key link 
layer ciphersuites providing encryption/integrity/replay protection, which 
eliminates piggybacking.  Yet it relies on 802.1X.  My understanding is that 
802.1ae/af will also solve the problem, by enabling "virtual ports".  

>It's very hard to solve this problem at a sub-IP layer 

I think the point is that there is a significant need (at least in the 
short term) for a transitional solution.  Enterprise WPA/WPA2 
is being deployed, albeit perhaps more slowly than we'd like.  Moving the 
problem up a layer doesn't really address expense/deployment 
concerns that much, especially since IPsec acceleration chipsets ship in 
much lower volumes than say, chipsets supporting 802.11, 802.3 or other 
link layer technologies. At the end of the day, there is significant 
appeal in being able to roll out solutions that don't require forklift 
upgrades.  


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: The Emperor Has No Clothes: Is PANA actually useful?,

[Subir Das]

I have been trying to post the following message last few days but failed.
Another try..

Subir Das wrote:
I have read both PANA protocol and PANA framework drafts. I understand 
the concept and it is an useful protocol to me. In particular, EAP 
over IP is necessary, IMO, and my understanding is that PANA base 
protocol is all about EAP over IP. The framework document should be an 
informational one and those scenarios that are described in PANA 
framework document should be treated as examples only. Also these are 
not only the scenarios that people will like to or deploy in their 
networks. There are several business aspects to it. I also believe 
that many folks in IETF would like to see a protocol that support EAP 
over IP. Since PANA has been chartered to address this problem, folks 
should work within the PANA WG and resolve the issues, if there is any.


AFAIK, several network security experts have reviewed the PANA 
documents but I have not seen any major security issue with the PANA 
protocol discussed either in the mailing list or at the WG level so 
far. Saying that the protocol is too complex and there is a simpler 
solution will not help much, IMO, unless we really compare the 
technical merits and demerits. We had some discussions with the 
operators and many of them think that a protocol like PANA would be 
very useful in their networks, if standardized it quickly. It's 
already late!!
regards, 
-Subir






---
Sam Hartman said:

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
Ietf at ietf.org
https://www1.ietf.org/mailman

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

[Yoshihiro Ohba]

Hi Joel,

Reading the entire thread, I think we should seriously consider your
detailed suggestions to improve the PANA framework draft for broader
acceptance in the community.

Thank you,
Yoshihiro Ohba


On Tue, May 30, 2006 at 09:42:25AM -0400, Joel M. Halpern wrote:
> I think the confusion and complexity that I perceive comes from the 
> fact that the framework problem treats all the tasks (user 
> authentication, network selection, and securing the network 
> connection as being of the same significance or same relationship to 
> the solution.
> 
> I think that most of the discussion of IPSec and pre-post PANA 
> addresses does not belong here at all.
> 
> Let me suggest an approach that might simplify and shorten the document:
> [Unfortuantely, I can't promise that it will fix everyone's problems.]
> 
> 2. Describe the primary goal of PANA, and approach thereto.  This 
> would state that the goal is to authenticate the user using an IP 
> level protocol.  This would probably state that the primary approach 
> is to proivde a transport for EAP that meets the requirements for an 
> EAP transport [cite RFC.]
> 
> 3. Describe very briefly the interaction between the EP and the 
> PAA.  State that the protocol between them is out of scope.  Note 
> that the EP must allow PANA messages to the PAA before authentication 
> is completed.  (Yes, that's obvious, but it is actually worth stating.)
> 
> 4. Describe that PANA protocol needs to provide for negotiation of 
> information before authentication.  List briefly some of the things 
> to be negotiated (services available, algorithms available.)  Also 
> indicate that the PANA protocol can provide additional 
> post-authentication information to the client (in the PANA response) 
> and to the EP.
> 
> Securing the data channel between the PCC and the EP should be out of 
> scope.  If you want to say anything about that, you might note that 
> this may be done in a link specific fashion, in may be done with an 
> unauthenticated IP exchange before PANA, or PANA may be used to carry 
> additional credentials / keys to be used to establish an 
> authenticated secure association.  The reason I would not include 
> this is that the question of why I need an authenticated exchange 
> will complicate the document.  The other reason for not describing it 
> is that it does not change the framework at all, and should be 
> documented as a usage of PANA capabilities, in its protocol RFC.
> 
> I would then probably dramatically reduce section 10.  Trying to 
> describe all those cases does not actually help the reader get the 
> mental model.  And I think they are too deployment specific.
> 
> The real key here is to focus on the primary goal.  The resulting 
> document ought to be clearer, and focused on the problem that needs 
> to be solved.  It can indicate that PANA can be used to help other 
> things, but that those things are not the purpose / point of PANA.
> 
> At 12:29 AM 5/30/2006, Yoshihiro Ohba wrote:
> >Hi Joel,
> >
> >Thank you for spending your time reading the framework document and
> >sending your feedback.  Please see my response below.
> >
> >On Fri, May 26, 2006 at 08:27:29AM -0400, Joel M. Halpern wrote:
> >> In reading the PANA Framework document,  what I read seemed to me to
> >> be more of a "system" or "solution" document than a clean IETF
> >> protocol framework.
> >
> >I think your reading is correct.  The document describes how different
> >types of access network deployments are enabled by PANA.
> >
> >>
> >> I saw efforts to address three different problems:
> >> 1) Securing an otherwise unsecured link, when the access node is not
> >> known to the client in advance.
> >> 2) Selecting an authorization (charging, possibly packet handling) 
> >service
> >
> >Just to make sure, do you mean by 2) network selection that is
> >described in Section 8 of pana-framework draft?
> >
> >> 3) Authenticating the user
> >>
> >> EAP over IP (or UDP, or link) is about authenticating the user.  If a
> >> media independent technique better than just using a browser is
> >> needed, then solve that problem.
> >
> >This is surely one problem PANA is trying to solve, and has been
> >clarified from the beginning of the work and more in this dicussion, I
> >believe.
> >
> >> Personally, I would find the work
> >> far more persuasive if it did not also try to solve the problem of
> >> creating an IPSec association to the access device, nor of the
> >> authorization selection problem.
> >
> >Bootstrapping lower-layer ciphering (IPsec and link-layer ciphering)
> >from EAP-based network access authentication is another problem.  When
> >a lower-layer does not provide EAP service, it is clear that PANA is a
> >standard way to solve the problem.  Perhaps the main confusion is
> >coming from the fact, as a side effect of solving this bootstrapping
> >problem, that it is possible to use PANA to bootstrap lower-layer
> >ciphering *even if the lower-layer supports EAP*.  

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

[Joel M. Halpern]

I think the confusion and complexity that I perceive comes from the 
fact that the framework problem treats all the tasks (user 
authentication, network selection, and securing the network 
connection as being of the same significance or same relationship to 
the solution.


I think that most of the discussion of IPSec and pre-post PANA 
addresses does not belong here at all.


Let me suggest an approach that might simplify and shorten the document:
[Unfortuantely, I can't promise that it will fix everyone's problems.]

2. Describe the primary goal of PANA, and approach thereto.  This 
would state that the goal is to authenticate the user using an IP 
level protocol.  This would probably state that the primary approach 
is to proivde a transport for EAP that meets the requirements for an 
EAP transport [cite RFC.]


3. Describe very briefly the interaction between the EP and the 
PAA.  State that the protocol between them is out of scope.  Note 
that the EP must allow PANA messages to the PAA before authentication 
is completed.  (Yes, that's obvious, but it is actually worth stating.)


4. Describe that PANA protocol needs to provide for negotiation of 
information before authentication.  List briefly some of the things 
to be negotiated (services available, algorithms available.)  Also 
indicate that the PANA protocol can provide additional 
post-authentication information to the client (in the PANA response) 
and to the EP.


Securing the data channel between the PCC and the EP should be out of 
scope.  If you want to say anything about that, you might note that 
this may be done in a link specific fashion, in may be done with an 
unauthenticated IP exchange before PANA, or PANA may be used to carry 
additional credentials / keys to be used to establish an 
authenticated secure association.  The reason I would not include 
this is that the question of why I need an authenticated exchange 
will complicate the document.  The other reason for not describing it 
is that it does not change the framework at all, and should be 
documented as a usage of PANA capabilities, in its protocol RFC.


I would then probably dramatically reduce section 10.  Trying to 
describe all those cases does not actually help the reader get the 
mental model.  And I think they are too deployment specific.


The real key here is to focus on the primary goal.  The resulting 
document ought to be clearer, and focused on the problem that needs 
to be solved.  It can indicate that PANA can be used to help other 
things, but that those things are not the purpose / point of PANA.


At 12:29 AM 5/30/2006, Yoshihiro Ohba wrote:

Hi Joel,

Thank you for spending your time reading the framework document and
sending your feedback.  Please see my response below.

On Fri, May 26, 2006 at 08:27:29AM -0400, Joel M. Halpern wrote:
> In reading the PANA Framework document,  what I read seemed to me to
> be more of a "system" or "solution" document than a clean IETF
> protocol framework.

I think your reading is correct.  The document describes how different
types of access network deployments are enabled by PANA.

>
> I saw efforts to address three different problems:
> 1) Securing an otherwise unsecured link, when the access node is not
> known to the client in advance.
> 2) Selecting an authorization (charging, possibly packet handling) service

Just to make sure, do you mean by 2) network selection that is
described in Section 8 of pana-framework draft?

> 3) Authenticating the user
>
> EAP over IP (or UDP, or link) is about authenticating the user.  If a
> media independent technique better than just using a browser is
> needed, then solve that problem.

This is surely one problem PANA is trying to solve, and has been
clarified from the beginning of the work and more in this dicussion, I
believe.

> Personally, I would find the work
> far more persuasive if it did not also try to solve the problem of
> creating an IPSec association to the access device, nor of the
> authorization selection problem.

Bootstrapping lower-layer ciphering (IPsec and link-layer ciphering)
from EAP-based network access authentication is another problem.  When
a lower-layer does not provide EAP service, it is clear that PANA is a
standard way to solve the problem.  Perhaps the main confusion is
coming from the fact, as a side effect of solving this bootstrapping
problem, that it is possible to use PANA to bootstrap lower-layer
ciphering *even if the lower-layer supports EAP*.  While I understand
the confusion but let me explain several reasons for why I think this
is still viable for lower-layers that support EAP.

- Use of PANA for bootstrapping IKEv2.  I explained several reasons
for why doing this while IKEv2 can carry EAP, in my response to Vidya:
http://www1.ietf.org/mail-archive/web/ietf/current/msg42002.html.

- Use of PANA for bootstrapping IEEE 802.11i PSK mode.  This makes APs
and non-AP STAs that support 802.11i but do not support 802.11r can
transit from o

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

[Gray, Eric]

Lucy,

Thanks!

--
E 

--> -Original Message-
--> From: Lucy E. Lynch [mailto:[EMAIL PROTECTED] 
--> Sent: Friday, May 26, 2006 2:31 PM
--> To: Gray, Eric
--> Cc: Narayanan, Vidya; Sam Hartman; Bernard Aboba; ietf@ietf.org
--> Subject: RE: The Emperor Has No Clothes: Is PANA actually useful?
--> 
--> On Fri, 26 May 2006, Gray, Eric wrote:
--> 
--> > For those of us that are just trying to follow this discussion,
--> > what does the word "posture" mean in this context?
--> 
--> according to draft-thomson-nea-problem-statement-02.txt
--> 
--> "Posture: Posture refers to the hardware or software 
--> configuration of
--> an endpoint as it pertains to an organization's security policy.
--> Posture may include knowledge about the types of hardware and
--> software installed and their configurations, e.g.  OS name and
--> version, application patch levels, and anti-virus signature file
--> version."
--> 
--> 
--> 
--> > --
--> > Eric
--> >
--> > --> -Original Message-
--> > --> From: Narayanan, Vidya [mailto:[EMAIL PROTECTED]
--> > --> Sent: Friday, May 26, 2006 2:05 PM
--> > --> To: Sam Hartman; Bernard Aboba
--> > --> Cc: ietf@ietf.org
--> > --> Subject: RE: The Emperor Has No Clothes: Is PANA 
--> actually useful?
--> > -->
--> > --> >
--> > --> > >>>>> "Bernard" == Bernard Aboba 
--> <[EMAIL PROTECTED]> writes:
--> > --> >
--> > --> > >> My question is more why do they need EAP in
--> > --> situations where
--> > --> > >> they are not running at the link layer than why do
--> > --> they want or
--> > --> > >> not want PANA.
--> > --> >
--> > --> > Bernard> The simple answer is that there are
--> > --> situations which IEEE
--> > --> > Bernard> 802.1X cannot handle on wired networks.  As
--> > --> specified,
--> > --> > Bernard> IEEE 802.1X is "network port control", which
--> > --> means that
--> > --> > Bernard> authorization is controllable only at the
--> > --> port level.  If
--> > --> > Bernard> there is more than one host connected to a
--> > --> switch port,
--> > --> > Bernard> then that model no longer applies.
--> > --> >
--> > --> > Yeah.  I guess I wonder whether you are actually getting
--> > --> > network access authenticatino at that point or whether you
--> > --> > are getting a service that allows you to check posture.  It
--> > --> > seems that a service that simply allows you to check posture
--> > --> > should be not EAP.
--> > --> >
--> > -->
--> > -->
--> > --> I fully agree. As far as I can tell, using EAP in 
--> this manner merely
--> > --> reduces it to a posture transport protocol. The level 
--> of security
--> > --> provided by EAPoUDP does not seem to be any greater than a
--> > --> kerberos-based authentication done today in most enterprise
--> > --> networks,
--> > --> considering the presence of switched ethernet. Hence, the
--> > --> only reason to
--> > --> move to EAPoUDP would be to check posture and I agree 
--> with Sam that
--> > --> making EAP the posture transport protocol is a bad idea.
--> > -->
--> > --> Vidya
--> > -->
--> > -->
--> > --> > ___
--> > --> > Ietf mailing list
--> > --> > Ietf@ietf.org
--> > --> > https://www1.ietf.org/mailman/listinfo/ietf
--> > --> >
--> > -->
--> > --> ___
--> > --> Ietf mailing list
--> > --> Ietf@ietf.org
--> > --> https://www1.ietf.org/mailman/listinfo/ietf
--> > -->
--> >
--> > ___
--> > Ietf mailing list
--> > Ietf@ietf.org
--> > https://www1.ietf.org/mailman/listinfo/ietf
--> >
--> 
--> -- 
--> Lucy E. Lynch   Academic User Services
--> Computing CenterUniversity of Oregon
--> llynch  @darkwing.uoregon.edu   (541) 346-1774
--> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Gray, Eric]

Sam,

Thanks!

--
E 

--> -Original Message-
--> From: Sam Hartman [mailto:[EMAIL PROTECTED] 
--> Sent: Friday, May 26, 2006 5:20 PM
--> To: Gray, Eric
--> Cc: Narayanan, Vidya; Bernard Aboba; ietf@ietf.org
--> Subject: Re: The Emperor Has No Clothes: Is PANA actually useful?
--> 
--> >>>>> "Gray," == Gray, Eric <[EMAIL PROTECTED]> writes:
--> 
--> Gray,> For those of us that are just trying to follow this
--> Gray,> discussion, what does the word "posture" mean in this
--> Gray,> context?
--> 
--> Assertions about your OS state--things like patch levels,
--> configuration of security settings, etc.
--> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Brian E Carpenter]

Yoshihiro Ohba wrote:

Hi Joel,

Reading the entire thread, I think we should seriously consider your
detailed suggestions to improve the PANA framework draft for broader
acceptance in the community.


Which is strong hint that this discussion now belongs on the PANA
mailing list.

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: The Emperor Has No Clothes: Is PANA actually useful?,

[Subir Das]

I have read both PANA protocol and PANA framework drafts. I understand 
the concept and it seems to me an useful protocol. In particular, EAP 
over IP is necessary, IMO, and my understanding is that PANA base protocol 
is all about EAP over IP. The framework document should be an informational 
one and those scenarios that are described in PANA framework document should 
be treated as examples only. In fact, we don't see similar documents in 
many other WGs and therefore it should not be a requirement for PANA 
protocol. I also believe that many folks in IETF like to see a protocol 
that support EAP over IP. Since PANA has been chartered to address this 
problem, folks should work within the PANA WG and resolve the issues, 
if there is any.


AFAIK, several network security experts have reviewed the PANA documents 
but I have not seen any major security issue with the PANA protocol 
discussed either in the mailing list or at the WG level. We had some discussions 
with the operators and many of them think that a protocol like PANA should 
have been available yesterday. We know few proprietary solutions that can be 
replaced by an IETF work like PANA.  

regards, 
-Subir 







---
Sam Hartman said:

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
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf




___
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/m

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

[Basavaraj Patil]

Dave Crocker wrote:


I would find it particularly helpful to have a concise statement from
someone who says that PANA will not work. Cannot be implemented
(properly) by virtue of technical errors or documentation too
confusing to understand. Or cannot be deployed and used, by virtue of
administrative complexity or, again, documentation too confusing to
understand.


The fact that the IETF is supposed to be based on "Rough consensus and
running code" is completely being missed here. Currently there are
multiple interoperable implementation of the protocol in addition to
there existing an open-source implementation as well.
The fact that several years of peoples work and effort has gone into
this is being ignored by claims that I find quite have a vested
interest.



Absent this, I will ask why it is productive to note that the emperor
is pursuing an idiosynchratic sartorial style?


I would also expect to hear a response to this. I would also like to
ask if the people who claim to be unable to understand the scenarios
where PANA can be applied have attended a PANA WG meeting or have
cared to ask these questions on the ML.



d/


-Raj

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: The Emperor Has No Clothes: Is PANA actually useful?,

[Hidetoshi Yokota]

I happened to hit this thread and read the PANA framework document. I 
eventually had a similar impression below. The framework document may be 
a bit meticulous, but the protocol itself doesn’t look so complicated. 
L2 level of authentication will usually provide optimal performance on 
each individual MAC; however, there is a growing demand to support 
multiple wireless technologies on one terminal and if we consider 
heterogeneous handover on these wireless technologies, we can see a real 
benefit of a link-layer agnostic authentication approach, by which the 
terminal doesn’t have to support each authentication method for each 
MAC. I’m aware that there are several candidates to meet this 
requirement besides PANA, but PANA seems to be ahead of others regarding 
the maturity of specifications. This does not mean PANA is the best 
choice and I see PANA has not been really deployed yet, but from a 
user’s perspective, I would like to see it go and let the market choose 
the best suited out of these candidates.


Best regards,
-- Hidetoshi

Subir Das wrote:
I have read both PANA protocol and PANA framework drafts. I understand 
the concept and it seems to me an useful protocol. In particular, EAP 
over IP is necessary, IMO, and my understanding is that PANA base 
protocol is all about EAP over IP. The framework document should be an 
informational one and those scenarios that are described in PANA 
framework document should be treated as examples only. In fact, we don't 
see similar documents in many other WGs and therefore it should not be a 
requirement for PANA protocol. I also believe that many folks in IETF 
like to see a protocol that support EAP over IP. Since PANA has been 
chartered to address this problem, folks should work within the PANA WG 
and resolve the issues, if there is any.


AFAIK, several network security experts have reviewed the PANA documents 
but I have not seen any major security issue with the PANA protocol 
discussed either in the mailing list or at the WG level. We had some 
discussions with the operators and many of them think that a protocol 
like PANA should have been available yesterday. We know few proprietary 
solutions that can be replaced by an IETF work like PANA. 
regards, -Subir





---
Sam Hartman said:

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

Re: AW: The Emperor Has No Clothes: Is PANA actually useful?

[Mohan Parthasarathy]

  
>  
> 
> A small comment when it comes to understand
> documents:
> 
> I have realized that it is popular in
> standardization organizations to
> be temporarly and selectively confused about some
> things. 
> 
> I suspect that you can copy-and-paste Sam's mail,
> replace PANA with
> another protocol and working group name, post it to
> the IETF mailing
> list and you might get a similar response. 
> 
Agreed. Perhaps, we should do this all working
groups in the IETF. I have no doubt in my mind
that this list will be flooded with countless
*opinions*. Perhaps, PANA is the first one
on the list and others to follow soon..

-mohan

> > I would find it particularly helpful to have a
> concise 
> > statement from someone 
> > who says that PANA will not work.  Cannot be
> implemented 
> > (properly) by virtue of 
> > technical errors or documentation too confusing to
> 
> > understand.  Or cannot be 
> > deployed and used, by virtue of administrative
> complexity or, again, 
> > documentation too confusing to understand.
> > 
> > Absent this, I will ask why it is productive to
> note that the 
> > emperor is 
> > pursuing an idiosynchratic sartorial style?
> 
> Sam accidently posted his mail shortly after the
> heated discussion of
> PANA usage at the 3GPP2.
> >From the comments on this mailing list it is
> obvious which company was
> not favor for PANA (for whatever reason).
> 
> Ciao
> Hannes
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

NEA scope (RE: The Emperor Has No Clothes: Is PANA actually useful?)

[Alper Yegin]

I, as a PANA WG chair, have many issues with this thread. It's objective,
execution, place in IETF process, roles and responsibilities, etc. I'm not
going to get into that now (yet). But I want to say I don't see how it's
going to achieve what Sam thinks he wants to achieve -- neither the need for
doing that as I explained earlier.

We'll try to weed out the technical and useful stuff out of this jungle. Let
me create separate threads for those and see if we can prevent further
confusion before people confuse each other, and identify what additional
work needs to be done on our documents.

With that in mind, here is the first thread.

> -Original Message-
> From: Sam Hartman [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 26, 2006 8:05 AM
> To: Alper Yegin
> Cc: 'Bernard Aboba'; ietf@ietf.org
> Subject: Re: The Emperor Has No Clothes: Is PANA actually useful?
> 
> >>>>> "Alper" == Alper Yegin <[EMAIL PROTECTED]> writes:
> 
> >> > Yes, that individual I-D is productized as a proprietary
> >> protocol by one > company (Cisco).
> >>
> >> As I understand it, EAP over UDP is one of the items proposed
> >> for standardization in the NEA WG.
> 
> Alper> You misunderstood it, despite the clear text in their
> Alper> charter:
> 
> Alper> ...
> 
> Alper>   Requirements need to be defined for an EAP over L3
> Alper> transport for L3 access scenarios.
> 
> I don't think he misunderstood.  IT may not be in their charter, but
> they definitely did want to standardize EAP over UDP in at least some
> versions of NEA.

This is not how the NEA charter read (see my above quotes). Where did you
get this idea from? 


> 
> My question is more why do they need EAP in situations where they are
> not running at the link layer than why do they want or not want PANA.


This is something that needs to be asked to the NEA community. PANA
community did not invent using PANA for NEA. When NEA people said they
needed IP over UDP, we said PANA does that.

Alper




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?)

[Alper Yegin]

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

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

> So far evaluations done by the broader
> community seem to be concluding that PANA is in fact complex and not
> easily deployable.

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


 



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

automatic discovery [Re: The Emperor Has No Clothes: Is PANA actually useful?]

[Pekka Savola]

On Sat, 27 May 2006, Yoshihiro Ohba wrote:


Vidya,

Administratively scoped multicast is not the only way for PAA
discovery.  DHCP based PAA discovery is also available:

draft-ietf-dhc-paa-option-02.txt


I suspect adminsitratively scoped multicast discovery wouldn't be 
acceptable for much the similar reasons as Service Location Protocol 
(SLP) wouldn't be -- it requires multicast deployment.


We made an analysis of end-point discovery mechanisms for v6 tunnels a 
while ago.  It might be worth a read:


http://draft-palet-v6ops-tun-auto-disc.potaroo.net


--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Framework document scope (RE: The Emperor Has No Clothes: Is PANA actually useful?)

[Alper Yegin]

> 
> I have to disagree.
> Firstly, if many of us reading the document can not figure out what
> problem it is solving, then the framework is not doing its job.

Framework document discusses deployments. Problem statement and requirements
is what you are looking for (RFC 4058).

> Secondly, if there are existing, viable, deployed solutions to the
> problem that the WG is attempting to solve then the WG needs to
> explain somewhere (the framework document would seem the obvious
> place) why there is a need for a new solution.

Again, this is in the scope of the problem statement and requirements. 


Alper


> 
> I am not claiming that the PANA protocol can't work.  As was said
> many years ago "with sufficient thrust, pigs will fly."  But that
> does not make flying pigs a good thing.
> 
> Yours,
> Joel M. Halpern
> 
> At 11:34 AM 5/26/2006, Dave Crocker wrote:
> 
> 
> >Joel M. Halpern wrote:
> >>EAP over IP (or UDP, or link) is about authenticating the user.  If
> >>a media independent technique better than just using a browser is
> >>needed, then solve that problem.  Personally, I would find the work
> >>far more persuasive if it did not also try to solve the problem of
> >>creating an IPSec association to the access device, nor of the
> >>authorization selection problem.
> >>And spell out in clear English what use case needs that problem solved.
> >>I can read between the lines and start to guess.  But the document
> >>is quite unclear.  The appendix about DSL is not helpful in that regard.
> >
> >
> >Although not a guaranteed way to distinguish among criticisms, it
> >can be helpful to categorize them as either "It will not work"
> >versus "I don't like it". The former indicates a basic technical
> >flaw, and the latter a matter of preference.
> >
> >If it is common for readers of a specification to fail to understand
> >what it is for then it has, perhaps, the most basic kind of
> >technical flaw.  How can a specification succeed if there is
> >confusion about its implementation or use?
> >
> >By contrast observations such as "there are better solutions" moves
> >into the fuzzier and more subjective realm of trying to predict
> >market preferences. The IETF is not very good at making these
> >predictions.  Absent any indication of actual harm that would ensue
> >from publishing a specification, fear that no one will adopt it or
> >that there will be multiple solutions seems an inappropriate basis
> >for denying publication.  (On the other hand, strong indication of
> >community interest in deplying a specification is supposed to be a
> >factor in deciding whether to charter the work in the first place;
> >however as Sam noted, we are rather late in the process.)
> >
> >In any event, I would claim that concerns over who will use PANA
> >fall into the "I don't like it" category, since it basically seeks
> >to make statements about market preferences, which is a small step
> >from personal preferences.
> >
> >Having looked over this thread and the -framework document a bit, I
> >find myself unclear which of the two lines of concern is being
> >pursued, although I impressed by the degree of confusion about PANA
> >after what appears to be considerable effort to understand it.  This
> >does not bode well for community understanding, and that of course
> >does not bode well for adoption and use.
> >
> >I would find it particularly helpful to have a concise statement
> >from someone who says that PANA will not work.  Cannot be
> >implemented (properly) by virtue of technical errors or
> >documentation too confusing to understand.  Or cannot be deployed
> >and used, by virtue of administrative complexity or, again,
> >documentation too confusing to understand.
> >
> >Absent this, I will ask why it is productive to note that the
> >emperor is pursuing an idiosynchratic sartorial style?
> >
> >d/
> >
> >___
> >Ietf mailing list
> >Ietf@ietf.org
> >https://www1.ietf.org/mailman/listinfo/ietf
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?)

[Lakshminath Dondeti]

At 03:20 PM 5/26/2006, Alper Yegin wrote:

> So far evaluations done by the broader
> community seem to be concluding that PANA is in fact complex and not
> easily deployable.

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.


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.




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.


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



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

Thanks.

Alper






___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?)

[Alper Yegin]

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




> -Original Message-
> From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 26, 2006 3:58 PM
> To: Alper Yegin
> Cc: ietf@ietf.org
> Subject: Re: Complexity (was RE: The Emperor Has No Clothes: Is PANA
> actually useful?)
> 
> At 03:20 PM 5/26/2006, Alper Yegin wrote:
> > > So far evaluations done by the broader
> > > community seem to be concluding that PANA is in fact complex and not
> > > easily deployable.
> >
> >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.
> 
> 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.
> 
> 
> >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.
> 
> 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
> 
> 
> >Please describe where you see unnecessary complexity, and suggest
> remedies.
> >
> >Thanks.
> >
> >Alper
> >
> >
> >




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?)

[Lakshminath Dondeti]

At 04:03 PM 5/26/2006, Alper Yegin wrote:

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.


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




Alper




> -Original Message-
> From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 26, 2006 3:58 PM
> To: Alper Yegin
> Cc: ietf@ietf.org
> Subject: Re: Complexity (was RE: The Emperor Has No Clothes: Is PANA
> actually useful?)
>
> At 03:20 PM 5/26/2006, Alper Yegin wrote:
> > > So far evaluations done by the broader
> > > community seem to be concluding that PANA is in fact complex and not
> > > easily deployable.
> >
> >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.
>
> 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.
>
>
> >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.
>
> 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
>
>
> >Please describe where you see unnecessary complexity, and suggest
> remedies.
> >
> >Thanks.
> >
> >Alper
> >
> >
> >



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?)

[Dave Crocker]

Alper Yegin wrote:
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.



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/

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?)

[Alper Yegin]

> >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.
> 
> I am not, really.  I am saying that the question has been answered by
> 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?
 
> "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"

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.

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

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.


> 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):
> 

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

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

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.

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

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





> 
> I am really not going to spend any more *substantial* time on this thread.
> 
> regards,
> Lakshminath
> 
> 
> 
> >Alper
> >
> >
> >
> >
> > > -Original Message-
> > > From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, May 26, 2006 3:58 PM
> > > To: Alper Yegin
> > > Cc: ietf@ietf.org
> > > Subject: Re: Complexity (was RE: The Emperor Has No Clothes: Is PANA
> > > actually useful?)
> > >
> > > At 03:20 PM 5/26/2006, Alper Yegin wrote:
> > > > > So far evaluations done by the broader
> > > > > community seem to be concluding that PANA is in fact complex and
> not
> > > > >

RE: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?)

[Lakshminath Dondeti]

 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.

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.

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

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





>
> I am really not going to spend any more *substantial* time on this thread.
>
> regards,
> Lakshminath
>
>
>
> >Alper
> >
> >
> >
> >
> > > -Original Message-
> > > From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, May 26, 2006 3:58 PM
> > > To: Alper Yegin
> > > Cc: ietf@ietf.org
> > > Subject: Re: Complexity (was RE: The Emperor Has No Clothes: Is PANA
> > > actually useful?)
> > >
> > > At 03:20 PM 5/26/2006, Alper Yegin wrote:
> > > > > So far evaluations done by the broader
> > > > > community seem to be concluding that PANA is in fact complex and
> not
> > > > > easily deployable.
> > > >
> > > >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.
> > >
> > > 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.
> > >
> > >
> > > >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.
> > >
> > > 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
> > >
> > >
> > > >Please describe where you see unnecessary complexity, and suggest
> > > remedies.
> > > >
> > > >Thanks.
> > > >
> > > >Alper
> > > >
> > > >
> > > >



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?)

[Jari Arkko]

Alper Yegin wrote:

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


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Complexity (was RE: The Emperor Has No Clothes: Is PANA actually useful?)

[Alper Yegin]

> 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.
> >
> >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.
> >
> > > 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.
> >
> >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
> >
> >
> >
> >
> >
> > >
> > > I am really not going to spend any more *substantial* time on this
> thread.
> > >
> > > regards,
> > > Lakshminath
> > >
> > >
> > >
> > > >Alper
> > > >
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED]
> > > > > Sent: Friday, May 26, 2006 3:58 PM
> > > > > To: Alper Yegin
> > > > > Cc: ietf@ietf.org
> > > > > Subject: Re: Complexity (was RE: The Emperor Has No Clothes: Is
> PANA
> > > > > actually useful?)
> > > > >
> > > > > At 03:20 PM 5/26/2006, Alper Yegin wrote:
> > > > > > > So far evaluations done by the broader
> > > > > > > community seem to be concluding that PANA is in fact complex
> and
> > > not
> > > > > > > easily deployable.
> > > > > >
> > > > > >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.
> > > > >
> > > > > 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.
> > > > >
> > > > >
> > > > > >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.
> > > > >
> > > > > 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
> > > > >
> > > > >
> > > > > >Please describe where you see unnecessary complexity, and suggest
> > > > > remedies.
> > > > > >
> > > > > >Thanks.
> > > > > >
> > > > > >Alper
> > > > > >
> > > > > >
> > > > > >




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

PANA vs. RADIUS/Diameter (RE: The Emperor Has No Clothes: Is PANA actually useful?)

[Alper Yegin]

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

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









> 
> 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!
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

IETF-SDO liaison (was Re: The Emperor Has No Clothes: Is PANA actually useful?)

[Vijay Devarapalli]

Avi Lior wrote:


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.


perhaps the IETF should have been consulted through the
3GPP2-IETF liaison?

actually I have seen some not-so-correct claims being
made about IETF protocols in other SDOs too (for e.g.
NETLMM in 3GPP). the SDOs should be making more use of
the liaisons instead of believing individual claims.

Vijay

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: IETF-SDO liaison (was Re: The Emperor Has No Clothes: Is PANA actually useful?)

[Avi Lior]

I think it is our collective responsiblity not to make false claims when
moving our agenda forward.  This is true with any group. 

Liaison should not be used for fact checking.  This will create
extra-ordinary work for them. They have better things to do.


> -Original Message-
> From: Vijay Devarapalli [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, May 30, 2006 2:53 PM
> To: Avi Lior
> Cc: ietf@ietf.org
> Subject: IETF-SDO liaison (was Re: The Emperor Has No 
> Clothes: Is PANA actually useful?)
> 
> Avi Lior wrote:
> 
> > 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.
> 
> perhaps the IETF should have been consulted through the 
> 3GPP2-IETF liaison?
> 
> actually I have seen some not-so-correct claims being made 
> about IETF protocols in other SDOs too (for e.g.
> NETLMM in 3GPP). the SDOs should be making more use of the 
> liaisons instead of believing individual claims.
> 
> Vijay
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF-SDO liaison (was Re: The Emperor Has No Clothes: Is PANA actually useful?)

[Thomas Narten]

> I think it is our collective responsiblity not to make false claims
> when moving our agenda forward.  This is true with any group.

Very much in agreement.

> Liaison should not be used for fact checking.

Speaking as a liaison, this sort of fact checking (what is the real
status of WG X or Document Y) is most certainly one of the things I
think is appropriate for a liaison to do.

And I would hope that my answer never differs from the one others are
making...

> This will create extra-ordinary work for them.

On the other hand, not consulting them, and having misinformation
propagated can also end up creating (much) more work for the
liaison. Indeed, one of the important reasons for having liaisons is
to facilitate information flow and prevent misinformation and
miscommunication.

Thomas

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

EAP/IKEv2 as an alternative to PANA (RE: The Emperor Has No Clothes: Is PANA actually useful?)

[Alper Yegin]

> >If the latter, the most natural solution to use is IKEv2 with EAP, since
> >even with PANA, you still need to run IKE/IKEv2 and IPsec - so, I don't
> >see what benefit PANA provides here.
> >
> >
> My comment above relates to the overall interest in an IP layer solution
> without considering what protocol is used.
> 
> I also wrote in my e-mail something about the different alternative
> solutions. It is true that IKEv2 with EAP is potentially a good
> fit for this task. IKEv2 is my favorite EAP encapsulation
> protocol :-) However, its not clear that it currently has all
> the parts (though I could have missed some extension somewhere).
> For instance, some mechanism appears to be needed to discover
> that you are in a network that requires this type of operation,
> and to find the address of the control device that you need
> to talk to. 

More fundamentally, when there are multiple gateways (for any
redundancy/failover/etc reason), pure IKEv2 solution requires multiple EAP
runs to get authorized for accessing "one" network. This does not work well
with the AAA backend deployments (which defaults to one authentication per
network access).

And it did not make any sense to augment IKEv2 (let alone not being able to
use IKEv1) to meet the PANA requirements, and then force everyone to use it
even though they are not interested in IPsec SAs. 

This was discussed in the PANA WG long time ago. But for people who are not
following the work and trying a last minute "how about this now?" this might
appear like an original idea.

Alper




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf