4 ms·

That's the thing with a vpn - it is just a single component of a fully setup network. The vpn documentation generally just covers how to setup the vpn connectio

by weavie 8y ago

That's the thing with a vpn - it is just a single component of a fully setup network. The vpn documentation generally just covers how to setup the vpn connection. The routing and rest of the network setup, as per the questions you are asking, generally falls out of its domain and into general networks.. which is quite a huge area!

kazen44 8y ago
this is a very good point. Also, from a network design perspective, the difference between a tunnel, GRE interface or VPN is nonexistant. They all accomplish the same objective with different technical methods.
- tssva 8y ago
  This is certainly not true. Tunneling and VPN protocols have distinct characteristics and capabilities which greatly affect network design. The reason for this is that they are not all designed to accomplish the same objective.
  - Hello71 8y ago
    Only if you're using the ridiculous IPsec protocol and its ridiculous modes. Nobody actually needs a mode that authenticates the header but doesn't encrypt it, and nobody can understand this mode anyways. Nobody needs ECB or 3DES or any of the other zillions of IPsec methods. The great thing about WireGuard is that it removes all the crap and has one mode: Fast and Secure.
    - tialaramex 8y ago
      The slightly dated TLS 1.3 talk from Rescorla talks about this briefly, this is not a situation with easy answers and the approach taken in WG, which is also the approach in TLS 1.3, may yet turn out to be a bad idea. In TLS 1.3 they have left themselves a fire exit they can run out of, hair ablaze, but it's not clear to me whether WG has a way out. From an API point of view, "Fast and secure" sounds pretty good. It maybe infantalizes the Software Engineer, which we're not really ready for yet‡, but we get more ready all the time, so I'll let that go. It's certainly better than "No real security unless you're an expert" which was historically what such APIs tend to offer. On the implementation side "fast and secure" is just a wish, not a fact. Individual elements, picked for being "fast and secure" may turn out not to be as fast as we'd like on tomorrow's hardware, or they may not turn to be as "secure" as we'd have liked. IPsec's Chinese Menu approach lets the software engineer pick something else, but WG's approach doesn't permit this. So, the entire protocol must perhaps be re-designed. ‡ Twenty years ago, we had no good "This just works" answers for a great many things software engineers expect from cryptography. Today we have good answers for many of them, e.g. AEAD modes for block ciphers do roughly what a non-expert software engineer foolishly thought the encryption did anyway. But for others we're still in the dark. Padding for example. For privacy we should pad lengths to hide the true nature of the data being transferred. But... how much should we pad? Today our answer is that hopefully the software engineer using the API knows. In almost all cases they do not.
yaleman 8y ago
That's an OK point, but when half the comments on this thread are "I had to mess around for days to work out the config" then surely some common use cases can be covered by general FAQ's, like every other VPN/networking technology provides?

by weavie 8y ago

kazen44 8y ago

this is a very good point. Also, from a network design perspective, the difference between a tunnel, GRE interface or VPN is nonexistant. They all accomplish the same objective with different technical methods.

tssva 8y ago
This is certainly not true. Tunneling and VPN protocols have distinct characteristics and capabilities which greatly affect network design. The reason for this is that they are not all designed to accomplish the same objective.
- Hello71 8y ago
  Only if you're using the ridiculous IPsec protocol and its ridiculous modes. Nobody actually needs a mode that authenticates the header but doesn't encrypt it, and nobody can understand this mode anyways. Nobody needs ECB or 3DES or any of the other zillions of IPsec methods. The great thing about WireGuard is that it removes all the crap and has one mode: Fast and Secure.
  - tialaramex 8y ago
    The slightly dated TLS 1.3 talk from Rescorla talks about this briefly, this is not a situation with easy answers and the approach taken in WG, which is also the approach in TLS 1.3, may yet turn out to be a bad idea. In TLS 1.3 they have left themselves a fire exit they can run out of, hair ablaze, but it's not clear to me whether WG has a way out. From an API point of view, "Fast and secure" sounds pretty good. It maybe infantalizes the Software Engineer, which we're not really ready for yet‡, but we get more ready all the time, so I'll let that go. It's certainly better than "No real security unless you're an expert" which was historically what such APIs tend to offer. On the implementation side "fast and secure" is just a wish, not a fact. Individual elements, picked for being "fast and secure" may turn out not to be as fast as we'd like on tomorrow's hardware, or they may not turn to be as "secure" as we'd have liked. IPsec's Chinese Menu approach lets the software engineer pick something else, but WG's approach doesn't permit this. So, the entire protocol must perhaps be re-designed. ‡ Twenty years ago, we had no good "This just works" answers for a great many things software engineers expect from cryptography. Today we have good answers for many of them, e.g. AEAD modes for block ciphers do roughly what a non-expert software engineer foolishly thought the encryption did anyway. But for others we're still in the dark. Padding for example. For privacy we should pad lengths to hide the true nature of the data being transferred. But... how much should we pad? Today our answer is that hopefully the software engineer using the API knows. In almost all cases they do not.

yaleman 8y ago

That's an OK point, but when half the comments on this thread are "I had to mess around for days to work out the config" then surely some common use cases can be covered by general FAQ's, like every other VPN/networking technology provides?