Weave is kinda slow • Hacker News Board

Re: Weave is kinda slow

#111

Post by yellowapple » Wed, May 06, 2015, 10:45 PM UTC

weavenetwork wrote: post #87

api wrote: post #72

Earlier quoted context omitted.

You speak as if SSL/TLS hasn't been a rat's nest of problems. If they did it competently, there is no reason they couldn't implement their own crypto encapsulation. As far as why they rolled their own... have you ever actually tried to use IPSec? It's a usability nightmare. It's also problematic in containers due to container permission issues. I suppose they could have used DSSL (datagram SSL) but that'd probably ad…

True. We did try ipsec, and couldn't find an implementation that was oss, demonstrably safe, and easy enough to pull into a first release. As weave matures, we'd love to work with experts to implement standard solutions, even if they are costly to put in place.

OpenBSD's implementation checks off at least the first two boxes, though the third would be a bit difficult in the GNU/Linux world.

Re: Weave is kinda slow

#112

Post by otterley » Wed, May 06, 2015, 11:39 PM UTC

stephengillie wrote: post #107

Confusion wrote: post #81

Earlier quoted context omitted.

I read the article: if they are, that is quite unclear to me. Possible answers that are discussed are only 'some sort of IP encapsulation', which is vague and GRE, which is just a single solution. He doesn't seem to disapprove of VXlan, so probably something was missing in 'IP encapsulation and GRE'. Was 'all problems solved decades ago' merely hyperbole or is there actually something to it?

I read the article, and I don't understand why we're trying to solve the problem of "telling each ContainerOS to listen/respond to an additional IP address, and route it to the correct Container" by "creating another network layer and accompanying additional complexity". In IIS this is done with Bindings.

On Linux this is done with virtual interfaces and DHCP. It's actually pretty straightforward.

Re: Weave is kinda slow

#113

Post by wbl » Thu, May 07, 2015, 12:19 AM UTC

api wrote: post #76

msutherl wrote: post #51

Earlier quoted context omitted.

This "our project is open source, feel free to submit a patch" dismissal is so passive aggressive. If you mean "fuck you," then just say "fuck you." That said, you shouldn't be saying "fuck you" in the first place: it's rude, it contributes to bad vibes in the OSS community, and it hurts you more than anybody. Try instead something like: "I'm having trouble understanding your argument, do you mind explaining in more…

"Fuck you" would have indeed been a more appropriate response to "how dare you try to implement crypto" FUD. Crypto is hard, but it's no harder than a lot of other hard things. If you think someone's crypto is broken, you could point out why you think it's broken. I see no evidence that consigning crypto to a forbidden zone is going to improve real world security, and the old "mature" cruftpiles seem to manifest prob…

No, it was clearly understood when SSL was developed, as shown in http://web.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipse.... The real reason why crypto is hard is that it requires an enormous amount of extremely specialized domain knowledge, and very subtle differences between two protocols can make the difference between success and failure. ISO regularly standardizes broken crypto.

Re: Weave is kinda slow

#114

Post by jheriko » Thu, May 07, 2015, 1:17 AM UTC

bascule wrote: post #39

Weave has other issues... like they homebrewed their own ECDHE-PSK-based transport encryption protocol on top of NaCl. Homebrewing your own crypto, especially transport encryption which has to solve problems like key exchange, replay attacks, etc is generally the wrong answer. Also, even if they were using a standard transport encryption like SSL/TLS or IPSEC, PSKs are generally frowned upon for anything other than p…

"they do not use a password hashing function"

this is a bit of a facepalm whenever i hear this.

Re: Weave is kinda slow

#115

Post by wmf » Thu, May 07, 2015, 2:07 AM UTC

otterley wrote: post #102

Confusion wrote: post #81

Earlier quoted context omitted.

I read the article: if they are, that is quite unclear to me. Possible answers that are discussed are only 'some sort of IP encapsulation', which is vague and GRE, which is just a single solution. He doesn't seem to disapprove of VXlan, so probably something was missing in 'IP encapsulation and GRE'. Was 'all problems solved decades ago' merely hyperbole or is there actually something to it?

Is GRE inadequate? A single solution that solves most cases, is codified in an RFC, and has mature, reliable, performant implementations sounds like a winner to me.

GRE (well NVGRE) works, but it's not offloaded by most NICs and it doesn't have port numbers to provide as much ECMP entropy as UDP.

Re: Weave is kinda slow

#116

Post by wmf » Thu, May 07, 2015, 2:10 AM UTC

api wrote: post #78

sophacles wrote: post #19

Earlier quoted context omitted.

How the heck are you running containers without kernel access? Does your software not malloc or read files or you know... execute?

Containers implement something not unlike SELinux policies. Networking stuff requires the NET_ADMIN permission, which is not set by default.

Setting up networking requires root but so does creating the container so I don't see what the problem is. Using networking doesn't require any special permissions.

Re: Weave is kinda slow

#117

Post by bascule » Thu, May 07, 2015, 2:22 AM UTC

juliangregorian wrote: post #80

msutherl wrote: post #51

Earlier quoted context omitted.

This "our project is open source, feel free to submit a patch" dismissal is so passive aggressive. If you mean "fuck you," then just say "fuck you." That said, you shouldn't be saying "fuck you" in the first place: it's rude, it contributes to bad vibes in the OSS community, and it hurts you more than anybody. Try instead something like: "I'm having trouble understanding your argument, do you mind explaining in more…

I find your attitude the ruder. Users of paid products have the right to complain about stuff like that; it's literally what they paid for. Users of open source projects have no such right: if you know what to do, why not make yourself useful instead of bitching out someone who's volunteered their free time to make your life easier? I have very little patience with armchair pundits myself, if you submit a pull reques…

You think security domain experts don't have the "right" to "bitch" (or perhaps, say, "inform") about potential security problems?

I understand you're trying to "get things done" but crypto is an area where you have to tread carefully, and talking down or ignoring people trying to inform you about security flaws is only encouraging the development of insecure software.

Re: Weave is kinda slow

#118

Post by bmurphy1976 » Thu, May 07, 2015, 2:41 AM UTC

otterley wrote: post #103

wmf wrote: post #83

Earlier quoted context omitted.

Docker was designed to be very easy to get started on your laptop with one IP address and it looks like some people are getting stuck in that model. I agree that if you are running on AWS VPC or some other overlay you should just use VPC for container networking. You shouldn't overlay your overlay. But there isn't any tooling that I know of to do that.

Everyone I know who runs Docker runs it in a virtual machine manager that has a built-in DHCP server and provide multiple virtual interfaces to the virtual machine. Certainly both VirtualBox and VMWare do. Even if one runs a Docker bridge in his development VM, that doesn't one must do so in production as well. Are we in this mess because production engineers don't understand networking?

We're in this mess because cloud providers don't give you all the functionality you need to solve things properly.

It's only a matter of time before they do, until then...

Re: Weave is kinda slow

#119

Post by swansonc » Thu, May 07, 2015, 3:49 AM UTC

lclarkmichalek wrote: post #79

swansonc wrote: post #67

Earlier quoted context omitted.

It depends on how you use DPDK. If I use it from the container directly to the NIC, you certainly do loose all of the kernel capabilities. However, we believe (but have not tested) that you can use a DPDK virtual interface in the container/vm (memnic or virtio) that connects to the DPDK driver in the kernel, so the path from the container/VM is 0 copy. The kernel then does it's processing, and then, another DPDK path…

Now that sounds interesting. I'd love to read about that if you ever do move the idea from paper to production :)

We'll let you know.

Re: Weave is kinda slow

#120

Post by tobbyb » Thu, May 07, 2015, 5:28 AM UTC

Container networking is not special or different from VM networking. There are tons of proven and widely used technologies available in the open source ecosystem.

We have been building out a series of networking tutorials at flockport from basics; static, public, private IPs, NAT, bridging etc to multi-host container networking with GRE, L2TP, VxLAN, IPSEC focussed on LXC but these will work with VMs and containers in general.

They don't need any special tools, just IP tools and the kernel and deliver performance and security. A lot of the Docker centric networking projects use these under the hood but they are easy enough to use on their own.

http://www.flockport.com/news