Conversion device, conversion method, and conversion program

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

[Technical Field]

[0001] The present invention relates to a conversion device, a conversion method, and a conversion program. [Background technology]

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

[0003] Also, 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. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2019-097069 [Patent Document 2] Patent Publication No. 2021-090161 [Patent Document 3] International Publication No. 2021 / 149245 [Patent Document 4] Japanese Patent Publication No. 2020-174257 [Non-patent literature]

[0005] [Non-Patent Document 1] NetFlow (RFC3954), [Retrieved November 10, 2022], Internet<URL:https: / / datatracker.ietf.org / doc / html / rfc3954.html> [Non-patent document 2] IPFIX (RFC5103, 7011-7015), [Retrieved November 10, 2022], Internet<URL:https: / / www.ietf.org / rfc / rfc5103.txt> [Non-patent document 3] sFlow, [Retrieved November 10, 2022], Internet<URL:https: / / sflow.org / sflow_version_5.txt> [Non-patent document 4] IPFIX with IE315 (RFC7133) [Non-Patent Document 5] pmacct, [Retrieved November 10, 2022], Internet<URL:http: / / www.pmacct.net / > [Non-patent document 6] nProbe, [Retrieved November 10, 2022], Internet<URL:https: / / www.ntop.org / products / netflow / nprobe / > [Non-Patent Document 7] Nishioka et al., “Proposal of Fast xFlow Proxy for visualizing traffic in carrier networks accommodating multiple operators,” IEICE General Conference 2021, B-6-33, Mar. 10, 2021 Summary of the Invention [Problem to be solved by the invention]

[0006] However, the conventional technology has a problem in that the processing load required for analyzing packet headers is large.

[0007] For example, a converter that performs format conversion as described in Patent Document 3 may receive xFlow packets whose xFlow header field configurations differ depending on the model of the source network (NW) device, even if the xFlow type (IPFIX, NetFlow, etc.) is the same. When analyzing such xFlow packets, it becomes necessary to perform processes such as detecting the position of the encapsulated packet from the beginning of the xFlow packet and header analysis, which increases the processing load of the converter.

[0008] The present invention has been made in view of the above, and has as its object to reduce the processing load required to analyze packet headers. [Means for solving the problem]

[0009] In order to solve the above-mentioned problems and achieve the object, the conversion device of the present invention is characterized by having a judgment unit that judges 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 xFlow packets that are judged by the judgment unit to be to be processed. [Effects of the Invention]

[0010] According to the present invention, it is possible to reduce the processing load required for analyzing packet headers. [Brief explanation of the drawings]

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

[0012] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The following describes in detail embodiments of a conversion device, a conversion method, and a conversion program according to the present invention, with reference to the accompanying drawings. However, the present invention is not limited to the embodiments described below.

[0013] [First embodiment] The converter of this embodiment performs protocol analysis and format conversion on xFlow packets that have predetermined characteristics and are subject to format conversion. However, the converter may receive encapsulated packets that are not subject to format conversion.

[0014] Therefore, the converter has a function to determine whether a received encapsulated packet is an xFlow packet that is subject to format conversion. Furthermore, the converter rewrites the field configuration (hereinafter sometimes referred to as a header pattern) of the header (hereinafter sometimes referred to as an xFlow header) of the xFlow packet that is determined to be subject to format conversion, thereby reducing the processing load in protocol analysis and format conversion.

[0015] [Communication system configuration] Fig. 1 is a block diagram showing an example of the 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 devices are not limited to those shown.

[0016] 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 a 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 a separate xFlow packet. Furthermore, the network device 2 can transfer not only xFlow packets but also mirrored encapsulated packets to the conversion device 10.

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

[0018] The conversion device 10 converts 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 that receives 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.

[0019] Here, the processing flow of the conversion device 10 will be described with reference to Fig. 2. Fig. 2 is a diagram illustrating the processing flow in the conversion device.

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

[0021] As shown in Fig. 2, the mirrored encapsulated packet includes an outer packet header and an inner packet header, and the xFlow packet includes the packet header of the xFlow packet in addition to the outer packet header and inner packet header.

[0022] First, the converter 10 performs packet transparency determination for the received xFlow packets (step S1). Here, the converter 10 determines that xFlow packets that match a template are subject to format conversion, and passes them on to the next process.

[0023] Next, the conversion device 10 rewrites the packet header of the xFlow packet that is determined to be a target for format conversion in the pass determination (step S2).

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

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

[0026] The conversion device 10 then 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 inner packet headers. For example, for xFlow packets classified into group "#2," the conversion device 10 performs outer statistical processing to obtain statistics on outer headers. For example, for xFlow packets classified into group "#3," the conversion device 10 performs header deletion to remove outer headers.

[0027] The conversion device 10 transmits the xFlow packet after 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 FIG. 2 are examples of the analysis device 3.

[0028] [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 has a communication unit 11, a storage unit 12, and a control unit 13.

[0029] The communication unit 11 is an interface for transmitting and receiving data to and from other devices (for example, the NW device 2 and the analysis device 3). For example, the communication unit 11 is a network interface card (NIC).

[0030] Here, an xFlow packet that the communication unit 11 receives from the network device 2 will be described with reference to Fig. 4. Fig. 4 is a diagram showing an example of an xFlow packet.

[0031] The communication unit 11 receives Data packets and Template packets as xFlow packets. The Data packets include Sample Data packets and Option Data packets. The Template packets include Sample Template packets and Option Template packets.

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

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

[0034] 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.

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

[0036] Storage unit 12 stores data relating to the OS (Operating System) and various programs executed by conversion device 10. For example, storage unit 12 stores a template rule table 121 and a transparency filter table 122.

[0037] The template rule table 121 is used to create the transparency filter table 122. The transparency filter table 122 is also used to determine whether an xFlow packet should be transmitted or not. The template rule table 121 and the transparency filter table 122 are set in advance before the transparency determination of an xFlow packet is made.

[0038] 5 is a diagram showing an example of a template rule table. In this embodiment, xFlow packets are transmitted and received using IPv4. However, the protocol for transmitting and receiving xFlow packets is not limited to IPv4 and may be, for example, IPv6.

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

[0040] As shown in FIG. 5, 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".

[0041] 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 received xFlow packet. 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).

[0042] 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".

[0043] In the following description, each row of template rule table 121 and transparent filter table 122 may be referred to as a rule.

[0044] Fig. 6 is a diagram showing an example of a transparent filter table. As shown in Fig. 6, transparent filter table 122 includes items such as "Src IP," "Dst UDP Port," "Obs ID (Observation Domain ID)," "Sample Template ID," and "Option Template ID," just like template rule table 121. These items in transparent filter table 122 store the same values ​​as those in template rule table 121. However, transparent filter table 122 may register rules that do not exist in template rule table 121.

[0045] Furthermore, the transmission filter table 122 includes items such as "Enable", "Sample Recv Flag", "Option Recv Flag", "Sample WDT", and "Option WDT".

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

[0047] 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.

[0048] Also, the item "Sample Recv Flag" and the item "Option Recv Flag" correspond to the item "Sample WDT" and the item "Option WDT", respectively.

[0049] 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".

[0050] 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".

[0051] The "Sample WDT" and "Option WDT" items 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 corresponding "Sample WDT" or "Option WDT" item to the initial value of a timer and starts decrementing the "Sample WDT" and "Option WDT" items in accordance with the timer.

[0052] When the timer times out (the value of the item "Sample WDT" and the item "Option WDT" is 0), the conversion device 10 updates the value of the corresponding item "Sample Recv Flag" or item "Option Recv Flag" to "0".

[0053] The items "Sample Recv Flag", "Option Recv Flag", "Sample WDT", and "Option WDT" are registered and updated in the filter transmission decision. At that time, each item in the transmission filter table 122 is registered and updated independently for the above-mentioned Sample Template and Option Template.

[0054] 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), an MPU (Micro Processing Unit), or a GPU (Graphics Processing Unit), or an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array).

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

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

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

[0058] 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 xFlow packets that it determines are to be processed by the determination unit 131 (step S19). After that, the analysis unit 133, grouping unit 134, and shaping unit 135 analyze and convert the xFlow packets whose xFlow headers have been rewritten (step S20). Fig. 7 mainly describes packet transparency determination, and details of the processing from step S19 onwards will be described later.

[0059] The network device 2 also transmits xFlow packets to the UDP port specified 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. Upon receiving an xFlow packet, the conversion device 10 starts the process shown in FIG. 7.

[0060] As shown in FIG. 7, the decision unit 131 decides whether or not the received xFlow packet is received by IPv4 and conforms to the UDP protocol (step S11).

[0061] If the decision unit 131 determines that the received xFlow packet was received using IPv4 and conforms to the UDP protocol (Yes in step S11), the process proceeds to step S12.

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

[0063] In step S 12 , the decision unit 131 decides whether the destination port that received the xFlow packet is a port that has already been set in the “destination UDP port” item of the transmission filter table 122 .

[0064] If the decision unit 131 determines that the destination port that received the xFlow packet is a port that has been set in the "destination UDP port" field of the transparent filter table 122 (Yes at step S12), the process proceeds to step S15.

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

[0066] 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.

[0067] 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.

[0068] 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.

[0069] If the Set ID in the xFlow header is not equal to or greater than "256" (step S17, No), the decision unit 131 discards the xFlow packet (step S14) and ends the process.

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

[0071] The flow of the transparent filter processing (step S18 in FIG. 7) will be described with reference to FIG. 8. FIG. 8 is a flowchart showing the flow of the transparent filter processing. In the following description, the value of each item in the transparent filter table 122 will be represented as a variable with the name of the 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, in the process of determining whether a rule exists in the transparent filter table 122, it is assumed that Enable=1. That is, the determination unit 131 regards a rule for which Enable is not 1 as a non-existent rule.

[0072] First, the process when the decision 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), will be described.

[0073] The determination unit 131 refers to the transparent filter table 122 and determines whether there is a row (rule) where 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).

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

[0075] If the rule indicated 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 match those of the xFlow packet (step S182).

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

[0077] On the other hand, if the rule indicated in step S182 does not exist (step S182, No), the decision unit 131 proceeds to step S14 and discards the xFlow packet.

[0078] Next, the processing when the decision 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), will be described.

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

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

[0081] On the other hand, if the rule indicated in step S183 does not exist (step S183, No), the decision unit 131 proceeds to step S14 and discards the xFlow packet.

[0082] 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.

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

[0084] Next, the process will be described when the decision 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 process (step S18).

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

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

[0087] On the other hand, if the rule indicated in step S186 does not exist (step S186, No), the decision unit 131 proceeds to step S14 and discards the xFlow packet.

[0088] In step S187, the determination unit 131 sets the timer for the matched row. That is, the determination unit 131 sets the timer initial value in Option WDT and sets Option Recv Flag=1.

[0089] Furthermore, when the set timer times out, the decision unit 131 sets Option WDT=0 and Option Recv Flag=0 (step S188).

[0090] In this way, the determination unit 131 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. The xFlow packet to be processed is an xFlow packet that is to be subjected to protocol analysis and subsequent format conversion.

[0091] For example, in step S11 of FIG. 7, the determining unit 131 can determine from the Ether header, which is an L2 header, whether or not the xFlow packet has been received by IPv4.

[0092] Furthermore, in step 181 in FIG. 8 and the like, 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.

[0093] 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 for updating the transparent filter table. The determination unit 131 sets timers in the transparent filter table 122 independently for Sample Template packets and Option Template packets.

[0094] 9 shows the transmission filter table 122 at the first time point. At the first time point, the translation 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.

[0095] At this time, the determination unit 131 updates both the Sample Recv Flag and the 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 every second until it reaches 0.

[0096] When the set timer reaches "0", that is, when the timer times out, the decision unit 131 updates the Recv Flag and Option Recv Flag to "0".

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

[0098] 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 in 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. Note that an xFlow packet with a specific value set in a field in the xFlow header is, for example, an xFlow packet whose Set ID in the xFlow header is set to "2" or "3".

[0099] Returning to FIG. 3, the rewriting unit 132 rewrites the xFlow header that has been determined by the determining unit 131 to be a target for format conversion and that has been passed to the rewriting unit 132 (corresponding to step S2 in FIG. 2).

[0100] The rewriting unit 132 rewrites the xFlow headers of multiple xFlow packets that have been determined by the determining unit 131 to be analysis targets and have different xFlow header field configurations 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 the Sample Data packets and Option Data packets passed from the determining unit 131 to unify the field configurations, i.e., the header patterns.

[0101] The rewriting unit 132 can identify the header pattern by the UDP dst port of the xFlow packet. The rewriting unit 132 also stores information about the UDP dst port of the xFlow packet and the rewriting type number corresponding to that port in a table. The rewriting type number corresponds to the xFlow header pattern of the received xFlow packet and the rewriting process information indicating 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 for the header pattern of an xFlow packet that conforms to the UDP protocol and that is determined by the determining unit 131 to be an analysis target, 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. The field configuration of the header pattern after rewriting is set in advance and stored by the conversion device 10.

[0102] The field configuration of the rewritten header pattern includes, for example, fields included in all of the header patterns to be rewritten. Additionally, fields newly added by rewriting are filled with zeros (zero padding).

[0103] 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.

[0104] 10 has a header pattern to be rewritten. 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 rewriting process information associated with the rewriting type number corresponding to the UDP dst Port of the xFlow packets of pattern A and pattern B both indicates rewriting so that the header pattern after rewriting becomes pattern C.

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

[0106] The rewriting unit 132 adds a 1-byte field “IPFIX Set / Direction” to pattern B in accordance with the rewriting process information associated with the rewriting type number corresponding to the UDP dst port of the xFlow packet of pattern B. The rewriting unit 132 also enters 0 into the added field.

[0107] 3, the analysis unit 133 analyzes xFlow packets that have been determined by the determination unit 131 to be processing targets. Furthermore, xFlow packets that have been determined by the determination unit 131 to be processing targets may have their xFlow headers rewritten by the rewriting unit 132. In this case, for example, the analysis unit 133 performs protocol analysis on the xFlow packets whose xFlow headers have been rewritten by the rewriting unit 132 (corresponding to step S3 in FIG. 2).

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

[0109] The shaping unit 135 performs information shaping (corresponding to step S5 in FIG. 2). Furthermore, the conversion device 10 transmits the information obtained by the information shaping by the shaping unit 135 to the analysis device 3.

[0110] [Advantages 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 an xFlow packet is to be processed based on the L2 header, L3 header, L4 header, and xFlow header contained in the xFlow packet. The analysis unit 133 analyzes the xFlow packets determined by the determination unit 131 to be to be processed. In this way, 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.

[0111] 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.

[0112] 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 analysis targets and have different xFlow header field configurations so that the field configurations of the xFlow headers of the multiple xFlow packets match a pre-specified field configuration. Even if the xFlow type is the same, there may be xFlow packets with different xFlow header field configurations. According to this embodiment, it is possible to efficiently analyze such xFlow packets.

[0113] The rewriting unit 132 rewrites the xFlow header of an xFlow packet that is determined by the determining 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 allows the conversion device 10 to easily manage the field configuration of the rewritten destination by associating it with the sender.

[0114] [System Configuration] 1 are conceptual functional components of the conversion device 10 and do not necessarily have to be physically configured as shown. In other words, the specific form of distribution and integration of the functions of the conversion device 10 is not limited to that shown, and all or part of the functions can be functionally or physically distributed or integrated in any unit depending on various loads, usage conditions, etc.

[0115] Furthermore, all or any part of the processes performed in the conversion device 10 may be realized by a CPU and a program analyzed and executed by the CPU. Furthermore, each process performed in the conversion device 10 may be realized as hardware using wired logic.

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

[0117] [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.

[0118] 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.

[0119] 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, a 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 those of the functional configuration of the conversion device 10 is stored in the hard disk drive 1090. Note that the hard disk drive 1090 may be replaced with an SSD.

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

[0121] The program module 1093 and program data 1094 are not limited to being stored in the hard disk drive 1090, but may also be stored in, for example, a removable storage medium 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 local area network (LAN) or a wide area network (WAN)). 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.

[0122] Although the present invention has been described above as an embodiment, the present invention is not limited to the description and drawings that form part of the disclosure of the present invention. In other words, other embodiments, examples, and operational techniques that can be made by those skilled in the art based on the present invention are all included in the scope of the present invention. [Explanation of symbols]

[0123] 1. Communication Systems 2 NW device 3 Analyzer 10 Conversion Device 11 Communications Department 12 Storage section 13 Control Unit 121 Template Rule Table 122 Transmission Filter Table 131 Judgment section 132 Rewrite section 133 Analysis Department 134 Grouping Section 135 Plastic Surgery Department

Claims

1. a determination unit that determines whether an 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; a rewriting unit that 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 their xFlow headers according to the UDP protocol, based on rewriting process information associated with the UDP ports that received the multiple xFlow packets; an analysis unit that analyzes the xFlow packet whose xFlow header has been rewritten by the rewriting unit; A conversion device comprising:

2. 2. The conversion device according to claim 1, wherein, 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.

3. 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 the L2 header, L3 header, L4 header, and xFlow header included in the xFlow packet; a rewriting step of rewriting the field configurations of the xFlow headers of multiple xFlow packets that are determined to be analysis targets in the determination step and have different field configurations of their xFlow headers according to the UDP protocol, based on rewriting process information associated with the UDP ports that received the multiple xFlow packets; an analyzing step of analyzing the xFlow packets whose xFlow headers have been rewritten by the rewriting step; A conversion method comprising:

4. On the computer, a determination step of determining whether 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; a rewriting step of rewriting the field configurations of the xFlow headers of multiple xFlow packets that are determined to be analysis targets in the determining step and have different field configurations of their xFlow headers according to the UDP protocol, based on rewriting process information associated with the UDP ports that received the multiple xFlow packets; an analyzing step of analyzing the xFlow packet whose xFlow header has been rewritten by the rewriting step; A conversion program characterized by executing the above.

Images