{ipv4,xfrm}: Introduce xfrm_tunnel_notifier for xfrm tunnel mode callback
authorFan Du <fan.du@windriver.com>
Wed, 28 Aug 2013 07:09:40 +0000 (15:09 +0800)
committerSteffen Klassert <steffen.klassert@secunet.com>
Wed, 28 Aug 2013 07:22:17 +0000 (09:22 +0200)
commitaba8269588301f7778bea811d6f7ec74c2e37279
treecaa13792e548e860403cf513a6f6d80f0838602a
parent0806ae4cc8722b2d2822fe3fa3f516f2da6b9459
{ipv4,xfrm}: Introduce xfrm_tunnel_notifier for xfrm tunnel mode callback

Some thoughts on IPv4 VTI implementation:

The connection between VTI receiving part and xfrm tunnel mode input process
is hardly a "xfrm_tunnel", xfrm_tunnel is used in places where, e.g ipip/sit
and xfrm4_tunnel, acts like a true "tunnel" device.

In addition, IMHO, VTI doesn't need vti_err to do something meaningful, as all
VTI needs is just a notifier to be called whenever xfrm_input ingress a packet
to update statistics.

A IPsec protected packet is first handled by protocol handlers, e.g AH/ESP,
to check packet authentication or encryption rightness. PMTU update is taken
care of in this stage by protocol error handler.

Then the packet is rearranged properly depending on whether it's transport
mode or tunnel mode packed by mode "input" handler. The VTI handler code
takes effects in this stage in tunnel mode only. So it neither need propagate
PMTU, as it has already been done if necessary, nor the VTI handler is
qualified as a xfrm_tunnel.

So this patch introduces xfrm_tunnel_notifier and meanwhile wipe out vti_err
code.

Signed-off-by: Fan Du <fan.du@windriver.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: David S. Miller <davem@davemloft.net>
Reviewed-by: Saurabh Mohan <saurabh.mohan@vyatta.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
include/net/xfrm.h
net/ipv4/ip_vti.c
net/ipv4/xfrm4_mode_tunnel.c