Open archit-p opened 4 years ago
It would be good to do a somewhat careful analysis from a security standpoint of the different VPN approaches. I am not sure you want to pick something that is new and not yet battle tested.
On Wed, Jun 10, 2020 at 11:43 AM Archit Pandey notifications@github.com wrote:
Wireguard https://wireguard.com 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.
- Are there possible use-cases for VPNs in NFs?
- 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?
- How hard would it be to verify the security of our implementation?
@twood02 https://github.com/twood02 @rohit-mp https://github.com/rohit-mp
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sdnfv/openNetVM/issues/225, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC6TUJJ44OEBAXYZWX6TPE3RV7H6VANCNFSM4N2UVHTQ .
-- K. K. Ramakrishnan
- 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).
- 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.
- 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.
The assurances that a user on a client machine gets is that none of his traffic is visible to anyone else. He really can't understand the big difference between having TLS on his machine and the VPN. So, we cannot take the risk that someone else running on an NF on ONVM can see the traffic the user sent. We need to be able to assure users that the VPN provides the capability that has been typically provided. The VPN NF probably will need to run on a separate security domain in the ONVM I think. Let us understand the security implications carefully before proceeding.
On Wed, Jun 10, 2020 at 12:49 PM Tim Wood notifications@github.com wrote:
- 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 https://github.com/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).
- 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.
- 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.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sdnfv/openNetVM/issues/225#issuecomment-642221157, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC6TUJMGB3TIXMZV2AIW6YTRV7PVLANCNFSM4N2UVHTQ .
-- K. K. Ramakrishnan
@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?
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?
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).
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.
We should think a bit carefully about what a VPN NF's role is. What are the service assurances it provides, and if it is any different than a VPN appliance? Quoting Tim: "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." - my belief is that for NFs claiming to provide security services are indeed distinct in that they provide assurances to users. So, if that VPN NF is co-resident with other NF functions that are supported by a provider (cloud/network), then the exposure of the traffic to those other NFs must be carefully considered.
On Sat, Jun 13, 2020 at 6:36 AM Archit Pandey notifications@github.com wrote:
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.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sdnfv/openNetVM/issues/225#issuecomment-643624931, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC6TUJJSTMHXVCPOJKULFKDRWN6HTANCNFSM4N2UVHTQ .
-- K. K. Ramakrishnan
@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.
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.
@twood02 @rohit-mp