Help nedeed (CTM command problem)

[burek 0]

Hi,

I really need some advice on this topic, so if anyone has any suggestions how to resolve the issue, thanks a lot in advance!

The problem is in the way DC clients handle CTM message. For example, take a look at the diagram to better understand the problem.

2 dc clients are connected to the same hub and client Alice (active connection setup) wants to download something from client Bob. So the communication goes like this:

1) Alice > hub

$ConnectToMe Bob 1.2.3.4:56

2) hub > Bob

$ConnectToMe Bob 1.2.3.4:56

3) Bob > Alice (through p2p link)

$MyNick Bob|$Lock ...

4) Alice > Bob (through p2p link)

$MyNick Alice|$Lock ...

This is all great if Alice and Bob are on the same hub. But.. If you link hubs (with any kind of hublink soft) Alice and Bob would have prefixes of their respective hubs and their conversation would most probably look like this: 1) Alice > hub1

$ConnectToMe Hub2:Bob 1.2.3.4:56

1a) hub1 forwards msg to hub2 2) hub2 > Bob

$ConnectToMe Hub2:Bob 1.2.3.4:56

3) Bob > Alice (through p2p link)

$MyNick Bob|$Lock ...

now the following step will not gonna happen.. 4) Alice > Bob (through p2p link)

$MyNick Alice|$Lock ...

Why? Because dc client Alice will check its own hub (Hub1) to see if the nick Bob is on that hub (which is not true), and if not, it will ignore the message. This is the "default" behavior regarding the implementation of NMDC protocol.

How can this be resolved? What can be done so that CTM works across hubs?

If you have ANY ideas, I'm eager to hear them, really and also, thanks in advance for any kind of help. I really appreciate it!

burek.

P.S.

Another approach of hublinking would be to require all nicks to be unique across the entire network, so we wouldn't even have this problem.

Thanks in advance again to whoever helps to resolve this issue.

[Guest Toast]

Think there are some guides on the dcdev blog

http://dcpp.wordpress.com/2007/10/02/nmdcs-client-client-handshake/

http://dcpp.wordpress.com/?s=nmdc

not sure if it helps u not sure why u waste time on nmdc but each to his own

as for fowarding ctms to others hubs im not so sure nmdc is that expendable

http://www.adcportal.com/wiki/index.php/Proposed_Extensions#LINK

however it is in theory possible under ADC if extended proper

Edited October 24, 2009 by Toast

[burek 0]

Hi again,

I've tried to ask DC++ developers to make a simple improvement over the usual CTM msg handling, but they don't seem willing to do so, and, frankly, I don't know why, especially because that change is backward compatible with any older dc client and plus, it improves security a little bit. But it's their project and I can't blame them whatever they decide: https://bugs.launchpad.net/dcplusplus/+bug/461785

Anyway, I must now ask the same question here, if your developers are willing to make that change...

P.S. This is needed only for NMDC protocol, not ADC.

Here is the copy of the proposed solution (a little bit changed, to reflect the real situation):

When any of you find some time to read about this issue, I've found a solution to this problem, that keeps the back compatibility and also improves security a little bit, not to mention it finally allows hubs to link themselves with any kind of hublink software.

The current way of handling CTM messages is (if client A, with ip 1.2.3.4, wants to download something from client B, in active mode):

A -> B: $ConnectToMe A 1.2.3.4:port

B -> A: connection is established directly from B to A and the standard exchange of $MyNick/$Lock occurs

This is, by my opinion, problematic in many ways, because the only way of "authenticating" the incoming connections on client A is to check if nick, supplied by $MyNick, is on that hub, which is actually not very good authentication, because anyone could spoof $MyNick message so that it contains nick of any other user currently connected to the hub. The solution could be to add an additional parameter to $ConnectToMe message (AuthKey / PassPhrase), for example:

A -> B: $ConnectToMe A 1.2.3.4:port <some_random_string_here>

B -> A: p2p connection

connection is established directly from B to A and according to the message received, the standard exchange of $MyNick/$Lock occurs (for older dc clients, to retain back compatibility) or a new way of checking occurs (for newer versions of dc clients), which is actually comparing <some_random_string_here> sent by user B to user A (who generated that string). For example:

A -> B: $ConnectToMe A 1.2.3.4:2222 B447C27A00E3A348881B0030177000CD

B -> A: (through p2p connection) $MyNick B447C27A00E3A348881B0030177000CD|$Lock ...

or some new nmdc message $PassKey, $AuthKey, etc. can be used, instead of using $MyNick.

That way user A is 100% sure that incomming connection is from the desired user, and not from someone else.

I've tested with Verlihub and YnHub so far and found out that modified $ConnectToMe messages all get through the hubs to the user B unchanged.

What does this mean after all. If you decide to extend $ConnectToMe message with just 1 parameter, you would improve the security and you would also allow hublinkig to be easily implemented, while keeping the back compatibility. How?

Here are the 4 cases possible, when extended $CTM msg is implemented.

1. both users have an old version of dc++ client (without extended CTM implemented): the process goes the same way as usual (the old way)

2. user A has a new version and user B has an old version of dc++ client: here, user B will receive an extended $CTM message, but he will simply ignore an additional auth parameter, so the process continues like the usual (the old way)

3. user A has an old version and user B has a new version of dc++ client: user B will detect no additional param in $CTM message so the process will continue as usual (the old way)

4. both users have a new version of dc++ client (with extended CTM implemented): they would establish p2p connection and, instead of sending $MyNick/$Lock, user B can send $MyAuth <additional_param_in_CTM_msg>|$Lock ... and user A will reply the same way

I hope you understand both the need for this and the proposed solution to this problem.

[Guest Toast]

as Poy said not going to happen since the future is with ADC i bet Crise would say the same put focus on ADC instead we gladly accept spec from you if you make it.

The reason why we dont wanna mess with the nmdc code is that in the past implementing stuff under NMDC might open up for problems to arise.

Since the protocol isnt that bendable so your kinda late to enter something into the NMDC "protocol" since most developers are only focusing on ADC these days.

LINK as a proposal isnt accepted yet so you got the doors wide open :whistling:

Edited November 2, 2009 by Toast

[burek 0]

:whistling: it seems like im on my own now..

however, would you mind if i create a new project on sourceforge, based on apexdc++, with this extended feature implemented?

[Guest Toast]

it seems like im on my own now..

however, would you mind if i create a new project on sourceforge, based on apexdc++, with this extended feature implemented?

burek i know your intent is good but why on earth do u want to create a feature for a almost unbendable protocol that can possible be security riddled if done wrong isnt it better to focus on adc like all the developers has told you to do ?

and its open source i cant tell you what not to do but i can say this if it goes wrong your damn sure to hear my war cry first :whistling: