From owner-freebsd-net@FreeBSD.ORG Thu Mar 9 04:02:37 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A7FB16A420 for ; Thu, 9 Mar 2006 04:02:37 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B8DF43D48 for ; Thu, 9 Mar 2006 04:02:37 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.199] ([10.0.0.199]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id k2942Zo7064994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Mar 2006 20:02:36 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <440FA8DC.3010006@errno.com> Date: Wed, 08 Mar 2006 20:02:36 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: VANHULLEBUS Yvan References: <20060307180222.GA1308@zen.inc> In-Reply-To: <20060307180222.GA1308@zen.inc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FAST_IPSEC and tunnelled packets processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2006 04:02:37 -0000 VANHULLEBUS Yvan wrote: > Hi all. > > I'm playing with FAST_IPSEC, and noticed what looks strange for me: > > I have an ESP/Tunnel configuration, and when I wanted to track packet > processing in the kernel, I noticed it goes 3 time in ip_input(): > > - ESP packet passes through ip_input(), and is sent to ipsec code. > > - esp_input_cb() removes the ESP header and trailer, and sends it back > to ipsec_common_input_cb(). > > - ipsec_common_input_cb() sends it back to ip_input(), without ESP header, > but still with an IPIP header (IP addresses are tunnel endpoints). > > - ip_input() will send it to "I don't know exactly where" (but I guess > it will go to ip_forward()), where the IPIP header will be removed > and.... yes, packet will be sent again to ip_input(), where it will > really be the inner packet..... > > Is this a bug, a "missing feature", or something done this way for > "some good reason I don't see" ? > > KAME's IPSEC stack removes both ESP header and IPIP header at the same > time (in esp4_input()/ipsec4_tunnel_validate()), the packet is only > seen twice by ip_input(). If I recall the IPIP handling is different from KAME because there is support for IPIP encapsulation independent of the IPsec protocols while KAME only handles IPIP as part of the ESP tunnel configuration. As to overhead, in practice, at least back in 4.x where this work was originally done, the netisr dispatch was effectively shortcircuited because the dispatch was done from the netisr thread so the net cost was a enqueue+dequeue of the packet. I'm not sure about extraneous trips through ip_input or not stripping headers; this stuff used to work right but I've not looked at the code in years. Sam