Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Wireguard for OpenNetVM #225

Open
archit-p opened this issue Jun 10, 2020 · 8 comments
Open

Wireguard for OpenNetVM #225

archit-p opened this issue Jun 10, 2020 · 8 comments
Labels
enhancement 🚀

Comments

@archit-p
Copy link

Wireguard is a relatively new, lightweight and fast VPN protocol. Would it be a good idea to implement Wireguard over openNetVM for packet processing?

I have a few questions to discuss in this regard.

  1. Are there possible use-cases for VPNs in NFs?
  2. On Linux, WireGuard works by adding a network interface. This interface is then used for tunneling. For openNetVM, what would be the equivalent of this interface? Would a NF be a good equivalent?
  3. How hard would it be to verify the security of our implementation?

@twood02 @rohit-mp
@kkrama
Copy link

kkrama commented Jun 10, 2020 via email

@twood02
Copy link
Member

twood02 commented Jun 10, 2020

  1. Are there possible use-cases for VPNs in NFs?

Yes, I think a VPN endpoint is a good NF which would appear in many networks, e.g., at the edge of a business's data center.

It is certainly a popular network function, but a separate question is whether it is a good NF that would benefit from ONVM's high performance.

If the VPN processing is too expensive, there may not be much benefit from the things ONVM/DPDK do to speed up packet processing. As @kkrama points out, we should pick the VPN server which makes the most sense to implement (not just the one that is newest/most exciting). The two points I see in favor of wireguard are that it is supposed to be very efficient (so perhaps ONVM's optimizations will have more effect) and its code is supposed to be more portable (so perhaps it will be easier to port to ONVM). Since we professors won't be the ones implementing the code, it will be easier to convince us with the first point (speed).

  1. On Linux, WireGuard works by adding a network interface. This interface is then used for tunneling. For openNetVM, what would be the equivalent of this interface? Would a NF be a good equivalent?

My view is that the VPN here is being used to make an encrypted tunnel between the client and the VPN-NF. Encrypted packets come into the VPN-NF and unencrypted packets leave the NF. Those packets could be sent to another NF or they could be sent out a physical port as needed.

If you are able to implement both a VPN server and a VPN client NF, then we could also support a chain where encrypted packets come in to the VPN-Server-NF, are decrypted and sent through several other NFs (perhaps observing/modifying the payload) before going out a VPN-Client-NF which would send them out of the host to another normal wireguard VPN server running elsewhere. This would be useful for showing how NF processing could be done on encrypted traffic.

  1. How hard would it be to verify the security of our implementation?

For the crypto aspects we would be relying on the guarantees of WireGuard. I think our main interest would be understanding ways that the ONVM setup might limit the normal guarantees. For example, with our shared memory pools, we can't guarantee that another NF will be unable to see the decrypted traffic (at least with our current setup). However, this may not be significantly different from normal wireguard -- a VPN is mainly used to protect the traffic between two hosts, not to protect traffic within a host.

@kkrama
Copy link

kkrama commented Jun 10, 2020 via email

@archit-p
Copy link
Author

@kkrama we'll perform a study of the security guarantees made by Wireguard, and how it compares against OpenVPN and IPSec. Currently, their website contains a formal verification of the protocol. I'm in the process of understanding the verification steps.

Wireguard claims that it is faster than both IPSec and OpenVPN. So I believe it could make a good candidate for evaluating the performance improvements brought by using OpenNetVM for packet processing.

@twood02 from my understanding of what you mentioned, the Wireguard NF could be used as the first NF in a chain to allow for access to the VPN for the rest of the NFs. Is the following diagram a good illustration of this?
NF

Along with the points @twood02 mentioned, a benefit with Wireguard is that it only consists of peers. These peers could act as clients or servers in the OpenVPN sense. So in our case, one NF could be used multiple times in a chain to create a VPN.

An observation I made while using Wireguard was that a program running on a user's local computer can easily capture the packets sent by the user, before they are encrypted by Wireguard interface. This means that Wireguard is not secure that way. I am not sure how this would translate to the case of NFs. Would it be wise to assume that another NF running on the same onvm system reading the packets does not affect privacy?

Also, I had a question from the discussions above, what does a separate security domain for an NF mean? Is it that the secure NF would use a different part of memory from the other NFs? Is there a particular book/paper I could refer for gaining a better understanding on this?

@twood02
Copy link
Member

twood02 commented Jun 11, 2020

Yes, that picture is pretty much what I was thinking. Instead of "cloud" in the middle it might be "WAN" which would imply even less control/security as packets flowed through it. Or if we don't fully trust the cloud then your picture is the same thing.

An observation I made while using Wireguard was that a program running on a user's local computer can easily capture the packets sent by the user, before they are encrypted by Wireguard interface. This means that Wireguard is not secure that way. I am not sure how this would translate to the case of NFs. Would it be wise to assume that another NF running on the same onvm system reading the packets does not affect privacy?

I think this is because VPNs aren't trying to protect against attackers on the same host as the VPN endpoint. If we make the same assumption, then we are assuming that all other NFs on the host are trusted so it is OK that they can access the shared memory pool where decrypted packets reside. I think this is an OK assumption to start with.

If we don't trust the other NFs (for example if ONVM is being used by a network provider to support NFs from different tenants), then we would need to be more careful about where the decrypted packets go (it would be OK for the encrypted packets to be in the shared pools since we can rely on VPN crypto to prevent eavesdropping). This isn't specific to VPNs and would be the case for any deployment with untrusting NFs.

When @kkrama talks about security domains he means that we could use separate memory pools outside of the shared region for storing packets/data for each NF. Each pool would be shared between the ONVM manager and a group of NFs that trust each other. Moving between pools would require copying. We've talked about this for a while but never fully implemented it (we'd have to change how DPDK does memory mapping to have several different regions).

@archit-p
Copy link
Author

Thanks for clarifying!

We're currently working on understanding the wireguard internals and what will need to be changed in order to make it work with openNetVM. We'll share a document with the design proposals here, and also get feedback from the Wireguard community on how to go forward.

@kkrama
Copy link

kkrama commented Jun 13, 2020 via email

@archit-p
Copy link
Author

archit-p commented Jul 8, 2020

@rohit-mp and I have come up with a design for the NF, based on using multiple threads to offset the cost of heavy crypto operations. For making the existing wireguard code work with OpenNetVM or DPDK, we plan to replace the Linux skbuf with rte_mbuf. Aside from this, we plan to replace the existing work queues with rte_ring for making them lockless, and the Linux timers to DPDK timers.

The following figure illustrates our plan to structure the app:

We aren't sure if this design is the best, and would love feedback!

On the issue of memory colocation raised by @kkrama , it'd be very helpful to have a few meetings to fully understand the problem and/or collaborators to work on it in parallel.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement 🚀
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@twood02 @kkrama @archit-p