4 ms·

A substantial fraction of the complexity of IPsec actually is the fault of the various vendors and implementations -- and is technically the complexity of IKE r

A substantial fraction of the complexity of IPsec actually is the fault of the various vendors and implementations -- and is technically the complexity of IKE rather than IPsec in most cases. It's actually quite simple under the hood and frankly can't be made much simpler while still achieving the security objectives. The often wildly overcomplicated configuration syntax together with subtle differences in implementation defaults, cipher and parameter naming are what I see creating challenges for vendor interoperability.

wrs 7y ago
The distinction between IKE and IPsec is the last thing on my mind when I’m in the fourth hour of debugging a connection. :) The existence of all the configuration options is the underlying problem. Well, the wealth of options plus the near-universal behavior when you have a mismatched configuration: either a vague yet misleading error message or just a silent refusal to work. Combine that with arbitrary vendor restrictions on that wealth of options and it’s just a guaranteed waste of time, E.g., neither GCP nor VMWare VeloCloud let you configure key lifetimes, so they can never connect to each other. Aside from the vendor stupidity, that’s a protocol problem: how does refusing to connect when the two sides disagree on key lifetime help security?
- 1_person 7y ago
  Permitting key lifetime to disagree can allow an attacker to manipulate key lifetime, which could defeat perfect forward secrecy if the key lifetime is manipulated towards infinity or used to gather data for a known plaintext attack if the key lifetime is manipulated towards 0. Replay attacks also come to mind.
  - jeltz 7y ago
    Yes, but that is kinda proving his point. The issue with IPSec is that way too many things are configurable which shouldn't be.
  - wrs 7y ago
    Or just have both sides pick the lowest/highest proposed lifetime with a fixed minimum/maximum. Or just don’t have lifetime be configurable, because what is the point?

wrs 7y ago

The distinction between IKE and IPsec is the last thing on my mind when I’m in the fourth hour of debugging a connection. :) The existence of all the configuration options is the underlying problem. Well, the wealth of options plus the near-universal behavior when you have a mismatched configuration: either a vague yet misleading error message or just a silent refusal to work. Combine that with arbitrary vendor restrictions on that wealth of options and it’s just a guaranteed waste of time, E.g., neither GCP nor VMWare VeloCloud let you configure key lifetimes, so they can never connect to each other. Aside from the vendor stupidity, that’s a protocol problem: how does refusing to connect when the two sides disagree on key lifetime help security?

1_person 7y ago
Permitting key lifetime to disagree can allow an attacker to manipulate key lifetime, which could defeat perfect forward secrecy if the key lifetime is manipulated towards infinity or used to gather data for a known plaintext attack if the key lifetime is manipulated towards 0. Replay attacks also come to mind.
- jeltz 7y ago
  Yes, but that is kinda proving his point. The issue with IPSec is that way too many things are configurable which shouldn't be.
- wrs 7y ago
  Or just have both sides pick the lowest/highest proposed lifetime with a fixed minimum/maximum. Or just don’t have lifetime be configurable, because what is the point?