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. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
