3 ms·

So I suppose the obvious question is, why did you roll your own instead of a well-known VPN protocol?

by hueving 12y ago

tptacek 12y ago
Not the OP, but also can speak for the perspective of some vendors other than Silver Springs (I'm unfamiliar with Silver Springs protocol): 1. Running on an RTOS platform, not Linux, so no VPN builds cleanly 2. Running on constrained platforms for which code space is not available for all the crap that comes with a VPN codebase 3. Operating a very constrained RF protocol in which every bit in every transmitted frame has to be accounted for, so not only is there no room to run something like L2TP/IPSEC, but what crypto can be run is also compromised (this is what makes me worry about "we use strong primitives unlike OSGP"). 4. Operating simple protocols with simple service models in which lots of round trips for session establishment are unworkable. 5. Can potentially get AES working on the platform, but less reasonable to use anything that requires bignum math, which makes Diffie-Hellman a problem; instead just using static keys, or some simple key rotation schedule.
- JoachimSchipper 12y ago
  This is true. Also, as someone who also works on network crypto boxes: the main VPN protocols are _really_ nasty. - OpenVPN requires TLS (you really don't want to use static keying in OpenVPN), which is a total nonstarter: the TLS protocol itself has non-stop problems, is completely infeasible to implement from scratch, and does not have any implementations useful for a high-security embedded device. Also, the data channel protocol is ugly. - DTLS-based VPNs are, well, DTLS-based (worse protocol than TLS, and still infeasible to implement). - IPsec is comparatively sane if you limit yourself to statically-keyed tunnel-mode ESP with no internal NAT'ing (NAT-T is ok, though). IKE is a pain (and usually requires certificates, which are very hard to parse correctly), and supporting all the zillions of options is extremely expensive. On the other hand, static keying has many pitfalls and pretty much requires a mechanism to send updated keys. Also, IPsec overhead usually ends up being rather high in practice, and e.g. IPsec/L2TP is even worse. - In practice, anything that requires connection negotiation requires some surgery to support high-packet-loss scenarios. (Loss-tolerant protocols over statically keyed IPsec work decently well at packet loss rates that break most IKE implementations.) Also, for any given device, you'd usually prefer to support as few algorithms as possible and/or tailor choose crypto primitives that are well-supported on your hardware. Finally, building a secure VPN wire protocol just isn't that hard. (Key negotiation etc. is very tricky, though.)
  - bdamm 12y ago
    These are all very good points. In addition: * We really care about on-the-"wire" efficiency. So we like having control over that. * We actually looked very hard at DTLS, and do support it, but it is still optimized for browsers and not devices and as such carries some thought-baggage that is tricky to work around. So DTLS doesn't carry the bulk of our traffic. * IPSec turned out to be impossible to support at the back end. Equipment that supports IPSec tunnel termination often is sold in terms of tens of thousands of tunnel terminations per box. We need tens of millions. That scale does not work for us. We do use it in some specific circumstances though. * Anything that requires TCP is a non-starter as well. Not at all for the same reasons as the QUIC people. The NoTCP joke was really funny to me.
  - hueving 12y ago
    >TLS (you really don't want to use static keying in OpenVPN), which is a total nonstarter: the TLS protocol itself has non-stop problems I beg to differ. What's we've seen is non-stop problems from implementation mistakes when it comes to all of the extra extensions. Maybe this indicates there would be a market for an opinionated TLS embedded library... >On the other hand, static keying has many pitfalls and pretty much requires a mechanism to send updated keys. Static keying issues aren't unique to IPsec, they occur with every symmetric cipher. There is nothing stopping you from having a management tool that rotates the static key based on a master key and the day. Or if you want to send updated keys, you just encrypt them and send them over the IPsec connection using GPG or whatever your asymmetric choice is. >Finally, building a secure VPN wire protocol just isn't that hard. (Key negotiation etc. is very tricky, though.) I'm sorry for saying this, but that's what every single person that has implemented a broken protocol thinks. It's true that it's not hard to get one that encrypts and decrypts. The trick is getting one that doesn't leak any information. There is basically know way to know that without an extensive analysis by the entire crypto community. Look at how long TLS has existed and they are still just finding issues now. RC4 is another example of one that looked pretty good for quite a while and then fell under scrutiny. Do you really think you are smart enough to know everything the entire crypto community knows?
    - tptacek 12y ago
- bdamm 12y ago
  Awesome overview, although we totally use (EC)DH mostly by offloading the crypto heavy lifting to a dedicated crypto processing unit. It's amazing what you can get in tiny packages these days.

So I suppose the obvious question is, why did you roll your own instead of a well-known VPN protocol?

by hueving 12y ago

So I suppose the obvious question is, why did you roll your own instead of a well-known VPN protocol?

Not the OP, but also can speak for the perspective of some vendors other than Silver Springs (I'm unfamiliar with Silver Springs protocol): 1. Running on an RTOS platform, not Linux, so no VPN builds cleanly 2. Running on constrained platforms for which code space is not available for all the crap that comes with a VPN codebase 3. Operating a very constrained RF protocol in which every bit in every transmitted frame has to be accounted for, so not only is there no room to run something like L2TP/IPSEC, but what crypto can be run is also compromised (this is what makes me worry about "we use strong primitives unlike OSGP"). 4. Operating simple protocols with simple service models in which lots of round trips for session establishment are unworkable. 5. Can potentially get AES working on the platform, but less reasonable to use anything that requires bignum math, which makes Diffie-Hellman a problem; instead just using static keys, or some simple key rotation schedule.

JoachimSchipper 12y ago
This is true. Also, as someone who also works on network crypto boxes: the main VPN protocols are _really_ nasty. - OpenVPN requires TLS (you really don't want to use static keying in OpenVPN), which is a total nonstarter: the TLS protocol itself has non-stop problems, is completely infeasible to implement from scratch, and does not have any implementations useful for a high-security embedded device. Also, the data channel protocol is ugly. - DTLS-based VPNs are, well, DTLS-based (worse protocol than TLS, and still infeasible to implement). - IPsec is comparatively sane if you limit yourself to statically-keyed tunnel-mode ESP with no internal NAT'ing (NAT-T is ok, though). IKE is a pain (and usually requires certificates, which are very hard to parse correctly), and supporting all the zillions of options is extremely expensive. On the other hand, static keying has many pitfalls and pretty much requires a mechanism to send updated keys. Also, IPsec overhead usually ends up being rather high in practice, and e.g. IPsec/L2TP is even worse. - In practice, anything that requires connection negotiation requires some surgery to support high-packet-loss scenarios. (Loss-tolerant protocols over statically keyed IPsec work decently well at packet loss rates that break most IKE implementations.) Also, for any given device, you'd usually prefer to support as few algorithms as possible and/or tailor choose crypto primitives that are well-supported on your hardware. Finally, building a secure VPN wire protocol just isn't that hard. (Key negotiation etc. is very tricky, though.)
- bdamm 12y ago
  These are all very good points. In addition: * We really care about on-the-"wire" efficiency. So we like having control over that. * We actually looked very hard at DTLS, and do support it, but it is still optimized for browsers and not devices and as such carries some thought-baggage that is tricky to work around. So DTLS doesn't carry the bulk of our traffic. * IPSec turned out to be impossible to support at the back end. Equipment that supports IPSec tunnel termination often is sold in terms of tens of thousands of tunnel terminations per box. We need tens of millions. That scale does not work for us. We do use it in some specific circumstances though. * Anything that requires TCP is a non-starter as well. Not at all for the same reasons as the QUIC people. The NoTCP joke was really funny to me.
- hueving 12y ago
  >TLS (you really don't want to use static keying in OpenVPN), which is a total nonstarter: the TLS protocol itself has non-stop problems I beg to differ. What's we've seen is non-stop problems from implementation mistakes when it comes to all of the extra extensions. Maybe this indicates there would be a market for an opinionated TLS embedded library... >On the other hand, static keying has many pitfalls and pretty much requires a mechanism to send updated keys. Static keying issues aren't unique to IPsec, they occur with every symmetric cipher. There is nothing stopping you from having a management tool that rotates the static key based on a master key and the day. Or if you want to send updated keys, you just encrypt them and send them over the IPsec connection using GPG or whatever your asymmetric choice is. >Finally, building a secure VPN wire protocol just isn't that hard. (Key negotiation etc. is very tricky, though.) I'm sorry for saying this, but that's what every single person that has implemented a broken protocol thinks. It's true that it's not hard to get one that encrypts and decrypts. The trick is getting one that doesn't leak any information. There is basically know way to know that without an extensive analysis by the entire crypto community. Look at how long TLS has existed and they are still just finding issues now. RC4 is another example of one that looked pretty good for quite a while and then fell under scrutiny. Do you really think you are smart enough to know everything the entire crypto community knows?
  - tptacek 12y ago
bdamm 12y ago
Awesome overview, although we totally use (EC)DH mostly by offloading the crypto heavy lifting to a dedicated crypto processing unit. It's amazing what you can get in tiny packages these days.