WO2024105892A1

WO2024105892A1 - Conversion device, conversion method, and conversion program

Info

Publication number: WO2024105892A1
Application number: PCT/JP2022/042930
Authority: WO
Inventors: 千晴森岡; 裕平林; 晶規古田; 里美井上; 篤史須藤
Original assignee: 日本電信電話株式会社
Priority date: 2022-11-18
Filing date: 2022-11-18
Publication date: 2024-05-23

Abstract

A conversion device according to an embodiment assesses, on the basis of a L2 header, a L3 header, a L4 header, and a xFlow header that are included in a xFlow packet, whether the xFlow packet is an object to be processed for protocol analysis or format conversion. The conversion device then performs protocol analysis and furthermore performs format conversion on the xFlow packet that has been assessed to be an object to be processed.

Description

CONVERSION DEVICE, CONVERSION METHOD, AND CONVERSION PROGRAM

The present invention relates to a conversion device, a conversion method, and a conversion program.

　Conventionally, xFlow technology is known, which samples packets and transfers the header portion of the packets themselves (header samples) to aggregate and analyze traffic.

In addition, a format conversion technology is known that analyzes the packet header information inside and outside the capsule to identify packets received as RAW packets, header samples, or xFlow packets, and enables different processing or analysis for each attribute, such as group.

JP 2019-097069 A JP 2021-090161 A International Publication No. 2021/149245 JP 2020-174257 A

However, conventional technology has the problem that analyzing packet headers requires a large processing load.

For example, a conversion device that performs the format conversion described in Patent Document 3 may receive xFlow packets whose xFlow header field configurations differ depending on the model of the source NW (Network) device, even if the xFlow type (IPFIX, NetFlow, etc.) is the same. When analyzing such xFlow packets, processing to detect the position of the encapsulated packet from the beginning of the xFlow packet and header analysis, etc. are required, which increases the processing load of the conversion device.

The present invention has been made in consideration of the above, and aims to reduce the processing load required to analyze packet headers.

In order to solve the above-mentioned problems and achieve the object, the conversion device according to the present invention is characterized by having a determination unit that determines whether an xFlow packet is to be processed based on the L2 header, L3 header, L4 header, and xFlow header contained in the xFlow packet, and an analysis unit that analyzes the xFlow packet that is determined by the determination unit to be to be processed.

The present invention can reduce the processing load required to analyze packet headers.

FIG. 1 is a block diagram illustrating an example of a configuration of a communication system according to an embodiment. FIG. 2 is a diagram illustrating the flow of processing in the conversion device. FIG. 3 is a block diagram showing an example of the configuration of a conversion device. FIG. 4 is a diagram illustrating an example of an xFlow packet. FIG. 5 is a diagram illustrating an example of the template rule table. FIG. 6 is a diagram illustrating an example of the transmission filter table. FIG. 7 is a flowchart showing the flow of processing by the conversion device. FIG. 8 is a flowchart showing the flow of the transmission filter process. FIG. 9 is a diagram for explaining a procedure for updating the transparent filter table. FIG. 10 is a diagram showing an example of rewriting the xFlow header. FIG. 11 is a diagram illustrating an example of a computer that realizes a conversion device by executing a program.

Below, the embodiments of the conversion device, conversion method, and conversion program according to the present application are described in detail with reference to the drawings. Furthermore, the present invention is not limited to the embodiments described below.

[First embodiment]
The converter of the present embodiment performs protocol analysis and format conversion on xFlow packets having characteristics that are predetermined as targets of format conversion. On the other hand, there are cases where an encapsulated packet that is not a target of format conversion is input to the converter.

The conversion device has a function for determining whether a received encapsulated packet is an xFlow packet that is subject to format conversion. Furthermore, the conversion device reduces the processing load in protocol analysis and format conversion by rewriting the field configuration (hereinafter sometimes referred to as the header pattern) of the header (hereinafter sometimes referred to as the xFlow header) of an xFlow packet that is determined to be subject to format conversion.

[Configuration of communication system]
Fig. 1 is a block diagram showing an example of a configuration of a communication system according to an embodiment. As shown in Fig. 1, the communication system 1 according to the embodiment includes a plurality of network devices 2, a conversion device 10, and a plurality of analysis devices 3. For example, the plurality of network devices 2 and the conversion device 10 communicate with each other via a network N. Note that the configuration shown in Fig. 1 is merely an example, and the specific configuration and the number of each device are not limited to those shown in the figure.

The network device 2 samples packets in the traffic to be monitored. The network device 2 transfers xFlow packets that encapsulate the sampled packet header samples to the conversion device 10. In the network device 2, a sample template and an option template are defined in advance as templates for xFlow packets. The network device 2 is configured to send xFlow packets to the UDP port of the conversion device 10 that corresponds to the xFlow header pattern defined in the network device 2. The network device 2 can transfer statistical information on flows, such as the number of packets, to the conversion device 10 together with the xFlow packets to be transferred, or as separate xFlow packets. In addition to xFlow packets, the network device 2 can transfer mirrored encapsulated packets to the conversion device 10.

The analysis device 3 analyzes the traffic. For example, the analysis device 3 uses statistical information contained in the xFlow packets received from the conversion device 10 to count packets in the traffic to be monitored.

The conversion device 10 converts the xFlow packets received from the network device 2 into xFlow packets in a format that corresponds to the processing content of the analysis device 3. The conversion device 10 pre-sets the UDP port for receiving xFlow packets from the network device 2 for each xFlow header pattern. This makes it possible to identify the xFlow header pattern based on the UDP dst port of the xFlow packets received from the network device 2.

Here, we will explain the process flow of the conversion device 10 using Figure 2. Figure 2 is a diagram that explains the process flow in the conversion device.

As shown in FIG. 2, the conversion device 10 receives the mirrored encapsulated packet and an xFlow packet including a header sample of the packet from the network device 2.

As shown in Figure 2, the mirrored encapsulated packet includes an outer packet header and an inner packet header. Also, the xFlow packet includes the packet header of the xFlow packet in addition to the outer packet header and inner packet header.

First, the conversion device 10 performs a packet transparency determination for the received xFlow packet (step S1). Here, the conversion device 10 determines that the xFlow packet that matches the template is subject to format conversion, and passes it on to the next process.

Next, the conversion device 10 rewrites the packet headers of the xFlow packets that are determined to be subject to format conversion during the pass-through determination (step S2).

Furthermore, the conversion device 10 identifies the header information of the xFlow packet (the outer packet header, the inner packet header, and the packet header of the xFlow packet) through protocol analysis (step S3).

Then, the conversion device 10 groups the xFlow packets based on conditions related to the identified header information (step S4).

Then, the conversion device 10 performs information shaping defined for each group (step S5). For example, for xFlow packets classified into group "#1", the conversion device 10 performs inner statistical processing to obtain statistics on the inner packet header. For xFlow packets classified into group "#2", the conversion device 10 performs outer statistical processing to obtain statistics on the outer header. For xFlow packets classified into group "#3", the conversion device 10 performs header deletion to delete the outer header.

The conversion device 10 transmits the xFlow packet after performing information shaping to a specified destination. The destination is, for example, the analysis device 3. "xFlow analysis device A", "xFlow analysis device B", and "packet capture device C" in Figure 2 are examples of the analysis device 3.

[Configuration of conversion device]
Next, the configuration of the conversion device 10 will be described with reference to Fig. 3. Fig. 3 is a block diagram showing an example of the configuration of the conversion device. As shown in Fig. 2, the conversion device 10 includes a communication unit 11, a storage unit 12, and a control unit 13.

The communication unit 11 is an interface for transmitting and receiving data between other devices (e.g., the network device 2 and the analysis device 3). For example, the communication unit 11 is a network interface card (NIC).

Here, we will use Figure 4 to explain the xFlow packets that the communication unit 11 receives from the network device 2. Figure 4 is a diagram showing an example of an xFlow packet.

The communication unit 11 receives Data packets and Template packets as xFlow packets. Furthermore, the Data packets include Sample Data packets and Option Data packets. Furthermore, the Template packets include Sample Template packets and Option Template packets.

The Sample Data portion of a Sample Data packet contains one or more packet headers of an encapsulated packet. Also, Sample Template packets and Option Template packets are templates for Sample Data packets and Option Data packets, respectively.

Sample Data packets, Option Data packets, Sample Template packets, and Option Template packets all contain an xFlow header in addition to the L2 header (Ether), L3 header (IP), and L4 header (UDP) of an xFlow packet. In other words, the xFlow header is included in the packet header of the xFlow packet.

The conversion device 10 can distinguish between Sample Template packets, Option Template packets, and Data packets (Sample Data packets or Option Data packets) from the Set ID value in the xFlow header. The method by which the conversion device 10 distinguishes between packets will be described later.

The storage unit 12 is a storage device such as a hard disk drive (HDD), a solid state drive (SSD), or an optical disk. Note that the storage unit 12 may also be a semiconductor memory in which data can be rewritten, such as a random access memory (RAM), a flash memory, or a non-volatile static random access memory (NVSRAM).

The storage unit 12 stores data related to the OS (Operating System) and various programs executed by the conversion device 10. For example, the storage unit 12 stores a template rule table 121 and a transparent filter table 122.

The template rule table 121 is used to create the transparent filter table 122. The transparent filter table 122 is also used to determine whether an xFlow packet is transparent. The template rule table 121 and the transparent filter table 122 are set in advance before the xFlow packet is determined to be transparent.

FIG. 5 shows an example of a template rule table. In this embodiment, it is assumed that xFlow packets are sent and received using IPv4. However, the protocol for sending and receiving xFlow packets is not limited to IPv4 and may be, for example, IPv6.

Here, in the conversion device 10, the receiving UDP port is preset for each header pattern of the xFlow packet. Also, in the network device 2, a sample template and an option template are predefined as templates for the xFlow packet. The template rule table 121 is created based on the set UDP port and the defined template.

As shown in FIG. 5, the template rule table 121 includes items such as "Src IP", "Dst UDP Port", "Obs ID (Observation Domain ID)", "Sample Template ID", and "Option Template ID".

The "Src IP" item is the IP address of the network device 2 that is the sender of the xFlow packet. The "Dst UDP Port" item is the receiving UDP port for each header pattern set in the conversion device 10, and is the UDP dst port of the xFlow packet to be received. The "Obs ID (Observation Domain ID)" item, the "Sample Template ID" item, and the "Option Template ID" item are information included in the xFlow header, and are defined as templates (Sample Template and Option Template).

For example, Figure 5 shows a row where "Src IP" is "192.168.1.1/32", "Dst UDP Port" is "4739", "Obs ID (Observation Domain ID)" is "1234567890", "Sample Template ID" is "384", and "Option Template ID" is "640".

In the following explanation, each row in the template rule table 121 and the transparent filter table 122 may be referred to as a rule.

Figure 6 is a diagram showing an example of a transparent filter table. As shown in Figure 6, the transparent filter table 122, like the template rule table 121, includes items such as "Src IP", "Dst UDP Port", "Obs ID (Observation Domain ID)", "Sample Template ID", and "Option Template ID". These items in the transparent filter table 122 store the same values as those in the template rule table 121. On the other hand, rules that do not exist in the template rule table 121 may be registered in the transparent filter table 122.

Furthermore, the transparent filter table 122 includes items such as "Enable", "Sample Recv Flag", "Option Recv Flag", "Sample WDT", and "Option WDT".

The "Enable" item indicates whether or not the rule is described in the template rule table 121. If the same rule is described in the template rule table 121 (if it exists as a record), the value of the "Enable" item is "1", and if it is not described in the template rule table 121, the value of the "Enable" item is "0".

The "Sample Recv Flag" and "Option Recv Flag" items indicate the rule status for Sample Data packets and Option Data packets, respectively. The values of these items are "1" if the rule is enabled, and "0" if the rule is disabled.

In addition, the items "Sample Recv Flag" and "Option Recv Flag" correspond to the items "Sample WDT" and "Option WDT", respectively.

For example, if the value of the item "Sample WDT" is greater than "0", the rule is valid and the value of the item "Sample Recv Flag" is "1". On the other hand, if the value of the item "Sample WDT" is not greater than "0", the rule is invalid and the value of the item "Sample Recv Flag" is "0".

For example, if the value of the item "Option WDT" is greater than "0", the rule is valid and the value of the item "Option Recv Flag" is "1". On the other hand, if the value of the item "Option WDT" is not greater than "0", the rule is invalid and the value of the item "Option Recv Flag" is "0".

The items "Sample WDT" and "Option WDT" indicate the time until each rule becomes invalid. When the conversion device 10 receives a template (Sample Template packet or Option Template packet) that matches a rule, it sets the initial value of the timer to the corresponding item "Sample WDT" or item "Option WDT" and starts decrementing the items "Sample WDT" and "Option WDT" in accordance with the timer.

When the timer times out (the values of the items "Sample WDT" and "Option WDT" are 0), the conversion device 10 updates the value of the corresponding item "Sample Recv Flag" or item "Option Recv Flag" to "0."

Note that the items "Sample Recv Flag", "Option Recv Flag", "Sample WDT", and "Option WDT" are registered and updated during filter transparency determination. At that time, each item in the transparent filter table 122 is registered and updated independently for the aforementioned Sample Template and Option Template.

The control unit 13 controls the entire conversion device 10. The control unit 13 is, for example, an electronic circuit such as a CPU (Central Processing Unit), MPU (Micro Processing Unit), or GPU (Graphics Processing Unit), or an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array).

The control unit 13 also has an internal memory for storing programs and control data that define various processing procedures, and executes each process using the internal memory. The control unit 13 also functions as various processing units by running various programs.

For example, the control unit 13 has a determination unit 131, a rewriting unit 132, an analysis unit 133, a grouping unit 134, and a shaping unit 135.

The determination unit 131 performs packet transparency determination (corresponding to step S1 in FIG. 2). The process flow of the conversion device 10, including the packet transparency determination, will be described with reference to FIG. 7. FIG. 7 is a flowchart showing the process flow of the conversion device.

Note that the determination unit 131 discards xFlow packets that it determines are not to be processed in step S13 or step S14 of FIG. 7. The rewriting unit 132 rewrites the xFlow header of the xFlow packet that the determination unit 131 determines are to be processed (step S19). After that, the analysis unit 133, grouping unit 134, and shaping unit 135 analyze and convert the xFlow packet whose xFlow header has been rewritten (step S20). Note that FIG. 7 mainly describes the packet transparency determination, and the details of the processing from step S19 onwards will be described later.

The network device 2 also sends xFlow packets to the UDP port indicated in the rule set in the template rule table 121. However, the packets received by the conversion device 10 are not necessarily xFlow packets that comply with the rule. When the conversion device 10 receives an xFlow packet, it starts the process shown in FIG. 7.

As shown in FIG. 7, the determination unit 131 determines whether the received xFlow packet was received via IPv4 and complies with the UDP protocol (step S11).

If the received xFlow packet was received via IPv4 and conforms to the UDP protocol (step S11, Yes), the determination unit 131 proceeds to step S12.

On the other hand, if the received xFlow packet was not received via IPv4 or does not comply with the UDP protocol (step S11, No), the determination unit 131 discards the xFlow packet (step S14) and terminates the process.

In step S12, the determination unit 131 determines whether the destination port that received the xFlow packet is a port that has been set in the "Destination UDP Port" item of the transparent filter table 122.

If the destination port that received the xFlow packet is a port that has been set in the "Destination UDP Port" item of the transparent filter table 122 (step S12, Yes), the determination unit 131 proceeds to step S15.

If the destination port that received the xFlow packet is not a port that has been set in the "Destination UDP Port" item of the transparent filter table 122 (step S12, No), the determination unit 131 discards the xFlow packet (step S13) and terminates the process.

In step S15, the determination unit 131 determines whether the Set ID in the xFlow header is "2". If the Set ID in the xFlow header is "2" (step S15, Yes), the determination unit 131 regards the xFlow packet as a Sample Template packet and proceeds to step S18. Note that here, an example of the Set ID when the xFlow packet is an IPFIX packet will be described as an example.

If the Set ID in the xFlow header is not "2" (step S15, No), the determination unit 131 determines whether the Set ID is "3" (step S16). If the Set ID in the xFlow header is "3" (step S16, Yes), the determination unit 131 regards the xFlow packet as an Option Template packet and proceeds to step S18.

If the Set ID in the xFlow header is not "3" (step S16, No), the determination unit 131 determines whether the Set ID is "256" or greater (step S17). If the Set ID in the xFlow header is "256" or greater (step S17, Yes), the determination unit 131 regards the xFlow packet as a Data packet (Sample Data packet or Option Data packet) and proceeds to step S18.

If the Set ID in the xFlow header is not "256" or greater (step S17, No), the determination unit 131 discards the xFlow packet (step S14) and terminates the process.

Depending on the result of the transparent filter processing (step S18), the determination unit 131 either discards the xFlow packet (step S14) or passes the xFlow packet to subsequent processing (step S19).

The flow of the transparent filter processing (step S18 in FIG. 7) will be explained using FIG. 8. FIG. 8 is a flowchart showing the flow of the transparent filter processing. In the following explanation, the value of each item in the transparent filter table 122 will be represented as a variable with the name of each item as the variable name. For example, the value of the item "Sample Recv Flag" being "1" will be represented as "Sample Recv Flag=1". Furthermore, the process of determining whether or not a rule exists in the transparent filter table 122 is premised on Enable=1. In other words, the determination unit 131 considers a rule for which Enable is not 1 to be a non-existent rule.

First, we will explain the process when the determination unit 131 determines that the xFlow packet is a Data packet (Sample Data packet or Option Data packet), that is, when the process proceeds from S17 in FIG. 7 to the transparent filter process (step S18).

The determination unit 131 refers to the transparent filter table 122 and determines whether or not a row (rule) exists in which Sample Recv Flag=1, the Set ID of the xFlow packet=Sample Template ID, and the Src IP, dst UDP Port, and Obs ID match those of the xFlow packet (step S181).

If the rule shown in step S181 exists (step S181, Yes), the determination unit 131 regards the xFlow packet as a Sample Data packet and passes the xFlow packet to subsequent processing (step S19).

If the rule shown in step S181 does not exist (step S181, No), the determination unit 131 refers to the transparent filter table 122 and determines whether or not a row (rule) exists in which Sample Recv Flag=1, the Set ID of the xFlow packet=Option Template ID, and the Src IP, dst UDP Port, and Obs ID of the xFlow packet match (step S182).

If the rule shown in step S182 exists (step S182, Yes), the determination unit 131 regards the xFlow packet as an Option Data packet and passes the xFlow packet to subsequent processing (step S19).

On the other hand, if the rule shown in step S182 does not exist (step S182, No), the determination unit 131 proceeds to step S14 and discards the xFlow packet.

Next, we will explain the processing when the determination unit 131 determines that the xFlow packet is a Sample Template packet, that is, when the process proceeds from S15 in FIG. 7 to the transparent filter processing (step S18).

The determination unit 131 refers to the transparent filter table 122 and determines whether or not a row (rule) exists whose Src IP, dst UDP Port, Obs ID, and Sample Template ID match those of the xFlow packet (step S183).

If the rule shown in step S183 exists (step S183, Yes), the determination unit 131 proceeds to step S184.

On the other hand, if the rule shown in step S183 does not exist (step S183, No), the determination unit 131 proceeds to step S14 and discards the xFlow packet.

In step S184, the determination unit 131 sets the timer for the matching row. That is, the determination unit 131 sets the timer initial value in Sample WDT and sets Sample Recv Flag=1.

Furthermore, if the set timer times out, the determination unit 131 sets Sample WDT=0 and Sample Recv Flag=0 (step S185).

Next, we will explain the processing when the determination unit 131 determines that the xFlow packet is an Option Template packet, that is, when the process proceeds from S16 in FIG. 7 to the transparent filter processing (step S18).

The determination unit 131 refers to the transparent filter table 122 and determines whether or not a row (rule) exists whose Src IP, dst UDP Port, Obs ID, and Option Template ID match those of the xFlow packet (step S186).

If the rule shown in step S186 exists (step S186, Yes), the determination unit 131 proceeds to step S187.

On the other hand, if the rule shown in step S186 does not exist (step S186, No), the determination unit 131 proceeds to step S14 and discards the xFlow packet.

In step S187, the determination unit 131 sets the timer for the matching row. That is, the determination unit 131 sets the timer initial value to Option WDT and sets Option Recv Flag = 1.

Furthermore, if the set timer times out, the determination unit 131 sets Option WDT=0 and Option Recv Flag=0 (step S188).

In this way, the determination unit 131 determines whether or not an xFlow packet is to be processed based on the L2 header, L3 header, L4 header, and xFlow header contained in the xFlow packet. Furthermore, an xFlow packet to be processed is an xFlow packet that is to be subjected to protocol analysis and subsequent format conversion.

For example, in step S11 of FIG. 7, the determination unit 131 can determine whether or not the xFlow packet was received via IPv4 from the Ether header, which is an L2 header.

Furthermore, in step 181 of FIG. 8, the determination unit 131 can make a determination based on information in the IP header, which is an L3 header, and the UDP header and xFlow header, which are L4 headers.

The procedure by which the determination unit 131 updates the transparent filter table 122 will be described with reference to FIG. 9. FIG. 9 is a diagram illustrating the procedure by which the transparent filter table is updated. The determination unit 131 sets timers in the transparent filter table 122 independently for Sample Template packets and Option Template packets.

In FIG. 9, 122a indicates the transparent filter table 122 at the first time. At the first time, the conversion device 10 receives both a Sample Template packet that matches the rule with Src IP=192.168.1.1/32, and an Option Template packet that matches the rule.

At this time, the determination unit 131 updates both the Sample Recv Flag and Option Recv Flag corresponding to the rule to "1", and sets the timer initial value "10" for both the Sample WDT and the Option WDT item. Note that the timer is measured in seconds, for example, and the determination unit 131 decrements the timer in one-second cycles until it reaches 0.

If the set timer is "0", i.e., if a timeout occurs, the judgment unit 131 updates the Recv Flag and Option Recv Flag to "0".

However, as shown in 122b of FIG. 9, if the conversion device 10 further receives a Sample Template packet that matches the rule before the timeout, the determination unit 131 updates the Sample Recv Flag of that rule to "1" and sets the Sample WDT to the timer's initial value of "10."

In this way, when the determination unit 131 receives an xFlow packet that matches a template and has a specific value set in a field of the xFlow header, it sets a timer and determines that the xFlow packet that matches the template is to be processed until the timer times out, and after the timer times out, it determines that the xFlow packet that matches the template is not to be processed. An xFlow packet with a specific value set in a field of the xFlow header is, for example, an xFlow packet with "2" or "3" set in the Set ID of the xFlow header.

Returning to FIG. 3, the rewriting unit 132 rewrites the xFlow header that has been determined by the determination unit 131 to be subject to format conversion and that has been passed to it (corresponding to step S2 in FIG. 2).

The rewriting unit 132 rewrites the xFlow headers of multiple xFlow packets that have been determined by the determination unit 131 to be analysis targets and have different field configurations in their xFlow headers so that the field configurations of the xFlow headers of the multiple xFlow packets match a pre-specified field configuration. The rewriting unit 132 rewrites the xFlow headers of each of the Sample Data packets and Option Data packets passed from the determination unit 131 to unify the field configurations, i.e., the header patterns.

The rewriting unit 132 can identify the header pattern by the UDP dst port of the xFlow packet. The rewriting unit 132 also holds information on the UDP dst port of the xFlow packet and the rewriting type number corresponding to that port in a table in advance. The rewriting type number corresponds to the xFlow header pattern of the received xFlow packet and the rewriting process information on which header pattern to rewrite it to, and a value is set for each combination of the header patterns before and after rewriting. Using this, the rewriting unit 132 determines the rewriting process of the header pattern of the xFlow packet that is determined by the determination unit 131 to be the analysis target and conforms to the UDP protocol, based on the UDP dst port, and rewrites the xFlow header of the xFlow packet. If the header patterns before and after rewriting are the same, the xFlow header is not rewritten. Also, it is assumed that the field configuration of the header pattern after rewriting is set in advance and stored by the conversion device 10.

The field configuration of the header pattern after rewriting includes, for example, fields that are included in all header patterns to be rewritten. In addition, fields that are newly added as a result of rewriting are filled with zeros (zero padding).

The procedure for rewriting the xFlow header by the rewriting unit 132 will be described with reference to FIG. 10. FIG. 10 is a diagram showing an example of rewriting the xFlow header, where the header pattern after rewriting is pattern C.

The IPFIX header of pattern A and the IPFIX header of pattern B in FIG. 10 have header patterns to be rewritten. In addition, the rewriting unit 132 rewrites the IPFIX header of pattern A and the IPFIX header of pattern B to unify them into fields of pattern C. The rewrite process information associated with the rewrite type number corresponding to the UDP dst Port of the xFlow packets of patterns A and B both indicates rewriting so that the header pattern after rewriting becomes pattern C.

The rewriting unit 132 adds a 1-byte field "IPFIX Set/Direction" and a 2-byte field "IPFIX Set/dataLinkFrameSize" to the A pattern according to the rewriting process information associated with the rewriting type number corresponding to the UDP dst Port of the xFlow packet of the A pattern. The rewriting unit 132 also enters 0 into the added fields.

The rewrite unit 132 adds a 1-byte field "IPFIX Set/Direction" to the pattern B according to the rewrite process information associated with the rewrite type number corresponding to the UDP dst port of the xFlow packet of the pattern B. The rewrite unit 132 also enters 0 into the added field.

Returning to FIG. 3, the analysis unit 133 analyzes the xFlow packet that the determination unit 131 has determined to be the target of processing. Furthermore, the xFlow header of the xFlow packet that the determination unit 131 has determined to be the target of processing may be rewritten by the rewriting unit 132. In such a case, for example, the analysis unit 133 performs protocol analysis of the xFlow packet whose xFlow header has been rewritten by the rewriting unit 132 (corresponding to step S3 in FIG. 2).

The grouping unit 134 performs packet grouping (corresponding to step S4 in FIG. 2).

The formatting unit 135 performs information formatting (corresponding to step S5 in FIG. 2). In addition, the conversion device 10 transmits the information obtained by the information formatting by the formatting unit 135 to the analysis device 3.

[Effects of the First Embodiment]
As described above, the conversion device 10 according to the embodiment includes a determination unit 131 and an analysis unit 133. The determination unit 131 determines whether or not an xFlow packet is a processing target based on the L2 header, L3 header, L4 header, and xFlow header included in the xFlow packet. The analysis unit 133 analyzes the xFlow packet determined by the determination unit 131 to be a processing target. In this manner, the determination by the determination unit 131 narrows down the xFlow packets to be analyzed by the analysis unit 133. As a result, according to this embodiment, it is possible to reduce the processing load required for analyzing packet headers.

When the determination unit 131 receives an xFlow packet that matches a template and has a specific value set in a field of the xFlow header, it sets a timer and determines that the xFlow packet that matches the template is to be processed until the timer times out, and after the timer times out, it determines that the xFlow packet that matches the template is not to be processed.

The conversion device 10 further includes a rewriting unit 132. The rewriting unit 132 rewrites the xFlow headers of multiple xFlow packets that have been determined by the determination unit 131 to be the subject of analysis and have different field configurations in their xFlow headers so that the field configurations of the xFlow headers of the multiple xFlow packets become a pre-specified field configuration. Even if the xFlow type is the same, there are xFlow packets that have different field configurations in their xFlow headers. According to this embodiment, it becomes possible to efficiently analyze such xFlow packets.

The rewriting unit 132 rewrites the xFlow header of an xFlow packet that is determined by the determination unit 131 to be an analysis target and conforms to the UDP protocol, so that the field configuration of the xFlow header of the xFlow packet becomes the field configuration associated with the UDP port that received the xFlow packet. This enables the conversion device 10 to easily manage the field configuration of the rewritten destination by associating it with the source.

[System configuration]
Each component of the conversion device 10 shown in Fig. 1 is a functional concept, and does not necessarily have to be physically configured as shown in the figure. In other words, the specific form of distribution and integration of the functions of the conversion device 10 is not limited to that shown in the figure, and all or part of it can be functionally or physically distributed or integrated in any unit depending on various loads, usage conditions, etc.

Furthermore, each process performed by the conversion device 10 may be realized, in whole or in part, by a CPU and a program analyzed and executed by the CPU. Furthermore, each process performed by the conversion device 10 may be realized as hardware using wired logic.

Furthermore, among the processes described in the embodiments, all or part of the processes described as being performed automatically can also be performed manually. Alternatively, all or part of the processes described as being performed manually can also be performed automatically using known methods. In addition, the information including the processing procedures, control procedures, specific names, various data, and parameters described above and illustrated can be modified as appropriate unless otherwise specified.

[program]
11 is a diagram showing an example of a computer in which a conversion device is realized by executing a program. The computer 1000 has, for example, a memory 1010 and a CPU 1020. The computer 1000 also has a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These components are connected by a bus 1080.

The memory 1010 includes a ROM 1011 and a RAM 1012. The ROM 1011 stores a boot program such as a BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to a hard disk drive 1090. The disk drive interface 1040 is connected to a disk drive 1100. A removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1100. The serial port interface 1050 is connected to a mouse 1110 and a keyboard 1120, for example. The video adapter 1060 is connected to a display 1130, for example.

The hard disk drive 1090 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. That is, the program that defines each process of the conversion device 10 is implemented as a program module 1093 in which code executable by the computer 1000 is written. The program module 1093 is stored, for example, in the hard disk drive 1090. For example, a program module 1093 for executing processes similar to the functional configuration of the conversion device 10 is stored in the hard disk drive 1090. The hard disk drive 1090 may be replaced by an SSD.

Furthermore, the setting data used in the processing of the above-mentioned embodiment is stored as program data 1094, for example, in memory 1010 or hard disk drive 1090. Then, the CPU 1020 reads the program module 1093 or program data 1094 stored in memory 1010 or hard disk drive 1090 into RAM 1012 as necessary and executes it.

The program module 1093 and program data 1094 may not necessarily be stored in the hard disk drive 1090, but may be stored in a removable storage medium, for example, and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program module 1093 and program data 1094 may be stored in another computer connected via a network (such as a LAN (Local Area Network), WAN (Wide Area Network)). The program module 1093 and program data 1094 may then be read by the CPU 1020 from the other computer via the network interface 1070.

The above describes an embodiment of the invention made by the inventor, but the present invention is not limited to the descriptions and drawings that form part of the disclosure of the present invention according to this embodiment. In other words, all other embodiments, examples, and operational techniques made by those skilled in the art based on this embodiment are included in the scope of the present invention.

REFERENCE SIGNS LIST 1 Communication system 2 Network device 3 Analysis device 10 Conversion device 11 Communication unit 12 Storage unit 13 Control unit 121 Template rule table 122 Transparent filter table 131 Determination unit 132 Rewriting unit 133 Analysis unit 134 Grouping unit 135 Shaping unit

Claims

a determination unit that determines whether or not an xFlow packet is to be processed based on an L2 header, an L3 header, an L4 header, and an xFlow header included in the xFlow packet;
an analysis unit that analyzes an xFlow packet that is determined to be a processing target by the determination unit;
A conversion device comprising:
The conversion device according to claim 1, characterized in that when the determination unit receives an xFlow packet that matches a template and has a specific value set in a field of the xFlow header, the determination unit sets a timer, determines that the xFlow packet that matches the template is to be processed until the timer times out, and determines that the xFlow packet that matches the template is not to be processed after the timer times out.
The conversion device according to claim 1, characterized in that the conversion device rewrites the field configurations of the xFlow headers of multiple xFlow packets that are determined by the determination unit to be analysis targets and have different field configurations of the xFlow headers according to the UDP protocol based on rewrite processing information associated with the UDP ports that received the multiple xFlow packets.
A conversion method performed by a conversion device, comprising:
a determination step of determining whether or not the xFlow packet is to be processed based on an L2 header, an L3 header, an L4 header, and an xFlow header included in the xFlow packet;
an analysis step of analyzing an xFlow packet determined to be a processing target by the determination step;
A method for converting, comprising:
On the computer,
a determination step of determining whether or not the xFlow packet is a processing target based on an L2 header, an L3 header, an L4 header, and an xFlow header included in the xFlow packet;
an analysis step of analyzing the xFlow packet determined to be a processing target in the determination step;
A conversion program characterized by causing a user to execute the above steps.