* 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.
-- 
To unsubscribe, e-mail: suse-security-unsubscribesuse.com
For additional commands, e-mail: suse-security-helpsuse.com
Security-related bug reports go to securitysuse.de, not here

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]