[ovs-dev] encrypting only some traffic (was: OVN: Encrypt tunnel traffic with IPsec)

Ben Pfaff blp at ovn.org
Fri Jun 22 22:57:24 UTC 2018

On Thu, Jun 21, 2018 at 03:44:58PM -0700, Qiuyu Xiao wrote:
> Discussion
> ---------------
> The current proposal only allows CMS to choose either encrypting all
> tunnel traffic or not. A more flexible design allows CMS to define
> that only the tunnel traffic from certain logical networks should be
> encrypted. To enable this, the IPsec stack needs to differentiate
> tunnel traffic from different logical networks. The kernel IPsec
> module cannot match packets based on the tunnel header. In the sending
> side, OVS can use skb mark to tag the tunnel traffic and the IPsec
> module can decide whether to encrypt the packet based on the mark. I
> am not so sure whether the skb mark information will be carried and
> transmitted to the receiving side or not. If not, an adversary can inject
> unencrypted fake packets to the protected flow without being detected
> by the IPsec module.

The skb mark is metadata and thus not carried directly in the network.
The symmetric way to do this would be:

- For outgoing packets, the skb_mark determines whether the kernel will
  encrypt the packet.  OVN can use this to decide on arbitrary grounds
  (e.g. even in ACLs if we decided to support it) whether to encrypt a
  given outgoing packet.

- For incoming packets, the kernel sets the skb_mark to indicate whether
  the packet was received encrypted.  OVN can use this to decide whether
  a plaintext packet is acceptable and drop it if it was supposed to be

I don't know whether the kernel can actually do the above.  If not, then
whether a packet is to be encrypted would have to be decided based on
criteria that the kernel does support.  For example, it could be on the
basis of IP addresses (maybe one group of HVs has to communicate with
another group of HVs encrypted, e.g. because they are in different data
centers).  If kernel IPSEC can match on the VNI of a Geneve packet, then
possibly it could even be limited to particular logical networks.

Ansis, you might know some of the answers above, or have opinions.

More information about the dev mailing list