Date: Wed, 24 Mar 1999 11:02:55 -0800 (PST) From: Archie Cobbs <archie@whistle.com> To: jdp@polstra.com (John Polstra) Cc: hackers@FreeBSD.ORG Subject: Re: Will IPFW pass GRE packets? Message-ID: <199903241902.LAA92365@bubba.whistle.com> In-Reply-To: <XFMail.990324105212.jdp@polstra.com> from John Polstra at "Mar 24, 99 10:52:12 am"
next in thread | previous in thread | raw e-mail | index | archive | help
John Polstra writes: > > John Polstra writes: > >> It gets even better. They explicitly specify that checksums must be > >> disabled in the GRE encapsulation. And the PPP packets contained > >> therein are stripped of all link-level headers. Thus, as far as I can > >> tell, there is zero, zilch, nada error detection of any kind on the > >> encapsulated PPP packets (i.e., your valuable data). Tcpdump confirms > >> this. > > > > I think this is reasonable for what they were trying to do (PPTP). > > In general, the PPP link layer (which is what GRE is functioning as > > here) does not guarantee uncorrupted frame transmission either. So > > nothing is being broken by this. > > Are you sure? PPP isn't exactly my specialty, but I've looked at > RFC1662, "PPP in HDLC-like Framing," which I assume applies to > standard dial-up PPP. It shows a Frame Check Sequence on every frame > (see section 3.1). Right.. that RFC states how to do PPP when the medium is HDLC-like. This is only a subset of the possible media. Others include asynchronous serial, ATM FUNI, Ethernet, etc. All of the other media examples that I know of *do* include a checksum, but this is mostly because they do already. For example, it's not possible with most Ethernet hardware *not* to include a checksum. So PPP is just going along. Async serial is an example where they explictly added a checksum (which was a good idea IMHO). > Without some sort of checksum, real bad stuff could happen. For > example, corrupted LCP packets could be received without even knowing > it. I have a hard time believing that the designers of PPP intended > for that to be so likely -- serial links have very high error rates. I think you're right.. they probably (implicitly) assumed a certain low error rate. But RFC 1661 is silent on this issue, as far as I can tell. > > Also, since PPTP GRE packets contain complete IP packets within > > them, the checksum could be considered redundant. > > But the LCP packets, for example, are not IP. They don't have any > checksum of their own. Besides, the redundancy argument was exactly > the rationale for having no checksum in SLIP. It was later found to > be a bad idea. That's why PPP added the FCS. Basically I agree with you, but it's agreement "in practice" rather than "in theory". In other words, Microsoft (and Ascend, 3Com, Copper Mountain, and ECI) may have done something that was just plain stupid, but they didn't do anything that was a blatant violation of any spec. Moreover, while not perfect, IP error rates are still much lower than 1990-era modem error rates were, etc. So they were probably just lucky enough to get by on this one... -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903241902.LAA92365>