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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Bernard,

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@xxxxxxxxxxxxx]
> Sent: Thursday, May 25, 2006 4:46 PM
> To: ietf@xxxxxxxx
> 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 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@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ietf



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]