Date: Thu, 20 Apr 2000 09:50:04 +0300 From: Ruslan Ermilov <ru@FreeBSD.ORG> To: Charles Mott <cmott@scientech.com> Cc: Archie Cobbs <archie@whistle.com>, julian@elischer.org, brian@Awfulhak.org, ari@suutari.iki.fi, perhaps@yes.no, net@FreeBSD.ORG, Erik Salander <erik@whistle.com> Subject: Re: Improved PPTP support for libalias(3) Message-ID: <20000420095004.B28609@relay.ucb.crimea.ua> In-Reply-To: <Pine.LNX.4.10.10004192333040.12933-100000@if.scientech.com>; from Charles Mott on Thu, Apr 20, 2000 at 12:22:16AM -0600 References: <200004192132.OAA38818@bubba.whistle.com> <Pine.LNX.4.10.10004192333040.12933-100000@if.scientech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 20, 2000 at 12:22:16AM -0600, Charles Mott wrote:
> > > It seems like the PPTP server address and call ID would provide
> > > enough information to correctly rewrite packets (i.e. a given
> > > server will not have duplicate call ID's).
> >
> > In practice, that may work, but AFAIK the call ID is scoped
> > only to the control stream session, not to the entire server.
> >
> > So in theory at least you can have two separate TCP connections to
> > the same server utilizing the same Call ID for different connections.
>
> >From RFC 2673:
>
> Call ID A unique identifier, unique to a particular
> PAC-PNS pair assigned by the PNS to this
> session. It is used to multiplex and
> demultiplex data sent over the tunnel
> between the PNS and PAC involved in this
> session.
>
> My reading is that the Call ID is scoped over all
> connections to to a given endpoint. However, there
> are actually _two_ Call ID's for every connection --
> one for each endpoint.
>
> So it appears that the control channel has to be
> watched for Call ID's, and new associations ("links"
> in libalias) need to be created for GRE packets based
> on the control channel data.
>
> Moreover, two clients behind the NAT gateway might
> choose the same Call ID when connecting to the same
> PPTP server. In this case, the control channel would
> have to modified ("swizzled" in Archie's terminology)
> and the call ID for outgoing GRE packets changed for
> one of the PPTP connections in order to avoid
> collision.
>
> At any rate, I think I finally understand Archie's
> somewhat concise remarks. He seems to be correct.
>
Yes, I see it too now.
> Modifying the TCP stream can be modelled ater the
> ftp and irc code. The checksum for GRE appears to
> be slightly different than for TCP or UDP.
>
PPTP does not use GRE checksum. In section 4.1 of RFC 2673 we read:
: The format of the enhanced GRE header is as follows:
:
: 0 1 2 3
: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: |C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type |
: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: | Key (HW) Payload Length | Key (LW) Call ID |
: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: | Sequence Number (Optional) |
: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: | Acknowledgment Number (Optional) |
: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:
: C
: (Bit 0) Checksum Present. Set to zero (0).
Cheers,
--
Ruslan Ermilov Sysadmin and DBA of the
ru@ucb.crimea.ua United Commercial Bank,
ru@FreeBSD.org FreeBSD committer,
+380.652.247.647 Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000420095004.B28609>