Re: [Pppext] Future of the PPP WG

Vernon Schryver <vjs@rhyolite.com> Sun, 11 September 2011 14:21 UTC

Return-Path: <vjs@rhyolite.com>
X-Original-To: pppext@ietfa.amsl.com
Delivered-To: pppext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4981721F849B for <pppext@ietfa.amsl.com>; Sun, 11 Sep 2011 07:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C20uEbMfad1 for <pppext@ietfa.amsl.com>; Sun, 11 Sep 2011 07:21:17 -0700 (PDT)
Received: from calcite.rhyolite.com (calcite.rhyolite.com [IPv6:2001:4978:230::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7054E21F846C for <pppext@ietf.org>; Sun, 11 Sep 2011 07:21:17 -0700 (PDT)
Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.14.4/8.14.4) with ESMTP id p8BEMvi5006794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <pppext@ietf.org> env-from <vjs@rhyolite.com>; Sun, 11 Sep 2011 14:22:58 GMT
Received: (from vjs@localhost) by calcite.rhyolite.com (8.14.4/8.14.4/Submit) id p8BEMtnS006793 for pppext@ietf.org; Sun, 11 Sep 2011 14:22:55 GMT
Date: Sun, 11 Sep 2011 14:22:55 GMT
From: Vernon Schryver <vjs@rhyolite.com>
Message-Id: <201109111422.p8BEMtnS006793@calcite.rhyolite.com>
To: pppext@ietf.org
In-Reply-To: <4E6C5F8C.6020605@gmail.com>
X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist
Subject: Re: [Pppext] Future of the PPP WG
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PPP Extensions <pppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pppext>, <mailto:pppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pppext>
List-Post: <mailto:pppext@ietf.org>
List-Help: <mailto:pppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Sep 2011 14:21:18 -0000

> From: Glen Zorn <glenzorn@gmail.com>

> > http://www.freesound.org/people/Jlew/sounds/16475/
>
> Well, this is all good fun, in a US/Euro-centric kind of way, but it
> would be good to remember that in a very large part of the world our
> "theme song" is a still a vital part of the Internet & is likely to
> remain so for a considerable period of time.  This email will make the
> first hop of its journey over (the much maligned) PPPoE, for example;
> not everybody lives in advanced countries such as S. Korea (the
> connectivity of which should make both the French and Americans hang
> their heads in shame).  In short, PPP is far from obsolete.

I don't think the thrust of that claim is entirely accurate.  Do people
outside advanced countries use dialup modems or wireless?  Have you
noticed the lack of modems and serial ports on modern portable computers?
That you can still buy a USB modem doesn't make PPP less obsolete than
floppy disks.  Last month I bought a USB modem so that I can dial with
my new portable, but that is mostly sign of my failure to move with
the times.  The salesman wasn't clear about what I wanted, and I didn't
find a lot of choices.  Somewhere I also have a USB floppy drive.

How would reissuing PPP RFCs with new security boilerplate help
anyone except the authors of the new RFCs?  What would people working
on PPP code do differently if the PPP RFCs had modern security
sections?  How many people are working on implementations of PPPoE
or any other flavor of PPP code?

If moving the never deployed PPP RFCs to Historic and reissuing the
rest with new security sections were all that would happen, it would
be only a dubious effort.  But there would be irresistible pressures
to to fix CHAP, MP, and even IPCP.  The replacements, delivered after
years of wrangling (and no implementations), would be as ill considered
as PAP, PPPoE, and the recently proposed IS-IS security fix.  If against
all likelihood they were eventually deployed, they'd be discovered to
be as insecure as many of the wireless security schemes and cause
interoperabilty problems as the PPPoE MTU still does.

The primary defense against those "improvements" would the fact
that no one (especially not the new RFC authors) would implement
them and fewer would deploy them.

Once upon a time, the IETF produced protocols to fill clear and
present user needs and demands.  Ostensibly fixing PPP with new
security words is the sort of idle hands standards committee
exercise that destroyed the ISO OSI protocol suite.


Vernon Schryver    vjs@rhyolite.com