On Thu, 12 Aug 2004, Alex Bihlmaier wrote:
> Fred Wright wrote:
> 
> > If you send me a packet trace I'll take a look.  You should be able to do
> > that on the Debian box with something like:
> > 
> > 	tcpdump -w pptp.cap -s 1536 -i <interface> ip proto 47
> 
> Okay. I captured some packets.
> http://www.kallisti.de/pptp.cap

Got it, as well as another from someone else.

> I started the pptp session, pinged an webserver and after 10-15 pings I 
> disconnected and stopped the capture.
> 
> Here is the logfile from the m0n0wall about the pptp-session handling:
> http://www.kallisti.de/m0n0.log
> (Due to Line Wrapping I uploaded it to my webserver)
> 
> As Peter mentioned, Debian defaults to not to use PFC (Protocol Field 
> Compression)

According to the negotiations, *both* parties requested *and accepted*
PFC.  Note the "PROTOCOMP" entry in the log.  That by itself doesn't show
what happened on the wire, but it's consistent with it.

I don't have an easy way to see the actual offending packets, since
they're encrypted, but the 0x2145 seems exactly like PFC confusion, given
that:

1) The upper byte of a PPP protocol type isn't permitted to be odd.

and

2) Interpreting the content as protocol type 0x21 (with the 0x45 as part
of the payload) yields a plausible ping packet.


As to whose fault this is, there's no simple answer, due to that fact that
MPPC and MPPE are poorly specified.  The problem is that there are *two*
PPP protocol types in compressed/encrypted packets, where the "normal" one
is set to 0x00FD, and the "real" protocol type is embedded in the
compressed/encrypted content in a compression/encryption-specific manner.  
Neither RFC2118 nor RFC3078 makes it clear whether PFC is allowed for the
embedded PT, although it consistently uses 4-digit numbers in the
examples.  Robustness would suggest not using it when sending, and
accepting it when receiving.  By that criterion, *both* FreeBSD *and* the
Debian implementation are at fault (though FreeBSD's behavior is more
excusable given the successful PFC negotiation).

It's not clear that "inner PFC" pays attention to the negotiated option
(since it's conceptually independent), but disabling PFC might be worth a
try, if possible.


BTW, there's a subtle security problem here.  Although the PPP data is
encrypted, the protocol reject packet includes the entire payload in
cleartext.  Any application that sends sensitive information in the first
packet would be vulnerable to eavesdropping via the error.  Or *any*
packet, if the PFC failure were intermittent.  Ideally, the rejected
content would be sent encrypted, but MPPE doesn't allow LCP packets to be
encrypted.  The next best thing would be to truncate the payload of
protocol reject packets when the original packet is encrypted, but the
possibility of VJC makes the maximum "safe" payload length so small as to
be practically useless.

					Fred Wright