[HECnet] Integrating with the Italian network.

[H Vlems]

I wasn't aware that moving to TCP would result in all that. UDP and TCP both
use the same IP addressing functionality. Only UDP is connectionless, i.e.
doesn't use acknowledgement messages and is thus a little faster than TCP
but less reliable. An IP address change is as much as a problem for UDP as
it is for TCP, I'd say.
Security is another issue. As you wrote, authentication is sent as clear
text so is not secure. Then again, it may only be used if there is a
connection to HECnet and that would make no difference anyhow.
Encryption is fine, but it is an up hill struggle: it requires continuous
attention to keep up with technology. I doubt if HECnet is worth that
struggle. 

-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: zaterdag, november 2011 12:59
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Integrating with the Italian network.

On 2011-11-26 12.48, Johnny Billquist wrote:
On 2011-11-26 12.05, H Vlems wrote:
What I've read about the "enhancements" to the bridge program is yet
another
matter. First off, it ain't called bridge for nothing: like any layer 2
bridge the program moves packets between ports and is transparent to both
the content of the datagrams and the functionality of the protocol.
Including DNS like functionality violates that rule.

I also wanted to keep the complexity and overhead down. Otherwise, yes,
you could change from UDP to TCP, include SSL, and certificates, to make
sure we keep it safe. But that would incur quite some costs both from an
administrative point of view, as well as lots more CPU resources to run
the bridge, and also more problems in porting it to other systems.

To expand, perhaps, a little here.
If we switched to TCP, any change in IP addresses would be detected 
"immediately", since the TCP connection would be lost at an IP change.
At that point, the bridge would need to re-resolve the address, and try 
to establish a connection again. That would have to be repeated 
regularly until a connection comes up. Since this is very blocking, we'd 
have to change the bridge to be threaded, so that you have one thread 
per connection. And then queue packets inside the bridge, with throwing 
away when queues become to large, in order to prevent other connections 
from becoming affected.
In addition, this would affect the complexity of things like config 
reloads. Everything is, as usual, doable, but the work involved is not 
trivial. And then, of course, we have all the certificate issues, and 
all the code to deal with them.

And then, also, TCP can introduce unwanted network delays and 
burstiness. It really don't fit well with what the bridge do. It 
provides services not really needed.

And I really like simple solutions... :-)

	Johnny