Subject: Re: [PATCH net v3] vti: fix spd lookup: match plaintext pkt, not ipsec pkt

From: Christophe Gouault <[email-masked]>
Date: Thu, 21 Nov 2013 11:07:27 +0100

Hi Saurabh,

Good to read your rationale.

On 11/18/2013 10:38 PM, Saurabh Mohan wrote:
>
>
>> -----Original Message----- From: Christophe Gouault
>> [mailto:[email-masked]] Sent: Thursday, November 07,
>> 2013 4:56 AM To: Steffen Klassert Cc: David S. Miller; Herbert Xu;
>> [email-masked]; 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.