CA2578010A1 - Data network traffic filter and method - Google Patents
Data network traffic filter and method Download PDFInfo
- Publication number
- CA2578010A1 CA2578010A1 CA002578010A CA2578010A CA2578010A1 CA 2578010 A1 CA2578010 A1 CA 2578010A1 CA 002578010 A CA002578010 A CA 002578010A CA 2578010 A CA2578010 A CA 2578010A CA 2578010 A1 CA2578010 A1 CA 2578010A1
- Authority
- CA
- Canada
- Prior art keywords
- ultrapeer
- query
- peer
- filter
- node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
- H04L63/0245—Filtering by information in the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1061—Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
- H04L67/1068—Discovery involving direct consultation or announcement among potential requesting and potential source peers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
- H04L67/1078—Resource delivery mechanisms
- H04L67/1085—Resource delivery mechanisms involving dynamic management of active down- or uploading connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1087—Peer-to-peer [P2P] networks using cross-functional networking aspects
- H04L67/1093—Some peer nodes performing special functions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/101—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measures for digital rights management
Abstract
A traffic filter and filtering method for a decentralized peer-to peer data network is disclosed. A decentralized peer-to-peer data network comprises a number of interconnected ultrapeer nodes, each ultrapeer node being arranged to: accept connections from a number of other leaf and ultrapeer nodes;
maintain a database identifying material available from each connected leaf node; receive search queries from connected leaf nodes and other ultrapeers, forward received search queries to connected ultrapeers and provide data from the database matching a received search query. The traffic filter (40) includes an ultrapeer node (41-43), a filter module (44) and a protected material database (45). Upon receiving a search query the ultrapeer node (41-43) is arranged to pass the query to the filter module (44), the filter module (44) being arranged to analyze the query in dependence on content in the protected material database (45) to determine if the query relates to protected material, the fïlter module (44) being arranged to filter queries relating to protected material and pass non filtered queries to the ultrapeer node (41-43) for subsequent processing.
maintain a database identifying material available from each connected leaf node; receive search queries from connected leaf nodes and other ultrapeers, forward received search queries to connected ultrapeers and provide data from the database matching a received search query. The traffic filter (40) includes an ultrapeer node (41-43), a filter module (44) and a protected material database (45). Upon receiving a search query the ultrapeer node (41-43) is arranged to pass the query to the filter module (44), the filter module (44) being arranged to analyze the query in dependence on content in the protected material database (45) to determine if the query relates to protected material, the fïlter module (44) being arranged to filter queries relating to protected material and pass non filtered queries to the ultrapeer node (41-43) for subsequent processing.
Description
Data Network Traffic Filter and Method Field of the Invention The present invention relates to a data network traffic filter and method that is particularly applicable for use in decentralised peer-to-peer data networks.
Background to the Invention Peer-to-peer (referred to as P2P) data networks are based on a communications model in which each party has the same capabilities and either party can initiate a communication session. In some cases, peer-to-peer communication is implemented by giving each communication node both server and client capabilities. In recent usage, peer-to-peer has come to describe applications in which users can use the Internet to exchange files with each other directly or through a mediating server.
Internet based peer-to-peer networks tend to be transient networks that allow a group of computer users with the same networking program to connect with each other and directly access files from one another's hard drives. Napster and Gnutella are examples of peer-to-peer software.
Each user's machine is referred to as a leaf node within the peer-to-peer network.
Peer-to-peer systems fall into two categories: centralised and decentralised systems.
Centralised systems such as Napster'rely on a central server to provide a database of locations of material (i.e. an IP address of a home user PC, along with the file name of a shared file). The database on the central server is regularly updated according to the material that leaf nodes allow to be shared.
To obtain material, leaf nodes connect to the central server to search its database of material locations and select an entry based on the location or material. Having determined a location, the leaf node then connects to the location to obtain the file.
Decentralised systems do not use a central server. In order to participate in a decentralised peer-to-peer network, a user must first download and execute a peer-to-peer networking program. After launching the program, the user enters the IP address of another computer belonging to the network.
(Typically, the Web page where the user got the download will list several IP
addresses as piaces to begin). Once the computer finds another network member on-line, it will update its list of accessible IP addresses from those held by the network member's PC (who has gotten their IP address list from another user's connection) and so on.
Location of material is determined by propagating search queries from node to node. As this architecture is not particularly efficient, most decentralized systems have evolved to include ultrapeers (also known as Supernodes).
Ultrapeers are other end-user client systems that have been selected, based on factors including system uptime, processing power, bandwidth, and other criteria, to act as such ultrapeer within the P2P network. Ultrapeers are distributed throughout the network so that all leaf nodes connect to the network via a local ultrapeer. Each local ultrapeer maintains a database or cache listing files or items that are available from its respective leaf nodes.
When an end-user performs a search for "Britney Spears", the search query is sent from their respective leaf node to the local ultrapeer to which the client/leaf node is connected. The local ultrapeer returns any results from items referenced in its database that match the search string and also forwards the query to its neighboring ultrapeers, eventually propagating the query throughout the P2P network. If an ultrapeer receives a query and is able to match it to one or more items referenced in its database then sends details of the item to the originating leaf node over the P2P network. If an ultrapeer has seen the query already (the query may be propagated to an ultrapeer via a number of different routes), it is ignored and not forwarded.
Ultrapeers only reply to search queries with positive matches - no reply is sent if no match in the database is found to a query.
Individual ultrapeers do not need to forward search queries down to their local leaf nodes, as they keep and maintain up-to-date cached lists of files that are being shared by the local users.
While corporations are looking at the advantages of using P2P as a way for employees to share files' without the expense involved in maintaining a centralized server and as a way for businesses to exchange information with each other directly, major producers of content, including movie studios and record companies, are extremely concerned about what has become a major use of peer-to-peer networks - the illegal sharing of copyrighted content.
Centralised peer-to-peer networks that have been used to share copyright protected material have largely been shut down due to legal actions concerning copyright infringement by bodies such as'the RIAA and the music industry. The success has been primarily due to the fact that the centralized server is easy to identify and therefore shut down using legal action. Once the central server is shut down, the peer-to-peer network no longer operates.
However, decentralised P2P networks are flourishing. The reason for this is because there is no central server that provides the location details in response to user searches, and every node on the network is effectively a server. In the case of the FastTrack network (which the application KaZaA
uses), it is estimated that there are over 3 million nodes. As ultrapeers are selected from existing leaf nodes and any leaf node could serve as an ultrapeer, merely shutting down a handful of ultrapeers is not effective. It has been found that decentralized peer-to-peer networks cannot be shut down using the legal avenues that proved so successful for centralized peer-to-peer networks.
Statement of Invention According to one aspect of the present invention, there is provided a traffic filter for a decentralised peer-to peer data network, the data network comprising a number of interconnected ultrapeer nodes, each ultrapeer node being arranged to: accept connections from a number of other leaf and ultrapeer nodes; maintain a database identifying material available from each connected leaf node; receive search queries from connected leaf nodes and other ultrapeers, forward received search queries to connected ultrapeers and provide data from the database matching a received search query, the traffic filter including an ultrapeer node, a filter module and a protected material database, wherein upon receiving a search query the ultrapeer node is arranged to pass the query to the filter module, the filter module being arranged to analyse the query in dependence on content in the protected material database to determine if the query relates to protected material, the filter module being arranged to filter queries relating to protected material and pass non-filtered queries to the ultrapeer node for subsequent processing.
Ultrapeers form the very backbone of any decentralised P2P network.
However, decentralised networks have no authoritative systems, and it is possible to insert a machine into the network as an ultrapeer. A traffic filtering system according to an embodiment of the present invention can be inserted as an ultrapeer. Once inserted, the traffic filter is arranged to operate as a conventional ultrapeer. However, all traffic passing through the traffic filter is checked against a predetermined database of protected material. If the traffic is identified as relating to the protected material then that traffic is filtered.
The filtering action can be adjusted as needed but could include not forwarding search queries to neighboring ultrapeers, providing spoof locations in response to search queries, intercepting packets containing the protected material itself and dropping them or replacing them with spoof packets. Not only is traffic to and from leaf nodes filtered but also traffic from other ultrapeer can be filtered. While a single traffic filter may only make marginal difference to the effectiveness of the P2P network, insertion of a number of traffic filters should severely affect the effectiveness of the P2P network to distribute copyright protected materials is severely affected.
Operation as a standard ultrapeer in addition to filtering protected material or queries allows embodiments of the present invention to be deployed, for example in a commercial or corporate environment, so that the full potential of P2P file sharing and the like can be exploited without the potential of a user breaching another's Inteliectual Property rights. In addition, protected material can also be defined as material that is considered confidential or sensitive -in this manner, file sharing can be implemented at a general level in the knowledge that even if a user attempts to share or distribute protected material, such attempts will be filtered and the material protected at source.
From the point of view of the performance of the P2P network, it is also important that ultrapeers act as intended as typically there will be some criterial determining a ratio of ultrapeers to leaf nodes. If a fake system is inserted as an ultrapeer and merely performs filtering of protected material without acting as a normal ultrapeer for non-protected material, the load that that ultrapeer should have carried in running the P2P network would be transferred to the other ultrapeers. Ultimately in such a situation, as the number of fake ultrapeers inserted increases, network performance will decrease until users migrate to another P2P network type.
Whilst the client software operated by leaf nodes in P2P networks has not yet evolved to detect fake ultrapeers or ultrapeers that provide spoofed search results or file locations, it is only a matter of time. Fake ultrapeers will be the easiest to detect as they most likely won't have a searchable database of material available locally and will be unable to allow leaf nodes to directly connect to them to access the P2P network. One suggestion to counter detection is to continually change the Internet Protocol address that identifies the location of the ultrapeer - whilst this may temporarily work it is expected 'that client software will eventually grade the quality of results provided by individual ultrapeers and leaf nodes so that spoofs and filters can be identified and avoided accordingly. Advantageously, embodiments of the present invention will during their life provide both spoofed or otherwise filtered results as well as valid results and will be much harder to detect. In a further embodiment of the present invention, spoofed results may be attributed to another ultrapeer such that any "blame" is avoided and directed to that other, ultrapeer.
Background to the Invention Peer-to-peer (referred to as P2P) data networks are based on a communications model in which each party has the same capabilities and either party can initiate a communication session. In some cases, peer-to-peer communication is implemented by giving each communication node both server and client capabilities. In recent usage, peer-to-peer has come to describe applications in which users can use the Internet to exchange files with each other directly or through a mediating server.
Internet based peer-to-peer networks tend to be transient networks that allow a group of computer users with the same networking program to connect with each other and directly access files from one another's hard drives. Napster and Gnutella are examples of peer-to-peer software.
Each user's machine is referred to as a leaf node within the peer-to-peer network.
Peer-to-peer systems fall into two categories: centralised and decentralised systems.
Centralised systems such as Napster'rely on a central server to provide a database of locations of material (i.e. an IP address of a home user PC, along with the file name of a shared file). The database on the central server is regularly updated according to the material that leaf nodes allow to be shared.
To obtain material, leaf nodes connect to the central server to search its database of material locations and select an entry based on the location or material. Having determined a location, the leaf node then connects to the location to obtain the file.
Decentralised systems do not use a central server. In order to participate in a decentralised peer-to-peer network, a user must first download and execute a peer-to-peer networking program. After launching the program, the user enters the IP address of another computer belonging to the network.
(Typically, the Web page where the user got the download will list several IP
addresses as piaces to begin). Once the computer finds another network member on-line, it will update its list of accessible IP addresses from those held by the network member's PC (who has gotten their IP address list from another user's connection) and so on.
Location of material is determined by propagating search queries from node to node. As this architecture is not particularly efficient, most decentralized systems have evolved to include ultrapeers (also known as Supernodes).
Ultrapeers are other end-user client systems that have been selected, based on factors including system uptime, processing power, bandwidth, and other criteria, to act as such ultrapeer within the P2P network. Ultrapeers are distributed throughout the network so that all leaf nodes connect to the network via a local ultrapeer. Each local ultrapeer maintains a database or cache listing files or items that are available from its respective leaf nodes.
When an end-user performs a search for "Britney Spears", the search query is sent from their respective leaf node to the local ultrapeer to which the client/leaf node is connected. The local ultrapeer returns any results from items referenced in its database that match the search string and also forwards the query to its neighboring ultrapeers, eventually propagating the query throughout the P2P network. If an ultrapeer receives a query and is able to match it to one or more items referenced in its database then sends details of the item to the originating leaf node over the P2P network. If an ultrapeer has seen the query already (the query may be propagated to an ultrapeer via a number of different routes), it is ignored and not forwarded.
Ultrapeers only reply to search queries with positive matches - no reply is sent if no match in the database is found to a query.
Individual ultrapeers do not need to forward search queries down to their local leaf nodes, as they keep and maintain up-to-date cached lists of files that are being shared by the local users.
While corporations are looking at the advantages of using P2P as a way for employees to share files' without the expense involved in maintaining a centralized server and as a way for businesses to exchange information with each other directly, major producers of content, including movie studios and record companies, are extremely concerned about what has become a major use of peer-to-peer networks - the illegal sharing of copyrighted content.
Centralised peer-to-peer networks that have been used to share copyright protected material have largely been shut down due to legal actions concerning copyright infringement by bodies such as'the RIAA and the music industry. The success has been primarily due to the fact that the centralized server is easy to identify and therefore shut down using legal action. Once the central server is shut down, the peer-to-peer network no longer operates.
However, decentralised P2P networks are flourishing. The reason for this is because there is no central server that provides the location details in response to user searches, and every node on the network is effectively a server. In the case of the FastTrack network (which the application KaZaA
uses), it is estimated that there are over 3 million nodes. As ultrapeers are selected from existing leaf nodes and any leaf node could serve as an ultrapeer, merely shutting down a handful of ultrapeers is not effective. It has been found that decentralized peer-to-peer networks cannot be shut down using the legal avenues that proved so successful for centralized peer-to-peer networks.
Statement of Invention According to one aspect of the present invention, there is provided a traffic filter for a decentralised peer-to peer data network, the data network comprising a number of interconnected ultrapeer nodes, each ultrapeer node being arranged to: accept connections from a number of other leaf and ultrapeer nodes; maintain a database identifying material available from each connected leaf node; receive search queries from connected leaf nodes and other ultrapeers, forward received search queries to connected ultrapeers and provide data from the database matching a received search query, the traffic filter including an ultrapeer node, a filter module and a protected material database, wherein upon receiving a search query the ultrapeer node is arranged to pass the query to the filter module, the filter module being arranged to analyse the query in dependence on content in the protected material database to determine if the query relates to protected material, the filter module being arranged to filter queries relating to protected material and pass non-filtered queries to the ultrapeer node for subsequent processing.
Ultrapeers form the very backbone of any decentralised P2P network.
However, decentralised networks have no authoritative systems, and it is possible to insert a machine into the network as an ultrapeer. A traffic filtering system according to an embodiment of the present invention can be inserted as an ultrapeer. Once inserted, the traffic filter is arranged to operate as a conventional ultrapeer. However, all traffic passing through the traffic filter is checked against a predetermined database of protected material. If the traffic is identified as relating to the protected material then that traffic is filtered.
The filtering action can be adjusted as needed but could include not forwarding search queries to neighboring ultrapeers, providing spoof locations in response to search queries, intercepting packets containing the protected material itself and dropping them or replacing them with spoof packets. Not only is traffic to and from leaf nodes filtered but also traffic from other ultrapeer can be filtered. While a single traffic filter may only make marginal difference to the effectiveness of the P2P network, insertion of a number of traffic filters should severely affect the effectiveness of the P2P network to distribute copyright protected materials is severely affected.
Operation as a standard ultrapeer in addition to filtering protected material or queries allows embodiments of the present invention to be deployed, for example in a commercial or corporate environment, so that the full potential of P2P file sharing and the like can be exploited without the potential of a user breaching another's Inteliectual Property rights. In addition, protected material can also be defined as material that is considered confidential or sensitive -in this manner, file sharing can be implemented at a general level in the knowledge that even if a user attempts to share or distribute protected material, such attempts will be filtered and the material protected at source.
From the point of view of the performance of the P2P network, it is also important that ultrapeers act as intended as typically there will be some criterial determining a ratio of ultrapeers to leaf nodes. If a fake system is inserted as an ultrapeer and merely performs filtering of protected material without acting as a normal ultrapeer for non-protected material, the load that that ultrapeer should have carried in running the P2P network would be transferred to the other ultrapeers. Ultimately in such a situation, as the number of fake ultrapeers inserted increases, network performance will decrease until users migrate to another P2P network type.
Whilst the client software operated by leaf nodes in P2P networks has not yet evolved to detect fake ultrapeers or ultrapeers that provide spoofed search results or file locations, it is only a matter of time. Fake ultrapeers will be the easiest to detect as they most likely won't have a searchable database of material available locally and will be unable to allow leaf nodes to directly connect to them to access the P2P network. One suggestion to counter detection is to continually change the Internet Protocol address that identifies the location of the ultrapeer - whilst this may temporarily work it is expected 'that client software will eventually grade the quality of results provided by individual ultrapeers and leaf nodes so that spoofs and filters can be identified and avoided accordingly. Advantageously, embodiments of the present invention will during their life provide both spoofed or otherwise filtered results as well as valid results and will be much harder to detect. In a further embodiment of the present invention, spoofed results may be attributed to another ultrapeer such that any "blame" is avoided and directed to that other, ultrapeer.
Traffic filtering systems according to embodiments of the present invention seek to impact the search functionality that P2P networks and their users rely on to locate and download material (whether protected by Copyright, or otherwise) in a manner that is scalable yet cost effective.
According to another aspect of the present invention, there is provided a method of filtering traffic in a decentralised peer-to peer data network, the data network comprising a number of interconnected ultrapeer nodes, each ultrapeer node being arranged to: accept connections from a number of other leaf and ultrapeer nodes; maintain a database identifying material available from each connected leaf node; receive search queries from connected leaf nodes and other ultrapeers, forward received search queries to connected ultrapeers and provide data from the database matching a received search query, the method comprising:
inserting a node as an ultrapeer node in the peer-to-peer network;
upon receiving a search query at the node, analysing the query in dependence on content in a protected material database to determine if the query relates to protected material; and, filtering the query if it relates to protected material and otherwise acting as a standard ultrapeer and processing the query.
Brief Description of the Drawings Embodiments of the present invention will now be described in detail, by way of example only, with reference to the accompanying drawings in which:
Figure 1 is a schematic diagram of a decentralised peer-to-peer network incorporating a traffic filter according to an embodiment of the present invention;
Figure. 2 is a schematic diagram of a traffic filter according to an embodiment of the present invention; and, Figure 3 is a schematic diagram of a server including a preferred embodiment of the present invention.
According to another aspect of the present invention, there is provided a method of filtering traffic in a decentralised peer-to peer data network, the data network comprising a number of interconnected ultrapeer nodes, each ultrapeer node being arranged to: accept connections from a number of other leaf and ultrapeer nodes; maintain a database identifying material available from each connected leaf node; receive search queries from connected leaf nodes and other ultrapeers, forward received search queries to connected ultrapeers and provide data from the database matching a received search query, the method comprising:
inserting a node as an ultrapeer node in the peer-to-peer network;
upon receiving a search query at the node, analysing the query in dependence on content in a protected material database to determine if the query relates to protected material; and, filtering the query if it relates to protected material and otherwise acting as a standard ultrapeer and processing the query.
Brief Description of the Drawings Embodiments of the present invention will now be described in detail, by way of example only, with reference to the accompanying drawings in which:
Figure 1 is a schematic diagram of a decentralised peer-to-peer network incorporating a traffic filter according to an embodiment of the present invention;
Figure. 2 is a schematic diagram of a traffic filter according to an embodiment of the present invention; and, Figure 3 is a schematic diagram of a server including a preferred embodiment of the present invention.
Detailed Description Figure 1 is a schematic diagram of a decentralised peer-to-peer network incorporating a traffic filter according to an embodiment of the present invention.
The peer-to-peer network 10 includes a number of leaf nodes 20 each connected to a respective ultrapeer node 30.
When a traffic filter 40 according to an embodiment of the present invention connects to the peer-to-peer network 10, it inserts itself as an ultrapeer and allows leaf nodes 20 and other ultrapeers 30 to connect to it.
When a leaf node 20 that is connected directly to the traffic filter 40 issues a search query to locate, and eventually download, material the search string is processed by the traffic filter. Processing includes analysing the search query string against a list of strings that correspond to predetermined protected material. Such strings could include artist names, publishers/distributors, song or film titles or other metadata such as hashes from which protected material can be identified. If the search query string analysis matches the search string query to an. entry in the list, the traffic filter returns one or more false results. The analysis may include heuristic, semantic or other forms of analysis to identify incorrectly spelt search query strings and attempts to avoid the filtering operation.
If the search query string analysis does not match the search query string then the traffic filter acts as a regular ultrapeer by forwarding the query to its neighboring ultrapeers and also searching for matches to the query in a database identifying material stored by leaf nodes connected to the traffic filter.
The filtering of search query strings is applied to queries from local leaf nodes and also search query strings forwarded by neighboring ultrapeers.
The peer-to-peer network 10 includes a number of leaf nodes 20 each connected to a respective ultrapeer node 30.
When a traffic filter 40 according to an embodiment of the present invention connects to the peer-to-peer network 10, it inserts itself as an ultrapeer and allows leaf nodes 20 and other ultrapeers 30 to connect to it.
When a leaf node 20 that is connected directly to the traffic filter 40 issues a search query to locate, and eventually download, material the search string is processed by the traffic filter. Processing includes analysing the search query string against a list of strings that correspond to predetermined protected material. Such strings could include artist names, publishers/distributors, song or film titles or other metadata such as hashes from which protected material can be identified. If the search query string analysis matches the search string query to an. entry in the list, the traffic filter returns one or more false results. The analysis may include heuristic, semantic or other forms of analysis to identify incorrectly spelt search query strings and attempts to avoid the filtering operation.
If the search query string analysis does not match the search query string then the traffic filter acts as a regular ultrapeer by forwarding the query to its neighboring ultrapeers and also searching for matches to the query in a database identifying material stored by leaf nodes connected to the traffic filter.
The filtering of search query strings is applied to queries from local leaf nodes and also search query strings forwarded by neighboring ultrapeers.
Figure 2 is a schematic diagram of a traffic filter according to an embodiment of the present invention The traffic filter 40 includes a number of communication modules 41, 42, 43, a filter module 44, and a protected material database 45.
Each communication module 41, 42, 43 allows the traffic filter to connect to a respective peer-to-peer network type and operate as an ultrapeer in that network. Although there are minor protocol and packet format differences between the various peer-to-peer network types in existence, search query analysis and traffic filtering operates in the same manner. The different communication modules 41-43 handle the coding and decoding of communication packets for the respective network type in accordance with its respective protocol and formats while filter module 44 handles search query analysis and filtering for all network types.
In this embodiment, communication module 41 is connected to the FastTrack peer-to-peer network, communication module 42 is connected to the Gnutella peer-to-peer network and communication module 43 is connected to the Overnet 'peer-to-peer network. Each communication module deals with insertion into the resepective network as an ultrapeer, handling of general communications (such as answering pings to confirm the node is still active) and receives communication packets for the ultrapeer.
Upon receipt of a communications packet, the communications module extracts the content from the packet and passes this to the filter module 44.
The filter module 44 analyses the content, searching for matches or near matches to entries within the protected material database 45 in a manner as discussed above. If a match or near match is found, depending on the programming of the filter the respective communications module is instructed to drop the packet and make no reply-or reply with erroneous data. The erroneous data may be a report of material matching the search result but indicating an incorrect IP address for the material. If no match or near match is found then the respective communications module is instructed to act as a standard ultrapeer. Actions taken as a standard ultrapeer may include forwarding the query to neighboring ultrapeers and searching for matches to the query in a database identifying material stored by leaf nodes connected to the traffic filter.
Taking communications module 42 as an example, the process of insertion into the Gnutella network as an ultrapeer and subsequent operation will be described.
The module 42 which connects to a predetermined list of known Gnutella ultrapeers and establishes an ultrapeer-ultrapeer connection with each.
Gnutella services can run on any TCP port, and so it is the traffic that is sent which is important.
Inserting into the network as an ultrapeer involves establishing a connection with another ultrapeer using the 'GNUTELLA CONNECT' command with 'X-ultrapeer: True'.
Once inserted as an ultrapeer, traffic is received including:
- Query (type 0x80) packets - search queries from leaf nodes - QueryHit (type 0x81) packets - responses to search queries from ultrapeers identifying the location of material satisfying a received search query Other network management traffic is also received, including Ping and Pong traffic from other ultrapeers that are sent to ensure the traffic filter (acting as an ultrapeer) is operational and accessible.
In Gnutella, query packets are simple text-based search packets that are propagated throughout the Gnutella network from leaf nodes using ultrapeer nodes.
The text-based query traffic is filtered by the filter module 44 to prevent inappropriate queries being answered or forwarded. Upon receiving a query with a word identified by database 45 as being banned (such as Britney, Madonna, or a trademark), the query is dropped and not forwarded to any of the other neighboring ultrapeers.
QueryHit traffic are results from outbound searches that have been succcessfully propogated. QueryHit packets contain a number of pieces of information including:
- IP address of the user sharing the file - File name - File size - XML meta-data Gnuteiia 0.4 does not support downloading from multiple sources, and so hash data is not used either in query or QueryHit packets.
QueryHit packets can also be filtered, in particular:
- File name - XML meta-data If the file name or XML meta-data for that file contains words identified by database 45 as being banned (trademarks, artist names, etc.), the QueryHit is dropped and not forwarded to any of the other node (ultrapeer, or leaf nodes).
In some implementations, false QueryHit data may be sent instead of dropping the packet. This is done by taking the QueryHit packet, and modifying the IP address of the user sharing the file, or any other details.
By changing the IP address information, the leaf node from where the search originated will not be able to download the file.
Because the Gnutella ultrapeer software runs actively on the Gnutella network, it also accepts direct connections from leaf nodes. Query and QueryHit data is filtered in the same way.
Figure 3 is a schematic diagram of a server including a preferred embodiment of the present invention.
The server 50 includes a number of traffic filters 40 operating in the same manner as has been discussed above with reference to Figures 1 and 2.
Each traffic filter 40 is assigned a respective associated IP address for use in communicating with its peer-to-peer networks and operates as a self-contained entity. However, a single prohibited material database 45 is maintained and shared by all of the traffic filters 40. The configuration of each traffic filter may be the same or different - they each may drop packets with prohibited content or replace them with falsified data. This action may be randomly selected, pre-programmed into the traffic filter or may be selected in dependence on the particular content. Similarly, each traffic filter may connect via communication modules to the same peer-to-peer networks or to different ones. From the outside world, the server appears to be a large number of ultrapeers. If each illustrated traffic filter 40 has 3 communication modules 41-43 then to the outside world the server 50 would appear to be 36 individual ultrapeer. If each ultrapeer was to have just 10 leaf nodes connected to it, the traffic of 360 leaf nodes in addition to that received from neighboring ultrapeers could be filtered in an extremely cost effective manner.
Although the traffic filters could be implemented as electronic circuits, it is preferred that each traffic filter is software run on the server, the number of traffic filters being limited only by the capabilities of the server and the number of available IP addresses.
Although the embodiments discussed above have been with reference to particular peer-to-peer network types, it will be appreciated that the present invention is applicable to all peer-to-peer network types. In addition, although traffic filters have been illustrated with communication modules connected to FastTrack, Gnutella and Overnet networks, communication modules could be connected to other networks and a traffic filter may include more or less communication modules depending on the implementation. For example on a high traffic network, a single communications module may be connected to a filter module whilst in lower traffic modules, many more communications modules may share the same filter module.
Each communication module 41, 42, 43 allows the traffic filter to connect to a respective peer-to-peer network type and operate as an ultrapeer in that network. Although there are minor protocol and packet format differences between the various peer-to-peer network types in existence, search query analysis and traffic filtering operates in the same manner. The different communication modules 41-43 handle the coding and decoding of communication packets for the respective network type in accordance with its respective protocol and formats while filter module 44 handles search query analysis and filtering for all network types.
In this embodiment, communication module 41 is connected to the FastTrack peer-to-peer network, communication module 42 is connected to the Gnutella peer-to-peer network and communication module 43 is connected to the Overnet 'peer-to-peer network. Each communication module deals with insertion into the resepective network as an ultrapeer, handling of general communications (such as answering pings to confirm the node is still active) and receives communication packets for the ultrapeer.
Upon receipt of a communications packet, the communications module extracts the content from the packet and passes this to the filter module 44.
The filter module 44 analyses the content, searching for matches or near matches to entries within the protected material database 45 in a manner as discussed above. If a match or near match is found, depending on the programming of the filter the respective communications module is instructed to drop the packet and make no reply-or reply with erroneous data. The erroneous data may be a report of material matching the search result but indicating an incorrect IP address for the material. If no match or near match is found then the respective communications module is instructed to act as a standard ultrapeer. Actions taken as a standard ultrapeer may include forwarding the query to neighboring ultrapeers and searching for matches to the query in a database identifying material stored by leaf nodes connected to the traffic filter.
Taking communications module 42 as an example, the process of insertion into the Gnutella network as an ultrapeer and subsequent operation will be described.
The module 42 which connects to a predetermined list of known Gnutella ultrapeers and establishes an ultrapeer-ultrapeer connection with each.
Gnutella services can run on any TCP port, and so it is the traffic that is sent which is important.
Inserting into the network as an ultrapeer involves establishing a connection with another ultrapeer using the 'GNUTELLA CONNECT' command with 'X-ultrapeer: True'.
Once inserted as an ultrapeer, traffic is received including:
- Query (type 0x80) packets - search queries from leaf nodes - QueryHit (type 0x81) packets - responses to search queries from ultrapeers identifying the location of material satisfying a received search query Other network management traffic is also received, including Ping and Pong traffic from other ultrapeers that are sent to ensure the traffic filter (acting as an ultrapeer) is operational and accessible.
In Gnutella, query packets are simple text-based search packets that are propagated throughout the Gnutella network from leaf nodes using ultrapeer nodes.
The text-based query traffic is filtered by the filter module 44 to prevent inappropriate queries being answered or forwarded. Upon receiving a query with a word identified by database 45 as being banned (such as Britney, Madonna, or a trademark), the query is dropped and not forwarded to any of the other neighboring ultrapeers.
QueryHit traffic are results from outbound searches that have been succcessfully propogated. QueryHit packets contain a number of pieces of information including:
- IP address of the user sharing the file - File name - File size - XML meta-data Gnuteiia 0.4 does not support downloading from multiple sources, and so hash data is not used either in query or QueryHit packets.
QueryHit packets can also be filtered, in particular:
- File name - XML meta-data If the file name or XML meta-data for that file contains words identified by database 45 as being banned (trademarks, artist names, etc.), the QueryHit is dropped and not forwarded to any of the other node (ultrapeer, or leaf nodes).
In some implementations, false QueryHit data may be sent instead of dropping the packet. This is done by taking the QueryHit packet, and modifying the IP address of the user sharing the file, or any other details.
By changing the IP address information, the leaf node from where the search originated will not be able to download the file.
Because the Gnutella ultrapeer software runs actively on the Gnutella network, it also accepts direct connections from leaf nodes. Query and QueryHit data is filtered in the same way.
Figure 3 is a schematic diagram of a server including a preferred embodiment of the present invention.
The server 50 includes a number of traffic filters 40 operating in the same manner as has been discussed above with reference to Figures 1 and 2.
Each traffic filter 40 is assigned a respective associated IP address for use in communicating with its peer-to-peer networks and operates as a self-contained entity. However, a single prohibited material database 45 is maintained and shared by all of the traffic filters 40. The configuration of each traffic filter may be the same or different - they each may drop packets with prohibited content or replace them with falsified data. This action may be randomly selected, pre-programmed into the traffic filter or may be selected in dependence on the particular content. Similarly, each traffic filter may connect via communication modules to the same peer-to-peer networks or to different ones. From the outside world, the server appears to be a large number of ultrapeers. If each illustrated traffic filter 40 has 3 communication modules 41-43 then to the outside world the server 50 would appear to be 36 individual ultrapeer. If each ultrapeer was to have just 10 leaf nodes connected to it, the traffic of 360 leaf nodes in addition to that received from neighboring ultrapeers could be filtered in an extremely cost effective manner.
Although the traffic filters could be implemented as electronic circuits, it is preferred that each traffic filter is software run on the server, the number of traffic filters being limited only by the capabilities of the server and the number of available IP addresses.
Although the embodiments discussed above have been with reference to particular peer-to-peer network types, it will be appreciated that the present invention is applicable to all peer-to-peer network types. In addition, although traffic filters have been illustrated with communication modules connected to FastTrack, Gnutella and Overnet networks, communication modules could be connected to other networks and a traffic filter may include more or less communication modules depending on the implementation. For example on a high traffic network, a single communications module may be connected to a filter module whilst in lower traffic modules, many more communications modules may share the same filter module.
Claims (15)
1. A traffic filter for a decentralised peer-to peer data network, the data network comprising a number of interconnected ultrapeer nodes, each ultrapeer node being arranged to: accept connections from a number of other leaf and ultrapeer nodes; maintain a database identifying material available from each connected leaf node; receive search queries from connected leaf nodes and other ultrapeers, forward received search queries to connected ultrapeers and provide data from the database matching a received search query, the traffic filter including an ultrapeer node, a filter module and a protected material database, wherein upon receiving a search query the ultrapeer node is arranged to pass the query to the filter module, the filter module being arranged to analyse the query in dependence on content in the protected material database to determine if the query relates to protected material, the filter module being arranged to filter queries relating to protected material and pass non-filtered queries to the ultrapeer node for subsequent processing.
2. A traffic filter as claimed in claim 1, wherein the filter module is arranged to filter a query by dropping the query.
3. A traffic filter as claimed in claim 1, wherein the filter module is arranged to filter a query by responding with erroneous data.
4. A traffic filter as claimed in claim 3, wherein the filter module is arranged to attribute the erroneous data to another ultrapeer in the peer-to-peer network.
5. A traffic filter as claimed in any preceding claim comprising a plurality of ultrapeer nodes arranged to pass received queries to the filter module.
6. A traffic filter as claimed in claim 4, wherein one or more of the ultrapeer nodes is connected to a different peer-to-peer network.
7. A traffic filter as claimed in any preceding claim, wherein the protected material database includes content on commercially sensitive or confidential material that is not to be shared.
8. A server including a plurality of traffic filters as claimed in any of the preceding claims.
9. A method of filtering traffic in a decentralised peer-to peer data network, the data network comprising a number of interconnected ultrapeer nodes, each ultrapeer node being arranged to: accept connections from a number of other leaf and ultrapeer nodes; maintain a database identifying material available from each connected leaf node; receive search queries from connected leaf nodes and other ultrapeers, forward received search queries to connected ultrapeers and provide data from the database matching a received search query, the method comprising:
inserting a node as an ultrapeer node in the peer-to-peer network;
upon receiving a search query at the node, analysing the query in dependence on content in a protected material database to determine if the query relates to protected material; and, filtering the query if it relates to protected material and otherwise acting as a standard ultrapeer and processing the query.
inserting a node as an ultrapeer node in the peer-to-peer network;
upon receiving a search query at the node, analysing the query in dependence on content in a protected material database to determine if the query relates to protected material; and, filtering the query if it relates to protected material and otherwise acting as a standard ultrapeer and processing the query.
10. A method as claimed in claim 9, wherein the step of filtering comprises dropping the query.
11. A method as claimed in claim 9, wherein the step of filtering comprises responding with erroneous data.
12. A method as claimed in claim 11, wherein the step of responding with erroneous data includes attributing the erroneous data to another ultrapeer in the peer-to-peer network.
13 13. A method as claimed in any of claims 9 to 11, further comprising identifying commercially sensitive or confidential material that is not to be shared in the protected material database.
14. A computer program comprising computer program code means for performing all of the steps of any of claims 9 to 13 when said program is run on a computer.
15. A computer program as claimed in claim 14 embodied on a computer readable medium.
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB0418783.7 | 2004-08-23 | ||
| GB0418783A GB2422214B (en) | 2004-08-23 | 2004-08-23 | Data network traffic filter |
| US11/028,733 | 2005-01-05 | ||
| US11/028,733 US20060039297A1 (en) | 2004-08-23 | 2005-01-05 | Data network traffic filter and method |
| PCT/GB2005/003274 WO2006021772A1 (en) | 2004-08-23 | 2005-08-23 | Data network traffic filter and method |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2578010A1 true CA2578010A1 (en) | 2006-03-02 |
Family
ID=35447595
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002578010A Abandoned CA2578010A1 (en) | 2004-08-23 | 2005-08-23 | Data network traffic filter and method |
Country Status (3)
| Country | Link |
|---|---|
| EP (1) | EP1787452A1 (en) |
| CA (1) | CA2578010A1 (en) |
| WO (1) | WO2006021772A1 (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2903512B1 (en) | 2006-07-10 | 2008-10-10 | Trident Media Guard Tmg Sa | METHOD FOR CONTROLLING THE ILLICIT DIFFUSION OF PROTECTED WORKS AND COMPUTER SYSTEM FOR IMPLEMENTING A METHOD |
| CN101399739B (en) * | 2007-09-28 | 2011-03-30 | 华为技术有限公司 | Method, system and device for coverage network interconnection implementation |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7627897B2 (en) * | 2001-01-03 | 2009-12-01 | Portauthority Technologies Inc. | Method and apparatus for a reactive defense against illegal distribution of multimedia content in file sharing networks |
| US7363278B2 (en) * | 2001-04-05 | 2008-04-22 | Audible Magic Corporation | Copyright detection and protection system and method |
-
2005
- 2005-08-23 WO PCT/GB2005/003274 patent/WO2006021772A1/en active Application Filing
- 2005-08-23 CA CA002578010A patent/CA2578010A1/en not_active Abandoned
- 2005-08-23 EP EP05773179A patent/EP1787452A1/en not_active Withdrawn
Also Published As
| Publication number | Publication date |
|---|---|
| EP1787452A1 (en) | 2007-05-23 |
| WO2006021772A1 (en) | 2006-03-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Naoumov et al. | Exploiting p2p systems for ddos attacks | |
| Hughes et al. | Free riding on Gnutella revisited: the bell tolls? | |
| US7761569B2 (en) | Method for monitoring and providing information over a peer to peer network | |
| Liang et al. | Pollution in P2P file sharing systems | |
| US7990870B2 (en) | Peer-to-peer traffic management based on key presence in peer-to-peer control transfers | |
| Brunner et al. | A performance evaluation of the Kad-protocol | |
| CN102148854B (en) | Method and device for identifying peer-to-peer (P2P) shared flows | |
| CA2644731A1 (en) | Method and communication system for the computer-aided detection and identification of copyrighted contents | |
| Liang et al. | Efficient blacklisting and pollution-level estimation in P2P file-sharing systems | |
| Montassier et al. | Content pollution quantification in large P2P networks: A measurement study on KAD | |
| US7565405B2 (en) | Method and apparatus for providing data storage in peer-to-peer networks | |
| US8935240B2 (en) | Method and apparatus for automated end to end content tracking in peer to peer environments | |
| US20060039297A1 (en) | Data network traffic filter and method | |
| Sunaga et al. | Technical trends in P2P-based communications | |
| CA2578010A1 (en) | Data network traffic filter and method | |
| US9385992B2 (en) | Inline key-based peer-to-peer processing | |
| Lee et al. | Advanced node insertion attack with availability falsification in Kademlia-based P2P networks | |
| Jia et al. | Spam characterization and detection in peer-to-peer file-sharing systems | |
| Soldani | Peer-to-peer behaviour detection by TCP flows analysis | |
| Jia | Cost-effective spam detection in P2P file-sharing systems | |
| Kak | Lecture 25: Structured Peer-to-Peer Networks and Their Security Issues | |
| CA2534397C (en) | Method for monitoring and providing information over a peer to peer network | |
| AU2012201512B2 (en) | Method for monitoring and providing information over a peer to peer network | |
| Perera et al. | Broadcast Updates with Local Look-up Search (BULLS) a new peer-to-peer protocol | |
| Heimann | Distributed Hash Table (DHT) and Peer-to-Peer |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |