Subject: Re: [net-next PATCH 01/02] net/ipv4: VTI support rx-path hook in xfrm4_mode_tunnel.

From: Steffen Klassert <[email-masked]>
Date: Fri, 15 Jun 2012 07:46:36 +0200

On Thu, Jun 14, 2012 at 07:44:11PM -0700, Saurabh Mohan wrote:
> > +
> >  static int xfrm4_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb)
> >  {
> > +	struct xfrm_tunnel *handler;
> >  	int err = -EINVAL;
> >  
> >  	if (XFRM_MODE_SKB_CB(skb)->protocol != IPPROTO_IPIP)
> > @@ -74,6 +142,10 @@ static int xfrm4_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb)
> >  	if (!pskb_may_pull(skb, sizeof(struct iphdr)))
> >  		goto out;
> >  
> > +	/* The handlers do not consume the skb. */
> > +	for_each_input_rcu(rcv_notify_handlers, handler)
> > +		handler->handler(skb);
> 
> I'm not sure if this is the right place to add your handler.
> My understanding of an IPsec tunnel device would be to
> receive the packet first and then do IPsec processing.
> Here it happens the other way arround.
> 
> @SM: The intention is to get the packet post decrypt and post-esp-decap. Just like a GRE tunnel the rx-counters account for the payload and NOT the GRE header.
> 

Well, I think a virtual interface should behave similar
to physical interfaces. And a physical interface has to
receive the packet before it can be processed.

I looked into the old klips IPsec implementation.
They had virtual IPsec interfaces and they did it like 
that, update the statistics and the input device first
and process the packet then.