4 ms·

Why reinvent the wheel when we already have IPsec?

wmf 16y ago
Basically, IPSec requires configuration and tcpcrypt doesn't. There's more in the Usenix Security paper: "A big challenge to IPSec is that it breaks middleboxes that require access to the transport layer. Given the increasing prevalence of NAT in particular, this excludes a large portion of the population from using IPSec. Tcpcrypt, by contrast, operates at the transport layer and so avoids these problems. Another challenge for IPSec is that it is hard to create a notion of a “session” in a connection-less environment (the network layer)."
deleted 16y ago
[deleted]
theBobMcCormick 16y ago
Have you configured many IPSec connections? It's a fricking pain in the rear. Nothing is every compatible "out of the box" and there are so many knobs to tweak and configure. Which is probably part of why everyone just uses SSL anymore, even for VPN's.
api 16y ago
"Why introduce this HTML/HTTP thing when we have Gopher? Don't re-invent the wheel!" Re-inventing the wheel is good. It's the only way we'll ever get better wheels.
- Groxx 16y ago
  Indeed; for all we know, our wheels are oblong if not triangular. Without reinventing the wheel sometimes, you'd never come up with stuff like this: http://en.wikipedia.org/wiki/Mecanum_wheel http://en.wikipedia.org/wiki/Mecanum_wheel
- arethuza 16y ago
  There were potential licensing issues with Gopher - by the time the creators of Gopher realized that this had scared off a lot of people and that they had shot themselves in the foot everyone had settled on using the Web - which had no such licensing issues.
ycweb 16y ago
IPSec doesn't support authentication well. For example, if you have a shared secret like a web cookie, how would you use this to authenticate one endpoint of an IPSec connection? It's hard, because the granularity of IPSec session keys is not the same as the granularity of tcp connections. Tcpcrypt, by contrast, makes it easy to do this--just hash the session ID together with the other authentication data.

wmf 16y ago

Basically, IPSec requires configuration and tcpcrypt doesn't. There's more in the Usenix Security paper: "A big challenge to IPSec is that it breaks middleboxes that require access to the transport layer. Given the increasing prevalence of NAT in particular, this excludes a large portion of the population from using IPSec. Tcpcrypt, by contrast, operates at the transport layer and so avoids these problems. Another challenge for IPSec is that it is hard to create a notion of a “session” in a connection-less environment (the network layer)."

deleted 16y ago

[deleted]

theBobMcCormick 16y ago

Have you configured many IPSec connections? It's a fricking pain in the rear. Nothing is every compatible "out of the box" and there are so many knobs to tweak and configure. Which is probably part of why everyone just uses SSL anymore, even for VPN's.

api 16y ago

"Why introduce this HTML/HTTP thing when we have Gopher? Don't re-invent the wheel!" Re-inventing the wheel is good. It's the only way we'll ever get better wheels.

Groxx 16y ago
Indeed; for all we know, our wheels are oblong if not triangular. Without reinventing the wheel sometimes, you'd never come up with stuff like this: http://en.wikipedia.org/wiki/Mecanum_wheel http://en.wikipedia.org/wiki/Mecanum_wheel
arethuza 16y ago
There were potential licensing issues with Gopher - by the time the creators of Gopher realized that this had scared off a lot of people and that they had shot themselves in the foot everyone had settled on using the Web - which had no such licensing issues.

ycweb 16y ago

IPSec doesn't support authentication well. For example, if you have a shared secret like a web cookie, how would you use this to authenticate one endpoint of an IPSec connection? It's hard, because the granularity of IPSec session keys is not the same as the granularity of tcp connections. Tcpcrypt, by contrast, makes it easy to do this--just hash the session ID together with the other authentication data.