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

Re: Informational RFC to be: draft-gpaterno-wireless-pppoe-11.txt

See below.

On Tuesday, September 9, 2003, at 02:16 PM, Bob Braden wrote:
*>
*> The author has requested that this document be published as an
*> informational document. I asked some knowledgable folk what they
*> thought of this document; their comments are below.
*>
*> Question for the author: what is your motivation for publishing this
*> document? Do you have plans for doing any follow-up work in this
*> space?
*>
*> Thomas
*>
*> Bernard Aboba <aboba@internaut.com> writes:
*>
*> > Aside from the fact that the document is somewhat out of date (WFA
*> > is currently in the process of certifying WPA-compliant access points that
*> > address the security issues described in the document), there is a
*> > fundamental problem with the logic of the argument.
*>
*> > First the author points out the security flaws of WEP. Then he goes ahead
*> > and advocates addoption of PPPOE along with PPP encryption algorithms
*> > such as MPPE which (like WEP) lack integrity protection. In addition, he
*> > does not propose a standard key exchange mechanism, after criticizing
*> > IEEE 802.1X for the same problem.
*>
*> > I would have no problem with this document if it actually listed
*> > the security flaws of WEP and then specified a PPPOE profile (including
*> > use of appropriate ciphersuites and key exchange algorithms) to address those
*> > issues.

Thomas,

I have much less expertise in this area than do your commentors, but
Bernard's comment on the confusion in the argument agrees with my
observation.

*>
*> > But as it is, this document reads mostly like a marketing blurb seeking
*> > validation by publication as an RFC. If there is really interest in this
*> > solution as the author claims, the right way to proceed is to flesh it out
*> > to the point where the approach is credible. This document doesn't do
*> > that.
*>

Yes.

*>
*> Karl Fox <karlfox@columbus.rr.com> writes:
*>
*> > Bernard's technical points notwithstanding, it turns my stomach to see
*> > yet another latecomer to wireless security proposed. We already have
*> > the IEEE and multiple groups within the IETF trying to solve this
*> > problem (some of which are well suited to the problem, such as Mobile
*> > IP), and they are dealing with the real life, difficult issues that
*> > occur in mobile networks. Trying to make a mobile network connection
*> > look like a dial-up is a poor fit. I say shut it down.

Intuitively that seems plausible, but I cannot pin down precisely why
it is a poor fit.  Where is the conflict, really?

Every other proposed solution to wireless security deals with the simple issue
of security as well as the far more complicated issue of security while mobile.
Since PPP has neither mechanism nor aspiration for supporting mobility, it
seems like this document is starting at a huge disadvantage. Who would want
a secure mobile system that isn't mobile?

Karl

But certainly the author would need to face this issue squarely and deal
with it.

*>
*> James Carlson <james.d.carlson@sun.com> writes:
*>
*> > I vote "no" for publication as an RFC. To be frank, I can't tell what
*> > this document intends to be. It doesn't actually describe any
*> > particular new or changed protocol, nor any particularly interoperable
*> > solution to a known problem, nor does it analyze the security issues
*> > of its recommendations in sufficient detail.

The document is certainly not clear on what it "intends to be", and that
is probably a fatal flaw. OTOH...

...

*>
*> > Moreover, what value would this document bring? Clearly, if someone
*> > wanted to deploy PPPoE over 802.11, he could do so _today_. No new
*> > IETF would be necessary. The components to do this all exist today in
*> > many implementations.
*>

this paragraph seems in fact to contain a plausible reason for the
existence of such a document.  It seems reasonable to me to publish an
RFC documenting an approach to using existing technology in a slightly
new way to solve real problems.  Yes?  I believe this is what the
author tried to accomplish.

Assuming you accept this goal, the difficulty is how to help the author
to create such a document without ourselves (RFC Editor and IESG)
spending much more of our own resources on it. I guess I am prepared to
say it's not worth the effort at this point.

Bob Braden for the RFC Editor

  *>
  *> Thomas
  *>