On Mon, 25 Jun 2018 at 15:06, Qiuyu Xiao <qiuyu.xiao....@gmail.com> wrote: > > Thanks for your comments! > > > For #1 and #2 you would not need skb mark at all. Are you considering these > > two approaches as well? > > My current proposal will implement #1. #2 is also a nice feature to have! To > enable #2, the northbound and southbound database can include information > that dictate which pair of transport nodes requires encryption. Then the OVN > controller can set tunnel options accordingly.
If your current proposal is #1 and/or #2 then can you explain one more time why skb_mark is even needed? > > > 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. > > Do you mean the IPsec stack in the sending side will let packets through > without being signed? It is receiving side, not sending side that must let unencrypted (possibly malicious) packets through to Open vSwitch. > > > 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. > > In the receiving side, if the IPsec stack can set skb mark for the decrypted > packets from a logical network, then OpenFlow rules can be set to drop those > packets without the mark. Do you know whether the IPsec stack can do this? IPsec stack does not know what is Logical Switch. First of all Logical Switch ID in the Geneve packet is encrypted, so you must decrypt packet first. Secon, IPsec stack can match only on 4 tuple (ie src, dst IP address and port) and gre key. > > -Qiuyu > > > > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
