All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christophe Gouault <christophe.gouault@6wind.com>
To: Saurabh Mohan <saurabh.mohan@brocade.com>,
	Steffen Klassert <steffen.klassert@secunet.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Andrew Collins <bsderandrew@gmail.com>,
	Fan Du <fan.du@windriver.com>
Subject: Re: [PATCH net v3] vti: fix spd lookup: match plaintext pkt, not ipsec pkt
Date: Thu, 21 Nov 2013 11:07:27 +0100	[thread overview]
Message-ID: <528DDB5F.8080400@6wind.com> (raw)
In-Reply-To: <1902752B0C92F943AB7EA9EE13E2DEEC1273BA977C@HQ1-EXCH02.corp.brocade.com>

Hi Saurabh,

Good to read your rationale.

On 11/18/2013 10:38 PM, Saurabh Mohan wrote:
>
>
>> -----Original Message----- From: Christophe Gouault
>> [mailto:christophe.gouault@6wind.com] Sent: Thursday, November 07,
>> 2013 4:56 AM To: Steffen Klassert Cc: David S. Miller; Herbert Xu;
>> netdev@vger.kernel.org; Saurabh Mohan; Sergei Shtylyov; Eric
>> Dumazet Subject: Re: [PATCH net v3] vti: fix spd lookup: match
>> plaintext pkt, not ipsec pkt
>>
>> Hello Steffen,
>>
>> I am also interested in knowing Saurabh's intentions regarding the
>> behavior of policies bound to vti interfaces.
>>
> The semantics is to match the policy "src 0.0.0.0/0 dst 0.0.0.0/0
> proto any" That is the only policy that VTI should use. The mark is
> needed to distinguish and limit the policy to a specific vti tunnel
> interface only. There is no other policy that may be applied to a vti
> interface. The fact that traffic is going over the tunnel interface
> implies that it must be encrypted/decrypted. Applying the above
> policy is a way to achieve that.

The proposed patch respects this model and accepts the same
configuration, but extends the possibilities: you can still set the
policy "src 0.0.0.0/0 dst 0.0.0.0/0 proto any" (which is the typical use
case), the mark is still used to distinguish and limit the policy to a
specific vti tunnel interface only, the traffic that is going over the
tunnel interface still implies that it must be encrypted/decrypted (in
tunnel mode).

But you can optionally apply differentiated policies within the same
tunnel, by setting SPs with narrower selectors: according to the
plaintext traffic that crosses the tunnel, you can request to use
different protocols (esp/ah), different SAs, maybe drop some traffic.
Only ipsec tunnel mode and drop policies should be bound to a VTI interface.

And the patch restores the SP semantics: the selector is used to match
the plaintext traffic, not the IPsec encrypted traffic.

Best Regards,
Christophe

>> However, please note that setting a policy with a wildcard
>> selector works in both cases (before or after this patch), so a
>> common test case can be defined.
>>
>> Actually the *previous* patch on vti (7263a5187f9e vti: get rid of
>> nf mark rule in prerouting) introduced significant changes, and
>> implies behaviors dependant on the kernel version, but it seemed to
>> meet Saurabh's agreement, as the following thread witnesses:
>>
>> http://www.spinics.net/lists/netdev/msg253134.html
>>
> Getting rid of the pre-routing mark, which had to be done outside of
> the vti tunnel code was prone to misconfiguration. Though it is
> unfortunate that it creates a kernel version dependency.

  parent reply	other threads:[~2013-11-21 10:08 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 [this message]
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
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=528DDB5F.8080400@6wind.com \
    --to=christophe.gouault@6wind.com \
    --cc=bsderandrew@gmail.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=fan.du@windriver.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=netdev@vger.kernel.org \
    --cc=saurabh.mohan@brocade.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.