From owner-freebsd-security  Sat Mar 24 11:24: 8 2001
Delivered-To: freebsd-security@freebsd.org
Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110])
	by hub.freebsd.org (Postfix) with ESMTP id A5D0537B71E
	for <freebsd-security@freebsd.org>; Sat, 24 Mar 2001 11:24:04 -0800 (PST)
	(envelope-from mvh@ix.netcom.com)
Received: from netcom1.netcom.com (lai-ca3b-185.ix.netcom.com [209.110.241.185])
	by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id OAA00638;
	Sat, 24 Mar 2001 14:24:00 -0500 (EST)
Received: by netcom1.netcom.com (Postfix, from userid 1000)
	id 9D2D5114069; Sat, 24 Mar 2001 11:23:33 -0800 (PST)
From: Mike Harding <mvh@ix.netcom.com>
To: itojun@iijlab.net
Cc: freebsd-security@freebsd.org
In-reply-to: <10518.985201829@coconut.itojun.org>
Subject: Re: IPSEC/VPN/NAT and filtering
References:  <10518.985201829@coconut.itojun.org>
Message-Id: <20010324192333.9D2D5114069@netcom1.netcom.com>
Date: Sat, 24 Mar 2001 11:23:33 -0800 (PST)
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


Okay, I think I know enough now to procede in making a doc on
interacting with a Cisco VPN, with a very minor kernel change.  Can
anybody suggest who I should contact to determine if this makes sense,
and how I can coordinate with the FreeBSD team?

Also, Itojun, can you provide reference to 'scoped addresses' and
'strong host model node'?

Thanks,

Mike Harding

   Cc: freebsd-security@freebsd.org
   X-Template-Reply-To: itojun@itojun.org
   X-Template-Return-Receipt-To: itojun@itojun.org
   X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
   From: itojun@iijlab.net
   Date: Thu, 22 Mar 2001 04:10:29 +0900
   Sender: itojun@itojun.org
   X-SpamBouncer: 1.3 (1/18/00)
   X-SBClass: OK


   >My modest proposal would be to have a sysctl variable to indicate an
   >alternate interface to reinject the decrypted packets (like a local
   >loopback, the default or maybe a new one, lo1).  Then you know that
   >anything coming in that interface was inserted by the KAME stack and
   >you can apply filtering to it.  This would allow firewall and IPSEC
   >gateway functionality to be put into the same box.

	   strong no to changing m->m_pkthdr.rcvif on IPsec tunnel operations.
	   that behavior will kill scoped addresses, as well as recently-
	   discussed-to-death strong host model node.

	   see latest NetBSD source code tree, and the following URL, on how
	   we handled it (now ipfilter looks at wire format packet only).  i have
	   no environment/time to do the same on freebsd, but i can
	   say that the foundations are there in kame and netbsd tree.
	   (you can check if the packet went throught ip sec on inbound,
	   by using ipsec_gethist())
	   http://www.netbsd.org/Documentation/network/ipsec/#ipf-interaction

   itojun


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message