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

Definitions

• 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.
• 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.
• peer-to- peer communication is implemented by giving each communication node both server and client capabilities.
• 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.
• 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.
• the Web page where the user got the download will list several IP addresses as places to begin).
• 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.
• 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.
• 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.
• 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.
• the FastTrack network which the application KaZaA uses
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• a method of filtering traffic in a decentralised peer-to peer 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.
• 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.
• FIG. 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.
• a traffic filter 40 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.
• 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.
• 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.
• FIG. 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.
• communication module 41 is connected to the FastTrack peer-to-peer network
• communication module 42 is connected to the Gnutella peer-to-peer network
• 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.
• the communications module 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.
• communications module 42 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 1 command with 'X- ultrapeer: True'.
• traffic is received including: - Query (type 0x80) packets - search queries from leaf nodes
• 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.
• 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.
• 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 successfully propogated.
• QueryHit packets contain a number of pieces of information including:
• Gnutella 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:
• 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).
• 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.
• 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.
• FIG 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.
• 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.
• each traffic filter may connect via communication modules to the same peer-to-peer networks or to different ones.
• 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.
• 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.
• 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.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer Security & Cryptography (AREA)
• Computing Systems (AREA)
• Computer Hardware Design (AREA)
• General Engineering & Computer Science (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
• Computer And Data Communications (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=35447595

Family Applications (1)

Country Status (3)

Families Citing this family (2)

Family Cites Families (2)

• 2005
  • 2005-08-23 EP EP05773179A patent/EP1787452A1/de not_active Withdrawn
  • 2005-08-23 CA CA002578010A patent/CA2578010A1/en not_active Abandoned
  • 2005-08-23 WO PCT/GB2005/003274 patent/WO2006021772A1/en active Application Filing

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events