RE: [suse-security] VPN with pptp
While I agree that IPSec should be favoured over PPTP, I have to make a few comments about this last post.
The simpler it is the better I like it (both from a maintenance as well as a security point of view).
That is an important point I think! But IPSec is straight-forward, but of course you need to read half a page about IPSec to understand it. Well, there are multiple "modes" for IPSec operation and so on, at least here is potential for misconfigurations or such.
I don't think that's specific to IPSec, but to all VPN solutions. There isn't a lot to get wrong configuration-wise that's IPSec-specific and that'll get the connection sort of running. It's more of it either works or doesn't at all. However, IPSec isn't that straightforward... CIPE is definitely a lot simpler by pure design. Hmm, thinking about that, it probably would be possible to use IPSec pretty much the same way and keep it almost as simple (still using ESP instead of UDP, though). FreeS/WAN is also not as clean a package as many would like. It's good enough, though, to prefer it to PPTP, IMHO.
Complex -> much code -> many bugs.
This rule is definitly wrong. The number (and kind) of bugs depend on the quality which itselfs depend on the software creation processes. And many small "hacked-in" things are horrible :)
I disagree, the general rule is quite right. Of course there are ways to reduce the number of bugs even in complex projects, but it is the rule that more lines of code mean more bugs. Theoretically, of course, the number of lines per bug can be extended to infinity, which means that there'll be no bug at all in the associated code, but I think we all agree that this is a truly entirely theoretical and unrealistic proposition.
Also have a look at cipe. [snip] - It runs on most Microsoft platforms.
Well, for Win it may be ok, and insecure VPN for insecure systems :) SCNR.
He's talking about CIPE, not PPTP.
- It uses UDP for transport (never use TCP for serious tunnelling).
Hum, why UDP? IPSec uses protocol 50,51 IIRC.
Why not use UDP? What is the advantage of dedicated IP protocols in this context? Note that I'm not against either one, which you choose to use depends on design considerations. It is definitely easier and less hassle to make use of an existing protocol that's in widespread use, such as UDP, instead of applying for another IP protocol..
Well, tunneling UDP Packets in a TCP tunnel would dramaticall increase the reliance :)
Not that much, really. If UDP packets get lost between two nodes, TCP packets will almost certainly share their fate. The difference between TCP and UDP is that TCP will notice that packets have been lost and keep trying to retransmit them, while UDP alone won't. If the connection really is bad, though, TCP doesn't have any higher chances of success than UDP. And quite frequently, the application using UDP will take care of TCP's job. This is true for most, if not all of the applications that use UDP in a connection-oriented manner. Having said all that, I don't know if I'd agree that you shouldn't use TCP to build tunnels. No reasons are given, unfortunately.
- It's got one small config file (and even that causes enough problems to those who don't know - their networking basics).
Without knowledge noone should start :)
Amen! Cheers Tobias
* Reckhard, Tobias wrote on Fri, Jun 14, 2002 at 11:19 +0200:
Complex -> much code -> many bugs.
This rule is definitly wrong. The number (and kind) of bugs depend on the quality which itselfs depend on the software creation processes. And many small "hacked-in" things are horrible :)
I disagree, the general rule is quite right.
This rule is correct if you compare similar kind of software. But if you compare a small PHP script with an enterprise class java application, things may change quickly! If you implement the same design in the same language with similar technics, then this rule is right. In the company, we have some very efficient C implementations. They are small and their developers knew every bitshifting feature of C. But here you have sometimes a set of a few lines that look like that they make no sense. Others write "optimized for reading" and I prefere that. Some programmers optimize for source(!!) size, and I think that decreases the relialability.
Theoretically, of course, the number of lines per bug can be extended to infinity, which means that there'll be no bug at all in the associated code, but I think we all agree that this is a truly entirely theoretical and unrealistic proposition.
Yes, but I don't think that this is the point. If you have a clean design that consits of many small, simple, trivial components, then you can easily write tests and so on. Finally you may get a large code base, but here you have to expect less bugs, as for instance from a "from brain to keyboard" hacked PHP web site!
Well, for Win it may be ok, and insecure VPN for insecure systems :) SCNR.
He's talking about CIPE, not PPTP.
Ohh, yes, this was may mistake I wasn't aware in my last reply, I was misoriented by the subject :)
Hum, why UDP? IPSec uses protocol 50,51 IIRC.
Why not use UDP? What is the advantage of dedicated IP protocols in this context? Note that I'm not against either one, which you choose to use depends on design considerations.
Yes, why not use UDP, and why not use anything other. I don't think that this make a big difference.
It is definitely easier and less hassle to make use of an existing protocol that's in widespread use, such as UDP, instead of applying for another IP protocol..
Well, for me it's the same if you implement a protocol into UDP payload or in another IP protocol. Well, UDP offers ports and some things, but if you do not need them, why use UDP?
Well, tunneling UDP Packets in a TCP tunnel would dramaticall increase the reliance :)
Not that much, really. If UDP packets get lost between two nodes, TCP packets will almost certainly share their fate. The difference between TCP and UDP is that TCP will notice that packets have been lost and keep trying to retransmit them, while UDP alone won't.
Yes, so it would increase reliance, but...
If the connection really is bad, though, TCP doesn't have any higher chances of success than UDP. And quite frequently, the application using UDP will take care of TCP's job.
I think *that* is the point. If the UDP packets get retransmitted by the application, then it's not a good idea to have some TCP tunnel to repeat them also. This helps nothing.
Having said all that, I don't know if I'd agree that you shouldn't use TCP to build tunnels. No reasons are given, unfortunately.
When you have protocols that do not need any packet, for instance a real-time monitor, then it's often better to drop packets (since they are obsoleted by successors) than to repeat them over wire and drop them in the target application. Well, same for video or voice streams. Better a short quality reduction as very high latency. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
participants (2)
-
Reckhard, Tobias
-
Steffen Dettmer