Nick faking in NMDC

The NMDC protocol contains several usability and security flaws which ADC fixes, including that of failing to unambiguously identify users to each other over client-client connections. As an example of its trivial exploitability under NMDC, this inability to cross-reference client-client and client-hub identifying tokens results in vulnerability to nick-faking.

This dearth of corroboration beyond a potentially ambiguous global nick ensures that no reliable way exists for a standard client to authoritatively confirm or refute a remote client’s ostensible self-identification, and thus to avoid nick-faking. At least four detection methods ameliorate but fail to solve this problem in NMDC: UserIP-based correlations, search result-based correlations, temporal correlations, and depending on the implementation, the simple expedient of asking someone whose nick is being faked if they’re responsible for a given C-C connection. None, however, suffice to create a reliable and secure P2P protocol.

Relying on $UserIP fails both in that no one-to-one mapping between users and IPs necessarily exists and that many hub-owners evince reticence towards distributing such information to users. Even were hub-owners more open to distribution of users’ IPs, or were one to trust nick/IP correlations derived from search results, multiple NAT’d users will appear from the same IP, meaning that though different ISPs imply different users, the converse remains untrue: the two connections having the same IP does not imply that they’re from the same user. These inherent issues with IP-based $UserIP imply continued vulnerability of NMDC, even allowed these methods, to nick-faking.

Not only do IP-based methods leave ambiguity, but intentional cheating, protocol innovation such as upload queuing, and even heavily lagged hubs similarly undermine useful dependency on temporal correlations. Traditionally, DC clients can know what what other users might connect to them because such connections generally occur in response to a $ConnectToMe message. Either a client seeks to upload or download. If seeking to download, standard procedure is to send a $ConnectToMe, which allows for the creation of a list of expected C-C connections which can dramatically narrow possibilities upon reception; if one’s sent a $CTM to user with nick X on hub Y rather than hub Z, then receiving an incoming C-C connection claiming nick X strongly suggests that one’s viewing the user from hub Y and not hub Z.

However, this still can fail – perhaps because hub Y hasn’t relayed the $CTM to the receiving user or because that user does not deign to respond by C-C connection to that message and sometimes because not all C-C connections occur in response to a proximate message at all. Upload queues, for example, can indefinitely delay a C-C response until when a slot actually opens up and thus break mechanisms depending on temporal proximity. Any of these alternative paths to a C-C connection break temporal correlation-based methods.

Finally, combining multiple techniques, including just asking the ostensible other user eliminates, does not eliminate this vulnerability, in the former case because they don’t, taken together, cover even the set of likely possible events and in the latter case because such manual intervention indicates a basic brokenness of a protocol. To find examples, just take the intersections of the sets of counterexamples of each technique, since they operate basically orthogonally – an upload-queuing user behind a NAT breaks both. One can appeal to manual fixes in response to arbitrary protocol flaws – taken to its limit, one can run a DC-like system entirely manually. As such, suggesting to use that tactic is a non-response.

Whilst none of these fixes reliably fixes NMDC, ADC robustly avoids nick-faking in client-client connections by use of the CTM token.

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

3 Responses to Nick faking in NMDC

  1. ghost852 says:

    i dont know anything about all this stuff so i may be totally off by asking this but…i want to know if there is a way to download off of someone within a hub without them being able to see me downloading from them. is this possible? now im not making my own hub or anything like that. im just a regular user, and want to be able to do this. any help you can give me would be appreciated. thank you

  2. Fredrik Ullner says:

    No, that’s not possible, and will not be in the future either.

  3. ghost852 says:

    damn…ok, thanks

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: