> The thinking behind this was that IPsec had to work at the IP level so > combining it in transport mode with a tunnel guarantees that.
In addition, I don’t know if it is helpful, but if ipsec is the way to go, they guys over at Free Range Routing, a Quagga fork, are working some aspect of ipsec to handle the ospf3 authentication mechanisms (which may or may not include the transport encryption). But as there is also some form of ipsec associated with ipv6, maybe there is something reusable there. They are talking about interacting with ipsec via netlink. Maybe some of their code is re-usable? (their starting code currently using iproute2). Thread starts at: https://lists.frrouting.org/pipermail/dev/2017-September/000895.html <https://lists.frrouting.org/pipermail/dev/2017-September/000895.html> Initial code: https://github.com/opensourcerouting/frr/commit/6c53790886228ffd22874f1da25c64a6587017bd <https://github.com/opensourcerouting/frr/commit/6c53790886228ffd22874f1da25c64a6587017bd> Don’t know if sharing code between projects is even feasible. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
