* Peter van den Heuvel wrote on Fri, Jun 14, 2002 at 11:56 +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 :)
Well, I could write a more formally correct specification.
:) Surely you could, but I think it's not needed here ;)
quality". In software (and IT more generally) there's a funny tendency towards TONS of features and complexity to the extreme.
Yes, I think you're right here. This ends up in software with integrated anything that can do anything - except it's job :)
keys if your setup would be just as sound with a fixed key and a fixed protocol. The point was: look at yours requirements before you select a product.
Well, don't get me wrong, I think exactly the same. But I see another tendency: choosing simple architechtures for complex problems, and mostly that stuff works, but not well.
Much configuration -> much time and many mistakes that are hard to find. Yes, this is correct. But you cannot implement a solution which is more easy than the problem, usually ;) Thanks for pointing that out.
[Hope you don't missed the smilie]
Well, VPN is not a trivial theme, even if M$ and all those stuff suggests. If you use simple protocols, maybe they are just so simple since they are bad by design? Simplicity is an ASPECT. You realy think I meant to say that a bad architecture is better than a complex architecture?
It sounded a little like that. Sorry if I misunderstood you.
Where is the difference to a kernel patch? A module runs in kernel space and has access to any resource, and a wild pointer can happily crash your system. The difference is clarity in architecture.
Ohh, you mean, that modules usually have are more clean interface? Ohh, yes, I see what you mean. You are afraid in software that patches hundered points of foreign kernel sources probably with some side effects or such things? Indeed, this may be very risky and seems to be much more complex than useing a nice interface.
- It runs on most Microsoft platforms. Well, for Win it may be ok, and insecure VPN for insecure systems :) SCNR. It's just a feature, not a recommendation. And please, would you care to explain why you feel cipe is not secure?
I don't know what I meant with this, sorry, either it was too late that I mixed up something or it was a kind of typo.
- It uses UDP for transport (never use TCP for serious tunnelling). Hum, why UDP? IPSec uses protocol 50,51 IIRC. Well, tunneling UDP Packets in a TCP tunnel would dramaticall increase the reliance Yes, and sooo useful if the protocol being tunneled does it as well. And then both protocols get their own transmission window timeouts and try to correct. As soon as you loose packets you'll find out why you do not want to use TCP.
Yes, you do not want TCP for UDP transmissions. But that doesn't means that you do want UDP for UDP transmissions, and IP proto 50 isn't TCP as well. The point is that it's not the best idea to put stream characteristics on packet based applications/sessions, but this isn't the case in IPSec AFAIK. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.