This page describes a theoretical model for verifying Primary TCP transactions, due to the overhead of this method it is suggested that this be used only where packet amplification attacks have already been exposed, this covers packets such as the search, search hash and room listing packets.

Let us look at the normal state of things when we send a message to our neighbours to pass our search request along for us.

we make the inital contact..




Our neighbour has been suffering from bogus requests with fake IPs of late so he wants to check we are real, he does this by
firstly sending us a token value for us to reflect back to him, and he sends this token only to our publicly announced IP.




We respond to our neighbour and deliver him back his token, thus proving we are at the IP we claimed and are thus a real network user
Our neighbour is now happy to rebroadcast our requests safe in the knowledge we are real.




The non-neighbour node (ring C) who just recieved the search request is also a suspicious chap and he has the idea that this could be a forged packet, he too wants to verify that it came from a genuine network user, because the guy who passed the traffic to him might be a man-in-the-middle attacker, so he cleverly parses the originator IP address from the packet header and sends the originator a new token value..




The search request originator now replies with the new token value to this non neighbour enquiry, this confirms that B is an honest broker and that I the originator actually exist, the ring C node can now be assured that this is a genuine transaction.




At this stage all looks well but what if the originator and one of his neighbours acted in concert to validate tampered packets ?
To counter this scenario a ring C node will add the IP addresses of both the originator and their neighbour and his own IP in an heavily encrypted form to the packet payload data to prevent normal users from working out who those nodes are, but this will allow the blocklist team to recover this important validated IP data, they would now be able to add any attackers IP to the blocklist with confidence.


Our chap At ring D is also a suspicious chap and he too would like to be reassured that the IP's in usage are genuine but at this late stage contacting the originator would cause a ddos effect due to the number of nodes now involved in this search, what can he do ?

The originator and B as well as C have already proven to each other they are good folks but D has no such confidence in his fellow nodes after all no ones spoken to him, at this stage it becomes clear that we need to move the handshaking routines further out of the centre of things and forget about the originator in the next step, lets see below how the new landscape looks when we move our "shoe" along the path of our network traffic.



The "shoe" has now moved one position ahead and the routine can continue.
As long as the routine is used to cover a limited number of nodes (as is the case in this model) there will be an overall increase in traffic but a lot less traffic than the current attacker is generating and of course we regain the usage of one the key elements of the network topography.