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

Ansis Atteka ansisatteka at gmail.com
Mon Jun 25 17:16:56 UTC 2018

On Fri, 22 Jun 2018 at 15:57, Ben Pfaff <blp at ovn.org> wrote:
> 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
> > unencrypted fake packets to the protected flow without being detected
> > by the IPsec module.

There are at least 3 choices at what scope you could have the encryption
switch that admin could use to enable IPsec:

1. At the whole setup scope
2. At the scope between any two transport nodes (or group of nodes)
3. At the scope of logical switch

I think you are proposing #3 here. It is the most fine grained. However, it
would require to use "opportunistic packet authentication" and expose Open
vSwitch code to potential attackers, because the IPsec stack will have to
let through packets that are not signed.

In other words, instead of letting IPsec stack to drop malicious packets
you will require OpenFlow rule to do that. Probably based on skb mark in
match part.

For #1 and #2 you would not need skb mark at all. Are you considering these
two approaches as well?

> 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
>   encrypted.
> 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