From owner-freebsd-hackers Mon Apr 23 8:11: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id B177037B422; Mon, 23 Apr 2001 08:10:58 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.11.3/8.11.3) id f3NFAlC07105; Mon, 23 Apr 2001 10:10:47 -0500 (CDT) (envelope-from dan) Date: Mon, 23 Apr 2001 10:10:47 -0500 From: Dan Nelson To: Wes Peters Cc: "E.B. Dreger" , hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: TCP intercept? Message-ID: <20010423101046.A4880@dan.emsphone.com> References: <3AE3D89D.9ABCA7B6@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <3AE3D89D.9ABCA7B6@softweyr.com>; from "Wes Peters" on Mon Apr 23 01:24:13 GMT 2001 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Apr 23), Wes Peters said: > > I'm no kernel hacker, and trying to think of useful little projects > > to change that. ;-) > > > > AFAIK, FreeBSD lacks support for TCP intercept. Is anyone already > > working on this? Would it be of interest to anyone? My initial > > thoughts are that it should be implemented in the same neighborhood > > as stateful firewall code, as the two are rather closely related. > > If you mean IP forwarding, you can do that with ipnat (part of > ipfilter) or with natd. If you mean network interface monitoring, > see the man page for bpf. Otherwise, you'll have to explain what you > mean by "TCP intercept", it is not a terminology in common use. It's a Cisco term. From what I can tell, it essentially proxies all TCP sessions, but solely to shorten the 3-way handshake timeout and trap SYN floods before the host sees them. It's useless for protecting modern systems, but if you have a lot of legacy OSes in your network, TCP Intercept will protect them all without forcing you to upgrade them. http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/secur_c/scprt3/scdenial.htm I don't trust a border router to proxy every TCP session going through it, though. Since the router doesn't know the capabilities of the 2nd host at the time it proxies the connection from the 1st, you can't negotiate any enhanced TCP features like SACK or rfc1323 (window scaling or timestamping). -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message