All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christophe Gouault <christophe.gouault@6wind.com>
To: Steffen Klassert <steffen.klassert@secunet.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	netdev@vger.kernel.org, Saurabh Mohan <saurabh.mohan@vyatta.com>,
	Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [PATCH net v3] vti: fix spd lookup: match plaintext pkt, not ipsec pkt
Date: Fri, 22 Nov 2013 15:33:22 +0100	[thread overview]
Message-ID: <528F6B32.5050103@6wind.com> (raw)
In-Reply-To: <20131121121246.GD31491@secunet.com>

On 11/21/2013 01:12 PM, Steffen Klassert wrote:
 > On Wed, Nov 06, 2013 at 09:05:53AM +0100, Christophe Gouault wrote:
 >>
 >> @@ -133,7 +134,13 @@ static int vti_rcv(struct sk_buff *skb)
 >>            * only match policies with this mark.
 >>            */
 >>           skb->mark = be32_to_cpu(tunnel->parms.o_key);
 >> +        /* The packet is decrypted, but not yet decapsulated.
 >> +         * Temporarily make network_header point to the inner header
 >> +         * for policy check.
 >> +         */
 >> +        skb_reset_network_header(skb);
 >>           ret = xfrm4_policy_check(NULL, XFRM_POLICY_IN, skb);
 >
 > If we do it like this, we would do an input policy check even for
 > packets that should be forwarded. I think that's a bit odd.

Admittedly, a forward policy check would be more appropriate for
forwarded traffic.

 > If we really change to match plaintext traffic, we should do
 > it like Fan Du proposed. Remove the policy check here and
 > let the further layers do the policy enforcement. All we
 > have to do is to set the skb mark, then the lookup should
 > match the vti policy.

This solution sounds seductive, however, we must be careful because we
change the skb input device (from the physical interface to the vti
interface). So we are supposed to call skb_scrub_packet as is normally
done when decapsulating a packet from a tunnel. This will reset the skb
secpath and mark, and hence will compromise the deferred inbound policy
check.

 > It is already clear that this packet was IPsec transformed
 > when it enters vti_rcv, so deferring the policy check should
 > be ok.

I had in mind to later support cross netns in vti interfaces like for
ipip tunnels (different netns for the decapsulated and encapsulated
packets). With the deferred inbound policy check, the SA and SP will not
be in the same netns, this will cause problems for the inbound policy check.

Best Regards,
Christophe

  parent reply	other threads:[~2013-11-22 14:33 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-05 10:16 [PATCH net] vti: fix spd lookup: match plaintext pkt, not ipsec pkt Christophe Gouault
2013-11-05 13:05 ` Sergei Shtylyov
2013-11-05 14:31   ` Christophe Gouault
2013-11-05 15:58 ` [PATCH net v2] " Christophe Gouault
2013-11-05 17:01   ` Eric Dumazet
2013-11-05 17:24     ` Christophe Gouault
2013-11-06  8:05 ` [PATCH net v3] " Christophe Gouault
2013-11-07 11:25   ` Steffen Klassert
2013-11-07 12:55     ` Christophe Gouault
2013-11-08 11:01       ` Steffen Klassert
2013-11-08 17:45         ` David Miller
2013-11-18 21:38       ` Saurabh Mohan
2013-11-19  0:01         ` Andrew Collins
2013-11-19  9:16         ` Fan Du
2013-11-21 12:17           ` Steffen Klassert
2013-11-21 18:39           ` Saurabh Mohan
2013-11-24 10:21             ` Fan Du
2013-11-21 10:07         ` Christophe Gouault
2013-11-21 11:45           ` Steffen Klassert
2013-11-07 23:17     ` David Miller
2013-11-08 12:55       ` Christophe Gouault
2013-11-21 12:12   ` Steffen Klassert
2013-11-21 18:35     ` Saurabh Mohan
2013-11-22 14:33     ` Christophe Gouault [this message]
2013-12-03  7:55       ` Steffen Klassert
2013-12-03  9:01         ` Christophe Gouault
2013-12-03  9:39           ` Steffen Klassert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=528F6B32.5050103@6wind.com \
    --to=christophe.gouault@6wind.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=netdev@vger.kernel.org \
    --cc=saurabh.mohan@vyatta.com \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=steffen.klassert@secunet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.