Date: Wed, 08 Mar 2006 20:02:36 -0800 From: Sam Leffler <sam@errno.com> To: VANHULLEBUS Yvan <vanhu_bsd@zeninc.net> Cc: freebsd-net@freebsd.org Subject: Re: FAST_IPSEC and tunnelled packets processing Message-ID: <440FA8DC.3010006@errno.com> In-Reply-To: <20060307180222.GA1308@zen.inc> References: <20060307180222.GA1308@zen.inc>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?440FA8DC.3010006>