FAST_IPSEC and tunnelled packets processing
sam at errno.com
Thu Mar 9 04:02:37 UTC 2006
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.
More information about the freebsd-net