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.
next prev 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$(echo .)com \
--cc=bsderandrew@gmail$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=fan.du@windriver$(echo .)com \
--cc=herbert@gondor$(echo .)apana.org.au \
--cc=netdev@vger$(echo .)kernel.org \
--cc=saurabh.mohan@brocade$(echo .)com \
--cc=sergei.shtylyov@cogentembedded$(echo .)com \
--cc=steffen.klassert@secunet$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox