SSLproxy icon indicating copy to clipboard operation
SSLproxy copied to clipboard

Published 20 hours ago • verified publisher icon sonertari

DPDK Support

Open mmanoj opened this issue 6 years ago • 3 comments

Hi,

  1. Please, advice is there any plan to integrate with DPDK ?

  2. What are the max concurrent connections supported as per test/benchmarks?

Thank you, Manoj M

mmanoj avatar Oct 13 '18 16:10 mmanoj

There are a couple of things against DPDK:

  • I don't know much about it.
  • It is fully supported on Linux only (limited support on FreeBSD).
  • Packet processing performance is important, but I think the performance of SSL/TLS and L7 protocols is more important on SSLproxy.
  • Scaling out would be a better choice.

So I would probably consider DPDK if I were developing an appliance on Linux.

I don't have performance tests or benchmarks. The most well-known factors limiting the number of connections are CPU and available RAM of course, but the max number of file descriptors allowed by the system settings is more important. Because SSLproxy starts rejecting new connections if it reaches within FD_RESERVE (currently set to 10) of that limit. The openfiles-max is set in login.conf file on OpenBSD. You would want to increase it as much as possible. I increase it to 1024 on UTMFW.

sonertari avatar Oct 13 '18 22:10 sonertari

Hi,

Thanks for the quick advice. I'm looking more concurrent scenario like operator traffic, What is the best scaling out strategy you can suggest. I would like to check the feasibility with DPDK for linux. May be we have to use user space TCP stack.

On the other hand we have to think about user certificate which we trusting as it's not the actual certificate from server owner. It's privacy concern if it's operator traffic. It's real challenge content inspection in encrypted traffic. we can explore more about this.

Thank you, Manoj M

mmanoj avatar Oct 14 '18 14:10 mmanoj

What I mean by scaling out is multiple SSLproxy instances running on separate hardware. And the traffic is distributed to those instances via a packet (flow) distributor running in front of SSLproxy instances. How packets (flows) are distributed would be implementation specific, but seems nontrivial to me. What traffic should and should not go through SSLproxy is important, as I guess you are trying to say too. My comments here are just theoretical of course, as I haven't tried them in practice.

sonertari avatar Oct 16 '18 12:10 sonertari