From owner-freebsd-security Fri Oct 22 22:35:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail0.mco.bellsouth.net (mail0.mco.bellsouth.net [205.152.48.12]) by hub.freebsd.org (Postfix) with ESMTP id A1E7514CFD for ; Fri, 22 Oct 1999 22:35:48 -0700 (PDT) (envelope-from bertke@bellsouth.net) Received: from bellsouth.net (adsl-78-196-151.sdf.bellsouth.net [216.78.196.151]) by mail0.mco.bellsouth.net (3.3.4alt/0.75.2) with ESMTP id BAA04292 for ; Sat, 23 Oct 1999 01:35:54 -0400 (EDT) Message-ID: <38114983.15EEE676@bellsouth.net> Date: Sat, 23 Oct 1999 05:37:08 +0000 From: Bert Kellerman X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.0.36 i386) X-Accept-Language: en MIME-Version: 1.0 To: security@FreeBSD.ORG Subject: Re: GRE/IP 47/PPTP References: <199910221748.KAA67824@bubba.whistle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Archie Cobbs wrote: > Martin Machacek writes: > > Well, GRE tunnelling is something completely different from suporting GRE in > > NAT. I can imagine doing one-to-one NAT and passing GRE, but doing many to one > > NAT and supporting multiple GRE streams is IMHO impossible. There is no > > parameter in the GRE encapsulation that would allow you to identify the real > > internal recipient if you NAT multiple internal addresses to one external > > address. > > True in general.. however, if all you're using GRE for is PPTP, then > you can multiplex on the call identifier in the PPTP/GRE header. > > -Archie > > Are you referring to the optional 32 bit key field in the GRE header? Won't the > packet on the way back in have a different key field, as this is used for > authenticating the sender, and change? The natd implementation would then need a > way to calculate the expected return key field to differentiate between > connections. However, since there is a 32 bit sequence number in the GRE > header like TCP, I wonder if it would be possible for the router to recreate the > internal sequence numbers and assign each internal client a limited pool out of > the 32 bit outside sequence block. Could this be possible? I mean how many times > has a single TCP session used all 4 million sequence numbers? RFC 1701 states > that this sequence number field is also optional so this might not work for all > vendors. Bert To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message