> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Jacek Sieka
> Sent: Wednesday, January 05, 2005 10:48 AM
> To: 'Direct Connect developers'
> Subject: RE: SV: [dcdev] Anyone still alive?
> 

> > I recently brought case-insensitivity on the development hub,
> > and it's a
> > noticeable issue. According to Tim Bray at
> > http://dotnetjunkies.com/WebLog/sriram/archive/2004/11/18/3270
> > 7.aspx#32794,
> > I'm sure hub authors will love that when they were (only partially
> > tongue-in-cheek) suggesting $ClientID sorts of mechanisms to save CPU
> > time because parsing the tag is just so horribly slow. I'm mostly
> > indifferent with mild bias against mandatory case-insensitivity for
> > unrelated reasons, but best to know this beforehand.

> Indeed. Case sensitive it is then...

Hey there, I think there needs to be a standard. Either case sensitivity or not, and I prefer not. When are case insensitivity matches taking place? Only on login to check user name? In that case, It's not like every command needs these checks, and I'm not sure why this would be heavy for a hub. I kind'a don't like the idea of forcing nick names into a specific case. We already have that when logging into unix machines and in many other computer domains for usernames... Personally I don't like it, but it's not the end of the world.

> > It drastically exceeds a 10Mbit/s connection's capacity, and
> > that of a
> > 100Mbit/s connection less drastically, even on a slow machine, and in
> > the former case by an order of magnitude even when not using
> > 100% CPU as
> > that test allowed. However, I fully expect that should encryption
> > appear, 100Mbit/s users might disable it as I gather they reasonably
> > commonly disable zlib compression.

> The problem is not the client, the problem is obviously the hub...

Indeed the hub, but I've had another thing in mind. Since some networks actually take action on simple things such as dc filenames, and some networks don't, couldn't it be that some users would need to _require_ encrypted traffic? Today if a 100mbit person disabled zlib, they use extra bandwidth from a 0.5mbit person, so maybe ones gain, but the others pain. When it comes to encryption I think that if it is to be implemented, the 'option of requiring it' should be there... In the cases were some has disabled it, and some requires it, they can't send files in between them, but is that a problem? I think not, it's equally bad for both in the end so...

> >
> > I'm unsure as to the nicest way of avoiding ever revealing
> > the presence
> > of a DC connection by encrypting from the very first packet of a
> > connection, but I would strongly support that.
> > http://l7-filter.sourceforge.net/technicaldetails and
> > http://l7-filter.sourceforge.net/protocols provide insight
> > into what the
> > programs you mention can detect, and thereby means of defeating them.
> > I'm fairly ignorant of the capabilities and limits of the commercial
> > versions.

> Well, as I see it, we simply create an ssl tunnel which is(?)
> indistinguishable from a http ssl tunnel (apart from the fact that the
> connections stays up for a long time...). Ssl in theory might be a bit
> overkill with certificates and all, but since speeds seem ok, that's
> probably the way to go for hubs that want to offer encryption as well...c-
> c encryption is a matter of changing protocol in the ctm, and also there
> ssl fits the profile...
> Trying to make the plaintext protcol look like something else is wasted
> effort imho - at some point we'll be sending data which is unique to our
> protocol, and all it then takes is a patch to the network filter to block
> it...

Off course the plaintext protocol shouldn't be changed, in a try to make it hard to analyse.  Some scrambling in a predefined way could do it though, if necessary. It would at least screw up debugging. Encryption in the hub is a bit more difficult than in c-c. When using normal encryption-styles with key-pairs it could be disastrous. Every client would have its own key-pair, and the hub would need to encrypt every message according to every clients public key... So, there another approach could be necessary. Certificates etc aren't really needed, and if I've understood it right TLS is more or less the 'certificate-less ssl'.
Does anyone have a good picture of how IPSec works btw? Isn't that encryption on a level (IP) that makes it totally transparent for socket implementations? Or is it that it's not supported by all hardware out there, such as routers? It seems too good not to have in mind at this state.

Opera

-- 
DC Developers mailinglist
http://3jane.ashpool.org/cgi-bin/mailman/listinfo/dcdev