Sign In to Follow Application
View All Documents & Correspondence

An Apparatus And A Method For Reporting The Error Of Each Level Of The Tunnel Data Packet In A Communication Network

Abstract: Abstract An Apparatus and a Method for Reporting the Error of each Level of the Tunnel Data Packet in a Communication Network The invention provides methods and devices for reporting and parsing the errors of a packet based on IPSec protocol family in a communication network. Concretely, the reserved field in ICMP security failure message is used to denote the error type at the second level of the error in the packet. With the aid of the solution provided by the invention, it is possible to report the error types for a tunnel packet which has an error in detail. And the source termination device can ascertain the error types of a tunnel packet, so as to eliminate the error.

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
23 January 2009
Publication Number
23/2009
Publication Type
INA
Invention Field
COMPUTER SCIENCE
Status
Email
Parent Application
Patent Number
Legal Status
Grant Date
2019-06-04
Renewal Date

Applicants

ALCATEL LUCENT
54, RUE LA BOETIE, 75008 PARIS

Inventors

1. ZHANG, QINGSHAN,
NO.388 NINGQIAO ROAD, PUDONG, JINQIAO, SHANGHAI 201206,
2. MA, SONGWEI,
NO.388 NINGQIAO ROAD, PUDONG, JINQIAO, SHANGHAI 201206,
3. YAN, RENXIANG,
NO.388 NINGQIAO ROAD, PUDONG, JINQIAO, SHANGHAI 201206,
4. WEN, HAIBO,
NO.388 NINGQIAO ROAD, PUDONG, JINQIAO, SHANGHAI 201206,
5. BIN, FANXIANG,
NO.388 NINGQIAO ROAD, PUDONG, JINQIAO, SHANGHAI 201206,

Specification

An Apparatus and a Method for Reporting the Error of each Level of the Tunnel Data Packet in a Communication Network Technical Field The present invention relates to telecommunication network, especially to termination devices and method for, in a telecommunication network, especially IP network, reporting and parsing the errors of packets based on IPSec (Internet Protocols Security) protocol family. Background of the Invention IPSec protocol family is a set of network secure access protocols widely-used in IP layer. By using IKE (Internet Key Exchange) protocol, IPSec protocol establishes dedicated a secure communication tunnel between two termination devices for a particular secure communication through negotiation. After that, IP packets belonging to said particular secure communication will be transmitted between the two termination devices at the ends of the tunnel. For conciseness, an IP packet based on IPSec protocol for the communication via secure communication tunnel will be referred to as a tunnel packet, unless otherwise specified. In particular, after a secure communication tunnel has been established, before forwarding an IP packet belonging to the particular communication, the source termination device, namely the termination device which the corresponding host of the source address of the IP packet corresponds to, should: 1. judging, whether the IP packet belongs to a particular secure communication, i.e. secure communication based IPSec protocol family, according to relevant information such as the destination address and source address of the tunnel packet. 2. if the IP packet belongs to a particular secure communication, performing encryption, encapsulation etc. on the IP packet by using the Security Association (SA) including encryption key and encryption algorithm which is in correspondence with the particular secure communication. Then, the IP packet becomes a tunnel packet. 3. The tunnel packet goes through the Internet via the secure communication tunnel corresponding to said particular secure communication and gets to the destination termination device, namely the termination device which the corresponding host of the source address of the IP packet belongs to. After receiving the tunnel packet, the destination termination device will, according to the corresponding Security Association, perform decryption etc. on the packet and forward the decrypted packet to the host in correspondence with the destination address of the packet. In practice, the tunnel packet may have errors for reasons like hack attack, the error of the computer system itself, the mismatch of the encryption and decryption algorithm etc. The errors will fall into 6 categories as below: (1) wrong SPI (security policy indication); (2) verification failed; (3) encapsulation failed; (4) decryption failed; (5) verification needed; (6) authorization needed. For the convenience in diagnosing and eliminating errors, when a destination termination device finds error(s) in a tunnel packet, it needs to report the corresponding error(s) to the source termination device. According to the error report, the source termination device can be aware of the errors in the packet it has sent and try to get rid of them. In the prior art, the errors of a tunnel packet are reported by the destination termination device to the source termination device via ICMP (Internet Control Message Protocol) security failure message. However, the existing ICMP security failure message has many drawbacks, i.e.: the granularity of error type reported to source termination device is so large (not quite detailed) that it goes beyond the secure access granularity provided by IPSec protocols family. Hence, once a tunnel packet encounters errors, based on existing error reporting schemes, after the destination termination device sends back the ICMP security failure message, the source termination device can only know the rough error type of the tunnel packet, it is not possible for it to ascertain the error accurately. Therefore, people need an optimized error reporting solution, which ca:n make the destination termination device report the errors of a tunnel packet accurately, so that it becomes more accurate and convenient for the source termination device to ascertain and diagnose the error. Summary of the Invention The invention is proposed to solve the aforementioned problems in the prior art. According to the minimum granularity of network secure access provided by IPSec protocols family, the six existing kinds of rough errors are further fractionized. And, the fractionized error will be reported to the source termination device together with its parent error. According to the first aspect of the invention, there is provided a method for, in a termination device (e.g. tunnel server) of a telecommunication network, reporting the errors of a packet based on IPSec protocol family, comprising steps of: receiving a packet from a source termination device; judging whether the packet has an error; if the packet has an error, generating error indicating message which indicates the error types at each level of the error in the packet; sending the error indicating message to said source termination device. Said error types at each level including the error types at the first level and the error types at the second error level, wherein, the error types at the second error level comprising one or more sub-error-type of each error type at the first error level. According to the second aspect of the invention, there is provided a termination device of a telecommunication network, for reporting the errors of a packet based on IPSec protocol family, comprising; a receiving means, for receiving a packet sent by a source termination device via the Internet; a judging means, forjudging whether the packet has an error; a generating means for, if the packet has an error, generating error indicating message which indicates the error types at each level of the error in the packet; a sending means, for sending the error indicating message to said source termination device. Said error types at each level including the error types at the first level and the error types at the second error level, wherein, the error types at the second error level comprising one or more sub-error-type of each error type at the first error level. According to the third aspect of the invention, there is provided a method for, in a termination device (i.e. tunnel server) of a telecommunication network, parsing an error indicating message based on IPSec protocol family, comprising steps of: receiving the error indicating message which indicates the error types at each level of the error in a packet sent by this termination device to said remote termination device; analyzing to educe, from the error indicating message, the error types at each level of the error in said packet. According to the forth aspect of the invention, there is provided a termination device (i.e. tunnel server) of a telecommunication network, for parsing an error indicating message based on IPSec protocol family, comprising: a receiving means, for receiving the error indicating message which indicates the error types at each level of the error in a packet sent by this termination device to said remote termination device; an analyzing means, for analyzing to educe, from the error indicating message, the error types at each level of the error in said packet. With the termination devices and the corresponding methods provided by the invention, it becomes possible to report the error of a tunnel packet in details. Hence, the source termination device can ascertain the error types of a tunnel packet, so as to diagnose and eliminate the error. Brief Description of the Drawings Other features and advantages of the present invention will appear in the following description of non-limiting exemplary embodiments, with reference to the appended drawings. Fig. 1 illustrates the structure of a network based on IPSec protocol family for secure communication via secure communication tunnel; Fig. 2 illustrates the format of an ICMP security failure message defined in RFC2521 standard; Fig. 3 is the flow chart of a method for, in a termination device of a telecommunication network, for reporting the errors of a packet based on IPSec protocol family, according to an embodiment of the invention; Fig. 4 is a block diagram of a tunnel server in a telecommunication network, for reporting the errors of a packet based on IPSec protocol family, according to an embodiment of the invention; Fig. 5 illustrates the format of an ICMP security failure message for reporting the error of a tunnel packet concretely, according to an embodiment of the invention; Fig. 6 is the flow chart of a method for, in a termination device of a telecommunication network, parsing an error indicating message based on IPSec protocol family, according to an embodiment of the invention; Fig. 7 is a block diagram of a tunnel server of a telecommunication network, for parsing an error indicating message based on IPSec protocol family, according to an embodiment of the invention. Detailed description of embodiments According to the present invention, there are two kinds of relationship between termination devices and the hosts; Case I. The termination devices are separated from the hosts, and work at the two ends of secure communication tunnels as tunnel servers. At this time, a tunnel sever can control the secure communication of one or more hosts, as shown in Fig.l; Case II. The termination devices are integrated into the hosts, acting as secure communication controlling means. At this time, a termination device is mainly responsible for the secure communication of the host which it belongs to. According to need, the terminal device performs relevant process on the IP packets sent by the host to the network card and the ones received by the network card, especially the tunnel packets. Fig. 1 illustrates the structure of a network based on IPSec protocol family for secure communication via secure communication tunnel. The network comprises tunnel servers 1 and 2 corresponding to the termination devices in aforesaid Case I, a plurality of hosts under the control of these two tunnel servers, only host a and b out of them are shown in the figure for conciseness. The hosts a and b are performing a specific secure communication based on IPSec protocol family in Internet, via the secure communication tunnel between the two tunnel servers shown in Fig. 1. Once the secure communication tunnel for the specific secure communication between hosts a and b has been established, hosts a and b can start the secure communication: - The host a sends an IP packet to the host b. Obviously, this packet belongs to the specific secure communication, and needs to be processed based on IPSec protocol family and then gets through the Internet as a tunnel packet. - The IP packet sent out by the host a will arrive at tunnel server 1 shown in the figure first. According to the "destination address-source address" pair of the IP packet, tunnel server 1 can determine that the packet belongs to the specific secure communication between host a and host b. Thus, tunnel server 1 performs processes, such as encryption, encapsulation etc., on the packet based on corresponding Security Association. Then the IP packet becomes a tunnel packet which can go through the Internet in security. For this tunnel packet, tunnel server 1 is the source termination device. - Since the destination host i.e. host b is under the control of tunnel server 2, the tunnel packet will arrive at tunnel server 2 via the secure communication tunnel between tunnel server 1 and 2 belonging to the specific secure communication between host a and host b. For this tunnel packet, tunnel server 2 is the destination termination device. - Based on the technical solution provided by the present invention, after tunnel server 2 receives said tunnel packet from tunnel server 1, it will judge whether the packet has an error, and report the error in the packet concretely with error indicating message, e.g. ICMP security failure message, to tunnel server 1 via said secure communication tunnel. It can be easily understood that, for the termination device in aforesaid Case II, tunnel server 1 and tunnel server 2 shown in Fig.l will be located in host a and host b respectively to control the secure communication of the hosts. Other hosts which need secure communication based on IPSec will also be configured to have their own termination devices. Wherein, the process performed on the packet is the same as that in Case I, no more unnecessary details. For conciseness, the description hereunder will mainly focus on Case I. Being different from the prior art, the method for reporting the error in a tunnel packet provided by the present invention makes some improvements on the existing ICMP security failure message. Figure 2 illustrates the format of an ICMP security failure message defined in RFC2521 standard for reporting the error in a tunnel packet based on IPSec protocol family. From the figure, it can be seen that, an existing ICMP security failure message comprises 6 fields as; - Type, taking 40 as its value, denoting that the message is an ICMP security failure message; - Code, denoting the error type of the tunnel packet. As mentioned before, an existing ICMP security failure message only uses Code field for the error report, the errors are not fractionized well, and the granularity of error type is pretty large. Wherein, the values taken by the Code field and the corresponding error types (i.e., error types at the first level) are as follows, 0: wrong SPI (security policy indication); 1: verification failed; 2: decapsulation failed; 3: decryption failed; 4: verification needed; 5: authorization needed. Obviously, when an existing ICMP security message from a source termination device gets to the destination termination device, the source termination device can ascertain the error in the tunnel packet only to the extent described by the 6 types above. - Checksum, the checksum of the ICMP security failure message; - Reserved, in an existing ICMP security failure message, this field is set to '0'; - Pointer, the offset position in the IP header of the tunnel packet in correspondence with the ICMP security failure message of the SPI. If there is no SPI, this field should be set to '0'. - the IP header of the tunnel packet in correspondence with the ICMP security failure message, and the first 64-bit payload. By using the aforesaid ICMP security failure message as the error indicating message of a tunnel packet, the report granularity of the error in a tunnel packet will be restricted, the source termination device can not ascertain the exact type of the error accurately. And this is undesired for people to solve the problem. Fig. 3 is the flow chart of a method for, in a termination device of a telecommunication network, reporting the errors of a packet based on IPSec protocol family, according to an embodiment of the invention. Description of the method will be made hereunder with reference to Fig.3 in conjunction with Fig. 1 and Fig.5. Wherein, Fig. 5 illustrates the format of an ICMP security failure message for reporting the error of a tunnel packet concisely, according to an embodiment of the invention. The method starts with step SI01. In step SI01, tunnel server 2 receives a tunnel packet from tunnel server 2 for the specific secure communication between host a and host b. This tunnel packet may have some errors, the method enters step SI02. In step SI02, the received packet will be tested so as to judge if there is any error in it. E.g., the type error at the first level in correspondence with the Code field taking 5 as its value, the present invention has defined 6 sub-error-type for this error type at the first level (namely error types at the second level are subject to this error type at the fir

Documents

Application Documents

# Name Date
1 439-CHENP-2009 FORM-18 29-06-2010.pdf 2010-06-29
1 439-CHENP-2009-RELEVANT DOCUMENTS [03-08-2023(online)].pdf 2023-08-03
2 439-CHENP-2009 FORM-13 02-12-2010.pdf 2010-12-02
2 439-CHENP-2009-RELEVANT DOCUMENTS [26-08-2022(online)].pdf 2022-08-26
3 439-CHENP-2009-RELEVANT DOCUMENTS [18-09-2021(online)].pdf 2021-09-18
3 439-chenp-2009 correspondence others 02-12-2010.pdf 2010-12-02
4 439-CHENP-2009-RELEVANT DOCUMENTS [23-03-2020(online)].pdf 2020-03-23
4 0439-chenp-2009 pct.pdf 2011-09-03
5 439-CHENP-2009-IntimationOfGrant04-06-2019.pdf 2019-06-04
5 0439-chenp-2009 form-5.pdf 2011-09-03
6 439-CHENP-2009-PatentCertificate04-06-2019.pdf 2019-06-04
6 0439-chenp-2009 form-3.pdf 2011-09-03
7 Abstract_Granted 313705_04-06-2019.pdf 2019-06-04
7 0439-chenp-2009 form-1.pdf 2011-09-03
8 Claims_Granted 313705_04-06-2019.pdf 2019-06-04
8 0439-chenp-2009 drawings.pdf 2011-09-03
9 0439-chenp-2009 description (complete).pdf 2011-09-03
9 Description_Granted 313705_04-06-2019.pdf 2019-06-04
10 0439-chenp-2009 correspondence-others.pdf 2011-09-03
10 Drawings_Granted 313705_04-06-2019.pdf 2019-06-04
11 0439-chenp-2009 claims.pdf 2011-09-03
11 Marked up Claims_Granted 313705_04-06-2019.pdf 2019-06-04
12 0439-chenp-2009 abstract.pdf 2011-09-03
12 Correspondence by Agent_Notarized Assignment_31-08-2017.pdf 2017-08-31
13 439-CHENP-2009 FORM-3 10-06-2013.pdf 2013-06-10
13 439-CHENP-2009-ABSTRACT [29-08-2017(online)].pdf 2017-08-29
14 439-CHENP-2009 CORRESPONDENCE OTHERS 10-06-2013.pdf 2013-06-10
14 439-CHENP-2009-CLAIMS [29-08-2017(online)].pdf 2017-08-29
15 439-CHENP-2009 CORRESPONDENCE OTHERS 04-02-2014.pdf 2014-02-04
15 439-CHENP-2009-COMPLETE SPECIFICATION [29-08-2017(online)].pdf 2017-08-29
16 439-CHENP-2009 FORM-3 04-02-2014.pdf 2014-02-04
16 439-CHENP-2009-DRAWING [29-08-2017(online)].pdf 2017-08-29
17 439-CHENP-2009-FER_SER_REPLY [29-08-2017(online)].pdf 2017-08-29
17 439-CHENP-2009 FORM-3 15-10-2014.pdf 2014-10-15
18 439-CHENP-2009 CORRESPONDENCE OTHERS 15-10-2014.pdf 2014-10-15
18 439-CHENP-2009-FORM-26 [29-08-2017(online)].pdf 2017-08-29
19 439-CHENP-2009-FER.pdf 2017-03-08
19 439-CHENP-2009-OTHERS [29-08-2017(online)].pdf 2017-08-29
20 439-CHENP-2009-FORM 3 [12-08-2017(online)].pdf 2017-08-12
20 439-CHENP-2009-PETITION UNDER RULE 137 [29-08-2017(online)].pdf 2017-08-29
21 439-CHENP-2009-PETITION UNDER RULE 137 [29-08-2017(online)].pdf_2.pdf 2017-08-29
21 439-CHENP-2009-Proof of Right (MANDATORY) [29-08-2017(online)].pdf 2017-08-29
22 439-CHENP-2009-PETITION UNDER RULE 137 [29-08-2017(online)].pdf_2.pdf 2017-08-29
22 439-CHENP-2009-Proof of Right (MANDATORY) [29-08-2017(online)].pdf 2017-08-29
23 439-CHENP-2009-FORM 3 [12-08-2017(online)].pdf 2017-08-12
23 439-CHENP-2009-PETITION UNDER RULE 137 [29-08-2017(online)].pdf 2017-08-29
24 439-CHENP-2009-OTHERS [29-08-2017(online)].pdf 2017-08-29
24 439-CHENP-2009-FER.pdf 2017-03-08
25 439-CHENP-2009 CORRESPONDENCE OTHERS 15-10-2014.pdf 2014-10-15
25 439-CHENP-2009-FORM-26 [29-08-2017(online)].pdf 2017-08-29
26 439-CHENP-2009 FORM-3 15-10-2014.pdf 2014-10-15
26 439-CHENP-2009-FER_SER_REPLY [29-08-2017(online)].pdf 2017-08-29
27 439-CHENP-2009 FORM-3 04-02-2014.pdf 2014-02-04
27 439-CHENP-2009-DRAWING [29-08-2017(online)].pdf 2017-08-29
28 439-CHENP-2009 CORRESPONDENCE OTHERS 04-02-2014.pdf 2014-02-04
28 439-CHENP-2009-COMPLETE SPECIFICATION [29-08-2017(online)].pdf 2017-08-29
29 439-CHENP-2009 CORRESPONDENCE OTHERS 10-06-2013.pdf 2013-06-10
29 439-CHENP-2009-CLAIMS [29-08-2017(online)].pdf 2017-08-29
30 439-CHENP-2009 FORM-3 10-06-2013.pdf 2013-06-10
30 439-CHENP-2009-ABSTRACT [29-08-2017(online)].pdf 2017-08-29
31 0439-chenp-2009 abstract.pdf 2011-09-03
31 Correspondence by Agent_Notarized Assignment_31-08-2017.pdf 2017-08-31
32 0439-chenp-2009 claims.pdf 2011-09-03
32 Marked up Claims_Granted 313705_04-06-2019.pdf 2019-06-04
33 0439-chenp-2009 correspondence-others.pdf 2011-09-03
33 Drawings_Granted 313705_04-06-2019.pdf 2019-06-04
34 0439-chenp-2009 description (complete).pdf 2011-09-03
34 Description_Granted 313705_04-06-2019.pdf 2019-06-04
35 0439-chenp-2009 drawings.pdf 2011-09-03
35 Claims_Granted 313705_04-06-2019.pdf 2019-06-04
36 Abstract_Granted 313705_04-06-2019.pdf 2019-06-04
36 0439-chenp-2009 form-1.pdf 2011-09-03
37 439-CHENP-2009-PatentCertificate04-06-2019.pdf 2019-06-04
37 0439-chenp-2009 form-3.pdf 2011-09-03
38 439-CHENP-2009-IntimationOfGrant04-06-2019.pdf 2019-06-04
38 0439-chenp-2009 form-5.pdf 2011-09-03
39 439-CHENP-2009-RELEVANT DOCUMENTS [23-03-2020(online)].pdf 2020-03-23
39 0439-chenp-2009 pct.pdf 2011-09-03
40 439-CHENP-2009-RELEVANT DOCUMENTS [18-09-2021(online)].pdf 2021-09-18
40 439-chenp-2009 correspondence others 02-12-2010.pdf 2010-12-02
41 439-CHENP-2009-RELEVANT DOCUMENTS [26-08-2022(online)].pdf 2022-08-26
41 439-CHENP-2009 FORM-13 02-12-2010.pdf 2010-12-02
42 439-CHENP-2009 FORM-18 29-06-2010.pdf 2010-06-29
42 439-CHENP-2009-RELEVANT DOCUMENTS [03-08-2023(online)].pdf 2023-08-03

Search Strategy

1 search_07-03-2017.pdf

ERegister / Renewals

3rd: 29 Aug 2019

From 03/07/2009 - To 03/07/2010

4th: 29 Aug 2019

From 03/07/2010 - To 03/07/2011

5th: 29 Aug 2019

From 03/07/2011 - To 03/07/2012

6th: 29 Aug 2019

From 03/07/2012 - To 03/07/2013

7th: 29 Aug 2019

From 03/07/2013 - To 03/07/2014

8th: 29 Aug 2019

From 03/07/2014 - To 03/07/2015

9th: 29 Aug 2019

From 03/07/2015 - To 03/07/2016

10th: 29 Aug 2019

From 03/07/2016 - To 03/07/2017

11th: 29 Aug 2019

From 03/07/2017 - To 03/07/2018

12th: 29 Aug 2019

From 03/07/2018 - To 03/07/2019

13th: 29 Aug 2019

From 03/07/2019 - To 03/07/2020

14th: 29 Aug 2019

From 03/07/2020 - To 03/07/2021

15th: 03 Jun 2021

From 03/07/2021 - To 03/07/2022

16th: 01 Jun 2022

From 03/07/2022 - To 03/07/2023

17th: 01 Jun 2023

From 03/07/2023 - To 03/07/2024

18th: 11 Jun 2024

From 03/07/2024 - To 03/07/2025

19th: 05 Jun 2025

From 03/07/2025 - To 03/07/2026