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

[Bob Braden <braden@ISI.EDU>]

  *> 
  *> 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?

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