From owner-freebsd-questions Sun Dec 13 15:47:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA27032 for freebsd-questions-outgoing; Sun, 13 Dec 1998 15:47:45 -0800 (PST) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from lily.ezo.net (lily.ezo.net [206.102.130.13]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA27020 for ; Sun, 13 Dec 1998 15:47:37 -0800 (PST) (envelope-from jflowers@ezo.net) Received: from crocus (c3-1d196.neo.rr.com [24.93.233.196]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id SAA16175; Sun, 13 Dec 1998 18:47:15 -0500 (EST) Message-ID: <001401be26fb$5f91f3c0$848266ce@crocus.ezo.net> From: "Jim Flowers" To: "Hal Snyder" Cc: , Subject: Re: SKIP behind NAT with single-homed skiphost Date: Sun, 13 Dec 1998 19:47:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----Original Message----- From: Hal Snyder To: Jim Flowers Date: Sunday, December 13, 1998 5:15 PM Subject: Re: SKIP behind NAT with single-homed skiphost >I don't have a solution to Jim Flowers' question, just more questions >and comments. > >1. Routing, where the same network is source and destination as in S1 > and S2 below, makes me uncomfortable. Doesn't that risk an > inordinately high collision rate? It certainly at least halves > effective bandwidth of the network. Or does this not matter because > the WAN link is slow compared to the data rate on network 2? Nope, works great and you've got the right answer. Even 10Mbps/2 is large compared to 1.5 Mbps (T-1). Does seem to be some packet processing overhead but I haven't measured it because most of my VPN's are sub-T1. > >2. Why is the *tunnel* slow? If this is an admission that SKIP > significantly reduces your available bandwidth (other than by #1 on > this particular setup) are there estimates on this? [FWIW, I've > seen AltaVista Tunnel VPN software apparently reduce available > bandwidth by 75% due to CPU load on a) a 100MHz pentium system > running Windows 95 AVT client into a 33Kbps line and b) a 200MHz > system running NT Server with AVT server into a T1.] I refer to the tunnel as slow only relatively, because at the parent end it is restricted by a a T-1 and my local connection is a 10Mbps cable modem. > >3. If Jim's idea of extending NAT to cover protocol 57 is sound, then > it should give FreeBSD systems the ability to NAT PPTP if we do the > same for GRE (protocol 47). I'm thinking about this. Before I posted, I hacked natd to recognize SKIP as IP protocol 57 but quit when a called program didn't appreciate a protocol that wasn't TCP or UDP. Probably not a significant job for someone that knows what they are doing. > >4. I read recently that IPSec is available for FreeBSD. Is there a > long term future for SKIP, or will it be superseded sometime soon? It's only my opinion, but IPSec implemented in a general and interoperable \ way over IPv6 or IPv4 for encrypted tunneling is in trouble right now due to the recent Wassenaur signings. I elected to use SKIP a year ago as the only real symmetrical key system in widespread operation anticipating about a 2 year life. Now I think more like 5 years. > >5. IIRC, the underlying crypto for FreeBSD SKIP traffic is RC4-40. How > secure is this? I don't use the RC4-40, I use MD5 DES-CBC and DES-EDE-K3 as appropriate. With 2048 kb keys and 30 sec / 512kB changes, I think it's pretty secure. > >6. The ASCII art was munged. I've guessed at its reconstruction. Always a problem with W95 clients only capable of variable pitch font renditions. Unfortunately monospaced fonts look terrible on W95 too. I think you got the concepts correct. The real point is the single interface at one end and the natd translation at the other. Jim > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message