On 19:57:10 Mar 16, Ermal Lu?i wrote:

The idea is this.

pf(4) is concerned only about layer 4 and below. It only looks
at headers. Never the payload.

The only argument for doing PPTP in kernel would be for avoiding the
performance overhead of a user-land proxy. In fact this is what prompted
me to do an in kernel implementation the first time.
Moreover it was much easier.

There is a *huge* performance hit in a user-land PPTP proxy since PPTP
is very different from ftp(1). PPTP is VPN technology and if every single
PPTP packet is to unnecessary travel all the way to user-land and back ,
then I am sure it will end up into something as bad as something like
SSLVPN. :)

If you watch carefully this design has no performance impact at all.

More explanation below.

On 2008/03/16 19:57, Ermal Lugi wrote:

PF already has a method of setting the port number for TCP and UDP.
GRE is a different IP protocol, without any particular support in PF.
call-id can be regarded pretty much like a port number here.

Girish, it looks like you take non-PPTP users of GRE into account
with the kernel changes (i.e. not to touch whatever's in the part of
the packet occupied by callid unless ptype == ETHERTYPE_PPP), have
you had chance to test that works ok?

This is *much* better than frickin.

That's a different (and higher overhead) architecture. This way the
simple bulk data transfers can be handled by some small and relatively
safe support in-kernel, and the inherently more dangerous PPTP protocol
handling is done by jailed unprivileged userland code.

Well i see the reason that OpenBSD developers have about not handling
application layer in kernel since they do no want special cases in
kernel in an application that should be general enough.

Though the way that you have written this patch it indeed inserts a
special case in kernel. That is GRE.
How about doing this with no special cases but with just a plugin
architecture for nat where let say if i write a rule like:

nat on $interface from any to any -> $extinterface with-proxy(pptp)

And just check after the nat rule has been found if it has a flag to
handle pptp or other protocols in the run.
And then just call the appropriate function for this.
It is a simple test insturction for users that do not want the
overhead and the users that accept it are served as requested.
IE.
pf_test() has

On 3/16/08, Esben Norby openbsd.org> wrote:

It prevents out-of-bound array accesses in dvmrpd's rde code if an
interface is specified in dvmrpd.conf with an interface index >=
MAXVIFS. This mostly prevents weird otherwise unexplained crashes
when using such interfaces. Maybe an attacker could use it to
compromise the rde and ultimately corrupt the mfc, but this seems
highly unlikely.

That would be better. In the mean-time, I still recommend my patch.

On Sunday 16 March 2008 07:13:52 Matthew Dempsky wrote:

There are multiple places in dvmrpd's source code where an interface
index is used to lookup into a fixed size array of MAXVIFS elements,
but I can't find anywhere that ensures ifindex is less than MAXVIFS.

It seems the simplest solution is to error when an interface is
specified in dvmrpd.conf with an interface index >= MAXVIFS. See
patch below.

Index: parse.y
===================================================================
RCS file: /cvs/src/usr.sbin/dvmrpd/parse.y,v
retrieving revision 1.13
diff -p -u -r1.13 parse.y
--- parse.y 12 Nov 2007 23:59:41 -0000 1.13
+++ parse.y 16 Mar 2008 06:05:44 -0000
@@ -843,6 +843,11 @@ conf_get_if(struct kif *kif)
{
struct iface *i;

On 09:07:15 Mar 15, Stefan Sperling wrote:

My pleasure.

The reason I did not think of it is simple. Discussions went over
personal mail with henning@. Later mrbride@, reyk@ and others joined.

Anyway I believe the code is a result of team effort. And I definitely
owe a lot of gratitude towards Camiel Dobbelaar whose excellent
ftp-proxy(8) made it a cinch for me to code pptp-proxy(8).

So there you go.

Please find the tgz here.

http://sirsasana.org/misc/pptp-patch.tgz

# sha1 pptp-patch.tgz
SHA1 (pptp-patch.tgz) = d6e18300c698c392a0f9c60e3c1cfae238c8e332

It contains the following files.

On Sat, Mar 15, 2008 at 06:54:58AM +0530, Girish Venkatachalam wrote:

[t]ftp-proxy

Why not send it to the list now then so Ermal and others can look at it,
too? I'd like to see it as well (I maintain the net/pptp port).

On Wed, 12 Mar 2008, Daniel Dickman wrote:

Applied - thanks (and your bind one too)

-d

On 16:13:10 Mar 14, Ermal Lu?i wrote:

It is not arguable at all.

I did my first implementation in kernel and the second in userland. I
agree the userland design is far more complex but that is the right way
to do things.

pf(4) has no business diddling with application level packets.

No problem. I did not mean that either.

Those were the first cut versions. My final patch has been substantially
reworked, the design completely changed and so on.

But you don't find that in the archives.