WO2000019678A2 - Arrangement and method for encoding and decoding digital data according to the internet protocol - Google Patents

Abstract

The invention relates to arrangements and methods that provide a simple means of making new transport services and security services created in Internet Protocol Version 6 or IPsec accessible to applications based on Internet Protocol Version 4. According to the invention, a mapping unit (106, 124) is provided for mapping data that exist in a first protocol format (115) onto data that can be processed by a second network layer (107). Said second network layer (107) encodes the data (116) conveyed to it by the mapping unit (106) in such a way that a second internet protocol format, e.g. IPV6, IPsec is created.

Description

description

Arrangement and method for coding and decoding digital data according to the Internet protocol

The next generation of the Internet Protocol (IP) is currently being developed by the Internet Engineering Task Force (IETF). The next generation of the Internet Protocol is called Version 6 of the Internet Protocol (IPv6). The Internet Protocol is a protocol of the network layer within the framework of the OSI communication layer architecture (Open Systems Interconnection). The Internet Protocol is the central element for linking different, autonomous communication networks to the worldwide Internet.

The format of the Internet protocol is described for example in [1].

An overview of version 6 of the Internet Protocol (IPv6) can be found in [2].

As part of the international work on IPvβ, it is known to develop security extensions to the Internet protocol. These security enhancements, which can also be implemented as part of the current version 4 of the Internet protocol, are known as IPsec. These are described for example in [3].

In their message format, the IPsec services use the so-called IP authentication header, which ensures the integrity and authenticity of IP datagrams, and the so-called "IP encapsulating payload", with which the confidentiality and integrity of the Data from higher protocol layers, for example the User Datagram Protocol (UDP) or the Transport Control Protocol (TCP) is saved in the so-called "transparent mode" or from entire IP datagrams in the so-called "tunnel mode". The so-called OSI communication layers are described in detail in [4].

So-called IPsec standards are known from [5], [6], [1], [8], in which two methods of assigning cryptographic keys are provided: In the context of so-called "host-oriented keying", all use Processes and users that communicate between two end devices via IPv6 or via an IPv4 extended by IPsec, the same cryptographic key material. As part of the so-called "user-oriented keying", different users or processes on the two end devices that communicate with one another can be assigned different cryptographic keys. With IPv4, known transport system interfaces are used for communication, for example the Berkeley sockets, the streams TLI, the insockets, etc. However, this means that applications, i.e. Any programs or processes from higher network layers that can use the new security services from IPsec or generally the new services from IPv6 are currently being developed to include the established transport system interfaces.

An Internet key management component (Internet Key Management Protocol, IKMP) and associated framework conditions in the Internet are in the form of so-called Internet Drafts in [9],

[10], [11], [12], [13], [14], [15], [16], and [17].

A major problem, however, is that existing applications use the novel services provided by IPsec or

IPvβ made available, can not be used easily. So far, the new services cannot be addressed without additional measures.

From [1] it is known that the applications which want to use the services of IPvβ or IPsec have to be adapted to the new transport system interfaces by modification ' of applications. It is also known from this document to use configuration files for use for the new services. These configuration files are static on the one hand and components of the IPsec or IPvβ implementations on the other. These configuration files tell an IPsec- or IPvβ-capable system how transport services have to be provided for existing applications that are not IPsec- or IPvβ-capable. In these two procedures, however, there is a considerable disadvantage in the fact that the modification of already existing applications is not generally feasible in view of the considerable amount of existing applications. Furthermore, no interaction with applications or users is supported in IPsec or IPv6 implementations.

The invention is based on the problem of specifying a method and an arrangement for encoding digital data in accordance with the Internet Protocol and a method and an arrangement for decoding digital data in accordance with the Internet Protocol, in which it is possible in a simple manner to which were developed for an older version of the Internet Protocol to make the new Internet Protocol services accessible.

The problem is solved by the arrangements and methods with the features according to the independent patent claims.

An arrangement for encoding digital data according to the Internet protocol has a first means with which the data are encoded according to the format of a first Internet protocol to data of a first Internet protocol format. Furthermore, a mapping unit is provided with which the data of the first Internet protocol format are mapped onto data that can be processed by a second means, the data being encoded according to the format of a second Internet protocol into data of a second Internet protocol format with the second means . According to the arrangement for decoding digital data that are available in a second Internet protocol format, according to the Internet protocol, a second means is provided with which the data are decoded into data of a decoded second Internet protocol format in accordance with the format of a second Internet protocol. Furthermore, an imaging unit is provided with which the data of the decoded second Internet protocol format are mapped onto data which can be processed by a first means, the data being decoded into the data in accordance with the format of a first Internet protocol.

In a method for coding digital data according to the Internet protocol, the data are coded in accordance with the format of a first Internet protocol to form data of a first Internet protocol format. The data of the first Internet protocol format are mapped to data that can be processed in a further coding according to a second Internet protocol format. In a last step, the data are encoded according to the format of a second Internet protocol to data of a second Internet protocol format.

In a method for decoding digital data which are in a second Internet protocol format according to the Internet protocol, the data are decoded according to the format of a second Internet protocol to form a decoded second Internet protocol format. Furthermore, the data of the decoded second Internet protocol format are mapped onto data that can be processed in a decoding according to a first Internet protocol format. The data is finally decoded into the data in accordance with the format of a first Internet protocol.

The arrangement and the method make it possible in a very simple manner to old applications that only use the services of the Internet Protocol version 4 or old versions can also make "IPsec or IPv6" capable. This means that the arrangement or the method makes it possible, without having to change the applications themselves, the new services offered by IPsec or Ipvβ, generally more recent versions of the Internet protocol, even with the "old ones "To use applications.

The invention can be clearly seen in the fact that in the previous architecture of the OSI

Communication layers an intermediate layer between the Internet protocol layer (IP layer), which is also referred to as a network layer within the framework of the OSI network architecture, an intermediate layer is inserted between the network layer of the "old" IPv4 and the "new" IPvβ or

IPsec. This intermediate layer serves as a generic means to provide future IPvβ transport services to applications based on the existing version 4 of the Internet protocol and thus to support their migration into the new network infrastructure.

This intermediate layer can be implemented or integrated both at the application level and at the operating system level. It is also possible to implement a so-called proxy service with this intermediate layer.

Advantageous developments of the invention result from the dependent claims.

In a further development, it is advantageous both for the arrangements and for the methods that the mapping unit has a parameter determination unit for determining parameters or that additional parameters are determined for the mapping, which encode the data from the first Internet protocol format to data in the second Internet protocol format are required. In a further development, it is advantageous to design the parameter determination unit according to at least one of the following types or to determine the parameters in one of the following ways: depending on the arrangement itself,

depending on a user of the arrangement,

- depending on a process currently being carried out by the arrangement, or

- to determine the parameters from a database to which the arrangement has access, for example from a local database of the arrangement.

In the figures, an embodiment of the invention is shown, which is explained in more detail below.

Show it

1 shows a sketch of the arrangement for coding, transmission and decoding of digital data;

Figure 2 is a sketch of the procedure for mapping IPv4 applications onto data for IPvβ or IPsec.

1 shows a first arrangement 100 for coding digital data.

The OSI communication layers used in the description, which are described in detail in [4], are used below for illustrative purposes.

An application (application), preferably an application program, which generates digital data to be transmitted in accordance with the Internet protocol, is logically arranged in a so-called application layer 101. So-called protocol data units (PDU) are exchanged between the individual layers. The individual PDUs 111 are uniquely assigned to the individual layers.

Coding regulations are carried out in the individual layers, which depend on the chosen known implementation of the layer.

The respective layer can be implemented both in software and in hardware.

In the context of the arrangement, each layer is designed as a means with which the individual method steps are implemented in accordance with the communication protocol to be implemented in the respective layer.

The PDUs 111 of the application layer are fed to a presentation layer 102.

After processing the PDU 111 from the application layer 101 in accordance with the regulations of the presentation layer, a PDU 112 of the presentation layer 102 is fed to a communication control layer 103.

After processing the PDU 112 of the presentation layer 102 in accordance with the protocol used in the communication control layer 103, a PDU 113 of the communication control layer is fed to a transport layer (Transport Layer) 104.

The transport control protocol (TCP) or the user datagram protocol (UDP) is preferably implemented in the transport layer 104. After encapsulation of the PDU 113 from the communication control layer 103, the transport layer 104, ie the means by which the transport Layer is implemented, a PDU 114 of the transport layer 104 is fed to a network layer 105.

The Internet protocol (IP), either version 4 or also version 6 or also IPsec, is usually implemented in the network layer 105. Within the scope of the invention, a first Internet protocol is implemented in the network layer, i.e. the data that are supplied to the network layer 105 in the form of the PDU 114 of the transport layer 104 are in accordance with the format of a first Internet protocol

(IPv4) encoded to data that are in a first Internet protocol format.

The data of the first Internet protocol format are fed as PDU 115 to the network layer 105 of an imaging unit 106, with which an intermediate layer 106 is realized. With the mapping unit 106, the data that are in the first Internet protocol format 115 are mapped to data that can be processed by a second means, a second mediation layer 107.

The data are supplied to the second network layer 107 in a format that can be processed by the second network layer in an interlayer PDU 116. In the second network layer 107, which is implemented by a second means, the data is encoded in accordance with the format of a second Internet protocol (Ipv6, IPsec) to data which are in a second Internet protocol format, which is in the form of a PDU 117 of the second Internet Protocol format of a transmission link layer (Data Link Layer) 108 are supplied.

In the transmission security layer 108, a PDU 118 of the transmission security layer 108 is formed and fed to the physical transmission layer 109. The processes involved in mapping the PDU 115 from the network layer 105 in the intermediate layer 106 are explained in more detail below with reference to FIG. 2.

An application based on the Internet Protocol Version 4 201 usually uses existing IPv4 transport system interfaces, e.g. Berkeley sockets or streams TLI. The existing transport system interfaces 202 are fully provided by the intermediate layer, i.e. for network layer 105 that appears

Imaging unit 106, i.e. the intermediate layer 106, as a transmission security layer.

The PDU 115 of the network layer 105 picked up by the intermediate layer 106 is mapped to the new transport system interfaces 203 of a second Internet protocol (IPv6, IPsec). The new transport system interfaces 203 have their own security interfaces 204. Depending on the transport services implemented in the second network layer 107, for example additional security services, additional parameters for the coding according to the second Internet protocol format are required in order to be able to use these services. An overview of various security parameters that are required in the context of IPsec and IPv6 are described in connection with the respectively provided procedures for IPsec, IPv4 for cryptographic data security in [4].

In the context of this figure, it is also provided that an Internet key management component (Internet Key Management Protocol, IKMP) 205 is taken into account or integrated, as described in [9], [10], [11], [12], [13], [14], [15], [16], and [17].

The encoded data is in the form of data packets 112, which contain the data in the second Internet protocol format, transmitted from the first arrangement 100 to a second arrangement 120 via a transmission unit 110.

The arrangements can be implemented both in software and in hardware, for example in a computer or in a special digital-electronic circuit adapted to the task.

In the second arrangement 120, the data packets 112 are received and fed to a physical layer 121 of the second arrangement 120. After encapsulation in accordance with the protocol of the physical layer 121, a PDU 131 of the physical layer 121 of the transmission security layer 122 is fed to the second arrangement 120.

After further decapsulation, i.e. Decoding in the transmission data link layer 122 is supplied to a PDU 132 of the transmission data link layer 122 of the second network layer 123 of the second arrangement 120, in which a debacking in accordance with the second Internet protocol format, i.e. according to IPv6 or IPsec. As part of this decoding, for example, the cryptographic security of the transmission is carried out in accordance with IPvβ or IPsec.

The decoded data in the second protocol format is stored as PDU 133 of the mapping unit 124, i.e. H . supplied to the intermediate layer 124 and again subjected to imaging. The image in the intermediate layer 124 is inverse with respect to the image in the intermediate layer 106 in the first arrangement 100.

The parameters required for processing can be determined in various ways. The parameter determination unit of the intermediate layer 106, 124 must be configured in accordance with the determination. The additionally required parameters can, for example, be end-system specific, user- be configured specifically or also process-specifically. In this context, specific to the end system means dependent on the arrangement used in each case. In this context, user-specific means dependent on the respective user who is currently using the arrangement. In this context, process-specific means dependent on the process that is currently being carried out by the arrangement.

The parameters can also be derived from e.g. locally available security policy databases or general databases can be queried or also determined interactively with a user of the arrangements.

According to the illustration in the intermediate layer 124, a PDU 134 is present, which is provided by the network layer 125, which according to the

"old" Internet Protocol (IPv4) is realized, can be processed. The PDU 134 of the intermediate layer 124 becomes the network layer 125, i.e. to the first means, and decoded according to the first Internet protocol format, i.e. decapsulated.

As a result of the encapsulation, a mediation layer 125 forms a PDU 135, which is fed to the transport layer 126. A transport layer 126 forms a PDU 136 which is fed to the communication control layer 127.

From the communication control layer 137, a PDU 137 is supplied to the communication control layer 137 of the presentation layer 128. A display unit 128 forms a PDU 138, which is fed to the application layer 129.

The double arrows in FIG. 1 indicate the bidirectional communication between the arrangements 100, 120. Some alternatives to the arrangements and methods described above are presented below.

Both the first arrangement 100 and the second arrangement 120 can also be implemented independently, without the transmission medium, i.e. the transmission unit 110.

Furthermore, the transmission unit 110 is to be understood in such a way that any number of routers or bridges can be provided as switching units. The transmission unit 110 thus represents only a logical channel between the first arrangement 100 and the second arrangement 120.

The invention can clearly be seen in that between the network layer with which the "old" Internet Protocol version 4 is implemented and a second network layer with which the "new" Internet protocol (IPvδ, IPsec) is implemented Intermediate layer 106, 124 is provided, with which the data formats of the IPv4 protocol format are mapped to the IPvβ protocol format.

The following publications are cited in this document:

[1] R. Hinden, IP Next Generation Overview, Communications of the ACM, Vol. 39, No. 6, pp. 61-71, June 1996

[2] D. Wagner, S. Bellovin, A "Bump in the Stack" Encryptor for MS-DOS Systems, in Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, pp. 155-160, February 1996

[3] RFC 1825, Security Architecture for the Internet Protocol, R. Atkinson, Network Working Group, pp. 1-22, August 1995

[4] A. Tanenbaum, Computer Networks, Wolfram's Fachverlag, 2nd edition, ISBN 3-925328-79-3, pp. 17-24, 1992

[5] R. Atkinson, RFC 1826, IP Authentication Header, August 1995

[6] R. Atkinson, RFC 1827, IP Encapsulating Security Payload, August 1995

[7] P. Metzger & W. Simpson, RFC 1828, IP Authentication using Keyed MD5, August 1995

[8] P. Kam, P. Metzger & W. Simpson, RFC 1829, The ESP DES-CBC Transform, August 1995

[9] T. Hardjono, B. Cain, N. Doraswamy, A Framework for

Group Key Management for Multicast Security, July 98, available on the Internet on September 29, 1998 at

Address: http: // www. ietf. org / html. charters / ipsec-charter .html

[10] D. Piper, The Internet IP Security Domain of Interpretation for ISAKMP, July 7, 1998, available on the Internet on September 29, 1998 at the address: http: // www. ietf. org / html. charters / ipsec charter. html

[11] D. Maughan, M. Schertier, M. Schneider, J. Turner, Internet Security Association and Key Management Protocol (ISAKMP), July 3, 1998 available on the Internet on September 29, 1998 at: http: / / www. ietf.org/html.charters/ipsec-charter.html

[12] D. Piper, A GSS-API Authentication Mode for ISAKMP / Oakley, Dece ber 18, 1997 available on the Internet on September 29, 1998 at: http: // www. ietf. org / html. charters / ipsec charter. html

[13] R. Pereira, S. Anand, B. Patel, The ISAKMP Configuration Method, May 13, 1998 available on the Internet on September 29, 1998 at: http: // www. ietf. org / html. charters / ipsec charter. html

[14] D. Harkins, D. Carrel, The Internet Key Exchange (IKE), June 1998, available on the Internet on September 29, 1998 at

Address: http: // www. ietf. org / html. charters / ipsec charter. html

[15] B.V. Patel, M. Jeronimo, Revised SA negotiation mode for ISAKMP / Oakley, November, 1997 available on the Internet on September 29, 1998 at

Address: http: // www. ietf. org / html. charters / ipsec-charter.html

[16] R. Pereira, Extended Authentication Within

ISAKMP / Oakley, May 13, 1998 available on the Internet on September 29, 1998 at the address: http: // www. ietf.org/html. charters / ipsec charter. html

[17] R. Thayer, PKI Requirements for IP Security, September 13, 1998 available on the Internet on September 29, 1998 at: http: // www. ietf. org / html. charters / ipsec-charter .html

Claims

claims 1. Arrangement for encoding digital data according to the Internet Protocol (IP), with a first means with which the data are encoded according to the format of a first Internet protocol (IPv4) into data of a first Internet protocol format, - With a mapping unit, with which the data of the first Internet protocol format are mapped to data that can be processed by a second means, and - With the second means with which the data are encoded according to the format of a second Internet protocol (IPv6) to data of a second Internet protocol format. 2. Arrangement for decoding digital data that are in a second Internet protocol format according to the Internet Protocol (IP), with a second means with which the data are decoded according to the format of a second Internet protocol (IPv6) to data of a decoded second Internet protocol format, with an imaging unit with which the data of the decoded second Internet protocol format are mapped onto data which can be processed by a first means, and - With the first means with which the data is decoded into the data in accordance with the format of a first Internet protocol (IPv4). 3. Arrangement according to claim 1 or 2, in which the mapping unit has a parameter determination unit for determining parameters which are required for coding the data from the first Internet protocol format to data in the second Internet protocol format. 4. Arrangement according to claim 3, in which the parameter determination unit is designed according to at least one of the following types: the parameter determination unit is configured depending on the arrangement itself, the parameter determination unit is configured depending on a user of the arrangement, the parameter determination unit is configured as a function of a process that is currently being carried out by the arrangement, or the parameter determination unit determines the required parameters from a database to which the arrangement has access. . 5. Method for coding digital data according to the Internet Protocol (IP), in which the data are encoded according to the format of a first Internet protocol (IPv4) to data of a first Internet protocol format, - In which the data of the first Internet protocol format are mapped to data that can be processed by a second means, and - In which the data are encoded according to the format of a second Internet protocol (IPvβ) to data of a second Internet protocol format. 6. Method for decoding digital data which are in a second Internet protocol format according to the Internet Protocol (IP), in which the data are decoded according to the format of a second Internet protocol (IPvβ) to data of a decoded second Internet protocol format, - in which the data of the decoded second Internet protocol format are mapped onto data which can be processed by a first means, and - in which the data are decoded into the data in accordance with the format of a first Internet protocol (IPv4). 7. The method according to claim 5 or 6, in which parameters are additionally determined which are required for coding the data from the first Internet protocol format to data in the second Internet protocol format. 8. The method according to claim 7, wherein the parameters are determined in at least one of the following ways: the parameters are determined depending on the arrangement itself, the parameters are determined depending on a user of the arrangement, - The parameters are determined depending on a process that is currently being carried out, or - The parameters are determined from a database.