weavenetwork

Thanks @takeda.

Are you aware that we did not roll our own crypto? Instead we used the NaCl crypto libs[1]. Weave adds about 300 LOC to integrate NaCl.

You can read about it here - http://docs.weave.works/weave/latest_release/how-it-works.ht... You can also read a bit about weave crypto in the comments from mradestock and msackman elsewhere on this page.

I would be extremely grateful if you could provide actionable advice (or help) on which other crypto libraries could fit our requirements for weave. Please note that in addition to functional requirements, any library must be open source, hard to misuse, easy to package, and demonstrably safe.

alexis

[1] http://nacl.cr.yp.to/

What about them? Would you recommend one of them over the others?

I'll have to stop saying please when in the US then ;-) But seriously, thanks for taking the time to explain your point of view. alexis.

cripes.

on each host? what kind of physical network are you using, and how many containers per host? how many hosts? let me know if I should email about this instead.

What throughput do you need, on a per-host basis?

We are open to recommendations, help and overall insight from expert contributors in security. As many people on this thread have pointed out, it is a big and complex world..

We did not roll our own crypto. We used NaCl. The rationale is explained here - http://weaveworks.github.io/weave/how-it-works.html#crypto We agree that other approaches are possible, but this is the one we picked for our first version.

No, for example it is 100% uncharitable and unreasonble to assert that "please" is sarcastic. The truth is quite the opposite.

Paul, I think our work is good. We thought about our approach very carefully.. And we have built systems like this before. The main difficulty is to combine moving fast with limited resources, with delivering something supportable and improvable, without creating technical debt.

Complaining on twitter is not the same as finding an issue! Criticism has value, but not all commentary deserves equal weight or time before it is reasonable to request reciprocal effort.

indeed. at the risk of entering tinfoil hat land, note the following http://blog.cryptographyengineering.com/2014/12/on-new-snowd... ..although also the not 100% reassuring https://nohats.ca/wordpress/blog/2014/12/29/dont-stop-using-...

although, sometimes not obviously so: https://github.com/GoogleCloudPlatform/kubernetes/pull/4483#...

Tony, the team recently updated the crypto docs to clarify the rationale etc etc - http://weaveworks.github.io/weave/how-it-works.html#crypto ... Moreover the entire crypto code for weave is about 300 lines. Please please please if you are an expert then a thorough review would not only be welcome but also acted upon. Thank-you. Alexis.

Using an account that I share with other people in the same team is not the same as 'marketing'. I am sorry if this somehow offends, but think of the handle as just one poster.

edit:

here is a kubernetes link: https://github.com/GoogleCloudPlatform/kubernetes/pull/4483#...

the author, who was part of the MS Azure team at the time, said: "as of today, this Weave/CoreOS tool and doc is the only way I was able to provision a Kubernetes cluster in Azure"

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.

I'm sorry but I find your interpretations of 1-4 completely uncharitable and unreasonable.

I don't think anyone meant, or said, "fuck you". Why are you even implying such a thing?

Ultimately we can't work on even a fraction of the features that every person wants, and Laurie said his idea was simple to implement... so why not show how it's done? Honestly, it's not that sinister and it is certainly not rude.

as laurie mentions in his article, you can easily use off the shelf security solutions with weave... the point of the current crypto is to provide something basic that works. we chose nacl for ease of implementation primarily. happy to add more types of security in the future. help would be welcomed!

You can of course use etcd with weave... indeed weave can be run with no dependencies, so it may make sense as a way to bootstrap etcd ;-)

I haven't seen those used in the wild yet, but fwiw, weave is working on a 'fast data path' that uses the same kernel path as ovs

I should add that one way to get more throughput is to use more than one CPU.

yes, microseconds surely - we estimate that the cost of switching from kernel to user space, and back again, several times, adds up to 2-300 microseconds. in return for this, you gain a lot of flexibility and ease of use. for apps that need lower latency, weave is currently working on implementing a fast data path option..

I'm not sure why you think so, but fwiw, irl, I am alexis at weave dot works

Correct! Once upon a time people said Amazon cloud was too slow. Then they said it wasn't suitable for large workloads. Then they said it did not make money ... etc etc. I'm not saying we are like Amazon, I'm just saying that making new stuff excellent in all dimensions at once in hard ;-)

That's an entirely subjective statement. What do you mean by 'large'?

hello, weave here. a few very quick comments!

weave has lots of very happy users who find that weave is plenty fast enough for their purposes, see eg http://blog.weave.works/2015/02/24/get-your-kicks-on-cloud66...

the strong points of weave network, as it is right now, are ease of use (not to be sniffed at), and enormous flexibility. it is really quite easy to create an application involving containers, that runs anywhere and does not commit you to specific architectural choices...

typically though, one weave network might be used by one app, or just a few. but you might run a lot of weave networks

weave works very nicely with kubernetes - later I shall dig out a few links for this

in our own tests, throughput varies by payload size; we tend to think of weave-as-is is best compared with using, for example, amazon cloud networking directly

for users with higher perf needs, we have a fast data path in the works, that uses the same data path that ovs implementations use... the hard problem to solve here is making that stuff incredibly easy and robust w.r.t deployment choices -- see above :-)

Hoping to see something soon! We at Weaveworks are involved and mentioned progress on our blog this week.

this began as a chat between me and solomon, and I then invited everyone at dockercon who was implementing network/extension related stuff. this all happened over a few hours... so wasn't possible to invite folks to hop on a plane from SFO at that point.

we are hiring ;-)