JP4724636B2 - Protocol processing system and protocol processing method - Google Patents

Description

  The present invention relates to a protocol processing system and a protocol processing method suitable for encapsulation and decapsulation in a tunneling protocol in IPv4 protocol processing based on IPv4 or RFC2460 based on RFC791 of IETF.

  When constructing a network that connects multiple bases, until recently, it was common to construct a network by contracting a private line provided by a first-class telecommunications carrier for each base. .

  However, with the spread of the Internet, the communication cost in the Internet network has drastically decreased, so that the leased line service has become more expensive than the communication cost of the Internet network. Therefore, VPN (Virtual Private Network) technology has been introduced that uses the Internet network to replace dedicated lines. Bandwidth is not guaranteed for conventional leased lines, but has attracted attention as a technology that can effectively reduce communication costs.

  On the other hand, in many cases, a communication service depending on each mainframe is not used as a communication service receiving side. In many cases, TCP (UDP) / IP used in many computers such as a personal computer (PC) is used, that is, an IP network is used.

  When these multiple computers are connected between multiple bases, the network is established even if they are connected to the Internet as they are, but considering that a lot of company information flows, at least the payload must be encrypted. . Further, when constructing a network as a corporate network, it is not preferable to have a structure depending on the Internet network, even if it is between bases, because it becomes a design constraint.

  Therefore, by encrypting the IP network used in the company and then encapsulating it with IP, the VPN that is used like a dedicated IP network even though the Internet network is used, that is, IP-VPN Is used. A configuration example of a network using IPsec-VPN is shown in FIG.

  In FIG. 12, the sites Client 1 to 5 and the sites Server 1 to 2 are connected to the Internet via the IP-VPN Gateway. It also indicates that there is access via a remote terminal connected to the Internet, access from a VPN Client terminal to the Internet Server, and the like. In FIG. 12, global IP addresses of the Internet are assigned to devices directly connected to the Internet, that is, Internet Server, Remote Terminal, and IP-VPN Gateways 1 to 4. This global IP address is used for communication between these devices. In addition, VPN-Servers 1-2 and VPN-Clients 1-5 connected via the VPN-Gateway are assigned the same IP subnet and can constitute a VPN. Further, the VPN-Gateway 2 also serves as a Proxy Server, and controls access to the Internet of devices constituting the VPN.

  In such a configuration, the IP-VPN Gateways 1 to 4 communicate with each other using the IPSec Tunneling protocol, but the VPN-Clients 1 to 5 perform communication between VPN devices without being particularly aware of the existence of IPSec. Can do.

  Details of communication from the IP-VPN Gateway 2 to the IP-VPN Gateway 3 via the VPN-Tunnel 1 will be described. In the case of VPN-Tunnel 1, access is made through a route of VPN-Client 2 → IP-VPN Gateway 2 → Internet → IP-VPN Gateway → VPN Client 3.

  A packet format in the access path in the case of VPN-Tunnel 1 is shown in FIG. In the access between VPN-Client 2 and VPN-Gateway 2, communication is performed in the simplest IP format including an IP header and a payload (the Ether header of L 2 is omitted; the same applies hereinafter). A local IP address in the IP-VPN Gateway 2 is assigned to the IP address of the IP header 1 assigned here. In the case of the simplest IP tunneling protocol, it is realized by further adding IP Header 2 to which an IP address used in the Internet is assigned outside IP Header 1 assigned first.

  In this case, it is possible to observe details of IP Header 1 and Payload on the route on the Internet, and it is also easy to try communication with a fake packet on the route. Therefore, encryption technology is used to prevent eavesdropping, and authentication technology is used to prevent counterfeiting. In the IP-VPN Gateway for processing IPSec, it is defined what encryption-authentication algorithm is applied to which destination IP packet. FIG. 13 shows the IPSec header format of the tunneling mode using authentication + encryption. Since the original IP header and payload are encrypted together with the ESP Trailer, it is difficult to analogize the original IP packet on the Internet unless there is a decryption key. Further, since the newly created IP header, AH header, and ESP header are authenticated, it becomes difficult to tamper the packet on the Internet.

  As described above, since the communication between the IP and VPN gateways is performed after improving the packet security on the Internet, even if an advanced attack is performed, an encryption-authentication algorithm suitable for the attack is used. Therefore, safety equivalent to that of dedicated lines can be provided.

  In the IP-VPN Gateway 3 on the packet receiving side, the IP header, AH, ESP header, ESP Trailer, and authentication data added in the IP-VPN Gateway 2 are removed. Then, the original IP header and payload are decrypted and passed to VPN-Client3.

  By communicating in this way, IP communication between VPN-Client 2 and VPN-Client 3 can be handled as computers on the same subnet without being aware of the existence of IP-VPN Gateway or the Internet.

  Such access is the same between the server and the client, and the VPN-Gateway of VPN-Client5 → VPN-Server1 in VPN-Tunnel2 also works in the same way.

  However, in order to access the VPN from RemoteClient, which is a terminal on the Internet, it is necessary to cause the RemoteClient side to perform an operation equivalent to VPN-Gateway. Therefore, it is necessary for such a terminal to manage two pieces of information, that is, network information in the VPN and network information on the Internet, and create and encapsulate each IP header.

  RFC2661 proposes L2TP as a Tunneling protocol in the data link layer. This protocol is a protocol integrated and formulated by the IETF based on the PPTP protocol and the L2F protocol, and is a protocol for constructing a VPN by assigning an IP address and authenticating a user for accessing the Internet. In L2TP, a PPP (Point to Point Protocol) header is added before an IP datagram to be transmitted. This PPP is composed of encapsulation of the original IP datagram, link control (LCP: Link Control Protocol), and network control (NCP: Network Control Protocols). Link control includes establishment, setting, inspection, etc. of data link layer connection, and network control includes establishment, setting, etc. of network layer protocol connection. Furthermore, an L2TP header is added before the PPP header. The L2TP header describes a session ID, tunnel ID, transmission / reception sequence number, and the like, and can have a plurality of VPN paths. Finally, the original transmission frame, PPP header, and L2TP header are encapsulated by UDP (Port: 1701), and a tunneling IP header is attached.

  By combining with user authentication in this way, it becomes possible to provide a VPN for access from a remote client.

  Since the encryption function is not provided as L2TP, the secrecy of the tunnel is usually secured by using the IPSec transport mode for L2TP. A format used in L2TP is shown in FIG.

  In order to realize the above tunneling protocol by a typical conventional protocol processing system (FIG. 15), it is possible to create the outermost TCP (UDP) / IP header. However, it is difficult to make a tunneled protocol hardware. In addition, although it is possible to connect the protocol processors sequentially to support the tunneling protocol, it is difficult to dynamically change the protocol format and it can be said that the system lacks flexibility.

  FIG. 16 shows an example of a protocol processing system corresponding to the IPSec tunneling protocol. Here, an IPSec tunneling protocol is realized by inserting an IP / IPsec protocol processor between the TCP (UDP) / IP protocol processor and the MAC device.

JP 2004-15504 A

  The protocol processing system or method found in the above conventional example has the following problems. In other words, in the IPSec tunneling mode and L2TP, when the same layer such as the IP layer is multiplexed for protocol tunneling or encapsulation, it is difficult to configure hardware corresponding to these various protocol formats. In other words, when such a configuration is attempted, the hardware scale increases and the system becomes inflexible.

  The present invention has been made to solve the above problems, and temporarily holds a TCP (UDP) / IP protocol processor for generating and analyzing a TCP (UDP) / IP protocol and a packet created by the protocol processor. A communication buffer capable of transferring the held packet to a destination device designated in advance, a plurality of protocol databases storing protocol information corresponding to the destination device designated in advance, and a MAC performing link layer processing Device, a DMA control device for transmitting payload and header information, a CPU for executing a host application and a protocol control program, a substance of the CPU program, and a system memory for storing packet information A protocol processing system, The protocol processor creates a header by searching the protocol database according to the destination by giving the destination instruction of the created packet when giving the header creation instruction of each layer to the protocol processor. Provided is a protocol processing system or the like that outputs MAC of packet information based on a destination instruction or writes it back to an arbitrary address in a system memory.

According to the present invention, in the protocol processing system, a communication buffer is provided before output to the medium, and an output means from the communication buffer to another device and an input means from another device are provided, so that the IP tunneling protocol is flexible It becomes possible to cope with.
This makes it possible to process various tunneling protocols such as a protocol format in the transport mode in IPSec.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

(First embodiment)
First, a first embodiment of the present invention will be described. FIG. 1 shows an example of the configuration of a protocol processor transmission / reception unit including a protocol processing system showing an embodiment based on the concept of the present invention.

  In FIG. 1, reference numeral 101 denotes a TCP (UDP) / IP protocol processor. Reference numeral 102 denotes a communication buffer for storing the packet created in 101 at a location and transmitting it to an arbitrary destination, or for temporarily storing the packet received by the MAC and transmitting it to the protocol processor 101. Reference numeral 103 denotes various databases for protocols according to the packet source, destination, or layer, 104 denotes a MAC device that performs link layer processing, and 105 denotes a DMAC device that transfers a header or payload. Reference numeral 106 denotes a CPU for executing an upper layer application program and controlling protocols of each layer. Reference numeral 107 denotes a system memory in which the CPU application entity and protocol control program are stored, and reference numeral 108 denotes a shared bus for connecting various devices to each other.

  FIG. 3 is a transmission packet descriptor used in the protocol processing system showing an embodiment based on the concept of claim 1 of the present invention. The transmission packet descriptor indicates what constitutes a part or all of the packet stored in the system memory, and is composed of data start address, data length, transmission destination, transmission packet descriptor connection information, and the like. .

  Analysis information, packet information, and the like in the protocol processing system are stored. The information includes a start address of the storage destination, a data length, and a used protocol.

  Now, a case where a payload is transmitted and received in the protocol processing system will be described. First, assume that the payload to be transmitted exists in the system memory.

  As shown in FIG. 4, it is assumed that payloads (payload1, payload2, and payload3) to be transmitted are fragmented and arranged at addresses starting with Address A, Address B, and Address C on the system memory. When these payloads are transmitted together as a packet under these conditions, the transmission address, data length, destination, and link information of each fragment area are described as a series of transmission packet descriptors in the transmission packet descriptor.

  In the transmission address field, address information managed by the system memory is described, and the head address of the fragmented packet is described. Subsequently, the length from the head address is described in the data length field, and the destination field describes the device name to which the packet generated by the protocol processor is sent via the communication buffer.

  In the link information, “Next” is described when a descriptor following the descriptor exists, and “End” is described when it does not exist. That is, a transmission packet descriptor that constitutes one packet is from the next descriptor in which the head or “End” is described to the descriptor in which the next “End” is described.

  FIG. 5 shows the correspondence between the memory map, the transmitted packet, and the transmission packet descriptor table.

  In order to configure as a packet, a header area is described in the first descriptor. However, when all headers are created by the 101 protocol processor, the header area may be omitted. Subsequently, the payload of the packet to be transmitted is divided and described. If it is not divided, it is sufficient to describe only one descriptor. In this way, the 106 CPU reads the transmission packet descriptor table, and the 106 CPU controls the 105 DMAC so that DMA is performed from the 107 system memory to the 101 protocol processor for each descriptor.

  At this time, the destination field which is a constituent element of the descriptor is also transmitted to the protocol processor 101 together with the header or payload on the system memory. When transmission to the descriptor of the link information “End” is completed, the protocol processor 101 creates a header while referring to the protocol database 103 that matches the destination. When the creation of the header is completed, it is transmitted as a packet to the communication buffer 102 and transmitted to a predetermined destination. In the example shown in FIG. 1, the data is transferred to an area on the MAC 104 or system memory that is a link layer control device.

  The packet that first passes through the protocol processor is a simple IP packet composed of a series of IP Header-TCP (UDP) header and payload as shown in FIG.

  Next, a description method of a transmission packet descriptor when the encapsulation protocol is applied will be described. FIG. 7 illustrates a memory map, a packet format, and a transmission packet descriptor table for creating a packet to which an IP encapsulation protocol is applied. In this example, a packet composed of “Headed” and “payload” is already imaged on the memory map. As can be seen from the transmission packet descriptor table up to the 4th line, the destination up to the 4th line is MAC in the packet creation example shown in FIG. 5, but it is Adrs E in the example of FIG.

  When the execution up to the fourth line of the descriptor of FIG. 7 is completed, the IP packet composed of Header and Payloads 1 to 3 created by the protocol processor is transferred onto Address E shown in the memory map of FIG. Next, in the 5th and 6th lines of the descriptor, packets are created as new Header 'and payload.

  These are transferred again to the protocol processor 101, and the packet format developed on the communication buffer becomes the encapsulation packet format shown in FIG. In this way, it is possible to define the packet format such as the presence or absence of encapsulation only by the description of the transmission packet descriptor.

  Next, we will describe in detail the behavior during reception. When a PHY (not shown) receives a packet from the media, the packet is transferred to the MAC 104, and after being processed in the link layer, transferred to the communication buffer 102. In the communication buffer 102, the received packet information and the received device information are transferred to the protocol processor 101. Since the protocol processor 101 recognizes that the packet is from the media because there is device information of the reception source, it can refer to the protocol database 103 suitable for the packet. When the analysis of the protocol is completed, the protocol processor 101 issues an interrupt to the CPU 106 and notifies the CPU 106 or notifies the CPU 106 that the received packet has arrived. Upon receiving the notification, the CPU 106 receives the packet length and protocol information that has arrived at the protocol processor 101, and describes them in the received packet descriptor.

  An example of the received packet descriptor table is shown in FIG. The received packet descriptor is described by one received packet descriptor with one received packet in order to execute processing for each received packet. In the example of the received packet descriptor in FIG. 9, since the packet is not encapsulated in the first row of the table, the packet received from the MAC is passed to the upper layer together with the analysis result of the protocol processor 101.

  However, the received packet described by the descriptor in the second line is transferred to the communication buffer 102 for analysis by the protocol processor 101 again after removing the header that was first analyzed and extracted. At that time, the transmission source is set as Address H ′ obtained by removing the header extracted in the first analysis from Address H, and is transferred to the communication buffer.

  Since the payload applied to the protocol processor 101 again is not MAC but Address H ′, a different protocol database is selected, and processing based on the database is performed. A flexible analysis is possible even for the received packet encapsulated in this way.

(Second Embodiment)
In the first embodiment, a simple encapsulation protocol has been described. However, in the case of a VPN or the like in which the encapsulation protocol is actually used, a security protocol such as IPSec may be applied as described in the conventional example. Many.

  This is because the encapsulated packet is transmitted using a public network such as the Internet. In other words, since the possibility of sending / receiving a packet that is encapsulated maliciously or accidentally on the network cannot be denied, communication is ensured by encrypting or authenticating the packet.

  FIG. 2 shows a block diagram in which an IPSec protocol processor is connected separately from the TCP (UDP) / IP protocol processor. In the configuration of FIG. 2, an IPSec protocol processor 209 is further connected between the communication buffer and the shared bus from the block diagram in the first embodiment. The IPSec protocol processor 209 has a plurality of Security Policy DataBases 210 for each transmission destination, and can adopt an encryption method and an authentication method according to each.

  In IPSec, two types of headers, an AH (Authentication Header) header and an ESP (Encrypt Security Payload) header, are added to an IP packet. There are three operation modes, IPSec (AH), IPSec (ESP), and IPSec (AH + ESP), according to these two types of header application methods, and each has a transport mode and a tunneling mode. The AH header is also called an authentication header, and guarantees the authenticity of the packet over the entire IP packet. The ESP header has an authentication function in addition to the encryption of the payload, and authentication after the ESP header is possible simultaneously with the encryption.

  When ESP authentication is performed, ESP Authentication Data is added to the end of the packet as authentication data. When authenticating and encrypting with AH + ESP, the authentication function of ESP: Authentication Data is not added because the ESP authentication function is not used. Since IPSec (ESP) is encryption and authentication after the payload, the encryption and authentication processing of the payload is performed before processing the TCP (UDP) / IP protocol processor, so the processing flow in this embodiment is directly Omitted because it is not involved in

  Next, the procedure up to the transmission of the IPSec packet in the protocol processing system of FIG. 2 will be described.

  First, FIG. 10 shows an example of a transmission packet descriptor when creating an AH header in the transport mode in IPSec. Although the contents are almost the same as the example of FIG. 5 described in the first embodiment, the destination of the generated packet is IPSec (AH). In this case, all the once created IP packets are transferred to the IPSec protocol processor 209, and an AH header is created. Since the original IP packet is already stored in the communication buffer 202, the IPSec (AH) packet in the transport mode can be transmitted by transferring the AH header from the IPSec protocol processor 209 to the communication buffer 202.

  In the case of the tunneling mode (AH), only the previous IPSec (AH) creation procedure is overlapped with the IP tunneling operation. Therefore, like the transmission packet descriptor shown in FIG. 11, first, a descriptor for executing the tunneling protocol is described in the first to fourth lines. Next, these encapsulation IP packets are transferred to the IPSec protocol processor using the IP packets created by the descriptor of the new IP header and finally the descriptors of the first to fourth lines as the payload. For this reason, the destination of the descriptor on the fifth and sixth lines is set to IPSec (AH).

  Accordingly, IPSec (AH) processing is performed in the IPSec protocol processor 209. Then, similarly to the processing performed by the TCP (UDP) / IP protocol processor, it is possible to use an authentication algorithm corresponding to the destination using the Security Policy Database corresponding to the destination IP address. As a result, the created AH header is transferred to the communication buffer 202, and an IP Header 'for tunneling and an IP packet to be tunneled are output following the AH header.

  As described above, the operation in which the TCP (UDP) / IP protocol processor processes the tunneling protocol in cooperation with other protocol processors in IPSec (AH) has been described. Also in this embodiment, the tunneling protocol can be flexibly handled by controlling the input / output destination of the IP packet in the communication buffer by the descriptor more than in the first embodiment.

  In addition to the above-described embodiment, various tunneling protocols such as IPv6 and L2TP are implemented by implementing a corresponding protocol processor, and are also included in the scope of the present invention.

  The embodiment of the present invention can be realized by, for example, a computer executing a program. Also, means for supplying a program to a computer, for example, a computer-readable recording medium such as a CD-ROM recording such a program, or a transmission medium such as the Internet for transmitting such a program is also applied as an embodiment of the present invention. Can do. The above program can also be applied as an embodiment of the present invention. The above program, recording medium, transmission medium, and program product are included in the scope of the present invention.

It is a figure which shows an example of the protocol processing system which concerns on the 1st Embodiment of this invention. It is a figure which shows an example of the protocol processing system which concerns on the 2nd Embodiment of this invention. It is a figure which shows an example of the transmission packet descriptor table which concerns on embodiment of this invention. It is a figure which shows the memory map of the fragmented transmission payload data. It is a figure explaining the correspondence of a memory map, a transmission packet descriptor, and a packet format. It is a figure which shows the packet format of TCP (UDP) / IP. It is a figure explaining the correspondence of a memory map, a transmission packet descriptor, and a packet format in the case of IP encapsulation. It is a figure which shows the IP packet format by which IP encapsulation was carried out. It is a figure which shows the memory map corresponding to a reception packet descriptor table and a descriptor. It is the figure explaining the response | compatibility with the memory map concerning 2nd embodiment of this invention, a transmission packet descriptor, and a packet format. It is a figure which shows the transmission packet descriptor and packet format in IPSec (AH). It is a network diagram using a VPN tunnel via the Internet. It is a figure which shows the protocol format used by IPSec. It is a figure which shows the protocol format used by L2TP. It is a figure which shows an example of the protocol processing system in a prior art example. It is a figure which shows an example of the IPSec protocol processing system in a prior art example.

Explanation of symbols

101: TCP (UDP) / IP protocol processor 102: Communication buffer 103: Protocol database 104: MAC (link layer control device)
105: DMAC
106: CPU
107: System memory 108: Shared bus 201: TCP (UDP) / IP protocol processor 202: Communication buffer 203: Protocol database 204: MAC (link layer controller)
205: DMAC
206: CPU
207: System memory 208: Shared bus 209: IPSec protocol processor 210: Security policy database

Claims (6)

A protocol processor for generating and analyzing TCP (UDP) / IP protocols;
A communication buffer capable of temporarily holding a packet created by the protocol processor and transferring the held packet to a destination device designated in advance;
A plurality of protocol databases storing protocol information corresponding to the pre-designated destination device;
A MAC device that performs link layer processing;
A DMA controller for transmitting header information;
A CPU for executing a protocol control program;
A system memory for storing the CPU program entity and packet information;
A protocol processing system comprising:
By giving the destination instruction of the created packet when giving the header creation instruction of each layer to the protocol processor, the protocol processor creates a header by searching the protocol database according to the destination and finishes the creation. A protocol processing system characterized in that packet information is MAC output based on a destination instruction or written back to an arbitrary address in the system memory.   The protocol processing system according to claim 1, wherein IPSec processing is executed as a tunneling protocol.   The protocol processing system according to claim 1, wherein IPv6 processing is executed as a tunneling protocol.   The protocol processing system according to claim 1, wherein L2TP processing is executed as a tunneling protocol. A protocol processor for generating and analyzing a TCP (UDP) / IP protocol, and a communication buffer capable of temporarily holding a packet created by the protocol processor and transferring the held packet to a destination device designated in advance A plurality of protocol databases storing protocol information corresponding to the destination device designated in advance, a MAC device that performs link layer processing, a DMA control device that transmits header information, and a protocol control program A protocol processing method in a protocol processing system having a CPU and a system memory for storing an entity of the CPU program and packet information,
Providing a destination instruction for a created packet when giving a header creation instruction for each layer to the protocol processor;
The protocol processor creates a header by performing a search to a professional database according to a destination;
A step of outputting the created packet information based on the destination instruction by MAC or writing it back to an arbitrary address in the system memory;
A protocol processing method characterized by comprising:   The program for making a computer perform each process of the method of Claim 5.

Images