P2P Protocol Detecting and Filtering Algorithm

In this section, we begin to address detection and filtering algorithm of our system.

Before comparison to find signature, first we must define packet payload offset for system to extract required information. When an incoming packet is received, system follows TCP/IP protocol standards to define IP header offset and TCP header offset. Figure 4.4 and Figure 4.5 show the IP header and TCP header.

Figure 4.4 IP datagram.

Figure 4.5 TCP datagram.

From Figure 4.4 it clearly shows that IHL (Internet Header Length) field specifies the length of IP header in 32-bit words, including any options. And it is 4-bit offset from the start

of IP header. From Figure 4.5 it clearly shows Data Offset field specifies where the TCP data begins, because the length of TCP header is variable, this is resulted from Option field value.

So checking Data Offset field from TCP header is required, and it is 13-byte offset from the start of TCP header.

According to the above two fields, the system calculates packet payload offset from the starting of packet. From the literature proposed regarding signatures of P2P protocols or P2P applications, [2], [9], [18], [35], we know most of signatures appear at the beginning of packet payload because P2P protocols let peers communicate with each other through application layer.

Inside the packet payload, for most popular P2P protocols or applications nowadays, signature does not appear at all portion of payload but several bytes from the starting byte. It is not necessary to examine every byte of each incoming packet payload from start to end and we can detect most popular P2P traffic. So for the sake of system utilization we extract only 32 bytes from the starting of packet payload which is stored in DRAM. After identifying the first 32 bytes of packet payload, we copy them from DRAM to SRAM for the purpose of caching. According to Table 2, memory access latency of DRAM is larger than memory access latency of SRAM. After caching the packet payload, we can compare byte by byte between packet payload cache and entries in the signature table.

For detecting P2P traffic, we examine each byte in payload cache from the start to the end. With comparison, first we get an entry from signature table of corresponding microengine. Then the system extracts a byte in turn from start to end and stores in a register.

After extracting a byte from entry of the signature table, the system then extracts a byte in turn from packet payload cache and stores it to another register as that in the above.

Before really detecting P2P traffic, system needs to check the flag field of an entry at first. If the value in flag field is equal to “0x96” then the system does comparison with this entry. If it is not, system jumps to the next entry in order and starts processing another entry.

Once the flag field is on, the system keeps value in signature length field. The value will be kept in a specific register for helping determine whether packets examined is belonging to P2P traffic or not. This value will be decreased to notice the progress of examination while examining packet payload and corresponding signature string in signature table. If the system does not keep this value then system will not be noticed after comparing all bytes of signature string in the signature table.

After preparing bytes for comparison, the system compares two registers from different sources. If two registers have the same value inside, the system will extract next byte from signature string in sequence and extract next byte from packet payload cache. At the same time, system checks whether the value extracted from signature length field is equal to zero or not.

If it is equal to zero then system determines that packet examined is belonging to P2P traffic and exits detection because an incoming packet only belongs to only one P2P protocol or P2P application at any time. If it is not equal to zero then system continues extracting next byte from signature string and next byte from packet payload cache. Finally system decreases the value from signature table by one and repeats the above process.

But if two registers have different values inside then it means that the packet with corresponding packet payload cache examined do not belong to P2P traffic with this signature string. Under this condition, the system will check the packet payload cache with the next entry of signature table. Unless values in the packet payload cache do not match any signature strings in signature table, the corresponding packet will be passed to the followed process and the system examines the next incoming packets.

In our system, there is a global register which can be used by any function in the system called “dl_next_block”. The purpose of this global register is to record which is the next processing stage for a certain packet. In normal condition, dl_next_block register for each incoming packet will be set to “ipv4” after the system received a packet from media interface

and confirmed that it belongs to IPv4 packet. In the original system setting, packets after receiving and corresponding dl_next_block register is set to “ipv4” will be forwarded by the system. To add a functionality to detect P2P traffic, we define a value, “P2P_packet”, additionally in the system to indicate what packets belong to P2P traffic.

In our system, if there is any kind of P2P protocols or P2P applications signatures is found inside an incoming packet, the corresponding dl_next_block register will be set to

“P2P_packet” to warn the system this packet is a P2P packet. We detect P2P traffic by examining whether any signature is included by a packet, then followed by filtering process.

We have mentioned that a normal packet has value “ipv4” in corresponding dl_next_block register. This normal packet will be forwarded by system. In order to achieve the purpose of filtering P2P traffic, we add additional mechanism that checks the value in the dl_next_block before forwarding.

If value inside the dl_next_block is set to “ipv4” then system start to do preparations for forwarding, otherwise system drops current packet instead of forwarding.

Figure 4.6 shows the flow chart of P2P traffic detection and filtering.

Figure 4.6 P2P detection and filtering flow chart.