From: Paul Mackerras <paulus@samba.org>
To: Tim Wilson <timwilson@mediaone.net>
Cc: linux-kernel@vger.kernel.org, torvalds@transmeta.com
Subject: Re: [PATCH] ppp_generic, kernel 2.4.3
Date: Sun, 22 Apr 2001 16:23:55 +1000 (EST) [thread overview]
Message-ID: <15074.30971.184067.341145@gargle.gargle.HOWL> (raw)
In-Reply-To: <3AE22CEC.8C000984@mediaone.net>
In-Reply-To: <3AE22CEC.8C000984@mediaone.net>
Tim Wilson writes:
> The bug can cause PPP to NOT install and use a compressor module for
> sending, even though the compressor is sucessfully negotiated by CCP.
> Since encryption is sometimes implemented as a compressor module (e.g.
> MPPE), this bug can cause PPP to send cleartext even though encryption
> appears to be sucessfully negotiated.
Hmmm... using CCP to negotiate encryption is a Bad Idea IMHO. I know
Microsoft does, but that isn't really a recommendation. :) Certainly
pppd and the Linux PPP kernel driver don't include support for some of
the things that the MPPE spec says you have to do, like taking down
the link if MPPE doesn't get negotiated successfully, and not sending
or receiving any data before MPPE is up.
All of which goes to say that MPPE support is not a "feature point" of
the Linux PPP implementation. So a potential insecurity in an MPPE
implementation is hardly a bug.
Anyway...
> The bug does not always show up--it depends on the order of CCP messages
> exchanged during establishment, and therefore is not deterministic.
The bug is only going to show up if CCP gets re-negotiated, i.e. if
CCP get negotiated and comes up and then one side starts sending
Configure-requests to renegotiate the compression method and
parameters.
> The specific problem is handling a sent or received CCP ConfReq. A sent
> ConfReq should reset my decompressor; a received ConfReq should reset my
> compressor. The original code had this logic exactly reversed.
Actually, after having another look at RFC 1962 I think that either
sending or receiving a ConfReq takes CCP out of Opened state and
should stop compression in *both* directions. So on balance I would
change it like you have for TermReq and TermAck, but make the same
change for ConfReq as well.
BTW, the spacing/indentation in the patch you sent was broken; the
patch seemed to have 1-space indentation whereas it should be 1-tab
indentation. Does your mailer convert tabs to single spaces maybe?
Paul.
next prev parent reply other threads:[~2001-04-22 7:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-22 0:59 Tim Wilson
2001-04-22 6:23 ` Paul Mackerras [this message]
2001-04-22 17:53 ` Tim Wilson
2001-04-23 0:28 ` Paul Mackerras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15074.30971.184067.341145@gargle.gargle.HOWL \
--to=paulus@samba.org \
--cc=linux-kernel@vger.kernel.org \
--cc=timwilson@mediaone.net \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®