[ovs-dev] OVN: Encrypt tunnel traffic with IPsec

[Qiuyu Xiao]

Hi everyone,

I am writing this email to propose adding encryption support to OVN
tunnel. The plan is described as below. Any feedbacks and suggestions
are appreciated!

Regards,
Qiuyu Xiao

Motivation
--------------
OVN tunnel traffic goes through physical routers and switches. These
physical devices could be untrusted (devices in public network) or
might be compromised. Adding encryption support to the tunnel traffic
can prevent the traffic data from being monitored and manipulated.

Design
----------
OVN gives an option to the Cloud Management System (CMS) to indicate
whether tunnel encryption should be enforced or not. If tunnel
encryption is set, all tunnel traffic between chassis is encrypted.

IPsec is used to encrypt tunnel traffic. IPsec policy can be set to
match traffic based on L4 protocol and port information, so we can set
policy to only encrypt GENEVE, STT, and VXLAN tunnel traffic without
introducing extra overhead.

The authentication between chassis is done by using PKI. Role-based
access control for southbound DB already requires installing
certificate and private key for each chassis. The same certificate and
private key can be used by IPsec IKE daemon.

Implementation plan
---------------------------
1) database
In the northbound DB NB_Global table and the southbound DB SB_Global
table, add an "ipsec" column of boolean type to record the tunnel
encryption setting.

2) ovn-northd
ovn-northd monitors the state of the "ipsec" column in NB_Global and
populates the change to the "ipsec" column in SB_Global.

3) ovn-controller
Based on the "ipsec" column in SB_Global, ovn-controller sets options
of the tunnel interface to indicate whether the tunnel traffic should
be encrypted or not.

4) ovs-monitor-ipsec daemon
ovs-monitor-ipsec
(https://mail.openvswitch.org/pipermail/ovs-dev/2015-June/299669.html)
was used to configure StrongSwan IKE keying daemon by monitoring the
tunnel options. It configures StrongSwan to do authentication based on
peer certificate. A preferable solution is to enable CA-based
authentication so that each chassis only needs to store its own
certificate and the CA's certificate.

5) ovs-pki
Change ovs-pki to generate x509v3 certificate of which the
subjectAltName field contains the chassis name. StrongSwan extracts
the certificate identity string from the Distinguished Name (DN) field
or the subjectAltName field. DN includes other information besides the
chassis name (in the Common Name field). By using subjectAltName to
store the chassis name, we don't need to populate other information
from DN to the southbound DB.

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.